AI時代のモブプログラミングFAQ

これまで、モブプログラミングに関する講演や研修を、さまざまな場所で開催してきました。先日も、AI時代のソフトウェア開発とモブプログラミングをテーマにした研修を実施しました。講義だけでなく、チームに分かれて実際にモブプログラミングを体験してもらう構成です。

こうした場で、よく聞かれる質問があります。「ミーティングと何が違うんですか？」「5人で1つの仕事をしたら、生産性は5分の1になりませんか？」「AIがコードを書くなら、タイピストは要らなくないですか？」どれも、モブプログラミングを検討したことのあるチームなら、一度は突き当たる問いだと思います。

せっかくなので、よく聞かれる質問への回答をFAQとしてまとめてみました。ぜんぶの答えの根っこには、ひとつの考え方があります。

モブプログラミングは、複数人でコードを書くための手法ではない。チームの理解を増幅する仕組みである。

なぜ「共有」ではなく「増幅」なのか。ここの詳しい種明かしは、別の記事でじっくり書くつもりです。今回はこの軸だけ頭の片隅に置いて、質問に答えていきます。

モブプログラミングとは

言葉の定義だけ揃えておきます。モブプログラミングとは、チーム全員で4つの「同じ」が揃っている状態です。

キーボードをたたく人がタイピスト（ドライバーとも呼ばれます）。それ以外の全員がその他のモブ（ナビゲーター）。全員で会話して、考えて、判断する。合意したことをタイピストが代表してアウトプットする。これを時間で交代しながら回していきます。オンラインでも成立しますし、プログラミングに限らず、設計・レビュー・調査・障害対応など、複数人で同じ目的に向かう仕事なら何でもモビングできます。

基本のやり方や背景は、スライドにまとめてあるのでそちらをどうぞ。

• Head First モブプログラミング — 基本のやり方と、よくあるアンチパターン
• モブプログラミング再入門 — 基本から見直す、AI時代のチーム開発の選択肢

ミーティング・レビュー・ペアとの違い

Q. ミーティングと何が違うんですか？

構造だけ見ると、ミーティングとモブはたしかに似ています。複数人が集まって、同じ画面を見て、会話して、同じ時間だけ人を使う。ミーティングは毎日やっているのに誰も咎めないのに、モブになると突然「そんなに人を集めるのは非効率では？」と言われる。投入している人数と時間の構造は、ミーティングと変わらないのに、です。

違うのは、その場で何をしているかです。多くのミーティングでは、誰かが事前に準備した資料を共有し、できたものをレビューし、意見を集めて合意します。つまり結果を持ち寄る場です。モブでは、仕事そのものをその場で全員で進めます。設計も、実装も、調査も、意思決定も、過程を共有する場です。

会議室で会議を繰り返すのと、集まって仕事を進めるの。構図は同じで、やっていることが違うだけ。だとしたら、どちらが「非効率」なのでしょうね。

Q. レビューや勉強会でも知識共有はできますよね？

できます。ただし、レビューや勉強会で共有できるのは、多くの場合すでに存在する成果物から読み取れる情報です。モブで共有できるのは、結果に至る過程です。どこで迷ったか、なぜその案を捨てたか、どの順番で問題を切り分けたか、経験者が無意識にやっているIDEの操作や調べ方。これらのほとんどは成果物に残りません。

そしてモブはリアルタイムレビューでもあります。事後レビュー(プルリクエスト等)と対立するものではなく、役割が違います。その場で直る・全員合意で進むのがリアルタイムレビュー、記録に残る・俯瞰できるのが事後レビュー。置き換えるのではなく、組み合わせるものです。

もうひとつ、研修や輪読会との違いは知識のジャストインタイムです。必要な瞬間に、必要な知識が入る。教えているのではなく、一緒に働いているだけ。なのに伝わる。

Q. ペアプログラミングとは何が違うんですか？

理解が蓄積される範囲が違う、と捉えています。5人チームでペアを組むと、その2人の間には強い共通理解が生まれますが、残りの3人には別途共有が要ります。モブなら、最初からチーム全体がその問題解決に参加します。

「ペアが悪くてモブが良い」という話ではありません。どの範囲まで理解を増幅したいのかで形を選べばいい。10人チームなら、全員で1モブ、5人×2モブ、ペア、ソロ、どれもありです。複数モブに分ければ「モブ同士の理解をどう同期するか」という設計課題は生まれますが、10人が10個の異なるコンテキストを持つ状態を同期するより、2〜3個のモブを同期するほうがずっと簡単です。

「5人で1つの仕事」は非効率なのか

Q. 5人で1つの仕事をしたら、生産性は5分の1になりませんか？

まず「生産性」という言葉を分けさせてください。コード行数、完了チケット数、同時に進む作業数。アウトプット（仕事量）の意味なら、分担したほうが増えることは多いです。ここは認めます。

でも本当に見たいのは、そこから生まれた価値、アウトカムのほうですよね。

分担作業には、前後に「同期」の作業が必要になります。タスク分割、設計のすり合わせ、キックオフ、レビュー、承認、引き継ぎ。そして理解がズレていると、ここで手戻りが生まれます。「3人が3つの仕事をするから3倍速い」という単純な構造では、実はないのです。

モブは、同期しないのではなく常に同期している働き方です。引き継ぎもレビュー待ちも、構造ごと消える。Gitのイメージで言えば、分担はマージで初めて答え合わせをするのに対し、モブは全員で1本の履歴を進めるので、いつでも「常にマージ済み」。答え合わせが「最後に一回」か、「常に」か、の違いです。

考える道具として、リソース効率とフロー効率という2つの効率を紹介させてください。リソース効率は人の稼働率を最大化する働き方。全員が別々の仕事を持って手を止めない。個人は速いが、待ちと引き継ぎが増える。フロー効率は1つの仕事の流れを最速化する働き方。仕事が人を待たない。モブはこちら側で、いわば究極の一個流しです。

道路を車で埋めれば稼働率は100%ですが、流れません。道路を空ければ、車は目的地に早く着く。どちらが正しいかではなく、何を最速にしたいかが違うのです。

実際に自分たちがモブを始める前は「遅くなるのでは？」という不安がありました。やってみると意外なほどスムーズに仕事が流れて、「むしろ分担より速かったのでは？」と感じたことも何度もあります。ただし、常にモブのほうが速いと主張するつもりはありません。仕事によって選ぶべきです。それが次の話です。

モブと分担を、使い分ける

Q. どんな仕事がモブに向いていますか？

「複雑だからモブ」と考えるより、その仕事を通して得られる理解を、チームの資産にしたいかを判断軸にすることをおすすめします。探索的な仕事、正解がまだ分からない問題、設計判断、ドメイン理解が必要な仕事、障害調査、新しい技術、スキル移転をしたい仕事。複雑な問題は結果として「チームの理解にしたい」ことが多いので、モブ向きになりやすい、という順番です。

迷ったら、「あとで全員に説明が必要になるか」で考えてみてください。あとで「なぜ」を聞かれる仕事は、最初から全員でやったほうが早いことが多いです。

逆に、誰がやっても結果がほとんど変わらない定型作業、ごく小さな修正、知識を広げる価値が低い仕事は、分担したほうがよいことがあります。モブは万能ではありません。モブと分担のどちらが正解かではなく、選択肢として両方持っていることがチームの強さです。

もうひとつ。「今日はモブ」「今日は分担」という大きな単位で考える必要もありません。熟練したチームでは、仕事の途中でも自然に切り替わります。モブ中に難しい課題にはまったら、一人は検索し、一人はドキュメントを調べ、一人は手元で試し、一人はAIに聞く。誰かが有力な情報を見つけたら「これちょっと見て」とモブに戻る。モブ→分担→モブを短い単位で行き来する。この粒度が細かいほど、チームは仕事の進め方を細かくチューニングできます。

良いモブをどう作るか

Q. タイピストは、自分で考えてはいけないんですか？

まず、よくある誤解から。「タイピストが仕事をして、他の人が見ている」。これは、モブではありません。モブでは、チームが会話して意思決定し、その合意をタイピストが代表して環境に反映します。タイピストは「手」であって「頭」ではない。タイピストが独断で書き進めて他の人が見ているだけなら、それはライブコーディングに近い何かです。

ただし「考えるな」という意味ではありません。役割の理解を優先して、あえて「その他のモブの合意どおりに操作する」という練習ルールを使うこともありますが、実際の仕事ではタイピストもチームメンバーです。意見も質問も「分からない」も、当然言っていい。チームの意思決定を手に反映する窓口、と捉えるのが分かりやすいと思います。

その他のモブも「見る人」ではありません。考えて判断する、口に出す、質問する、調べる、記録を残す、タイムキープ、ファシリテーション、「わからない」と言う。貢献の仕方はひとつではなく、どれか1つでも担えていればチームへの貢献です。

Q. スキル差が大きいチームでは、どうすればいいですか？

発言量を全員均等にする必要はありません。詳しい人が多く話すこと自体は悪いことではなく、その知識が周囲に伝播するなら価値があります。大事なのは、そのモブの目的に対して必要な会話が起きているかです。

スキル差を埋めたいときに効く工夫がひとつあります。経験の浅い人に、タイピストを多めに担当してもらうことです。タイピストには強い権利があります。分からなければ、手が止まる。通常の参加者が「ちょっと分からないので止まってもらえますか」と言うのは心理的ハードルが高いですが、タイピストなら操作できないので自然に止まります。そこで詳しいメンバーが背景を説明し、判断理由を言葉にする。聞きながら手を動かすと学びが最大化されるので、結果としてチーム内の理解がならされていきます。

Q. タイピストの交代は、どうやって決めればいいですか？

交代の仕方に、決まりはありません。時間で交代する、キリのいいところで交代する、コミット単位で交代する。どれでもよくて、チームに合う方法を選べばよいです。ちなみに研修では、タイピストを全員に回すために10分で交代しています。実務では30分や1時間で回しているチームもあります。

キリのいいところやコミット単位で交代する場合に、ひとつだけ気をつけたいことがあります。問題が難しいとキリがなかなか来ず、同じ人がタイピストをやり続けてしまうことがある点です。そうなっていることに気づける仕掛けがあると安心です。

時間で交代する場合には、ローテーション以外の価値もあります。30分経って交代するとき、「30分やったのに問題が解決していない」ことに気づけるのです。このまま続けるか、問題の捉え方を変えるか、一度調査に切り替えるか。交代が、自分たちの仕事を一段上から眺めるタイミングになります。

Q. 心理的安全性がないとモブは無理ですよね？

順序が逆かもしれない、と思っています。モブにおける心理的安全性とは、仲が良いことではなく、必要なときに仕事を止められることです。「今ちょっと分からない」と言える。「意見が合っていない気がするので整理しませんか」と言える。

モブについて覚えておくことをひとつだけ選ぶなら、自分はこれを挙げます。「わからない」と言うことは、チームへの貢献です。 わからないまま進んだ分だけ、理解はチームから抜け落ちていきます。「わからない」が言えるチームには、理解が貯まっていく。そういう状況を、モブを通じてつくっていくのです。

Q. モブがうまくいかなかったら、どうすればいいですか？

まず「何がうまくいかなかったのか」を言葉にすることからです。一人だけずっと話していた、誰かが参加できていなかった、会話がほとんどなかった、居心地が悪かった。モブの最後に短いふりかえりをして、よかったこと・居心地が悪かったこと・次に試したいことを話す。理想のモブは最初から存在しないので、そうやって自分たちのモブをテラフォーミングしていくイメージです。

そして重要なのは、「モブがうまくいかなかった→モブはダメだ」と短絡しないことです。実際には、モブの問題ではなく、もともとチームが抱えていた問題が、モブによって顕在化したケースが多い。モブはコミュニケーション密度が非常に高いので、発言の偏り、権力関係、スキル差、意思決定の癖が見えやすくなります。その意味で、モブはチームの状態を映す鏡です。見えたなら、直せます。問題の解像度が上がると、むしろ気が楽になりますよ。

ただし、鏡に映ったものによっては、モブで解決しようとしてはいけません。特定の人との仕事が精神的に大きな負担になっている、ハラスメントに近い問題がある、強い権力関係がある。そういうチームだけでは解決できない問題が見えたときは、コミュニケーション密度の高いモブはむしろ状況を悪化させえます。モブを止めて、マネージャーや組織へエスカレーションしてください。モブはチームのあらゆる問題を解決する万能薬ではありません。

Q. リモートでもできますか？ カメラはONにすべきですか？

できます。フルリモートで何年もやってきました。難しいのはハイブリッドです。3人がオフィスの会議室、2人がリモート、という形にすると、オフィス側だけで会話が盛り上がってリモート側が置いていかれます。オフィスにいる人も一人ずつPCからオンライン会議に入るなど、参加者間の情報格差を減らすのがコツです。

カメラは、絶対ONとは考えていません。ただ、顔が見えると情報量は増えます。タイピストが突然止まったとき、困っているのか、考えているのか、表情から読み取れて「何か分からなかった？」と自然に声をかけられる。大事なのはON/OFFそのものより、チームで期待値を合わせておくことです。「基本はONにする。ただし体調や家庭の事情があるときは遠慮なくOFFに」というWorking Agreementがあれば、OFFの人を見ても「何か事情があるんだろう」と思えるし、OFFにする側も罪悪感がありません。

Q. モブを嫌がるメンバーがいたら、どうすればいいですか？

好きか嫌いかだけで仕事のやり方を決めるのは、どちらの方向にも望ましくないと思っています。個人の感情は重要な情報ですが、最終的にはチームとして何を達成したいかで考えたい。

モブは説明だけでは価値が伝わりにくいので、まず小さく体験するのが有効です。午前中だけ、一つのタスクだけ、2時間だけ。やってみて「スキル差を埋めるにはすごく良さそうだ」と分かったら、「スキルトランスファーのために週に数時間モブをしよう」とチームで合意できます。モブ自体が好きではないメンバーでも、「スキル差を減らすことは重要」という目的には合意できるかもしれない。必要なのは、モブをやることへの合意ではなく、目的への合意です。

導入時に全タスクをモブにする必要もありません。基本すべてモブのチームも、週に一定時間だけのチームも、必要なときだけのチームもあります。スプリントプランニングで「このタスクはチーム全体の理解にしたいからモブ」「これは分担」と選んでいけば、どの仕事をモブでやるかという判断自体が、チームの上達していくスキルになります。

マネージャーのみなさんへ

ひとつだけお願いがあります。5人で1つのモブをしているのを見て、自分の感覚だけで「それ効率悪くない？」「モブやめたら？」と言わないでほしいのです。ここまで書いてきたとおり、5人で1つの仕事をしているからといって、生産性が5分の1になったわけではありません。短期的な作業量の裏で、理解の蓄積、スキル移転、レビューコスト、手戻り、中長期的なチームの能力が動いています。

AIで全体の変化が速くなったいま、すべてを1人のマネージャーが理解して管理するモデルはもう限界です。理解は管理者の頭ではなくチームに貯める。だから任せられる。マネジメントの仕事は、時間と場所を確保して、成果はチームで見て、最初の数回は見守ることです。チームの変化は、支援側にまわると加速します。

そして可能なら、一度モブに参加してみてください。モブは理論では価値が伝わりにくく、体験すると一発で分かる類のものです。「なぜそんなに人を張り付けているのか？」と聞かれたら、こう答えることにしています。「チームで仕事をしているだけですよ」。

AI時代のモブプログラミング

Q. AIがコードを書くなら、タイピストは要らなくないですか？

ソフトウェア開発には、情報を集める→分析する→意思決定する→作業する→結果を見る→また判断する、というループがあります。AIが自動化しているのは、主に「作業する」の部分です。

モブでは、人間が会話して判断し、チームで意思決定して、AIへ依頼し、AIが作業して、結果をまた全員で評価する、という形が自然に作れます。AIと人間の役割分担を、自然に実現しやすい仕事の形なのです。

タイピストの本質は変わりません。チームの意思決定を実際の環境に反映する窓口です。手段が、コード入力からAIへのプロンプトに変わっているだけ。チームでAIへのプロンプトを書く、という状態です。

そしてモブの会話は、そのままAIへの入力品質になります。AIの性能が上がったことで、面白い逆転が起きています。かつては「AIがつくっただから品質が低い」と道具の限界を言い訳にできました。いまは「AIがつくったのに品質が低い」。指示した人間側の理解と言語化が、そのまま結果に出る。品質の説明責任が、AIから人間に戻ってきたのです。

結果の質を決めるのは、理解の質×言語化の質。何をなぜ作るかをどれだけ深く分かっているかと、それをどれだけ正確に言葉にできるか。モブプログラミングの毎日は、この2つを同時に鍛えるトレーニングになっています。

Q. AIとの会話コンテキストは、チームでどう共有するんですか？

最初に言っておくと、これはモブ固有の問題ではありません。分担開発でも、AさんのAI・BさんのAI・CさんのAIがそれぞれ別のコンテキストを持つ問題は起きています。モブでは1つの仕事を共有しているぶん、この問題が見えやすくなるだけです。

自分たちは、二層で考えています。

同期コンテキストは、いま共有する層です。ターミナル共有やLive Shareで、モブ全員が同じAIセッションを囲む。CLI型のAIを使っていれば、タイピストが交代してもAI側の会話履歴は維持されます。tmux等でセッションを残しておけば、次回のモブでも同じ続きから再開できます。

永続コンテキストは、リポジトリに残す層です。AIとの会話で生まれた判断・制約・仕様・背景を、CLAUDE.mdやADRやdocs/に書き残す。そうすれば、タイピスト交代でCommit/Pushして次の人が新しいセッションを開いても、リポジトリのコンテキストからAIが理解を再構築できます。この層は、モブでも分担でも、チーム全体でAIコンテキストを蓄積する基盤になります。

Q. AI時代でも、TDDに意味はありますか？

「実装とテストを作って」とAIに言えば、一気に作れてしまう時代です。それでも、TDD的な考え方の価値は残ると思っています。TDDの価値を、最初に仕事のゴールを形式化することとして捉えるからです。

「このタスクは、どうなったら達成なのか？」を最初にチームで話す。それをテストという形式にする。ゴールをチームで明確にして、AIへ渡し、AIが問題を解決して、最初に決めたゴールを満たしたかを確認する。人間がテストコードを手入力することが大事なのではなく、先に期待する状態を明確にすることが大事。だから、TDDとモブは相性がいいのです。

Q. AI時代に、人間が集まって仕事をする意味はあるんですか？

2026年現在、仕事の起点を作っているのはまだ人間です。AIが勝手に「このユーザーの問題を解決するプロダクトを作ろう」とビジネスを立ち上げたりはしません。この問題を解決したい、このユーザーを助けたい。そういう起点には、プロダクトへの情熱のようなものがあります。その情熱を共有し、優先順位を決め、意思決定し、AIへ仕事を渡す部分は、現時点では人間の重要な仕事です。

ただ、5年後もそうだとは断言しません。AIがアイデアを生み、意思決定し、人間に仕事を割り当てる世界になる可能性も否定しない。だからこの記事の答えはすべて「2026年現在の観察」です。そして、変化し続ける状況のなかで自分たちの働き方を選び直し続けるためにこそ、チームに理解を貯めておく必要がある、と自分は考えています。

おわりに

AIは個人の能力の増幅器。モブはチームの理解の増幅器。 この2つは対立するものではなく、組み合わせるものです。そして、モブが正しい、でもありません。ソロ、ペア、モブ、分担。大事なのはモブプログラミングができることではなく、チームで働き方を選べることです。

ここまで読んでいただいてなんですが、モブプログラミングは、説明を読むより一度体験したほうが圧倒的に理解が早いです。研修でも、体験前は半信半疑だった方が、体験後にはまるで解像度の違う質問をしてくれます。この記事のFAQも、もともとはそういう質問たちでした。

チームで体験しながら、自分たちにとってどう使えるかを考えたい方向けに、AI時代のモブプログラミング研修を実施しています。興味のある方は 研修・トレーニング からお問い合わせください。

ソフトウェア開発って、楽しいよね。そう思える時間が、チームに少しでも増えますように。