MVPを作ったのに、検証が終わらない。改善要望が増えるたびに期間を延ばし、最後は「よくできたアプリ」と報告書だけが残る。新規事業で繰り返される失敗です。
私たちが大手旅行会社との共創案件で4週間かけて確かめたのは、アプリの出来ではありませんでした。企画し、作り、育て、評価し、得た学びを次の企画へ戻す——この「学習の輪」が一周するかです。
本記事では、4週間という短い期間を機能させた契約の3点、伴走の役割、作る人と育てる人の関係、2つの評価軸を実務に落として解説します。
【結論】AI時代の新規事業で、先に設計すること
| 検証期間は、作業量ではなく「確証が足りなくても評価する日」として先に固定する契約・稟議には、仮説、成功条件、締め切りの3点をセットで書く小規模・短期間では、作る人と育てる人を近づけ、引き継ぎで落ちる文脈を減らす日々は個別の出来を見て改善し、節目では学習の輪が一周したかを評価する |
ほとんどのプロジェクトは、一本の線で終わる
プロジェクトはたいてい、一本の線として始まる。企画があって、それを形にする人がいて、終わったら報告する。矢印は一方向に進み、最後に報告書が残る。
問題は、その線が次の企画に繋がらないことである。報告書は書かれる。しかし次の案件は、また白紙から始まる。前回何を学んだかは担当者の頭の中に残るだけで、組織のどこにも置かれていない。
線を輪にする、というのはこの逆である。企画 → 作る → 育てる → 事業として成立するか判断する → そこで得た学びが、次の企画に戻る。矢印が一周して戻ってくる。
言葉にすると当たり前に聞こえる。ただ、実際に一周させるのは難しい。多くの場合、輪は一周する前に力尽きる。
先日、実際に一周した4週間があった。何がそれを可能にしたのかを、順に見ていく。
なぜ、線で終わってしまうのか
その前に、輪にならない側の理由を整理しておきたい。悪意も怠慢もないのに線で終わるのには、だいたい3つの理由がある。
- 終わりに、評価の場が無い。 納品して、報告書を出して、解散する。「この案件から何を学んだか」を全員で並べて見る時間が、どこにも予約されていない。忙しければ、予約されていない時間は必ず消える。
- 学びが、個人の中に残る。 実際にやった人の頭の中には、確実に何かが残っている。しかしそれは言葉になっていないので、その人が別の案件に移った瞬間、組織からは消える。次の案件は別の人が担当するので、また一から同じことに気づく。
- 「次に活かす」が、誰の仕事でもない。 現場は次の案件で手一杯で、上は個別案件の中身まで見ていない。誰も担当していない仕事は、当然やられない。
この3つを裏返すと、輪にするために要るものが見えてくる。立ち止まる時間を先に予約しておくこと。学びを個人の外に出しておくこと。そしてそれを誰かの仕事にしておくこと。
以下で見ていく4週間には、この3つがそろっていた。
契約に、締め切りが書いてあった
その案件は、大手の旅行会社向けにアプリを4週間で改善し検証する、というものだった。複数社が入る共創ワークスペースの中で動く、戦略案件である。
他の案件と違ったのは、期限が最初から契約に入っていたことだった。
仕事を受け渡すとき、本来そこには3つのことが書かれていなければならない。何を確かめたいのか（仮説）。何が起きたら成功と見なすのか（成功の見方）。いつまでにやるのか（締め切り）。
このうち締め切りは、いちばん軽く扱われやすい。単なるスケジュールの都合だと思われているからだ。しかし実際には、締め切りが輪の速度と、終わり方を決めている。
締め切りが曖昧だとどうなるか。「もう少し検証すれば確証が持てそうだ」という感覚は、ほとんど常に正しく感じられる。厄介なのはここで、この感覚はたいてい本当に正しい。もう少しやれば、たしかに精度は上がる。だからこそ歯止めが効かず、輪はいつまでも一周を終えない。
4週間という数字は、恣意的に決まったものではなさそうだった。企画にかかる時間、作る時間、反応が見え始めるまでの時間、評価する時間。これらを足したときに、一周させるのに必要な最小単位として逆算されたように見える。
そして効いていたのは、この4週間が「4週間経ったら、確証が足りなくても評価のテーブルにつく」という規律でもあったことである。締め切りは作業量の話ではない。いつ立ち止まるかの取り決めである。
契約を結ぶ人と、守らせる人は、別々でいい
ただし、契約を結んだだけでは輪は回らない。紙の上の約束を、日々の現実の中で守り続ける人間が要る。
この案件では、現場推進をリードしたSさんがその役割だった。
4週間は、聞こえるほど長くない。日々の進行の中では、無数の小さな判断が起きる。ここで立ち止まるべきか、このまま進むべきか。その一つ一つの積み重ねが、「4週間後に評価する」という約束を、実際に守れるものにしていく。
派手な意思決定ではない。静かな伴走である。
ここから読み取れるのは、契約を結ぶ人と、契約を守らせ続ける人は、同じである必要がないということだった。むしろ分けたほうが機能する。結ぶのは一瞬の仕事で、守らせるのは4週間ずっと続く仕事だからである。求められる性質がそもそも違う。
作る人と育てる人の、境目が消えた
この4週間で、いちばん面白い現象が起きたのはここだった。
教科書的には、「作る人」と「育てる人」は別である。開発が形にしたものを、グロース担当が育てる。間には引き継ぎがあり、受け渡しがあり、そこには必ずいくらかのロスが生まれる。
しかしこの案件では、その境目が溶けていた。アプリを育てる役を担ったKさんの中で、作ることと育てることが、同時に、一体として進んでいた。
これは手順を省略したということではない。輪が小さく、速く、当事者が同じ文脈を持っているとき、本来別々であるはずの工程が自然に折り畳まれる、ということである。
折り畳まれると、引き継ぎのロスがそもそも発生しない。
引き継ぎで失われるものを具体的に書くと、こうなる。なぜその作りにしたのかという理由。検討して捨てた案。作りながら気づいた、まだ言葉になっていない違和感。 引き継ぎ資料に書かれるのは決まった仕様であって、この3つはたいてい落ちる。書くのが面倒だからではなく、渡す側が「これは書くほどのことではない」と判断してしまうからである。
そして育てる段になって効いてくるのは、まさにこの落ちた3つのほうだったりする。1人の中で完結していると、この情報が失われる場所がない。学びが、そのまま次の一手に変換される。
結果として現れたのは、想像を超える育ち方と、想像以上に磨き込まれた検証だった。これは担当者が優秀だったという話に還元できない。引き継ぎが無いという構造が生んだものとして説明がつく。
大きなプロジェクトが持てない速さが、小さいプロジェクトにはある。その正体のひとつが、これである。
4週間後、想定と違う問いが置かれた
期限が近づけば、当然こう聞きたくなる。「このアプリは、うまくいったのか」。
しかし実際にテーブルに置かれた問いは、これではなかった。
問われたのは、「企画 → 作って育てる → 事業として推進する → 企画、という矢印が、本当に一周して戻ってきたか」だった。
個別のサービスの数字は、この問いの前では二次的な情報として扱われた。プロダクトが多少不完全でも、輪が機能して次の企画への学びが生まれていれば、それは価値だった。逆にプロダクトの完成度が高くても、輪が一周せず次に繋がらなければ、評価に値しなかった。
物差しは、二種類ある
この問いの立て方そのものが、いちばん重要な発見だったと思う。
物差しには二種類ある。
ひとつは個別の出来を見る物差し。このコードは正しいか。この提案は顧客の目線でおかしくないか。この数字は良いか。現場が日々使うのはこちらである。
もうひとつは構造が機能したかを見る物差し。輪が一周したか。次の企画に戻る学びが生まれたか。
この二つは階層が違う。そして厄介なのは、混ぜると必ず前者に引きずられることである。数字のほうが具体的で、目に見えて、議論しやすい。会議の場で強いのは、いつも具体的なほうだ。
意識して後者を置かないと、評価はいつのまにか「プロダクトの出来栄え」に矮小化される。この案件でそうならなかったのは、評価の焦点を最初から構造側に置いていたからだった。
第2部のまとめ
一本の線として始まったプロジェクトが、4週間かけて輪になった。それを可能にしたのは、次の3つだったと整理できる。
- 締め切りが契約に入っていた — いつ立ち止まるかが、最初から決まっていた
- 契約を守らせ続ける人が、別にいた — 結ぶ仕事と、守らせる仕事を分けた
- 評価の物差しを、構造側に置いた — プロダクトの出来ではなく、輪が回ったかを見た
念のため書いておくと、ここまでは私の読み解きである。当事者が最初からこう設計したというより、実際に起きたことを後から構造として取り出すと、こう説明がつく、という話に近い。
- そして、ここで話は終わらない。むしろ、ここからが本番である。
輪が一周したという事実は、その中にいた人たちの経験としては確かなものになった。しかしその経験は、まだその輪の中に閉じ込められている。 別のクライアント向けの案件には、自動的には何も伝わらない。
- 第3部では、閉じた輪をどう他へ移すのかを扱う。そしてなぜそれが、輪の中にいる人には構造的にできないのかも。
よくある質問（FAQ）
Q. MVP検証は4週間で十分ですか？
すべてを証明するには足りません。しかし、一つの仮説について実ユーザーの反応を得て、評価の場へ着くには十分な場合があります。期間は事業ごとに変わりますが、開始前に評価日を固定する点が重要です。
Q. MVPの成功条件は、何を置けばよいですか？
利用、継続、問い合わせ、課金など、市場側の行動を置きます。完成機能数や社内評価だけでは事業性を確かめられません。撤退の停止条件と、次のゲートへ進む判断材料は分けて設計します。
Q. 4週間で結果が出なければ、すぐ撤退すべきですか？
直ちに撤退とは限りません。評価日に必ず立ち止まり、仮説を変える、追加検証する、縮小する、止めるを判断します。「もう少し」を無条件に延長しないことが目的です。
この連載を順番に読む
- 第1部｜AI活用で新規事業はどう変わる？「指示・回す・つなぐ」3段階
- 第2部｜新規事業のMVP検証を4週間で回す方法
- 第3部｜新規事業の成功事例を横展開する方法
- 第4部｜AIループインキュベーションとは？
公開順：第1部 → 第2部 → 第3部 → 第4部。4本を公開後、相互リンクの到達確認を行ってください。
アルチェコに相談する
| PoCを「作って終わり」にしたくない方へ 4週間で何を証明するか、一緒に設計しませんか アルチェコは、仮説・成功条件・締め切りを先に定め、MVPを最短数週間で構築し、実ユーザーの利用・課金まで検証します。アプリの完成度ではなく、次の投資判断に使える一次データを残します。 ▶ MVP検証について相談する 初回相談では、現状のフェーズ・検証したい仮説・社内の意思決定条件を整理します。相談内容が固まっていなくても問題ありません。 |
この記事を書いた会社について（アルチェコ）
アルチェコ（ARCHECO）は、AI戦略・生成AI導入・AIエージェント開発・UX/UIデザイン・MVP/PoC開発・グロースを横断する新規事業の共創パートナーです。戦略だけ、開発だけで分断せず、仮説設計から実市場での検証まで一貫して支援します。
Yasu
Yuki Susai
