---
title: "ペアプログラミングとは？メリット・進め方・ツールと導入判断を実装者向けに解説"
url: "https://www.issoh.co.jp/tech/details/4676/"
published: 2024-12-26
updated: 2026-09-27
categories: ["開発"]
publisher: "株式会社一創"
---

# ペアプログラミングとは？メリット・進め方・ツールと導入判断を実装者向けに解説

ペアプログラミングは2人で1台の環境を共有してコードを書く手法です。導入の相談で必ず出るのが「人件費が2倍になるのでは」という指摘ですが、公開されている検証ではオーバーヘッドは15%程度と見積もられています。この記事では定義と役割分担、効果がどこまで裏付けられているか、1セッションの組み立てとリモート環境、そして向かない場面までを実装目線で整理します。チーム全員で行うモブプログラミングとの違いは[モブプログラミングとは？ペアプログラミングとの違い・メリット・進め方を解説](/tech/details/4677/)で扱っています。

## まとめ：ペアプログラミングの効き方と使いどころ

- **2人で1台のワークステーションを共有する**。Agile Allianceの用語集は「two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair)」と定義し、キーボードを持つ側をdriver、全体の方向づけに集中する側をnavigatorと呼びます。
- **コストは2倍ではない**。同用語集は、体系的なペアリングのオーバーヘッドとして15%という見積もりを挙げています。「プログラミング＝タイピング」と捉えることが、2倍になるという誤解の出どころだとも指摘されています。
- **役割交代は数分ごと、ペアの組み替えは2〜3日ごと**。この2つは別の話で、混同すると「交代が多すぎて進まない」という反応になります。
- **1日6時間まで**。Martin Fowler氏の解説は、ペアリングは消耗する実践だとして休憩の確保と1日あたりの上限を挙げています。

## 定義とドライバー・ナビゲーターの役割

Agile Allianceの用語集はペアプログラミングを「two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair)」と定義しています。キーボードを持つ側が「driver」、プログラミング作業に同じく積極的に関与しながら、より全体の方向づけに集中する側が「navigator」です。

この2つの呼び名は、ペアプログラミングを説明するために後から導入された用語で、用語集は判明している最も古い言及を2000年前後のメーリングリスト投稿だと補足しています。役割名そのものより、**手を動かす人と、先を見る人を分ける**という構造が本体だと考えてください。

### 役割交代は数分、ペアの組み替えは2〜3日

交代には2つの層があり、ここを混同すると運用が破綻します。

| 種類      | 入れ替わるもの          | 目安     | 目的            |
| ------- | ---------------- | ------ | ------------- |
| 役割交代    | driverとnavigator | 数分ごと   | 片方が受け身になるのを防ぐ |
| ペアの組み替え | 組む相手             | 2〜3日ごと | 知識のサイロ化を防ぐ    |

Agile Allianceの用語集は役割について「数分ごとに交代することが期待される」としています。一方でFowler氏の解説が挙げるのは組む相手の入れ替えで、「2〜3日ごとの組み替えが知識の広がりと品質のために不可欠だと考える人もいる」という書き方です。ただし組み替えには**新しい人を立ち上げる時間とコンテキストスイッチのコスト**がかかるとも述べており、機械的に短くすればよいものではありません。

「20分で交代」といった運用ルールを見かけたら、それがどちらの話なのかを確認してください。役割交代を20分に固定すると、ナビゲーター側の集中が切れやすくなります。

## エビデンスで見る効果とコスト

「ペアプログラミング 効果」で調べたときに欲しいのは体感談ではなく検証結果のはずなので、公開されている整理をそのまま示します。

### 15%のオーバーヘッドという見積もり

Agile Allianceの用語集は、Laurie Williams氏の博士論文「The Collaborative Software Process」が**品質の向上と、統計的に有意なコスト増は見られなかったこと**を報告していると紹介しています。一方、メタ分析「The effectiveness of pair programming」は**品質の向上と工期の短縮、ただし多少のコスト増**という結果で、体系的なペアリングのオーバーヘッドとして15%という見積もりが挙げられています。

つまり議論の焦点は「2倍か否か」ではありません。**15%前後の追加コストに対して、欠陥の削減と知識の共有が見合うか**という比較です。用語集は「プログラミングをタイピングと同一視すること」がコスト2倍という誤解の出どころだと指摘しています。

### 実証研究が抱えるサンプルの限界

同じ用語集は、実証研究の多くが**専門的な開発現場ではなく、入手しやすい学生サンプルを用いている**点を認めており、一般化には限界があるとしています。社内提案で数字を使うなら、この限界まで添えるほうが通ります。

自チームで測るなら、レビュー待ちの滞留時間、着手から本番反映までのリードタイム、特定領域を1人しか触れない状態の解消といった前後比較できる指標を置いてください。振り返りの枠組みは[KPTとは？開発チームの振り返りをスプリントで機能させる進め方・ツール連携・判断](/tech/details/15266/)が使えます。

### 効果が出ない条件

用語集が挙げる落とし穴は明確です。**2人とも作業に能動的に関与し続けていなければ効果は現れません**。片方が横で眺めているだけの状態は、コストだけが2人分になります。また、対人関係の問題がある相手に対して**ペアリングを強制することはできない**とも明記されています。制度として全員に義務づける導入は、この点で失敗しやすくなります。

## 1セッションの組み立て

始める前に、対象タスクと完了条件を2人で声に出して確認します。ここが曖昧なままだと、ナビゲーター側が何を見ればよいか分からず、単なる見学になります。

時間の上限も先に決めてください。Fowler氏の解説は、ペアリングは消耗する実践なので休憩のリマインダーが役に立つとしたうえで、**1日あたり最大6時間に制限すること**と**昼休みを飛ばさず、モニターから離れて実際に休むこと**を挙げています。終日ペアで埋める前提の計画は、成果ではなく疲労を生みます。

### リモートでの環境づくり

リモートで組むなら、共有の仕方を先に決めます。Fowler氏の解説が挙げているのは、リモート操作に対応したビデオ会議ツール、`ssh`と`tmux`の組み合わせ、Visual Studio CodeのLive Share拡張です。

環境面では2点が指摘されています。**ビデオをオンにすること**（人はジェスチャーや表情で多くを伝えるため）と、**ノイズキャンセリングヘッドホンを使うこと**です。音声だけで長時間組むと、相手が考えているのか詰まっているのかが分からず、navigator側が口を出しすぎる方向に傾きます。

### ペアの組み合わせ

スキル差がある組み合わせでは、経験者が**ドライバーに考える余地を与える**ことが求められます。答えを先回りして言うと、手を動かしている側は入力係になります。

初心者同士のペアも成立します。Fowler氏の解説は、初心者同士でも一緒に解決策を探し、行き詰まりから抜け出すのが1人より速いとしています。ただし、初心者側が「見られていなければ自分にできたのか」と自信を失う可能性にも触れられているため、**できたことを言語化して返す**時間を最後に取ってください。

## ペアを使うべきでない場面

次の性質を持つ作業は、2人で組む価値が小さくなります。

- **判断が発生しない単純作業**。Fowler氏の解説も、退屈な単純作業なら組む必要はないのではないかと述べています。ただし同時に、そうした作業が頻発すること自体が設計の問題を示す兆候かもしれない、とも指摘されています。
- **一次調査や下書き**。持ち寄って議論する前段は、分担したほうが速く終わります。
- **対人関係に問題がある組み合わせ**。前述のとおり、強制しても機能しません。
- **1日の後半に詰め込む長時間セッション**。6時間の上限を超えた分は、質が落ちた状態の作業になります。

逆に投資対効果が高いのは、セキュリティに関わる実装、複雑な分岐を持つロジック、担当者が1人しかいない領域、新メンバーが最初に触るコードです。チーム全員で囲む必要があるほど判断が割れる作業なら、ペアではなくモブを選びます。判断基準は[モブプログラミングとは？ペアプログラミングとの違い・メリット・進め方を解説](/tech/details/4677/)で整理しています。

## ペアワーク・ペアレビュー・ペアコーディングの呼び分け

似た言葉が混在するので、指しているものを整理します。

- **ペアプログラミング**：2人で1台の環境を共有し、driverとnavigatorに分かれて実装する開発手法。
- **ペアコーディング**：ペアプログラミングとほぼ同義で使われる言い回しです。
- **ペアワーク**：2人1組で行う作業全般を指す一般語で、研修や教育の文脈でも使われます。実装に限りません。
- **ペアレビュー**：書き上がったコードを2人で確認する形式。実装をその場で行わない点がペアプログラミングとの違いです。
- **モブプログラミング**：チーム全員で1台に向かう形式。ペアの概念をチーム全体へ拡張したものです。

アジャイル開発全体の中での位置づけは[アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説](/column/details/12850/)で確認できます。

## よくある質問

### ペアプログラミングとは何ですか？

2人のプログラマーが1台のワークステーション（1つの画面・キーボード・マウス）を共有してコードを書く開発手法です。キーボードを持つ側をdriver、プログラミングに関与しながら全体の方向づけに集中する側をnavigatorと呼び、役割は数分ごとに交代することが期待されます。Agile Allianceの用語集がこの定義を採用しています。

### ペアプログラミングは本当に効率的なのですか？

公開されている整理を見ると、体系的なペアリングのオーバーヘッドは15%程度という見積もりです。Laurie Williams氏の博士論文は品質の向上と統計的に有意なコスト増が見られなかったことを報告し、メタ分析では品質向上と工期短縮に加えて多少のコスト増が示されています。ただし実証研究の多くが学生を対象にしている点は用語集自身が限界として挙げているため、自チームでの前後比較を併せて見てください。

### 役割はどのくらいの頻度で交代すべきですか？

driverとnavigatorの交代は数分ごとが目安です。これと混同されやすいのが組む相手の入れ替えで、こちらは2〜3日ごとが知識の広がりに有効だとされています。ただし相手の入れ替えには立ち上げの時間とコンテキストスイッチのコストがかかるため、短くすればよいわけではありません。

### リモートでもペアプログラミングはできますか？

できます。リモート操作に対応したビデオ会議ツール、`ssh`と`tmux`の組み合わせ、Visual Studio CodeのLive Share拡張などが使われます。ビデオをオンにすること（ジェスチャーや表情の情報が失われるため）と、ノイズキャンセリングヘッドホンで音環境を整えることが推奨されています。

### 1日どのくらいの時間まで続けてよいですか？

1日あたり最大6時間が目安です。ペアリングは消耗する実践のため、休憩のリマインダーを設定し、昼休みはモニターから離れて実際に休むことが推奨されています。終日をペアで埋める計画は、後半の質が落ちるため避けてください。

## 関連記事

- [モブプログラミングとは？ペアプログラミングとの違い・メリット・進め方を解説](/tech/details/4677/)
- [KPTとは？開発チームの振り返りをスプリントで機能させる進め方・ツール連携・判断](/tech/details/15266/)
- [アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説](/column/details/12850/)

---

出典: [ペアプログラミングとは？メリット・進め方・ツールと導入判断を実装者向けに解説](<https://www.issoh.co.jp/tech/details/4676/>)（株式会社一創）
