コンサルタントとしての3年半で、私は他のいかなるテーマよりもペア・プログラミングについて、時間をかけて（顧客と）話してきました。通常、クライアントの開発者は、適切なペア・プログラミングの経験がない、あるいは、それを望まない人たちでした。さらに悪いことに、大半の企業では、2人の開発者で1台のマシンを使用するのは無駄なことだと考えていました。
このような先入観にもかかわらず、たいていわれわれが顧客のもとを去る頃には、企業や開発者たちはペア・プログラミングの支持者になります。
ペア・プログラミングの採用を成功させることは困難な場合がありますが、私が習得してきた教訓を活用すればそれも十分可能です。
本稿は、これまでにペア・プログラミングの経験が多少あり、合理的なペア・プログラミングの採用に向けて組織の協力を求めている読者を前提としています。このアドバイスは様々な役割の人に有効ですが、主にペア・プログラミングをチームに導入しようとする開発者やチーム・リーダに向けて書かれています。
本稿は、ペア形成をすべきか否かを問うためのものではありません。ペア・プログラミングにも（大半のものと同様に）プラスとマイナスの面があります。また、このテーマを扱うために利用できる適切な知識はすでにあるものと考えています。ペア・プログラミングの賛否を議論することは、本稿の目的からは外れることになります。したがって、すでにペア・プログラミングの価値を認めているのであれば、どうすればうまくチームに取り入れられるのか、について取り上げます。
ペア用のステーション
経験上、ペア・プログラミングの採用を成功させる上で唯一最大のステップは、適切なペア用ステーションを用意することです。以下で記述するようなペア用の構成を推奨しますが、状況に応じてカスタマイズする必要があるでしょう。
- 両者が並んで快適に座れるような平らな机。Nat Pryce氏は円卓の使用でも成功しています。通常、作業者の方へカーブする机は快適な作業条件を実現できないため、避けるべきです。
- 手ごろに購入できる最速な開発用マシン。ペア用のステーションが個々のマシンより優れているならば、使用する機会も増えます。また、2人につき1台を購入しさえすればよいため、より多くの費用をかけることができます。
- デュアルDVI出力付きビデオ・カード。スプリッタも正常に機能しますが、十分ではありません。最大の解像度を得るには、デュアルDVI出力を使用するほうがより適しています。
- 24インチまたは30インチのモニタを2台。2台の大型モニタはデスクトップのクローニング（または、ミラーリング）に優れています。この結果（2台のキーボードと2つのマウスを組み合わせた場合）各ペア・メンバは自身のワークステーションを使用しているような感覚が得られます。
- 2台のキーボードと2つのマウス。両方を望む者が使用できるように2つとも用意しますが、中には1台のキーボードや1つのマウスを好むチーム・メンバもいる可能性があることも覚えておいてください。
理想的をいえば、よりよい作業環境（少なくとも、自身のマシンで作業するのと同様に快適である）を作ることがねらいです。
メンバに自身の席（およびヘッドフォン）を離れてもらうのは困難なことです。しかし、席を離れて最適とはいえない環境で作業するよう依頼するなどまさしく愚かなことです。それよりはむしろ、彼らが個人のデスクトップよりも気に入るような魅力的なペア用ステーションを作り出してください。
優れたペア用ステーションを用意することは、大きな一歩ですが、ペア用ステーションを適切にセットアップすることもまた重要です。過去に、ペア用ステーションのイメージを作り出し、それを利用して他のペア用ステーションをすべてセットアップし最も大きな成功を収めたことがあります。週単位でペア用ステーションの再イメージをするのもよいでしょう。開発者は、必要な時に新しいツールやエイリアスをペア用ステーションに追加することがよくありますが、そのツールやエイリアスは、チームの残りのメンバが使用する他のペア用ステーションではうまく行きません。定期的にステーションを再イメージすることは、個々のペア用ステーション1つずつではなく、チーム・メンバにイメージの更新を要求することがわかりました。
イメージの作用はチームにより大きく異なります。理論的上、チームに編集やデスクトップ・レイアウトなどの同意を依頼する場合、混乱が予想されるかもしれません。実際、自身の給料に値するチーム・メンバであれば誰でも、最適なツールで作業に取り組みたいと考えています。時に、最適さは主観的な場合もありますが、通常、優れたツールになります。完勝者がいない場合、一般に、基準を設定し進めることは容易です。それは非常に満足のいく結果が得られます。つまり、それは最適なツールを用いたイメージであり、あらゆるペア用ステーションで、各チーム・メンバの効率がきわめてよくなることを約束します。
始めから正確なイメージを得ることを期待してはいけません。もちろん、それでも構いませんが、イメージの作成とは、チームが継続的に改善していくべき反復プロセスになります。
私は、共同の場所やペア用のスペースを設けることで大いに成功を収めてきました。ほとんどの人が会議室を持っており、20%の効率向上が見込める場合は進んで明け渡します（ペア形成とコロケーションでは、20%の効率向上を得ることはきわめて容易です）。DRW（私の現在の雇用主）では、チームの作業部屋を取り壊し、机を直線に並べました。われわれは、「個人的な」スペースをやめ、ペア・プログラミング用のエリアを作りました。一人で作業をしたい場合は、いつでも、ノート・パソコンを持って会議室に行くことができます。
適切なペア用ステーションがなければ、仮に本稿の他のアドバイスにすべて従ったとしても、必ず失敗するでしょう。とはいえ、本稿のレビューアの中には、私の意見とは異なる方もいることでしょう。われわれが同意すべき点は、ペア・プログラミングを採用する上で、最も重要なのは想定しうるあらゆる障害を取り除くことだということです。経験上、最も大きな障害は、作業者に快適な作業スペースを与えることです。しかし、私のレビューアが指摘するように、例外なく適用できるルールなどありません。
一度に一人のメンバに注目する
私は、誰か他の人にペア・プログラミングを強制しようとは思いません。ペア・プログラミングを好む人もいれば、そうではない人もいます。しかし、チーム・メンバにペア形成の試行を強制して親しくなろうとは思わないでしょう。
私は、基本的なアプローチを用いて非常に多くの成功を収めてきました。通常、ほぼ例外なく、確信はしていないもののこのアイデアを受け入れているメンバをペアにすることから始めます。彼らもまた、一人で作業するよりペアでの作業を好むようになるまでに長い時間を要しません。この時点で、このアイデアに賛成している別のメンバに移ることができます。私は常に最も簡単なところから試し、次にペア・プログラミングに対して最も閉鎖的なメンバへと取り組んでいます。
少なからず、ペア形成に最も賛成を示していないメンバに取り掛かるようなことには決してなりません。私が彼らに対応する前に、通常、次の2つのどちらかが起こることになります。
- 彼らはチームの残りのメンバが著しく早く作業を行っていることに気付き、彼らもペア・プログラミングに参加できるか尋ねます。
- 彼らはチームの残りのメンバが著しく早く作業を行っていることに気付き、最終的にチームを離れていきます。チームに協力しない者ほどパフォーマンスが思わしくないのは全員に明らかです。通常、これらのメンバはその兆候を感じ取り去って行きます。
経験上、つなぎとめておきたい社員のうち90%は、結果的にペア形成を好むようになります。しかし、ペア形成に閉鎖的なメンバを失うことがプロジェクトや会社にどれほどの影響を与えるか考慮する価値は確実にあります。これらのチーム・メンバを脅威やプレッシャーを感じない役割に移すほうがよい場合や、チームから去ってもらうほうが賢明な場合もあります。
明確にすると、ペア・プログラミングの価値を認めてはいないものの優れた開発者は数多くいます。私は決まって次のように主張します。それは彼らの大半は適切なペア・プログラミングの経験がない可能性が高いためであると。しかし、適切にペア・プログラミングを行ったあとでさえ、単独でのコーディングを好む者が多くを占める場合もありえます。私はこれらのメンバは、主にペア・プログラミングを好むメンバで構成されたチームには向いていないだけであって、有能であると分類する傾向にあります。ペア・プログラミングを好むことは才能の指標ではありません。同様に、ペア・プログラミングを好まないからといって才能が欠けているというわけではありません。
長期的に、1つのチーム内でペア形成に反対意見を持つことは間違いだと考えます。経験上、両者が反対意見のようなものを感じると非常に効率が悪くなります。さもなければ、結果として、合理的かつ好意的なチーム・メンバは継続的にこの話題について討議し、議論と責任の所在を明確にすることに非常に多くの時間を費やします。両者の意見を合わせるための余地は必ずあるでしょう。採用を成功させる一環として、決して同意を示さない人を認識し、達成不可能な目標で時間を無駄にしないことです。
ペアの交換
ペア・プログラミングを受け入れてはいるもののまだ確信を持っていないメンバと作業をしているなら、そのようなメンバと頻繁に、もしくは常にペアを組むことは合理的です。ペア・セッションの始めの数回は、ほとんどの場合は調整期間であり、メンバにできる限り最適な環境を提供することが大切です。しかしペア・プログラミングの実験段階からそれを享受する段階へと移行するメンバがいたなら、別のチーム・メンバとペアを組み始めることが適している場合も多くあります。経験上、ペアを組む期間は最低1日、最高でも2日が最適です。このガイドラインは状況により左右されます。しかし、これまでのところは、ほぼ一定しています。
1人のチーム・メンバとペアを組むのに最も効果的な期間については、意見が対立しています。前述したとおり、通常、少なくとも1日は1つのペアに費やしますが、決して2日を超えることはありません。他の推奨する見解として、イテレーションごとに一度のペア交換や様々なペアを検討することです。いずれも極端であるとは思いますが、このアイデアが適するような状況もあると認識しています。頻繁にペアを交換することで、少なくとも2つの大きなメリットが得られます。
- メンバが持つツール（たとえば、grepやIDE）、ドメイン、パターン、テストなどに対する専門知識の度合いは異なります。現行機能の実装に必要な分野の専門家であれば誰でも、ともに作業をすることは合理的です。
- 異なるチーム・メンバと作業することで、学習者あるいはメンターとして費やす時間のバランスがいっそう取りやすくなります。
ペアの交換によるメリットは、より優れた効率を導き、さらにはペア・プログラミング採用の成功にもつながります。
誰がドライバをすべきか
ペア・プログラミングに不慣れなメンバは常に次のように尋ねます。結局両者とも同時にタイピングをすることになるのではないですか？簡単に言ってしまえば、答えは「ノー」です。もしこれまでに、誰かのタイピングの量があまりにも少なすぎたり多すぎたりといった問題があったのであれば、ピンポン・ペア・プログラミングによって容易に対応できます。
ピンポン・ペア・プログラミング（または、ピンポン・ペアリング）では、2人が交代でテストと実装を記述します。さらに冗長な名前のピンポン・ペア・テスト駆動開発は、おそらく、いっそう有効ですが、予想以上に扱いが難しいでしょう。ペアが行うワークフローは以下のようになります。
- ペア開発者1は失敗するテストを記述します。
- ペア開発者2は必要なものだけを実装しテストを通します。
- ペア開発者2は失敗するテストを記述します。
- ペア開発者1は必要なものだけを実装しテストを通します。
- 手順1に戻ります。ペア・セッション全体を通して、このループに従います。
ペア形成を導入する場合、ピンポン・ペアリングは非常に効果的です。しかし、最初の数日を過ぎて、「誰がタイピングをすべきか」は、多くの場合、ペアの各メンバがどの役割を果たしているかで決まることに気付きます。
メンター役のペア
ほぼすべてのタスクを考えてみても、1組のペアは通常、一方のメンバのほうがもう一方のメンバより、当面の問題についてよく知っているものです。この場合、一般に、よく知らないペア・メンバがドライビングをするほうがうまくいきます。メンターは、「この機能を実現させるためにすることがある」という考え方から「どのようにして自分のペアをこの問題に対する的確なソリューションへと導くことができるのか」という考え方へ切り替える必要があります。メンターの役割を果たすときに、機能の実装者である代わりに、指導者であることのほうがはるかに重要です。次のことわざをご存知でしょう。人に魚を与えれば、その人は一日生き延びられる。魚の捕り方を教えれば一生生きていける。
注意：学習期間、採用期間、および定常状態のペア形成における役割は有効であることがわかりました。ペア・プログラミングの学習や採用を行う場合、自分がメンターであり、ナレッジを効果的に伝えていると認識することで、多大な自信やペア・メンバとの信頼を築くことができます。定常状態でのペア形成期間中は、メンター役を務めることで、機能の完全性へと前進すると同時にナレッジを伝えることもできます。
メンター役を務める場合、より大きな状況や現在の進路について熟考するのは良い機会です。当面の問題を解決するのによりシンプルな方法を思いつくかもしれません。問題を解決するもっと効果的な方法を図らずも思いついたならば、通常、自分のペアに最初のアプローチ（必要に応じて時間を区切って）を用いて教えるのはやめて、次にすばやく他のアイデアを停止します。それがより優れていると判明したなら、なぜ入れ替えたのか自分のペアに理解してもらうようにします。もしそれが劣っていると判明したなら、これまでのソリューションに容易に戻すことができます。
学習者役のペア
メンターがいるのであれば、もう一方のメンバは学習者ということになります。学習者として、行うタスクは１つのみです。ペア用ステーションの指揮を取り、問題について理解するまで話し合います。そして、最も明白なソリューションを実践します。そのソリューションが適切であれば、メンターは必要な指導をすべて提供できるはずです。ソリューションに遜色がある場合は、メンターが提案されたソリューションに欠けている点を明確にし、そのソリューションを改善する方法を指導するのは容易なはずです。
メンターあるいは学習者という分類は、長期間にわたるものではありません。この記述は、現行の取り組みへの適用に限られていると考えます。私がRubyとRailsの専門家で、私のペアがSQLとJavascriptの専門家という場合があるかもしれません。1つの機能を実装している間、メンターと学習者の役割を両者で何度か交代することもあるでしょう。大切なことは、交代するタイミングと交代に基づいたタイピング・メンバの調整を認識することです。
A原則として、学習者はドライビングの大部分を行うべきです。
関心を示さないペアや注意散漫なペア
自分のペアが現行のタスクに興味を示さない場合があります。いずれのメンバにとっても、興味を示さないペアと作業をするのは決して楽しいことではありません。ペア・プログラミングのメリットは、2人の開発者が協力して最適なソリューションを得ることです。明らかに、無関心な開発者は、協力しているとはいえません。こうして、低品質なソリューションになるおそれがあります。少なくとも、そのソリューションはこれまでとは何ら変わらず、1人のメンバの時間は完全に無駄となります。
ペアが興味を持つ事ができない理由はいくつかある。しかしながら、ペアが無関心な理由を記述することは、一般的な方法では合理的な回答ができない人間的な問題です。
注意散漫なペアとは、その名前が示すように、周囲の環境に気を取られがちなペアを指します。注意散漫なペアは、周囲の人すべてを手伝うことに余念がないため、タイピングにかける時間がより少ない傾向にあります。注意散漫なペアは無用というわけではありません。実際には、通常、彼らはペアが取り組んでいるコードに大きく貢献します。しかし、注意散漫なペアは、同時に複数のペアの問題を解決しようとすることが多いため、最大限の潜在能力を提供することはめったにありません。注意散漫なペアの中には、メールのチェックや他の補助的タスクを行う時間が多すぎる場合もあります。
Joel Spolsky氏は、オープンスペースの作業場所は楽しいが生産的ではないと考えています。私は氏の意見に賛成しないわけではありませんが、いかに少数の注意散漫なペアにより、管理者がそのような結論を出しやすいかは理解できます。
私が注意散漫なペアであったこともあります。また、いくつか注意散漫なペアと作業したこともあります。これは折に触れて、われわれすべてに起こり得ることなのです。過去に、ルールの作成により管理された注意散漫なペアを見たことがあります。たとえば、以前のプロジェクトには「個人的なノート・パソコンを開発ルームに持ち込んではいけない」というルールがありました。このルールは問題の解決に有効ですが、他の問題を引き起こします。
関心を示さないペアや注意散漫なペアにおける最大の問題点は、彼らが本格的にペア・プログラミングに参加していないということです。それゆえ、いくつもの生産性向上が打ち消されてしまいます。関心を示さないペアや注意散漫なペアに手こずるような場合、有効なことがいくつかあります。
注意散漫なペアの対応として推奨する方法は、ピンポン・ペアリングの実践です。ピンポン・ペアリングはペアの両者にレベル1の注意を余儀なくさせます。この提案の別の優れた特性に、ルールを追加し副作用のある問題を起こすような必要性が一つもない点があげられます。ピンポン・ペア・プログラミングは関心を示さないペアを貢献的なペアに変えるのに有効です。しかし、時に、貢献のレベルは彼らの全潜在能力にまで及ばない場合もあります。関心を示さないペアに対応する場合、実際は混乱を装うことがより有効であるということがわかりました。
混乱を装うことは、実に退屈なことです。通常は、やるべきことを理解しています。少なからず、頭の中にはソリューションがあるものです。このソリューションを独自に実践し関心を示さないペアを付き合いで参加させることができます。経験上、残念ながらそれはまさに発生することなのです。しかし、単に関心を示さないペアを付き合いで参加させることは最適な長期的ソリューションとはいえません。そのうちそのペアは、既存のソリューションを改善するよう求められるかもしれません。注意していなかったために、改善ができない場合、自身のタスクから離される可能性があります。さらに悪いことに、チームを離れ、コードのコンテキストが永遠に失われるおそれもあります。
したがって、混乱を装うのは退屈なことなのですが、チームの得策でもあります。ソリューションを実践する代わりに、自身のペアに「どのようにしてこれを終わらせるつもりか」を尋ねます。最初の答えを受け入れてはいけません。彼らは最初の答えを早く出そうとしがちですが、非常に厄介です。自己投入量を与えますが、ソリューションがあることを明かしてはいけません。代わりに、質問を押し通します。おそらく、彼らはソリューションを理解するでしょう。彼らのソリューションを理解しても、理解していない振りをしても構いません。関心を示さないペアに最初の3つのテストを記述させ、そのテストが通るようなコードを実装させます。この時、作業を引き継いでテストを記述しますが、ソリューションの実践は彼らにさせます。続いて、徐々にピンポン・ペア・プログラミングに取り掛かりますが、積極的にアピールしてはいけません。代わりに、関心を示さないペアにコーディングの65%をさせます。関心を示さないペアが全面的に貢献するペアになるまでそう長くはかからないはずです。また、これは全員にとってプラスになります。
スペルチェックを行うペア
才能の大きな格差により、チームメイトが転じるものといえばスペルチェッカー以上の何ものでもありません。これは何年にもわたり、幾度となく見てきたことですが、最近私の身にも起こりました。新規ジョブを引き受け、作業2日目に、社内で最も上位のメンバとペアを組みJavaでライブラリ実装をすることになりました。そのライブラリは彼が以前.NETで書いたものでした。私はその分野には不慣れでした。実際、それまでJavaでの本格的な経験はありませんでした。.NETバージョンのライブラリを見たこともなく、ライブラリと連携するようなメッセージング・システムを使用したこともありませんでした。また、Java用のIntelliJを使用したこともないなど、いろいろとありました。
私のペアにとって、私は役立たずでした。そのタスクには、少々時間的な制約があり、私たちの情報格差があまりにも大きかったため、スペルミスを指摘する時以外は黙る羽目になりました。多少ドライバも務めましたが、その時は、タイプすべきものを私のペアが教えてくれました。
通常、私はペアを好みますが、スペリングを指摘する以上のことをチームメイトが与えてくれないのであれば、それは彼の時間を有効に利用していないことになるでしょう。さらに、経験豊かなチームメイトがペースダウンするのに必要とされる場合、知識の格差が埋められれば、これは通常、最も効果的な行動方針になります。一方、知識の格差が大きすぎて合理的に埋められず、うまく伝えられない場合、そのペアは離れるべきです。
ペアを使用しない場合
一方のペア・メンバがスペルチェッカーになるような場合を含め、ペアを使用しないほうがよい状況がいくつあります。独自に取り組むほうがより合理的な他の一般的な状況には以下のものがあります。
- あとで役立つ可能性のあるライブラリについて読んでいる場合。
- 複雑なソリューションをやめる場合や知識の格差があるメンバと厄介なエラーのデバッグをする場合。通常、ペア形成は調査および知識の格差を埋めることの併用には理想的に適しているとはいえません。
これらの状況は、ペア・プログラミングにとって最適な機会とはいえないということを覚えておくことは重要なことです。それを行っている間、決してペアになるべきではないということではありませんが、仮にこれらの取り組みをペアで行った場合、一方のペア・メンバは関心を示さないか、あるいは有効性を提供できない可能性があります。ペア・プログラミングの採用を遅らせる手っ取り早い方法の一つは、有効性の提供を阻止するような不利な立場にメンバを置くことです。
すべてのタスクにペアが必要となるわけではありませんが、ペア形成を必要とするタスクの数は、そうでないタスクの数をはるかに上回っています。
本稿のレビュー時に、Dan North氏は次のことを指摘しました。おそらく、タスクの数ではなく、タスクの種類です。伝達の中心的ないかなる開発の取り組み（コードの記述、テストの記述、技術の確立）も、ペアで行われた場合、より優れた品質になる傾向があります。取り止め、調査、管理用の雑務など、中心的ではないタスクに関しては、効果が減少していきます。このため、ペアで行わないほうが適切な場合が多くあります。
ペア形成のコアタイム
概して、ペア形成が現在の問題に最適でないと判断する場合、即座にペアを離したほうがよいでしょう。私はこれまで、一日のうちペアに利用可能な時間を定義することで多くの成功を収めてきました。通常、ペア形成のコアタイムは、一日の全作業のうち60%から70%になります。たとえば、勤務時間が午前8時から午後5時までであれば、ペア形成のコアタイムは午前10時から午後4時にということになるかもしれません。
ペア形成のコアタイム中、ペアになるよう義務付けられることではありません（決してペアになることを「義務付けられる」べきではありません）。しかし、ペアを利用できる状態でなければなりません。仮に一人で行うことに適した作業を行っていた場合、ペアにはなれません。しかし、現在ペアにはなっておらず、ペアでの作業に適した作業を行っているのであれば、ペアを探すか、他のペアでの作業に適した作業を行っている誰かとペアが組めるようにするべきです。ペア形成のコアタイムが終わるまで、一人での作業を（可能であれば）後回しにするのも有効です。たとえば、優先度が中位のバグが午後2時に割り当てられ、自分のペアがそのバグのあるライブラリについて何も知らないような場合、おそらく、バグの調査を午後4時まで待った方が合理的でしょう
勤務時間に多少の柔軟性が与えられる点でも、ペア形成のコアタイムは優れています。
ペア形成に対する最も強力な異議申し立ては、「各自の時間が必要」なメンバや、「一日8時間のペアが可能」でないメンバです。この異議は私には常に奇妙に映ります。一日8時間のペア時間が必要である人がいるとは思えませんし、誰でも各自の時間を取る権利があるからです。私は自分の時間の70%をペア形成の時間に優先していることに気付きました。仲間の中には、60%を好む者をいますし、95%という者もいます。誰のやり方が正しいのかはよくわかりませんが、いずれにせよ、100%を推奨する者はいません。特に採用段階では、ペアが有効だと考える時にペアになり、そうでないと判断した時には離れることは非常に重要です。
可能な限り簡単に
可能な限り簡単なことを行うというフレーズは、大半のアジャイル開発者が心に抱いていますが、これは従うのが常に容易なアドバイスというわけではありません。あまりにも簡単なことをする場合、短絡的だと非難されるおそれがあります。一方、過度に複雑なことを行った場合、自身の時間やそのソリューションのメンテナンスが必要となる人の時間を無駄にしていると非難されるでしょう。しかし、ペア・プログラミングは、そのソリューションは簡単であるにもかかわらず、機能するだけの堅牢性があるという信頼を得るのに役立ちます。
ペア形成を行う時、可能な限り簡単なことに忠実であるよう決意します。ペア形成を行っている場合、おそらく、平均的な利用に耐えられるような簡潔なソリューションを賢明に作り出していることでしょう。よりシンプルなソリューションに忠実であることで、すばやく機能を作り出し、より短時間で既存の機能をメンテナンスできるはずです。この効率性の上昇は、ペア・プログラミングが有効なアイデアであることを理解してもらうのに役立つはずです。
コード・レビューの要求
コードの品質を高めたいのであれば、チーム・メンバにレビューしてもらう必要があります。実際、一部の法律（SOX、HIPPA）では、すべての製品コードにレビューが必要となるものもあります。とはいえ、ペア･プログラミングの導入を試みるのであれば、ペア・プログラミングを要求することにより、間違いなく破綻すると認識できるぐらい賢明であれば、代わりにコード・レビューを（すべての製品コードに）要求してもよいのではないでしょうか。コード・レビューの要件を満たすには、従来のコード・レビューまたはペア形成が可能です。ペア形成とコード・レビューにおける主な違いは、一方は批評であり所有者と防御の意味が含まれるのに対し、もう一方は協力的である点です。コードのレビューをしてもらうということは、ほとんどの場合、痛みを伴うプロセスであり、通常、代わりにメンバがペア形成を選択するまでに長くはかかりません。
何かを要求するということは、常に危険な賭けであり、このアイデアは最後の手段として使用したいものです。
結論
ペアを「許可」されることは成功ではありません。チームがペア形成の利益を享受し、それによりさらに生産性が高まった時に成功は得られます。この観点から採用に臨むのであれば、より多くの成功の機会が得られるでしょう。そして、上記のアイデアを適用する場合は、チーム・ビルディングと効率性に注目する方法で取り入れてみてください。