財務モデルの設計図（モデリングプラン）｜組み始める前に決める7つのこと

結論：モデルの質は着手前に半分決まる

財務モデルの完成度は、Excelに最初の数式を打った瞬間からではなく、その前の10〜30分でどれだけ設計を詰めたかでほぼ決まります。この記事は「組み立て方」ではなく「組み始める前に決める判断」に特化した内容です。3表連動モデルを実際に手を動かして作る7ステップの手順は別記事「財務モデリング完全ガイド」で解説しているので、作業手順を探している場合はそちらを参照してください。本記事はその前段、つまり「何を、どの粒度で、どういう構造で作るか」を決める設計図（モデリングプラン）の作り方を扱います。

結論を先に言うと、決めるべきことは7つあります。①モデルの目的と、それが支える意思決定 ②必要なアウトプット ③粒度と期間 ④主要ドライバー ⑤データソース ⑥シート構成 ⑦更新頻度と引き継ぎ、です。この7つを紙かメモ1枚に書き出してからセルに向かうだけで、後戻りの量は大きく減ります。

なぜ設計図が要るのか：手戻りコストの非対称性

設計を飛ばして着手すると、序盤は速く進んでいるように感じます。しかし手戻りのコストは着手からの時間経過とともに指数的に増えます。これは「手戻りコストの非対称性」と呼べる現象で、モデリングに限らず設計作業全般に共通します。

例えば、最初に決めた粒度（年次）が途中で「四半期でも見たい」に変わった場合を考えます。着手直後であれば行の並びを組み替えるだけで済むが、すでに20本のシートが年次の列構成を前提に相互参照している段階で変更すると、参照先をすべて洗い出し、数式を1本ずつ書き直し、検算し直す必要があります。同じ変更でも、タイミングによってコストが数倍から数十倍に膨らみます。これが「後からの構造変更は指数的に高くつく」という意味です。設計図を先に作る目的は、こうした構造変更が発生する確率そのものを下げることにあります。

着手前に決める7つ

以下の7項目は、Excelを開く前にメモ1枚で言語化しておきたい論点です。

① 目的と意思決定——このモデルは何のために作るのでしょうか。買収の意思決定を支えるのか、社内の予算策定なのか、バリュエーションの参考資料なのかで、必要な精度もアウトプットも変わります。「誰が」「いつまでに」「何を判断するために見るのか」を1文で書けるか確認します。

② 必要なアウトプット——最終的に何を見せるのでしょうか。サマリーページ1枚か、感応度分析の表か、グラフか。アウトプットが先に決まれば、そこから逆算して必要な計算だけを組めばよく、不要な精緻化を避けられます。

③ 粒度と期間——月次か四半期か年次か。予測期間は3年か5年か10年か。粒度は途中で細かくする方向の変更は比較的軽いが、粗くする方向（月次→年次）は集計ロジックの作り直しになりやすいです。

④ 主要ドライバー——モデルの結果を動かす変数は何でしょうか。売上であれば数量×単価、コストであれば人員数×一人当たり単価など、KPIとして追うべき変数をあらかじめ列挙します。ドライバーが曖昧なまま作り始めると、後で「この数式は何を動かすためのものか」が分からなくなります。

⑤ データソース——各ドライバーの数値はどこから取るのでしょうか。決算短信、有価証券報告書、社内管理会計データ、業界統計など、出典を先に特定しておきます。データソースが定まらないまま組むと、入力欄に仮置きの数字が残り続けます。

⑥ シート構成——タブをどう分けるのでしょうか。次章で詳述します。

⑦ 更新頻度と引き継ぎ——このモデルは一度作って終わりか、四半期ごとに実績を反映して回し続けるのでしょうか。自分以外の人が更新・引き継ぎする可能性があるかも、シート構成や入力欄の作り方に影響します。

シート構成の定石

設計図の項目⑥にあたるシート構成には、実務でほぼ共通して使われる定石があります。

左から右へ1方向に流す——タブの並びを、情報の流れる方向と一致させます。一般的には「前提（Assumptions）→ 個別スケジュール（負債・設備・運転資本等）→ 3表（PL・BS・CF）→ アウトプット（サマリー・感応度）」の順に左から右へ並べます。ある数式が右のタブから左のタブを参照する構成（逆方向参照）は避けます。参照の方向がタブの並び順と一致していれば、モデルを初めて見る人でも計算の流れを目で追えます。

入力タブの分離——手入力するセルと、数式で計算するセルは別のタブに分けます。少なくとも色分け（入力＝青字、数式＝黒字といった慣例）は徹底します。入力と計算が同じセル範囲に混在すると、どこを変更してよく、どこを変更してはいけないかが一目で分からなくなり、誤入力の温床になります。

タブの粒度——1タブに詰め込みすぎません。1つのタブは1つの役割（例：人件費スケジュールのみ、設備投資スケジュールのみ）に絞ります。タブ数が増えすぎる場合は、色でグループ化するなどナビゲーションを工夫します。

タイムライン設計

期間軸（タイムライン）の設計も着手前に固めておく項目の1つです。

開始月の決め方——モデルの起点を「直近の実績確定月の翌月」に置くのが一般的です。過去実績と将来予測の境目を1列で明確にし、その列以降を数式、それ以前を実績値（ハードコード）とします。

年度と暦年の整理——日本企業は3月期決算（4月始まり）が多く、暦年（1月始まり）と決算年度がずれます。どちらの軸で列を並べるかを最初に決め、途中で混在させません。海外の親会社と比較する場合など、暦年と決算年度の両方が必要になるケースでは、変換用の対応表を別途用意します。

EOMONTHでの月次展開——月次モデルでは、日付セルを1つずつ手入力せず、起点セルからEOMONTH関数で1列ずつ生成すると、月末日のずれ（28日/30日/31日）を自動処理できます。例えば起点セルをA1とすると、翌月の日付は=EOMONTH(A1,1)で求められます。

年次・四半期への切替可能性——最初は年次で十分でも、後で四半期に分解したいという要望は珍しくありません。月次で計算し、四半期・年次はSUMIFやAVERAGEIFで月次列を集計して表示する構造にしておくと、粒度の切り替えに強くなります。逆に最初から年次でしか組んでいないと、四半期化は事実上の作り直しになります。

設計を終えたら、実際に手を動かして3表を組み上げる工程に入ります。具体的な数式の組み方や連動のさせ方は「財務モデリング完全ガイド」で7ステップに分けて解説しているので、あわせて確認してください。より体系的に学びたい場合は大手町プレップの講座でも財務モデリングの実践的なトレーニングを扱っています。

整数設例：簡易な設計メモの実例

実際にどの程度の粒度でメモを書けばよいか、簡易な例を示します。仮に「上場消費財メーカーの5年間PL予測」を作るとします。

この例では、数量1,000千個×単価500円＝売上高500百万円が初年度の起点となり、以降は数量成長率と単価改定率という2つのドライバーだけで5年分の売上を伸ばす設計にする、という具合に、着手前の時点で「何が結果を動かすか」まで言語化しておきます。この1枚があれば、実際にセルへ数式を打つ段階で迷う場面がほとんどなくなります。

ありがちな失敗

目的なき精緻化——目的を決めずに着手すると、「念のため」で不要な明細まで作り込んでしまいます。感応度分析に使わない変数まで細かく分解するのは、意思決定に寄与しない工数です。

双方向の参照——シート構成の定石に反して、右のタブから左のタブへ、左のタブから右のタブへと参照が両方向に走ると、循環参照や計算順序の混乱を招きます。参照は必ず一方向に統一します。

入力と計算の混在——手入力セルと数式セルが同じ範囲に混在していると、他人が手入力すべき箇所を誤って数式ごと上書きしてしまう事故が起きやすいです。入力欄は最初から独立させておきます。

面接での答え方（30秒回答例）

Q：財務モデルを作る前に何を確認しますか。
「まずモデルの目的と、それが支える意思決定を確認します。次に必要なアウトプット、粒度と予測期間、主要ドライバー、データソースを整理し、シート構成を左から右へ1方向に流れるように設計してから着手します。後からの構造変更はコストが指数的に増えるため、着手前の設計に時間をかけることを重視しています。」

よくある質問（FAQ）

Q. 設計図はどのくらいの時間をかけて作ればよいですか。
A. 小規模なモデルであれば10〜30分程度でも十分効果があります。重要なのは時間の長さではなく、7項目を漏れなく言語化することです。

Q. 途中で目的が変わった場合はどうすればよいですか。
A. 目的が変わった時点で7項目を見直し、影響が大きい場合（粒度やシート構成に及ぶ場合）は作り直しを検討します。手戻りコストは時間が経つほど増えるため、変化に気づいた時点で早く判断するほうが結果的に安く済みます。

まとめ

財務モデルの質は、セルに数式を打ち始める前の設計判断でほぼ決まります。目的と意思決定、必要なアウトプット、粒度と期間、主要ドライバー、データソース、シート構成、更新頻度と引き継ぎ——この7つを着手前にメモ1枚で言語化するだけで、後からの手戻りを大きく減らせます。特にシート構成は左から右へ1方向に流し、入力と計算を分離するという定石を守るだけでも、モデルの保守性は大きく変わります。

出典・参考（2026-08-01確認）

• Microsoft公式サポート「EOMONTH 関数」（Excel関数リファレンス） https://support.microsoft.com/en-us/office/eomonth-function-7314ffa1-2bc9-4005-9d66-f49db127d628

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