フェーズ別、作るべきものの全体像

スタートアップの開発でよくある行き違いは、「何を作るか」を機能の一覧として話し始めることです。機能一覧から入ると、話は足し算にしかなりません。実際には、フェーズごとに確かめたいことが違い、確かめたいことが違えば、必要なものも入れ替わります。

本記事は、投資フェーズ別のシリーズの入口として、プレシードからシリーズB以降までの各段階で「何を確かめるのか」「そのために何を作るのか」の対応を整理します。各フェーズの詳細は、それぞれの記事で個別に扱います。

フェーズは調達額ではなく「未解決の問い」で決まる

フェーズを調達額やラウンドの名前で捉えると、自社がどこにいるのか分かりにくくなります。判断しやすいのは、「今、一番確かめられていないことは何か」で見る方法です。

• 課題が本当に存在し、誰かがそれにお金や時間を払うのか → プレシード相当
• 作ったものを、人が繰り返し使い続けるのか → シード相当
• 顧客を獲得する方法に再現性があるのか → シリーズA相当
• 人が増えても開発と運用が回り続けるのか → シリーズB以降相当

調達をしていなくても、確かめたい問いがこのどれかに当てはまるなら、同じ考え方が使えます。逆に、調達を終えていても課題の存在が未確認なら、作るべきものはプレシードのそれです。

フェーズと作るべきものの対応

実務で重要なのは右列です。作るものの一覧は自然に増えますが、作らないものの一覧は意識しないと作られません。

各フェーズで何が変わるのか

プレシード — 多くの場合コードは要らない

この段階の問いは「課題が本当にあるか」です。この問いは、ほとんどの場合プロダクトなしで確かめられます。説明ページを出して反応を見る、手作業でサービスを提供してみる、表計算ソフトで運用してみる、といった手段のほうが速く安く確かめられます。詳しくはプレシードで作るべきものは何かで扱います。

シード — 中心の体験だけを、まともに作る

問いは「使い続けられるか」に変わります。ここで初めてプロダクトを作りますが、作るのは中心の体験だけです。管理画面、権限、決済、通知といった周辺は、どこまで省けるかを一つずつ判断します。省き方の基準はシード期のMVPはどこまで作るかにまとめました。

この段階でよく出てくるのが「AI機能を載せるか」の判断です。差別化のために必要なのか、なくても検証は成立するのかで分かれます。多くの場合は後者です。判断の材料はシード期にAI機能を載せるべきかで整理しています。

シリーズA — 作るものの性質が変わる

ここから、作るものの目的が「確かめること」から「繰り返せるようにすること」へ移ります。何が起きているかを数字で見る仕組み、増えた人が安全に使える権限管理、問い合わせに対応するための運用画面。いずれも顧客には見えませんが、この三つが欠けたまま人と広告費を増やすと、伸びない理由が分からなくなります。詳細はシリーズAで開発の何が変わるかをご覧ください。

あわせて、調達直後は技術的負債の扱いが議題に上がります。全面的な作り直しは選ばず、人が増えることの障害になる部分から順に返すのが現実的です。順番の付け方は調達後に返す技術的負債の順番で扱います。

シリーズB以降 — 個々の機能より、続けられる仕組み

この段階の問いは「組織として開発を続けられるか」です。作るものは、プロダクトの機能より、開発を支える仕組みに寄ります。データ定義の共通化、テストと配信の自動化、障害に気づく監視、新しく入った人が短期間で貢献できる環境。一覧にすると地味ですが、ここに投資していないと、人を増やしても出せる量は増えません。

フェーズを取り違えると何が起きるか

取り違えには二つの方向があります。

先に作りすぎる。課題の存在が確かめられていないのに、想定した全機能を作ってしまうパターンです。仮説が変われば作ったものの多くが使われません。加えて、作り込んだ分だけ「せっかく作ったので方向転換したくない」という力が働き、判断が遅れます。

遅れて作る。すでに顧客が増えているのに、誰が何をしたかを追える仕組みがなく、問い合わせのたびにデータベースを直接見ているような状態です。この段階では、機能追加より先に計測と運用を整えたほうが結果的に速くなります。

どちらも「今どの問いに答えている最中か」を言語化していれば避けられます。作るものを決める会議の最初に、その一文を確認するだけで、議論の足し算が止まります。

外部に依頼するときに伝えること

開発を外部に依頼する場合、フェーズの共有は費用にも品質にも影響します。何を確かめたいかが伝わっていないと、依頼を受けた側は安全側に倒し、将来の拡張を見越した作りを提案しがちです。検証段階では過剰になります。

依頼時に伝えると噛み合いやすいのは次の三つです。

1. 今確かめたい問い（一文）
2. その問いの答えが出たときに、次に何を判断するか
3. 仮説が外れた場合に捨ててよい部分

三つ目を明示すると、相手も「ここは作り込まない」という判断ができます。フェーズごとの体制や契約形態の考え方は資金調達フェーズ別に見る、開発パートナーとの関わり方で扱っています。人数と外部比率の判断はフェーズ別、開発の人数と外部比率にまとめました。

フェーズと調達額はずれることがあります。調達を終えた会社が、シリーズA相当の計画として権限管理と管理画面の整備を進めている場面を想定してみてください。ところが、既存顧客の継続率を確認すると、契約更新まで残った利用者は当初の想定を大きく下回っていました。確かめられていなかったのは「使い続けられるか」であり、フェーズとしてはシード相当の問いが未解決でした。この会社が取った対応は、整備の計画を止め、離脱した利用者に理由を聞く工程に戻ることでした。調達額はシリーズAでしたが、作るべきものはシードのそれだったという例です。

弊社がフェーズの前倒しに反対する理由

ご相談の場で、弊社は「次のフェーズを見越して今のうちに」という進め方には反対の立場を取ります。

先取りが提案される理由は、たいてい合理的に聞こえます。後から入れると高くつく、作り直しになる、二度手間になる。しかし、この理屈が成立するのは、先取りした前提が実際に当たった場合だけです。検証段階のスタートアップで、一年先の要件が当たる確率は高くありません。外れた場合、先取りした分は使われないまま保守の対象として残ります。

作り直しを恐れて先取りするより、捨てやすい形で作り、捨てるほうが、この段階では安く済みます。開発を請け負う側としては、作り込む提案のほうが受注額は大きくなります。それでも先取りをお勧めしないのは、使われない実装の保守費用が、発注側に長く残るからです。

例外は、後から入れると事業側に影響が及ぶ領域です。データの持ち方、認証、他人のデータが見えないこと、記録が残ること。ここは最初から標準的な形で作ります。この線引きだけは、フェーズにかかわらず共通です。

この一覧の使い方

このシリーズは、機能の正解を示すものではありません。フェーズごとに「今は作らない」と言える根拠を持つための整理です。問いを一文で書き、それに答えない機能を脇に置く。この繰り返しが、限られた資金と時間の使い方を決めます。

フェーズの判断や、今作るべき範囲の相談は、Webシステム開発や市場リサーチとあわせてお問い合わせからどうぞ。ご相談・お見積りは無料です。