モブプログラミング（モブプロ）は、チーム全員が同じ課題に、同じ時間に、1台のコンピューターで取り組む開発手法です。ペアプログラミング（ペアプロ）を2人からチーム全体へ広げた形で、違いは人数だけでなく、その場で決められることの範囲と、1時間あたりに使う工数にも出ます。この記事では定義とペアとの違いを一次情報で押さえたうえで、1回目のセッションの組み方、対面とリモートで変わる交代時間、「生産性10倍」の出典と留保、合わないと言われたときの切り分けまでを扱います。ペアプロ単体の進め方とツールはペアプログラミングとは？メリット・進め方・ツールと導入判断を実装者向けに解説にまとめています。
まとめ：モブプログラミングの定義・ペアとの違い・始め方
- モブはペアの拡張。Agile Allianceの用語集は、チーム全員が同じものに、同じ時間に、同じ場所で、同じコンピューターで取り組む手法と定義し、ペアプログラミングの考え方をチーム全体へ広げたものと説明しています。
- 違いは人数・交代時間・工数。ペアは2人で役割を数分ごとに交代し、モブは3人以上で10〜15分を目安に交代します。モブは同じ1時間で参加人数分の工数を使います。
- 交代時間は対面とリモートで分ける。提唱者のWoody Zuill氏は普段15分交代で、始めたばかりのチームにはずっと短い設定を勧めています（自身も当初は4〜5分）。リモートでは引き継ぎに手間がかかるため、10分より短いとうまくいかなかったという報告があります。
- 判断が要る作業ほどモブ。仕様の解釈が割れる機能や1人しか触れない領域に向き、手順が決まった定型作業には向きません。
- 「生産性10倍」は条件付き。出典のレポート自身が、規模を考慮していない比較であること、導入前が個人作業のウォーターフォールだったことを認めています。
モブプログラミングとペアプログラミングの定義
モブプログラミング：チーム全員が1台で同時に取り組む形式
Agile Allianceの用語集は、モブプログラミングを「the whole team works on the same thing, at the same time, in the same space, and on the same computer」と定義しています。キーボードを持つ1人がドライバー（タイピスト）、残りの全員がナビゲーターで、ドライバーは時間で交代します。
提唱者のZuill氏は、自身のサイトで「Software Teaming (Mob Programming)」と併記しており、ソフトウェアチーミングは同じ実践の別名です。英語ではmobbingとも呼ばれます。
ペアプログラミング：2人で1台のワークステーションを共有する形式
同じ用語集のPair Programmingの項は「two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair)」と定義しています。キーボードを持つ側がdriver、全体の方向に集中する側がnavigatorで、役割は数分ごとに交代するとされています。
人数・交代時間・工数の比較
| 観点 | モブプログラミング | ペアプログラミング |
|---|---|---|
| 人数 | 3人以上（実践例は3〜6人） | 2人 |
| ナビゲーター | 複数 | 1人 |
| 交代の目安 | 10〜15分（導入初期は短め） | 数分ごと |
| 1時間の工数 | 参加人数分 | 2人分 |
| その場で決められること | 設計方針をチーム全員で合意 | 2人の範囲での判断 |
| 知識の広がり方 | チーム全体へ同時 | 組んだ相手へ |
この表で効いてくるのは工数の行です。5人のモブは、同じ1時間で5人分を使います。その時間に全員が同じ判断へ立ち会う価値があるかどうかが、モブを選ぶ基準になります。
モブプログラミングで得られる効果と、その根拠
質問・レビュー・引き継ぎの待ち時間の削減
モブの効果は、作業そのものの速さより、作業の間にある待ちが消えることに出ます。分担して開発していると、仕様の質問への回答待ち、レビュー待ち、担当者間の引き継ぎが発生し、そのたびに作業が止まります。モブでは、必要な知識と判断の権限を持つ人が参加していれば、質問への回答とコードのレビューがその場で済み、チーム内の引き継ぎも発生しません。チームの外の人への確認待ちは残ります。
Zuill氏の実験レポート「Mob Programming – A Whole Team Approach」（Agile2014）は、導入後に目立たなくなった問題を分類しています。挙がっているのは、非生産的なコミュニケーション、意思決定の機能不全、必要以上の作り込み、技術的負債、見積もり・優先順位付け・スケジューリング・順番待ちといった重い管理作業、不要なタスク切り替えと割り込み、会議で決めて現場と判断が分かれることです。どれも1人の作業速度ではなく、人と人の間で起きる問題です。
裏返すと、待ちがほとんど発生しない作業では、モブにしても得るものが少なくなります。この点は後の判断基準の章で扱います。
同時作業によるチーム内の知識共有
同じレポートは、チームに見学者が1日参加すると、参加から10分以内にコードや技術的なアイデアで貢献し始める例が多いと書いています。全員が同じ画面を見て判断の理由を聞けるため、作業中の文脈を共有し、疑問をその場で確かめられます。
この効果は、特定の領域を1人しか触れない状態を解消したいときに最も大きくなります。担当者が休むと止まる機能があるなら、その機能をモブで扱い、担当者以外の参加者が変更理由を説明して修正を進められるかを確かめます。
「生産性10倍」の出典と、著者本人が付けた留保
モブプロの紹介で繰り返し引用される「生産性10倍」は、同レポートの8章に由来します。原文は、モブプログラミングを始める前の1年と始めた後の1年で、使われる状態まで届けたプロジェクトの本数を比べ、およそ10倍に増えたと書いています。
重要なのは、同じ章に書かれた留保です。原文は、この改善がモブプログラミングだけによると証明する簡単な方法はないこと、プロジェクトの規模や機能数を考慮していない比較であること、他の環境で再現できるとは主張しないこと、そして導入前が個人作業中心の段階的なウォーターフォールだったため、アジャイルな進め方へ移っただけでも多くが説明できることを認めています。Zuill氏はポッドキャストの対談で、約3年半の間にバグ管理システムへ報告されたバグは3件だったとも話していますが、これも同じチームの自己申告です。
社内提案でこの数字を根拠にするのは筋が悪くなります。持ち出すなら、比較対象（個人作業のウォーターフォール）と測定単位（届けたプロジェクトの本数）まで添えてください。導入判断に使えるのは、レビュー待ちの滞留時間、着手から本番反映までのリードタイム、1人しか触れない領域の数など、自チームで前後を比べられる数字です。
モブプログラミングの進め方
初回セッションの課題・人数・時間の決め方
最初の1回は、次の4点だけ決めて始めます。
- 課題：仕様の解釈に議論が要る機能を1つ。完了の条件（テストが通る、画面が動く）を先に書き出しておきます。
- 人数：3〜5人。Zuill氏のレポートは、チームの会話の多くが5〜6人、ときにはそれ以上で行われると書いていますが、初回は少ないほうが全員が話せます。
- 交代の順番とタイマー：その日の参加者を並べた順番表と、時間が来たら全員に分かるタイマー。Zuill氏のチームは、時間が来ると画面を消す小さなタイマーアプリを自作していました。
- 振り返りの時間：初回の試行として、終了前の15〜20分を空けておきます。
セッション自体は、初回の試行として2〜3時間で区切ることを勧めます。終日のモブは、交代と振り返りの型が固まってから広げます。
交代時間を決める：対面は短く始め、リモートは10分
交代時間は、対面かリモートかで考え方が変わります。
対面で1台のキーボードを回す場合、受け渡しはキーボードを隣に渡すだけです。Zuill氏のレポート5.3節は、普段は15分交代で、ときには短くすること、そしてモブを始めたばかりの人には、ずっと短い設定を勧めると書いています。チーム自身も最初は4〜5分のタイマーで始め、慣れに合わせて延ばしました。短い交代は全員にキーボードが回る頻度を上げ、ナビゲーターが話を聞いていない状態を作りにくくします。
リモートでは事情が違います。Remote Mob Programmingの著者たちは10分交代を採用し、いくつかの間隔を試したうえで、リモートチームに固有の切り替えコストがあるため、それより短い間隔はうまくいかなかったと書いています。画面共有の切り替えとコードの受け渡しが毎回発生するためです。
まとめると、対面は5分前後から始めて10〜15分へ延ばし、リモートは10分から始めるのが一次情報に沿った決め方です。
ナビゲーターの指示の抽象度
Zuill氏のレポートは、ナビゲーターはドライバー（とチーム）がその時点で理解できる最も高い抽象度で話すことを求めています。ドライバーが概念を分かっていれば「この関数を3つに分けて、入力チェックを先頭に出す」で足り、伝わらなければキー操作の単位まで具体化してもよい、と同じ箇所に書かれています。粒度は人によって、同じ人でもその日の題材によって変わります。失敗の典型は指示が細かいことではなく、ドライバーが理解しないまま打ち続ける状態なので、伝わったかを確かめながら粒度を上げ下げします。
モブの前提になっている原則が、Llewellyn Falco氏のストロングスタイル・ペアリングです。「アイデアが自分の頭からコンピューターへ入るには、必ず他人の手を通らなければならない」というもので、アイデアを持っている人はキーボードを持たず、言葉で伝える側に回ります。実装に詳しい人ほどナビゲーターに回ることが、知識が広がる仕組みそのものになります。
振り返りでの交代時間・発言機会の調整
Zuill氏のチームは、1〜2週間分を振り返る時間を30分〜1時間取り、それとは別に、気づいたことがあればその場で短い振り返りをしていました。議題を参加者がその場で決めて1つ5分程度で区切るLean Coffeeを、45分ほどで回すこともあったとレポートは書いています。
初回の振り返りで聞くべきなのは、交代時間は長すぎたか短すぎたか、話せなかった人はいたか、待機していた時間はあったか、の3点です。次の回はその答えに合わせて1か所だけ変えます。振り返りの枠組みはKPTとは？開発チームの振り返りをスプリントで機能させる進め方・ツール連携・判断が使えます。
テスト駆動開発との併用（ピンポン方式）
テスト駆動開発と組み合わせるなら、交代の区切りをテストに揃える方法があります。Martin Fowler氏のサイトに掲載されたOn Pair Programming（Birgitta Böckeler氏・Nina Siessegger氏）は、開発者Aが失敗するテストを書き（Ping）、開発者Bがそれを通す実装を書き（Pong）、続けてBが次の失敗するテストを書く流れを「ピンポン」として説明しています。
テスト1本を単位にすると、区切りの悪いところで交代する不満が起きにくくなります。ただしモブは人数が多く1周に時間がかかるため、時間のタイマーと併用して上限を切るのが現実的です。手順そのものはTDD（テスト駆動開発）とは？Red・Green・Refactorの手順をpytestとJUnit 6の実行例で解説で扱っています。
リモートでのコード引き継ぎと画面共有
mob CLIによるGit経由のコード引き継ぎ
リモートでは、キーボードを渡す代わりにコードを渡す必要があります。Remote Mob Programmingの著者たちは、一時的な作業用ブランチへWIPコミットをpushして次の人へ渡し、セッションの終わりにWIPコミットを意味のあるコミットへまとめてから本流へ取り込む方法を取っています。この作業用ブランチでは、コミットメッセージも、ビルドが通るかも、テストが緑かも気にしません。受け渡しの速さを優先するためです。
この手順をコマンド化したのが、同じ著者たちが作ったmobです。GitHubのリリース一覧では、2026年11月4日時点の最新版は2026年1月26日公開の5.4.2です。基本の流れは次のとおりです。
# 前提：全員がmobを導入し、同じリモートを持つ各自のcloneで、作業ツリーがクリーンな状態から実行
# 1人目：作業用ブランチを作り、10分のタイマーを開始
mob start 10
# 時間が来たら：変更をWIPコミットしてpushし、次の人へ渡す
mob next
# 2人目：同じブランチの続きから始める
mob start 10
# 最後の人：WIPコミットをまとめて元のブランチのステージへ戻す
mob done
git commit -m "注文確定時の在庫引当を追加"
git pushmob doneは作業用ブランチの変更を元のブランチのインデックスへ戻すところまでで、コミットはしません。最後に意味のあるメッセージでコミットするのは人の仕事です。休憩用にmob break 5のような休憩タイマーもあります。
画面はビデオ会議の画面共有で、ドライバーが自分の画面を映すのが基本です。Remote Mob Programmingの著者たちは、カメラを常にオンにし、1日に少なくとも6時間モブをするためにコアタイムと昼休みの時間をそろえています。
同じファイルを全員で編集したい場合は、VS CodeのLive Share拡張でも、共同作業者の編集と選択範囲がリアルタイムに表示されます。ただしMicrosoftの公式ドキュメントは、Visual Studio Live Shareは保守モードで、新しい機能は予定されていない（既存の機能は引き続き使える）と案内しています。新しく仕組みを作るなら、Git経由で受け渡すmobを主にし、Live Shareは補助にする構成を勧めます。保守モードのLive Shareには、今後の機能追加が見込めないためです。
モブとペアのどちらを選ぶかの判断基準
作業の性質で決めます。判断が発生し、間違えたときの手戻りが大きい作業ほどモブが向きます。
- モブが向く：仕様の解釈が割れている機能、担当者が1人しかいない領域、新メンバーが最初に触るコード、障害対応の方針決め、設計の大きな変更。
- ペアが向く：実装量が読めていて品質を落とせない作業、レビュー待ちが慢性的に溜まっている領域、1対1での育成。
- どちらも使わない：手順が確定した定型作業（バージョン上げ、機械的な置換）、持ち寄る前の一次調査、ドキュメントの下書き、参加者の大半が待つだけになる環境固有のトラブル対応。
導入初期は終日をモブにせず、判断が要る時間帯だけモブにする運用から始め、参加者の負担と待ち時間がどう変わったかを振り返りで確かめます。外部の開発チームと自社のメンバーが同じ体制でモブを続けたい場合は、ラボ型開発のように期間でメンバーを確保する契約を検討し、その際は契約期間だけでなく、メンバーが入れ替わらないか、共同作業の時間を取れるか、コードを共有できる条件かを確認してください。
「モブプロが合わない」と言われるときの切り分け
ドライバー1人に集中する負荷
モブプロが嫌われる理由は性格の問題として語られがちですが、構造の問題であることが多くあります。複数人が1人の手元を見て話す形は、キーボードを持つ人に注意と指摘が集中します。対策として、交代時間をタイマーで固定して「持ち時間が必ず終わる」ことを保証し、途中でも交代や休憩を申し出てよいルールを決めます。
もう1つの原因は、話せない時間が続くことです。Remote Mob Programmingは、タイピストは自分だけでコードを書いてはならず、ほかの全員が解決策を話し合って指示すると役割を明文化し、これで強い個性の人に場が偏るのを抑えるとしています。ルールを空気に任せると、声の大きい1人が実質的に書き続け、残りが待つ会になります。
参加の強制と個人作業の選択肢
Zuill氏のレポート11章は、モブでは全員の弱みが見えるため、それが耐えられないほど不快な人もいると認めたうえで、参加を強制せず、1人で作業する自由を残していると書いています。チームに入るかどうかは各自の選択で、全員がそれぞれのやり方で貢献することが期待されています。
「合わない」という声が出たら、まず全員参加を前提にしていないかを確認してください。判断が要る時間帯だけ集まり、残りは個人やペアで進める案を示し、本人が参加するかを選べる状態になっているかを確かめます。
経験者への操作・発言の集中
経験者と初心者が混ざると、経験者がキーボードを離さないか、ナビゲーターとして指示を出し続けて初心者が口を挟めなくなりがちです。ストロングスタイルの原則に戻り、経験者はナビゲーターとして意図だけを伝え、初心者がドライバーとして手を動かす時間を増やします。初心者が「なぜそうするのか」を質問した時間は、知識が広がっている時間なので、遅れとして数えないことをチームで合意しておきます。
モブワーク・モブレビュー・スウォーミングの呼び分け
同じ形式でも、対象とする作業によって呼び方が変わります。
- モブプログラミング：チーム全員で1台のコンピューターに向かう形式。Zuill氏のレポートは、コーディングに加えてストーリーの定義、設計、テスト、デプロイ、顧客とのやり取りもチームで行うと書いており、実装だけを指す言葉ではありません。
- ソフトウェアチーミング：Zuill氏がモブプログラミングと併記している呼び名で、実践としては同じものです。
- モブワーク（モブ作業）：開発に限らず、資料作成や運用手順づくりなど、ソフトウェア開発以外の仕事を全員で進めるときにも使われる呼び名です。
- モブレビュー：レビュー対象を全員で同時に確認する形式です。実装を進めることより、レビュー対象への理解と指摘をその場で共有することに重点があり、レビュー会の運用に近くなります。観点の決め方はコードレビューとは？目的・観点・進め方と実装現場の運用設計を解説を参照してください。
- モブエラボレーション：AWSが提唱するAI駆動の開発手法AI-DLCで、要件と設計をAIとチーム全員で詰める場を指す呼び名です。詳しくはAI-DLCとは？モブエラボレーション・Boltの進め方とWorkflows v2の使い方【2.11対応】で扱っています。
- スウォーミング：スクラムの文脈で、1つのバックログアイテムにチームが集中して片付ける進め方を指す言い回しです。
開発プロセス全体の中での位置づけはアジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説で確認できます。
モブプログラミングに関するよくある質問
モブプログラミング（モブプロ）とは何ですか？
チーム全員が同じ課題に、同じ時間に、同じ場所で、同じコンピューターを使って取り組む開発手法です。キーボードを持つ1人がドライバー、残りの全員がナビゲーターになり、ドライバーは時間で交代します。Agile Allianceの用語集は、ペアプログラミングの考え方をチーム全体へ広げたものと説明しています。
モブプログラミングとペアプログラミングの違いは何ですか？
人数、交代時間、使う工数、その場で決められることの範囲が違います。ペアは2人で1台を共有し、役割を数分ごとに交代します。モブは3人以上で10〜15分を目安に交代し、設計方針をその場で全員で合意できる代わりに、1時間あたり人数分の工数を使います。判断が要り手戻りの大きい作業はモブ、実装量が読めていて品質を落とせない作業はペアが向きます。
モブプログラミングは何人で行うのが適切ですか？
3〜5人から始めるのが扱いやすい人数です。リモートで実践しているRemote Mob Programmingの著者たちは、3〜4人のチームが費用対効果が最も良かったとしており、4人なら1人休んでもモブが成立する点も挙げています。対面のZuill氏のチームは、5〜6人かそれ以上で会話しながら進めていました。待つだけの人が目立つようなら、チームを分けてください。
交代は何分ごとにすべきですか？
対面は5分前後から始めて10〜15分へ延ばし、リモートは10分から始めてください。Zuill氏のレポートは普段15分交代で、始めたばかりのチームにはずっと短い設定を勧めており、自身も当初は4〜5分でした。リモートのRemote Mob Programmingは、10分より短いと切り替えのコストでうまくいかなかったと書いています。
モブプログラミングとモブワーク・ソフトウェアチーミングは同じ意味ですか？
ソフトウェアチーミングは、提唱者のZuill氏がモブプログラミングと併記している呼び名で、同じ実践を指します。モブワークは実装に限らず要件整理や運用手順の作成まで含めた呼び名、モブレビューはレビュー対象を全員で同時に確認する形式です。呼び名が違っても、交代の仕組みと話し方のルールを決めるという要点は共通です。
