ひとことで言うと#
ペアプログラミングの拡張版。チーム全員(3〜6人)で1つの画面に向かい、1人がキーボードを打ち、残り全員がナビゲーターとしてリアルタイムに議論しながらコードを書く開発手法。
押さえておきたい用語#
- ドライバー
- 実際にキーボードを操作しコードを入力する人。ナビゲーターの指示に従って書く。自分の考えではなくチームの合意を反映する。
- ナビゲーター
- ドライバー以外の全参加者。設計方針・次のステップ・バグ指摘を議論し、ドライバーに指示を出す役割。
- ローテーション
- 10〜15分ごとにドライバーを交代する仕組み。考えの途中でも交代し、全員が平等に参加する。
- タイムボックス実験
- 意見が対立したとき、短時間で両方試して検証するアプローチ。議論より実験で決着をつける。
モブプログラミングの全体像#
こんな悩みに効く#
- チーム内で知識が偏り、特定の人がいないと進まない
- 設計の議論が長引き、なかなか結論が出ない
- チームとしての一体感がなく、各自がバラバラに作業している
基本の使い方#
取り組むタスクと環境を整える。
- 取り組む課題を1つ選ぶ(複雑な問題、設計判断が必要なものが最適)
- 大きなモニターまたはプロジェクターを用意する(リモートなら画面共有)
- タイマーアプリを用意する(ドライバー交代用)
ポイント: 参加者全員がタスクの背景を理解していることが前提。事前に簡単なブリーフィングを行う。
10〜15分ごとにキーボードを打つ人を交代する。
- ドライバー: ナビゲーターの指示に従ってコードを書く
- ナビゲーター(全員): 設計方針、次のステップ、バグの指摘を議論する
- タイマーが鳴ったら次の人に交代。考えの途中でも交代する
ポイント: ドライバーは「自分の考え」ではなく「チームの合意」を書く。
発言しやすい雰囲気を維持する。
- 経験が浅いメンバーにも意見を求める
- 「それいいね」「なるほど」のリアクションを積極的に
- 意見が対立したら、小さく試して検証する(Time-boxed experiment)
ポイント: 声が大きい人だけが方向を決める状態は避ける。
具体例#
参加者: バックエンド2名、フロントエンド1名、インフラ1名、新卒1名(計5名)
セッション(3時間):
- 最初の30分: ホワイトボードで認証フローを全員で議論。OAuth2 + JWTの方針に合意
- 次の1時間: バックエンドがドライバーを交代しながら認証エンドポイントを実装。インフラが「この設定は環境変数に出した方がいい」とナビゲーション
- 次の1時間: フロントエンドがドライバーとしてトークン管理のコードを書く
- 最後の30分: 新卒がドライバーとしてテストを書く。全員がテストケースを提案
結果: 設計→実装→テストが3時間で完了。全員が認証基盤の仕組みを理解し、ドキュメントが不要なレベルの共有知識が生まれた。
状況: 前日に本番障害が発生し、復旧まで2時間かかった。根本原因の修正と再発防止策をチーム全員で実装したい。
セッション(2時間):
- 30分: 障害の時系列を全員で再現。ログとメトリクスを画面共有しながら原因を特定(DBのデッドロック)
- 1時間: モブプロでデッドロック回避のコード修正を実装。DBA経験者が「この順序でロックを取れば安全」とナビゲーション
- 30分: 再発防止のアラート設定とランブックを全員で作成
結果: 修正内容を全員が理解し、類似の障害に全員が対応可能に。特定の人に依存しない障害対応体制ができた。
状況: チームでGraphQLを導入することが決定。経験者はゼロ。個人の自習では進みが遅い。
モブプロ学習セッション(週2回 x 2時間 x 3週間):
- 第1週: 公式チュートリアルをモブで進行。疑問点をその場で全員が議論
- 第2週: 実際のプロダクトの1エンドポイントをGraphQLで実装
- 第3週: テストとエラーハンドリングのパターンを実装
結果: 3週間でチーム全員がGraphQLの基本を習得。個人学習では1ヶ月以上かかる見込みだった。「一人で悩む時間」がゼロになり、学習効率が3倍に。
やりがちな失敗パターン#
- 参加者が多すぎる — 7人以上になると発言の機会が減り、傍観者が増える。3〜6人が最適。それ以上なら2チームに分ける
- 簡単なタスクにモブプロを使う — 定型的なCRUD実装に5人で取り組むのは無駄。複雑な問題、設計判断、新技術の学習に限定する
- ドライバーが自分の考えで暴走する — ナビゲーターの意見を無視して自分のやり方で書いてしまう。「ドライバーはタイピストに徹する」ルールを徹底する
- 休憩を取らない — 3時間以上の連続セッションは集中力が切れる。90分ごとに10分の休憩を挟むこと
まとめ#
モブプログラミングは 「全員で同じ問題に取り組む」 という一見非効率に見える手法だが、知識共有・合意形成・品質向上の3つ を同時に実現できる。毎日やる必要はなく、複雑な問題や重要な設計判断の場面で週1〜2回取り入れるだけでも効果が大きい。まずはチームで「一番難しいタスク」を1つ選んで試してみよう。