⚓第4章: ペアプロは導入すべきなのか
高品質かつメンテ可能なソフトウェアを持続的に生み出すために、ペアプログラミング（以下ペアプロ）の実践が重要であることは、私たちの経験から明らかです（『ペアプロのメリット』参照）。しかしながら私たちは、独善的なペアプロや闇雲なペアプロが有害であるとも信じています。ペアプロの効用がどれほど正確なのか、ペアプロのコストがどれほどになるか、どのタスクをペアプロでやるか、これらは一概には言えません。私たちが見出した有用な方法は、ペアプロをチームの「常識的なデフォルト体制」として制定し、そのうえで、何を例外扱いするかについていつでも話し合うことです。
ペアをいつどのように組むかのバランスを見極めるのに有用な例をいくつかご紹介しましょう。
⚓1. 単調なタスク
ある種のコーディング（定義済みのテンプレを用いる作業など）は単調なものになります。この場合もしかするとペア作業は不要でしょうか？そうした作業についてはチーム全体でわかっているから、あるいはとてもわかりやすい作業だから、知識を共有する作業の重要性は低いでしょうか？既に十分確立されたパターンで、しかも過去に成功を収めているので、ライブコードレビュー（書いた端からのコードレビュー）の意義は薄いでしょうか？もし「イエス」であれば、ペア作業は不要なのかもしれません。
しかし機械的に作業をこなしてばかりいると、残念な設計という「コードの臭い」が立ち込める可能性があることも常に気にかけておきましょう。ペアで作業すれば、そうした退屈なコードを正しく抽象化する方法が見つかるかもしれません。「こんなのチョロいから」とばかりに反射神経に任せて作業しているうちに、何かを見落としたり雑なミスをしたりする可能性もありえます。
⚓2. 「自分ひとりになっても本当にやれるだろうか...」
ペア作業は、チーム内のベテランメンバーから比較的短時間で学ぶ機会になるので、駆け出しプログラマーにとって計り知れないメリットがあります。しかしながら、若手プログラマーがペア作業で自信を喪失してしまう可能性がないわけではありません。「自分は誰か後ろで見ててくれないとちゃんとやれないんじゃないか...」というふうに。ペア作業は、若手プログラマーが解決方法などを自力で見つけ出す方法を学ぶ機会を失うことでもあります。
私たちはデバッグやエラー解析によって最終的に優れたプログラマーになれますが、デバッグやエラー解析の最中は絶えずフラストレーションにさらされながら水面下で必死に実験を繰り返します。罠を踏む前に注意を受けるよりも、自分自身が実際に罠を踏む方がよい学びの経験になることもしばしばあります。
対処方法はいくつか考えられます。ひとつは、若手プログラマーにメンターをひとり付けて定期的な作業チェックやある程度のコードレビューができる体制にしたうえで、若手プログラマーにひとりで作業する機会をときどき与えることです。もうひとつは、若手プログラマーを、チーム内のさらに若手のプログラマーと組ませることです。2人の若手は共同でソリューションを見つけられるようになりつつ、ひとりでコーディングするよりも短期間で罠から脱出できるようになります。最後の方法は、あなたがチーム内で経験豊富なプログラマーであれば、若手とのペア作業のほとんどの時間でナビを担当することです。ドライバーを担当する若手には考える余裕をきちんと与えること。2人揃って壁にぶち当たるまでは、先回りしてあれこれ注意するよりも、少し時間をかけてもらえば解決することもあります。
⚓3. コードレビューがあればペア作業は不要か
ペアプロの利点は、その場で問題の首根っこを押さえられることだ。自分のすぐ横に座っているレビュアーを無視することは不可能なのだから。
Jeff Atwood: Pair Programming vs. Code Reviews
「コードレビューが行われていればペアプロなど無用」と考える人はたくさんいます。しかし私たちは、コードレビューとペアプロを同列に並べて二者択一と考えることについては反対します。
第1に、コードレビューは雑に済まされることもあれば、形ばかりのレビューで終わることもあるのが普通です。たとえば、コーダーとレビュアーが心の中でこっそりお互いを当てにしすぎていたらどうなるでしょうか。コーダーは「レビュアーが何とかしてくれるだろう」とばかりに、ちょっとした決定や改良を先延ばしにしてしまうかもしれません。レビュアーはレビュアーで、コーダーが手抜きしていないことを当てにして、コードをまともに見ずにコーダーの作業を信頼してしまうかもしれません。それから「サンクコストの誤謬」も影響します。一度精査したことをまたやり直すのはチームで嫌がられるのが普通だからです。
参考: 埋没費用（サンクコスト）の誤謬 – とまらない公共事業のナゾ – sawacom.net
第2に、コードレビューはチームの作業フローを中断します。レビュータスクを引き受ければ、レビュアー自身ではない他の誰かのために脳内コンテキストの切り替えを求められます。つまりコードレビューを引き受ければ引き受けるほど、レビュアーの作業はずたずたになります。小さな変更を継続的に統合（CI）しようとすれば、レビュアーのコンテキスト切り替えは必然的に頻繁になります。やがてレビュアーが統合やデプロイのボトルネックになり、残り時間が迫ってくると、やはり不十分なレビューで終わってしまう可能性があります。
trunkベース開発を実践するチームのパフォーマンスについて詳しくは2017 edition of the "State of Devops Report"をご覧ください。
（抜粋）昨年確認された、より高品質なソフトウェアをデリバリー（納品）するパフォーマンスに貢献する開発手法は次のとおり:「コードを毎日trunkにマージする」「ブランチやforkのライフサイクルを極めて短命（1日以内）に抑える」「アクティブなブランチを3本未満に抑える」
参考: DevOps 技術: トランクベース開発 | Google Cloud
継続的インテグレーション（CI）（および継続的デリバリー）においては、ごく小さな変更を頻繁にデリバリーすることでリスクを軽減することを目指します。CIは元々、trunkベース開発を意味します。trunkベース開発でコードレビューが遅延すると、コードの変更はレビューの質にかかわらずmasterブランチに押し込まれてしまい、レビューの効果がさらに落ちてしまいます。つまり、「ペアプロ」と「CI」を合わせ技にすればお互いの長所を引き出せるのです。
チームで効果的なアプローチのひとつが「ペア作業をデフォルトにする」であることは既にご説明しましたが、例外として、ペア作業なしでproductionコードを変更しなければならない場合はプルリクエストとコードレビューを用いましょう。この場合、CIを引き続きうまく回すために、プルリクが長期間にわたって残らないようチームが注意深く監視すべきです。
⚓第5章: それでもペアプロする理由
本記事ではペアプロのメリットについてはもちろん、ペアプロの困難な点についてもさらに事細かに説明いたしました。ペア作業を正しく進めるには、いつもと違うさまざまなスキルを求められますし、チームの他の作業に影響する可能性もあります。ペアプロでわざわざ苦労を背負い込む価値は本当にあるのでしょうか？
チームがペアプロで成功を収めて幸せになるには、ペアプロの困難を克服できるあらゆるスキルを養うべくチームで精進しなければなりません。「集中力」「タスク編成」「タイムマネージメント」「コミュニケーション」「フィードバックをスムーズに受け渡す」「相手の気持を汲む」「自分の弱みを隠さない」、これらはいずれもチームを実際にうまく回し高効率かつ力を合わせられるうえで極めて有用なスキルです。ペア作業は、チーム全員が力を合わせてスキルを高められるチャンスなのです。
ペア作業は、個人やチームに秘められた学びのスキルを解き放つものである。
Dave Farley: Taking Back Software Engineering
今日よく語られる、効率の高いチーム編成を成功させるうえで有用なもうひとつのファクターといえば、やはり「多様性」でしょう。チームのパフォーマンスは「視点の多様性」「ジェンダーの多様性」「経歴の多様性」「スキルの多様性」によって向上することは証明されていますが、最初のうちはチーム内で小競り合いが増えることもしばしばあります。場合によっては前述したペアプロの困難がさらに増すかもしれません。たとえば私たちが勧める「自分の弱みを隠さない」ことは重要なポイントのひとつですが、特にチーム内で過小評価されているメンバーにとっては肩身の狭い作業になります。
ハーバード・ビジネス・レビューの記事『多様性に伴う「居心地の悪さ」こそチームの成果を高める 』について考えてみましょう。記事の著者は「多くの人の直観に反して、同質なチームは居心地がよい代わりにパフォーマンスに悪影響を及ぼす」と指摘し、その原因を「フルーエンシー・ヒューリスティック」と呼ばれる認知バイアス（偏見）に求めています。「人間は自分が楽に処理できる情報を好み、しかもそうした情報の方が正しく、美しいとすら感じる」のです。
このバイアスが人間にあるために、ソフトウェア開発の多くの場面で通用する「単純な方法」を強く求めるようになります。しかし私たちは、ペアプロに単純な方法は通用しないと考えます。ペア作業は確かに骨が折れますが、だからといってチームで役に立たないわけではありません。何より最も重要なのは「しんどい作業をいつまでも続ける必要はない」という点です。SpotifyのPia Nilssonは以下の動画で、自分のチームにペアプロなどの手法を導入したことで生じた不快な軋轢を克服したときの対策について説明しています。とりわけ「気軽にフィードバックしあえるのが当たり前の文化」「暴力と無縁なコミュニケーション」「心理的安全性」「謙虚な態度」「目的意識を持つこと」についても言及しています。
ペアプロ、XP（エクストリームプログラミング）、アジャイルソフトウェア開発、これらはいずれも必ず変化を伴います。アジャイルを実践する人々は、変化が避けがたいからこそ、変化に備えることを望みます。
もうひとつ私たちが受け入れを覚悟し、備えておくべきものとして、チーム内の「軋轢」を挙げておきたいと思います。軋轢もまた、高効率かつ多様性に満ちたチームづくりにおいて避けがたいものだからです。ただし軋轢を受け入れるといっても「チーム内でゴタゴタがたくさん起きるほどチームはよくなる」という意味ではありません。チーム内での軋轢をうまく扱うのに必要なツールをチームで準備し、チーム内で既に起きている問題に限らずデフォルトで用いる常備薬として設置すべきだと申し上げているのです。フィードバックを実践し、チーム内コミュニケーションを改善し、心理的安全性を保証する環境を作り上げましょう。
私たちは、ペアプロが避けられがちな理由は「軋轢を引き起こしたくない」からだと信じています。しかし、どうかペアプロにチャンスを与えてやってください。みなさんがペアプロを自分で改善できるスキルとして扱い、よいペアプロの実践に力を注げば、チームの弾力性はさらに高まることでしょう。
⚓謝辞
本記事は、当初ThoughtWorks社内向けSlide Deckとして作成し、私たちがクラウドソーシングで開催したペアプロの実践に関する知識を共有した成果です。制作中に多くの方から数々のご意見や素晴らしい助言をいただき、貢献者リストにすべて名前を載せるのが難しいほどだったため、おそらく大半の方の名前を思い出せなくなるかもしれません。そうしたわけで、私たちはすべての人々に深く感謝を表明したいと思います。特に、私たちと議論を重ね、関連資料の情報を提供いただき、元のSlide Deckにコメントをくださり、本記事をレビューしてくださったThoughtWorksの同僚の皆さまには大変お世話になりました。おかげさまで、多くの人々のペアプロ実践経験が本記事で結晶化されました。みなさん本当にありがとうございます！
特に、本記事の挿絵のほとんどを制作してくださったStefanie Grewenigに深く感謝いたします。
⚓主な原文更新履歴
- 2020/01/15: 記事公開