第3章: ペアプロの難しい点
ペアプログラミング（以下ペアプロ）には実に多くのメリットがありますが、ペアプロには訓練が必要ですし、最初からペアプロがうまく回るとも限りません。チームがペアプロで苦労しがちな点のリストと、克服するための助言をいくつかご紹介します。実際にこうした困難に出くわした場合は、ペアプロの数々のメリットと、自分たちがペアプロする理由を頭に思い浮かべてください。ペアプロを軌道修正するには、自分たちが実践で何を達成しようとしているのかを意識しておくことが重要です。
![⚓]()
1. ペア作業で消耗する問題
ひとりで作業するのであれば、いつでも好きな時間に休憩できますし、必要ならば少々現実から逃避してうさばらしもできるでしょう。ペア作業では集中の維持を強いられますし、時間が延長される可能性もあります。また、相手の作業のリズムや考え方の癖について共通点を見い出して合わせていくことも求められます。集中時間が増えることはペア作業のメリットでもありますが、その分かなりエネルギーも必要となり、消耗します。
対策
この問題に取り組むうえで重要なのは、十分な休憩を挟むことです。休憩を定期的に入れるのを忘れていたら、アラームで休憩時間を設定してみましょう（1時間あたり10分など）。あるいはポモドーロのようなタイムマネージメント手法も使ってみましょう。昼食を抜いてはいけません。休憩時には画面から離れてしっかり休憩を取ってください。休憩は、ペアプロと関係なく重要であり、生産性を高めてくれるものです。
消耗を防ぐうえでもうひとつ重要なのは、ペア作業を1日8時間もやらないことです。どんなに長くても1日あたり6時間までにします。ドライバーとナビを定期的に交代するのも、消耗を防ぐのに有用です。
![⚓]()
2. 共同作業に集中するのがつらくなる問題
相手と顔を突き合わせて長時間作業するのは相当なことです。相手と絶えずコミュニケーションを交わす必要がありますし、相手の気持を汲むなどの対人スキルも求められます。
「技術」「知識」「スキル」「社交性」「性格」「問題解決のアプローチ」は人によって違いがあるものです。お互いの相性があまりよくないと、出だしからペア組みが厳しくなるかもしれません。そのようなときは変にじたばたせず、お互いがこの経験から学びを得られるように共同作業を改善する時間をしばらく設ける必要があります。
対策
ペアリングセッションの最初の話しかけ方を工夫することで、お互いのスタイルの違いを理解してスタイルのすり合わせを計画する手助けになる可能性があります。初めてセッションを開始するときに「どんなスタイルで共同作業したいですか？」「ペアの組み方について希望はありますか？」という具合に最初に質問します。このとき、あなた自身がどのように作業したいかという希望や、自分がどれだけ効率よくやれるかを意識しつつ、焦って他のアプローチに飛びつかないようにしましょう。やっていくうちに何か発見があるかもしれません。
ペア作業した日の終りには、お互いにひととおりフィードバックしましょう。フィードバックするのが気重に感じられるのであれば、むしろちょっとした「振り返りタイム」だと考えてみましょう。ペアリングセッション中に双方が何を思い、どう感じたかを振り返ります。「気配りはできていたか」「疲れがたまっているか」「これがあったおかげでやりやすかったというものはあるか」「逆にこれのせいでやりにくかったというものはあるか」「キーボード入力の交代頻度は十分だったか」「目標は達成できたか」「次回やってみたいことはあるか」。こうした振り返りは、早いうちにルーチンに組み込んでおくとよいでしょう。そうすることで、何か問題が起きたときに相手にフィードバックする訓練にもなります。
人間関係の衝突や困難（うまく会話できないなど）をうまく扱うのに役立つ、優れたトレーニングや書籍はたくさんあります。
問題点にはチームとして取り組んでください。個人に任せきりにしないこと。たとえば、ペア作業の問題点をどう扱うかを議論するためのセッションを別途開催することで対処する方法も考えられます。このセッションでは、最初にペア作業のメリットを列挙することから始め、自分たちがペア作業で何を得ようとしているのかをはっきりさせます。それが終わったら、各個人がペア作業でどんな困難を感じているかを調査します。これで、グループがどのアクションを改善できるかについて考えられる状態になります。また、チームメンバーのホットボタントリガー（=むかつきポイント）を事前に調べておく方法もあります。「『これをやられたら即嫌になる』ことはありますか？」という具合です。
![⚓]()
3. ミーティングが割り込む問題
一日中ミーティングで終わってしまい、その日は何にもできなかったという気持ちになった経験はありますか？おそらく、これはどんなデリバリーチームにでも起きることです。ミーティングは、議論や計画立案、これから作るものについての合意形成には必要ですが、ペア作業の流れを中断するものでもあります。チームがペアプロを実践するときに、ミーティングがあまりに多すぎるとむしろ事態が悪化する可能性もあります。ペアの2人がそれぞれ別の時間にミーティングを抱えると、中断の回数が増えてしまいます。
対策
この問題へのアプローチのひとつは、ミーティングの開催を制限するタイムスロットを設けることです。たとえば「ペア作業のコアタイムにはミーティングは入れられないようにする」「ミーティングを開催できない時間帯を設ける（”午後はミーティングを開催してはいけない” など）」といった方法が考えられます。
ミーティングの長さとトータル時間についても再考する価値があります。「どうしても外せないミーティングはどれなのか」「ミーティングの参加者はどんな目標を持っているのか」「目標の質を改善するにはどうすればよいか」などです。改善には、ミーティングの下準備やファシリテーション（議事進行）を適切に行う、明快なアジェンダを用意するといった方法が考えられます。
しかし「ミーティングはいつ入ってもおかしくない」こともまた確かです。ミーティングにペアが対処するにはどうすればよいでしょうか。ペア作業では、ペアセッションの開始時にカレンダーを2人でチェックし、ペア作業を開始する時間が十分確保されていることを確認しましょう。ミーティングがぶつかっているのであれば、ペアの2人で出席することを検討しましょう。ペア作業のコアタイム中は、チームメンバーをミーティングから遠ざけるよう、プロダクトオーナーや、ペアを組んでない他のチームメンバーにお願いしましょう。
![⚓]()
4. スキル差が大きい問題
ペアを組む2人の間に、あるトピックについてレベルの差があると、お互いがどの程度貢献できるかについて見積もりを誤ってしまったり、作業のペースが違いすぎて不満がたまってしまうことがよくあります。
対策
- そのトピックについて経験豊富なペアの場合
- そのペアが持つ知識が万全だという前提を置かないこと。おそらく、「今の作業をこうやって進めている理由」を明確に説明することを義務付けることで、新たな洞察につながるでしょう。（たとえ自明と思えても）作業の進め方や、その進め方を選んだ理由をお互いに質問し合うことで、話し合いも有意義になり、よりよいソリューションにつながります。
- そのトピックについて経験が浅いペアの場合
- そのペアが問題解決に貢献できるはずがないという前提を置かないこと。自分が目隠ししたまま立ち往生している可能性もあること、そして別の視点によってよりよいソリューションが得られる可能性もあることを思い出しましょう。コンセプトをはっきり説明することを義務付けることは、自分の理解が本物であるかどうかをテストし、改めて考え抜くまたとない機会となることも思い出しましょう。
初心者からエキスパートになるまでの学習プロセスをうまく回す方法を理解するには、学習のステージは人によってさまざまであることを知っておくことも有用です。Dan Northは以下の「Patterns of Effective Teams」というトークで、この点を実に的確に説明しています。Danはこのトークで、学習におけるさまざまなステージや、ペア作業の文脈においてステージの組み合わせが何を意味するのかを理解するために、スキル獲得のドレイファスモデルを紹介しています。
5. ![⚓]()
力関係の問題
力関係（power dynamics）は、おそらく本記事の「難しい点」リストの中でも相当厄介な問題です。ペアプロが行われるのは、上下関係のない世界ではありません。目に見える公式な上下関係（上司と部下など）もあれば、水面下にある非公式の上下関係もあります。水面下の上下関係には以下のようなものがあります。
- 「若手」と「シニア」
- 「男性以外」と「男性」
- 「転職組」と「CS学位持ち」
- 「有色人種」と「白色人種」
これはほんの一例です。力関係は固定ではなく状況によって変動するものですし、部門の壁をも超えます。ペアを組むときには、こうしたさまざまな力関係が働いたり覆いかぶさってきたりします。力関係の差がペア作業にどんな影響をもたらすかを理解するために、いくつか例をご紹介します。
- ペアの1人がペア作業のセッションを独り占めする（キーボードを相手に渡さない、相手に余裕を与えない）
- ペアの1人が教える側にばかり回り、先生ぶるのをやめようとしない
- ペアの1人が相手に耳を傾けようともせず、相手からのサジェスチョンも冷たく却下する
こうしたシチュエーションをいちがいに上下関係のせいにするのは少々微妙です。単に「この人とはやっていけない」と思っているだけというのもよくあることです。しかし、ペアを組む2人の力関係の差が問題の背後に影を落としていることも、これまたよくあるのです。
Sarah Meiは以下の一連のツイートでこの話題をうまく取り上げています。また、アジャイルにおける力関係のより一般的な問題についても以下の動画で触れています。
For many years, I was a pair programming evangelist. Between that & my consulting work, I've met lots of people who tried pair programming and hated it. Some of them had paired for months, with different people, on different schedules, & still couldn't find a modality they liked.
— Sarah Mei (@sarahmei) April 30, 2018
アジャイルで目につきにくい問題を突き止めるために、異種混合チームで揉める理由を見ていきたいと思います。目に付きやすい問題の裏に何が潜んでいるかを調べてみましょう。
まずは「メンバーのほとんどがペアをうまく組めない」問題から。
私は長年ペアプロの伝道師として普及に努めていた時期がありました。当時からコンサル時代まで、ペアプロを試した挙げ句すっかり嫌気がさしてしまった人々を山ほど見てきました。中には、数か月間さまざまな相手とさまざまなスケジュールでペアを組んでみたにもかかわらず、好みに合う様式をついに見つけられなかった人々もいます。
Power dynamics in pairing is a subject that rarely comes up, at either the macro (community discussion) or micro (team discussion) levels. First let's talk about what a power dynamic is, and then we can look at how it manifests in a pair.
— Sarah Mei (@sarahmei) April 30, 2018
皆、性別も人種もさまざまでしたし、内向的な人もいればそうでない人もいました。これらの人々に共通していたものが何だったのか、私も長年わからずにいましたが、最近になってやっと気が付きました。
どの人も、ペア内部の（1つまたは複数の）「力関係」で風下に立たされている時間が長かったのです。
ペア作業における力関係は、マクロ（コミュニティでの議論）レベルでもミクロ（チーム内での議論）レベルでもめったに取り上げられません。私から、まず力関係とは何かについて説明し、次に力関係がペアの間でどのように顕在化するかについて説明します。
対策
この問題に取り組むには、力関係において上位の人物が『自分が（図らずも）力関係で相手より上の立場にいる』ことを正面から認識し、自覚することから始めます。それができて初めて、ペアの相手にどんな圧力がかかっていたか、力関係が2人にどの程度悪影響を及ぼしていたかを率直に振り返る準備が整います。そのときの自分の立ち位置や状況を思い返し、「いびつな力関係を是正するために、自分に何ができるだろうか」と考えてみましょう。
こうしたさまざまな力関係を自覚し、振る舞いを正して共同作業を改善する作業は、さまざまな点において反省を求められるため、当人にとってつらいものになることもあります。この問題を抱えている個人やチームを支援するために、「アンチバイアス」トレーニングや「アライアンススキル」などさまざまなトレーニング法が存在します。
![⚓]()
6. ペアで未知の課題に取り組むときの問題
ペア作業のスタイルは、ペアのどちらも解決方法の見当がまったく付かないような大規模なトピックに取り組んでいる場合には、思ったように行かないことがしばしばあります。たとえば「まったく初めての技術を使う必要がある」または「新しいアプローチやパターンを試す必要がある」としましょう。調査や実験をペアで行うことについてはうまくいくこともありますが、どう動くかを見極めるためのアプローチもさまざまですし、資料の読み込みや学習をいつもと違うペースで行うことになるので、ストレスがたまる可能性もあります。
対策
新しい技術を使う場合など、わからないことが多すぎるのであれば、実際に作業を開始する前に、トピックの調査や技術の習得を「スパイク」（XPの手法のひとつ）で行うことを検討しましょう。結果をチームで共有するのをお忘れなく。知識交換セッションを開催して図をチームの部屋の壁に貼る方法なども考えられます。
訳注: スクラムのスパイクとは何ですか？ What is Spike in Scrum? : warren_lynchのblog
このような場合は「ペアプログラミング」ではなく「ペア開発」マインドセットを思い出しましょう。ペア開発では、調査を2人で手分けするのは「あり」です。疑問点をひととおり洗い出してから、共同でその疑問を解決する必要があるでしょう。
7. ![⚓]()
自分の時間が取れなくなる問題
これまでも申し上げたように、絶え間なく会話を続けるのはかなりエネルギーを使う作業です。しかも、多くの人はその日のスループットを達成するための時間も必要とします。特に「内気な人」にとっては切実です（動画参照↓）。
ひとりで作業していれば、必要に応じてトピックを深堀りしたり学んだりする時間はだいたい自然に取れます。しかしペアで作業すると、そうした時間に割り込まれたような気持ちになることもあります。必要なときにひとりの時間や学習時間を確保するにはどうすればよいでしょうか。
対策
繰り返しますが、ペア作業を1日8時間もぶっ通しでやってはいけません。コーディング用のコアタイムについてチームで合意を取り、どんなに多くても1日6時間を上限としましょう。自習のための時間も数時間ほど確保しておきたいでしょう。
問題にアプローチするためのまとまった知識がこのペアに欠けていると感じられたら、資料を手分けして読んだ後で共有し、それから実装を続けましょう。
![⚓]()
8. ローテーションでの頭の切り替え問題
知識の共有はペア作業のメリットのひとつであり、ペアをローテーションするとさらに効果が高まります。しかしながら、ローテーションを頻繁にやりすぎると、コンテキスト（つまり頭）の切り替えも頻繁になってしまいます。
対策
「ローテーションの頻度」や「新しいパートナーとペアを組む頻度」については、ストーリーのコンテキストを見失わず、正しい方法で貢献できる落とし所を見つけましょう。「ローテーションのためのローテーション」にしないこと。あるコンテキストを共有することが本当に重要かどうか、そしてコンテキストを共有する理由を今一度考え、そのうえでコンテキストを効率よく共有できる時間を確保しましょう。
9. ![⚓]()
ペア作業では「弱みを隠さない」ことが求められる
ペアを組むときは弱みを見せる1ことが求められる。弱みを見せるとは、自分がわかっていることも、わかっていないことも、ガードを下げて洗いざらいさらけ出すことだ。この作業はしんどい。プログラマーは一般に「頭がキレる」、それも「めちゃめちゃ頭がキレる」と思われているし、普通の人々はプログラマーの仕事ぶりを目にして「自分には絶対無理だわ」とため息をつく。プログラマーはそれを見て、ちょっぴり自分が特別な人間だという気持ちが芽生え、その気持がプライドを生み、そしてそのプライドが「弱みを隠そうとする態度」を生み出す。
『The Shame of Pair Programming』Hom Howlett
ペアを組んでいるときに「自分はここがわからない」と率直に話すのを強くためらったり、決定を下すときに不安に駆られたりすることがあります。特に「10倍スゴいエンジニア（10x engineer）」伝説が定期的に生まれる業界や、「どんなプログラミング言語を使っているか」「5年前にどんな設計上の決断を下したか」で相手を値踏みする世界ではなおさらです。
自分のわからない点を率直に述べる行為は、ほとんどの文化圏で何かと弱点と結び付けられがちですし、自分の強さを誇示する行為も普通によくあることです。しかしBrené Brownという研究者は「自分の弱みを認める行為は、実際にはイノベーションや変革において極めて重要な要素である」と講演や書籍で繰り返し述べています。
イノベーション、創造性、変革は、自分の弱みをさらけ出したところからこそ生み出されるのです。
Brené Brown（動画↓）
対策
ガードを下げて自分の弱みをさらけ出すには勇気が必要です。そして、みんなが安心して自分の弱みを率直に話せる雰囲気を作り出すことも求められます。繰り返しますが、これはお互いを信頼できるチームを作れるかどうかにすべてかかっています（1on1やフィードバックの機会を定期的に設ける、気後れせずに質問できる文化づくりなど）。
チームの中で他の人よりも権威の高い人であれば、自分の弱みを見せることはそれほど難しくありませんし、リスクもさほどではありません。権威は（既にチーム内で尊敬を集めていれば）自然に備わることもあれば、（テックリードなどの肩書があれば）肩書が物を言うこともあります。つまり、他の人より権威のある人が率先して「わからないことを率直に話す」役割を引き受けてモデルとなることが重要です。それによって「ここはわかる」「ここがわからない」と当たり前に話せるようにし、他のメンバーが自分のわからない点を安心して話せる空気を作りましょう。
![⚓]()
10. 経営陣や同僚の説得に手間取る問題
ペアプロを推進しようとすると、多くの場合、チームの毎日のルーチンにペア作業の時間を組み入れることを経営陣や同僚に理解してもらうために駆けずり回らなければならなくなります。
対策
ペアプロの効能を他の人に納得してもらえるシンプルなレシピは、さすがに存在しません。ただし、この場合に常にキーポイントとなるのは、最初に「ペアプロの効能についてプレゼンする時間を確保する」ことと「全員が同じ理解を共有できるようにする（例: 本記事を読んでもらう
）」ことです。それが終わってから、ペアをひと組作って試しにペアプロを行ってその体験を他の人と共有するか、あるいは「次回の2スプリントはペアプロをデフォルトとしてみる」というようにチームでの実験を提案します。結果へのフィードバックや振り返りの場を必ず設け、「ペアプロでうまく行った点」「ペアプロで手こずった点」を共有しましょう。
もちろん最終的に実践を頭ごなしに強要するわけにはいきませんし、万人に有効とも限りません。やってはみたもののチームにペアが1組できただけだった、という結果に終わるかもしれません。私たちの経験から申し上げれば、説得するうえで最も効くのは「実践している様子を定期的に他の人に見せる」ことと「チームメンバーにペア作業のメリットや楽しさを体験してもらう」ことです。
説得中によく受ける質問のトップに挙げられるのが「実践が経済的に見合うかどうか」です。「ペアプロしたらコストが倍になるだけでは？」「品質向上やチームのメリットは最終的にそのコストに見合うのか？」といった具合です。これについてはいくつか研究がありますが、その中でも最もよく知られている『The Costs and Benefits of Pair Programming（PDF）』を引用して、ペアプロに価値があるというエビデンスを示しましょう。ただし私たちは、ペア作業が効果的であることを「科学的に証明」しようとする試みに対しては慎重な立場を取っています。ソフトウェア開発は変化と不確定性に満ちたプロセスであり、コードの裏側には比較や測定（分析、試験、品質など）の困難な知見がたくさん潜んでいます。ペア作業に誠実に反対する人々は、開発の生産性の高さを証明するべくセットアップされた再現可能な「科学的」実験のどこかに穴が空いていないかを常に探しています。結局、ペアプロの効果は「自分の身をもって示す」必要があります。ペアプロを実践するには、自分たちの環境でやってみるしかないのです。
訳注
参考: DeepL翻訳
deepl.comより
- 本文と直接関係ありませんが、今話題のDeepLでもこれは難しいだろうと思われるパラグラフを機械翻訳させてみました↑。 ↩