モブプログラミング

英語名 Mob Programming
読み方 モブ プログラミング
難易度
所要時間 1セッション2〜4時間
提唱者 ウディ・コーティ
目次

ひとことで言うと
#

ペアプログラミングの拡張版。チーム全員(3〜6人)で1つの画面に向かい、1人がキーボードを打ち、残り全員がナビゲーターとしてリアルタイムに議論しながらコードを書く開発手法。

押さえておきたい用語
#

押さえておきたい用語
ドライバー
実際にキーボードを操作しコードを入力する人。ナビゲーターの指示に従って書く。自分の考えではなくチームの合意を反映する。
ナビゲーター
ドライバー以外の全参加者。設計方針・次のステップ・バグ指摘を議論し、ドライバーに指示を出す役割。
ローテーション
10〜15分ごとにドライバーを交代する仕組み。考えの途中でも交代し、全員が平等に参加する。
タイムボックス実験
意見が対立したとき、短時間で両方試して検証するアプローチ。議論より実験で決着をつける。

モブプログラミングの全体像
#

全員参加でコードを書く協働モデル
ドライバー(1人)チームの合意をコードに書くナビゲーター群設計・方針・レビューを議論10〜15分で交代タイマーで強制ローテーション成果物全員が理解した高品質なコード
モブプロセッションの進め方
1
課題選定
複雑な問題を1つ選ぶ
2
環境準備
大画面+タイマーを用意
3
ローテ実行
10〜15分交代で全員参加
4
振り返り
学びと改善点を共有

こんな悩みに効く
#

  • チーム内で知識が偏り、特定の人がいないと進まない
  • 設計の議論が長引き、なかなか結論が出ない
  • チームとしての一体感がなく、各自がバラバラに作業している

基本の使い方
#

ステップ1: セッションの準備をする

取り組むタスクと環境を整える

  • 取り組む課題を1つ選ぶ(複雑な問題、設計判断が必要なものが最適)
  • 大きなモニターまたはプロジェクターを用意する(リモートなら画面共有)
  • タイマーアプリを用意する(ドライバー交代用)

ポイント: 参加者全員がタスクの背景を理解していることが前提。事前に簡単なブリーフィングを行う。

ステップ2: ドライバーをローテーションする

10〜15分ごとにキーボードを打つ人を交代する

  • ドライバー: ナビゲーターの指示に従ってコードを書く
  • ナビゲーター(全員): 設計方針、次のステップ、バグの指摘を議論する
  • タイマーが鳴ったら次の人に交代。考えの途中でも交代する

ポイント: ドライバーは「自分の考え」ではなく「チームの合意」を書く。

ステップ3: 全員が貢献する環境を作る

発言しやすい雰囲気を維持する

  • 経験が浅いメンバーにも意見を求める
  • 「それいいね」「なるほど」のリアクションを積極的に
  • 意見が対立したら、小さく試して検証する(Time-boxed experiment)

ポイント: 声が大きい人だけが方向を決める状態は避ける。

具体例
#

例1:マイクロサービスの認証基盤をモブプロで設計・実装する

参加者: バックエンド2名、フロントエンド1名、インフラ1名、新卒1名(計5名)

セッション(3時間):

  • 最初の30分: ホワイトボードで認証フローを全員で議論。OAuth2 + JWTの方針に合意
  • 次の1時間: バックエンドがドライバーを交代しながら認証エンドポイントを実装。インフラが「この設定は環境変数に出した方がいい」とナビゲーション
  • 次の1時間: フロントエンドがドライバーとしてトークン管理のコードを書く
  • 最後の30分: 新卒がドライバーとしてテストを書く。全員がテストケースを提案

結果: 設計→実装→テストが3時間で完了。全員が認証基盤の仕組みを理解し、ドキュメントが不要なレベルの共有知識が生まれた。

例2:障害対応のポストモーテムをモブプロで実施する

状況: 前日に本番障害が発生し、復旧まで2時間かかった。根本原因の修正と再発防止策をチーム全員で実装したい。

セッション(2時間):

  • 30分: 障害の時系列を全員で再現。ログとメトリクスを画面共有しながら原因を特定(DBのデッドロック)
  • 1時間: モブプロでデッドロック回避のコード修正を実装。DBA経験者が「この順序でロックを取れば安全」とナビゲーション
  • 30分: 再発防止のアラート設定とランブックを全員で作成

結果: 修正内容を全員が理解し、類似の障害に全員が対応可能に。特定の人に依存しない障害対応体制ができた。

例3:新技術導入の学習セッションとして活用する

状況: チームでGraphQLを導入することが決定。経験者はゼロ。個人の自習では進みが遅い。

モブプロ学習セッション(週2回 x 2時間 x 3週間):

  • 第1週: 公式チュートリアルをモブで進行。疑問点をその場で全員が議論
  • 第2週: 実際のプロダクトの1エンドポイントをGraphQLで実装
  • 第3週: テストとエラーハンドリングのパターンを実装

結果: 3週間でチーム全員がGraphQLの基本を習得。個人学習では1ヶ月以上かかる見込みだった。「一人で悩む時間」がゼロになり、学習効率が3倍に。

やりがちな失敗パターン
#

  1. 参加者が多すぎる — 7人以上になると発言の機会が減り、傍観者が増える。3〜6人が最適。それ以上なら2チームに分ける
  2. 簡単なタスクにモブプロを使う — 定型的なCRUD実装に5人で取り組むのは無駄。複雑な問題、設計判断、新技術の学習に限定する
  3. ドライバーが自分の考えで暴走する — ナビゲーターの意見を無視して自分のやり方で書いてしまう。「ドライバーはタイピストに徹する」ルールを徹底する
  4. 休憩を取らない — 3時間以上の連続セッションは集中力が切れる。90分ごとに10分の休憩を挟むこと

まとめ
#

モブプログラミングは 「全員で同じ問題に取り組む」 という一見非効率に見える手法だが、知識共有・合意形成・品質向上の3つ を同時に実現できる。毎日やる必要はなく、複雑な問題や重要な設計判断の場面で週1〜2回取り入れるだけでも効果が大きい。まずはチームで「一番難しいタスク」を1つ選んで試してみよう。