10分交代のモブプロがコンテクストと集中力を高める

こんにちは！本記事では、来月開催されるスクフェス金沢で発表予定の「10分交代のモブプロがコンテクストと集中力を高める」のセッション内容について、概要を先行共有します！

モブプログラミングとは？

モブプログラミング（以下、モブプロ）とは、複数人で一つのコードを一緒に書いていく開発手法です。

基本的に、「ドライバー」「ナビゲーター」「モバー」という3つの役割に分かれて進めます。

• ドライバー：実際にコードを書く人
• ナビゲーター：ドライバーに対して指示を出す人
• モバー：それ以外のコードレビューや議論に参加する人

全員が同じ画面を見ながら、ひとつのアウトプットを協力して生み出すスタイルとなっています。

なぜモブプロを選んだのか？

今回のプロジェクトは、内製化支援を目的としており、開発は主にリモートで行われています。顧客サイドの開発者も交えながら、モブプロをベースに日々の開発を進めてきました。

モブプロを採用した理由としては、複数人が関わることでコードレビューの時間を短縮できること、開発と同時に知識が共有されることで高い学習効果が得られること、さらにリモート環境でも孤独感が軽減され、自然と会話の機会が増えることなどが挙げられます。

モブプロで感じた課題

私たちはこれまで1年半以上にわたり、モブプロを継続してきました。チーム全体としてモブプロすることに慣れ、状況に応じて指示の抽象度を変えたり、ときにはドライバーがモブプロ全体をリードしてコードを書くなどの工夫が生まれるようになりました。

そういった取り組みが行われる中では、実装方針や設計の方向性について、メンバー間で認識がしっかり一致しているときは、高度な議論とスピード感をもって開発を進めることができます。しかし、認識にズレがあると、誰かのアイデアに引っ張られながら、ドライバーが具体的な指示に従って地道に進めるしかないという状況になりがちでした。

結果として、休憩を取りながら進めているつもりでも、いつの間にか心身の疲労が蓄積していることに気づきます。設計の方向性で意見が噛み合わないと、チームの足並みも揃わなくなり、モブプロ本来の「全員で進めている感覚」が失われていくこともありました。

さらに、ジュニアのメンバーがいる場合、知識や経験の差によって話の流れについていけず、取り残されてしまうこともあります。リモート環境では声が重なりやすく、話すタイミングを掴むのが難しいため、知識に自信がない人ほど発言しにくくなってしまいます。その結果、自然と発話が偏り、ジュニアのメンバーは黙りがちになってしまいます。

こうした課題を解決するための実験として、私たちは「10分モブプロ」を導入しました。

「10分モブプロ」導入のきっかけ

RSGT2025のOSTで、モブプロの生みの親であるクリスさんのセッションに参加した際、彼のチームでは5分交代でモブプロを行っていることを知りました。

それまで、交代の頻度・時間について深く考えたことがなかった私たちは、自分たちのチームでも試してみることにしたのです。

とはいえ、クリスさんのチームとは異なり、私たちのチームはリモート環境で開発を行っているため、交代のたびに少し手間がかかります。そのため、5分では短すぎると感じ、まずは10分でやってみることにしました。

10分モブプロの効果

実際に導入してから3週間ほど経ち、10分モブプロになれてきたタイミングでのふりかえりで、メンバーから「10分モブプロのおかげでテンポよく開発できている」といったコメントがありました。また、チーム全体のアウトプット量としてもそこまで変わっていないことがわかりました。。

10分モブプロの効果のひとつは、短い時間で交代することで、小さなサイクルを何度も回せるようになることです。これにより、「10分これに集中しよう」という選択と集中がこまめに行われ、自然と集中力が持続するようになりました。

モブのタイムスケジュール

モブプロがうまく回るようになってきた頃には、1サイクルあたりおよそ6〜7分をコーディングに使い、1〜2分で直前の状態を再現、さらに1〜2分で次にやることを決めたり、記録したり、ふりかえったりという時間配分で動くようになっていました。

最初の数分で話し合うこと

10分のサイクルが始まる前の1〜2分では、以下のような会話がよく行われます：

• 「とりあえず○○のユニットテスト書いてみようか」
• 「前回の10分で詰まったから、やり方を変えてみよう」
• 「今回はコードリーディングだけにしよう」
• 「次の10分間はリファクタリングしてみよう」
• 「この設計、本当にいいのか？この10分で調べてみる？」

ここで大切なのは、10分を使い切るムーンショットなアクションではなく、数分程度でできるよう「次の一歩だけを合意する」ということです。

10分後に得られる“観察結果”と向き直り

10分の終わりには、試したこととその結果を Issue コメントやコミットメッセージに記録したり、次にやることをチームで共有したりします。

この記録や共有のプロセスにより、「やりたかったことが達成できた」「あと少しで終わりそう」「途中で大きなバグに気づいた」「できたら考えたいことが出てきた」といった観察結果が毎サイクル得られます。このように最低でも10分毎にチームで一度立ち止まってふりかえり向き直る機会が作られることによって、チームとして以前よりも納得感を持ちながらテンポよくモブプロを進められるようになっていることに気がつきました。

交替のたびに認識を合わせるための「間」が生まれる

交替の頻度が上がることで、キャッチアップや質問の「間」が生まれ、ジュニアのメンバーが置いていかれる頻度が減りました。

たとえば、3人で30分交代制のモブプロを行うと、1人あたり約1時間はコードを書かない時間が発生します。その間に他の2人が猛スピードで進めてしまうと、交代のタイミングで「何がどうなっているのかまったく分からない」という状態になってしまいます。

ですが、10分モブプロを導入することで、10分間で集中するところが明確になることに加え、爆速で進んでしまい質問するタイミングを逃しがちだったのが、交替やドライバーになるタイミングで「間」が生まれやすくなり、改善されました。

まとめ

10分という時間枠があることで、私たちの開発の進め方を「次のコミットで何をするか」という視点に集中することができました。モブ中に「現状から次にやること」だけを話すことで、チーム全体の集中力が向上しました。こうした小さな実験の積み重ねによって、開発の質そのものも高まっていったと実感しています。また、ドライバーとして手を動かす回数が増えたことで、理解が深まり、学習効果も上がりました。

おわりに

私たちのチームでは、「10分交代のモブプロ」によってコンテクストの共有と集中力の維持が格段に向上しました。「10分でできることは限られている」という共通認識があるからこそ、「次はこれをやってみよう」と自然に声が出るようになったのだと感じています。

ただし、私たちのチームでは10分がマッチしましたが、チームの能力・環境などによっては10分よりも (短かい | 長い) 時間が適している可能性もあります。

もし、今モブプロをやってみていて課題を感じているなら、ぜひ「交替時間を変えてみる」というアプローチも一度試してみてください。