ペア・プログラミング

アジャイルのプラクティスを、もう一度解説して行きたいと思います。できるだけ、日本の文脈にあった内容を加えて、実践できるように。また、野中先生に後でコメントを頂く予定。

• ペア・プログラミング

文字通り、2人一組になってペアでプログラミングを行う。XPでの１つのプラクティスに挙げられており、１台のPCを交互に使って行うのが基本形。昨今ではデュアルディスプレーを使ったり、ネットワークと画面共有を使ったりして遠隔地で実践しているチームもある。

コーディングは単純作業ではない。１つ１つの変数や操作の名前を決めることや、その構造、アルゴリズムにいたるまで、多くの設計判断が入り込む、クリエイティブな活動である。また、ミスが起こりやすい作業でもある。刑事やパイロット、スキューバダイビングなど、リスクが高い作業はペアで行うことは現実の世界にはたくさんある。二人でプログラミングを行うことで、リアルタイムにレビューをしていく効果、また、コードの中に注入されていく知識を共有していく効果がある。

別の視点からは、会話をしながら考えを共有することで、チームの一体感も高まるし、よいアイディアが出やすい。実際にキーボードを打っている方を「ドライバ」、横で一歩引いた視点から助言や質問を投げる方を「ナビゲータ」という。ペアの交代は１５分くらいの短い間隔で行われ、開発のメリハリ、リズムも生まれる。特に、「テスト駆動開発」（後でリンク）と組み合わせることで、より会話を誘発してプログラミング活動を対話として捉えることもできる。

また、一人で書かれたコードは、独りよがりでその人しか読めないような職人コードになる傾向があり、これを回避する効果もある。すなわち、リアルタイムにレビューしながらコーディングしている、という感覚だ。レビューを後回しにするのでなく、その場で行うことで、設計のエラーをフロントロードできる。

最初の写真はAstahの中国チームの立ち上げ初期に、できるだけ日本のプログラマと中国のプログラマをペアにすることによって、知識を伝達しているところ。

よくある質問：

• 工数が２倍になりませんか？

管理者からは、効率を心配する声があがることが多いプラクティスでもあるが、ペアプログラミングによる工数の増加は2倍ではなく、1.15倍であり、その代わりバグの混入率が１５％低下するテストパス率が15%向上するという報告がある。後になってバグを取り除く工数を考えると、効果は高いと言える。また、この質問は、開発行程、テスト行程、などを分けて工数管理している組織から多い。請負契約などを含めて行程が分断されて、部分最適が起こり始めると、全体の品質向上という視点から離れてしまいがち。

• 二人でプログラミングって、集中できますか？

実際にやってみるとわかるのだが、ペアプロは非常に疲れる。脳を酷使しながらコミュニケーションを取るからだろう。ペアプロの机には、チョコレートなどのお菓子を置くことが推奨されている。（写真２では周囲にお菓子を配置）

参考情報：
すべてのプログラミングをペアで行うべきかどうかには、意見が分かれる。Jim Coplienはプログラミング作業だけでなくリスクが大きい作業や逆にクリエイティブな作業はペアで行ったほうが効果的としており、より広くPairwise Work"Developing In Pairs"という言葉を使っている（組織プロセスパターン）。また、ペアプログラミングの研究はLaurie Williamsが大きく貢献しており、書籍『ペアプログラミング』にさまざまな組み合わせ（初心者と上級者のマトリクス）が上げられている。

野中先生への言及ポイント：
マイケル・ポランニーの身体知と場、についてペアプログラミングの解釈をお願い。