前回のおさらい
前回の記事では、「ブループリント・ジャムセッション（BJ）」という手法を提案しました。
「実装はAIに任せ、人間は設計と合意形成に集中する」 という考え方です。
記事の最後で、こんな展望を書きました。
AIエージェントに対して、「音声（自然言語）」で指示が出せるようになれば、BJは真価を発揮します。
あれから時間が経ち、音声入力の精度は飛躍的に向上しました。AIエージェントの実装能力も格段に上がりました。
そこで今回は、BJを現場でどう回すか—— より具体的で泥臭い話をします。
テーマはひとつ。
「チーム開発で、いかに ”人起因の手戻り” を減らすか」 です。
チーム開発のボトルネックは、コードではなく「方針のズレ」
個人で開発しているとき、手戻りの原因は大体「技術的な見落とし」です。
ところが複数人で開発すると、手戻りの原因が変わります。
「あれ、そういう方針だったの？」
これです。
設計方針のズレ。ゴールの解釈違い。暗黙の前提条件のすれ違い。
コードの品質がどれだけ高くても、そもそも向かっている方向が違えば、全部やり直しです。
しかもこのズレは、コードレビューの段階で初めて発覚することが多い。実装が終わった後です。
つまり、最もコストが高いタイミングで爆発します。
私たちが日々戦っている本当の敵は、技術的な複雑さではなく、人と人の間に生まれる認識のギャップなのです。
解決策は単純。「ズレがなくなるまで話す」こと
じゃあどうするか。答えはシンプルです。
タスクのゴールと実装方針について、認識の齟齬がなくなるまで対話する。
「そんなの当たり前じゃないか」と思うかもしれません。
でも、現実を振り返ってみてください。
...
チケットに要件を書いて、担当者にアサインして、あとはよろしく
「まぁこのくらいは言わなくてもわかるでしょ」
Slackで軽く方針を共有して、それで合意したつもりになっている
...
心当たりはありませんか？
問題は「対話が足りない」ことではなく、「対話したつもりになっている」 ことです。
テキストベースのやり取りでは、書き手の意図と読み手の解釈の間に、思っている以上のギャップが生まれます。
だからこそ、声を使って、リアルタイムで、お互いの理解を確認し合うことが必要なのです。
そしてここに、「音声入力 × AI」の組み合わせが強烈にハマります。
新しいBJフロー：対話 → 詳細設計 → 実装 → レビュー
前回の記事で提案したフローを、音声入力とAIエージェントの進化を踏まえてアップデートします。
【Phase 1】対話で設計方針を固める
ここがBJの心臓部です。
チームメンバーが集まり、タスクのゴールと実装方針について話し合います。
キーボードは使いません。声で話す。 それだけです。
音声入力の精度が上がった今、会話をそのままテキストに起こすことは容易です。
私はNotionのAIミーティングノートを使って会話の内容をテキストに起こしています。
大事なのは、以下の状態になるまで対話を終わらせないこと。
- 「何を作るのか」 が全員同じ言葉で説明できる
- 「どう作るのか」 の大枠について合意がある
- 「なぜその方針なのか」 の理由を全員が理解している
5分で終わることもあれば、1時間かかることもあります。
時間の長さは問題ではありません。全員が腹落ちしているかどうかが唯一の判断基準です。
ここで生まれるのは、整った設計書ではなく、チームの会話ログです。
多少雑でも構いません。認識が揃っていることの方が、ドキュメントの美しさより100倍重要です。
【Phase 2】AIに詳細設計を生成してもらう
Phase 1で生まれた会話ログ（音声入力で記録されたテキスト）を、AIに渡します。
ここでAIにお願いするのは2つ。
会話の内容を詳細設計に変換する
クラス設計、データ構造、インターフェース、処理フローなど、実装に必要な粒度まで落とし込む
抜け漏れ・不明点を指摘してもらう
「このケースのエラーハンドリングについて言及がありませんが、どうしますか？」
「A画面からB画面への遷移時に、データの受け渡し方法が未定義です」
AIは対話の文脈を読み取り、人間が見落としがちな隙間を埋めてくれます。
ここが重要なチェックポイントです。
AIが出力した詳細設計を、チームで確認してください。
Phase 1で合意した方針からズレていないか？ を見るのです。
人間同士の会話は、しばしば曖昧さを含みます。「なんとなくこういう感じ」で合意していた部分が、詳細設計に落とし込む段階で矛盾として現れることがあります。それを、ここで潰します。
方針のズレが見つかったら？
Phase 1に戻ってください。遠慮は不要です。
ここで戻るコストは、実装後に戻るコストの10分の1以下です。
【Phase 3】AIに実装・テストを任せる
方針チェック済みの詳細設計をAIエージェントに渡し、実装とテストを行ってもらいます。
ここでのポイントは、AIに丸投げして終わりではないということ。
AIは詳細設計という「正解」を持っています。だから、こういうサイクルが回せます。
- AIが詳細設計に基づいてコードを生成する
- AIが詳細設計に書かれた要件に対してテストを書き、実行する
- テストが通らなければ、AIが自分でコードを修正する
要件を満たすまで、このサイクルを繰り返す
人間がやることは、詳細設計と実装の整合性を適宜確認することです。
AIが迷走していないか。詳細設計に書いていない独自の判断をしていないか。
設計図通りに建てられているかを、現場監督として見守ります。
【Phase 4】AIレビュー + 人間レビュー
実装が完了したら、まずGithub CopilotなどのAIにレビューを依頼します。
AIレビューでは、コードの品質、セキュリティ上の懸念、パフォーマンスの問題、エッジケースの考慮漏れなど、機械的に検出できる項目を洗い出してもらいます。
その後、人間のレビュアーが確認します。
ここで人間のレビュアーがやることは、従来と根本的に変わります。
「設計方針はこれでいいのか？」を議論する必要がない。
なぜなら、Phase 1で方針は合意済み。Phase 2で詳細設計も確認済み。
レビュアーは、期待通りの動作になっているかどうかを確認するだけです。
問題がなければ、マージ。
このフローの本質：3つの「減らす」
ここまで読んで「フローが増えたじゃないか、面倒だ」と感じた方もいるかもしれません。
しかし、このフローが削減しているものを整理してみてください。
1. 認知負荷を減らす
従来のチーム開発では、一人のエンジニアが「要件理解」「設計」「実装」「テスト」「レビュー対応」のすべてを頭の中で回す必要がありました。
BJフローでは、各フェーズでやることが明確に分離されています。
対話のフェーズでは対話に集中する。設計はAIが構造化する。実装もAIが担う。
人間は「今このフェーズで何を判断すべきか」だけに集中できます。
2. 方針ブレによる手戻りを減らす
手戻りの最大の原因である「設計方針のズレ」を、フローの最上流で潰します。
しかも、一度だけではなく、Phase 2（詳細設計の確認）で二重チェックが入ります。
実装後に「そういう方針だったっけ？」が発生する余地を、構造的に排除しているのです。
3. 個人の知識への依存を減らす
「この設計はAさんしか知らない」「あのモジュールの仕様はBさんに聞かないとわからない」
こういった属人化は、チーム開発において最も根深い問題のひとつです。
BJフローでは、設計方針がPhase 1の対話で共有され、Phase 2で詳細設計として文書化されます。
「誰かの頭の中にしかない知識」が、チームの共有資産としてアウトプットされるのです。
AI時代のチーム開発とは何か
AIがコードを書ける時代になって、エンジニアの仕事は変わりました。
でも、チーム開発の本質は変わっていません。
「複数の人間が、同じゴールに向かって、整合性のあるシステムを作る」
この営みにおいて、最も難しいのは昔も今も「人と人の認識を揃えること」です。
AIは実装を加速させてくれます。テストも書いてくれます。レビューもしてくれます。
しかし、チームメンバー間の認識のズレを、AIが勝手に解消してくれるわけではありません。
だからこそ、私たちがやるべきことは明確です。
- 声を使って対話し、認識を揃える
- 揃った認識をAIの力で構造化し、設計に落とす
- 設計をAIに渡し、正確に実装してもらう
- 人間は「方針通りか」「期待通りか」の判断に集中する
これが、AI時代のチーム開発です。
人間は「何を作るか」「なぜ作るか」を決め、AIは「どう作るか」を実行する。
その間を繋ぐのが、チームの対話から生まれた、質の高い設計図です。
おわりに：キーボードを置いて、話そう
前回の記事で、私はこう書きました。
キーボードから解放された時こそ、この手法は「AI時代のXP」として完成するのではないか
今、その時が来ています。
音声入力でチームの対話を記録し、AIが設計書に変換し、AIが実装する。
人間はキーボードを叩く代わりに、チームメンバーの目を見て話す時間が増える。
なんだか逆説的ですよね。テクノロジーが進化した結果、私たちがやるべきことは 「ちゃんと話す」 という、一番アナログで、一番人間らしいことだったのです。
手戻りを減らしたい。属人化を解消したい。もっと良いものを作りたい。
その答えは、最新のツールの中ではなく、チームメンバーとの対話の中にあります。
AIから、BJへ。
キーボードを置いて、話しましょう。