ペアプログラミング

英語名 Pair Programming
読み方 ペア プログラミング
難易度
所要時間 1セッション1〜2時間
提唱者 ケント・ベック(XP: エクストリームプログラミング)
目次

ひとことで言うと
#

2人で1台のパソコンに向かい、リアルタイムにコードを書く開発手法。1人がコードを書く「ドライバー」、もう1人が全体を見て指示・レビューする「ナビゲーター」の役割を交互に担当する。

押さえておきたい用語
#

押さえておきたい用語
ドライバー
実際にキーボードを操作しコードを入力する役割。ナビゲーターの指示や議論を反映してコードに落とし込む。
ナビゲーター
全体の設計方針を考え、方向性の指示・バグ発見・次のステップ提案を行う役割。常に声に出して議論する。
ピンポンペアリング
TDDと組み合わせたスタイル。一方がテストを書き、もう一方がテストを通す実装を書く。交互に役割を切り替える
リモートペアプロ
VS Code Live ShareやTuple等のツールでリモート環境でペアプログラミングを行う手法。
属人化
特定の人しか知らないコード領域が生まれること。ペアプロは属人化の解消に最も効果的な手段の一つ。

ペアプログラミングの全体像
#

ドライバーとナビゲーターの協働モデル
ドライバーキーボードを操作しコードを書く考えを声に出しながら実装15〜30分で交代ナビゲーター設計方針を考え指示を出すバグ発見・改善提案常に対話しながらレビュー成果高品質コード + 知識共有 + 属人化解消対話
ペアプロセッションの進め方
1
タスク選定
複雑な問題や重要な設計を選ぶ
2
役割分担
ドライバーとナビゲーターを決定
3
対話+実装
声に出しながらコーディング
4
振り返り
学びと改善点を共有

こんな悩みに効く
#

  • 難しい問題に1人で何時間も悩んで進まない
  • 新メンバーが既存コードを理解するのに時間がかかる
  • 特定の人しか知らないコード領域(属人化)が多い

基本の使い方
#

ステップ1: ペアとタスクを決める

取り組むタスクと相手を選ぶ

  • 複雑な問題、重要な設計判断、新技術の導入時に特に効果的
  • スキルレベルが異なるペアでも、同じレベルのペアでもOK
  • 事前にタスクのゴールを共有する

ポイント: すべてのタスクをペアでやる必要はない。単純作業は1人の方が効率的。

ステップ2: ドライバーとナビゲーターの役割を決める

ドライバーがコードを書き、ナビゲーターが全体を見る

  • ドライバー: キーボードを操作し、コードを書く
  • ナビゲーター: 設計の方向性を考え、バグを見つけ、次のステップを提案する
  • 15〜30分ごとに役割を交代する

ポイント: ナビゲーターは「見ているだけ」ではない。常に考え、声に出して議論する。

ステップ3: コミュニケーションしながら進める

考えていることを声に出しながらコーディングする

  • ドライバー:「ここで例外をキャッチして、ログを出すね」
  • ナビゲーター:「その前にnullチェックが必要じゃない?」
  • 意見が対立したら、小さく試して検証する

ポイント: 沈黙が続くと効果が激減する。常に対話すること。

ステップ4: 振り返りと改善

セッション後に短く振り返る

  • うまくいったこと、改善したいことを共有する
  • ペアの相性やタスクの適性を確認する
  • 次回のペアリングに活かす

ポイント: 疲れたら休憩する。集中力が切れた状態では効果が出ない。

具体例
#

例1:決済機能のリファクタリングをペアプロで行う

ペア: シニアエンジニア(決済ドメインに詳しい)+ 中堅エンジニア(最近チームに参加)

セッション1(1時間): シニアがナビゲーターとして既存の決済フローを説明しながら、中堅がドライバーとしてコードを読み解く。「この部分は歴史的経緯でこうなっている」「ここが今回の改善ポイント」と対話。

セッション2(1時間): 役割を交代。シニアがドライバーとしてリファクタリングの核心部分を実装。中堅がナビゲーターとして「ここのテスト足りてますか?」とフィードバック。

結果: 1人でやれば3日かかる作業が、2人で1日で完了。中堅エンジニアが決済コードの知識を獲得し、属人化が解消。

例2:新メンバーのオンボーディングをペアプロで加速する

状況: 入社2週目の新メンバーが、既存コードベース(10万行)の理解に苦戦。ドキュメントを読んでいるが実務レベルの理解に至らない。

ペアプロ導入: 週3回 x 2時間、チームの各メンバーとローテーションでペアプロ。

  • Week 1: バグ修正タスクで既存コードの構造を理解
  • Week 2: 小さな機能追加でAPIの設計パターンを学習
  • Week 3: コードレビューの観点を実践的に習得

結果: オンボーディング期間が想定6週間から3週間に短縮。新メンバーのアンケートで「ドキュメントだけの自習と比べて理解度が3倍」との回答。

例3:セキュリティクリティカルなコードの品質を担保する

状況: 金融系APIの認可ロジックを実装。間違いがあれば重大なセキュリティインシデントにつながる。通常のコードレビューだけでは不安。

ペアプロ実施: セキュリティに詳しいシニアとドメインに詳しい中堅がペアで実装。

効果:

  • ナビゲーターが「この権限チェック、管理者APIにも必要では?」と実装中に指摘 → 後工程なら見つからなかったバグをリアルタイムで防止
  • テストケースも2人で網羅的に設計。権限の組み合わせパターンを48ケースカバー
  • コードレビュー時間は通常の1/3に短縮(すでに2人でレビュー済みのため)

結果: セキュリティ監査で指摘事項ゼロ。従来は平均3件の指摘があった領域。

やりがちな失敗パターン
#

  1. ドライバーが独走してナビゲーターが観客になる — ナビゲーターがスマホをいじっている。役割交代の時間を決めてタイマーをセットする。ナビゲーターは常に「次何をする?」を考える
  2. すべてのタスクをペアプロにする — 簡単なバグ修正やドキュメント更新まで2人でやるのは非効率。複雑な問題、重要な設計、知識共有が必要な場面に絞る
  3. スキル差が大きいと「指導」になる — シニアが一方的に教える形になり、ペアプロの対等な関係が崩れる。ジュニアにもドライバーをさせ、ナビゲーションで導く形にする
  4. 休憩を取らずに長時間続ける — ペアプロは集中力を要する。2時間以上連続すると効果が低下。最大2時間、休憩を挟むことを徹底する

まとめ
#

ペアプログラミングは 「2人分のコスト」 ではなく 「1人では得られない品質と知識共有」 を生む投資。すべてのタスクに適用する必要はないが、複雑な問題や重要な設計の場面では非常に有効。まずは週に1〜2回、難しいタスクでペアプロを試してみよう。