売上モデル（Revenue Build）の作り方：ドライバー分解で説得力ある予測を組む

財務モデルで最も重要な行はどこかと聞かれたら、迷わず売上と答えます。売上原価や販管費の多くは売上に連動して動き、利益もキャッシュフローも運転資本も、突き詰めれば売上から派生するため、売上予測の質がモデル全体の質を決めるからです。それにもかかわらず、「売上＝前年×成長率」の一本線で済ませてしまうモデルが少なくありません。

本記事では、売上をビジネスの構造に沿ったドライバー（売上を動かす要因）に分解して予測するRevenue Build（レベニュービルド、売上の積み上げモデル）の考え方と作り方を解説します。P×Qの原則から、業種別の分解パターン、SaaS企業の数値例と感度分析、Excelでの実装ポイント、市場規模との整合性チェックまで、実務で使える形でまとめました。

Revenue Buildとは：P×Qの原則

Revenue Buildの基本原則は、売上を価格（Price）と数量（Quantity）に分解することです。売上＝P×Q。この単純な式が出発点であり、業種ごとにPとQの中身を具体化していくのがドライバー分解です。小売であれば「何店舗で、1店舗あたりいくら売るか」、SaaSであれば「何社の顧客に、1社あたりいくら課金するか」。事業によってPとQの顔ぶれは変わりますが、構造は常にこの掛け算に行き着きます。

なぜ分解するのか。理由は3つあります。

• 予測の根拠が説明可能になる。「成長率5%」には根拠を問えませんが、「店舗を年10店出店し、既存店売上は2%成長」という前提なら、経営計画や過去実績と突き合わせて検証できます。
• 感度分析が意味を持つ。動かせる変数が事業のレバーそのものになるため、「新規出店を絞ったら」「解約率が悪化したら」という問いに、モデルが直接答えられるようになります。
• デューデリジェンス（買収監査）や投資委員会での質問に耐えられる。売上の前提を経営陣が使うKPI（重要業績評価指標）と同じ言葉で説明できることは、モデルの説得力に直結します。

トップダウンとボトムアップ：2つのアプローチ

売上予測のアプローチには、市場全体から降りてくるトップダウンと、ドライバーを積み上げるボトムアップの2つがあります。トップダウンは「市場規模×自社シェア」で売上を求める方法で、TAM（Total Addressable Market：獲得可能な市場全体の規模）に目標シェアを掛けるスタートアップのピッチ資料が典型です。ボトムアップは本記事のRevenue Buildそのもので、店舗数や顧客数といった自社で管理できる変数から積み上げます。

実務の主役はボトムアップです。トップダウンだけの予測は「シェア1%取れれば」という願望の域を出ないためです。ただしトップダウンは検算として不可欠で、ボトムアップの積み上げ結果を市場規模と比べ、暗黙のシェアが非現実的になっていないかを確認します。両者は対立するものではなく、片方で組んでもう片方で検証する関係と覚えてください。

業種別の代表的な分解パターン

実務でよく使う分解の型を業種別に整理します。対象会社の決算説明資料のKPIページを見ると、その業界の標準的なドライバーが何かが分かります。

いくつか補足します。小売・外食で既存店と新店を分けるのは、成長の質が異なるからです。既存店成長は事業の地力を示す一方、新店による成長は出店投資を伴い、開店から数年かけて売上が立ち上がるランプアップ（立ち上がり曲線）の考慮も必要になります。新店を既存店と混ぜてしまうと、「投資で買った成長」と「オーガニックな成長」の区別がつかなくなります。

SaaS・サブスクリプションは、売上が毎期リセットされるフロー型ではなく、契約が積み上がるストック型です。したがって顧客数を「期首＋新規獲得−解約」でつなぐロールフォワード（残高の繰り越し計算）が分解の中心になります。ホテルの「客室数×稼働率×ADR」は、稼働率とADRを掛けたRevPAR（販売可能客室1室あたり収益）という業界標準KPIそのものですし、ECプラットフォームのGMV（流通総額）×テイクレート（手数料率）も、開示資料で必ず語られる組み合わせです。モデルのドライバーを業界標準のKPIに揃えておくと、実績データの入手も、関係者への説明も格段に楽になります。

分解の深さをどう決めるか

ドライバー分解は細かければ良いというものではありません。深さを決める基準は3つです。

第一に、データの入手可能性。予測はできても実績が取れないドライバーは検証不能になり、かえってモデルの信頼性を下げます。月次の稼働率データが取れないのに時間帯別の稼働率を前提に置いても、誰もその数字を検証できません。

第二に、予測可能性。細分化しすぎると個々のドライバーの予測が当てずっぽうになり、精緻に見えて実は砂上の楼閣というモデルになります。SKU（品目）別に売上を積み上げても、個々のSKUの予測精度が低ければ、合計の精度は上がりません。

第三に、重要性。売上の8割を占めるセグメントは丁寧に、1割のセグメントは簡便に、とメリハリをつけるのが実務の作法です。全セグメントを同じ深さで作り込むのは、工数の面でもモデルの保守性の面でも得策ではありません。

M&Aの実務では、「経営陣が事業を管理しているKPIと同じ粒度で分解する」のが一つの目安です。経営陣が店舗数と既存店成長で事業を見ているなら、モデルも同じ構造にする。こうしておくと、マネジメントインタビューで聞いた話をそのまま前提に落とし込めますし、経営陣に前提の妥当性を確認するときも話が早く進みます。

数値例：SaaS企業のRevenue Build

SaaS企業を例に、顧客数ロールフォワード型のRevenue Buildを組んでみます。前提は、期首顧客数1,000社、新規獲得が年300社、解約率（チャーン）が年10%、ARPU（Average Revenue Per User：顧客1社あたり平均収益）が年120万円で毎年2%上昇、とします。

ポイントは2つあります。第一に、顧客数を「期首＋新規−解約」のロールフォワードでつないでいること。2年目の期首顧客数1,200社は1年目の期末顧客数をそのまま参照しており、この接続によって各年の予測が一本の連続した計算になります。第二に、売上を期末ではなく期中平均の顧客数×ARPUで計算していること。顧客は年間を通じて徐々に増減するため、期末値で計算すると売上を過大評価してしまいます。ここでは簡便に（期首＋期末）÷2を使っています。

感度分析への展開

この構造にしておくと、感度分析が事業のレバーに直結した形で行えます。ベースケースの3年目売上18.2億円に対して、主要ドライバーを動かした結果は次のとおりです。

新規獲得を年50社動かすと約1.4億円、解約率を2ポイント動かすと約0.7億円のインパクト。どのレバーが売上に効くのかを同じ土俵で比較でき、施策の優先順位の議論にそのまま使えます。「売上＝前年×成長率」のモデルでは、この議論はそもそも成立しません。なお実際のSaaSモデルでは、既存顧客のアップセルを反映するNRR（Net Revenue Retention：既存顧客からの売上維持率）を組み込み、新規と既存を分けて予測する形に拡張していきます。

ExcelでのRevenue Build実装：3つのポイント

第一に、前提（ドライバー）と計算の分離。新規獲得社数、解約率、ARPU成長率といった前提は、計算式の中に直接数値を埋め込む（ハードコードする）のではなく、前提セクションに独立したセルとして置き、青字などの色分けで入力セルであることを明示します。感度分析で動かすのはこのセルだけ、という状態を作ることが、モデルの操作性と検証可能性の土台になります。色分けの実務ルールは財務モデルの色分けルールの記事で詳しく解説しています。

第二に、ロールフォワードの行構成の統一。「期首残高／増加／減少／期末残高」の4行セットを縦に並べ、期首は必ず前期の期末セルを参照します。この型は顧客数だけでなく、固定資産や有利子負債など、財務モデルのあらゆる残高計算に共通する基本形です。また、同じ行の数式はすべての年で同一にして、右方向にコピーできる状態を保つのが財務モデリングの基本作法です。

第三に、チェック行の常設。期末顧客数が「期首＋新規−解約」と一致しているかの検算行や、予測売上を市場規模で割った暗黙シェアの表示行をモデル内に置いておくと、前提を動かすたびに整合性を自動で確認できます。

実務での注意点：ドライバーの整合性チェック

Revenue Buildで最も怖いのは、個々のドライバーはもっともらしいのに、掛け合わせた結果が非現実的になっているケースです。チェックすべきポイントは3つあります。

第一に、予測最終年の売上を市場規模と比べたときの暗黙のシェア。たとえば市場規模1,000億円・年3%成長の市場で5年後に売上150億円を計画する場合、5年後の市場規模は約1,160億円ですから、暗黙のシェアは約13%です。現在のシェアが5%なら、5年でシェアを2.6倍にする根拠——営業体制の拡充、競合の撤退、製品の優位性——を具体的に説明できなければなりません。

第二に、過去実績との連続性。過去3年の実績を予測と同じドライバーに分解し、予測期間のドライバーがそこから不連続にジャンプしていないかを確認します。過去2年の新規獲得が年150社だった会社が、来期から突然300社獲得する計画なら、その裏付け（営業人員の倍増計画など）が必要です。

第三に、費用・投資との連動。売上ドライバーは費用やCapex（設備投資）のドライバーでもあります。店舗数が増えれば人件費・賃料・出店投資が増え、SaaSの新規獲得には営業・マーケティング費用がかかります。売上だけが伸びて費用が付いてこないモデルは、利益率が年々改善するホッケースティック型の計画になりがちで、レビューで真っ先に疑われるポイントです。

まとめ：売上の一行に事業の構造を宿す

Revenue Buildは、売上という一行に事業の構造を写し取る作業です。P×Qの原則から始めて、業種の標準的なドライバーに分解し、経営が使うKPIと同じ粒度に揃える。Excelでは前提の分離とロールフォワードの型で実装し、市場規模・過去実績・費用との整合で検証する。この流れを押さえれば、説明可能で感度分析に耐える売上予測が作れます。

売上予測は3表モデル（オペレーティングモデル）の起点であり、DCF法をはじめとするあらゆるバリュエーションの土台です。当サイトではDCFモデルをゼロから構築するチュートリアルを公開しており、練習版のExcelファイルは無料でダウンロードできます。Revenue Buildを実際に手を動かして組みたい方は、ぜひ練習版から始めてみてください。