概要
ペアプロを導入しているが、改めてペアプロも目的について考える
今回は、ペアプロするための環境については触れません
ペアプロとは
- 一つのプログラムを二人で共同開発する手法
- ドライバーとナビゲーターに分かれて開発する
- ナビゲーターは、指示する人
- ドライバーは、実際に操作する人
- アジャイル開発の現場でよく使われる
ナビゲーターの役割
- ドライバーが書いているものが正しいかチェック
- ドライバーに問題が発生したら、問題解消のための提案をする
ドライバーの役割
- 実際にキーボードを叩いて操作する
なぜペアプロは必要なのか
メリット
- 常に設計から実装までを共有しているので、レビュー時間の短縮 (ペアプロ自体がレビュー)
- 属人化の解消
- 他の人のやり方が観れるので、知識の共有 (ペアプロ自体がナレッジマネジメント)
- スキルの向上
- 常にナレッジの共有ができるので、メンバーの技術力がわかる (ペアプロ自体がほぼ新人教育)
- 若手の育成
- コミュニケーションをとるので、チームワークの向上 (ペアプロ自体がほぼ1on1)
- チームビルディング
その結果
- チーム生産性の向上
- ソフトウェア品質の向上
逆にペアプロしないと起こること
- ソフトフェア知識の属人化がすすむ
- 他人のコードの影響範囲がわからないので、仕様変更が難航する
- ゼロベースからのコードレビューには時間がかかる
- 知識が独学になりがちになる
- チームでの実装方法に乖離がでる
- 自分が成長するための時間を別途に作らないといけない
- メンバーの技術力が把握できない
- 若手がどこまで育っているのか把握できない
- 若手の育成時間を作らないといけない
- メンバーとのコミュニケーション機会がなくなる
- チームじゃなくても良いと思い始める
- 気持ちの乖離が発生しても解消する機会を喪失
- などなど...
ペアプロしないで実際に起こったこと
- レビューの工数過多で、スケジュールに間に合わない
- 仕様の考慮漏れが発生 (品質が不安定)
- 若手の成長が見えない (教育の不安定)
- 一人で開発に悩んでしまって1日溶かしてしまった (開発速度が不安定)
- などなど...
まとめ
結論
不確実性を排除し、コントローラブルなチームにするためには、ペアプロはするべき
ペアプロしない方が良い場合もある
- 既に属人化が解消されている実装
- 小さなbugfix
- 小さなリファクタリング
- ペアプロ外からのレビューに対する修正
- PoC開発 (品質が重要視されないパターン)
- ドキュメントを大前提とした開発 (開発後に人がすぐ変わることが多いパターン)
- 契約書ベースの開発 (受注開発など)
ペアプロでよくある課題 + 対策
- 技術力に差がある場合がある
- ある程度力関係が同じ方がやりやすい
- または、若手教育として割り切る
- コーディングの宗教論争で対立
- ADRで、アーキテクチャや思想を事前に共有しておく
- 力関係に気を遣って思うようにできない時がある
- 力が強い側が心理的安全性を確保するアプローチを取る
- 思考回路が異なり、ナビゲーターが過剰に口を出してしまい、ドライバーがやりづらそうにする
- ドライバーはこれからする事を口に出し、ナビゲーターを心配にさせない (例えば、「今考え中」も口に出す)
- また、コーディングを始める前に、実装の単位や実装の順番の認識合わせをしてから始める
以上です！
外伝: モブプロというものもある
モブプロとは
- ペアプロは2人、モブプロは3人以上
- ナビゲーターがたくさんいる
モブプロって流石にやりすぎじゃないのか
- 見ているだけの人が多くなる
- 全体の開発人数が少なくなる
でも、モブプロが必要な時もあるはず
どういったときにモブプロが向いているか
- 若手育成に特化する時
- 複数人の若手を一人で担当
- 現在のタスクの生産性向上ではなく、長い目で見た生産性の向上を目的とする時
- 今後の基盤となる設計・実装
- コーディング方針を決める必要があるタスク
- 重要な仕様の共有会
実際にあったよくない話
- 半日ほど5人でモブプロ、半分の人はお茶飲んでいるだけだった
- 手も動かさず、口も動かさず、午前中が終わる
- 自分の存在意義を感じず、モチベーション低下
モブプロは、考えないで実施すると損失が大きい
モブプロのメンバーの種類
- ファシリテーター
- ドライバー (プログラミングする人、議事ログ)
- ナビゲーター (指示する人)
- オブザーバー (学習するひと)
- リスナー (ただ聞いているだけ)