この記事で分かること

  • FA・PEファンド・レンダー・法的手続きなど、立場によって事業計画の精査の目的と着眼点がどう変わるか
  • 過去の予実達成率の検証、主要前提のベンチマーク比較、市場規模との整合性確認という、精査の具体的な手順
  • マネジメントケースをFAケース・バンクケースへ調整するプロセスと、ホッケースティック計画に潜む「盛り」の見抜き方
  • 精査結果をDCFの前提修正・感応度分析としてバリュエーションへ反映し、ICメモで報告する型

結論:事業計画の「精査」とは何か、本記事が扱う範囲

事業計画(ビジネスプラン)は、投資判断・融資審査・企業価値評価のいずれにおいても出発点になります。しかし、対象企業が提示する事業計画(マネジメントケース)を額面通りバリュエーションへ投入することはできません。経営陣は基本的に自社の将来に楽観的であり、資金調達や投資獲得という目的意識が計画数値に影響することも珍しくないためです。事業計画の精査(Business Plan Review)とは、この提示された計画の達成可能性を検証し、投資判断・与信判断・企業価値評価に耐えうる水準まで前提を調整する一連の技術を指します。

本記事は、他者が作成した事業計画を受け取った側が検証する視点に一貫して焦点を当てます。隣接領域との役割分担は次の通りです。事業計画を戦略コンサルの言葉からファイナンスの言葉へ翻訳する視点は事業計画をファイナンスの言葉に翻訳する、計画の「作り方」そのもの(作成側の技術)は中期経営計画の作り方で扱っています。また、精査によって前提を調整した後、さらに踏み込んで悲観シナリオを設計する技術はダウンサイドケースの設計が専門です。本記事はその手前の工程、すなわち「提示された計画のどこを、どう疑い、どう検証するか」に的を絞ります。

誰が、なぜ事業計画を精査するのか

事業計画の精査は、場面によって目的も重視するポイントも異なります。同じ計画書を見ても、FAとレンダーでは着眼点がまったく違うことを理解しておくと、精査の設計がぶれません。

主体主な場面精査の主目的特に重視する観点
FA(財務アドバイザー)M&Aのバイサイド/セルサイドDD買い手・売り手双方が納得できる計画の妥当性説明正常収益力、シナジー前提の切り分け
PEファンド投資審査・IC提出前投資仮説の裏付けとダウンサイド耐性の把握エグジット時点での企業価値、レバレッジ耐性
レンダー(金融機関)融資審査・コベナンツ設計元利金返済に必要なキャッシュフローが確保できるか保守的なダウンサイド、資金繰りの余裕度
法的手続き関連私的整理・株式価値評価訴訟等第三者専門家による客観的な妥当性の証明恣意性の排除、手続き的な公正性

PEファンドの投資審査では、精査結果は最終的に投資仮説(Investment Thesis)の裏付けとして使われます。日本では、私的整理などの準則型手続きにおいても、第三者専門家が経営改善計画事業再生計画の妥当性を検証する仕組みが制度化されています(中小企業活性化協議会や事業再生ADR等)。立場によって「どこまで保守化するか」の程度は変わりますが、検証の手順そのものは共通しています。以下では、その共通手順を順に見ていきます。

精査の出発点:過去の予実達成率を検証する

最初に確認すべきは、将来の計画そのものではなく過去の計画がどれだけ実績と一致していたかです。過去3〜5期分の事業計画(前年に立てた翌期計画)と、実際の決算数値を並べ、売上高・EBITDA・主要KPIごとに達成率を算出します。この工程は予測精度(Forecast Accuracy)の検証そのものであり、経営陣の計画策定能力と楽観バイアスの強さを定量的に把握する唯一の手段です。

達成率が期を追うごとに低下している、あるいは常に一定率で未達が続いているという傾向が見つかれば、それは経営陣の見積もり能力そのものに構造的な問題があることを示唆します。逆に、外部環境の急変(一過性の要因)による未達であれば、その要因を切り分けた上で評価する必要があります。単年度の達成率だけでなく、複数年のトレンドを見ることが重要です。

予実トラックレコードの検証イメージ(仮設例) 以下は説明用の仮設例です。単位:億円 0 15 10 Y1 計画10.0 達成率 95% Y2 計画13.0 達成率 90% Y3 計画17.0 達成率 80% 計画 実績 達成率が年々低下
図:達成率が3期連続で低下している場合、翌期の計画をそのまま採用するのは危険です。低下トレンドの要因分析が精査の起点になります(数値は説明用の仮設例)。

主要前提(成長率・マージン・回転日数・Capex)の跳ねを見る

過去のトレンドから明らかに乖離する「跳ね」がある前提は、精査で最も優先度の高い検証対象です。具体的には次のような項目を確認します。

  • 成長率:直近3〜5期の年平均成長率のレンジに対し、計画期間の成長率が明らかに高い場合、その根拠(新製品・新規顧客・値上げ等)が具体的に特定できるか。
  • マージン(粗利率・EBITDAマージン):過去の水準から数ポイント跳ね上がる計画になっていないか。コスト削減が根拠なら、削減項目と金額の内訳が示されているか。
  • 運転資本の回転日数売上債権回転日数棚卸資産回転日数仕入債務回転日数):急激な短縮は現実的な業務改善の裏付けが必要。単なる「努力目標」になっていないか。
  • Capex(設備投資):売上成長率に対してCapexの伸びが不自然に低い場合、将来の増産能力や更新投資が過小に見積もられている可能性がある。

実務上のコツは、各前提を単独で見るのではなく、過去の変動幅(レンジ)を基準線として引き、計画がそのレンジの外に出ている箇所を機械的に洗い出すことです。レンジの外に出ていること自体が悪いわけではありませんが、その場合は必ず「なぜ過去と違うのか」を裏付ける具体的な根拠(契約書、パイプライン、意思決定済みの投資計画等)を要求します。

以下は説明用の仮設例です。過去3期のEBITDAマージンが18%→19%→18%とほぼ横ばいで推移してきた企業が、計画初年度から24%へ一気に引き上げるケースを考えます。過去のレンジ(18〜19%)に対し、計画は5ポイント外側に出ており、これは「跳ね」として最優先で確認すべき論点です。内訳を分解した結果、その大半が原価率の改善(外注費の内製化)に依存しており、内製化に必要な設備投資や人員計画が事業計画の投資項目に反映されていない、という不整合が見つかることがあります。このように、跳ねの検出は前提単体だけでなく、次章のKPIツリーによる整合性チェックとセットで行って初めて実務上の意味を持ちます。

市場規模・シェアとの整合性を確認する

個社の積み上げだけを見ていると気づきにくい歪みが、市場規模・シェアとの突き合わせで発覚することがあります。計画期間の売上高を、想定される市場全体の規模(TAM/SAM)で割り戻し、計画終了時点で対象企業が獲得することになるマーケットシェアを逆算します。

このとき、業界の平均成長率を上回るシェア拡大を計画に織り込んでいる場合は、その根拠(競合の撤退、規制変化、技術的優位性等)が具体的かどうかを確認する必要があります。市場全体の成長率がおおむね一定なのに、自社シェアだけが計画期間中に大きく拡大するという前提は、多くの場合、トップダウンの目標値(「シェア30%を目指す」)が先にあり、ボトムアップの積み上げが後付けで作られています。ドライバーツリー(ドライバーツリー・KPIツリー)を使って、トップダウンの目標とボトムアップの積み上げが整合しているかを確認する手法は次章で扱います。

マネジメントケースをFAケース・バンクケースへ調整するプロセス

精査で識別した論点は、最終的にマネジメントケースとスポンサーケースの分離という形で調整に反映します。経営陣が作成した元の計画(マネジメントケース)をそのまま使わず、精査結果を踏まえて段階的に保守化したケースを別途作成するのが実務の標準です。

ケース主な作成主体典型的な調整内容
マネジメントケース対象企業の経営陣調整前の原案。最も楽観的な前提を含みやすい
FAケース(スポンサーケース)FA・買い手・投資家売上ヘアカット、マージンの正常化、投資タイミングの後ろ倒し
バンクケースレンダー最も保守的な前提。コベナンツ設計・返済能力の下限確認が目的

この調整プロセスの技術的な中身はマネジメントケースの検証・調整で詳しく解説していますが、実務で頻出する調整項目は、(1) 新規案件・新規顧客の売上計上時期を保守的に後ろ倒しする、(2) 一過性のコスト削減効果を除いた正常化マージンを使う、(3) 為替・原材料価格などの外部前提を計画時点の楽観的な水準から中立的な水準へ置き換える、の3つです。調整の幅は精査で発見した論点の重さに応じて変わり、機械的に一律のヘアカット率を当てるものではありません。

「検証する側」から「作れる側」へ

ここまでの調整プロセスを実務で回すには、マネジメントケースの構造を分解し、前提を差し替えてFAケース・バンクケースを自分の手で組み立てられる必要があります。事業計画・予算策定・事業計画精査講座では、実際のモデルを使いながら、精査から調整、感応度分析までを一気通貫で扱います。

→ 事業計画・予算策定・事業計画精査講座を見る

KPIツリーで計画の内的整合性を検証する

個々の前提が妥当に見えても、それらを組み合わせたときに計画全体が矛盾していることがあります。これを検出する方法がKPIツリー(ドライバーツリー)による内的整合性チェックです。売上高を「顧客数×客単価」「数量×単価(P×Q)」といった構成要素に分解し、それぞれのドライバーが個別に見て現実的な水準かを確認します。

精査の観点は、大きく4つのレンズに整理できます。売上を構成するP×Q(数量×価格)の前提、それを支えるコスト構造(マージン)の前提、成長を実現するための投資(Capex・運転資本)の前提、そしてそれらを賄う資金(キャッシュ・調達余力)の前提です。この4つを個別にではなく、相互の整合性まで含めて確認することが、単純な数値チェックとの違いになります。

事業計画を検証する4つのレンズ ① 数量×価格(P×Q) 顧客数・客単価・販売数量・ 値上げ幅の前提は現実的か → 過去実績・市場シェアと整合するか ② マージン構造 原価率・販管費率の改善は 具体的な施策に裏付けられているか → 一過性要因を除いた正常水準か ③ 投資(Capex・運転資本) 成長を支える投資が 売上計画に対して十分な規模か → 回転日数の改善は現実的か ④ 資金(キャッシュ・調達) 投資と運転資本の拡大を 賄うキャッシュ・調達余力はあるか → コベナンツ・資金繰りは持続可能か
図:4つのレンズは独立ではなく相互に連動します。①の売上成長を実現するには③の投資が必要で、③の投資を賄うには④の資金が必要、という連鎖が計画内で閉じているかを確認します。

楽観バイアスの検出:ホッケースティック計画の見抜き方

精査の実務で最も頻繁に遭遇するのが、直近期まで横ばいだった成長率が、計画期間の後半から急激に立ち上がるホッケースティック型予測です。ホッケースティック自体は必ずしも不合理ではありません(新製品の立ち上がりや規制変化など、実際に急成長の転換点が存在する事業もあります)。問題は、その転換点を裏付ける具体的な根拠がなく、単に「計画年数の後半だから伸びる」という前提だけで作られているケースです。

典型的な「盛り」のパターンには次のようなものがあります。

  • 売上成長率がEBITDAマージンの改善と同時に、かつ両方とも過去実績の上限を超えて計画されている(コストが変わらないまま売上だけ伸びる想定は、固定費レバレッジの効果が現実的な範囲を超えていないか要確認)。
  • 新規事業・新規拠点の立ち上がりが、既存事業と同じ収益性で即座に達成される前提になっている(立ち上げ期の赤字・投資回収期間が考慮されていない)。
  • 一過性の特別利益・補助金・在庫評価差益などを含んだ収益を、翌期以降も継続する前提で伸ばしている(正常収益力への調整が行われていない)。
  • 解約率(チャーン)や不採算取引先の離脱が計画に織り込まれておらず、既存顧客の売上が期間を通じて100%継続する前提になっている。

これらのパターンを見つけたら、「なぜ後半に急伸するのか」を1行で説明できるかを経営陣に問います。説明できない、あるいは説明が抽象的(「営業を強化する」等)にとどまる場合は、その部分の前提を保守化する強い根拠になります。

精査結果をバリュエーションにどう反映するか(DCF前提修正・感応度)

精査で洗い出した論点は、最終的にDCF等のバリュエーションモデルへ機械的に反映します。反映の流れは次の通りです。

  1. 前提の差し替え:s3〜s8で識別した過大な成長率・マージン・回転日数改善などを、精査後の水準(FAケース)に置き換えてフリーキャッシュフローを再計算する。
  2. 正常収益力ベースへの調整:一過性項目を除いた正常収益力をベースにEBITDA・EBITを再定義し、バリュエーションの起点とする。
  3. 感応度分析:精査で最もリスクが高いと判断した前提(例:後半年度の成長率、マージン改善幅)を軸に、企業価値がどの範囲で動くかを可視化する。1つの前提を微修正しただけで企業価値が大きく振れる場合、その前提は交渉・追加検証の優先度が高い。
  4. 割引率への反映:計画の達成可能性そのものに構造的な不確実性がある場合、フリーキャッシュフローの調整だけでなく、割引率(WACC)にリスクプレミアムを上乗せする、あるいは複数シナリオの期待値で評価するという選択肢も検討する。ただし前提の保守化と割引率の引き上げを二重に行うと過度に保守的な評価になるため、どちらか一方を主に用いるのが一般的です。

なお、市場で観測される株価やディールの実勢マルチプルから逆算して、市場がどのような成長率・マージン前提を織り込んでいるかを確認する手法(Reverse DCF)は、精査で得た前提と市場の期待値を突き合わせる補助線として有用です。詳細はReverse DCF入門を参照してください。

反映結果を報告する際は、企業価値(Enterprise Value)株式価値(Equity Value)のどちらの水準で調整幅を語っているのかを常に明示します。精査によるフリーキャッシュフローの調整はまず企業価値に効きますが、レンダー側の関心事である返済能力・コベナンツ耐性は、そこから有利子負債・現金を差し引いた株式価値やキャッシュフロー創出力の水準で判断されるため、両者を混同した報告は誤解を招きます。

精査報告の型(ICメモ・デューデリレポート)

精査結果は、最終的に投資委員会や与信審査会向けの文書にまとめます。投資委員会メモ(ICメモ)における事業計画精査パートの標準的な構成は次の通りです。

  • 予実トラックレコードの要約:過去数期の達成率とそのトレンド
  • 主要前提のベンチマーク結果:成長率・マージン・回転日数・市場シェアが過去実績・業界水準からどの程度乖離しているか
  • 識別した論点(レッドフラグ):具体的にどの前提が、なぜ問題かを1論点1行で列挙
  • 調整後ケースの比較表:マネジメントケース/FAケース/バンクケースの主要数値(売上・EBITDA・企業価値)の並列比較
  • バリュエーションへの影響と感応度:調整によって企業価値がどの程度変動するか、最もセンシティブな前提は何か
  • 推奨事項:追加デューデリジェンスが必要な論点、コベナンツ・アーンアウト等の契約条件への反映案

この型を一貫して使うことで、異なる案件・異なる担当者の間でも精査の質を比較可能にし、後から見返したときに「何を確認し、何を確認しなかったか」を追跡できるようにします。

よくある質問(FAQ)

Q. 事業計画の精査と、財務デューデリジェンスはどう違いますか。
A. 財務デューデリジェンスは主に過去の実績(決算・会計処理・簿外債務等)の正確性を検証する作業です。事業計画の精査は、その延長線上で将来の計画の達成可能性を検証する作業であり、対象範囲が異なります。実務上は同じチームが連続して実施することが多く、財務DDで発見した過去の異常値が、事業計画の前提検証にそのまま活きることもあります。

Q. マネジメントケースをそのままバリュエーションに使ってはいけないのですか。
A. 禁止されているわけではありませんが、多くの実務では精査後の調整ケース(FAケース・バンクケース)を主軸に使い、マネジメントケースは参考値・上振れシナリオとして併記するのが一般的です。マネジメントケースのみでバリュエーションを行うと、経営陣の楽観バイアスがそのまま企業価値評価に転嫁されるリスクがあります。

Q. 過去実績が乏しいスタートアップの場合、どう精査すればよいですか。
A. 予実トラックレコードが使えない、または期間が短い場合は、類似企業・同業界の成長曲線をベンチマークとして代用し、KPIツリーによる前提の内的整合性チェックの比重を高めます。特にユニットエコノミクス(顧客獲得コストとLTVの関係等)の妥当性検証が中心になります。また、直近数か月分の月次実績(MRR等)は短期間でも入手できることが多いため、年次の予実比較ができない代わりに、直近の月次トレンドと計画の初年度前提がどの程度整合しているかを確認するだけでも、有効な検証になります。

Q. 事業計画の精査には、どの程度の期間・資料が必要ですか。
A. 案件規模やデータの入手状況によって幅がありますが、過去3〜5期分の決算・月次試算表・KPI実績データが揃っていれば、予実検証からKPIツリーによる整合性チェックまでを1〜2週間程度で一巡させるのが実務上の目安です。経営陣へのヒアリングが複数回必要になる場合や、セグメント別の内訳データが未整備で個別に集計を依頼する場合は、さらに時間を要します。DDの一環として実施する際は、財務DD・事業DDのスケジュールと並走させ、他チームの発見事項を都度取り込めるようにしておくと手戻りが減ります。

まとめ

事業計画の精査は、経営陣が作成した計画を疑うことそのものが目的ではなく、投資判断・与信判断・企業価値評価に耐えうる水準まで前提の解像度を高めるための技術です。過去の予実達成率、主要前提のベンチマーク、市場規模との整合性という3つの切り口で計画を分解し、マネジメントケースからFAケース・バンクケースへ段階的に調整した上で、その結果をDCF等のバリュエーションモデルへ機械的に反映する。この一連の流れを型として持っておくことで、案件ごとに精査の質がぶれることを防げます。

精査から調整、バリュエーション反映までを一気通貫で実践する

本記事で扱った手順は、実際のモデルを触りながらでないと定着しません。事業計画・予算策定・事業計画精査講座では、事業計画の作成側の視点と精査側の視点の両方から、前提設計・調整プロセス・バリュエーションへの反映までを実践形式で扱います。

→ 事業計画・予算策定・事業計画精査講座を見る

出典・参考(2026年8月16日確認)

※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための仮設例です。