これは何？

投稿時に在籍していた会社で、新メンバーのオンボーディングを兼ねたペアプログラミングを実施しました。
これはその成果と課題について整理し、次に活かすためのドキュメントです。

ペアプログラミングとは？

ラリーレースのように、実際にコードを書いてプログラムを動かす人をドライバー、どのように書くかを案内する人をナビゲーターとして、二人三脚でコーディングする手法です。

もう少し細かい役割は以下のとおりです。

ドライバー
- 実際に手を動かしてコードを書く人
- ナビゲータのサポートの元、プログラムを完成させることに集中する
- 実装の細かい部分を考える
ナビゲーター
- ドライバが気持ちよくコードを書く事をサポートする人
- ドライバが書いたコードを横から常にレビューする(コーディングスタイル、バグのチェック、コードの簡潔化の提言、etc)
- プログラムを書く上での大局的な問題を考える

引用：ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話

ペアプロのメリットとデメリット

Wikipediaより引用。

メリット

規範意識の増大。
- ペアプログラミングでは、個人の作業よりも怠けることなく作業を進める可能性が高い。
よりよいコード。
- 相乗効果により設計の質が向上することが期待される。
作業効率の向上。
- 1人で作業するときとは流れが変わる。例えば、次に何をすべきか考え込むといったことが少なくなる。また、外乱要因に対しても耐性を示し、他の人が割り込んできても、一方が応対している間にもう一方が作業を進められる。
- 常にレビューされた状態となるため、別途レビューのための時間を確保しなくても良くなる
- ペアプログラミングの生産性は、1人で作業した場合の2倍以上であることが研究によって示されている。
多数の開発者による設計。
- ペアを頻繁に入れ替えれば、複数の人間が1つの機能の開発に関わることになる。これにより、よりよい設計が生み出される。例えば、あるペアが解決できない問題で作業が止まってしまっても、別のペアでは解決できることもある。
勤労意欲の向上。
- ペアプログラミングの方が1人で作業するよりも楽しいと感じる開発者もいる。
集団的なコード所有権。
- プロジェクトの全員がペアプログラミングを行い、頻繁にペアを組みかえる場合、そのコード全体について全員がそれなりの知識を共有することになる。
教育的側面。
- 初心者であっても固有の知識（プログラミングテクニックなど）を持っているものである。ペアプログラミングでは、余計な手間をかけずに、そのような知識をチーム全体で共有できる。
チームワーク。
- ペアプログラミングを行うことで、チームの各人が互いをよりよく知ることができ、結束力を生み出しやすい。
割り込みの削減。
- 1人で作業している人に割り込みをかけるよりも、ペアプログラミング中の2人に割り込みをかける方が抵抗があるため、割り込みが少なくなる。
ワークステーション数の削減。
- 2人で1台のワークステーションを使うため、ワークステーションが少なくて済み、余ったワークステーションを他の用途に活用できる。

デメリット

経験を積んだ開発者によっては、初心者とのペアプログラミングを退屈な指導と捉える場合もある。
一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。
プログラマの生産性についてはさまざまな議論があり、ペアプログラミングで生産性が必ず向上することが保証されているわけではない。
コーディング・スタイルの違いによって、一種の衝突が発生する場合もある。

今回実施した内容

期間：2018/10/11〜10/24（2週間のスプリント）
対象チケット：12枚

厳密な役割遵守はしていません。
今回はスプリント本格参戦したてのメンバーのオンボーディングを兼ねているため、どちらがコーディングしていても、ナビゲーターは常に自分でした。
なので、ペアプロもどき状態でした。

また、コーチするにあたっての姿勢としては、以下の記事を参考にしました。
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

成果

観点	成果	コメント
規範意識の増大	◎	迷惑がかかるので、怠けられないですね
よりよいコード	△	相乗効果で出るほどシンクロした感はなし
作業効率の向上	△	教育的側面を強くしたこともあり、１人で実施した場合と比較して、被教育者の効率は上がるが、コーチ役の効率は下がる。常にレビューされた状態なので、そもそも論的な間違いは軽減される。とは言え、第三者的レビュー観点は失われがち。
多数の開発者による設計	-	今回は１ペアのみで実施のため、対象外
勤労意欲の向上	-	これは個々人の感想のため、対象外
集団的なコード所有権	-	今回は１ペアのみで実施のため、対象外
教育的側面	◎	担当プロダクト, 言語, フレームワーク, プログラミング技法いずれにおいても、被教育者が得られるものは大きいはず
チームワーク	○	ずっと話しているので、普通にやっていれば良くなると思う。ただし、初学者に対してイライラしてしまう人には向いてないと思います。
割り込みの削減	○	今回はよくある割込タスクがほぼなかった。たまたまかも知れない。打合せスペースで籠もってやれば割り込みされなくなる。
ワークステーション数の削減	△	２台あったほうが調べ物は捗る

課題

よりよいコード
- スキル面で拮抗するペアのほうがよいoutputが出そう
- 教育的側面が強い場合は、コーチ役のスキルが上限になってしまう
作業効率の向上
- 被教育者的には思考の流れが整理され、一人で実施する場合よりも作業効率が上がる
- ただし、教育的側面が多くを占めると、そちらに引きづられるために効率は上がらない
- 教育的側面では、常にレビューされた状態となるため、そもそも間違っていて手戻りしてしまうということは防げる
- ただし、この場合は実質１人によるアウトプットになりがちなので、第三者レビューが必要になりレビュー時間削減とはならない

総評

教育的側面を重視するならば、非常に効果があると思います。
実際、マンツーマンの個別塾状態なので、短時間で多くのinputを得られるはず。
また、一人で考え込んで迷ってしまう状態にはならず、どうやれば突破できるのかを気づかせることが可能です。
これの反復によって、そのクセが付くようになれば良いと思います。

効率面では、やはりスキルが互いに拮抗し合う状態でないと極大化しないと感じました。

今回は純粋なペアプロではなかったので、ペアプロでは効率上がらん！とは言えないです。

まとめ

ペアプロはオンボーディング手法としては使える
効率を上げるにはスキルバランスの良いペアとすべき

最後に、この言葉を引用しておきます。

ペアプロは、XPの中でも一番過激なプラクティスです。教育的な意味でも、品質向上の面でも、うまくはまれば効果は高いのですけれど、その分、副作用も出てきがちです。

引用元：ペアプロ導入事例：「Lean XP」の一部としてペアプロの導入に挑んだ「ヤフオク!」

参考