ペアプログラミング

ペアプログラミング（英: pair programming）は、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人で作業することを好み、ペアでの作業を面倒と感じる場合もある。
• プログラマの生産性については様々な議論があり、ペアプログラミングで生産性が向上するという共通認識が出来上がっているわけではない。
• 経験を積んだ技術者は非常に正確なコードを書く。従って、ペアを組んだとしても、もう1人が何か寄与することは難しい。
  • ペアプログラミングの目的は、正確性の向上だけでなく、知識や技術の共有にもある。
• コーディング・スタイルの違いによる一種の衝突が発生する場合もある。
  • エクストリーム・プログラミングなどでは、コーディング・スタイルは統一すべき物であるとしている。
• 各人のスケジュールが異なるようなプロジェクトでは、スケジュールがうまく合ったときだけペアプログラミングが可能となる。つまり、ペアプログラミングで作業にかかる工数が増えるだけでなく、ペアプログラミングに一日当たり割ける時間が限られ、結果として完了までの期間が長くなる。
  • エクストリーム・プログラミングなどでは、そもそもコードは特定の個人が独占する物ではなく、また、30分〜数時間の頻度でペアを交換する物である。つまり、その時に作業可能な2人がタスクをこなしていく物である。これが可能になるのは、エクストリーム・プログラミング自体のタスクの粒度の小ささにも由来している。

派生

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

テレワークなど、何らかの理由で遠隔地で作業する場合は、文字を入力する度に相手側のコンピュータに変更がリアルタイムで反映されるエディタや統合開発環境のプラグインを使用したり、画面転送のためのソフトウェアを使用したりして行われる。

関連項目

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

外部リンク

• "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