Royal School of SignalsのStuart Wray氏は、2010年1月版のIEEE Software Magazineに「ペア・プログラミングの実際の効果(How Pair Programming Really Works)」と題する記事を書いた。
その記事で氏は、まず、さまざまなペアリングのアプローチ(熟練者と初心者、ドライバとナビゲータ)について次のようにまとめている。
開発者としての私個人の経験から、ペア・プログラミングの使用は、一方がプログラムをし、他方が見ているというだけのテクニックではありません。両方のプログラマは、常に話し合いをし、残りのやるべきことを手早くメモし、また、画面上で数々のコードを指摘しながら密接に連携して作業します(ペア・プログラミングの常套句の一つに、「すぐに実行すれば、今日中に、画面は脂で汚れた指紋でいっぱいになるはずだ」というものがあります)。プログラマは交代でキーボードを使用し、「いいえ、私が言いたいことをお見せします。」などの発言により通常入れ替わります。
同氏は、効果的なペア・プログラミングの説明に基づいて(また、ペア・プログラミングの実践がすべて効果的であるとは限らないということを明確にして)、効果的なペア・プログラミングを成功に導く4つのメカニズムを提示している。
メカニズム1: ペア・プログラマの会話
Brian Kernighan氏とRob Pike氏は、(たとえ、ぬいぐるみに向かってでも)問題を声に出して説明することを勧めています。これはJohn Sturdy氏がゴムの木の効能(the rubber-plant effect)と称するプラクティスです。おそらく、ペア・プログラミングの有効性の一部として、ある効果が継続的に誘発されていることが挙げられます。その効果とは、片方のプログラマが手詰まりになったときに、会話のやりとりによって、単独のプログラマが問題を声に出して話すのと同様、そのプログラマを手詰まりの状態から引き離せることです。
氏は、会話がもたらすさらなるメリットについて説明している。これは、同氏が「熟練プログラマの理論(expert programmer theory)」と称するものが適用できる状況、つまり、ペアのメンバ間で、知識の豊富な問題であれば、より効率的に解決できると考えられている状況で発生する。
熟練プログラマの理論による実際の効果とは、おそらく次のとおりです。熟練者というものは奥深い質問をすることが多々あり、それにより手詰まりのプログラマには新しい推論が生じます。さらに熟練者(または、そのように装っている人)と話をしていると考えるだけで、手詰まりのプログラマは熟練者が過去にしたことのある一種の奥深い質問のようなものを提示できるようになるようです。
会話における価値を要約して、氏は次のように述べている。
したがって、この最初のメカニズムでは、プログラムについて会話をするプログラマほど、より生産的になり、また、時折、奥深い質問を相互に投げかけることは、何よりも生産的になると予測できます。
メカニズム2: ペア・プログラマは詳細事項に気付きやすい
「人は、自分自身の間違いに気付かない」とは、ソフトウェア開発(および、その他多くの分野)における自明の理である。
Wray氏はこのことを、変化の見落としおよび不注意による見落としの理論に関連付けている。
われわれが気付くことは、予期することや無意識に顕著だと判断することに左右されます。このため、良好なペア・プログラマは、たいてい同じことに注目しますが、さまざまなことに気付く可能性もあります。
このため、共にプログラミングをする2人は、同じ予備知識やカテゴリを持ちません。おそらく、一方があることに早く気付き、もう一方は別のことに早く気付きます。彼らが単に見るだけで見つけられることの割合で、作業効率が決まるのであれば、1人より2人で考えた方が名案が浮かぶはずです。また、実際、ペア・プログラミングを開始して、最も初期に見られることの一つとして、コードをタイピングしていない人の方が、「あれ、ここのカンマが抜けていますよ。」などと、常に迅速にタイプミスを見つけている点が報告されています。
氏は続けて、ペアの倦怠感に関する現象について、次のように警告している。2人のプログラマがペアを組む場合、彼らが気付くことと見落とすことは、次第に似てくる。その結果、2組の視点から得られるメリットは、ごくわずかになる。
ペアの倦怠感は、ペアの定期的なローテーションへのきっかけとなります。
ペア・プログラマの中には、ローテーションをプラクティスにおけるオプション的な要素とみなす者もいます。さらに、小規模なチーム、またはペアを組むことに前向きなプログラマがほとんどいない場合、選択肢がほとんどない場合もあります。ただし、ペアの倦怠感は、最終的にそれほど生産性が上がらないことを意味します。
メカニズム3: 悪質なプラクティスへの抑制
仲間からのプレッシャーが、悪質なプラクティスへの抑制になることは、効果的なペア・プログラミングのメリットとして明確に認識されている。
氏は、「作ってから直す」プログラミングの例について説明し、それをスロット・マシンのギャンブルにおける常習性に関連付けている。
これは、対話的なプログラミングに特有の性質であり、これにより、適切な行動をとることが困難になります。作ってから直す場合、プログラムを場当たり的にいじり回すものですが、これは事実上、コードを実行するたびに、スロット・マシンにコインを入れていることになります。スロット・マシンは、最も常習性の高いギャンブルの形態として知られており、作ってから直すプログラミングからの報酬も同様に予測不可能であるため、同様の常習性が考えられることを意味しています。
ペア・プログラマは、特定の方法でコードを書くように約束することができ、互いの約束は必ず守るようにするため、悪質なプラクティスの影響を受けにくいと考えられます。人間の可謬性が深刻な問題となるような作業に2人で取り組むことが普及すれば、われわれは、ペアの圧力も解決策になると真剣に考えるようになるはずです。
メカニズム4: 専門知識の共有と判断
個人間における生産性の違いは多大なものであり、少なくとも10倍はあるとされている。これは、難易度と時間の見積もりが正確性に欠けることが多いことを意味している。これは、優秀なプログラマと未熟なプログラマの両者に当てはまるが、誰かのプログラミング能力を判断するには、彼らと密接に関わって作業するよりほかにない。
ほとんどのプログラマは、1人で問題に取り組みます。このため、彼らがどの程度優秀(または未熟)なのか誰もわかりません。しかし、ペア・プログラミングの場合、メンバは常に一緒に作業をします。ペアを交換し続けることで、特定のことに対して誰が最も専門的であるか、チーム全員が把握するようになります。この比較により、彼らは自らの専門性のレベルも認識します。このため、ペア・プログラミングのチームによる時間と難易度の見積もりは、単独でのプログラミングのチームによるものよりは、正確性が増すことを期待できるはずです。私の経験上から言うと、このことは実に当てはまるように思えます。
あなたの環境で、ペア・プログラミングを効果的にする方法やメカニズムには、どのようなものがありますか？
InfoQのペア・プログラミングに関するこの他のコンテンツはこちらにあります。