【アジャイルFAQ 今日は実験室】「AIいいなり開発」への不安を、BMADは解消してくれるのか？（前編）

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。
 前回の番外編「日本式アジャイル撲滅」では、AI駆動開発が日本式アジャイルの新しい看板になりかねない、と書きました。今回は、それに続く「実験室」です(…って、本線に戻るのはいつなのか…)。
 私は長らく、ユースケースやストーリーを使った要求管理といった”上流工程”を専門にしてきました。何を作るか（What）がどう決まり、言語化されていくかが、ずっと仕事の中心でした。そんな私にとって、昨今のAI駆動開発は、「ともすると”いいなり”になっちゃうあやうさ」を秘めたものに見え、あぶなっかしくみえていたのでした。
 しかし、開発におけるAIの適用領域が爆速で拡大していくなかで、私の専門領域に入ってくるとなれば、気にならないはずがありません。

 そこで、この実験室では、ここしばらく（マジで）ハマっている BMAD Method（以下、BMAD）を実際に試してみます。手っ取り早く知りたい人と、自分でも試したい人の両方がいると思うので、前編は実際のやり取りの例と評価、後編は試してみたい人向けの手順書（深みもなにもない）としました。
 評価の観点は、次の3つです。

1. いいなりになると、どうなるか
2. AIとの対話は、成立するか
3. その対話は、単なる質疑応答ではなく、人の側のアイディアを洗練させる助けになっているか

• 観点1：人が何も答えずに進めても、道具は推測に印を付け、確かめるべき問いを残しました。ただ、その推測をもとに586行の要求仕様までできあがっており、人が答えてみると、前提の多くが実際とは違っていました
• 観点2：対話は成立しました。AIは聞いたことを言い直して確かめ、答えに応じて次の問いを変え、「分からない」という答えも受け止めました
• 観点3：洗練の助けになりました。お題は「サイトを新しく作る」から「今あるサイトが使われない理由を探る」に書き換わり、私の見立ては「確かめるべき仮説」に置き直されました。ただし洗練は一方通行ではなく、AIの提案を人が直す場面も同じくらい大事でした

 道具が問いを立ててくれても、答えるのは人です。答えないまま進めば、結局は「AIいいなり」に近づいてしまいます。

 BMADは Breakthrough Method for Agile AI-Driven Development の略で、オープンソースのAI駆動開発の手法です。Claude Code のようなコーディング用のAIツールに組み込んで使います。
 AIのエージェントを開発チームの役割に見立てて使い分け、それぞれが自分の段階の文書を作って次の段階に渡していくのが特徴です。

 規模に応じて計画を省くこともでき、どの段階でも、誰が何をどう決めたかが記録ファイル（.memlog.md）に一行ずつ残ります。
 この記事で見るのは、表の分析と計画の段階、つまり仕様が決まる「前」をBMADがどこまで支えてくれるかだけです。設計や実装、コードの品質、他の手法との比較は扱いません。

 お題は、架空のソフトウェアベンダーのこんな要望です。

当社製品の利用者向けのサポートサイトを作り、顧客の利便性を最大化したい。

 起点は、たったこれだけ。
 これを二通りで通しました。実験1で観点1を、実験2で観点2と3を確かめます。

 表の「決定の記録」は、前述の記録ファイルに残った行の数です。「推測の印」は、観点1で詳しく説明します。

 BMADはかなりの量の文書を出力するので、この記事で紹介する出力は、いずれも要所の抜粋です。全体は、ぜひ後編の手順で実際に試して確かめてみてください。
 まず、実験1の製品概要の冒頭です。

当社製品の利用者が、困ったときに自分で答えを見つけられ、見つからなければ迷わず人にたどり着けるサポートサイトを作る。依頼にある「利便性を最大化」は、このままでは測れない。そこでこの概要では、困りごとが早く、確実に解決することと言い換える。
調べた限り、問題は「サポートサイトがない」ことよりも「あっても見つからない」ことにある。セルフサービスで完全に解決した問い合わせは14%にとどまり、失敗の最大の理由は「関連する情報が見つからない」（43%超）だった（Gartner、2024年）。

 正直に言って、よくできています。AIは誰にも聞かずにWeb調査まで行い、測れない「利便性の最大化」を測れる言葉に言い換えていました。推測の箇所には、きちんと印も付いています。
 ここで「推測の印」を説明しておきます。BMADのAIは、人に確かめていないことを推測で書いたとき、その箇所に [ASSUMPTION]（英語で「仮定」）という印を付けます。「ここはAIの推測で、まだ誰も確かめていない」という目印です。人に質問しない実験1では、分からないことをすべて推測で埋めるしかないため、この印が多く付きます。また、推測では埋められず、人にしか答えられない問いは、文書の末尾に「未確認の問い」としてまとめられます。
 実際の課題の節はこうです。見出しの横に付いている [ASSUMPTION] が、その印です。

当社側 [ASSUMPTION]

• 同じ質問が繰り返し届き、サポート担当者の時間がそこに取られる。
• 回答がどこにも残らないため、次の担当者に引き継がれない。

 末尾の「未確認の問い」には、まさに確かめるべき問いも残っていました。

3. 既存のFAQ・マニュアル・問い合わせ窓口は何があり、誰が管理しているか。
4. 目的は顧客満足か、サポートコストの削減か。両方なら、ぶつかったときにどちらを優先するか。

 続けて作らせたPRDは586行。機能要求は27件に番号が振られています。PRDには、利用者が製品をどう使うかを、名前の付いた人物の物語として書く「利用場面（ユーザージャーニー、UJ）」という節があり、その1つ目はこう始まります。

UJ-1. 経理担当の佐藤さんが、月末の締め作業の途中で出たエラーを自分で片づける。
佐藤さんは当社製品を毎月の締めに使う経理担当者。製品には詳しくない。締め切りが迫っている。

 「佐藤さん」は、製品概要には出てきません。PRDのこの節の冒頭に、AI自身がこう注記していました。

製品概要には利用者が実際に使う場面の記述がない。以下は製品概要の「誰のためか」「つくるもの」から組み立てた想定である。

 つまり佐藤さんは、PRDの段階でAIが新たに思い描いた人物で、推測の上にさらに推測が重なっています（この場面にも、もちろん推測の印が付いています）。では、実際はどうだったのか。実験2で私が答えた内容と並べます。

 公平のために書くと、道具はやるべきことをやっています。ただ、推測の印は、人が読んで確かめてこそ意味があります。 印を確かめずに次へ渡すと、27件の機能要求が、実際にはいない「サポート担当者」や「経理担当の佐藤さん」を前提に組み上がってしまうおそれがあります。
 いいなりで気をつけたいのは、間違った文書ができることより、もっともらしい文書が、確かめられないまま次の工程の前提になりやすいことです。

 実験2で同じ要望を渡すと、アナリストはいきなり文書を作らず、まず頭の中を全部出すように求めてきました。私が製品のこと、いまの問い合わせの流れ、きっかけ、優先したいことを思いつくままに書くと、聞いたことを表にまとめ直して返してきました。

 聞いたことを言い直して確かめ、どこに引っかかっているかを示す。上手な聞き手がやることと同じです。「速い道」を選ぶと残りの不明点を6問にまとめて聞かれ、私が「不明」と返したところは、推測の印付きで埋めるか「分かっていないこと」として残しました。後から送った追加の答えも、きちんと反映されました。
 対話は成立します。 ただし「速い道」では問いがまとめて来るので、やり取りは質疑応答に近づきます。ちなみに、一問ずつ押し返されながら進む「じっくりの道（Coaching path）」という進め方もあります。ぜひ皆さんで試してみてください。

 いちばん知りたかったのは、ここです。

お題が書き換わり、手段の選択肢が広がった

 「簡単なサイトは既にある」と答えた時点で、アナリストはお題を「今あるのに使われていない理由を探る」に書き換え、こう付け加えました。

操作の質問が多く、利用者が作業の途中だとすると、「サイト」という形自体が正しいかどうかも後で問い直すかもしれません。

 実際、のちに「範囲はサイトだけか、製品の画面から呼び出すヘルプまで含めるか」と、同業他社の調査結果を添えて聞いてきました。私は「早く公開することを優先しているので、まずはサイトだけ」と答えています。選択肢を広げたのはAIで、選んだのは私です。

見立てが、仮説に置き直された

 「いまのサイトが役に立たないのはなぜか」に、私は「記事が足りない、探しにくいのだと思う」と答えました。製品概要には、こう書かれました。

「操作の質問が多い」「記事が足りない、探しにくい」は、どちらも見立てであり、確かめた結果ではない。

 否定もせず、事実扱いもせず、「まず確かめるもの」に置き直す。第3回から第5回で「現行機能」をまず確かめる話をしましたが、同じ動きが要望の段階で起きています。

物差しが、使えるものになった

 満足度は「アンケート、解約、更新時の声を総合的に勘案して判断している」と答えると、アナリストは「結果が出るまで時間がかかる指標なので、手前で早く動く指標を置きました」と、解決までの時間などを足してきました。作り直したサイトが効いているかを途中で確かめる手立てがないことに、言われて初めて気づきました。

答えられない問いが、残った

 下書きのあと、アナリストはいちばん弱い点を押し返してきました。

記事を書き、更新し続けるのは誰ですか？
サポート担当がいないまま記事づくりを開発者に頼むと、「質問に答える負担」が「記事を書く負担」に変わるだけです。

 私は答えられず、「いまは決められない」とだけ返しました。それは製品概要の「分かっていないこと」の先頭に残りました。答えの出ていない問いを、いちばん目立つ場所に置くことも、洗練のうちだと思います。

洗練は、一方通行ではなかった

 逆向きの場面もありました。アナリストは下書きの冒頭で、お題を「操作の質問を、人に聞かずに短い時間で解決できるようにする。残る質問は開発者ではない窓口が受ける」と言い換えていました。そして仕上げの段階で、それがまだ私の了承を得ていない提案であることを申告してきました。読み返すと、開発者が流れから抜け落ちていました。実際には、一次窓口で受けきれない問い合わせは開発者にエスカレーションしますし、AIも活用したい。そう伝えると、言い換えは次のように修正されました。

操作の質問の多くを、利用者がサイトで（AI の助けも借りて）短い時間で自己解決できるようにする。自己解決できない質問は一次窓口が受け、一次窓口で解決できないものだけを開発者にエスカレーションする。

 アナリスト自身が置いていた「最初の版にAI自動応答は含めない」という推測も、このとき取り下げられ、記録ファイルに残りました。
 洗練の助けになります。 ただし、AIが一方的に磨いたのではありません。AIの問いが人の見立てを揺さぶり、人の答えがAIの提案を直す。振り返れば、実験1が「サイトを作る」をそのまま受け取ったように、私も「サイト」という手段や自分の見立てを疑わないまま答えかけていました。違いは、問いを立てる相手がいたかどうか、だけです。

• 代わりに考えない：製品概要のスキルの指示書には「考えを代わりにしない」「答えが薄ければ押し返す」と書かれています（原文は英語。引用は筆者訳。以下同じ）。実際の振る舞いも、観点2・3のとおりでした
• 推測に印を付け、決めていないことを残す：PRDの指示書は、人に聞かずに進めるときも「成功指標やスコープの判断を作り出してはならない、記録せよ」と定めています。実際、目標値は空欄のまま残り、PRDは自分の状態を「完了」ではなく「一部完了（人の確認が要る）」と報告しました
• AIの提案と人の決定を、区別する：了承前の言い換えを「提案」と申告したのは、観点3で見たとおりです。「AIいいなり」を防ぐうえで、いちばん大事な性質かもしれません
• 歯止めの指標を置く：PRDには「問い合わせ件数——減らすこと自体を目標にしない。入口を隠せば簡単に減るからである」という指標が置かれました。第9回・第10回で書いた、指標を成績表にしない話そのものです
• 決めていないWhatは、次の段階へ流れない：エピックとストーリーへの分割のスキルには、人に聞かずに進める道がありません。指示書には「人の入力なしに内容を生成するな」とあり、実装前の判定でも「記録されていない判断を作り出さずに実装できるか」が問われます。いわゆる「Readyの定義」と同じ問いです
• 決定の記録が残る：推測の取り下げまで一行ずつ残ります。第5回の「謎の挙動の判断一覧」や、意思決定の記録（ADR）と同じ考え方です

• 推測も、整った文書の中に収まる：586行の中の31か所の印を、すべて確かめきるのは大変です。文書が整っているほど、確かめずに先へ進みたくなるので、意識しておきたいところです
• 調査は一般論：調査そのものは確かでした。製品概要が引いたGartnerの調査（2024年8月）は実在し、数字も出典どおりです。ただ、Web調査で分かるのは世の中の一般論で、「サポート担当がいない」というこの会社の事情は出てきません。調査が確かなぶん、推測の部分まで確かに見えやすい点には、注意が必要かもしれません
• 手段を問い直すのは、人が答えたときだけ：実験1は「サイトを作る」を最後まで前提にしていました
• 段取りが、ウォータースクラムフォールに見える：これをシステム全体について一度にやり、文書を契約で凍結すれば、撲滅の回で書いた「AIで速く打鍵するウォーターフォール」になりかねません。途中で方針を直す仕組み（Correct Course）も用意されているので、上手に使いたいところです
• 文書が増える：一文の依頼から13分で586行。誰が、いつ読む文書なのかを見極める規律は、AIで書くほど必要になるでしょう
• 答える時間は、人が出すしかない：BMADは「案を作る」側を大きく肩代わりしますが、「決める」時間は肩代わりしません

1. 推測の印と未確認の問いを、人がすべて潰してから次へ進む。印の数は、そのまま「人が確かめるべきことの数」だと考える
2. 最初の作業は「見立てを確かめる」にする。要望や見立てを事実として扱わない
3. 全体ではなく、エピック単位で回す。文書は契約の付属書ではなく、学んだら直すファイルとして扱う
4. AIの提案と人の決定を、混ぜない。言い換え、成功の物差し、何を作らないかは、人が了承したものだけを決定として扱う

 第1回で、CASE、RAD、ローコードと、新しい道具が来るたびに「基礎は不要では」と問われてきた、と書きました。結論は毎回同じで、道具は「どのように作るか」を変え、「何を作るか」「何を学ぶか」は外に残ります。BMADはその「何を作るか」の手前まで入ってきましたが、使ってみると、残る側の仕事は消えたのではなく、はっきり見えるようになったのでした。
 もう一つ分かったことがあります。私の答えはほとんどが短い言葉でしたが、AIはそれを言い直し、整った製品概要にまとめてくれました。言葉にする作業そのものは、AIがかなり手伝ってくれます。
 一方で、実験1が外したのは言葉ではなく事実でした。人に残るのは、言語化の中身のほうです。現場の事実を知っていること。見立てと確かめた事実を分けられること。「いまは決められない」と言えること。AIの提案のどこが違うかを指摘できること。要求を「書く」技能より、「引き出し、確かめ、決める」技能のほうが、AIの時代には重くなります。上流工程を長く仕事にしてきた身として、少しうれしい発見でした。
 道具がどれだけ賢くなっても、Whatの中身を持っているのは人です。だから、人が大事なのです。

 書き終えてみて、「作業」と「仕事」の違いにも気づかされました。決められた手順を機械的にこなすのが作業で、意味のある結果をもたらすのが仕事です。「AIいいなり」と「AIとの対話」の違いは、ここにあるのだと思います。AIと対話しているあいだ、私は考えてもいなかった条件に思いをはせ、これが何の役に立つのかを考えていました。
 「AIが成長したら、スクラムマスターや開発者は要らなくなるのか」という質問をよく受けます。けれども今回の実験を終えて、それより大事な問いがあるように思えてきました。AIは、POの成熟を助ける相手になれるのではないか。何を作るかを決めるPOの隣で、問いを立て、見立てを揺さぶり、答えの出ていないことを目の前に並べてくれる。AIの位置づけとしては、こちらのほうがずっと大切です。
 前者は人を減らす話、後者は人を活かす話です。
 私だったら、後者の立場でお客様にAIをお勧めしたいと思います。

 さて、ここまで読んでくださった皆さんに伺います。
 BMADのような道具があれば、「AIいいなり」は避けられそうな気がしてきたでしょうか。

 …と尋ねつつ、筆者自身がまだまだBMAD初心者なので、もっと精進しなければ。

後編（手順編）：「BMADを動かしてみる——環境づくりから『AIだけ』と『人が答える』の比べ方まで」／次回: 「POが多忙でチームに来ません」（12/1）／本編の連載一覧は第1回をご覧ください。