ペアプロを極めて最強の開発チームをつくる（1/4）ペアの組み方（翻訳）

概要

原著者の許諾を得て翻訳・公開いたします。

英語記事: On Pair Programming
原文公開日: 2020/01/15
著者: Birgitta Böckeler — ドイツのThoughtWorks社で開発とコンサルティングを担当しています。カスタムソフトウェアチームのテックリードとして一日を「コーディング」「コーチング」「コンサルティング」「仕事を楽しく続けること」に分けています。
著者: Nina Siessegger — ドイツのハンブルグ出身の開発者/テックリード/コンサルタント。元ThoughtWorks。コーディングの楽しさ以外に、特にソフトウェア開発の人間的な側面にも強い関心を抱き、高品質ソフトウェアは「コミュニケーション」「共同作業」「信頼関係」を重んじるチームによって成し遂げられると強く信じています。
サイト: martinfowler.com

日本語タイトルは内容に即したものにしました。画像は元記事からの引用です。
原文が長いので記事を4つに分割し、章立ての階層を浅くしました。原文にない強調やリンクも必要に応じて追加してあります。

第1章: ペアの組み方（本記事）
第2章: ペアプロのメリット
第3章: ペアプロの難しい点
第4章: ペアプロは導入すべきなのか、第5章: それでもペアプロする理由

はじめに

ソフトウェア開発業界で現在働いている人の多くがペアプログラミング（以下ペアプロと略します）について耳にしているにもかかわらず、業界では未だにぼちぼち採用され始めている程度なのが現状です。ペアプロの普及状況がまちまちである理由のひとつは、ペアプロのメリットがすぐには明らかにならないためです。ペアプロの効果が目に見えるようになるまでには中〜長期を要します。しかも「1台のコンピュータに二人が張り付いて作業する」のは簡単ではないので、多くの人がペアプロ中に嫌気が差したあたりで放り出してしまいます。しかし私たちの経験では、チームでの共同作業や高品質のソフトウェア開発は「ペアプロなしでは実現不可能」です。

私は最初の時点からBetty Snyderとペアを組みました。最高のプログラムと設計はペアプロがあってこそ成立すると私は信じています。ペアプロすることによって、お互いに論評しあって相手の間違いを見つけ出し、ベストなアイデアに到達できるからです。
Jean Bartik（ほぼ最初期のプログラマー）

2人で1台のコンピュータを用いてすべての本番プログラムを書く作業。
Kent Beck: Extreme Programming Explained

Jean BartikはENIACの開発チームにいた女性で、最初期のプログラマーのひとりとみなされています。このチームがプログラミングを行っていたのは「プログラム」という言葉すらなかった時代であり、模範とすべきロールモデルもなければ、やり方を教えてくれる本もありませんでした。にもかかわらず、このチームはこの当時に「ペアを組んで仕事をするのがよい」という判断を下したのです。それから50余年を経た1990年代後半に、Ken Beckの『Extreme Programming』にペアプロという用語が登場し、広まりました。同書では「アジャイルソフトウェア開発」を多くの読者に紹介しましたが、ペアプロもその中のひとつに含まれていました。

ペアプロとは本質的に「2人が1台のコンピュータでコードを書く」ことを指します。ペアプロは非常に高い協調を求められる作業方法であり、コミュニケーションが多くを占めます。2人の開発者は1つのタスクを共同でこなしますが、コードを書くだけが作業ではありません。作業計画の立案や話し合いも作業に含まれます。その過程ではアイデアを2人で明確にし、よりよいソリューションを達成するためのアプローチについて2人で議論します。

本記事の第1章「ペアの組み方」では、ペアプログラミングのさまざまな実践的アプローチを概観します。この章は、ペアを組むことになった人や、上手なペアの組み方を知りたい人を対象にしています。

第2章「ペアプロのメリット」と第3章「ペアプロの難しい点」では、ペアプロで目指すべき目的と、ゴールにたどり着くときの障害とどう戦うかについて深堀りします。この2つの章は、ペアプロが自分の書くソフトウェアにもチームにとっても有用である理由を深く理解したい方や、ペアプロの質を高めるためのアイデアを探している方が対象です。

第4章「ペアプロは導入すべきなのか」と第5章「それでもペアプロする理由」では、チーム全体の作業フローや共同作業のスキームにペア作業を取り入れることについて、私たちの考察をまとめました。

第1章: ペアの組み方

どんなペアを組むか

ここでご紹介するペアプロの役割定義は、ある種のペアリングにおいてはもちろん、その他さまざまなペアリングアプローチにも適用できます。

「ドライバー」「ナビゲーター」スタイル

ドライバーはハンドルを握る（つまりキーボードを操作する）係です。ドライバーは、目の前の小さいゴールをクリアすることに集中し、もっと大きな課題についてはさしあたって無視します。ドライバーになった人は、作業中に「今自分はこれこれをやっている」と常に口に出すようにすべきです。

ドライバーが入力担当なら、ナビゲーター（ナビ）はお目付け役です。ナビはコードを絶えずレビューし続け、指示を出したり自分の考えを相手に伝えたりします。ナビ担当になった人は大きな課題やバグにも目を配り、想定される次のステップや障害物をメモします。

この役割分担方式は「同じコードを違う角度で見る」ところがポイントです。ドライバーはなるべく狭く戦術的に考え、目の前のコードの細かな部分について考えることが前提です。ナビはお目付け役として、なるべく広く戦略的に考えるようにします。ドライバーもナビも、それぞれ心のうちに「大きな絵（big picture）」を思い描きながら作業するようにします。

「ドライバー」「ナビゲーター」スタイルでよく使われる進め方

両者が十分納得のいくまで定義されたタスクをひとつ開始する
タスクごとに小ゴールを設定して両者で合意を取る。これは単体テストやコミットメッセージで定義してもいいし、定義を付箋にメモしてもいい。
定期的に役割を入れ替えて相手にキーボードを渡す。積極的な参加を共有することでモチベーションも高まり、学びや理解も進む。
ナビ担当になったら、細かな点にこだわる「戦術モード」で考えるのを避け、詳細をドライバーに任せること。ナビの仕事は「一歩身を引く」ことと「中長期的な視点で考える」ことでドライバーの戦術モードを補完すること。ナビは「次のステップ」「想定される障害」「アイデア」を付箋にメモして、ドライバーが小ゴールを完了したときに話し合い、ドライバーの作業が中断しないよう心がける。

「ピン」「ポン」スタイル

このスタイルにはテスト駆動開発（TDD）も包含されています。テスト駆動的に実装できるタスクが明確に定義済みであれば完璧です。

「ピン」: 担当Aはfailするテストを書く
「ポン」: 担当Bはテストがパスする実装を進める担当
担当Bは次の「ピン」を開始する（別のfailするテストを書く）
「ポン」の後に共同でリファクタリングを行ってから次のfailするテスト作成に進んでもよい。このようにして「Red」「Green」「リファクタリング」サイクルのアプローチに従う。つまりfailするテストを書き（Red）、最小限の方法でテストをパスさせ（Green）、それからリファクタリングする。

『99 Bottles of OOP』（Sandy Mets、Katrina Owen著）には「Red」「Green」「リファクタリング」ワークフローの素晴らしい例がいくつも掲載されています。

ストロングスタイル

ストロングスタイル（二人羽織スタイル）は、知識を伝授するときに特に有用な手法です。詳しくはLlewellyn Falcoの以下の記事をどうぞ。

参考: The way things work in Llewellyn’s world: Llewellyn’s strong-style pairing

ルール: 「自分の考えをコンピュータに入力するときは必ず相手に入力させなければならない」。このスタイルでは、そのセットアップやタスクに長けた経験豊富なベテランがナビを担当し、（言語やツールやコードベースの）初心者がドライバーを務めるのが普通です。ベテランはほとんどの時間をナビに専念して初心者を導きます。

このスタイルで重要なポイントは、「ドライバーはナビを全面的に信頼し、恐れず身を任せる」ことと、「ドライバーは自分の理解がさしあたって不十分でもよしとする」ことです。ドライバーが理由を質問したり問題解決に挑戦するのは、必ず実装セッションが終わってからにすること。ペアの一方がズブの素人であれば、ストロングスタイルの効果はさらに高まります。

ストロングスタイルはマイクロマネージメントすれすれですが、受け身の「見て学ぶ」方式よりも能動的な「身体で覚える」式の新人研修ツールとしても有用です。ストロングスタイルは初歩的な知識の伝授には有用ですが、やりすぎは禁物です。あくまで目的は「役割をすっと切り替えられるようにする」ことであり、マイクロマネージメントは早々に切り上げることをくれぐれもお忘れなく。マイクロマネージメントが終わったときが、知識の伝授がうまくいった合図です。

ペア開発スタイル

「ペア開発」はペアプロ特有の手法ということよりも、ペアプロにおける心がけ、つまりマインドセットの要素が多くを占めています（この言葉を最初に知ったのはSarah Meiの以下のツイートに続くスレッドでした）。ユーザーストーリーや機能を開発するうえでは、コーディング以外にもさまざまな作業が必要です。つまり、あらゆることにペアとして共同で責任を取らなければなりません。

Under pair development, as a pair, you're responsible for the development of a feature, which includes the programming & many other things.

— Sarah Mei (@sarahmei) June 22, 2017

何か新しい名前が必要だ。@wycatsも言ってたように、Tildeでやっている「ペア開発」がいいと思う。
「ペア開発」では機能の開発に2人で共同責任を持つ。プログラミング以外の多くにも共同で責任を持つ。

このマインドセットを身体に馴染ませるために、ペアプロで大きなメリットを得られる（コーディング以外の）ライフサイクルの例をいくつかご紹介します。

プランニング: 目標をはっきり定める

ペアを組んで仕事を開始するときには、いきなりコーディングを始めてはいけません。機能のライフサイクルの立ち上げ期は、無駄な作業を回避する絶好の機会です。初期段階では4つの目玉を駆使して問題を見つめ、思い違いや見落としをつぶしておくことで、後々時間を大きく節約できます。

問題を理解する: 2人がそれぞれストーリーに目を通し、理解した内容を順に復唱します。未解決の問題や思い違いの可能性がある箇所については、プロダクトオーナーにも同席してもらって解決します。自分のチームに「readyの定義」が確立しているのであればそれをチェックし、開始しても大丈夫な状態であることを確認しましょう。
解決方法を模索する: 問題に対してどんなソリューションがありそうかをブレインストーミングします。ブレインストーミングは2人共同でやっても、個別に行った後でアイデアを出し合っても構いません。この作業がうまくいくかどうかは、ソリューションとは何かがどの程度事前にきちんと定義されているかにかかっていますが、個々人の考え方のスタイルにも依存します。ひとりでしばらくじっと考えるのが好きな人もいれば、考え中の内容を声に出すのが好きな人もいます。ペアの一方がそのビジネスドメインや技術にあまり詳しくないのであれば、必要なコンテキストを共有するための時間をある程度確保しておきましょう。
自分のアプローチを計画に落とし込む: 「自分が選んだソリューションを達成するのにどんなステップが必要か」「頭に置いておくべきタスクには特定の順序はあるか」「テストはどうやって行うか」などを考えます。理想は、そうした手順を共有ドキュメントや付箋にメモしておくことです。これによって進捗を追えるようになりますし、タスクを他の人に手伝ってもらう必要が生じたときにも役立ちます。メモしておけば、その時点でわかっているToDoを後で思い出すのにも役に立ちます。メモしておかないと、翌日にはあっという間に忘れてしまうことを甘く考えてしまう人が多すぎます。

調査

不慣れな技術を用いて機能を実装しなければならない場合、最初の段階である程度の調査が必要です。「ドライバ」「ナビゲーター」スタイルや「ピン」「ポン」スタイルはこの作業に合いません。つまり、2人で同じ画面を見ながら共同でググっても、さほど効率は上がらないのが普通です。

ペア開発モードでのアプローチをひとつご紹介しましょう。

自分が答える必要がある疑問のリストを定義し、ふさわしいソリューションを思い付けるようにする。
手分けする: 今抱えている疑問のリストを2人で分け合うか、同じ疑問について2人がそれぞれ解を探ります。疑問を解くために、ネットを探すか社内の書籍や資料に当たってみます。あるいは、2人ともまだ慣れていない概念について調べます。
2人で事前に合意していたタイムボックスの締め切りになったら2人で集まり、お互いが見つけたものを共有します。

ドキュメント作成

コード以外で共同で行う作業として、ドキュメント作成があります。これまで行ってきた作業について必要なドキュメントが揃っているかどうかを2人で振り返ってみましょう。取り組んでいる問題や各人の好みに応じて、共同でドキュメントを作成しても構いませんし、一方がドキュメント作成を担当し、もう一方がレビューや推敲を担当しても構いません。

ドキュメント作成というタスクは、ペアの2人が互いに相手を訓練できるよい例です。ドキュメント作成は後回しにされがちで、しかもドキュメント作成が完了するまでは現在取り組んでいるストーリーを終わらせてすっきりした気持ちになれません。そしてたいていの場合、ドキュメント作成をすっ飛ばすか、やっつけ仕事で間に合わせることになりがちです。ドキュメントをペアで作成することで、面倒ではあるが価値の高いドキュメント作成という作業にある程度率直に向き合えるようになり、ひいてはいつの日か「ドキュメントを作成しておいてよかった」と大いに感謝したくなることでしょう。

タイムマネージメント

これまでご紹介した一般的なペアリングスタイルの他にも、作業を楽にしてくれる気の利いた小物ツールがいくつかあります。

ポモドーロテクニックもそうしたツールのひとつで、時間を小分けにして（25分にするのが通例）合間に休憩を挟むというタイムマネージメントの手法です。この手法は、上述のペア作業のほとんどすべてに適用して集中力を高めるのに利用できます。ペア作業は消耗するので、ポモドーロのリマインダーを合図に休憩を挟み、役割を定期的に切り替えるのに役立ちます。

ポモドーロテクニックを実践するとこういう感じになるという例をひとつご紹介しましょう。

次の作業を決定する。
タイマーを25分に設定する。ポモドーロのブラウザ拡張を使うのもよし、何なら台所に転がっているトマト型のキッチンタイマーを使うのもよし。
タイマーが鳴るまで中断せずに作業する。
タイマーが鳴ったら作業を止め、5〜10分ほど休憩を挟む。
ポモドーロを3〜4回繰り返したら、長めの休憩（15〜30分）を挟む。
小休憩では気持ちを切り替えて気力をためることを心がける。水やコーヒーを飲んだりトイレに行ったり、外の空気を吸いに行ったり。小休憩中はメールチェックなど他の業務を避けること。

ペアのローテーション

ペアのローテーション（選手交代）とは、しばらく共同作業を行った後で一方がストーリーから離れ、もう一方が残って、職場にいる他の誰かと作業を続行することを指します。この「残る人」はしばしばストーリーの「アンカー」と呼ばれます。

ローテーションする理由のひとつは、ロジスティクス（調達）です。ペアの一方が病気になることもあれば、休暇を取ることもあります。一方がリモートワークの日のこともあります。ハードウェアのセットアップの関係上、ペア作業は2人が物理的に同じ場所にいる必要があります。

もうひとつの理由は、ローテーションで「淀みを防ぐ」ためです。同じペアでの作業がしばらく続いて一緒にいる時間が長くなりすぎると、ペアの一方にストレスがたまっている兆候が現れ始めます。それに、非常に退屈かつ消耗する作業でもローテーションがあれば一息つけますし、新しく来たメンバーが違う視点を持ち込んでくれたり活気づけてくれることもあります。

最後に、ペアをローテーションする最大の理由は「知識のタコツボ化（knowledge silos）」を避けるためです。すなわち、自分が掌握しているコード（コードのオーナーシップ）が増加して、絶えずレビューしなければならないコード量がさらに積み上がってしまう状態を避けるためです。もちろんペアを組むことで既にある程度対処はできますが、ローテーションも取り入れることで、本番コードを見つめる目玉の平均個数をさらに増やせます。

ローテーションの理想的な頻度については、さまざまな意見が飛び交っています。「知識の伝搬や品質を十分なものにするには2〜3日に一度は常にローテーションすることが重要」だと信じている人々もいます。しかし、ローテーションはある程度の代償を伴います。新人には研修期間も必要ですし、ペアの1人にはコンテキストスイッチのコストも発生します。継続的にアンカーを引き受ける人がいないと、問題に対する暗黙知が増加するリスクや、ソリューションの余地が失われて手戻りにつながるリスクが生じます。若手の開発者であれば、ローテーションの間隔を長めに取り、じっくりトピックに取り組んで知識を身体に馴染ませるのに十分な期間を設ける方がメリットが大きいこともよくあります。

原注: 「show and tell」という用語は、アジャイルのチームでさまざまな意味で使われています。ここでは「定期的に開催される開発者作戦会議」「技術的負債や学習や重要な新しいコードについて週1で集まって議論する時間」を指すことにします。

ローテーションにおける「コスト」と「メリット」のトレードオフについて考えてみましょう。たとえば自分が既に高品質の知識を持ち合わせていて、読みやすいコードやよいドキュメント作成についてチームで「show and tell」するとしましょう。この場合、ローテーションを頻繁に行うことにこだわってしまうと、コードのオーナーシップ（の削減）はわずかに改善されるだけにとどまってしまい、むしろチーム内に軋轢やオーバーヘッドが生じてしまう可能性があります。

その日の作業計画を立てる

ペア作業では、スケジューリングやカレンダーの調整もある程度以上きちんと行うことが求められます。これらを確認して対応する時間を確保しておかないと、その日のうちに悩みのタネとなって我が身に返ってきます。

業務のスタートはカレンダーのチェックから始めること。ペア作業に何時間使うかについてペアの相手と合意を取り、ペア作業以外のミーティングや業務についてもプランニングが必要かどうかをチェックします。ペアの一方がしばらく一人で作業に集中しなければならないことがわかったら、その間はペアの他方が席を外していても作業を続行できるよう準備しておきます（つまりペアの他方のPCを使わないようにする）。

その日に他にもミーティングや立ち会いの必要な作業がある場合は、リマインダーをしっかりセットして時間になったら通知されるようにします（特にペアの他方のPCを使っている場合に重要）。チームがデフォルトでペアを組む体制を取っているのであれば、チーム共通の「コーディング集中タイム」を設けてチーム全員と合意を取ることも検討してみましょう。こうしておくとスケジューリングが遥かにやりやすくなります。

物理的セットアップ

ペアプロでは、1つの机の物理スペースを共有し、2人が顔を突き合わせながら作業することになります。この状態は、自分の机に何でも置いておける状態とかなり勝手が違います。2人が近寄って作業するうえでは、お互いへのリスペクトと、相手のニーズに注意を払うことが求められます。ある程度時間をかけて、ペアのどちらにとっても快適な作業環境を模索しておくことに価値がある理由がこれです。

ペアのそれぞれの机の上に十分スペースを確保したか: 必要なら机の上を片付けておきましょう。
机の前に2人が楽に座れるスペースはあるか: ゴミ箱や自分のかばんはしまっておきましょう。
使うキーボード（マウス）は2つにするか1つにするか: これについては一般的にうまくいく明確なルールはないので、最適なセットアップをいろいろ試してみることをおすすめします。「清潔さ」は割とあなどれない要素です。他人のキーボードに触るのはイヤではありませんか？自分のスペースが狭いのはイヤではありませんか？
外部モニタは1台以上あるか: 外部モニタがない場合は、リモートでペア作業するときのように、何らかの形で画面共有することを検討しましょう。画面共有のセットアップでは、それぞれ自分のノートPCのキーボードを使うことになるでしょう。
ペアの相手には設定上の特別な好みや注文があるか: フォントは大きい方がいい、コントラストは強めがいいなど。
特殊なキーボードやIDEセットアップを使っているか: そうした特殊なセットアップを相手が使っても大丈夫かどうかをチェックします。その場合、特殊なセットアップをワンタッチで標準セットアップに戻せるかどうかもチェックします。
チームのデフォルトセットアップを統一可能か: セットアップの統一についてチームで合意できるのであれば、各人の好みについて延々と議論せずに済むので話が早くなります。

リモートペアプロ

自分のチームが複数拠点に分散していたり、メンバーの何人かがときどき自宅で作業することはありますか？双方のネット接続が十分安定している限り、ペアプロは十分可能です。

リモートペアプロのセットアップ

リモートペア作業では、自分の見ている画面の他に、キーボードを切り替えて相手のPCの画面も制御する何らかの画面共有ソリューションが必要です。こうした機能は既にさまざまなビデオ会議ツールでサポートされていますので、商用ビデオ会議ツールのライセンスを持っている会社で働いているのであれば、まずそれを使えるかどうか試してみましょう。オープンソースにもjitsiのようなリモート制御機能付きのビデオ会議ツールがあります。通信帯域幅の狭い環境向けには、sshとtmuxの併用やVSCodeのLive Share拡張などのソリューションも試してみましょう。

リモートペアプロのコツ

動画でお互いの顔も見えるようにする: 人間同士のコミュニケーションでは仕草や表情が大きな要素を占めるので、画面を共有するときにペアの相手の顔も動画で表示しておくとよいでしょう。そうした機能を持つビデオ会議ソリューションもありますが、自分の使っているビデオ会議にそうした機能がない場合は、別の回線を開いてお互いの顔が見えるようにすることを検討します。
計画立案や設計作業: オンラインコラボレーションツールのビジュアル表示機能を使えば、紙やホワイトボードに共同でスケッチを書き込む作業を再現できます。
音声品質: 周囲の騒音が少ない静かな部屋を選び、品質の良いヘッドセットを使いましょう。指向性マイクもあるとさらによいでしょう。ノイズがある場合はマイクのオンオフ機能も有用です。周囲の騒音で気が散らなくなるノイズキャンセリングヘッドフォンも便利です。

原注: リモートペア作業について詳しく知りたい方へ
Chelsea Troyのブログ記事には、リモートペアプロのノウハウを含むペアプロ上級編記事がまとめられています。

ネットワーク遅延と戦う: ネットワークが遅延している状態でリモートPCと作業していると消耗しがちです。定期的にPCを入れ替えて、遅延の少ない方のPCで作業するチャンスを見つけてみましょう。ネットワークが遅延すると、ファイルのスクロールを追うのもつらくなってしまうことがあります。長いファイルのスクロールを避けて、ファイル内を移動するキーボードショートカットや、エディタの折り畳み/展開機能を活用してみましょう。

人的要因

チームの全員が分散しているのではなく、1〜2名だけがリモート作業しているのであれば、オフィス内で行われるすべての話し合いにもリモートメンバーを参加させてみましょう。同じ部屋にいるというだけで、ちょっとしたすり合わせがいかに多く行われているかということを私たちは忘れがちです。

顔を合わせたこともない人と初めてリモート越しで作業すると、通常よりも面倒が増えます。ペア作業はリモートチームのメンバーとお互いに親しくなれるチャンスでもありますが、共同作業の部分を見落としがちでもあります。相手とじかに会う機会がなさそうなら、お互いをよく知るために別の手を考えてみましょう（リモートでコーヒータイムを取ってみるなど）。

最後に、リモートペア作業にはそれなりの困難が伴いますが、ヘッドフォンを付けて気が散りにくくなる分、オフィスでペア作業をするよりも集中しやすくなることもあります。

作業が終わったら喜びを分かち合おう

共同のタスクが終わったら、お互いに「やったね！」「お見事！」「お疲れさま！」などとねぎらったり声をかけたりしましょう。いい大人同士がハイタッチなんて気恥ずかしいと思うかもしれませんが、実はこういうちょっとした「パワーポーズ」を2人でキメることで元気も出ますし、次のタスクの準備もはかどります。もちろん自分なりのオリジナルなねぎらい方でやってもよいでしょう。たとえばLara Hoganは自分のキャリアで何か達成するとドーナツで自分にごほうびをあげるそうです。

ペア作業で避けるべき落とし穴

ペア作業を快適に進めるのに役立つ、さまざまなアプローチやテクニックがあります。避けておきたい、よくある落とし穴についていくつかご紹介します。

1. よそ見で相手を無意識にないがしろにする

ペアを組んでいる最中は、メールを読んだりスマホをいじったりしないようにしましょう。そのような気晴らしを手元で繰り返していると、相手はだんだん自分がないがしろにされているように感じ、取り組んでるタスクに気乗りしなくなってしまう可能性もあります。もしどうしてもメールチェックなどが必要であれば、こそこそやらずに「すみません、一瞬メールチェックさせて」というふうに理由も含めて相手に伝えましょう。また、休憩時間や日々の個人的な時間にメールに目を通したりするのは問題ありませんよと伝えて相手を安心させましょう。

2. マイクロマネージメント

マイクロマネージメントモードに陥らないよう注意しましょう。次のように、相手に考える余地も与えずに一挙一動を指示していると相手に不満がたまってきます。

「じゃあsystemドットprintって入力してそれから…」
「つまりxxという名前のクラスが必要かな…」
「コマンドキーとシフトキーを押しながらOキーを押して…」

3. せっかち

「5秒ルール」をお忘れなく。ドライバーのやっていることが「間違っている」ことにナビが気づいてツッコみたくなっても、必ず5秒以上待ちましょう。ドライバーが既に自分で間違いに気づいていたら、余計なおせっかいで流れが中断されてしまいます。

ナビを担当するときは、ミスや落とし穴になりそうな点をその場で指摘しないこと。ドライバーが自分で修正するまでちょっと待つか、後で思い出せるように付箋にメモしておきましょう。ドライバーがミスするたびに横槍を入れると、ドライバーが混乱してしまう可能性があります。

4. キーボードを譲ろうとしない

キーボードを握ったら放さないタイプの方はご用心。相手に入力させるのを忘れて自分ばかり操作していませんか？

これをやられた人は心底嫌な気持ちになります。蚊帳の外に置かれた気分ではろくに集中できなくなるかもしれません。既にご紹介したアプローチのどれかを用いて、入力担当をまめに切り替えるようにしましょう。

5. ぶっ通しのペア作業

ペアプロをうまく回そうとチームが真剣に取り組むあまり、1日8時間ずっとペアプロし続けてしまうことがあります。私たちの経験から申し上げれば、こんなペアプロは長続きしません。第1に消耗が激しすぎます。第2に現実の業務でうまくいきません。コーディング以外にもメールチェックや面談や会議や調査や自習など、やることはたくさんあります。一日の計画を立てるときは、コーディングに100%の時間が使えると仮定しないよう、くれぐれもお忘れなく。

「正しい方法」の決定版は、ない

ペアプロのアプローチはさまざまですが、ペアプロに「これこそが正しい方法」というものは存在しません。ペアプロは、スタイルや個人の性格、経験値、状況、タスクそのものなど、さまざまな要因に応じて姿を変えます。最後に、最も重要な問いかけをご紹介しましょう。「それをやれば確実にメリットが生じますか？」もしノーであれば他の方法を試し、見直しや議論や調整を重ねてメリットを得られるようにしましょう。

第1章: ペアの組み方（本記事）
第2章: ペアプロのメリット
第3章: ペアプロの難しい点
第4章: ペアプロは導入すべきなのか、第5章: それでもペアプロする理由

概要