ペアプログラミングは、二人が同じコードを眺めるだけの時間ではありません。役割を分け、短い間隔で交代しながら考えを共有する開発方法です。
二つの役割
| 役割 | 主な仕事 |
|---|---|
| ドライバー | 今必要なコードを入力し、直近の一手に集中する |
| ナビゲーター | 全体の方向、仕様、見落とし、次の一手を考える |
ナビゲーターが命令し、ドライバーが作業する上下関係ではありません。二人で同じ問題を異なる距離から見ます。
声に出す内容
ドライバーは、操作を実況するのではなく意図を話します。
この条件を先に返して、正常系の入れ子を浅くします。
ナビゲーターは、答えを奪わず確認します。
nullの場合もこの関数へ来ますか？
この名前から戻り値の単位は分かりますか？
「なぜそうするか」が言葉になるため、一人では気づかなかった前提が見えます。
交代のルール
10〜20分ほどで役割を交代します。難しい場面だけ詳しい人がずっと入力すると、もう一人が観客になります。
交代時には次を共有します。
- 今どこまで分かったか
- 次に試すこと
- 保留している疑問
- テストの状態
うまくいかない兆候
- 一人だけが話し続ける
- ドライバーが指示どおり入力するだけ
- 分からなくても進行を止められない
- 速さを競っている
- 休憩せず長時間続ける
ペア作業は集中力を使います。時間を区切り、一人で調べる時間も組み合わせます。
一人でも使える考え方
AIと作業する時にも役割分担を応用できます。自分がドライバーなら、AIには設計上の見落としやテスト観点を尋ねます。AIに実装案を出させる時は、自分がナビゲーターとして目的と制約を確認します。
ケーススタディ：入力検証を二人で直す
会員登録フォームで、空白だけの名前が登録できる不具合を直す場面を考えます。開始時に二人で「前後の空白を除いた名前が空なら送信せず、理由を画面に出す」を完了条件にします。ドライバーは現在の送信処理とテストを開き、ナビゲーターは入力が画面、検証関数、APIのどこを通るかを追います。
最初の一手は、いきなり条件式を書くことではありません。既存テストへ空文字、空白だけ、前後に空白がある正常名を追加します。ドライバーがテストを書いている間、ナビゲーターは「全角空白は仕様に含めるか」「サーバ側にも同じ制約があるか」を確認します。テストが意図した理由で失敗したら最小の修正を入れ、成功後に役割を交代します。新しいドライバーが実装を説明し直せれば、知識も片側に偏っていません。
悪い進め方は、経験者がキーボードを握り続け、「ここを直せばよい」と完成コードを口頭で渡すことです。短時間で直っても、もう一人は入力値の流れもテスト理由も説明できません。良い進め方は、ナビゲーターが答えではなく観測点を示し、ドライバー自身が差分を選ぶことです。
ペアの状態を観測する
終了時にはコード品質だけでなく共同作業も振り返ります。交代回数、二人が提案した仮説の数、保留した疑問、テストを失敗から成功まで確認したかを短く記録します。片方しか変更理由を説明できない、交代時に次の一手を共有できない、ナビゲーターの発言が命令だけになる場合は失敗条件です。次回は交代間隔を短くする、五分だけ個別に調べてから再集合するなど、観測した兆候に合わせて運用を変えます。
また、難易度差が大きいペアでは、初心者がドライバーになる時間を意図的に確保します。ただし放置はしません。ナビゲーターは「今の値をどこで確認できるか」「このテストが通れば何を証明できるか」と質問し、考える範囲を狭めます。沈黙が続くこと自体を失敗と決めつけず、考えている沈黙か、参加できない沈黙かを本人に確認することが大切です。
よくある誤解と役割の修正
「詳しい人がナビゲーターなら、正解を順番に指示すればよい」という理解では、ドライバーが音声入力装置になります。ナビゲーターの仕事は完成形を読み上げることではなく、仕様とのずれ、次に壊れそうな境界、検証していない前提を少し先から示すことです。一方、ドライバーも黙って入力せず、「いまは空白判定を関数へ移し、画面とAPIで同じ規則を呼べるようにする」と意図を共有します。
「常に二人なら品質が二倍になる」わけでもありません。名前変更の反映、機械的な整形、既知の設定変更は一人で進め、設計の分岐、未知の障害、重要な権限処理で再び組む方が集中力を使えます。ペアにする単位は勤務時間ではなく、二つの視点が同時に必要な判断です。
「交代はタイマーが鳴った瞬間でなければならない」も誤解です。失敗中のテストや未保存の編集を置き去りにせず、現在地を説明できる区切りで交代します。ただし、難所を理由に経験者が延長し続けるなら役割分担は崩れています。
動作確認：二人とも変更を説明できるか
セッション後、コードを触っていなかった側が、変更の目的、採用しなかった案、追加したテスト、残った不確実性を説明します。説明が途切れた場所は共有できていない判断です。次に役割を入れ替え、同種の小さな修正を行います。片方だけが速い状態ではなく、どちらがドライバーでも同じ完了条件へ到達できるかを見ます。
確認表には、交代時刻より「誰が何を判断したか」を残します。ナビゲーターが早い段階で境界値を指摘できたか、ドライバーが提案を鵜呑みにせずテストで確かめたか、保留事項をIssueへ移したかを振り返ります。良いペア作業の成果は差分だけでなく、変更理由を二人が持ち帰れることです。
まとめ
ペアプログラミングの役割：ドライバーとナビゲーターで大切なのは、用語を単独で暗記することではありません。期待、観測、差分、仮説、操作、結果を順に残し、テーマに合う証拠で判断します。小さく確認し、再現できる説明を残すことが、修正と学習の両方を次へつなげます。
参考リソース
ペアを解消する判断も必要です。単純作業へ移った、調査対象が二つに分けられる、疲労で会話品質が落ちた場合は、終了時刻と再集合条件を決めて分かれます。反対に、認可、データ移行、公開障害のように一つの誤判断が大きな影響を持つ場面では、実装速度が落ちても二人の確認を維持します。作業後の振り返りでは相手の性格ではなく、交代、質問、テスト、決定記録という変えられる行動を扱います。
ケース別の組み方
未知のライブラリを調べる場面では、ドライバーが最小の試作を動かし、ナビゲーターが公式資料の前提、廃止されたAPI、既存コードへの影響を確認します。二人とも同時に検索すると視点が重なるため、十五分で得た事実を合流します。設計判断では、一人が案を描き、もう一人が利用者、保守、テストの反例を出します。障害対応では操作担当と記録担当を分け、未確認のコマンドを勢いで実行しないようにします。
リモートでは画面共有だけでなく、編集権限の移動、音声遅延、休憩を明示します。ナビゲーターがカーソルを勝手に動かすとドライバーの思考を奪うため、指摘箇所は行番号や関数名で伝えます。セッション終了時には差分を小さくコミットし、次回の開始点、保留中の仕様、実行したテストを残します。
初学者同士なら、開始前に「分からないと言ってよい」「検索に五分使ったら共有する」「答えを知っていても質問で前提を確かめる」を合意します。経験者同士なら、暗黙の略語や高速な意思決定で片側が置き去りになっていないか確認します。ペアの目的は常時合意ではなく、異論をコードへ入る前に安全に表へ出すことです。
