【イベントレポート】AIでコード書く前に、要求・要件定義足りてる？ミノ駆動さんと改めて考える ドメイン駆動設計

AIコーディングエージェントに頼めば、コードはすぐに出てきます。では、その手前の「何を作るべきか」は、誰がどう決めればよいのでしょうか。

実装スピードが上がるほど、顧客やユーザーが欲しいものを言語化できていないまま作り切ってしまう危うさが増しています。速く作れても、使われないものでは意味がありません。

2026年10月6日の #Offers_DeepDive は、前回「AI時代×ドメイン駆動設計」に続く第2弾として、合同会社DMM.com のミノ駆動様をお迎えしました。『良いコード／悪いコードで学ぶ設計入門』の著者として知られる方です。

モデレーターの大西政徳様の進行で、LT「見えないものを探る 要求要件定義に必要な基本的思考」と、現場エンジニアの問いに答えるディスカッション・質疑応答をお届けします。

設計・実装がAIに移り、人間の仕事は要求・要件定義へ

目的は文脈から生まれる

顧客は本当に欲しいものを知らない

アウトカムから逆算し、具体から抽象へ向かう

仮説推論と目的論的抽象

要求・要件定義なしでClaude Codeに頼めるか

――大西様：ここからはディスカッションです。現場エンジニア目線の疑問として、1問目は「要求・要件定義なんてしなくても、Claude Codeに頼めばよしなに実装してくれませんか」です。いかがでしょうか。

ミノ駆動：これは無理ゲーだと思いますね。AIエージェントに頼んだらテトリスのような、どこかで見たことのあるゲームを作ってくれてすごい、というのが一時流行りました。それは単に、AIがそのゲームの仕組みや仕様を知っているから再現できただけです。その手前にある要求や要件が何であるかを、AIは知らないはずです。

お客さんが具体的に何を要求しているのかというインプットがない限り、それに答えられるものは僕には想像できません。

AIには、与えられた目的を達成するためにひたすら頑張る性質があります。昨日のニュースで、ある人がAIエージェントにフィットネスの予約を依頼したところ、サイトに攻撃めいたことをして他の人の予約を勝手にキャンセルし、自分の予約をねじ込んだという話がありました。目的を達成するために手段を選ばないのです。

目的を与えると、それだけ強力にそこへ向かい出す。逆に言えば、目的がないと何をしていいか分からず、どこへ向かえばいいかも分からないような振る舞いをしますし、作られるものもちぐはぐになります。

要求・要件の通りに強く走り出させるには、要求・要件を言語化したものをAIに渡す必要があるということです。

――大西様：出発点のところは、やはり人間が考えないといけないということですね。

要求は「何をしたいか」、要件は「達成条件」

――大西様：初めて聞いた方もいるかもしれないので伺います。そもそも要求定義と要件定義の違いを、ミノ駆動さんはどう捉えていますか。

ミノ駆動：要求は「何をしたい」であり、要件は条件です。あなたが何をしたいのかは分かった、ではこのシステムがどういう条件を満たしていればその要求を達成したことになるのか。その達成条件、達成基準が要件です。

――大西様：要求は出発点なのでAIに任せられないと思いますが、要求定義をもとに要件定義を導き出すところは、AIでできたりするものでしょうか。

ミノ駆動：もちろんトレードオフはあるので、人間の判断が必要な部分はあるでしょう。ただ、機能要件や非機能要件など、要件を定義するには何を考えなければいけないのかをAIは知っています。要求に対してどういう要件を考えるべきかを網羅させることはできるはずで、実際そういう振る舞いを何回も見てきました。

その上で、開発リソースは有限なので、重視すべき要件とそうでない要件を取捨選択しなければなりません。そこは人間の仕事だと考えています。

――大西様：要件の中の順序付けは、会社やチーム、プロダクトに応じて変わってくるということですね。

ミノ駆動：そうだと思います。

要求・要件定義は誰が書き、誰が保守するのか

――大西様：2問目は「要求・要件定義は、それぞれ誰が書き、誰が保守すべきなのか」です。プロダクトマネージャー、エンジニア、デザイナーもいるかもしれません。ミノ駆動さんのご経験では分かれていましたか。

ミノ駆動：その時々でしたね。Web系に移ってPdMという職種があることを初めて知ったのですが、要求定義に関しては多くがPdMの人が担っていたという印象です。ただ、僕がJTCにいた頃は時代的にPdMという概念がそもそもなかったので、役職に関わらず開発者が要求定義も要件定義もやっていました。

システム開発上どうしても必要なので、誰かが担わなければいけないものです。ただ、今映している「それぞれ誰が書き、誰が保守すべきか」という問いについては、AI時代にはだんだんエンジニアが担っていくことになるのではないかと見ています。

――大西様：要求定義をやったことがない人にとって、顧客のところへ出向いて要望を聞くといったことは求められるのでしょうか。

ミノ駆動：ものによっては、実際にお客さんのところへ足を運ぶことは必要だと考えています。僕も3年前の開発では、お客さんとオンラインで対話し、どういう状況で、具体的に何に困っているのかをインタビューしました。

――大西様：Web系では、それはエンジニアの仕事ではないと思われている方も多いかもしれません。Web系に移られた後も、そういう場に顔を出していたのですか。

ミノ駆動：そうですね。僕が顔を出すのは、ある種ドメイン駆動設計の文脈です。ドメインモデルを正しく作るには、そもそも顧客の要求をちゃんと知らなければいけません。お客さんが解決してほしい問題があり、それを解決するために存在するのがドメインモデルです。

何に困っているのかを正しく知らなければ、正しい設計はできません。ドメイン駆動設計ではドメインエキスパートと対話するのが重要だと言われますよね。より正しい設計をするために、顧客やビズサイドの利害関係者に近いインタビューの場に立った、ということです。

不備は防ぐものではなく、フィードバックで直すもの

――大西様：3問目は「実装以降のフェーズにおける要求・要件定義の不備を防ぐために気をつけていることは」です。作って実装したけれど違っていた、ということを防ぐために気をつけていることはありますか。

ミノ駆動：いや、不備はあって当然だと思っています。後段に行くに従って「これも検討しなければいけなかった」ということがよくあるんですよね。不備の発見が何もなく100%実装までいけた経験は、僕にはありません。

曖昧なものを具体化していくわけですから、ぼんやりした要求や要件は、具体と照らし合わせたときに初めて抜け漏れに気づくものです。皆さんも経験があるのではないでしょうか。

だから大事なのは、フィードバックサイクルを回していくことです。不備が見つかったら要件や要求といった上段にフィードバックし、もう一度サイクルを回して改善する。初めから100%の完成を目指そうとするから「不備を防ぐ」という発想になるのだと捉えています。

もちろん可能な限り明らかにしていくことは大事ですが、検討漏れは必ずあるはずなので、フィードバックで順繰りに100%へ近づけられればよい、というところです。特にAIは抜け漏れをチェックするのが得意なので、そこで活用すると漏れを防ぐのに役立つでしょう。

優秀なエンジニアの要求・要件定義は「何をやらないか」が書いてある

――大西様：4問目は「優秀なエンジニアが書く要求・要件定義は何が違う」です。これまで見てきた中で、筋がいいと思った特徴があれば聞かせてください。

ミノ駆動：何をやって何をやらないかを網羅している要求・要件定義書ですね。人・物・金という開発リソースは有限です。限られた予算と時間の中で開発しなければならないので、お客さんの要求をいくら盛り込んだところで、全部やることは土台できません。

そこで大事なのが戦略です。戦略とは「戦を略す」、長期目標を達成するために何を取って何をやらないかということであり、要は何を捨てるかです。「今回は価値に見合わないのでやりません」と物事に優劣をつけて判断する必要があります。

そのためには、やる・やらないの材料を全部揃えて俎上に乗せなければいけません。例えばA・B・C案を出し、それぞれに優劣をつけた上で、今回はこれをやる、こちらはやらないと決めていくわけです。

要件も同じです。機能要件や非機能要件は言い換えるとソフトウェア品質特性で、どの品質を重視するかはプロダクトの性質によって違います。ものすごい負荷がかかるものならパフォーマンス要件を重視しなければなりませんが、そうでないものもあるでしょう。

どの要件を重視し、どの要件の優先度を下げるかというトレードオフを解決しなければなりません。何を取って何を捨てるかを理由付きで書いているドキュメントはよくできていますし、後から見返したときに判断を改善しやすいと感じます。

五分五分の選択肢は判断ではなく決断で選ぶ

――大西様：材料を集めてトレードオフを考えても、論理的にはどちらも取り得る五分五分の判断があり得ますよね。2つを1つに絞るには別の力が必要な気がしますが、どう選んでいますか。

ミノ駆動：これはとてつもなく難しいと思っていて、そもそも何が正解か分からないのです。分かっていたら、みんな大金持ちになっているはずです。事業とはそういうもので、何が当たりかは分かりません。

最近、海外で日本のけん玉のような昔のおもちゃがやたらと流行り出したというニュースがありました。そんなものが大当たりするとは、机上で検討していても想像がつきません。前例があるから当たる、と前例に頼りがちですが、それでも当たらない部分はあるものです。

だから、どちらか優劣をつけられないものについては、論理的にこうだからこちらが当たるはずだという「判断」で決めるのではなく、「決断」が必要だと考えています。どちらが当たるか分からないけれど、勇気を持ってこちらを選ぶ。それが決断です。

もちろん複数の案があればABテストのような仮説検証も加えますが、最後はどうしても決断という側面が必要になってくるのではないでしょうか。

初めての要求・要件定義は、技術の言葉から離れることから

――大西様：最後の問題は「初めて要求・要件定義をする人は、何から始めればいい」です。要件定義はしたことがあるけれど、要求定義はプロダクトマネージャー任せ、という現場を想定した場合、ミノ駆動さんならどう動きますか。

ミノ駆動：まずは、自分たちが使っている考え方と言葉を改めるべきだと考えています。要求定義に不慣れなエンジニアは、技術のことばかり扱っているので、APIがどうとか、データベースのカラムがどうとか、常に技術の言葉で話しているんですよね。

そういう人たちを要求定義の場に連れて行くと、顧客が事業やビジネスの話をしているのに、勝手に技術の言葉に置き換えて「それはデータベーステーブルの何々のことですよね」と、途端に技術用語で話し始めるのです。これがめちゃめちゃ多い。

即座に技術用語へ翻訳して話すと、ビズサイドの人たちと話が噛み合いませんし、向こうも何を言っているか分からなくなります。

何から始めればいいかといえば、技術の言葉から一旦離れて、ビズサイドの文脈や立場に立ち、お客さんがどう困っているのかをビズサイドの言葉で話すこと。それが最初の一歩だと捉えています。

――大西様：一歩目として、とても有意義なものになりそうです。コメントでも「DDDっぽい用語が来た」「勝手に抽象を具体化しちゃうんですよね」といった声が上がっています。

質疑応答

AIは仮説出しが苦手、網羅は得意

――質問：顧客から大枠しか示されず、明確な要件がない案件で、担当エンジニアが仮説を立てて進めることを苦手としています。生成AIをコード生成だけでなく、仮説出し・案の比較・確認事項の洗い出しなどの思考補助に使うのは有効でしょうか。また、AI依存を避けつつ仮説思考を育てるには、どのような使わせ方がよいでしょうか。

ミノ駆動：仮説は、AIは苦手だと思っています。うまく使っている人がいたら教えてほしいくらいです。理由はちゃんとあって、仮説にはある種のひらめきが必要なのです。顧客の話や置かれた状況を鑑みて、「もしかして本当に欲しいものはこうではないか」と気づく。そういうひらめきがどうしても要ります。

ところが、AIは使った言葉の延長線上で物事を考えようとします。今の生成AIは言葉の連想ゲームの仕組みで、ある種の高級なオウム返しです。あくまでその言葉の範囲のものしか返してきません。

何もないところからいきなり「もしかしたらこうでは」と出すのは苦手で、僕も実験してみましたが、程度のいい答えが返ってきた記憶がありません。

案の比較をさせるのはよいと感じますし、抜け漏れをチェックするための確認事項の洗い出しは、AIは何かを網羅するのが得意なので、補助として使っていいでしょう。

AI依存を避けつつ仮説思考を育てる使わせ方は、分からないです。そもそもAIは仮説を立てるのが得意ではないと見ていますし、僕自身うまく使えたことがないので、そこはうまく回答できません。

――大西様：仮説思考は自分でやり、網羅性はAIで効率化する、というところですね。

手段の形で来る依頼から、上位目的を聞き出す

――質問：依頼者から「この項目を年1回自動で更新してほしい」のように、手段の形で依頼が来ることが多いです。相手にアウトカムを聞くとき、最初に何を聞いていますか。また「たぶん目的はこうでは」と仮説を出すと、相手が仮説に引っ張られて同意してしまう心配があります。誘導にならないよう気をつけていることはありますか。

ミノ駆動：スライドでも説明したように、目的は文脈から生まれるので、その人がどういう状況に置かれているかをちゃんと調べます。どういう仕事をしていて、何に困っていて、何が制約になっていて、利害関係者は誰か。そういう文脈を洗い出すわけです。

「年1回自動で更新してほしい」は、目的ではなく手段を提案しているのです。なぜ年1回更新してほしいのか、その上位目的を類推する必要があります。上位目的を捉えた上で「年1回ではなく、本当はこうしたいんですよね」と別の手段を提案する、ということになるでしょう。

先ほどの速い馬の話で言えば、顧客が本当に求めている上位目的は、早く目的地に移動したいということです。その手段の1つが馬であり、自動車であり、現代なら飛行機です。

顧客がどういう状況に置かれているかという文脈を捉えつつ、目的と手段を分けて考える。「今おっしゃっているのは目的を達成する手段の話なので、その上位にある目的は何ですか」「その目的を達成する別の手段はないですか」と考えていきます。

目的についても具体と抽象をする必要があるので、難しいですよね、という感じです。

――大西様：目的と手段の関係性を説明した上で、目的を聞き出すということですね。依頼者との関係値を作り、そういう思考を取っていることをすり合わせておくのは大事ですね。

文脈をAIに与えれば、要求・要件定義はできるのか

――質問：文脈をAIに与えられるようになれば、要求・要件定義ができるようになるのでしょうか。抽出くらいならできそうだと思っています。

ミノ駆動：確かに、文脈によって目的が決まると僕は言いました。でも、本当に顧客が求めているものが何かは分からないのです。けん玉の話をしましたよね。何を欲しているかは分からないからこそ、仮説推論で「本当に求めているのはこうではないか」と仮説を立てて開発を進めなければなりません。

文脈を与えた結果として要求・要件定義を定義できるようになれば、誰もが大金持ちになれるはずです。それはできないので、どうしても仮説推論という仕事が必要になります。一方で、今のところAIは仮説推論を苦手としているというのが僕の見方です。

文脈をAIに与えること自体は必須で、やらなければいけません。ただ、そこからAIに要求が何かを決めさせるのは難しいと考えています。

若いうちに身につけるべきは「目的を問う」姿勢

――質問：現在学生です。ミノ駆動さんのXを拝見し、具体と抽象に入門しました。将来的には抽象的な要求や文脈から課題解決できるようになりたいです。学生のうち、若いうちに身につけるべき技術は何でしょうか。

ミノ駆動：この流れだと、テクノロジーではなく広くテクニックのことをおっしゃっているのでしょう。実は、抽象的に物事を考えられる人は、人口比的にはあまり多くないと僕は思っています。

何かを具体化したり、与えられた具体的な指示に基づいて何かしたりするのは普通にできる。でも「そもそもこれは何のためにやっているのか」を考えられる人は多くありません。それをできるようになってほしいのです。

僕の周りにいる、とてもよく仕事ができるエキスパートの方々は、「この仕事で価値を発揮するには、そもそも何の目的でやっているのか」という会話を大抵しています。目的という言葉を聞かない日がないくらいです。

いつも目的に立ち返り、「これは本来やりたいことと違う、目的から外れてきているから是正しましょう」という話を毎日しています。だからこそ、価値が高く正確性の高い仕事ができるわけです。

そこを外すと、いくら頑張っても誰にも受けないサービスが作られてしまいます。そもそも私たちの目的は何か、を考えられることが大事です。

もう1つは、未知の未知へのアプローチです。人間は外部から取り込む情報の9割が視覚からだと言われていて、目に見えるものだけで判断しようとします。動いている画面やドキュメントなど、目に見えるものだけで判断するバイアスがかかりがちです。

僕は目に見えるものにあまり価値を感じていません。本当に大事なものは、目に見えないことがとても多いのです。自分の知らないものは一体何なのだろう、というところにアプローチする姿勢をぜひ持ってほしいですね。

技術で解消できない要望は、IT以外の手段を考える

――質問：先ほど「AIの進化で、それっぽく爆速でビジネス負債・要求負債のあるものが作られている現状にどう感じますか」と伺った者です。ビジネス負債とは、業務要件自体に技術で解消できない矛盾が存在する場合を指しています。

ミノ駆動：なるほど、そういう概念なんですね。技術で解決できないものを無理やり作ってしまっている、ということですよね。AIに実装しろと言うと、とにかく実装すればいいんでしょう、という感じで進みます。

本来は技術ではない別のソリューションとして提供すべきものを、無理やりソフトウェアとして実装してしまう。そういう振る舞いを指しているのだと捉えました。

僕自身はそういう状況に遭遇したことはありません。ただ、要求定義がとても上手い人は、お客さんから要望を聞いたときに「それはソフトウェアやITで解決するのではなく、別の方法でやった方が絶対に効率がいい」と、IT以外の手段を提供することをよくやっていると聞いています。

これはAIで試したことはありませんが、要求を定義する際には「システム開発以外の方法でも解決できないか」をAIに指示した上で、考えを支援してもらうアプローチが大事なのではないかと、この話を聞いて感じました。

――大西様：作れるから作ってしまう、という方向ではなく、一度立ち止まってシステム以外で解決できないかという視点も持つ、ということですね。

チーム構成ではなく、コミュニケーションパスを設計する

――質問：他社の要求・要件を整理して定義するチームに必要なチーム構成は何になりますか。それに合うようにチームの再構成は不可避でしょうか。

ミノ駆動：これは質問の要求自体を見直す必要がありますね。こういう質問こそ、本当に何を知りたいのかを考える契機になります。僕はこれをチームの構成ではなく、コミュニケーションパスのあり方を設計する必要があると捉えました。

まともな要求定義をするには、お客さんに近いところへ行って話をしなければいけません。最悪なのは伝言ゲームになることです。企画がお客さんから話を聞いて企画書を作り、「この企画書通りにシステムを作って」と渡す。

人間の言葉は話者の言っていることの劣化コピーに過ぎないので、伝言ゲームになるほど内容は正確に伝わらなくなり、どんどん劣化していきます。

結局お客さんが何をしたいのかが末端まで正確に伝わらない、下手をすると真逆の内容として伝わってしまうこともあります。だからこそ開発者は顧客のところに近づかなければいけないのです。

有名なケースとして、第二次大戦時の日米の軍のコミュニケーションの違いが『失敗の本質』に書かれています。日本は伝言ゲームで、現場はすごく苦しいのに「大丈夫です、勝てます」と伝わっていった。

一方の米軍は、最前線で戦っていた兵士を司令部に異動させ、現場で何が起こっているのかを報告させるコミュニケーションパスを設計して運用していたそうです。だからこそフレッシュな情報に基づいて作戦を指揮できた、という話で、これは仕事でも同じでしょう。

この質問はチーム構成を聞いていますが、誰とコミュニケーションを取るかというあり方を設計し、そこに必要な人を連れてくる。コミュニケーションありきでチームを編成する、というあり方を考える必要がある、というのが僕からの答えです。

――大西様：情報をいかに劣化させずに伝えるか、コミュニケーションパスの設計ですね。ミノ駆動さん自身が最前線に行きやすくするパスは確立されていますか。

ミノ駆動：弊社は大きいので、人数が多いと全員とコミュニケーションを取りきれない部分はあります。人間が一度にコミュニケーションを取れる人数は上限50人と言われていて、全員は絶対に無理です。

ただ、離れていてもどうしてもコミュニケーションを取りたい人がいる場合は、上司や関係者に進言して話ができるパスを作ってもらう、という仕事の進め方をしています。

――大西様：誰がどの情報を持っているかが分かれば、パスの設計自体をAIがやってくれる未来もあるかもしれませんね。

ミノ駆動：誰がどの情報を持っているかがデータ化されていれば、そこを効率よくやってくれるのではないかと、今思いました。

AIエージェントが集約を崩すときは、目的ごとに分ける

――質問：大きいストーリーを解決しようとすると、AIエージェントは本来の集約を掠ったような新しい集約を勝手に生み出し、「違うんだけど」となることが多いです。このあたりはどのように解決していますか。

ミノ駆動：DDDの文脈が入ってきましたね。この答えは僕が次に出す本に書いているのですが、ちゃんと答えます。最近の登壇で「目的駆動設計」なるものを提唱し、モジュールの設計に活かしましょうと言っています。

手段は何かしらの目的を達成するためのものなので、手段は必ず目的と一対一にする。そのためには目的の違いを見分けなければいけません。

例えばショッピングサイトの注文には、すぐ注文できる即時注文、予約して注文する予約注文、当たるか外れるか分からない抽選注文、定期的に届けてもらうサブスクリプション注文と、いろいろな種類があります。

よくありがちで最悪な設計が、それを全部「注文」という1つのクラスでやってしまい、中で条件分岐するものです。注文という集約がいろいろな目的に対応し、いろいろな目的のコードがごちゃ混ぜになってしまっています。

本来は、即時注文クラス、予約注文クラス、サブスクリプション注文クラスと、目的ごとに分けるべきです。目的ごとに使うデータとロジックは違います。予約なら予約日と予約を制御するロジックが必要ですし、サブスクリプションなら何週間おきに届けてほしいかというデータが必要になります。

質問に戻ると、AIエージェントが集約の構造をおかしくしてしまうのは、ストーリーが大きすぎて目的の違いを識別できていないからです。「この目的とこの目的は違う」と見分けて、目的ごとに集約を設計しろと言えば、AIはやってくれます。

即時注文は今すぐこの商品が欲しい、予約注文は発売日当日に絶対に手に入れたい、サブスクリプションは日常的にいつも使うものを一々注文しなくても定期的に届けてほしい。目的が全部違うのです。目的を見分けた上で、目的に対応する手段たるクラスや集約を用意しましょう、という話です。

――大西様：曖昧に「注文」として渡したとき、AIがうまく察して目的を分けてくれる場合と、分けてくれない場合がある気がしています。ミノ駆動さんは常に目的を分けて依頼しているのですか。

ミノ駆動：僕はそうします。そうしないと、注文クラスにいろいろな行動を追加で実装しようとします。実際そういう振る舞いをしていて、既存のモデルにどんどんデータやロジックを追加しようとするのです。

ただ、僕はそこを賢くやってくれるAIエージェントを用意していて、社内の組織で使ってもらい、変更しやすいコードを生み出しています。先ほど言ったように、目的は文脈から生まれます。

そもそも置かれている文脈は何か、目的ごとに要件は何か。予約注文なら予約を設定できる、予約の注文数に上限がある、といった要件が決まっていますよね。文脈・目的・要件と、その手段はセットなのです。

その一貫性を維持できるように設計しろと言えばやってくれますし、混ざりそうになると「これは文脈が違います、分けるべきですよ」とAIが提案してくれます。完璧ではありませんが、かなり賢くやってくれるという印象です。

組織改革の要求・要件に、AIをどう使っているか

――質問：Copilotとして、AIにカスタマージャーニーマップを書いてもらい、それをどう感じるかで要件を判断しています。ミノ駆動さんのCopilotとしての要求分野での使い方の一例を知りたいです。

ミノ駆動：先ほど言ったように、システム開発での要求定義には最近は携わっていないので答えづらいのですが、組織改革をする上で、この組織には何が求められているかを考えるためにAIを活用することはあります。

その使い方も、やはり文脈の把握は絶対にマストでインプットします。その結果として本来どうあるべきか、何が求められているのかは、僕の方から仮説を立てながら、それをサポートしてもらう形です。

要件に関しては、組織改革で今後何に取り組まなければいけないのか、やらなければいけないことのリストとして出してもらい、その妥当性を判断する、という使い方をしています。

おわりに

――大西様：最後に、ご視聴の皆さんへ一言お願いします。

ミノ駆動：今まで具体の技術を扱うことが多かったエンジニアの方は多いかもしれませんが、AIの登場でいろいろなことがドラスティックに変わっています。要求や抽象はよく分からない、と不安になる部分もあるかもしれません。

それでも、どうしても必要になってくるものです。ありきたりな言い方ですが、自分を成長させる、自分を強くするという強い気持ちを持って、新しい世界に踏み出していただければと思います。

LTで示された4つの思考は、どれもAIに渡す前の「人間側の仕事」でした。文脈を把握し、未知の未知に目を向け、アウトカムから逆算し、仮説を立てて目的に合う特徴だけを抜き出す。ディスカッションと質疑で繰り返されたのも、目的と手段を分け、目的ごとに手段を一対一で対応させるという同じ原則です。

AIに頼む前に、自分たちは何を実現したいのかを言葉にできているか。今回のお話は、その問いを自分のプロダクトに向けるきっかけになるのではないでしょうか。