育てると決めたら：どこまで伸ばし、いつ止めるのか

プロダクトを育て続ける方向に決めた瞬間、それまで抑え込んでいた機能要望のリストが一気に噴き出します。顧客と接する営業チームはこの機能を、問い合わせを受けるCSチームはあの機能を求め、代表も公開前から温めていたアイデアを持ち出します。要望リストは際限なく膨らみますが、与えられた予算と開発人員は変わりません。どの案件にもそれなりの理由があるため、何から手をつけるかは純粋に優先順位判断の領域になります。

この段階で最もよくある間違いは、受け付けた順番や声の大きい人の要求を先に処理してしまうことです。そのやり方で企画、開発、リリースのサイクルを三、四回繰り返すと、何を先に扱うべきだったのか、そしてどこまで機能を足し続けてよいのかという明確な基準がなかったことに気づきます。予算に余裕があれば順序が多少乱れても目立ちませんが、大半のスタートアップにその余裕はなく、一つの優先順位の誤りがプロダクトサイクル全体を崩しかねません。

先の第2部では、プロダクトを育て続けると決める根拠が、当初の仮説が依然として有効であることだと述べました。その根拠が、今回の優先順位設定の出発点になります。

何から育てるか

プロダクトを育てると決めたのは、事業仮説が成り立つという意味にすぎず、到達・反復・支払い・要望という四つのシグナルすべてが強いという意味ではありません。たいていは一つか二つ、弱い部分が残っているものです。新機能をやみくもに追加する前に、この弱い部分を先に補強するのが正しい順序です。

到達のシグナルが弱いとき: まず初回のユーザー体験とオンボーディングの流れを見直します。登録後、中核価値を体験するポイントまでのハードルを下げる作業が最優先です。
反復のシグナルが弱いとき: サービスの中核価値をさらに強化します。ユーザーが繰り返し戻ってくる本質的な理由を明確にする必要があります。
支払いのシグナルが弱いとき: まず価格設定と決済動線を整えます。単に機能を増やしたところで、閉じた財布は開きません。

上記三つのシグナルがすべて安定的に確保された後で、ようやく要望のシグナル、つまり新機能の追加を検討します。この順序が逆転すると、弱い部分は放置されたまま表面的な機能ばかりが増え、次の判断の時点でも同じ壁にぶつかります。この基準を一度確立しておけば、サイクルのたびに起きる不要な優先順位の議論を減らせます。

予約サービスでこの順序が入れ替わる状況は珍しくありません。予約完了までに五段階も要する構造的な問題を放置したまま、レビュー共有機能を新しく開発します。二回サイクルを重ねても到達率は変わりません。手間をかけて作ったレビュー機能が、中核となる段階にすら到達できていない大多数のユーザーには届かないためです。オンボーディングの動線から改善していれば、新しいレビュー機能の効果も一緒に大きくなっていたはずの場面です。

機能追加と整備の配分

新機能を追加する作業と、既存システムを整える作業のバランスを取ることも重要です。通常、一サイクルは2週間から6週間ほどかかります。

経験上、各サイクルの作業量の30%程度は、新規開発ではなく既存コードの整備と構造改善に割り当てる必要があります。短期間で組んだ初期のコード、応急的につないだロジック、後回しにしていたパフォーマンス最適化などがこれに当たります。この割合を無視して新機能の追加だけに開発力を注ぎ込むと、三回目や四回目のサイクルあたりから開発速度が目に見えて落ちます。機能を一つ足すたびに、既存コードとの衝突箇所が加速度的に増えていくためです。

この配分は、大がかりなツールがなくても管理できます。サイクルを始める際に新機能のリストと整備作業のリストを並べて作成し、後者が空のまま放置されていないかを確認するだけで十分です。整備の項目が二サイクル連続で空だとしたら、その時点からはプロダクトの成長ではなく技術的負債が積み上がっているという警告のシグナルです。

育てるのを止めるべきシグナル

既存の構造を育て続けるプロセスが無限に続くわけではありません。次の四つの兆候が現れ始めたら、現在のアーキテクチャで受け止められる限界に達したという意味です。

停止シグナル	意味するもの
機能を一つ追加する期間がサイクルごとに長くなる	システム構造が新機能を受け入れるコストが過度に積み上がっている状態
一つを直すと別の機能が壊れる	モジュール間の依存関係が複雑に絡み合い、独立した修正ができない状態
新規ユーザーのオンボーディングが徐々に複雑になる	これまで積み重ねた機能が当初の中核価値の体験を覆い隠している状態
開発会社が「構造を変える必要がある」と二度以上提案する	開発の現場がシステムの構造的限界を最初に察知するシグナル

これらの兆候は単独では現れません。オンボーディングが複雑になって新規の転換率が落ちると、それを補おうとしてさらに機能を積み重ね、それが次のサイクルの開発期間をさらに遅らせるという悪循環につながります。

とりわけ開発会社からの構造変更の提案は、主観的な主張ではなく客観的なデータに基づく根拠として受け止める必要があります。サイクルごとにシステム構造と直接向き合っているのは開発チームであり、同じ指摘が繰り返されるということは、アーキテクチャが限界に達していることを意味します。一度であれば見方の違いとして流せても、二度目の提案からは構造再設計の強力な根拠として扱うのが安全です。

育てることの終わり

育てるプロセスには終わりがないと考えがちですが、実際には機能の完成時点ではなく、次の意思決定を下すタイミングこそが育成の区切りです。通常は三、四回のサイクル、期間にして6か月から9か月ほどが経つと、現在の構造を維持するか、作り直すべきかを判断する時点に到達します。

この判断は感覚に頼りません。サイクルごとに記録されたデータ、つまり何を追加し、何を整備し、どんな問題が繰り返されたかを突き合わせ、停止シグナルを点検するプロセスです。記録がなければ判断の時点があいまいになり、システムの損失が深刻化してから問題に気づくことになります。上記の停止シグナルのうち二つ以上が重なっていれば、全面的な作り直しを検討すべき時点です。構造を作り直す際に何を引き継ぎ、何を捨てるかは第4部で扱います。