ペアプロという選択肢

ペアプロのメリット・デメリットをまとめました

Transcript

1. ペアプロという選択肢
   @nerusan
   

   View Slide

2. 目次
   1. 背景
   2. 提案
   3. 効果
   2
   

   View Slide

3. 目次
   1. 背景
   2. 提案
   3. 効果
   3
   

   View Slide

4. 背景：現状の開発課題
   ● 作った人が退職しており修正に時間がかかる
   ● ドキュメントがない、間違っている、古い
   ● コードが複雑で何か書いているかわからない
   ● 誰かが休むと仕事が止まる
   ● キャリアチェンジしにくい（フロントからバックなど）
   4
   属人化により運用が大変
   

   View Slide

5. 背景：ありたい姿
   人の移動を前提とした開発体制
   ● 急な人の入れ替わりが発生しても
   問題なく開発可能
   ○ キャリアチェンジ
   ○ 転職
   ○ 休暇
   5
   フロントエンド
   React/CSS/TS
   バックエンド
   Go/SQL/REST
   

   View Slide

6. 背景：課題
   とりあえず動くものを早くお客様に届けることが評価される文化を変え
   ることが大事
   ● 運用をあまり考えていない個人任せの開発スタイル
   ● とりあえず動くものを早くお客様に届けることが評価される文化
   ● シンプルより多機能(一部顧客しか利用しない機能)が良いとされる
   6
   技術力に対して月のリリースが多
   くて作るので手一杯...
   人が足りず、スケジュールも間に
   合わない...
   企画 開発
   

   View Slide

7. 目次
   1. 背景
   2. 提案
   3. 効果
   7
   

   View Slide

8. 提案：アジャイル開発の登場
   短いサイクルで繰り返し開発することで素早く開発する手法
   ● XP（エクストリームプログラミング）
   ○ 変更への対応力を高めた手法
   ○ テスト駆動開発
   ○ ペアプログラミング/モブプログラミング
   ● スクラム
   ○ スケジューリングや進捗を重視する手法
   ○ デイリースクラム
   ○ スプリントプランニング
   8
   

   View Slide

9. 提案：アジャイルが解決すること
   長期運用を見据えた開発が可能
   9
   https://udemy.benesse.co.jp/development/system/agile.html
   

   View Slide

10. 提案：ペアプログラミングの提案
    1つのエディターを共有して2人でコードを実装する
    アジャイル開発とともに採用されることが多い
    ２人以上で行うことはモブプログラミングともいう
    10
    ドライバー
    コードを書く人
    ナビゲーター
    ドライバーを補佐
    

    View Slide

11. 提案：具体的なやり方：設計
    設計とテスト作成もペアで行い、抜け漏れを防ぐ
    ペアの組み合わせ
    ● バックエンド１名、フロント１名 ←人員不足も解消できる
    ● バック２名
    ● フロント２名
    11
    

    View Slide

12. 提案：具体的なやり方：実装
    ● ドライバー
    ○ 主導的にコードを書く
    ● ナビゲーター
    ○ ドライバーの補佐
    ○ ドライバー行き詰まったら一緒に考える
    ○ リファクタの指示
    ○ 仕様書確認・更新
    ● 1時間おきまたはキリの良いタイミングで交代
    12
    

    View Slide

13. 提案：具体的なやり方：フロント１名バック１名の場合
    13
    設計 バック実装 フロント実装 テスト
    ペアで詳細設計
    Swagger作成
    DB設計
    画面設計
    ペアプロ
    Swagger・仕様書
    をもとに実装
    ペアプロ
    Swagger・仕様書
    を元に実装
    

    View Slide

14. 目次
    1. 背景
    2. 提案
    3. 効果
    14
    

    View Slide

15. 効果：メリット
    ● キャリアチェンジしやすい
    ○ フロント、バックどちらもチャレンジしやすい環境
    ○ 一方の人員不足を解消できる
    ● 人の出入り容易
    ○ 新しい人は入りやすいし、転職しやすい
    ○ 採用に繋がる
    ● 相互確認でミスを防止
    ○ コード及びサービス品質向上
    ● リモートによるコミュニケーション不足の解消
    ○ 相談しやすいので効率にも繋がる
    ● エディターの使い方、コマンド操作も学べる
    15
    

    View Slide

16. 効果：デメリット
    ● 工数が増える
    ○ 毎月のリリースを少し調整する必要がある
    ● 対立が起きると効率が下がる
    ○ 実装方法の違いで争う可能性がある
    ● 自身のペースでできない
    ○ 一人でやる方が効率的な人にとって不向き
    16
    

    View Slide

17. 効果：デメリットに対する考え
    ● 工数が増える
    →トラブル対応が全員可能
    →技術的ナレッジ形成
    →長期的にみて効率化につながる
    ● 毎月のリリースを調整（減らす）する必要がある
    →代わりに品質活動に時間を当てているので今後の拡張性、品質が良くなる
    →スウォーミングを導入するなどで改善
    17
    

    View Slide

18. 効果：工数
    Laurie Williamsのペアプロ効果に対する研究[1]によると、ペアプロによって
    工数が2倍になるのではなく
    15%増、バグの数は15%減
    プログラムの正確性は15%向上し、最終的な成果としては、
    15%から
    60%の効率向上があるとされている
    [1] https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
    18
    

    View Slide

19. 提案：採用している会社
    メルカリ
    https://engineering.mercari.com/blog/entry/2018-06-27-100628/
    サイボウズ
    https://blog.cybozu.io/entry/2022/06/08/141944
    https://blog.cybozu.io/entry/2022/04/14/170000
    LayerX
    https://tech.layerx.co.jp/entry/2021/04/09/090000
    Yahoo
    https://about.yahoo.co.jp/hr/linotice/20180925.html
    19
    

    View Slide

20. 提案：採用している会社
    ZOZO
    https://techblog.zozo.com/entry/remote-pairprogramming
    グロービス
    https://note.com/globis_engineers/n/n739a36da3893
    クラスメソッド
    https://dev.classmethod.jp/articles/try-remote-pair-programming/
    ホワイトプラス
    https://style.wh-plus.co.jp/enginners-development-style-b/
    20
    

    View Slide

21. 提案：サイボウズの事例１
    ● 基本モブプロ
    ● 参加人数2~4人
    ● ドライバー
    ○ ナビゲーターに説明しつつ自主的
    にどんどん記述
    ○ 行き詰まったらナビゲータと解決
    に向けて調査
    ● ナビゲーター
    ○ ドライバーの意図を読み取り、リ
    ファクタの指示などしたりする
    ○ つまづいた点、参考になった点な
    どメモに残す（ナレッジ形成）
    21
    https://blog.cybozu.io/entry/2022/04/14/170000
    

    View Slide

22. 提案：サイボウズの事例２
    ソロプロとモブプロを両立したスウォーミング
    22
    https://blog.cybozu.io/entry/2022/06/08/141944
    

    View Slide

23. 提案：サイボウズでの事例２
    23
    優先度の高いタス
    ク担当者をキャプ
    テン
    優先度 高
    

    View Slide

24. 提案：サイボウズの事例２
    キャプテンから招集がかかれば、メンバーは作業を止めて、
    モブプログラミングを行い早急解決に努める
    24
    

    View Slide