ユニットエコノミクスを「平時・悪化・破綻」三シナリオで同時管理する——PandionとBuilder.aiの失敗から逆算する手順

1億2,500万ドルを調達したPandionが物流市場に参入した2021年、運送業のコストはコロナ禍の余波で急騰していた。ユニットエコノミクスの計算式自体は精緻だった。ただ、「平時の市況が続く」という前提のもとに一本しか描かれていなかった。Builder.aiも構造は同じだ。SaaSモデルで積み上げた数字が、調達環境の悪化と契約履行コストの上昇で崩れた。

両社に共通していたのは、シナリオが一本しかなかったことだ。台帳が崩れたとき「今が何フェーズか」を判断する基準がなく、撤退の決断が遅れた。このガイドはその問題への対処法だ。平時・市況悪化・破綻の三レイヤーを同じ台帳で同時管理し、毎月の経営会議で「今どのシナリオにいるか」を数字で確認できる構造を作る手順を解説する。

※この記事に対応するケーススタディ「1億2,500万ドル調達したPandionが『運送業の不況底』にローンチした構造——ユニットエコノミクスが市況連動で崩れる落とし穴」も合わせて読むと、背景が深まります。

なぜ一本シナリオは機能しないのか

スタートアップのユニットエコノミクスが一本シナリオになりやすいのは、調達フェーズの構造による。投資家に見せる数字は「成長ケース」であり、経営会議の台帳もそれが流用されがちだ。平時であれば問題は出ない。ただ、グロスマージンが20〜30%落ちる、次のラウンドが止まる、人件費比率が上昇する——どれかひとつでも重なると、一本シナリオの台帳は現実との乖離を測る機能を失う。

三シナリオ管理の核心は「今どこにいるか」を毎月判定できることだ。閾値を事前に決め、数字が動いたらシナリオが切り替わる設計にする。「悪化フェーズに入った」という判断を感覚ではなく数字で下せれば、意思決定の速度と精度が変わる。

始める前に確認する三つの前提条件

実装前に整っていないといけないものがある。まず、現在のユニットエコノミクスの計算式が明文化されていること。CAC・LTV・グロスマージンの計算ロジックが誰かの頭の中にしかない状態では、シナリオを増やせない。次に、月次の管理会計データが引き出せること。シナリオ判定は月次で行うため、月次P/Lと主要コスト項目が確認できる体制が必要だ。最後に、経営チームと投資家が撤退基準を率直に議論できる関係性にあること。これがないと、台帳だけ作っても破綻シナリオのセクションを更新し続けるインセンティブが生まれない。

三シナリオ台帳を実装する5ステップ

ここが本丸だ。5ステップで進める。

ステップ1：現在の台帳を「平時シナリオ」として固定する
今あるユニットエコノミクスの計算式をそのまま「シナリオA（平時）」と名付ける。変数は単価・原価・利用頻度・解約率の4つが基本だ。Google SheetsかNumbersでシナリオ切替セルとして設計する。A列に「シナリオ」のドロップダウンを置き、B列以降の変数がA列の値に応じて自動で切り替わるIF文を書く。数式が入れ子になりすぎる場合はVLOOKUPテーブルを別シートに切り出すと管理しやすい。作業時間の目安は4〜8時間。

ステップ2：市況悪化シナリオの変数を設定する
シナリオB（悪化）の変数は、業界の実態に合わせて設定する。グロスマージンを20〜30%減、新規顧客獲得コスト（CAC）を30〜50%増、解約率を1.5〜2倍として置くケースが多い。Pandionの場合は燃料費・人件費の急騰が主要なドライバーだった。自社で最も市況に連動しやすい変数を特定し、その変数に感度分析を走らせる。どの変数が1%動くとLTVがどれだけ変わるかを確認しておくと、閾値設定の根拠が作りやすい。

ステップ3：破綻シナリオのシャットダウン計画を文書化する
シナリオC（破綻）は「買収交渉が6ヶ月以内にまとまらなかった場合」を想定する。記載する項目は5つだ。①現在のランウェイと月次バーン、②従業員への法定通知に必要なリードタイム（国・地域によって異なる）、③主要契約の解約条件と違約金、④資産の換金可能性（機材・知財・未収金）、⑤清算手続きに必要な費用の概算。Builder.aiが最後の数ヶ月で混乱したのは、この計画がなく各ステップを順番に調べながら動くことになったからだ。Notionかドキュメントに残し、取締役会で年1回以上レビューする。

ステップ4：閾値と判定ルールを決める
三シナリオを切り替えるトリガーを定義する。「グロスマージンが○%を下回る」「ランウェイが○ヶ月を切る」「次ラウンドのタームシートが○月末までに出ない」のように、定量的な条件で記述する。重要なのは、この閾値を経営チームと投資家の両方が合意していることだ。合意なしに「悪化フェーズに入った」と宣言しても、行動が揃わない。閾値の設定会議は1〜2時間で終わる。その場でドキュメントに記録してサインするか、少なくともメールでログを残す。

ステップ5：月次レビューの議題に組み込む
台帳を作っても使わなければ意味がない。月次の経営会議の冒頭10分に「今月のシナリオ判定」を固定議題として入れる。確認するのは、①主要変数の実績値、②現在のシナリオ位置、③次月の警戒指標の3点だけでいい。データの引き出し元と更新担当者を事前に決めておき、会議に入る前に数字が揃っている状態を作る。これが月次の習慣になると、シナリオ切替の判断を「みんなで気づく」から「数字が示す」に変えられる。

ツールの選び方——メイン・代替・初心者向け

キャッシュフロー管理には、RunwayかPryを使うと三シナリオのランウェイを同時表示できる。どちらも会計ツールとの連携機能があり、実績値の自動取込ができる点が手作業より安全だ。費用は月数万円の範囲。初期費用をかけたくない場合はGoogle Sheetsで同等の機能を作れる。ただし手動更新の工数と入力ミスのリスクは受け入れる必要がある。

マクロ監視は、自社の事業に直接影響するセクター指数を1〜2つ選んで定点観測するだけで十分だ。FREDや日銀統計は無料で使える。重要なのは「どの指標が悪化したら悪化シナリオに入るか」を事前に決めることであり、指標の数を増やすことではない。

撤退基準の文書管理はNotionが使いやすい。閾値・判定ルール・シャットダウン計画を一箇所に集約して、権限のある人間全員が参照できる状態にしておく。ファイルサーバーに置かれた更新日不明のExcelより、ずっとマシだ。

向いている組織・向いていない組織

このフレームワークが機能するのは、ユニットエコノミクスの計算式が既に存在し、月次で実績を追える体制がある組織だ。SaaSや物流など、変数が数えられる事業モデルに特に向いている。経営チームと主要投資家が撤退基準について率直に話せる関係性も必要条件だ。

向いていないのは、まだユニットエコノミクス自体を定義できていないアーリーステージだ。PMFを探している段階では、変数設定よりも顧客と向き合うことに時間を使ったほうがいい。意思決定者が一人だけで取締役会への説明責任がほぼない組織でも、このフレームワークのメリットは薄い。

事業のコアコストがマクロに連動していない安定したニッチ市場の企業も、三シナリオ管理の優先度は低い。資本効率が高く調達に依存しない状態であれば、シンプルな管理で十分だ。

三シナリオ管理が本当に役立つのは「今が平時かどうか自信を持って言えない」と感じる瞬間のためだ。PandionもBuilder.aiも、崩れ始めたことに気づいたのが遅かった。台帳があれば防げたかどうかはわからないが、少なくとも「今月どのシナリオか」という問いに毎月答えられる体制は、判断を数週間は早めてくれる。

AI編集部コメント