ペアプログラミングについて
今日のソフトウェア開発に従事する多くの人は、ペアプログラミングという手法を耳にしたことがあるでしょう。しかし、それでも業界での採用は未だに断片的です。その受け入れ方が様々である理由の一つは、そのメリットがすぐに明らかにならないことであり、中長期的な効果が大きいです。「2人が1台のコンピューターで作業する」だけではないため、不快に感じた際に多くの人がすぐにそれを却下します。しかし、私たちの経験では、ペアプログラミングは協調的なチームワークと高品質なソフトウェアに不可欠です。
2020年1月15日
Birgitta Böckelerは、ドイツのThoughtworksで開発者兼コンサルタントとして活躍しています。カスタムソフトウェアデリバリーチームのテクニカルリードとして、コーディング、コーチング、コンサルティング、そして仕事の楽しさを維持することに日々を費やしています。
Nina Siesseggerは、ドイツのハンブルク出身のソフトウェア開発者、テクニカルリード、コンサルタントであり、元ThoughtWorkerです。コードを書く喜びに加え、ソフトウェア開発における人間的な側面にも特に興味を持っています。彼女は、高品質なソフトウェアは、コミュニケーション、コラボレーション、信頼を重視するチームによって開発されると強く信じています。
Betty Snyderと私は、最初からペアでした。そして、最高のプログラムとデザインはペアによって行われると信じています。なぜなら、互いに批判しあい、互いのエラーを見つけ、最高のアイデアを使うことができるからです。
すべてのプロダクションプログラムを、2人が1台の機械に座って作成する。
-- Kent Beck
Jean Bartikは、ENIACの女性プログラマーの一人で、多くの人々によって最初のプログラマーと考えられています。「プログラム」という言葉さえまだ使われておらず、ロールモデルや方法を記した本もなかった時代にプログラミングという仕事を引き受け、ペアで作業するというアイデアを思いつきました。ペアプログラミングが広く知られるようになるまでには、さらに約50年かかりました。Kent Beckが1990年代後半に著書「エクストリームプログラミング」の中でこの用語を説明した時です。この本は、アジャイルソフトウェア開発手法をより広い層に紹介し、ペアプログラミングもその一つでした。
ペアプログラミングは、基本的に2人が1台の機械で一緒にコードを書くことを意味します。非常に協調的な作業方法であり、多くのコミュニケーションを伴います。開発者のペアが一緒にタスクに取り組む際に、コードを書くだけでなく、作業の計画や議論も行います。その過程でアイデアを明確にし、アプローチについて議論し、より良い解決策にたどり着きます。
この記事の最初の部分、「ペアプログラミングの方法」では、ペアプログラミングへの様々な実践的なアプローチの概要を示しています。ペアプログラミングを始めたい、またはペアプログラミングのスキルを向上させたい読者の方々を対象としています。
2番目と3番目の部分、「メリット」と「課題」では、ペアプログラミングの目標と、その目標を達成する妨げとなる課題への対処方法を掘り下げて説明します。ソフトウェアやチームにとってペアプログラミングがなぜ有益なのかをより深く理解したい方、または改善すべき点を探している方にとって役立つ部分です。
4番目と5番目の部分、「ペアプログラミングを行うべきか、しないべきか？」と「しかし、本当に、なぜ苦労するのか？」では、チームのフローとコラボレーションという大きな枠組みにおけるペアプログラミングについての考えをまとめます。
ペアプログラミングの方法
スタイル
ドライバーとナビゲーター
これらの古典的なペアプログラミングの役割定義は、多くのペアリングアプローチに何らかの形で適用できます。
ドライバーは、ハンドルを握っている人、つまりキーボードを操作する人です。彼女は目の前の小さな目標の達成に集中し、今のところはより大きな問題を無視します。ドライバーは、作業中常に自分が何をしているかを説明する必要があります。
ナビゲーターは、ドライバーがタイピングしている間、観察者の立場にあります。彼女はコードをオンザゴーでレビューし、指示を与え、考えを共有します。ナビゲーターは、より大きな問題やバグにも目を向け、次のステップや障害の可能性をメモします。
この役割分担の考え方は、コードについて2つの異なる視点を持つことです。ドライバーの思考はより戦術的であり、目の前のコード行といった詳細について考えます。ナビゲーターは、観察者の役割においてより戦略的に考えることができます。彼らは全体像を念頭に置いています。
一般的な流れは以下のようになります。
- 比較的明確に定義されたタスクから始める
- 一度に一つの小さな目標に合意する。これは、単体テスト、コミットメッセージ、付箋に書き留めたもので定義できます。
- キーボードと役割を定期的に交換する。共有された能動的な参加は、エネルギーレベルを維持し、物事をより良く学習し理解します。
- ナビゲーターとして、「戦術的」な思考モードを避け、コーディングの詳細をドライバーに任せましょう。あなたの仕事は一歩下がって、中長期的な思考でペアのより戦術的なモードを補完することです。次のステップ、潜在的な障害、アイデアを付箋に書き留め、小さな目標が達成された後にそれらを話し合うことで、ドライバーのフローを中断しないようにします。
ピンポン
このテクニックは、テスト駆動開発 (TDD) を採用しており、テスト駆動型で実装できる明確に定義されたタスクに最適です。
- 「ピン」：開発者Aが失敗するテストを作成する
- 「ポン」：開発者Bがそれをパスさせるための実装を作成する。
- 開発者Bは次に「ピン」、つまり次の失敗するテストを開始します。
- 各「ポン」の後には、次の失敗するテストに進む前に、一緒にコードをリファクタリングすることもできます。「赤-緑-リファクタリング」アプローチに従います。失敗するテストを書く（赤）、最小限の手段でパスさせる（緑）、そしてリファクタリングする。
ストロングスタイルペアリング
これは、Llewellyn Falcoがここでより詳細に説明している、特に知識転移に役立つテクニックです。
ルール：「あなたの頭からコンピューターにアイデアを入れるには、必ず他人の手を介さなければならない」。このスタイルでは、ナビゲーターは通常、設定またはタスクに精通している人であり、ドライバーは初心者（言語、ツール、コードベースなど）です。経験豊富な人は主にナビゲーターの役割を担い、初心者を指導します。
重要な点は、ドライバーがナビゲーターを完全に信頼し、「不完全な理解で快適である」ということです。「なぜ」という質問や解決策への異議は、実装セッション後に議論する必要があります。一人が完全に初心者である環境では、これによりペアリングがはるかに効果的になります。
このテクニックはマイクロマネジメントの域に達しますが、受動的な「見て学ぶ」よりも能動的な「やって学ぶ」を促進するための有用なオンボーディングツールになる可能性があります。このスタイルは、初期の知識転移には最適ですが、使いすぎないように注意してください。目標は、しばらく経ってから役割を簡単に切り替え、マイクロマネジメントモードから容易に抜け出せるようになることです。それが、知識転移がうまくいったことの証となります。
ペア開発
「ペア開発」は、ペアプログラミングを行うための具体的なテクニックというよりも、ペアリングに対する考え方です。（この用語を最初に目にしたのは、Sarah MeiのTwitterアカウントのこのスレッドでした）。ユーザーストーリーや機能の開発には、コーディングだけでなく、多くの他のタスクも必要です。ペアとして、あなたはそれらのすべてに責任を負います。
考え方を理解するために、ペアリングに役立つストーリーライフサイクルにおける非コーディングアクティビティの例をいくつか示します。
計画 - 私たちの目標は何ですか？
何かを一緒に作業し始めるときは、すぐにコーディングを始めないでください。機能のライフサイクルの初期段階は、無駄を避けるための絶好の機会です。この初期段階で4つの目で問題を見ることで、誤解や前提条件の欠落を早期にキャッチし、後で多くの時間を節約できます。
- 問題を理解する：ストーリーを読み、お互いに理解していることを説明し合います。プロダクトオーナーと未解決の質問や潜在的な誤解を明確にします。チームに準備完了の定義がある場合は、それをもう一度確認し、開始するために必要なものすべてがあることを確認します。
- 解決策の考案： 問題に対する潜在的な解決策をブレインストーミングします。これは共同で行うか、個別にアイデアを出し合って共有するか、どちらの方法でも可能です。これは、解決策が既にどの程度明確になっているか、そして個々のスタイルにも依存します。一人で考える時間を好む人もいれば、考えながら大声で話し合うことを好む人もいます。どちらか一方がその分野や技術にあまり詳しくない場合は、必要なコンテキストを互いに共有する時間をとってください。
- アプローチの計画： 選択した解決策に対して、そこに到達するために必要なステップは何ですか？考慮すべきタスクの特定の順序はありますか？どのようにテストしますか？理想的には、これらの手順を共有ドキュメントまたは付箋に書き留めてください。これにより、進捗状況の追跡や、タスクの作業に他のメンバーを参加させる必要がある場合に役立ちます。書き留めることで、何をすべきかを思い出すのに役立ちます。私たちはしばしば、翌日ですら、どれだけのことを忘れてしまうかを過小評価しがちです…
調査と探求
どちらも慣れていない技術を使用する必要がある機能を実装する場合、最初に調査と探求を行う必要があります。「ドライバー-ナビゲーター」や「ピンポン」アプローチのような明確な方法では対応できません。たとえば、同じ画面で一緒に検索エンジンの結果を閲覧するのは、通常はあまり効果的ではありません。
ペア開発モードでこれに取り組むための1つの方法を以下に示します。
- 適切な解決策を考案するために回答する必要がある質問のリストを定義します。
- 分担 - 質問を分けるか、同じ質問に別々に回答してみます。質問に答えるためにインターネットや組織内の他のリソースを検索するか、両方にとって新しい概念について読んでください。
- 事前に合意した時間枠の後で再び集まり、発見した内容について話し合い、共有します。
ドキュメント作成
コード以外で共同作業するもう一つのことは、ドキュメント作成です。行った作業に必要なドキュメントがあるかどうかを一緒に検討してください。これも、ケースバイケース、個々の好みによって異なりますが、ドキュメントを共同で作成するか、一人が作成して他の人がレビューと表現を調整するかを選択できます。
ドキュメント作成は、ペアが互いに規律を維持できるタスクの良い例です。これはしばしば最後に残されるタスクであり、「完了」状態にするという素晴らしい気分を妨げている最後のタスクである場合、多くの場合、スキップするか、「適当に済ませ」ます。ペアで作業することで、将来非常に感謝するであろう価値のある、しかし面倒な作業について、正直になります。
時間管理
ペアリングの一般的なスタイルに加えて、作業を容易にするためのその他の小さなツールやテクニックがあります。
ポモドーロテクニックはそのようなツールの1つです。これは、作業を伝統的に25分間の時間枠に分割し、短い休憩で区切る時間管理方法です。このテクニックは、説明されているほとんどすべてのペアリングアプローチに適用でき、集中力を維持します。ペアリングは疲れる作業となる可能性があるため、休憩を取ることを思い出したり、定期的にキーボードを切り替えたりすることが役立ちます。
ポモドーロテクニックを実際どのように使用するかの一例を以下に示します。
- 次に取り組む作業を決定する
- 多くのポモドーロブラウザ拡張機能（または本物のトマト型のキッチンタイマーなど）を使用して、25分のタイマーを設定します。
- 中断せずに作業を行う
- タイマーが鳴ったら作業を一時停止します - 短い休憩（5〜10分）から始めます
- これらの「ポモドーロ」を3つか4つ行ったら、より長い休憩（15～30分）を取ります。
- 短い休憩は、本当に休憩してエネルギーを充電し、水やコーヒーを飲み、トイレに行き、新鮮な空気を吸うために使用してください。電子メールの執筆など、他の作業にはこれらの短い休憩を使用しないでください。
ペアローテーション
ペアのローテーションとは、しばらく一緒に作業した後、ペアの半分がストーリーから離れ、もう一方が新しいメンバーをオンボーディングして作業を継続することです。残る人をしばしばストーリーの「アンカー」と呼びます。
ローテーションを行う理由の1つのカテゴリは、ロジスティクスです。ペアリングパートナーが病気になったり、休暇を取ったりする場合があります。または、ハードウェア設定が含まれているなど、作業に現場での物理的な存在が必要なため、どちらか一方が1日リモートで作業する場合があります。
ローテーションを行うもう1つの理由は、状況を変えることです。2人がしばらく一緒に作業していて、「籠城気分」を示し始めている場合、または非常に退屈でエネルギーを消耗する作業をしている場合があります。ローテーションにより、一方は休憩でき、新しいメンバーが新鮮な視点とエネルギーをもたらすことができます。
最後に、ペアローテーションの最も一般的な理由は、ナレッジサイロを回避し、集団的なコード所有権を高め、より多くのコードレビューをオンザゴーで行うことです。ペアリング自体は既にこれらのことに役立っていますが、ローテーションにより、本番環境に投入される各コード行に対する平均的な目数をさらに増やすことができます。
ローテーションの理想的な頻度については、意見が分かれています。ある人は、十分な知識の普及と品質を確保するために、2〜3日ごとのローテーションが不可欠だと信じています。しかし、ローテーションにはいくつかのコストが伴います。新しいメンバーをオンボーディングする時間と、2人のうちの1人のコンテキストスイッチのコストがあります。継続性を維持するための定常的なアンカーがない場合、問題と解決策の空間に関する暗黙の知識が失われ、再作業を引き起こすリスクが高まります。よりジュニアレベルの開発者にとっては、十分な時間を費やしてトピックに没頭し、新しい知識が定着する時間を与えるため、より長く作業を続ける方が有益な場合があります。
これらのコストとメリットのトレードオフについて考えてみましょう。たとえば、チームの「ショーアンドテル」、可読性の高いコード、適切なドキュメントなど、既に高品質の知識共有がある場合、頻繁なローテーションを強く主張しても、集団的なコード所有権がわずかに向上するだけで、摩擦とオーバーヘッドが大量に発生する可能性があります。
1日の計画
ペアリングには、ある程度のスケジューリングとカレンダーの調整が必要です。これを認識して対応する時間を取らないと、後で問題が発生します。
カレンダーを確認して1日を始めてください。ペアリングパートナーと、ペアリングする時間を合意し、ミーティングやペアリングタスク以外の作業に必要な時間を考慮して計画する必要があるかどうかを確認します。どちらか一方がしばらく一人で作業しなければならないことが判明した場合は、たとえばその人のコンピューターを使用してコードを作成しないなど、他のメンバーがいない場合でも作業を継続できるように準備してください。
日中にミーティングやその他の約束がある場合は、特にペアリングパートナーのマシンで作業している場合は、気付くことができるようにリマインダーを設定してください。チームがデフォルトでペアリングする場合は、全員で定期的な「コアコーディング時間」を合意することを検討してください。これにより、スケジューリングがはるかに容易になります。
物理的な設定
ペアプログラミングとは、共有デスクの物理的な空間で非常に緊密に協力して作業する必要があることを意味します。これは、自分のテーブルを広げて作業することとは大きく異なります。お互いに非常に近い距離にいるためには、お互いのニーズに対する一定の尊重と配慮が必要です。そのため、両方にとって快適な設定を把握するのに時間を費やす価値があります。
- 両方とも十分なスペースがあることを確認し、必要に応じて机を片付けます。
- 机の前に2つの椅子を置くのに十分なスペースがありますか？ゴミ箱やバックパックを邪魔にならないように片付けてください。
- キーボードを2つ使用しますか、それとも1つ使用しますか？マウスについても同様です。常に有効な明確なルールはありません。状況ごとに最適な方法を試してみることをお勧めします。これに関与する要因には、衛生状態、キーボードの共有時間の長さ、利用可能なスペースの量などがあります。
- 外部モニター、または2つある場合もありますか？ない場合は、リモートペアリングのように、何らかの画面共有を設定することも検討できます。その設定では、それぞれが自分のラップトップキーボードを使用します。
- パートナーに特定の好みやニーズ（たとえば、大きなフォントサイズ、高いコントラストなど）があるかどうかを確認してください。
- 珍しいキーボード/IDE設定を使用している場合は、パートナーがそれで問題ないかどうかを確認してください。これらの状況では、設定をより標準的な構成に簡単に切り替えるメカニズムを用意できるかどうかを確認してください。
チームがデフォルトの設定に合意できれば、これらのことを何度も話し合う必要がないため、有益です。
リモートペアリング
分散型チームの一員ですか、または一部のチームメンバーが時々自宅で作業していますか？両方とも比較的安定したインターネットアクセスがあれば、ペアプログラミングを実践できます。
設定
リモートペアリングの場合、相手のマシンを見ることができるだけでなく、制御することもできる画面共有ソリューションが必要です。これにより、キーボードを切り替えることができます。今日の多くのビデオ会議ツールは既にこれをサポートしているので、商用VCツールのライセンスを持っている企業で働いている場合は、最初にそれを使用してみてください。リモートコントロール付きのビデオ通話のためのオープンソースツールもあります（例：jitsi）。低帯域幅で動作するソリューションとしては、tmuxを使用したsshやVisual Studio CodeのLive Share拡張機能などがあります。
ヒント
- ビデオを使用する： 人々はジェスチャーや表情を通して多くのコミュニケーションをとるため、共有画面とペアリングパートナーのビデオを同時に見るのは良いことです。一部のビデオ会議ソリューションにはこの機能が備わっています。お使いのソリューションにない場合は、お互いを見ることができるように追加の通話を開始することを検討してください。
- 計画と設計： 紙やホワイトボードにスケッチする体験を再現するために、共同オンライン視覚化ツールを使用します。
- オーディオ体験： 静かな場所を探して、できれば指向性マイク付きの高性能ヘッドセットを使用してください。騒音から離れられない場合は、「プッシュトゥトーク」機能も役立ちます。自分の側の気を散らすものを避けるために、ノイズキャンセリングヘッドホンはあなたの味方です。
- ネットワーク遅延への対処：ネットワーク遅延がある場合、リモートコンピューターで長時間作業するのは大変です。そのため、定期的にコンピューターを切り替えて、全員が遅延なく自分のマシンで作業できる機会を確保しましょう。ファイルのスクロール時にネットワーク遅延が発生すると、追跡が難しくなるため、煩わしい場合があります。長いファイルのスクロールは避け、キーボードショートカットを使ってファイルの異なる部分を開くか、折りたたみ/展開機能を使用すると役立ちます。
人間的な側面
チーム全体が分散しておらず、リモートワークをしているメンバーが1～数名だけの場合、オフィスで行われているすべての議論にリモートパートナーを含めましょう。同じ部屋にいることで、どれほど多くの情報を無意識のうちに共有しているかを忘れがちです。
会ったことのない、知らない人とリモートで作業することは、さらなる課題となります。一方では、ペアプログラミングはリモートチームで互いに親しくなる機会となります。他方では、コラボレーションの一部を忘れがちです。直接会う機会がない場合は、互いをよりよく知るための他の方法を検討しましょう。例えば、リモートで一緒にコーヒーを飲むなどです。
最後に、リモートペアプログラミングには課題がありますが、オフィスでのペアプログラミングよりも集中しやすくなる可能性もあります。ヘッドフォンを使用することで、周囲の気を散らすものを簡単にシャットアウトできるためです。
一緒にドーナツを食べる
タスクを一緒に完了したら、お祝いしましょう！ハイタッチは古臭く思えるかもしれませんが、実は一緒にできる小さな「パワーステンス」で、活力を与え、次のタスクの準備ができます。あるいは、ドーナツでキャリア上の成果を祝うLara Hoganのように、独自の成功の祝い方を生み出すこともできます。
避けるべきこと
様々なアプローチとテクニックは、より良いペアプログラミング体験に役立ちます。避けるべき一般的な落とし穴をいくつかご紹介します。
離れていくこと
ペアプログラミング中は、メールを読んだり、携帯電話を使用したりしないようにしましょう。これらの気が散る行為は、ペアに対して失礼に当たる可能性があり、作業から気をそらします。本当に何かを確認する必要がある場合は、何をしているのか、なぜそうしているのかを明確に伝えましょう。十分な休憩を取り、毎日個人の時間を確保することで、全員がメールを読むのに十分な時間を取れるようにしましょう。
マイクロマネジメントモード
マイクロマネジメントモードに注意しましょう。相手が考える余地がなくなり、次のような指示を繰り返し与えられると、フラストレーションが溜まります。
- 「今、『System.print("...』と入力してください。」
- 「新しいクラスを作成する必要があります…」
- 「command + shift + Oを押してください…」
せっかちさ
「5秒ルール」を適用しましょう。ナビゲーターがドライバーが何か「間違った」ことをしたのを見て、コメントしたいと思った場合、発言する前に少なくとも5秒待ちましょう。ドライバーはすでにそれを考えている可能性があり、その場合は不必要な割り込みになります。
ナビゲーターは、エラーや差し迫った障害をすぐに指摘しないようにしましょう。ドライバーが修正するのを少し待ち、後で覚えるために付箋にメモを残しましょう。すぐに介入すると、ドライバーの思考プロセスを妨げる可能性があります。
キーボード独占
キーボードを「独占」していないか注意しましょう。常にキーボードを操作していて、ペアプログラミングのパートナーがタイピングする機会を与えていないでしょうか？
これはペアにとって非常に迷惑な経験となり、「積極的な参加」が制限されるため、集中しにくくなる可能性があります。先に説明したアプローチのいずれかを使用して、キーボードを頻繁に切り替えるようにしましょう。
1日8時間のペアプログラミング
ペアプログラミングを成功させることに本当にコミットしているチームは、1日に8時間ペアプログラミングを行うことがあります。私たちの経験では、それは持続可能ではありません。まず第一に、単に疲れすぎます。第二に、コーディング以外の作業（メールの確認、1on1ミーティング、会議への参加、調査/学習など）が多いため、実際には機能しません。そのため、1日の計画を立てる際にはそれを念頭に置き、100％一緒にコーディングできるとは思わないようにしましょう。
「唯一の」正しい方法はない
ペアプログラミングには多くのアプローチがあり、「これしかない」という正しい方法はありません。あなたのスタイル、性格、経験、状況、タスク、そして多くの他の要因によって異なります。最終的に最も重要な質問は、「約束されたメリットを得られていますか？」ということです。そうでない場合は、他の方法を試して、反省し、議論し、調整してメリットを得ましょう。
メリット
ペアプログラミングは何に役立つのか？その潜在的なメリットをすべて認識することは、いつ行うか、どのようにうまく行うか、そして困難な時期にそれを続けるモチベーションを維持するために重要です。ペアプログラミングがサポートできる主な目標は、ソフトウェアの品質とチームのフローです。
では、ペアプログラミングはどのようにしてこれらの目標を達成するのに役立つのでしょうか？
知識共有
ペアプログラミングの最も明白で、最も議論の余地のないメリットである知識共有から始めましょう。2人がコードの一部に取り組むことで、チームは日々の技術とドメインに関する知識を共有し、知識のサイロを防ぐことができます。さらに、2つの頭脳が問題を理解し、議論することで、良い解決策を見つける可能性が高まります。異なる経験と視点は、より多くの選択肢を考慮することにつながります。
実践的なヒント
関係する技術やドメインについて全く分からなくても、タスクのペアプログラミングを避けないようにしましょう。最も快適だと感じる分野で働き続けると、新しいことを学ぶ機会を失い、最終的にはチーム内で知識を共有することができなくなります。
チームメンバーが常に同じトピックに取り組んでいることに気付いたら、専門知識を広げるために、それを混ぜるように依頼しましょう。チームの技術とビジネスのトピック、そして各人の強みと各分野におけるギャップを示したスキルマトリックスを作成するのも役立ちます。それをチームエリアの壁に掲示すれば、一緒に知識を効果的に広げることができます。
振り返り
ペアプログラミングは、単に頭の中で考えるのではなく、アプローチや解決策について議論することを強制します。大声で説明することで、本当に正しい理解をしているか、本当に良い解決策を持っているかを自問自答することができます。これは、コードや技術設計だけでなく、ユーザーストーリーやストーリーがもたらす価値にも当てはまります。
実践的なヒント
質問を自由にしたり、理解できないことについて率直に話したりできる雰囲気を作るには、2人の間の信頼が必要です。そのため、ペアプログラミングを行う場合は、チーム内の関係構築がさらに重要になります。定期的な1on1とフィードバックセッションに時間を割きましょう。
集中力の維持
2人いると、構造化されたアプローチを取りやすくなります。それぞれが、何をしているのか、どこに向かっているのかを明確に伝えなければなりません。一人で作業すると、例えば「ちょっとだけ」別の方法を試してみて、何時間も後になってから元の場所に戻ってくるなど、簡単に気が散ってしまいます。ペアプログラミングのパートナーは、あなたがそのような「ウサギ穴」に落ち込むのを防ぎ、タスクやストーリーを完了するために重要なことに集中するのに役立ちます。互いに軌道に乗った状態を維持することができます。
実践的なヒント
一緒に計画を立てましょう！現在のタスクについて話し合い、目標を達成するために必要な手順を考えましょう。各手順を付箋に書き留め（リモートの場合は、チケット管理システムのサブタスク）、順番に並べて、1つずつ進めていきましょう。ポモドーロテクニックと組み合わせて、1つのポモドーロで1つの目標を完了するようにしましょう。
コミュニケーションが鍵であることを決して忘れないでください。自分が何をしているのかについて話し合い、互いに説明を求めましょう。
オンザゴーでのコードレビュー
ペアプログラミングでは、作業中に大小さまざまな事柄について4つの目で確認できるため、完了後に発見されるエラーの数が少なくなります。
コードのリファクタリングは、常にコーディングの一部であり、したがってペアプログラミングの一部でもあります。誰かと一緒にいれば、アプローチや命名などを議論できるため、コードを改善しやすくなります。
事後に行うコードレビューには、いくつかの欠点があります。これについては、後ほど"ペアプログラミングをするかしないか？"で詳しく説明します。
実践的なヒント
互いに質問しましょう！質問は、自分が何をしているのかを理解し、より良い解決策にたどり着くための最も強力なツールです。コードがどちらか一方にとって読みやすく理解しにくい場合は、より理解しやすい別の方法を試してみましょう。
ペアプログラミングされたコードについて、より多くのコードレビューが必要だと感じた場合は、ペアプログラミングを改善できるかどうかを検討しましょう。ペアプログラミングセッション中に、すべての質問や懸念事項を提起することができなかったのでしょうか？なぜでしょうか？何を変更する必要がありますか？
2つの思考モードの組み合わせ
先に説明した古典的なドライバー/ナビゲータースタイルで説明したように、ペアプログラミングでは、コードに対する異なる視点を持つことができます。ドライバーの脳は通常、「戦術的」モードで、詳細、現在のコード行について考えています。一方、ナビゲーターの脳は、より戦略的に考え、全体像を考慮し、次のステップやアイデアを付箋にメモすることができます。1人がこれらの2つの思考モードを組み合わせることができるでしょうか？おそらくできません！戦術的な視点と戦略的な視点を組み合わせることで、全体像を念頭に置きながら詳細にも注意を払うことができるため、コードの品質が向上します。
実践的なヒント
キーボード、そして役割を定期的に切り替えることを忘れないようにしましょう。これにより、リフレッシュでき、退屈にならず、両方の思考方法を練習することができます。
ナビゲーターは、「戦術的」な思考モードを避け、コーディングの詳細をドライバーに任せましょう。あなたの仕事は一歩下がって、ペアのより戦術的なモードを中期の思考で補完することです。
集合的なコード所有権
集合的コード所有権は、モジュールの個々の所有権という概念を放棄します。コードベースはチーム全体が所有し、誰でもどこでも変更を加えることができます。
一貫したペアプログラミングにより、コードの各行が少なくとも2人の担当者によって触れられたり、見られたりするようになります。これにより、チームの誰もがほとんどどこでもコードを変更することに快適に感じることができるようになります。また、単独のコーダーだけの場合よりも、コードベースの一貫性が高まります。
実践的なヒント
ペアプログラミングだけでは、集合的コード所有権が保証されるわけではありません。知識のサイロを防ぐために、異なるペアやコードの領域に人をローテーションさせるようにする必要があります。
チームのWIPを低く保つ
作業中のものを制限することは、チームのフローを改善するためのカンバンの中核原則の1つです。作業進行中（WIP）の制限を設定すると、チームは最も重要なタスクに集中することができます。マルチタスクは個人だけでなくチームレベルでも非効率的であるため、WIP制限を設けると、チーム全体の生産性が向上することがよくあります。特に大規模なチームでは、ペアプログラミングはチームが並行して作業できるタスクの数を制限し、全体的な集中力を高めます。これにより、作業が常に流れ、ブロッカーがすぐに解決されます。
実践的なヒント
チームのWIPをチームの開発者ペアの数に制限し、チームスペース（リモートで作業する場合は、オンラインのプロジェクト管理ツール）で表示するようにしましょう。新しいタスクに着手する前に、制限を確認しましょう。WIP制限の遵守は、自然とペアプログラミングの習慣につながる可能性があります。
新規チームメンバーの迅速なオンボーディング
ペアプログラミングは知識共有を促進するため、新しいチームメンバーのオンボーディングに役立ちます。新規メンバーは、ペアの助けを借りて、プロジェクト、ビジネス、組織について知ることができます。チームの変更はチームのフローに影響を与えます。人々は互いにを知るのに少し時間が必要です。ペアプログラミングは、ソロで作業する場合よりもはるかに多くのコミュニケーションを強制するため、その影響を最小限に抑えるのに役立ちます。
実践的なヒント
新規メンバーをペアに配置するだけで、「魔法のように」参加してオンボーディングが完了するわけではありません。最初のペアリングセッションの前に、全体像と広い文脈を提供し、オンボーディングのために追加の時間を確保してください。これにより、ペアリング中に内容を理解し、貢献しやすくなり、最大限に活用できます。ペアリング時は常に新規メンバーのマシンを使用し、彼らが単独で作業できるよう設定されていることを確認してください。
取り上げるトピックのリストを含むオンボーディングプランを作成します。一部のトピックについては、専用のセッションをスケジュールする必要がある場合がありますが、他のトピックについては、新しいチームメンバーがペアからペアへとオンボーディングプランを持ち歩くことができます。ペアリングセッションで何かがカバーされた場合は、リストからチェックを外すことができます。このようにして、オンボーディングの進捗状況はチームの全員に可視化されます。
課題
ペアプログラミングには多くの利点がありますが、練習が必要であり、最初からスムーズに機能するとは限りません。以下は、チームが経験する一般的な課題の一部とその対処方法に関する提案です。これらの課題に遭遇した場合は、利点を念頭に置き、ペアリングを行う理由を思い出してください。方法を調整できるように、実践で何を達成したいかを理解することが重要です。
ペアプログラミングは疲れることがある
一人で作業している場合、いつでも休憩を取ることができ、必要に応じて心が少しの間さまよったり、シャットダウンしたりすることができます。ペアリングは、より長い時間集中し続け、相手のリズムや考え方との共通点を見つけることを強制します。集中力の向上はペアリングの利点の1つですが、非常に集中的で疲れる可能性もあります。
対処方法
この課題に対処するには、十分な休憩をとることが重要です。定期的な休憩をとるのを忘れていないかを確認するには、アラームクロックで休憩をスケジュールします（例：1時間あたり10分）。または、Pomodoroなどの時間管理テクニックを使用します。昼食休憩をスキップしないでください。モニターから離れて、本当の休憩を取りましょう。ペアリングの有無にかかわらず、休憩をとることは重要であり、生産性を向上させます。
疲労を防ぐために重要なもう1つのことは、1日に8時間ペアリングしないことです。1日最大6時間に制限します。ドライバーとナビゲーターの役割を定期的に切り替えることで、エネルギーレベルを維持することもできます。
集中的なコラボレーションは難しいことがある
長時間、他の人と緊密に協力することは集中的です。絶えずコミュニケーションをとる必要があり、共感力と対人スキルが必要です。
技術、知識、スキル、外向性、性格、または問題解決へのアプローチに違いがある場合があります。それらの組み合わせによっては、うまく合わず、困難なスタートを切る可能性があります。その場合、コラボレーションを改善するために時間を投資し、苦労ではなく相互学習の経験にする必要があります。
対処方法
ペアリングセッションの開始時に会話をすることで、スタイルの違いを理解し、それに適応する計画を立てることができます。「どのように協力したいですか？」、「どのようにペアリングすることを好みますか？」などの質問で最初のセッションを始めましょう。自分がどのように作業するのが好きで、どのように効率的であるかを意識する一方、他のアプローチに固執しないようにしましょう。新しい発見があるかもしれません。
1日のペアリングの終わりに、お互いにフィードバックのラウンドを行います。フィードバックを与えるという考えが不安に感じられる場合は、ミニレトロスペクティブとして考えてみてください。ペアリングセッション中の両方の感情を振り返ってみましょう。警戒していましたか？疲れていましたか？何が快適に感じさせ、何がそうではなかったですか？キーボードを十分に頻繁に切り替えましたか？目標を達成しましたか？次回試してみたいことはありますか？何かがうまくいかないときにフィードバックを与える練習ができるように、これを早い段階で習慣にすることが重要です。
対人関係の衝突や困難、たとえば難しい会話に対処するのに役立つ優れたトレーニングと書籍があります。
課題にチームとして取り組み、個々に問題を残さないようにします。たとえば、ペアリングに関するセッションを開催し、困難に対処する方法を一緒に議論することで、これを行うことができます。セッションの開始時に、ペアリングの利点を収集して、全員がそこから何を達成したいかを理解します。その後、ペアリング時に各人が感じる課題を収集します。これで、グループは改善に役立つ可能性のあるアクションについて検討できます。チームメンバーのホットボタンのトリガー（ペアリング時にすぐに不快に感じるもの）を収集することもできます。
会議による中断
会議だらけの1日を経験したことはありますか？何もできていないという印象を受けるかもしれません。これはおそらくすべてのデリバリーチームで発生します。会議は、構築しようとしているものについて話し合い、計画し、合意するために必要ですが、一方ではフローを中断します。チームがペアプログラミングを実践すると、会議が多すぎる影響はさらに悪化する可能性があります。ペアリングしている各人が異なる時間に会議を持っている場合、中断は増加します。
対処方法
1つのアプローチは、たとえば会議のないコアペアリング時間を定義するか、「正午以降は会議なし」などのルールで会議のない時間をブロックすることで、会議が発生する時間枠を制限することです。
会議の長さと全体的な量についても検討する価値があります。本当に必要な会議はどれですか？それらの目標は何ですか？適切な準備、ファシリテーション、明確な議題などにより、品質を向上させるにはどうすればよいですか。
しかし、1つ確かなことは、常に会議があるということです。それでは、ペアとしてどのように対処すればよいでしょうか？ペアリングセッションの開始時に一緒にカレンダーを確認し、ペアリングを開始するのに十分な時間があることを確認します。会議がある場合は、ペアとして参加することを検討してください。プロダクトオーナーや他の非ペアリングチームメンバーに頼り、コアペアリング時間帯にチームからの中断を防ぎましょう。
異なるスキルレベル
経験レベルの異なる2人が特定のトピックでペアリングする場合、それぞれがどれだけ貢献できるか、またはペースの違いによる不満について、誤った仮定につながることがよくあります。
対処方法
ペアの経験がトピックについて多い場合：彼らが最善を知っていると仮定しないでください。なぜ彼らがその方法で物事をしているのかを説明する必要があることで、新しい洞察が得られるかもしれません。どのようにそしてなぜという質問をすることは、実りある議論とより良い解決策につながる可能性があります。
ペアの経験がトピックについて少ない場合：彼らが解決策にあまり貢献できないと仮定しないでください。あなたは盲目的な状態に陥っている可能性があり、異なる視点がより良い解決策に至るのに役立つ可能性があります。また、概念を説明する必要があることは、自分がそれを本当に理解し、すべてを考え抜いたかどうかを確認する絶好の機会であることを忘れないでください。
また、初心者から専門家までの学習プロセスがどのように機能するかを理解するために、さまざまな学習段階を認識することも役立ちます。ダン・ノースは、彼の講演Patterns of Effective Teamsでこれを非常にうまく説明しています。彼は、Dreyfus Model of Skills Acquisitionを、さまざまな学習段階と、それらを組み合わせることをペアリングのコンテキストで意味することを理解する方法として紹介します。
パワーダイナミクス
パワーダイナミクスに対処することは、おそらくこのリストの中で最も難しい課題の1つです。ペアプログラミングは、階層のない空間では発生しません。マネージャーとその部下の間など、正式な階層と非公式な階層があります。非公式な階層の例は次のとおりです。
- ジュニア - シニア
- 男性以外 - 男性
- キャリアチェンジ者 - コンピュータサイエンスの学位を持つ人々
- 有色人種 - 白人
そして、これらはほんの一例です。パワーダイナミクスは流動的で交差しています。2人がペアリングする場合、これらのダイナミクスのいくつかが作用して重なり合う可能性があります。パワーバランスがペアリングにどのように影響するかを理解するために、いくつかの例を挙げます。
- 1人がキーボードを独占し、ペアリングパートナーに場所を与えないことで、ペアリングセッションを支配しています。
- 1人が常に教える立場と態度を維持しています。
- 1人がもう1人の話を聞いておらず、提案を無視しています。
これらの状況を階層に結び付けるのは微妙な場合があり、お互いにうまくいかないだけだと思うことがよくあります。しかし、根本的な問題は、多くの場合、ペアリングしている2人の間の不均衡の影響を受けています。
サラ・メイはこのトピックについて優れた一連のツイートを書いており、より一般的な方法でアジャイルにおけるパワーダイナミクスを網羅した講演も行っています。
対処方法
これに対処するための最初のステップは、パワーダイナミクスの上位側の人物が自分の立場を認め、認めることです。そうすることで初めて、ペアリングパートナーとのやり取りを正直に振り返り、パワーダイナミクスがどのように影響するかを検討できます。自分の位置付けと状況を考えましょう。パワーバランスを中和するために積極的にできることは何ですか？
これらのタイプの差異を認識し、コラボレーションを改善するために自分の行動を適応させるのは難しい場合があります。多くの自己省察が必要です。これに対して個人またはチームを支援できるトレーニングがあります。「反バイアス」またはアライ・スキルトレーニングなどです。
多くの未知数を含むペアプログラミング
両者が問題の解決策を思いつかないような大規模なトピックに取り組む場合、通常のペアリングスタイルはそれほどうまく機能しないことがよくあります。初めてテクノロジーを使用する必要がある場合、または新しいアプローチやパターンを試してみる場合を考えてみましょう。一緒に調査して実験することは、いくつかの構成では機能しますが、物事がどのように機能するかを理解する方法にはそれぞれ異なるアプローチがあり、それぞれ異なるペースで読み書き学習するため、イライラすることもあります。
対処方法
不明な点が多い場合（たとえば、新しいテクノロジーを使用する場合）、実際に作業を開始する前に、トピックを調査してテクノロジーについて学習するためのスパイクを行うことを検討してください。調査結果をチームと共有することを忘れないでください。知識交換セッションを行い、チームスペースに配置できる図表を作成することもできます。
このような状況では、ペアプログラミングではなく、ペア開発の考え方を取り入れることを忘れないでください。一緒に答える必要のある質問のセットに同意した後に、調査を行うために分割しても問題ありません。
自分自身のための時間がない
絶えず互いに会話をすることは、かなりエネルギーを消耗させる可能性があることについて説明しました。ほとんどの人は、1日を通して自分自身で過ごす時間が必要です。内向的な人々にとって特にそうです。
一人で作業している場合、必要に応じてトピックを掘り下げたり、学習したりする時間を自然に取ります。しかし、ペアリングでは中断のように感じられる可能性があります。では、必要に応じてどのようにして一人で学習時間を確保できるでしょうか？
対処方法
繰り返しますが、1日に8時間ペアリングしないでください。チームとコアコーディング時間に同意し、1日最大6時間に制限します。自己学習時間にも数時間を割り当てることもできます。
ペアが問題にアプローチするための共同知識を持っていないと感じた場合は、調べて情報を共有してから、実装を続けます。
ローテーションによるコンテキストスイッチング
知識共有はペアリングの利点の1つであり、ローテーションがその効果をさらに高める方法について説明しました。一方、ローテーションが多すぎると、頻繁なコンテキストスイッチングにつながります。
対処方法
ローテーションの頻度と、新しいペアリングパートナーがストーリーの十分な文脈を理解し適切に貢献できる可能性のバランスを見つける必要があります。ローテーション自体を目的とするのではなく、特定の文脈を共有することが重要かどうか、そしてなぜ重要なのかを考え、効果を発揮するのに十分な時間をかけるべきです。
ペアプログラミングには脆弱性が求められる
ペアリングには、脆弱性が必要です。それは、自分が知っていること、そして知らないことをすべて共有することを意味します。これは私たちにとって難しいことです。プログラマーは賢く、本当にめちゃくちゃ賢くなければなりません。ほとんどの人は私たちがすることを見て、「そんなことできない」と言います。それは私たちを特別に感じさせ、プライドを与え、プライドは無敵感を生み出します。
-- Tom Howlett
ペアリングするとき、何かがわからないことを見せたり、決定に対して不安を感じたりするのは難しい場合があります。特に、「10倍のエンジニア」のような神話が繰り返し取り上げられ、使用する言語や5年前に取った設計決定によって互いを評価する傾向がある業界ではそうです。
脆弱性はしばしば弱さと結び付けられ、現代のほとんどの文化では強さの表示が普通です。しかし、研究者のブレネー・ブラウンが複数の講演や書籍で述べているように、脆弱性は実際にはイノベーションと変化にとって非常に重要な要素です。
脆弱性は、イノベーション、創造性、変化の出発点です。
-- Brené Brown
対処方法
脆弱性を示すには勇気が必要であり、人々が脆弱性を示すことをより安全に感じる環境を作る必要があります。繰り返しますが、これはすべて、人々が互いに信頼するチームを構築することです（定期的な1対1、フィードバック、質問できる文化など）。
脆弱になることは、自然な権威（例えば、すでに尊敬されているため）または組織的な権威（例えば、「テックリード」などの肩書きを持っているため）を持つチームメンバーの方が、より簡単でリスクが低くなります。そのため、そうした人々が率先して模範を示し、それを標準にすることで、他の人にとっても脆弱になることがより安全になるようにすることが重要です。
マネージャーや同僚を説得する
ペアプログラミングの支持者は、マネージャーや同僚を説得して、ペアリングをチームの日常業務の一部にすることに苦労することがよくあります。
対処方法
ペアプログラミングの有効性を他の人に納得させるための簡単な方法はありません。しかし、重要な要素は常に、まずそれについて話し合う時間を取り、全員が同じ理解を持っていることを確認することです（例えば、この記事を読むことなど）。その後、1組のペアから始めてその経験を他の人と共有するか、「次の2スプリントはデフォルトでペアリングしましょう」といったチーム実験を提案するなどして、試行する方法を見つけます。何がうまくいっていて何が苦労しているかを共有するためのフィードバックとレトロスペクティブの機会を組み込むようにしてください。
最終的に、誰かに実践を強制することはできず、すべての人に有効なわけではありません。少なくとも最初は、チームの一部の人とだけペアリングすることになるかもしれません。私たちの経験では、人々を説得する最善の方法は、実践を定期的に経験し、チームメンバーがペアリングしながら得ているメリットと楽しさを体験することです。
この状況で最も頻繁に提起される質問は、この実践の経済性です。ペアリングは単に費用の2倍になるだけで、増加した品質とチームのメリットによって、最終的に追加費用に見合う価値があるのでしょうか？このトピックに関するいくつかの研究があり、特にこれが引用されており、ペアリングは価値があると示唆しています。しかし、ペアリングの有効性を「科学的に証明する」試みには警戒しています。ソフトウェア開発は変化と不確実性に満ちたプロセスであり、コード行を超えた多くの成果（分析、テスト、品質など）は比較や測定が困難です。ペアリングの頑固な反対者は、開発生産性を証明するために設定された「科学的」実験の再現可能性に常に穴を見つける方法を見つけます。最終的には、それがあなたにとって有効であることを示す必要があります。そして、それを行う唯一の方法は、あなたの環境で試してみることです。
ペアプログラミングを行うべきか、しないべきか
私たちの経験では、ペアプログラミングは、持続可能な方法で高品質で保守可能なソフトウェアを作成するための重要な実践であることが明確に示されています（"メリット"を参照）。しかし、教条的にアプローチして*常に*ペアリングを行うことは役に立つとは考えていません。ペアプログラミングがどのように効果的であるか、どの程度、そしてどのタスクに対して効果的であるかは、変化する可能性があります。チームではペアプログラミングを「妥当なデフォルト」として設定し、例外を作りたい場合はいつでも話し合うことが有益であることがわかりました。
ペアリングの方法と時期のバランスを取るのに役立ついくつかの例を見てみましょう。
退屈なタスク
いくつかのコーディングタスクは、よく定義された定型的なアプローチを使用することに関して「退屈」です。そのため、ペアリングは必要ないかもしれません。チーム全体がすでにこのタイプのアプローチを知っているか、非常に簡単に理解できるため、知識共有はそれほど重要ではありませんか？そして、既定のパターンが過去に成功裏に使用されてきたため、ライブコードレビューはそれほど役に立ちませんか？はい、ペアリングは必要ないかもしれません。
しかし、反復的なタスクは設計不良の兆候である可能性があることを常に考慮してください。ペアリングは、その退屈なコードに適切な抽象化を見つけるのに役立ちます。また、脳が「これは簡単だ」というオートパイロット状態になると、物事を見逃したり、軽率なエラーを犯したりする可能性が高くなります。
「本当に一人でできるだろうか？」
ペアリングは、チームのより経験豊富なメンバーから比較的早く学ぶ機会があるため、初心者プログラマーにとって多くのメリットがあります。しかし、ジュニアプログラマーは、ペアリングすると自分の能力に自信を失う可能性もあります。「本当に誰かが見ていなくてもこれができるだろうか？」。また、自分で物事を解決する方法を学ぶ機会も失われます。私たちは皆、デバッグとエラー分析で、最終的に私たちをより良いプログラマーにする、フラストレーションと観察されていない実験の瞬間を経験します。自分で問題に遭遇することは、誰かが問題に遭遇すると教えてもらうよりも、しばしばより効果的な学習経験になります。
これに対抗する方法はいくつかあります。1つは、メンターが定期的にチェックインしてコードレビューを行うことで、ジュニアプログラマーが時折自分で作業できるようにすることです。もう1つの方法は、チームのよりジュニアなプログラマー同士をペアリングさせることです。彼らは一緒に解決策を見つけることができ、一人でコーディングするよりも早くラビットホールから抜け出すことができます。最後に、ペアリングでより経験豊富なコーダーである場合は、できるだけナビゲーターの席にいるようにしてください。ドライバーに物事を解決する余地を与えましょう。それは、事前に指摘するのではなく、一緒に次の壁にぶつかるまで少し待つことだけです。
コードレビュー vs. ペアプログラミング
ペアプログラミングの利点は、その緊迫した即時性です。レビューアーがすぐ隣にいる場合、無視することは不可能です。
-- Jeff Atwood
多くの人は、コードレビュープロセスが存在することを、ペアプログラミングを必要としない十分な理由だと考えています。私たちは、コードレビューがペアリングに十分な代替手段であるという意見に反対します。
第一に、ずさんな、または表面的なコードレビューにつながる可能性のあるいくつかのダイナミクスが通常あります。例えば、コーダーとレビューアーがそれを明確にせずに互いに依存しすぎている場合：コーダーは、問題がレビューでキャッチされると考えて、いくつかの小さな決定と改善を延期する可能性があります。一方、レビューアーはコーダーの勤勉さに依存し、彼らの仕事を信頼し、コードをあまり詳しく見ていません。埋没費用効果も作用します。私たちは通常、チームがすでに投資したものの修正作業を引き起こすことを嫌がります。
第二に、コードレビュープロセスはチームのフローを妨げる可能性があります。レビュータスクを引き受けるには、誰かのコンテキストスイッチが必要です。そのため、コードレビューの頻度が高くなるほど、レビューアーにとって中断が多くなります。そして、小さな変更を継続的に統合するために、頻繁に行われる必要があります。そのため、レビューアーは統合とデプロイのボトルネックとなり、時間的なプレッシャーが加わり、再び、潜在的に効果の低いレビューにつながります。
継続的インテグレーション（およびデリバリー）では、小さな変更を頻繁に配信することでリスクを軽減したいと考えています。元の定義では、これはトランクベース開発を実践することを意味します。トランクベース開発では、コードの変更はとにかくマスターブランチにすぐに反映されるため、遅延されたコードレビューはさらに効果が低くなります。そのため、ペアプログラミングと継続的インテグレーションは、連携して行われる2つのプラクティスです。
チームが効果的に使用しているアプローチとして、デフォルトでペアリングを行うが、ペアリングせずに本番コードを変更する必要がある例外的なケースにはプルリクエストとコードレビューを使用するというものがあります。これらの設定では、継続的インテグレーションを実践していることを確認するために、プルリクエストが長すぎることにならないようチームで注意深く監視する必要があります。
しかし、本当に、なぜ苦労するのか？
ペアプログラミングの利点について多くを語ってきましたが、その課題についてもさらに多くを語りました。ペアリングを正しく行うには多くの異なるスキルが必要であり、チームの他のプロセスにも影響を与える可能性があります。では、なぜ苦労するのでしょうか？本当に手間をかける価値があるのでしょうか？
チームがペアプログラミングを快適に成功させるためには、その課題を克服するのに役立つすべてのスキルに取り組む必要があります。集中力と焦点、タスクの組織化、時間管理、コミュニケーション、フィードバックのやり取り、共感、脆弱性などです。そして、これらは実際には、円滑に連携し、効果的なチームになるのに非常に役立つスキルです。ペアリングは、チームの全員にこれらのスキルを一緒に磨く機会を与えます。
効果的なチームの成功要因として今日広く議論されているもう一つの要素は、多様性です。視点、性別、背景、スキルの多様性はチームのパフォーマンス向上に役立つことが証明されていますが、最初に摩擦を増大させることも少なくありません。ペアプログラミングで私たちが議論した課題の一部をさらに増大させる可能性もあります。例えば、私たちが提案した重要な要素の1つは、脆弱性を示すことですが、これは特に、過小代表グループのチームメンバーにとって困難です。
ハーバード・ビジネス・レビューの見出しを考えてみましょう：「多様なチームは居心地が悪く感じる - そして、それがパフォーマンスを向上させる理由です」。著者は、「同質的なチームは簡単に見える - しかし、簡単であることはパフォーマンスにとって悪影響です。（…）この考え方は多くの人々の直感に反しています」という点を強調しています。説明するために、彼らは流暢性ヒューリスティックと呼ばれる認知バイアスを指摘しています。「私たちはより簡単に処理できる情報を好み、それをより真実である、あるいはより美しいと判断します。」
このバイアスは、私たちにシンプルさを求めるようにさせます。これはソフトウェア開発における多くの状況で非常に役立ちますが、ペアプログラミングの場合には役に立たないと考えています。ペアプログラミングは難しいと感じますが、それが必ずしもチームにとって良くないという意味ではありません。そして最も重要なことは、難しいままである必要がないということです。この講演で、Pia Nilssonは、Spotifyの彼女のチームが、ペアプログラミングなどのプラクティス導入によって当初発生した不快な摩擦を克服するために取った対策について説明しています。とりわけ、彼女はフィードバック文化、非暴力コミュニケーション、心理的安全性、謙虚さ、そして目的意識を持つことを挙げています。
ペアプログラミング、エクストリームプログラミング、そしてアジャイルソフトウェア開発全体は、変化を受け入れることに尽きます。アジャイルソフトウェアの実践者は、変化は避けられないことを認識しているので、それに備えたいと考えています。
私たちは、摩擦もまた、非常に効果的で多様なチームになる上では避けられないので、受け入れ、準備すべきだと提案します。「たくさんの衝突を起こして良くなろう」という意味ではありません。私たちが意味するのは、チームが摩擦に対処するために必要なツールを備え、チームがすでに問題を抱えている場合だけでなく、デフォルトでツールボックスに入れておくべきだということです。フィードバックを実践し、チームコミュニケーションを改善し、心理的に安全な環境を作るための対策を講じましょう。
ペアプログラミングは摩擦を生む可能性があるため、避けることが多いと考えていますが、試してみることをお勧めします。意識的に改善可能なスキルとして扱い、それを向上させる努力をすれば、より強靭なチームになるでしょう。
謝辞
このテキストは、Thoughtworks社内のスライドデッキとして始まり、ペアプログラミングの実践に関する知識を共有するためにキュレーションとクラウドソーシングが行われました。このプロセス全体を通して、非常に多くのフィードバックと素晴らしい提案を多くの人々から受けました。貢献してくれたすべての人を挙げるのは困難であり、多くの人名を忘れてしまう可能性があります。そのため、私たちと議論してくれた方、さらなるリソースを指摘してくれた方、元のスライドデッキにコメントを残してくれた方、この記事をレビューしてくれた方、特にThoughtworksの同僚であるすべての方に感謝したいと思います。これはまさに多くの人々の経験を集めたものとなりました。ありがとうございました！
この記事の図面のほとんどを作成してくれたStefanie Grewenig氏に特に感謝いたします。
重要な改訂
2020年1月15日:公開