AIでコードを書くのは速くなった。一方で、仕様決めのAI壁打ちには少し飽きてきた。同じように感じている人、いませんか？
「これどう思う？」と聞くと丁寧に答えてくれるし、「他の案は？」と聞けば、3つくらい出してくれる。非常に便利になったと理解しています。
でも、なんだろう、このインタビューしてる感。自分がずっと聞き手で、AIがずっと回答者。1対1の問答がずっと続く。
この記事では、BMAD-METHODと呼ばれる、ディスカッション形式でAI駆動のアジャイル開発を進めるOSSを活用し、これらの課題を解決する方法について紹介します。
チャットで育った世代の違和感
思えば自分たちの世代は、Slackなどのチャット文化で育ってきたと思っています。
誰かが発言すると、別の誰かが「いや、それよりこっちじゃない？」と返す。そこに第三者が「両方試せばよくね？」と入ってくる。
同意された時、ひどく批判された時、色々ありましたが、あのテンポ感が自分には合っていました。
あのザワザワした感じの中でこそ、アイデアが磨かれてきた。
なのにAIとの対話は、壁に向かってボールを投げているような感覚。
返ってはくるけど、いきいきとした会話がない。
BMAD-METHODという選択肢
BMAD-METHODは、AI駆動のアジャイル開発フレームワークとして作られたOSSです。
ざっくり言うと：
- PM、アーキテクト、開発者、UXデザイナーなど12以上の専門エージェントが定義されている
- 分析 → 計画 → 設計 → 実装の4フェーズが型として用意されている
- 各フェーズで適切なエージェントが登場し、ディスカッション形式で進行する
正直に言うと、Claudeに「PMの視点でレビューして」と頼めば同じようなことはできます。
BMADの価値は、それを毎回自分で考えなくていいところ。レシピ本みたいなものです。料理の腕（AI）は同じでも、手順があると失敗しにくい。
上述のような価値は大事です。しかし、私が一番注目しているのはそこではありません。
BMADはペルソナを設定することで、AIの中に疑似チームを作れる。PM、アーキテクト、QA...それぞれの専門家が、それぞれの立場で意見をぶつけ合う。
しかも、各ペルソナの性格やチーム全体の雰囲気まで自分で決められる。
慎重なアーキテクトと攻めのPM、みたいな組み合わせも自由自在です。
つまり、自分の手元にあっという間に理想のチームが出来上がってしまう。
採用も調整もいらない。これが壁打ちとは決定的に違うところです。
実際のディスカッションを覗いてみよう
では、BMADを使うと実際にどんな会話が生まれるのか。自分のターンが来るまで、チーム全員が勝手に会話を進めてくれるイメージです。
たとえば、タスク管理アプリを開発中にクライアントから「編集ボタンをつけてほしい」と要望が来たとします。
BMAD（ディスカッション）：
PM：クライアントから「タスクに編集ボタンをつけてほしい」って要望が来てるんだけど
自分：了解、じゃあ編集機能つけようか
UXデザイナー：ちょっと待って。何を編集したいの？タイトル？ステータス？全部？
自分：えーと...聞いてないな。たぶん全部？
アーキテクト：全フィールド編集可能にすると、変更履歴の管理とか権限まわりが一気に複雑になるよ
ジュニアエンジニア：あ、それ僕が実装する側なんですけど...編集の取り消し機能とかも要ります？正直けっこう重いです
PM：そもそもなんで編集したいんだろう。タスクの書き間違いを直したいだけなら、作成後5分以内だけ編集可能とかでよくない？
UXデザイナー：あるいはステータス変更だけなら、ドラッグ＆ドロップで十分だよね。わざわざ編集画面を開かせる必要ある？
QA：ちなみに編集機能つけると、テストケースが爆発するよ。権限×フィールド×状態の組み合わせで。本当に必要なら覚悟してね
アーキテクト：ドラッグ＆ドロップなら実装もシンプルだし、APIも薄くて済む
PM：一回クライアントに「編集で具体的に何がしたいですか？」って聞き返した方がよさそうだね
自分：たしかに。「編集ボタン」って言われてそのまま作るとこだった。聞いてみるわ
コードを1行も書く前に、こんなやりとりが勝手に始まる。
1対1の単調なやりとりと違って、会話にリアリティが生まれる。
気づいたら没頭していて、アイデアに磨きがかかっている。
Slackで育った世代の自分にとって、これが何より大きなメリットだと感じています。
没頭できるから、アウトプットが変わる
壁打ちとディスカッション、やっていることは似ているかもしれません。でも体験がまるで違う。
壁打ちは「自分が次に何を聞くか」を常に考えなければいけない。
ディスカッションは、勝手に議論が転がっていく中で「お、それいいね」「いや、ちょっと待って」と参加するだけ。
この没頭感が、実はいちばん大きなメリットだと思っています。
集中のスイッチが入りやすい。
考えるべきことに集中できる。
結果として、アウトプットの質も上がる。「ツールの性能が上がった」のではなく、自分のパフォーマンスが上がる。そういう種類の改善です。
まとめ
BMAD-METHODは魔法のツールではありません。Claudeにできないことを可能にするわけでもない。
でも、AIとの協業を「壁打ち」から「チーム開発」に変えてくれる。チャット世代の自分にとって、それだけで十分に価値がありました。
壁打ちに飽きたあなたへ。一度、会議に参加してみませんか。
Author
その他おすすめ記事
FastAPI × Diffusers でローカル完結の「顔属性変換」学習アプリをつくる
生成 AI を「使う」だけでなく「アプリに組み込む」とどうなるのか。これを手を動かして理解したくて、人物写真をアップロードすると顔の属性（性別的な見た目）だけを別の性別に変換する学習用 Web アプリを個人で作りました。外部の画像生成 API には一切頼らず、推論まですべてローカルで完結させているのが特徴です。本記事では、その構成と実装上の判断、つまずいた点を技術寄りに整理して共有します。 なぜ「ローカル完結」にこだわったのか 顔写真は最もセンシティブな個人データのひとつです。学習目的とはいえ、自分や知人...
AIで生演奏のピッチ検出を試してみた
さて。このAI全盛期、我が社でも例に漏れずAIをうまく使っていこうという流れがきているため、AIを使った技術の検証をしてみようと思います。 どうせなら自分に身近なテーマを、ということで長らく趣味で習っているヴァイオリンのピッチ判定ができたら面白そうです。 調べてみたところいくつか使えそうなAIモデル(CREPE、Basic Pitch)があったため使えるか検証していきます。 また、比較用としてAIを使っていない従来の方式のaubioも試してみましょう。 はてさて、全てうまく動くでしょうか...。 環境構...
