ペアプログラミング

ペアプログラミングとは

ペアプログラミング (Pair Programming) は、2 人の開発者が 1 台の PC で協力してコードを書く開発手法である。エクストリームプログラミング (XP) のプラクティスの 1 つで、1 人がコードを書き (ドライバー)、もう 1 人が設計やレビューを行う (ナビゲーター)。

ドライバーとナビゲーター

ドライバーがキーボードを操作してコードを書き、ナビゲーターが設計を考えたりバグを指摘したりして全体を俯瞰する。15〜30 分ごとに役割を交代するのが一般的だ。

役割を分けるのは、書く作業と考える作業で注意の向き先が違うからだ。ドライバーは目の前の 1 行の構文や変数名に注意を取られ、全体の設計や抜けている条件が見えにくくなる。ナビゲーターはその負荷を負わないぶん俯瞰に集中できる。交代を挟むのは、片方だけがキーボードを持ち続けると、もう片方が受け身になって指摘が出なくなるためだ。

スタイルには、基本のドライバー/ナビゲーター方式のほか、テストと実装を交互に書く Ping-Pong (TDD 向き)、ナビゲーターが指示しドライバーが実装する Strong-Style (メンタリング向き) がある。Ping-Pong は片方が失敗するテストを書き、もう片方がそれを通す実装を書いて役割を入れ替える形で、テスト駆動開発のリズムがそのまま交代の区切りになる。Strong-Style は、思いついた側はキーボードを触らず必ず相手の手を通して入力させるという制約で、知識のある側がドライバーを務めて相手が見ているだけになる状態を避ける狙いがある。

メリットとデメリット

効果の源は、レビューの時差がゼロになることにある。コードレビューを後工程で回すと、指摘が届くのは書いた本人が別の作業に移った後で、差分もまとまって大きい。ペアなら誤りは書かれた瞬間に指摘され、直す対象は数行で、なぜそう書いたかの文脈も本人の頭に残っている。設計の分岐点も、その場で 2 人が合意してから進むため、後で設計ごとやり直す手戻りが減る。

2 人が同じコードに関わることで知識が共有され、その箇所を触れる人が 1 人だけという状態を避けられる (バス係数の改善)。ベテランとペアを組めば、コードの読み方や不具合の切り分け手順といった文書に残りにくい判断が、手元の作業を通して伝わる。

一方、同じ機能に 2 人が張り付くため、人時では単独作業の 2 倍を投じることになる。ただし単独作業の側にはレビュー工程とレビュー待ちの時間が別に乗るので、工程全体で見た差は単純な 2 倍にはならない。判断の目安は、指摘と修正の往復が多く発生するタスクかどうかだ。複雑な設計判断、原因の見えないバグ調査、新メンバーのオンボーディングは往復が多いため向く。仕様が決まりきった定型実装では 2 人目に指摘する余地がなく、コストに見合わない。

落とし穴もある。ナビゲーターが黙って画面を見ているだけの状態になると、コストだけが 2 倍になって効果は消える。考えていることを声に出す、時間で交代する、詰まったら役割を替えるという運用が前提になる。会話を続ける負荷は高いので 1 日 2〜4 時間程度にとどめ、ペアの組み合わせを固定せずローテーションする。リモートでは、画面を映すだけでなく相手の環境を直接編集できるツール (Visual Studio Live Share、Tuple など。いずれも 2026 年 8 月時点で提供中) を使うと、交代のたびに操作を口頭で伝える手間がなくなる。

モブプログラミング

ペアプログラミングの拡張で、チーム全員 (3〜5 人) が 1 台の PC で作業する。1 人がドライバー、残り全員がナビゲーターを務め、数分単位でドライバーを回す。狙いは知識共有そのものより、判断に必要な人が全員その場にいる状態を作ることにある。仕様の確認や設計の合意を後から取りに行く待ち時間が消えるため、決めごとの多い立ち上げ期や、影響範囲が読めない改修で効く。逆に、人数と時間の積がそのままコストになるので、作業を分割して各自が並行して進められる局面では割に合わない。