ペアプログラミング
〜チームの知識共有とコミュニケーションを増やします〜
ペアプログラミングとは
ペアプログラミングは、一つのPCと二つのディスプレイ、マウス、キーボードを用意し、
ミラーリングされた同じ画面を見て、二人で考え、操作し、開発をする手法のことです。
なぜ使うのか
なぜ、ペアプログラミングをするのかというと、下記、5点になります。
- 知識の共有
- 関係性の構築（チームビルディング）
- 品質の向上 （複数視点）
- コードレビューが不要になる
- テディベア効果
知識の共有
一人の人が知っている知識を効率よく、広げられます。新人を効率的に教育できます。
また、属人化が解消され、一人のスーパープログラマに頼らなくてもよくなります。
関係性の構築（チームビルディング）
孤立しがちな開発作業をペアで行うことで関係性が構築できます。
他の人がどういう考えでプログラミングをしているか
どういう思いがあるのかを知ることで
とても勉強になりますし、コミュニケーションが取りやすくなっていきます。
品質の向上 （複数視点）
ペアで行うとフロー状態（完全にのめり込んでいる状態）に入りづらくなるので問題点に早く気づけます。
バグの発見など、二人なら一人の時よりも圧倒的に早くなります。
エンジニアであれば単純なタイポなどでかなりの時間を無駄にした経験はあるのではないでしょうか？
また、開発する際に対象の要件がこういう仕様だという思い込み、
違う仕様で作成してしまうことも
二人で話し合うことで少なくできます。
もし、食い違うようだったら
開発前に他の人に確認を取ることで手戻りも減らすことができます。
コードレビューが不要になる
ペアでプログラミングをすると
コードレビューを常にされているようなものなので
コードレビューをする必要がなく、効率が良くなります。
また、上記のため、別のプラクティスであるTrunkベース開発（ブランチを作らない開発管理手法）をやりやすくなります。
テディベア効果
こんなことを経験したことはないでしょうか？
プログラムで何かわからないことがあり、
詳しい人に質問している間に自分で答えを発見してしまう現象です。
この現象をテディベア効果と言います。
本来はテディベア（人形）に語りかけるだけでもいいのですが、
ペアプログラミングは質問して自ら答えを導き出せなくても
相手が知っていれば答えを教えてもらえますし、
たとえわからなくても、
二人で考えられるという一石二鳥以上の効果が得られます。
どうやって行うか
ペアプログラミングには、下記の二種類の方法があります。
ドライバー・ナビゲーター方式
一人がキーボードを使いプログラミングをし、（ドライバー）
一人は開発の案内を行います。（ナビゲーター）
知識の共有や教育に適しています。
ピンポンペアリング方式
交代でドライバーとナビゲーターを入れ替えます。
テスト駆動開発（TDD）と組み合わせ、テストを片方が書いたら、
もう片方が実装、などのようにするととても相性が良いです。
注意点
ペアプログラミングは慣れるまで、または、慣れていても、
注意すべき点がいくつかあります。
ローテーションしましょう
同じプロジェクト内に二つ以上のペアが作れるのであれば、ペアを入れ替えましょう。
ローテーションすることで、ペアの固定化による属人化が防げますし、知識の伝搬、関係性の構築にも効果的です。
休憩を忘れない
ペアプログラミングは非常に疲れるプラクティスです。
一日中やっていると
夜はほとんど何もする気が起きないくらい疲れます。
慣れてくるとかなり疲れは軽減されますが、
それでもこまめな休憩は必須です。
少なくとも2時間起きくらいには休憩を取るようにしましょう。
尊重する心を忘れない
ペアプログラミングで最も大切なのは高スペックのマシンでも技術力でもありません。
お互いを尊重する気持ちです。
ペアプログラミングは文字通り、お互いにコミュニケーションを取りながら、
コーディングをしていきます。
まず、お互いを知り、お互いの心地の良い環境を理解しあってこそ、
ペアプログラミングの効果が発揮できます。
よくある質問
生産性は下がりませんか？
生産性はむしろ上がるという研究結果が出ています。
一人で開発すると思い込みでの開発やバグなどの手戻りが多くなり、
全体的な開発効率は、ペアプログラミングの方が高くなる傾向があります。
実感としても、ペアプログラミングの方が開発効率も品質も高くなりやすく、
実施したプロジェクトでは一度もバグらしいバグは発生しませんでした。
また、だんだんとペア同士の理解が深まり、
スピードという観点でも一人でやる時よりも速くなる傾向がありました。
一人のプロジェクトだとできませんか？
一人のプロジェクトはお勧めしません。
一人で開発していると、その人が休み、退職などの理由で開発できなくなった場合に
大きなリスクとなります。
このリスクをはかる指標を「バス係数」と呼びます。
バス係数というのは、プロジェクト内で何人がバスに轢かれたら
プロジェクトがなりたたなくなるかの数値です。
一人プロジェクトの場合、バス係数は1となります。
バス係数を高く保つためにも、複数人のプロジェクトを推奨します。
しかし、どうしようもなく、一人で開発しているということであれば、
可能なら、他プロジェクトの人にペアプログラミングをお願いするのもよいかもしれません。
その人に対して、少しでも知見の共有ができますし、
もしかしたら、自分の知らない知識・アイディアを教えてもらえるかもしれません。
リモートで働いていてもできますか？
リモートでも工夫次第で可能です。
Visual Studio Live Shareなどのツールを使うとオンラインで
コードの直接シェアができますし、
もし、回線に自信があれば、
常時、チャットツールの画面共有でペアプログラミングをするなども可能です。
ただ、対面のペアプログラミングをしたことある人でも
慣れるのに時間がかかると思います。
少しでもやりやすくするために、
実践した際の工夫をシェアさせていただきます。
前提：Visual Studio Live ShareとSlackチャットを利用。
- 周りの音の影響が大きいので、なるべく周りが静かな環境で行う、または、イヤホンマイクで会話する（できれば指向性のあるマイク）
- 対面でのペアプログラミングをしたことがなければ、可能であれば対面でやってからリモートにする
- テスト実行はどちらか一方の環境で行なった方が無難
- 相手の様子が見えないので、考え込んで無言にならないように極力話すようにする。また、片方が置いてきぼりにならないように対面の時よりも気を遣うようにする。
- 画面が二つあるので、同時にコードを修正するというシンクロナイズドなペアプログラミングが可能 （テストと実装を同時に書くなど。成功した時はとても気持ちがいい。）
楽しいですか？
テスト駆動開発（TDD）とうまく組み合わせると新感覚コーディングを味わうことができます。
ペアプログラミングでTDDしたときに
片方がテストして、もう片方が実装みたいにやると
将棋みたいですごい楽しい
俺はこういうテストを書いた
お前ならどうやって通す？
的な
横にいるのでアドバイスしあえるのもよい
その手はいいね
でもこっちの手にするともっとよいかもね
的な
https://twitter.com/tomoya_su/status/1006497186685714432
ペアプログラミングしていると自分にない発想でコードが書かれることも多くあるので、
たとえそれが最高のコードでなかったとしても、とても刺激になりますし、楽しいと思います。
参考資料/ツール
さいごに
文章の改善のため、フィードバックや質問などありましたら、こちらからお願いいたします。