シード期の開発で失敗しやすいのは、作る量が多すぎることです。「作らない」判断を先に言葉にしておくと、資金の減り方が読めるようになります。
1. このシートの使い方
上から順に埋めてください。空欄のまま進めても構いませんが、空欄が多い項目ほど、後から見積りや期間がぶれる場所になります。開発パートナーに相談する前に一度埋め、相談したあとにもう一度見直すと、認識のずれが見つかります。一人で埋めるより、経営者と事業責任者の二人以上で別々に書き、突き合わせるほうが効果があります。
2. 今のフェーズを言葉にする
「シード期」という言葉は、会社によって指す状態が違います。資金の状況と顧客の状況を数字と事実で書き出すと、今やるべきことの範囲が絞れます。ここが曖昧なまま機能の議論を始めると、話が噛み合いません。
- 現時点の手元資金と、月々の支出(人件費・外注費・その他に分けて)
- 直近で予定している調達の有無と、その想定時期
- 有償・無償を問わず、実際に使っている顧客の数
- 顧客に会って話を聞いた回数(直近3か月)
3. 今のフェーズで確かめたいことを一つに絞る
シード期のプロダクトは、事業のすべてを表現するものではありません。次の資金調達やチーム拡大の判断材料になる問いを一つだけ選び、それ以外を今回の対象から外します。問いが複数ある場合は、外れたときに事業が止まるほうを選びます。
- 顧客がこの課題にお金を払う意思があるか
- 顧客が繰り返し使う理由があるか
- この方法で顧客に届けられるか(獲得の手段が成立するか)
- 技術的に実現できるか(実現性に本当に不確かさがある場合のみ)
4. 作らないものを先に決める
シード期に着手を見送ることが多い領域を挙げます。必要かどうかではなく「今の問いを確かめるのに要るか」で判断してください。見送ったものは消さずにリストに残し、どうなったら着手するかの条件を書き添えます。
- 権限管理の作り込み(役割が複数ある前提の設計)
- 管理画面の網羅的な機能(データベースや表計算での代替を検討する)
- 複数プランの課金と請求の自動化
- 多言語対応、複数通貨対応
- ネイティブアプリ(Webで確かめられないかを先に検討する)
- 自動テストの網羅(壊れると事業が止まる箇所に絞る)
5. 投資家に見せる材料を分けて考える
投資家との対話で必要になるのは、完成したプロダクトそのものではなく、顧客が使っている事実と、そこから読み取れる兆しです。プロダクトの見栄えを整える作業と、事実を積む作業は別物として扱い、資金と時間の配分を決めます。
- 見せられる状態にしておきたい画面はどれか(1〜3画面程度に絞る)
- 顧客の利用が数字で示せるか(登録、継続、頻度など、記録が残っているか)
- 顧客の声を引用できる形で持っているか(記録の許可を得ているか)
- 見栄えの改善に使う時間の上限を、あらかじめ何日と決めているか
6. あとで作り直す前提の部分を明示する
シード期のコードは、検証結果によって捨てる可能性があります。すべてを丁寧に作ると資金が足りず、すべてを雑に作ると当たったときに土台が残りません。作り直す前提の部分と、残す前提の部分を分け、開発パートナーと文書で合意します。
- 残す前提にしたいもの: 顧客データの構造、認証の仕組み、ドメインとアカウントの名義
- 作り直してよいもの: 画面の流れ、料金の表現、管理側の画面
- 作り直す判断を、誰がいつ行うか(検証終了後の日付を入れる)
7. 最低限の守りを確認する
フェーズにかかわらず、事故が起きると事業そのものが止まる領域があります。シード期でも手を抜きにくい範囲を挙げます。過剰な作り込みは要りませんが、抜けていないかの確認は必要です。
- 顧客の個人情報をどこに保存し、誰がアクセスできるか把握しているか
- 取得する情報が、実際に必要な範囲に収まっているか
- 本番のデータのバックアップが取れていて、戻せることを一度試したか
- 認証情報(各種サービスのパスワード・鍵)の管理方法が決まっているか
- プライバシーポリシーと利用規約の草案があるか
8. 名義と権利を自社に寄せる
シード期のうちに整えておくと、その後の調達やチーム拡大で手戻りが減る事務的な項目です。作業そのものは短時間で済みますが、後回しにすると関係者が増えてから直すことになります。
- ドメイン、クラウド、各種サービスのアカウントが自社名義になっているか
- ソースコードの保管場所が自社の管理下にあるか
- 外部に依頼した成果物の権利の帰属が、契約書に書かれているか
- 業務委託・副業メンバーとの間で、成果物と秘密保持の取り決めがあるか
9. 次の見直し日を決める
このシートは一度埋めて終わりにせず、検証期間の区切りごとに見直します。日付を決めずに置くと、状況が変わっても最初の判断のまま走り続けることになります。見直しの場では、作らないと決めたものの条件が満たされたかどうかも確認します。
- 次に見直す日付(検証期間の終わり、または調達の準備開始時)
- その日までに集める事実は何か
- 見直しの場に誰が参加するか
- 見直しの結果として起こりうる判断(続ける・対象を変える・やめる)を先に書いておく
関連するインサイト
- 資金調達前に整えておきたいプロダクトと技術面の準備投資家による技術デューデリジェンスを見据え、資金調達前に整えておきたい準備を手順化。プロダクトの現状説明資料、指標の整理、技術的負債の可視化、セキュリティと個人情報の基本対応、ソースコードの権利、開発体制の説明を解説します。
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP(実用最小限の製品)の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
- 資金調達フェーズ別に見る、開発パートナーとの関わり方プレシード・シード・シリーズA・シリーズB以降の各フェーズで検証すべきこと、開発体制、契約形態、避けたい失敗を整理し、外部の開発パートナーとどう関わるかを段階ごとに解説します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開