ペアプログラミング

2人のプログラマーによるペアプログラミング

ペアプログラミング（英: pair programming）はソフトウェア開発の手法の一つで、2人のプログラマが1台のマシンを操作してプログラミングを行う手法。

当初は、2人が1台のワークステーションに向かって作業するものだったが、現在では一人で複数台を同時に使ったり、一台に複数台のディスプレイを使うことも多くなり、具体的なやり方は変わっている。

実際にキーボードを操作してコードを書く人を「ドライバ」、もう1人を「ナビゲータ」と呼ぶ。30分ごとか、単体テストを1つ完成させる度に役割を交替するのがよいとされる。また、1日に一度の頻度でパートナーを変えるのがよいともされている。

利点

ペアプログラミングには、以下のような利点があるとされている。上に挙げた項目ほど重要である根拠を示していない。

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

ペアプログラミングの生産性は、1人で作業した場合の2倍以上であることが研究によって示されている。エコノミスト誌によると、

「ソルトレイクシティ、ユタ大学のLaurie Williamsによれば、ペアプログラミングでは、2人のプログラマが個人で作業した場合と比較して、コーディング速度が15%低下するが、バグの数も15%少なくなる。テストやデバッグにはコーディングよりも時間がかかるので、この調査結果は興味深い」[1]

なお、Laurie Williamsは、現在はノースカロライナ州立大学の准教授である。

Williams 他 (2000) の調査によると、プログラムの正確性は15%向上し、時間的には20%から40%程度の削減となり、最終的な成果としては、15%から60%の効率向上があるとされているが、他の条件が同じである保証はなく、他の要因を排除していない。

最近の大規模な研究（Arisholm 他 2007）によると、複雑なシステムではプログラムの正確性が48%向上し、大きな時間の削減は見られなかったとされている。一方、単純なシステムでは時間が20%削減され、正確性には大きな変化が見られなかったとされている。全体としては、時間の削減や正確性の向上の傾向はさまざまだが、最終的な効率は84%向上しているとされているが、他の条件が同じである保証はなく、他の要因を排除していない。

別の最近の研究によると、上級者1人の場合と上級者同士のペアとの間での生産性向上よりも、初心者1人と初心者同士のペアを比較した時の生産性向上のほうが大きいとされている（"Int J. of Human Computer Studies Vol (64) 2006"）。

弱点

利点の裏返しで弱点も存在している。また、利点に安住するリスクもある。

• 経験を積んだ開発者によっては、初心者とのペアプログラミングを退屈な指導と捉える場合もある。
• 一部の技術者は1人で作業することを好み、ペアでの作業を面倒と感じる場合もある。
• プログラマの生産性についてはさまざまな議論があり、ペアプログラミングで生産性が必ず向上することが保証されているわけではない。
• 経験を積んだ技術者は、非常に正確なコードを書く。その場合、ペアを組んだとしても、もう一人が何か寄与することは難しい。
  • ペアプログラミングの目的は、正確性の向上だけでなく、知識や技術の共有という面もある。
• コーディング・スタイルの違いによって、一種の衝突が発生する場合もある。
  • エクストリーム・プログラミングなどでは、コーディング・スタイルは統一すべきものであるとしている。
• 各人のスケジュールが異なるようなプロジェクトでは、スケジュールがうまくかみ合ったときにだけペアプログラミングが可能となる。したがって、その場合にペアプログラミングを採用すると、作業にかかる工数が増加するだけでなく、ペアプログラミングに割ける時間が制限され、結果として完了までの期間が長くなる。
  • エクストリーム・プログラミングなどでは、そもそもコードは特定の個人が独占するものではなく、また、30分から数時間の頻度でペアを交換するべきである。つまり、その時に作業可能な2人がタスクをこなしていくのである。これが可能になるのは、エクストリーム・プログラミング自体のタスクの粒度の小ささにも由来している。

派生

リモートペアプログラミング

テレワークなど、何らかの理由で遠隔地で作業する場合は、文字を入力する度に相手側のコンピュータに変更がリアルタイムで反映されるエディタや統合開発環境のプラグインを使用したり、画面転送のためのソフトウェアを使用したりして行われる。 git, dockerなどを利用し、同じソースの設計と試験を同時に分担して書いたり、お互いにissueを発行しながら、お互いにcloseし合うなどの方法を使うこともある。

関連項目

• エクストリーム・プログラミング

外部リンク

• "Agility counts", The Economist, Sep 20th 2001
• Stephens, M.; Rosenberg, D., "Will Pair Programming Really Improve Your Project?", Methods & Tools より
• Lui, K.M. & Chan, K.C.C. (2006), "Pair Programming Productivity: Novice-novice vs. Expert-expert", International Journal of Human-Computer Studies 64(9): 915-925, DOI:10.1016/j.ijhcs.2006.04.010
• Williams, L.; R.R. Kessler & W. Cunningham et al. (2000), "Strengthening the case for pair programming", Software, IEEE 17(4): 19-25, DOI:10.1109/52.854064
• Arisholm, E.; H. Gallis & T. Dyba et al. (2007), "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise", Software Engineering, IEEE Transactions on 33(2): 65-86, DOI:10.1109/TSE.2007.17
• Miller, R. (2003), エクストリーム・プログラミングの神秘を解く: ペアで勝つ, IBM developerWorks, Mar 11th 2003