ブリッジ期に何を作り、何を止めるか

次の調達までの見通しが立たない期間、いわゆるブリッジ期には、開発の判断の性質が変わります。平時であれば「何を作るか」を議論しますが、この局面で重みを持つのは「何を止めるか」です。そして止める判断は、先送りにするほど選べる選択肢が減っていきます。

本記事では、資金が細る局面で開発をどう絞り込むかを、経営者・事業責任者の判断材料として整理します。数字の置き方は事業によって大きく異なるため、金額ではなく考え方を中心に述べます。

証明すべきことを一つに絞る

最初にやることは、削減の検討ではありません。次の調達で何を証明できていればよいのかを一つに絞ることです。これが決まらないと、何を止めてよいかの基準がありません。

絞る対象は、たとえば次のようなものです。

• 特定のセグメントで継続率が改善していること
• 一定の獲得単価で新規顧客が取れる経路が見つかっていること
• 単月の粗利が黒字化する道筋が数字で説明できること
• 大口の顧客が本格導入に進んでいること

複数を挙げたくなりますが、資金が限られている局面では、複数を同時に追うと、どれも中途半端な数字になります。一つに絞ると、開発の判断がかなり機械的になります。「この開発は、絞った数字に効くか」という問いに答えるだけで済むためです。

指標の選び方についてはプロダクトのKPI設計とダッシュボードやPMFをどう見極めるかもあわせてご覧ください。

止める単位は機能ではなく活動

「どの機能を削るか」という問いの立て方は、実はあまり効率的ではありません。すでに動いている機能は、触らなければ追加の費用がほとんど発生しないことが多いためです。削除の作業自体にコストがかかり、短期的には支出が増えることさえあります。

止めるべきは、継続的に人の時間と資金を消費している活動です。具体的には次のようなものです。

• 特定の顧客向けの個別対応や、要望に応じた改修の受け入れ
• 検証がまだ済んでいない新領域への投資
• 定例の改善サイクルのうち、絞った数字に効かないもの
• 複数の販路・チャネルの並行運用

想定例：ある会社が、主力の業務向けサービスに加えて、一般消費者向けの簡易版を並行して育てていたとします。ブリッジ期に入り、証明すべき数字を「主力サービスの継続率」に絞りました。ここでの判断は、簡易版のコードを消すことではなく、簡易版に割いていた開発と問い合わせ対応の稼働をゼロにし、既存利用者にはそのまま使い続けてもらう形にすることでした。動いているものを止めるコストは払わず、消費している時間だけを止めるという判断です。

一方で、動かし続けること自体が費用になっている場合は別です。専用のサーバーや有償サービスに依存している機能は、止めれば直接的に支出が減ります。この判断は次の節の話につながります。

運用コストは「削るリスクの小ささ」の順で見る

運用コストの圧縮は、削減額の大きい順ではなく、削ったときのリスクが小さい順に手をつけます。資金が細る局面で障害を起こすと、そこから先の選択肢がさらに狭まるためです。

順序としては、おおむね次のようになります。

1. 誰も使っていないもの：検証用に立てたまま残っている環境、終了した施策の残骸、期限の切れたアカウント。止めても事業に影響しません。
2. 契約・サブスクリプションの棚卸し：座席数が実人数と合っていない有償ツール、重複している機能の契約、自動更新のまま使われていないもの。
3. 規模の適正化：性能に余裕がありすぎるサーバーやデータベースを、実際の利用に合わせて下げる。
4. 割引・予約の仕組みの活用：一定期間の利用を確約することで単価を下げられる仕組み。ただし、期間の確約は資金が細る局面では慎重に判断します。
5. 構成そのものの見直し：影響が大きく、作業時間もかかります。この局面で手をつけるのは、支出に占める比率が突出している場合に限ります。

具体的な進め方はクラウドインフラコストの圧縮に整理しています。ここで強調したいのは、ブリッジ期は5番に手を出しにくい時期だということです。構成の見直しは効果が大きい一方、作業中に事故が起きる確率がゼロではなく、かつ効果が出るまでに時間がかかります。時間と安全の余裕がない局面では、1から3で止めるという判断が合理的です。

AI機能を持っている場合、外部APIの利用料は利用量に比例するため、ここも点検の対象になります。ただし、削るべきは機能そのものではなく、無駄な呼び出しであることが多いです。同じ内容を繰り返し送っていないか、必要以上に長い文脈を渡していないか、上限の設定があるかを確認してください。既製のサービス側に利用量の管理機能が用意されていることも多く、まずそれで見えるようにするのが先です。

止め方には再開の余地を残す

ブリッジ期の判断は、状況が変われば覆ります。調達が決まれば、止めたものを再開したくなります。だからこそ、止め方が重要になります。

再開できる止め方の要点は次のとおりです。

• 削除ではなく無効化にする：コードや設定を消すと、戻すのに再実装が必要になります。表示しない、受け付けないという形で止めておけば、戻す判断が軽くなります。
• 判断の理由を残す：なぜ止めたのか、どうなったら再開するのかを一行ずつでも書き残します。数か月後には、止めた理由を誰も覚えていません。
• データは残す：利用ログや顧客データを消すと、再開時に連続性が失われます。保管費用は多くの場合それほど大きくありません。個人情報を含む場合は、保管期間と利用目的の整理が別途必要です。
• 顧客への告知は先に：提供を止める機能に利用者がいる場合、告知と移行期間を先に決めます。突然の停止は、残っている顧客の解約を招き、証明したかった数字を自分で壊すことになります。

開発を止めきらない

最後に、この局面でもっとも避けたい判断に触れておきます。それは、開発をすべて止めて資金を守ることです。

資金の残高は、それ自体では調達の材料になりません。投資家が見るのは、この期間に何が前進したかです。使える資金を全部守った結果、証明すべき数字が何も動いていないという状態は、資金が尽きかけている状態よりも説明が難しくなります。

同時に、止めてはいけないものもあります。障害への対応、セキュリティの更新、顧客データの保全。これらは事業の継続そのものに関わるため、規模を縮小しても残す必要があります。ここを削ると、事故が起きたときに事業が終わります。

要するに、ブリッジ期の開発判断は「全部やる」でも「全部止める」でもなく、証明すべき一つの数字に効くものと、事業が壊れないための最低限だけを残す、という絞り込みです。

どこを止め、どこを残すかの整理を外部の目で確かめたい場合は、インフラ構築・運用やWebシステム開発の観点から状況を伺います。お問い合わせからご相談ください。ご相談・お見積りは無料です。

なお本記事は一般的な情報です。契約の解除、人員に関わる判断、個人情報の保管期間など、法務・労務に関わる事項は、個別の事案について専門家にご確認ください。