概要
ペアプログラミングといえば、ジュニアエンジニアを育てる際など「育成」の観点から語られることの多い開発手法です。
そのためPLとして案件にアサインされ、メンバーの成長に責任を負っていた自分自身「試すなら案件が落ち着いて余裕がある時にやるべき」というイメージを持っており、良いとは聞いていたもののなかなか導入に踏み切れずにいました。（そして概して案件に落ち着いて余裕のある時、等というものは無い
）
ですが、3年続いたプロジェクトが3か月後に納期を迎える、というタイミングで敢えてペアプロ導入を決定、結果的にも大きなメリットがあったと感じたため、その経緯や効果を上げる条件などをこの記事にまとめようと思います。
なお最後に実際の手法も記載していますが、ペアプロ自体を通常のやり方と大きく変えて新しい効果を得たという話ではなく、教育以外の副次的な効用があったという方向性になります。
プロジェクト状態
- 中規模のシステム開発で、常時6～7人のエンジニアがアサインされているがメンバーの入れ替わりもある。
- 既に要件定義などから3年以上走っている案件でリリースはまだしていないものの、既にいないメンバーが作ったレガシーコード的な部分が多数あり、特にジュニアにはパッと把握するのが難しい実装になっている
- チーム構成は、案件に1年以上いるメンバーがミドルレベルが2名・同期間いるジュニアレベルが2名・半年未満のジュニア（未経験に近い人もいる）2～3名
- 業務ロジックが超複雑で、長く案件にいて案件の業界用語などに精通している人でないと完全には把握困難
導入背景
上記のような状況の中で案件も終盤に差し掛かり、案件に慣れて自走してくれるメンバーに実装のタスクを振って問題なく進めてもらう一方で、
新規メンバー（半年未満）にある程度細分化したり既存部分の修正タスクなどを振っても、レビューしてみるとデグレが発生、または「どういう状態が正なのか分からないまま実装を進めてしまい期待した状態になっていない」といったケースが頻発していた。
今まで通りの「①タスクをチケット化→②作業者に分配→③作業者が実装→④PLがレビュー」というフローだと、新規メンバーには影響範囲が明確である程度難易度の低いタスクを振らないと④での手戻り工数が多くなってしまい、メンバー数はいるのに今残っているタスクを振れる人工が十分いないという状況に陥っていた。
その状況の対策として、かねてより過去に別の会社でペアプロを経験していたPMから導入を打診されていたのもあり、下記の観点からリリースが3か月後に迫りつつある時期ではあるが、労力的にペイすると考えて導入した。
- 新人メンバーの技術的育成
- タスクの最初を案件に長くいるエンジニアがガイドすることでコードの重複や、実装箇所の取り違えや抜け漏れを防ぐ
- これにより実装者自身の実力を考えると難しいタスクも配分でき、タスクの偏りを減らせる
結果
実際の体制としては下記で行なった。
- インストラクター：PMとミドルの3名から各1名
- ペア：実務歴半年以下の中で2名で組む（足りない場合はPLも入った）
一つのタスクに、単純計算で実装者の他2名分の人工が掛かる体制だが、下記の理由で良い施策だったと考えている
- 狙い通り、期待を大きく外したPRは無くなったのでレビュー工数が大幅に減った
- そのためレビュー担当者がペアやインストラクターとして組めば、ペアプロ時に投入している人工ほど時間のロスは無さそう
- チケットを振る側が、PJの実装に慣れている人を基準に工数を見積もれるようになった
- 作業時間自体は少し多めに取るが、原因箇所の特定工数は慣れた人と一緒にやるので同じと考えられる
- Live Shareなど同期的な開発環境を全員が設定したことで、ペアプロ外での実装の質問の際もそれを使用して効率が上がった
- PRレビュー以上に手厚いフィードバックが受けられるため、実装者の満足度も高かった
手法
こちらは基本的に最後の参考資料を基に作成していて、instructorという枠を追加した部分だけが独自の取り組みとなります。
instructorを入れた理由は以下のようなものになります。
- PJにペアプロ経験者がPMしかおらず、導入初期はPMにペアを監修してもらう必要があった
- ジュニアにもobserverの役割経験を積んで貰いたかった
- 原因特定などタスク開始時のガイドはミドルも一緒に考えるが、その後のコードのクオリティについてのペアプロは業務負荷的に他の業務をしながら聞く程度でコミットしたかった
役割
driver：メインでコーディングする人
observer：driverの書くコードを眺め、エラーや設計を吟味する
instructor：（導入時期だけの特別枠）2人が役割を正しく果たせるようガイドする
フロー
- チケットを開始する前に、driverが一緒に作業する人をcalenderに招待して開始告知する
- driverはまず最初にチケットの説明と、期待値と挙動をobserverに説明する
- driverはひたすらコードについて説明しながら手を動かす
- 今なにをしようとしているか、変数名、関数名、別の短くすむやり方、今のコードが想定していない入力、driverが知っていてobserverの知らないAPIの事情etc…
- observerはdriverの説明とコードを見聞きしながら、理解できなくなったら質問したり、考慮漏れがないか、もっと良い設計がないかなどを考えてフィードバックする
- 1時間やったらその回は終了
TIPS
driver
- 悩むのも悪く無いが一人で悩むのは十秒程度に留めよう。じっくり腰を据えて悩むのは自習の時に一人でやれば良い。ペアプログラミングの時には一緒に相談しながら考える練習をしよう。
observer
- コードの書き手を一時的に変わるのは全然あり。口で言うより書いた方が早い時もある。
-
driverに指摘をするタイミングには気をつける練習をしよう。
- 読みづらいコードや文法ミスは、その行を書き終わった後に指摘する
- 大局的な問題やデザインのアイデアは、メモだけしておき、一段落した後で話す （メモ重要。人は忘れてしまう。思ったことを即書き出せるようにタイピング練習しよう）
両方
- 議論が起こるのは悪いことではないです、起きない方が上手くいってないと言えます。
- ですがその議論が解決中の問題に対して重要なことかどうかを考えて、時には譲歩することも大切です
- 書いてみないと説明しづらい場合も「ちょっと書いてみる」と口で言うこと。この類の試し書きは1分以内ですませたほうがいい。
- 一仕事すんで次の問題が見えたらお祝いをする！
参考資料
効果についての記事
やり方や押さえるべき考え方
https://gist.github.com/j5ik2o/2970973
まとめ
今回ペアプロを導入した理由は、主として「レビューによる大きな手戻りってする方もされる方もモチベ落ちてしんどいからどうにかしたい」というもので、それに対してはしっかりと効果を実感できました。
ジュニアが原因特定で掛かっていた時間とその上で手戻りを修正する時間が削減されたことで、1タスクに（最初の1時間ですが）2名以上の人工を投入するという投資も十分にペイしていたと思います。
「上手い」ペアプロが出来ていたかというと、上記の理由を優先するためにジュニア同士でペアを組ませていたのでまだまだ難しいなと感じましたが、言葉で実装を説明するという行為自体が論理的思考を鍛えるトレーニングになると思いますし、レビュー中心のプロジェクトでも併用して気軽に導入して良いのではないかと感じました。