はじめに
本文はペアプログラミングについての資料を調査した結果を報告するとともに、その有効性について考察するものです．多くの内容はLaurie William の執筆した「ペアプログラミング エンジニアとしての指南書」と彼女の論文が元になっています．
ペアプログラミング
概要
ペアプログラミングとはプログラミングスタイルの一つで，「二人」のプログラマが共同で実装を行うことです．一人が実際のコードを記述し、もう一人はそれをチェックしながらナビゲートをします。この役割を随時交代しながら作業を進めます．
効果
ペアプログラミングを行うことで様々な効果が期待できます．ここではそのいくつかを紹介します．
レビュー効果
ナビゲーターが常時，実装のチェックを行うため，コードレビューを常時行っているのと同等の効果が発生します．このことにより，高品質な製品の作成を期待できます．
デバッグ時の効果
問題を他人に説明するだけで，その問題を解決したという経験を誰もがした事があると思います．ペアを組むことにより，その説明を行う機会が多くなり，早期に問題を解決できる効果があります．
ペア間の学習
ツール使用のコツ，プログラミング言語，設計方法など様々な知識，ノウハウがパートナー間で共有できます．特に文字や言葉では伝えられない技術の継承ができるベストに近い方法です．このことは新入社員の教育や新しくプロジェクトに入った人間のトレーニングとしての効果が発揮できます．
人材喪失のリスク削減
ペアプログラミングによってどのタスクも最低，二人以上は経験者が存在することになります．
これにより、バックアップとフォロー体性を整えることができ、人的資源の消耗を抑えることができます．
また，最悪の場合でも，トラックナンバーを増やすことができます．トラックナンバーとは「何人のプログラマがトラックに轢かれたら(=退職)プロジェクトが立ち行かなくなるか」という数値です．もちろん最悪は１人です．ペアプログラミングを行うことにより，（最悪でも）トラックナンバーが２以上になります．
ペアプレッシャー
ペアプログラマは互いに建設的なプレッシャーを掛け合います．プログラマは熱心かつ懸命にプログラムに取り組むようになります．それはパートナーを失望させたくないからです．
ペアプログラミングの歴史と事例
ペアプログラミングの概念は決して新しいものではありません．ここでは過去に報告された事例について紹介します
Fred Brookの報告
「人月の神話」の著者Fred Brooksはペアプログラミングの研究を行っているLaurie Williams に次のようなメールを送っています．
「同級生のBill Wright と私は大学院の時(1953-1956)に初めてペアプログラミングをためしました．私たちは1500行の欠陥なしのコードを作成しました．それは一回で正常に動作しました」
Dick Gabrielの事例
Common Lisp (CL) の考案者，Dick Gabrielは1972-1973までMIT人工知能研究所にいました．そのころ，ペアプログラミングが一般的に実践されていたと述べています．その後，彼がイリノイ大学とスタンフォード大学に在籍中にJonl WhiteとペアプログラミングをおこないMacLisp の移植作業をおこなっています．
Larry Constantineの報告
「ソフトウェア開発のカオス」の著者Larry Constantine はWhitesmith社での「ダイナミックデュオ」と呼ばれる開発方法を観察して，より早く，欠陥なしでコードが生産されたことを報告しました．
彼は二人のプログラマは余剰ではなく，効率と品質を増すための近道になると，1995年に結論付けています．
Jim Coplien(James O Coplien) の報告
「C++プログラミングの筋と定石」の著者Jim Coplienは“Developing in Pairs”というパターンを1995年に発表しました．「ペア開発者は個々の開発者より盲点が少ない傾向があり，より効率的なプロセスになる」と述べています．
ヒル空軍基地の事例
二人一組になる手法をおこなった，ヒル空軍基地でのプロジェクトは次のような結果を残しています．
このプロジェクトでの総生産量は人月あたりの生産行数(llpm)は175lppmでした．一方，一般的な生産量は77llpmに過ぎませんでした．またシステム統合時のエラー率は組織基準よりも３桁低い数字でした．
C3の事例
Chrysler Comprehensive Compensation project 略称 C3，クライスラーで実施された給与計算プロジェクトです.COBOLベースの既存給与計算システムをリプレスする作業でしたが、安定した状態を得る事ができませんでした．
その後，1996年にKent Beckがプロジェクトを立て直すため投入されました．そのとき実践した項目のなかにペアプログラミングが含まれています．Kent Beckは次のように述べています．
「ここ半年の間で発生した唯一の問題は，ペアを組まずに書いたコードが引き起こしたものだけです」
ペアプログラミングの実験
ペアプログラミングとソロでのプログラミングにどのような差があるか実験した結果を紹介します．
この実験は1999年にユタ大学で行われたものです．この実験ではソロプログラムとペアプログラムが直接対決しています．
実験の概要
上級ソフトウェアエンジニア課程に在籍する学生41人を対象に実験を行いました．学生たちは全員同じクラスに出席し，同じ指導を受けて，ペアプログラミングについて賛否両論の講義理論に参加しました．
その後，学生を２グループに分けました．グループは成績が優，良，可の学生が同じ割合になるように構成しています．
13人の学生には学生全員が同じ課題に対して個々に作業を行う対照群を形成しました．
28人の学生は全員で２人チームを組み，作業を行う実験群を形成しました．実験群と対照群は同じ課題を仕上げます．（共同作業を行うペアには２グループ間で同じ作業負荷になるように追加の課題を割り当てました．）
そして,品質，生産性，士気について情報を収集しました．
実験の結果
品質
各課題を自動化された開発後テストを実施した結果以下のようになりました．
ペアで作成した場合，15%少ない欠陥率になりました．また，この欠陥率の結果はペアの場合，安定していましたが，個人の場合，平均値から変動が大きくなっていました．さらに，個人は断続的にプログラムを提出しなかったり，遅れたりすることがありましたが，ペアは予定通り提出しました．これはペア間のプレッシャーによるものだと考えられます．
また，ペアが作成したプログラムは常に個人より20%少ない行数で同じ機能を作成できました。
生産性
各作業にどれだけの時間がかかったか記録をしました．結果，最初ペアは一人の場合より，60%多い人時をついやしましたが，平均的には15%の多くの時間しか使っていませんでした．また，これには統計的な有意性はありませんでした．それは13組中2組で平均値が吊り上げられていたためです．一人および，ペアの時間コストの中央値は本質的に一致していました．
士気
80％以上の学生が，作業を楽しみ，かつ自分のおこなった作業に自信が持てたとアンケートに答えました.
実験のまとめ
Williamsはこの実験結果を以下のようにまとめています．
・ペアは高品質のコードを作成します．
・ペアでおこなった場合，平均的には15%の余計な時間しか使用しません．
・ペアは自分の仕事に楽しみと自信を与えます．
コードの開発時間が15%増加しますが，品質が高くなるので，将来的なリソースが減少します．そのため，投資する価値は十分にあると,Williamsは述べています．
実験方法の批判的見解
上記のユタ大学の実験は，ペアプログラミングを導入する際の強い資料になり得ると思いました．
しかし，この実験方法には問題がありました．この実験に批判的な見解を紹介します．
実験群の選出方法の問題
実験群の28人はランダムで選ばれたわけではありません．共同作業を行いたい志願者35人の中から28人を選択したことになります．つまり，6人は志望とことなる対照群に入ることになります．これらのことは人員の構成に偏りを生じることになります．
・実験群の全員は自分が望むグループに所属しました．対照群は半数が望まないグループに所属しています．これはその後の彼らの性能に影響を与える可能性はあります．
・実験群の全員は熱意あるボランティアであり，より大きな能力で作業を進めるでしょう．この特性は対照群の7人が持っていないものです．
・実験群に与えられた追加課題は彼らの能力や士気にいい影響を与えた可能性があります．
・14組中13人は自分でパートナーを選択しました．したがって実験は一般的なペアプログラミングではなく，関係者が自分でパートナーを選べる特別な実験になっています
そして，この人員の偏りはアンケートに対して肯定的な答えを返すことになります．なぜなら彼らは良い条件でパートナーを選択しています．また，自分で志願して，ペアプログラミングを行った人間ばかりなので肯定的な答えが返るようになります．
ホーソン効果
ホーソン効果とは自分が観察の対象になっているという意識が生産性を向上させる効果のことです．
この実験に参加した人間はWilliamsが共同ソフト開発の権威であることを知っています．また，Williamsは彼らにとってはボスです．
彼らは意識的かそうでないかはともかく，Williamsにとって好ましい結果を作成するように振う動機付けがされます．
プラシーボ効果
Williamsの実験の重大の弱点は独立して行わなかった事です．この実験の前にペアプログラミングについての指導を行っています．そのため，被験者が効果があると思い込んでしまう可能性は高いです
実験結果ついて
実はこの研究では４回実験を行っています．４回の実験のうち，最後の実験は無効とされており，最初の実験は変則的であるとして無視されており，所要時間の情報は統計的に重要でないとされています．
これはWilliamsにとって必要な結果に偏っているといえるでしょう．
批判的な見解のまとめ
これらのことをまとめると，この実験の信頼性は低く，この実験をペアプログラミングの擁護の手段に引き出すのは問題があります．
考察
ペアプログラミングについての個人的な考察を本項では述べます．
残念ながら，常時，ペアプログラムを採用することのは費用対効果を考えた場合，現状では慎重にならざるを得ません．少なくともコストと品質の計算ができるデータが揃うまでは実践することは難しいでしょう．
経験と直感的にペアプログラミングを考えた場合，品質は確実に上がると思います．生産量も一人でやるよりもあがる可能性はある場合が多いと考えられます．ただ，人的資源を二倍使用するコストに対する効果を得たと証明するのは難しいでしょう．また，品質を追求するなら，テスト駆動型の開発，あるいは継続的なレビューなどで代替可能です．開発者からも導入の抵抗が強いペアプログラミングをあえて採用するにはメリットが少ないと思われます．
その上で現状，ペアプログラミングという手段を取るとしたら以下の状況が考えられます．
(1) 教育/訓練
新入社員の教育や，新しくプロジェクトに投入された人材の訓練を行う際に利用します．ペア間でのノウハウの共有が通常より速く進むことを期待します．
(2) プロジェクトの立ち上げ時
ペア間でノウハウの共有を進める効果と共にチームワークを育む効果を期待します．
(3) ボトルネックの作業
並列で作業を行えない状況の時に，ボトルネックをペアプログラミングで可能な限り早く，正確に完了させます．
最後に，ペアプログラミングは大きな可能性と魅力を感じる開発手法です．少なくとも,言葉や文章で伝えられない暗黙知の共有を行うには最善の手段の一つだと考えています．これは長期的なスパンで考えた場合,ペアプログラミングの最大の効果だと考えています. 常時行うのは資源や環境的に厳しいにせよ,状況によっては採用を検討するに値する手法だと思います.
参考文献
[1]Laurie Williams, Robert Kessler 「ペアプログラミング エンジニアとしての指南書」,テクノロジックアート，2003
[2]ペアプログラミングのチュートリアル
[3]Radium Software Development
[4]Experimenting with Industry’s “Pair-Programming” Model in the Computer Science Classroom
[5]ペアプロにメタファ適用
[6]Joel on Software射撃しつつ前進
[7]山崎敏 「火事場プロジェクトの法則」,技術評論社，2006