シード期の開発で失敗しやすいのは、作る量が多すぎることです。「作らない」判断を先に言葉にしておくと、資金の減り方が読めるようになります。
1. このシートの使い方
上から順に埋めてください。空欄のまま進めても構いませんが、空欄が多い項目ほど、後から見積りや期間がぶれる場所になります。開発パートナーに相談する前に一度埋め、相談したあとにもう一度見直すと、認識のずれが見つかります。一人で埋めるより、経営者と事業責任者の二人以上で別々に書き、突き合わせるほうが効果があります。
2. 今のフェーズを言葉にする
「シード期」という言葉は、会社によって指す状態が違います。資金の状況と顧客の状況を数字と事実で書き出すと、今やるべきことの範囲が絞れます。ここが曖昧なまま機能の議論を始めると、話が噛み合いません。
3. 今のフェーズで確かめたいことを一つに絞る
シード期のプロダクトは、事業のすべてを表現するものではありません。次の資金調達やチーム拡大の判断材料になる問いを一つだけ選び、それ以外を今回の対象から外します。問いが複数ある場合は、外れたときに事業が止まるほうを選びます。
4. 作らないものを先に決める
シード期に着手を見送ることが多い領域を挙げます。必要かどうかではなく「今の問いを確かめるのに要るか」で判断してください。見送ったものは消さずにリストに残し、どうなったら着手するかの条件を書き添えます。
5. 投資家に見せる材料を分けて考える
投資家との対話で必要になるのは、完成したプロダクトそのものではなく、顧客が使っている事実と、そこから読み取れる兆しです。プロダクトの見栄えを整える作業と、事実を積む作業は別物として扱い、資金と時間の配分を決めます。
6. あとで作り直す前提の部分を明示する
シード期のコードは、検証結果によって捨てる可能性があります。すべてを丁寧に作ると資金が足りず、すべてを雑に作ると当たったときに土台が残りません。作り直す前提の部分と、残す前提の部分を分け、開発パートナーと文書で合意します。
7. 最低限の守りを確認する
フェーズにかかわらず、事故が起きると事業そのものが止まる領域があります。シード期でも手を抜きにくい範囲を挙げます。過剰な作り込みは要りませんが、抜けていないかの確認は必要です。
8. 名義と権利を自社に寄せる
シード期のうちに整えておくと、その後の調達やチーム拡大で手戻りが減る事務的な項目です。作業そのものは短時間で済みますが、後回しにすると関係者が増えてから直すことになります。
9. 次の見直し日を決める
このシートは一度埋めて終わりにせず、検証期間の区切りごとに見直します。日付を決めずに置くと、状況が変わっても最初の判断のまま走り続けることになります。見直しの場では、作らないと決めたものの条件が満たされたかどうかも確認します。
関連するインサイト
- 資金調達前に整えておきたいプロダクトと技術面の準備投資家による技術デューデリジェンスを見据え、資金調達前に整えておきたい準備を手順化。プロダクトの現状説明資料、指標の整理、技術的負債の可視化、セキュリティと個人情報の基本対応、ソースコードの権利、開発体制の説明を解説します。
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP（実用最小限の製品）の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
- 資金調達フェーズ別に見る、開発パートナーとの関わり方プレシード・シード・シリーズA・シリーズB以降の各フェーズで検証すべきこと、開発体制、契約形態、避けたい失敗を整理し、外部の開発パートナーとどう関わるかを段階ごとに解説します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開