BMAD Method は、アナリスト・PM・アーキテクト・開発者などの役割を持った AI エージェントと対話しながら、要求整理から設計・実装までを進めていく開発手法です。
とりあえず試してみました。

要約

なお、基本的に AI に勧められるがままに進めたので、使い方やプロンプト次第で印象は変わると思います。

作ったもの

自分用のタスク管理ツールを作ってみました。人によって困りごとが違う領域なので、個人用に特化させるのは設計能力が試される課題だったと思います。

設計までは要求の深掘りや研究事例からの裏付けなども行なってくれて、満足感が高かったです。
一方で実装については、自分用なのでサクッと作りたいという思いもあり、BMAD での実装は足が重く感じてしまいました。

どのくらい待てばいいかの目安がないため、中途半端に待たされます。
プロンプトがすぐに進むことはあまりなく、数分待つと結果が出てくる感じです。
かといって 10 分放置してから確認すると、許可が必要な場面で止まったままになっていたりします。

5 分で生成された文書を 1 時間かけて読むことになったりして、AI とのスピード感の差がプレッシャーになることがあります。
気軽に AI 主導で始めると、自分がボトルネックになる状態がなんともいたたまれない...
気にしなくていいんですけどね...

待ち時間の話と被りますが、実装スピードも遅いと感じました。
要求整理・設計は対話形式が多いので遅いとは感じませんでしたが、素の Claude Code で実装させた場合と比べるとだいぶ遅く感じます。

出力メッセージを読む限りだと、内部的にレビュー役のエージェントがチェックして、OK ならユーザーに返しているようです。ただ、その待ちが長いうえに、私がチェックして差し戻すとまた待つことになるので、手間がかかる印象を受けました。
ドラフトの段階でも早めに読ませてもらえた方がうれしかったです。

分かりにくかったのは、BMAD 自体の流れと実装の順序の 2 つです。

BMAD の流れはなんとなく知っている程度で始めましたが、大体わかっている前提でチャットが進むので、全体の中で今どこにいるのかが分かりにくかったです。
設計が進んでいることはわかるし、次の操作がこれなのも納得できる。でも、あとどのくらいで終わるのかがわからない、という状態で進んでいきました。

実装の順序は提示されるままに進めたので、正直あまり覚えていません。
実装計画がわかりやすいところに無かったのが問題だったかなという気がします。

という流れでした。

BMAD にはスクラムマスター役のエージェントや進捗確認用のワークフローもあるらしいので、私が使いこなせていなかっただけかもしれません。

最初に「こういうことがしたい」を伝えるのですが、実際の困りごとや現状のヒアリングをちゃんとしてくれる印象です。
今回は「タスク管理ツールを作りたい」から始まり、

実際に困った場面のヒアリング
本当の問題点の発見
- タスクを切り替えた後も、前のタスクが頭に残る（次のタスクの選択では困っていない）
- タスクリストが肥大化し、リストを見たときに全部のタスクが頭に残る
- 放置されたタスクが罪悪感を引き起こす
「attention residue（注意残余）」として研究された事例の調査¹
問題点と調査結果を踏まえた設計
- 切り替えの速さは重視せず、「完了の意識」や「中断の負荷軽減」に集中する
- タスクリストに出す情報を絞る
- 放置されたタスクは非表示にしていく（別のところで管理する）

といったことをやってくれました。

各段階での決定事項や、意思決定の背景事情などを文書化してくれます。
自分で作ると大変なのでありがたいです。

問題点・要求事項・機能のそれぞれに番号を振り、関係性を紐づける形で文書化されていて、かなりしっかりした印象を受けました。

プロジェクト全体の進捗率は見えませんが、「今何をしたか」「次はこれが良さそうです」は提示してくれます。

BMAD は要求整理から実装までしっかりと進めてくれる仕組みです。ただし AI に任せきりにすると、AI の提案を聞いて AI の出力を待つばかりになり、ストレスになることもあります。

次に使うときは、進行管理を意識して次のようなことを試してみようと思います。