はじめに：モブプロ、疲れていませんか？

「モブプログラミング」は素晴らしい手法です。
知識の共有、フロー効率の向上、チームワークの強化。
しかし、実際に現場で運用してみると、こんな悩みに直面することはありませんか？

空中戦になる
知識のあるメンバーだけで議論が進み、若手が置いてけぼりになる。
タイピング競争
ドライバーのコーディング速度に思考が追いつかず、ただ画面を眺める時間が増える。
結局、疲れる
常に全員でコードを書き続けるのは、体力的・精神的にコストが高い。

私の所属するプロジェクトでも、同様の課題を感じていました。
そこで、「実装」ではなく「設計」にフォーカスして全員で集まる 新しい開発フローを考案し、これを 「ブループリント・ジャムセッション（Blueprint Jam Session）」（以下、BJ）と名付けました。

この記事では、まだ世の中にないこの新しい手法について、私たちが試験導入している事例をもとに紹介します。

ブループリント・ジャムセッション（BJ）とは？

一言で言うと、「実装の前に『設計図（ブループリント）』を全員で協力して作り、合意形成するセッション」 です。

従来のモブプロとの最大の違いは、この場では 「完成したコードを書くこと」を目指さない 点です。

名前の由来：なぜ「ジャムセッション」なのか？

この名称は、 ジャズの「ジャムセッション」 に由来しています。

楽譜通りにただ演奏するのではなく、ゴール（曲の終わり）に向かって、メンバーそれぞれがその場で感じたままに音（意見）を出し合う。時にぶつかり、時に調和しながら、一人では決して到達できない「相乗効果」によってより良いグルーヴ（成果物）を作り上げる。

そんな「チーム開発ならではの醍醐味」を設計フェーズに取り戻したい、という想いを込めました。

キーコンセプト：AIをドライバーにする

BJの肝は、人間がコードを書かないことです。

ドライバー：AI (GitHub Copilotなど)
ナビゲーター：人間（チーム全員）

人間は「どういうインターフェースにするか？」「クラス設計はどうあるべきか？」という思考と議論に100%集中します。
コードの生成はAIに任せることで、「タイピングが遅いから」「文法に自信がないから」といった理由で発言を躊躇する必要がなくなります。全員が対等な演奏者（ナビゲーター）として参加できるのです。

既存のXP（モブプロ）と何が違うのか？

「これってただのモブプロでは？」と思われるかもしれません。しかし、AIをドライバーに据えることで、焦点やボトルネックが大きく変化しています。

比較項目	従来のモブプロ / ペアプロ	ブループリント・ジャムセッション (BJ)
ドライバー	人間 (タイピングと微細な思考が必要)	AI (指示通りに即座に出力)
ナビゲーター	ドライバーへの詳細な指示 + 全体設計	設計と合意形成に100%集中
最大の焦点	「動くきれいなコード」を完成させること	「全員が納得した設計図」を作ること
ボトルネック	人間の入力速度、言語化のコスト	人間の意思決定スピード
疲労感	常に実装と思考を同期させるため高い	議論に集中する疲れはあるが、実装の単純作業疲れはない
適したフェーズ	詳細実装、デバッグ、リファクタリング	要件定義、基本設計、インターフェース設計

従来のモブプロが 「実装の質と知識共有」 を同時並行で行うのに対し、BJは 「設計の合意形成」 に特化し、実装（詳細なコーディング）はAIや個人のフロー状態に任せるという「分離」を行っている点が大きな違いです。

具体的な進め方

私のチームでは、以下のフローで試験運用を行っています。

1. 対象範囲と時間の考え方

ここが非常に重要です。私たちは、個々の小さなタスク（チケット）単位ではなく、「ひとつの機能」や「ひとつの施策」単位でBJを実施しています。

スコープ： ゴール（リリース）から逆算し、その機能全体をどう作るか？という粒度で扱います。
時間配分： 厳密には決めていません。
- 軽い会話で全員の認識が揃えば、5分で終わることもあります。
- 複雑な機能設計であれば、1日〜2日かけてじっくり行うこともあります。
理由： これは「設計作業」だからです。モブプロのような実装スピード勝負ではなく、 「全員が腹落ちし、納得できる状態」 になることがゴールだからです。ここで時間をかけることが、後の手戻りを防ぐ投資になります。

2. 【Phase 0】計画ジャムセッション 🎼

まずは全員で「何を作るか」のタスク出しです。リリース目標から逆算し、必要なタスクを議論しながら細分化します。
ここで「誰が何をするか」ではなく「チームとして何を倒すか」を可視化します。

3. 【Phase 1】設計ジャムセッション 🎸🥁（ここがメイン！）

タスクごとに集まり、AIをドライバーにして「骨格コード」を作ります。

進め方:
1. 画面共有者がAI（GitHub Copilot等）を開く。
2. 「この機能のデータ構造はどうする？」「インターフェース名は？」と全員で議論。
3. 合意した内容をAIに指示し、クラス定義、メソッドの型、処理の概要コメントなどを出力させる。
4. 出力結果を見て「あ、この例外ケース抜けてるね」と気づき、修正指示を出す。
成果物:
- 全員が合意した 「実装の設計図」 となるスケルトンコード。

4. 【Phase 2】個人実装フェーズ 🎧

作成された「設計図」を持ち帰り、各々が詳細ロジックを実装します。
すでに方針は合意済みなので、迷いなく「ゾーン」に入って実装作業に集中できます。
もし実装中に大きな方針転換が必要になった場合は、独断で進めず、チームに相談します。

5. 【Phase 3】レビュー

設計方針のズレがないため、PRレビューでは「設計思想の衝突」による手戻りがなくなります。
レビュアーは、バグの有無やパフォーマンス、エッジケースの考慮など、より本質的な品質チェックに集中できます。

導入のメリット：なぜやるのか？

最大の目的は 「手戻りの撲滅」 です。

レビューコストの激減: 「そもそも設計が違う」という絶望的な手戻りがなくなります。
属人化の解消: 実装前に全員で設計を握るため、誰が担当しても一定の品質が担保されます。
心理的安全性の向上: 「これで合ってるかな…」と不安になりながら実装する時間がなくなります。

想定するQ&A

Q. 最初から分担して実装したほうが速いのでは？
A. 短期的にはそう見えます。しかし、手戻りや後の技術的負債の解消コストを含めると、トータルのリードタイムは短縮されます。これは 「急がば回れ」をシステム化したもの です。

Q. 意見が対立したら？
A. それこそがBJの価値です！実装後に「やっぱりあっちが良かった」となるより、設計段階で戦わせる方が傷は浅いです。目的は「論破」ではなく「より良い第3の案」をチームで見つけることです。

工夫：夕方相談タイム
実装は個人作業ですが、「困ったときにすぐ聞けない」状況を防ぐため、夕方に任意の「相談タイム」を設けています。任意参加ですが、現時点の参加率はほぼ100%です。
毎日何かしらの課題がここで解消されるため、不安を翌日に持ち越さずに済むという精神的なメリットも大きいです。

現在の課題と、未来への展望

実際にやってみて見えてきた「課題」と、それを踏まえた「未来の可能性」について触れておきます。

課題：プロンプト入力というボトルネック

現状、AIへの指示出しは「キーボード入力」です。
そのため、画面共有者が皆の意見を聞いてタイピングする時間がどうしても発生し、 「プロンプト入力ドライバー」 のような役割になってしまうという課題があります。議論のテンポがタイピング速度に依存してしまうのです。

展望：音声入力 × 仕様駆動開発エージェントで「真のジャムセッション」へ

しかし、この課題は近い将来解決すると信じています。
AIエージェントに対して、 「音声（自然言語）」 で指示が出せるようになれば、BJは真価を発揮します。

メンバーが口々にアイデアを出す（ジャムセッション）。
AIがそれを聞き取り、リアルタイムで設計図（仕様）を更新する。
完成した仕様を「仕様駆動開発（Spec-Driven Development）」のエージェントに渡す。

まるで人間同士がホワイトボードの前で議論するように、声でAIとセッションし、その場でシステムが組み上がっていく。
キーボードから解放された時こそ、この手法は 「AI時代のXP」 として完成するのではないかと考えています。

「Garbage In, Garbage Out（ゴミを入れたらゴミが出る）」
AIエージェント時代において最も重要なのは、「AIに渡す仕様（ブループリント）の質」 です。

一人で書いた曖昧な仕様をAIに投げても、期待通りのものは出てきません。だからこそ、「チームの集合知を結集し、最高品質の設計図を作り上げる」 というBJのプロセスが、AI全盛期におけるエンジニアの最もコアな仕事になっていくはずです。

おわりに：AIから、BJへ

私のチームでもまだ試行錯誤の段階ですが、すでに「レビューが楽になった」「手戻りが減った」という手応えを感じ始めています。

最後にあることに気づきました。
Artificial Intelligence（AI）のアルファベットを、それぞれひとつ先に進めると...

A の次は B
I の次は J

そう、AIの次は BJ（Blueprint Jam Session） なのです！

AIに使われるのではなく、AIと共に進化する次世代の開発フロー。
AIにコードを書かせるこの時代、私たちはもっと人間らしい仕事をしませんか？