目次
ウォーターフォールがAI機能開発で機能しない理由
「まず市場調査を行い、要件定義を固め、開発に入る」——この順序はソフトウェア開発の常識として長年機能してきた。しかし、AI機能をプロダクトに組み込もうとする場面では、このウォーターフォール的アプローチが根本的に崩壊する。
問題は「要件を固める」ステップにある。 AI機能——とくに生成AIを使ったコンテンツ生成、会話型インターフェース、レコメンデーション——は、実際に動かして使ってみるまで「何ができるか」の輪郭すら掴めない。ユーザーが「欲しい」と言う機能と、実際に使い続ける機能が大きく乖離することも日常茶飯事だ。Dew et al.（2009）が指摘するように、ナイト的不確実性の下では事前の期待値計算そのものが無意味であり、プロダクト開発においてもこの原則は直接適用される（Dew et al., 2009, pp. 108–110）。
エフェクチュエーション理論の観点から言えば、ウォーターフォールは典型的な因果論的アプローチ（Causation）——目標を先に定め、それに必要な手段を調達する——だ。Sarasvathy（2001）が論じたように、因果論が機能するのは「将来の状態が現在の情報から合理的に予測できる」場合に限られる（Sarasvathy, 2001, p. 244）。AI機能開発では、この条件が満たされない。エフェクチュエーションとコーゼーションの違いの詳細は比較記事で論じている。
「作れるものから作る」という発想の転換
エフェクチュエーション的プロダクト開発の核心は、手中の鳥の原則にある。「何を作るべきか」ではなく、「今持っている手段で何が作れるか」から出発する。AI機能開発では、この手段は具体的に次のように定義される。
AIツールとしての手段。 Cursor（AIコーディング）、Claude（コンテンツ生成・API）、Perplexity（リサーチ）、Gemini（マルチモーダル処理）——開発チームが実際にアクセスできるツール群が「今日の手段」だ。これらを「まだ使いこなせていないから要件定義が難しい」と捉えるのが因果論的発想であり、「これらを使って今すぐ動くプロトタイプが作れる」と捉えるのがエフェクチュエーション的発想である。
ドメイン知識としての手段。 AIは汎用的な処理能力を提供するが、どの問題に適用するかはドメイン知識に依存する。医療系プロダクト開発者は医療記録の構造を知っており、法律系開発者は契約書のパターンを知っている。このドメイン固有の知識が、AI機能の差別化要素になる。Sarasvathy（2008）が強調する「What I know」の手段は、AI時代においてむしろ重要性が増している（Sarasvathy, 2008, p. 15）。
初期ユーザーとしての手段。 「誰が最初に使ってくれるか」は、AI機能のプロダクト開発において最も重要な手段だ。自分のネットワーク内に「この問題を抱えていて、ベータ版を喜んで試すユーザー」がいるかどうかで、学習速度が大きく変わる。
AFM（Affordable Failure Mode）：MVPを高速回転させる設計
Dew et al.（2009）が提唱する許容可能な損失の概念を、プロダクト開発に適用したフレームワークが**AFM（Affordable Failure Mode）**だ。これは「このMVPが完全に失敗しても、何をどこまで失うか」を事前に定義する設計思想である。
AFM設計の3つの軸。 第一の軸はコスト上限だ。このMVP開発に投じるAPIコスト・エンジニア工数・インフラ費用の上限を定める。第二の軸はタイムボックスだ。「2週間でユーザーに見せられるものを作る、作れなければそのアイデアは捨てる」という時間的コミットメントの上限を設ける。第三の軸は学習目標だ。このMVPで答えを得たい問いを1-2個に絞る。「ユーザーはAI生成コンテンツを実際に使うか」「レスポンス速度3秒は許容されるか」など具体的な問いに落とす（Dew et al., 2009, pp. 115–118）。
AFMが機能する理由は、「失敗の設計」にある。 ウォーターフォールは「成功を計画する」アプローチだが、AFMは「失敗のコストを許容可能な範囲に収める」アプローチだ。AI機能のMVPは高確率で「想定通りには機能しない」。だからこそ、失敗したときに失うものを事前に定義し、その範囲内で最大限の実験を行うことが合理的だ。
MVPの高速回転とは何か。 AFMの範囲内でMVPを作り、ユーザーに見せ、フィードバックを得て、次のMVPを定義する——このサイクルを2週間単位で回す。Sarasvathy（2008）が観察した熟達した起業家は、1つの計画に執着せず、各実験から得た情報を次の手段の棚卸しに反映するパターンを繰り返していた（Sarasvathy, 2008, pp. 35–36）。
CursorとClaude APIで「作れるものから作る」実践例
具体的な開発ワークフローを示す。これはAI機能を持つB2Bプロダクトの初期開発を想定している。
ステップ1：手段の棚卸し（1日）。 チームが持つAIツールアクセス（どのAPIが使えるか）、ドメイン知識（どの業界の問題を知っているか）、初期ユーザー候補（誰が最初に試してくれるか）を書き出す。この棚卸しが終わらない限り、次のステップに進まない。
ステップ2：AFM定義（半日）。 「このMVPで失ってよいもの」を明文化する。具体的には「APIコスト月1万円以内」「開発工数2週間以内」「評判リスク：社外公開前の内部ベータのみ」などだ。
ステップ3：Cursorで動くプロトタイプを2週間で作る。 Cursor（AIコーディングアシスタント）を使えば、単純なAI機能のプロトタイプは数日で動く状態にできる。完璧なコードより「ユーザーが触れる状態」を優先する。Claude APIを使う場合、最初はPrompt APIを直接呼ぶシンプルな実装で十分だ。
ステップ4：5人のユーザーに見せる（1週間）。 ベータユーザー候補5人に実際に触ってもらい、録画・観察・インタビューを行う。ここで得られるフィードバックは、市場調査レポートでは絶対に得られない「実際の行動」だ。
ステップ5：次のAFMを定義して繰り返す。 ユーザーフィードバックから「次の2週間で試すべき仮説」を1つ選び、AFMを再定義してサイクルを回す。
ウォーターフォールが機能する条件とエフェクチュエーションが機能する条件
重要な点は、エフェクチュエーション的アプローチが常に優れているわけではないということだ。Sarasvathy（2001）自身が論文で強調したのは、エフェクチュエーションとコーゼーションは対立ではなく、環境の不確実性の度合いに応じて使い分けるべきということだ（Sarasvathy, 2001, pp. 244–245）。
AI機能開発でウォーターフォールが機能する条件が一つある。それは「類似のAI機能を以前に開発した経験があり、ユーザーの反応パターンが予測できる」場合だ。同じチームが同じドメインで同じ種類のAI機能を2度目・3度目に開発する場合は、過去の学習から要件を固めることができ、因果論的アプローチが有効になる。
しかし、新しいAI機能の初回開発においては、ほぼ例外なくエフェクチュエーション的アプローチが有効だ。AIの能力限界、ユーザーの受容性、倫理的問題の発生パターン——これらは実際に動かさないと分からない。「作れるものから作る」のは雑な開発ではなく、不確実性に対する合理的な応答だ。
「学習速度」が競争優位を決める時代
AI機能を持つプロダクトが乱立する現代において、競争優位の源泉は機能の差別化より学習速度に移行している。同じAPIを使えば同じ機能は作れる。差が出るのは、「どれだけ速く・多く・正確にユーザーから学べるか」だ。
Dew et al.（2009）が行動経済学的観点から論じたAffordable Lossの本質は、**「失敗のコストを下げることで実験の回数を増やす」**にある（Dew et al., 2009, p. 118）。AFMでMVPを高速回転させるアプローチは、単なる開発手法ではなく、不確実性の高い環境での学習戦略だ。
AI時代のプロダクト開発において「作れるものから作る」は、妥協ではなく戦略だ。許容可能な損失の原則と手中の鳥を組み合わせた設計思想は、変化し続けるAI環境で最も持続可能な開発アプローチを提供する。
引用・参考文献
- Sarasvathy, S. D. (2001). Causation and effectuation: Toward a theoretical shift from economic inevitability to entrepreneurial contingency. Academy of Management Review, 26(2), 243–263.
- Sarasvathy, S. D. (2008). Effectuation: Elements of Entrepreneurial Expertise. Edward Elgar Publishing.
- Dew, N., Sarasvathy, S. D., Read, S., & Wiltbank, R. (2009). Affordable loss: Behavioral economic aspects of the plunge decision. Strategic Entrepreneurship Journal, 3(2), 105–126.
参考書籍
