6〜9人月の見積もりがAI駆動で実働3日に。では開発は「安く」なったのか？-その確信に迫る
お久しぶりですbravesoft株式会社のタッキーです。
普段の仕事は組織運営がメインで、日常的にコードを書く立場ではありませんが、そんな私が、弊社のAI推進主催のAIワークショップを実施するにあたりその事前知識としての勉強会(※テーマはターゲットをなぜ決めるのか？そのお題はタイマー)に参加した中から考えたものを、勉強会後の社内メンバーに向けた参考資料として企画書を作成をしました。
そこから派生し、どうせなら企画のブラッシュアップをして事業計画書〜TestFlight 配布までを AI（Claude Code/Codex）に大半を委ね、ハンドドリップ初心者向けアプリの MVP を実際作ってみようと思い立ち、受託開発の積算で6〜9人月相当の成果物を、実働3日で TestFlight に乗せたことで、これがどうビジネスにインパクトさせ、これから何が変わるのか。についてを話します。
——シンプルに書くと「開発は1/50の値段でできるようになる」と読めてしまいますが、結論は違います。この記事では、安くなったのは何で、価値が上がったのは何かを、見積もりを引いてきた立場から整理します。
作ったもの
「器具は揃えたのに毎回味が違う」ハンドドリップ初心者のためのアプリです。コンセプトは「はじめてでも、毎回おなじ一杯を。」。この企画の最大仮説は「初心者はレシピを探したいのではなく、迷わず再現したい」——情報はもう世の中に溢れていて、足りないのは自分の環境で再現できる体験だ、という見立てです。
現に何個か近しいアプリは出ていますが、明確なターゲット選定というよりはもう幅広くといった形になるか、コーヒーは抽出という概念上、数学的な要素もあるので難しそうといったアプリも多くありました。
そこでユーザーは数値を覚えず「すっきり／バランス／しっかり」と好みを選ぶだけ。アプリがレシピを自動生成し、タイマーが注湯をガイドし、飲んだ感想（♡評価と味タグ）から次の一杯のパラメータをひとつだけ補正する——「迷わず一杯を完成させる」コアループが一周動くところまでを MVP と定義しました。
技術スタックは Flutter + Riverpod + Drift + Firebase(尚自分自身はFlutter
アプリは案件では取り扱っていても自ら作ったことは1回もありません)
レシピ生成は決定論的ルールエンジン、テスト176本、Apple/Google サインインまで実装しています。
従来の積算と、実績
この成果物を受託案件として見積もると
対して実績はこうでした。
コードベースは `lib/` 配下84ファイル・約21,000行です。
念のため先に書いておくと、この数字は「開発費が1/50になる」という意味ではありません。この3人日の中身を振り返ると、その大半は決める仕事です。誰のどんな困りごとに張るか、事業として成立する筋はあるか、何を作って何を作らないか、どう確かめるか
——企画から実装まで、難しさの正体は一貫して意思決定です。安くなったのは、調査・資料づくり・文書化・実装といった「手を動かす作業」のほうです。何が起きたのかは、もう少し解像度を上げて見る必要があります。
今回の検証で見えた変化は4つあります。
変化①：検証が「画面の絵」から「実体験」になった
私が最も重要だと思っている変化はスピードではなくこれです。
これまで、企画検証フェーズの成果物は Figma のプロトタイプやモックでした。画面遷移は確認できる。見た目の印象も聞ける。しかし体験は検証できません。
このアプリが検証したい最大仮説は「初心者は、迷わず再現したい」。
事業計画上の検証 KPI は 初回抽出完了率 50%以上（ガイドに沿って迷わず1杯を淹れ切れた割合）と、7日以内の2回目利用率 25%以上です。お気づきでしょうか——この2つの指標は、実際にお湯を沸かしてコーヒーを淹れてもらわないと、1件も計測できません。タイマーの音に従って注ぎ、飲んで♡を付け、数日後にもう一度淹れたくなるか。クリッカブルプロトタイプでは、原理的に確かめようがないのです。
今回、検証フェーズの成果物が「画面の絵」から「TestFlight で配れる実体」に変わりました。テスターは明日から実際にコーヒーを淹れて使えます。得られるフィードバックが「このボタン分かりにくい」から、初回は「ガイド通りに、本当に最後まで淹れ切れたか」、2杯目からは「同じ味を再現できたか、前よりおいしくなったか、上達できているか」に変わる——先ほどの2つの検証 KPI に、そのまま対応するフィードバックです。同じ検証予算で買える学習の質が、UI の良し悪しからプロダクト仮説そのものの真偽に変わった、ということです。
作ってから判断できる。プロダクトの意思決定の質は試行回数で決まりますが、その試行1回あたりの解像度も桁で上がっています。
変化②：「真っ先に削られる体験」が、検証の主役になった
従来の MVP のスコープ設計では真っ先に削られていた「体験の層」が、MVP に入るようになりました。このアプリのタイマーには、気分に合わせて選べる BGM、注ぎはじめ直前のカウントダウン SE、操作に応えるハプティクスが入っています。従来の MVP 予算なら、どれも「リリース後の付加価値」として削られる贅沢品です。
しかし考えてみてください。ハンドドリップ中のユーザーはケトルで手が塞がり、視線はスケールの数字とドリッパーの湯面を行き来しています。
画面を凝視する余裕は、手にも目にもありません。
「いまは待つ時間」「そろそろケトルを持つ」を音の種類とタイミングだけで伝えられるか。待ち時間のうちに「次は◯gまで注ぐ」を先に知らせておけば、注いでいる最中に画面へ視線を戻さずに済むか。BGM は初心者の緊張をほぐし、リラックスして淹れる体験を作れているか。カウントダウンの鳴りはじめは、ケトルを持ち上げる所作に間に合うか——これらは実際のリビング等で、本物のお湯で試さないと1秒も検証できない領域であり、同時にこのプロダクトの「迷わず淹れ切れる」という仮説の中核そのものです。
体験の磨き込みは「MVP の後でやる贅沢」ではなく、仮説の一部である——実装コストが桁で下がったことで、ようやくこの当たり前を MVP のスコープに含められるようになりました。
変化③：計画が「固める対象」から「更新される対象」になった
事業計画書は、当初の目的は勉強会参加者向けの企画書という意図があったため、経営層や株主向けレベルの精緻な計画ではありませんでしたが、今回のMVP制作にあたり目的を変更し仮説検証を回すための叩き台と割り切り、2〜3時間で作成しました。
そのため本来の事業計画の承認レベルには到底足りていないことも自覚しています。ただし意図的に落としているのです。
これはコンサルティング業務として時間かけて作り込み、経営を納得させる資料を最初に作り込むことよりも、実際の検証結果によって書き換えていく前提のドキュメントとして目的・位置付けを変化させたということです。
その事業計画書に書いたロードマップは「AI 活用で 90日以内に MVP 検証まで到達」。実装が3日で済んだいま、この90日の意味が変わります。かつての90日は大半が開発で埋まり、検証は最後に1回できれば上出来でした。これからの90日は、「作る→配る→計測する→判断する」のサイクルを何周も回すための期間になります。MVP は一発勝負の成果物ではなく、検証サイクルの最初の1周にすぎません。計画も実装も、「先に固める対象」から「検証で更新される対象」に変わったのです。実際、この記事で引用した検証 KPI（50%／25%）も、最初の1周で書き換わるかもしれません。書き換わったなら、それは計画が外れたのではなく、計画が仕事をした証拠です。
変化④：速さの源泉は、AIではなく判断だった
AI を使ったのは実装だけではありません。市場調査・競合調査・ポジショニングの整理も、情報収集と資料化は AI に任せました。ここで気づくべきは、上流も下流も構図が同じだということです。集める・整理する・書き起こすはAIの仕事になり、「この市場のどこにポジションを取るか」「どの競合とは戦わないか」を決めるのは変わらず人間の仕事です。調査レポートが一晩で揃っても、そこから間違った結論を引けば、間違ったものが高速にできあがるだけです。
「AIがすごいから速かった」は半分しか正しくありません。効いたのは着手前に決めた3つの制約で、いずれも AI ではなく人間の仕事です。
1. コアのレシピ生成を、AIに任せないと決めた。
昨今サービスにAIという波に乗り安易に導入することが多いものですが
今回のコンセプトではAIでレシピを作ると出力は毎回揺らぎ、「毎回おなじ一杯」という約束そのものに反します。だからレシピ生成は純粋な決定論ロジックにしました。同じ入力なら必ず同じ出力。仕様が書き切れて、テストが書き切れて、AIに実装を任せても正解判定が機械的にできる。AI を諦めたのではなく、使う場所を決めたということです。AI の出番は、積み重なった個人の記録をもとに「次の一杯」の改善を提案するところ。提案を取り入れたレシピは、また毎回おなじ味を返します。「AIで何を作るか」というHOWの前に「AIの出力をどの価値に使うのか」を決める——これは技術選定ではなくプロダクトの意思決定です。
2. 仕様書を「正典」として先に書いた。
コアであるレシピロジック・技術アーキテクチャ・デザインシステムの3ドキュメントを固めてから実装に入りました。以降のあらゆる判断が「正典に従っているか」の検証になるので、手戻りがほぼ発生しません。
3. 品質を確かめる仕組みを先に敷いた。
ビジネスロジック層はフレームワーク非依存の純粋 Dart、テスト176本。品質保証とスピードはトレードオフではなく、確かめる仕組みがあるからこそ全速力で進められるという関係でした。
仕様を書き切る力。何を作らないかを決める力。品質に責任を持つ判断。AI はこれらを代替しません。むしろ、これらが揃っている現場ほど AI は速く走る。コモディティ化したのは作業で、価値の源泉は判断に移った——これが今回の検証の結論です。
誠実に書いておくと
前述の通り、事業計画書は仮説検証用の叩き台であり、精緻な市場分析や財務計画を含むものではありません
課金は導線UIのみ(AIの改善提案も課金後に含みます)、Firebase も計測のみ。「全部入り」ではなく MVP のスコープ設計の話です
一人での検証プロジェクトであり、チーム開発でのコミュニケーションコストは含まれていません
まとめ — 買うものが「工数」から「検証」に変わる
冒頭の問いに戻ります。
開発は「安く」なったのか——私の答えは No です。
安くなったのは調査・資料づくり・実装といった作業であり、同じ予算で手に入る価値はむしろ増えました。画面の絵ではなく実体験で仮説を検証でき、削るしかなかった体験の磨き込みまで含められ、計画ごと更新しながら検証サイクルを何周も回せる。今このIT業界で起きているのはAIの進化により早くなっているのだから値下げではなく、プロダクト開発という買い物の中身の入れ替わりです。そして、その増えた価値を数える単位が「検証」だと私は考えています。
これまでのPdMのマインドセットを変化させる上で社内では以下のような資料を作成しました。
特に注目すべきは右下の27%が以前ならやらなかった仕事です。
これまで出来なかったことが増えているということは仕事量は減っていないのです。時間は変わらず、作業の内訳と質が変わったということです。
発注側の視点で言えば、開発パートナー選びの軸は「人月単価が安いか」だけではなくなります。かといって、「伴走の手厚さ」だけでもない。どれだけ寄り添ってくれても、検証が遅ければその間に市場は瞬く間に動き、競合が先に学習を終えてしまう。検証の速度は、もはや品質の一部です。
そして、検証の回数で買えるのはGo/NoGoの確信です。1周まわすごとに間違った仮説が早く落ち、外れたまま作り込んでしまうリスクが減っていく。だからこそ選び方も複合的になります。仮説に自信のある領域は、少ない試行でさっと安く進める。外すと致命的な領域は、回数を踏んで確信を買う。「どこに、何周の検証を配分するか」——発注の意思決定の材料そのものが変わるということです。私たちが提供したいのは時間をかけて作った資料でもなく、機能数に比例するコードの行数でもなく、発注者側のペースにあわせ一緒に走ってあげる伴走人材でもない。圧倒的な速度で実体験まで到達する検証サイクルと、その配分を設計する判断の質によって起こる、ビジネス成長とエンドユーザーの満足度です。
「アイデアはあるが、プロトタイプ止まりで本当の手応えが分からない」——そんな課題をお持ちの方は、ぜひ一度 bravesoftまでご相談ください。画面の絵ではなく、触れる実体で検証するところから一緒に始めましょう。
