モブプログラミングとは？ペアプログラミングとの違い・メリット・進め方を解説

モブプログラミングとペアプログラミングは、どちらも複数人で1台の画面に向かう開発手法です。違いは人数だけではなく、決められることの範囲と、1時間あたりに使う人件費が変わります。この記事では両者の定義を一次情報で押さえたうえで、どちらを選ぶかの判断基準、交代サイクルの決め方、そして「合わない」と言われたときの切り分けまでを扱います。ペアプログラミング単体の進め方・ツール・導入判断はペアプログラミングとは？メリット・進め方・ツールと導入判断を実装者向けに解説にまとめてあります。

まとめ：モブとペアの違いと使い分け

• モブはペアの拡張。Agile Allianceの用語集はモブプログラミングを「チーム全員が、同じものに、同じ時間に、同じ場所で、同じコンピューターで取り組む開発手法」と定義し、ペアプログラミングの概念をチーム全体へ広げたものだと説明しています。
• 交代は10〜15分から。Zuill氏の実験レポートはドライバーの担当時間を「typically 10 to 15 minutes」とし、リモート実践のRemote Mob Programmingは10分交代を採用しています。ペアの役割交代はAgile Allianceが「数分ごと」としており、モブより短い単位です。
• 判断が要る作業ほどモブ、手が足りない作業はペアか分担。全員の時間を使う以上、意思決定を伴わない定型作業をモブでやると人件費だけが増えます。
• 「生産性10倍」は条件付き。出典であるZuill氏のレポート自身が、規模を考慮していない比較であること、導入前が個人作業中心のウォーターフォールだったことを認めています。

モブプログラミングとペアプログラミングの定義

モブプログラミング：チーム全員が1台で同時に取り組む形式

Agile Allianceの用語集は「Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and on the same computer」と定義しています。同じ用語集は「これはペアプログラミングの概念を、2人からチーム全体の継続的な協働へ拡張したものだ」とも説明しており、モブはペアの上位互換ではなく拡張形という位置づけです。

キーボードを持つ人をドライバー、指示を出す側をナビゲーターと呼ぶ点はペアと同じですが、モブではナビゲーターが複数になります。実装に詳しい人ほどキーボードから離れ、言葉で伝える側に回るのが基本形です。

ペアプログラミング：2人で1台のワークステーションを共有する形式

同じ用語集はペアプログラミングを「two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair)」と定義しています。キーボードを持つ側が「driver」、より全体の方向づけに集中する側が「navigator」で、役割は数分ごとに交代することが期待されると明記されています。なお、ドライバーとナビゲーターという呼び方自体はペアプログラミングを説明するために後から導入された用語で、用語集は最も古い言及を2000年前後のメーリングリスト投稿だと補足しています。

人数・交代・コストの比較

表で効いてくるのは人件費の行です。5人のモブは、同じ1時間で5人分の工数を消費します。その時間で全員が同じ判断に立ち会う価値があるかどうかが、モブを選ぶ唯一の基準だと考えてください。

どちらを選ぶかの判断基準

作業の性質で決めます。判断が発生し、間違えたときの手戻りが大きい作業ほどモブが向きます。

• モブが向く：仕様の解釈が割れている機能、担当者が1人しかいない領域、新メンバーが最初に触るコード、障害対応の方針決め。
• ペアが向く：実装量が読めていて品質を落とせない作業、レビュー待ちが慢性的に滞留している領域、1対1の育成。
• どちらも使わない：手順が確定した定型作業、一次調査、ドキュメントの下書き。

導入初期は全日をモブに倒さず、判断が要る時間帯だけモブにする運用から始めるほうが定着します。ペアの進め方やツール選定はペアプログラミングとは？メリット・進め方・ツールと導入判断を実装者向けに解説で個別に扱っています。

交代サイクルの設計

ローテーション頻度とその重要性

交代の間隔は感覚で決めず、実践者が公開している値から始めるのが安全です。Woody Zuill氏がAgile2014で発表した実験レポート「Mob Programming – A Whole Team Approach」は、キーボードを持つドライバーの担当時間を「typically 10 to 15 minutes」としています。リモート主体で実践しているRemote Mob Programmingのチームは10分交代を採用し、それより短い間隔は切り替えコストがあってうまくいかなかったと明記しています。

つまり5分や3分の交代は、受け渡しの手間が実作業を上回ります。最初は10分に固定し、コードベースへの慣れが進んでから調整してください。ペアプログラミングはAgile Allianceが「数分ごとの交代」としており、モブより短い単位で回ります。人数が増えるほど1周に時間がかかるため、モブでは1人あたりの持ち時間を長めに取る形になります。

操作でなく意図を伝えるナビゲーターの役割

交代制が機能しない典型は、ナビゲーター側がキーの位置まで口頭で指示し、ドライバーが代筆者になる状態です。Zuill氏のレポートは、ナビゲーターはドライバーが理解できる最も高い抽象度で話すことを求めています。

これを最も短く言い切ったのが、Llewellyn Falco氏が整理したストロングスタイル・ペアリングの原則「アイデアが自分の頭からコンピューターへ入るには、必ず他人の手を通らなければならない」です。知っている人がキーボードを持たないことを求める原則で、実装に詳しい人ほどナビゲーター側に回るのが、知識が広がる仕組みそのものになります。

ピンポンペアプログラミングという変型

テスト駆動開発と組み合わせる場合は、交代の単位をテストに揃える方法があります。Martin Fowler氏のサイトに掲載された解説では、開発者Aが失敗するテストを書き（Ping）、開発者Bがそれを通す実装を書き（Pong）、続けてBが次の失敗するテストを書く、という流れで説明されています。

時間ではなくテスト1本を単位にするため、キリの悪いところで交代する不満が起きにくくなります。モブでも同じ考え方を使えますが、人数が多いと1周に時間がかかるため、時間制と併用して上限を切るのが現実的です。

「生産性10倍」の出典と、著者本人が付けた留保

モブプログラミングの紹介で繰り返し引用される「生産性が10倍」という数字は、Zuill氏の実験レポートに由来します。原文では、導入前年と導入後の年で「使われる状態まで届けたプロジェクトの本数」を比べ、およそ10倍に増えたと書かれています。

重要なのは、同じ段落に置かれた留保のほうです。原文は、この改善がモブプログラミングだけによると証明する簡単な方法はないこと、プロジェクトの規模や機能数を考慮していない比較であること、導入前の開発方式が個人作業中心のウォーターフォールだったためアジャイル的な進め方へ移るだけでも多くが説明できることを認め、他の環境で再現できるとは主張しないと明記しています。

社内提案でこの数字を根拠に使うのは筋が悪くなります。持ち出すなら比較対象（個人作業＋ウォーターフォール）と測定単位（届けたプロジェクト本数）まで添えてください。導入判断に使えるのは、レビュー待ちの滞留時間、着手から本番反映までのリードタイム、特定領域を1人しか触れない状態の解消といった、自チームで前後比較できる数字です。振り返りで数字を追う枠組みはKPTとは？開発チームの振り返りをスプリントで機能させる進め方・ツール連携・判断が使えます。

「モブプロが合わない」と言われるときの切り分け

ドライバー1人に集中する負荷

モブプロが嫌われる原因は性格の問題として語られがちですが、実際には構造の問題であることが多くなります。複数人が1人の手元を見て発話する形は、キーボードを持つ人に注意と指摘が集中する構図です。交代間隔を短めに固定し「持ち時間が必ず終わる」ことを保証するのが実務的な緩和策になります。

もう1つの原因は、発言できない時間が続くことです。Remote Mob Programmingは「タイピストは自分だけでコードを書いてはならない」「タイピスト以外は言葉で説明する」と役割を明文化しています。ルールを口頭の空気に任せると、声の大きい1人が実質的に書き続け、残りが待機する会になります。

モブプロを使うべきでない場面

全ての作業をモブでやる必要はありません。次の性質を持つ作業は、分担したほうが速く終わります。

• 手順が確定していて判断が発生しない定型作業（バージョン上げ、機械的な置換）
• 調査結果を持ち寄る前の一次調査、ドキュメントの下書き
• 参加者の大半が待機になる、環境固有のトラブルシューティング

逆に効くのは、設計の判断が必要で、後から手戻りするとコストが大きい作業です。仕様の解釈が割れている機能、担当者が1人しかいない領域、新メンバーが最初に触るコードが該当します。

モブワーク・モブレビュー・スウォーミングの呼び分け

同じ形式でも、対象とする作業によって呼び方が変わります。

• モブプログラミング：実装をチーム全員で行う形式。Agile Allianceの定義がこれにあたります。
• ソフトウェアチーミング：Zuill氏自身のサイトで「Software Teaming (Mob Programming)」と併記されている呼称で、実践としては同じものです。
• モブワーク／モブ作業：実装に限らず、要件整理や運用手順の作成など実装以外の作業まで含めた呼称です。
• モブレビュー：レビュー対象を全員で同時に確認する形式。その場で実装するわけではないため、レビュー会の運用に近くなります。
• スウォーミング：スクラムの文脈で、1つのバックログアイテムにチームが集中して片付ける進め方を指す言い回しです。

呼称が違っても運用の勘所は共通で、交代の仕組みと発話のルールを決めることに尽きます。開発プロセス全体の中での位置づけはアジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説で確認できます。

モブプログラミングに関するよくある質問

モブプログラミング（モブプロ）とは何ですか？

チーム全員が同じ課題に、同じ時間に、同じ場所で、同じコンピューターを使って取り組む開発手法です。Agile Allianceの用語集はこの定義に加えて、ペアプログラミングの概念を2人からチーム全体へ拡張したものだと説明しています。キーボードを持つドライバーと、指示を出すナビゲーターに分かれる点はペアと同じで、モブではナビゲーターが複数になります。

モブプログラミングとペアプログラミングの違いは何ですか？

人数と、決められることの範囲が違います。ペアは2人で1台のワークステーションを共有し、役割を数分ごとに交代します。モブはチーム全員が参加するため、設計方針をその場で全員合意できる代わりに、1時間あたり人数分の工数を消費します。判断が発生し手戻りのコストが大きい作業はモブ、実装量が読めていて品質を落とせない作業はペアが向きます。

モブプログラミングは何人で行うのが適切ですか？

リモート実践のRemote Mob Programmingは3〜4人を採用しています。人数を増やすほど1周の交代に時間がかかり、待機している人が増えるため、まずは3〜5人程度から始めて、待機が目立つようなら分割してください。参加者の大半が手を動かせない作業は、そもそもモブに向いていないサインです。

交代は何分ごとにすべきですか？

10分から始めてください。Zuill氏の実験レポートはドライバーの担当時間を10〜15分としており、Remote Mob Programmingは10分交代を採用したうえで、それより短い間隔は切り替えコストがあってうまくいかなかったと明記しています。テスト駆動開発と組み合わせる場合は、時間ではなくテスト1本を単位にするピンポン方式も使えます。

モブプログラミングとモブワーク・ソフトウェアチーミングは同じ意味ですか？

ほぼ同じ考え方を指します。ソフトウェアチーミングはZuill氏自身のサイトで「Software Teaming (Mob Programming)」と併記されている呼称で、実践としては同じものです。モブワークは実装に限らず要件整理や運用手順の作成まで含めた呼称、モブレビューはレビュー対象を全員で同時に確認する形式を指します。呼称が違っても、交代の仕組みと発話のルールを決めるという勘所は共通です。

関連記事

• ペアプログラミングとは？メリット・進め方・ツールと導入判断を実装者向けに解説
• KPTとは？開発チームの振り返りをスプリントで機能させる進め方・ツール連携・判断
• アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説