ペアプログラミングを実践する技術系企業が増えていることに注目し始めた Wall Street Journal が，自らの見解を Computer Programmers Learn Tough Lesson in Sharing (共有を通じて厳しい教訓を学ぶコンピュータプログラマたち) という記事に発表した。
Facebook やモバイル決済の新興企業 Square など，技術系企業の間でペアプログラミングが人気です。その信奉者は，カップルによる効果を賞賛のことばで語ります。ペアコーダはコストの高いソフトウェアエラーを捕まえることができる，Web サーフィンのような時間の浪費もない，というように。
しかし実践してみれば，すぐに問題に突き当たる。デートするのとは訳が違うのだ。
現実はむしろ，最悪のブラインドデート以下かも知れません。やっかいな問題があっという間に山と積み上がり，パートナーを悩ませるのです – 不潔だったり，テーブルマナーが悪かったり，さらには共有デスクに足を乗せたり，食事の音がうるさかったり。
３月に技術大手の EMC によって買収された Pivotal Labs というソフトウェア開発会社では，175 名の技術者全員が毎日ペアを組んでいます。中には，毎日パートナーを代える "無差別ペアリング" というプラクティスを実践している，浮気性の人もいます。
さらにデートの比喩が続く。
ペアリングのパートナとの問題を解決するということと，特別な人との問題を解決することには，共通点がたくさんあります。
"どんな関係でも同じです" と Kite さんは言います。"話し合わなければ，問題は解決しません。"
記事の最後に紹介されているのは，Drive Current 社のペアプログラミングに関する体験談である。
当社では技術者に対して，１日３時間のペアリングを実施するように指導してきました。そして２年後の９月に，Kocol 氏がそのプラクティスを段階的に廃止したのです。
St. John 氏は，"特に残念に思っている人はいなかったようです。" と言っていました。
ペアリングに関する自らの意見と経験を書いたコメントで，何人かの開発者がこの議論に参加した。Anne Bennet 氏は 次のような意見だ。
とんでもない話です。私たちのマネージャでそれを話題にしていた人がいたのですが，幸いなことに他へ移動しました。よかった，もうちょっとで退職したくなるところだったのです。他人にコードをレビューしてもらうのならともかく，一緒に書くってどうなんでしょう？ 私はご免ですね。
Mike Edwards 氏はペアリングに対して，もう少し 肯定的な経験 をしている。
私の経験から言うと，長く放置されて荒廃したコードベースを引き継いで，その真っ只中で作業しなければならないような人には，ペアプログラミングが役に立ちます。立ち会ってくれている人がいれば，何とか我慢もできるというものです。
Christopher Wong 氏は，その人の性格によって向き不向きがある という考えだ。
ペアプログラミングというのは始終，ミーティングにどっぷり浸かっているようなものだと思います。とても疲れますし，へとへとになってしまいます。ところがこの方法で，逆に元気が出る人たちがいるのです。どうやら個人の性格の問題らしいので，実践する人の裁量に任せたほうがよいでしょう。
Catherine Jefferson 氏はそのメリットを認めてはいるものの，自分に向いているという確信は持てなかった。
冷静になって考えてみれば，ペアプログラミング向きの人々やプログラミングのタイプについて想像することは可能でしょう。しかし，もし私が，少しでもこれに似たようなことをするように期待されたなら，１日と持たずに疲れ果ててしまうと思います。ぞっとしますね。
Thomas Gordon 氏は 一時的なブームだと考えている。
おや，面白い。流行りのプログラミングですね。最近スクラムが心配になってきたところだったのですが，頭痛の種がひとつ増えたようです。私個人としては，この共有デスク作業にはびっくりしています。プログラマならば普通は，自分のアイデアを本当に大事にしたいと思うはずです。問題を解決するときに，最初に思い付いたものと違う方法を実行しようと考える人がいるなんて，まったくもって驚きです。
Wall Street Journal の評価に同意できない人もいる。Mavenlink の共同創設者で CTO である Roger Neel 氏は，記事のペアリングに関する説明が公正でない，と考えるひとりだ。自身の見解を記した The WSJ Got it Wrong On Pair Programming (WSJ はペアプログラミングを誤解している) によれば，
私たちは早い段階で Ruby on Rails の採用を決定しました。そして上流工程の開発パートナ探しを始めたのです。その結果，見つけたのが Pivotal Labs です。プロジェクトの期間中 (Davis, Rajan, 元気かい！) は，Pivotal の一般的なアジャイルプラクティスである XP や テスト駆動，ペアリングに関して議論を重ねてきました。その頃の私たちにとっては，彼らのベストプラクティスを練習する上で，ペアリングは最高のやり方でした。その開発作業を３年間も続けた上，ペアプログラミング能力を基準とした人選で自身のチームを編成することになるとは，その時には思いも寄りませんでした。
WSJ が選んだ実例にも問題があると見ている。
ペアリングに向かない文化を持った企業と，ペアリングの嫌いな連中を例に挙げてくれたのはいいのですが，そうではない企業や，そこで働く人たちについてはどうなのでしょう？
氏はペアリングのメリットを挙げた上で，ペアリングとヨガの対比をして見せている。どちらも最初は奇妙に見えるが，ヨガはアクティビティとしてすでに人気を博している，と氏は説明している。
ペアリングはコラボレーションであり，よりよいコードを書くための方法であり，ティーチングであり，互いをチェックする場なのです。多少の練習を積めば，コラボレーションとアイデアのやりとりはずっと簡単にできるようになります。しかし Kent Beck 氏が言うように，すべての人たちがブツブツ言いながらコードを書くようになる訳ではありません。膝腱がまだ堅い間はヨガを止めないのと同じように，もう少し (あるいはもっとたくさん) 会話をする必要があるうちはペアリングを止めないことです。
ペアリングのメリットは他にもある。
ペアプログラミングとペアローテーションを毎日行えば，多数の会議を開く必要性を減らすためにも役立ちます。さらに多数の製品を持ち回りすることで，全員がビジネスの並行開発の経験を持つことになって，すべてのペアが日々の作業に関して自身の決定を行うことができるようになります。
ペアリングがすべての人のためではない点を認めつつも，氏はペアリングを，その他の一般的なプラクティスと比較する。
従来型モデルのひとつに，定期的なコードレビューを実施してお互いをコーチングしながら，ソフトウェアを分割して構築する，という方法があります。組織が完璧な規律を備えているならば，この方法はうまくいくでしょう。しかしすべての開発者が，１日８時間の作業で16時間分のコードを書かなければならいような状況が，現実には頻繁に発生します。そのような時には，他の人の問題は一番後回しになるものです。それに，基礎知識を持っているか，あるいは相当な時間を費やさない限り，他の誰かが何日も時間を費やしてきた問題を理解できるはずがありません。時間不足のレビューは往々にして，深い議論や改善を伴わない，うわべだけのリファクタリングに終わるものなのです。
アジャイル設計のテクニックを定期的なコミュニケーションやローテーションと結び付けることによって，ペアプログラミングは，反復的にコンセンサスを得るための優れた手法になります。これまでのように，作り始めたものを "カードを放り出す” ように放棄して，最初からやり直す必要がなくなるのです。
ペアリングに関して，どのような経験をお持ちだろうか？読者がこのプラクティスのファンならば，理解の低い人たちに対して，このアイデアをどのように説明しているだろう？
注： ペアプログラムの採用 について，我々が行った調査の結果を公表している。読者もこの 調査に参加してほしい。