【コラム】（財務モデリングの最先端）第12回財務モデルにおける計算モジュールとは

2020.04.10 連載コラム

ナレッジパートナー：川井文哉

第8回のコラムにて、財務モデル内部のシートは項目別の分類ではなく、機能別に分けるべきであると述べた。また、それと同時にシートを、アウトプットシート、計算シート、インプットシートの3つに概念的に分け、アウトプットシートには計算結果、インプットシートには前提条件の一覧を表示し、計算シート内でモデルの計算を行うといった構造的な階層を作る、と説明した。今回は、財務モデルの中でも心臓部である、計算シートのベストプラクティスについて解説をしていきたいと思う。

財務モデルで使用する計算モジュール (Calculation Module) とは

計算モジュールとは、端的に言えば「計算ブロック」のことだ。最新の財務モデルのベストプラクティスとして、計算をモジュール単位、つまりブロック単位で構築し、それらをレゴブロックのように組み合わせて構築する、という手法が用いられる。計算モジュールは計算ブロックの一部ではあるが、いくつか厳密なルールが設けられる。

アウトプットの項目と1対１対応
1行に対して1項目しか入力してはならない
計算は左から右、上から下に行われる
1行内では数式を途中で変更してはならない

まず、計算モジュールの根底にあるものとして、アウトプットの項目と1対1対応するという点だ。例えば、「固定資産」という計算ブロックの中で、固定資産の期末残高や、設備投資金額、減価償却費などが計算され、それらが BS の固定資産期末残高や、CF の設備投資支出、PL の減価償却費にリンクされているとしよう。このような場合、「固定資産」という計算ブロックは計算モジュールではない。計算モジュールはあくまでアウトプット項目と1対1対応している必要があるため、上記の項目をカバーするためには「BS 固定資産残高モジュール」、「PL 減価償却費モジュール」、「CF 設備投資モジュール」の3つが必要だ。例外的に複数のアウトプットを1つのモジュールでまとめる例もないわけではないが、原則はアウトプット項目に1対1対応する必要がある。

次に、モジュール内部の構造として、財務モデリングのルールに厳密に従っている必要がある。1行に1項目の原則や、1行内で数式を途中で変更してはいけない、などのルールが守られていないものは、モジュールとは呼ぶことはできない。モジュールとは「交換可能な構成要素」とも訳されるように、モジュール単位で入れ替えたり、修理したり、使いまわしたりできる必要がある。ルールが守られていないものは、いわばオーダーメイドの特注品となってしまい、レゴブロックのように他のパーツ（モジュール）と組み合わせることができないため、とても使い勝手が悪く、財務モデルの中で使用すべきではない。

モジュールの内部構造

計算モジュールの内部構造について、少し解説をしよう。モジュールの中身は5行 ~ 20行程度の計算量で、3行程度の非常にシンプルになるジュールになることもあれば、20行程度のモジュールになることもある。20行を超えるような計算の場合は、モジュールを2つに分解するという手法が必要になるが、これについては後述をする。

例えば、シンプルな例として、PL の売上に対応する売上モジュールを考えてみよう。売上 = 単価 x 数量という計算になっているとすれば、売上モジュールは以下のような構造となる。

上記の例を少し変更して、売上 = 都市部売上+地方部売上、と2つの地域に分解した上で、それぞれ地域において単価と数量が異なるケースを考えてみよう。このような場合、売上モジュールは以下のような構造となる。

上記の例を見ると、売上モジュールの中に、都市部売上、地方部売上、売上高という3つの小さな計算ブロックができていることにお気づきいただけるだろうか？このように、モジュール内の計算を整理する単位として、サブモジュールというより小さなブロックを用いて計算をすることになる。上記の例のように、1モジュール内にはサブモジュールが3 ~ 4つ程度、またサブモジュールとしては3~4行の項目からなるといった構成が理想的だ。

メインモジュールとファンクションモジュール

先ほど述べた通り、1モジュールの計算量は20行程度が最大となるように構築することが望ましい。しかしながら、非常に複雑な計算をしなければならず、1モジュールの計算量が20行を超えてしまうようなケースにはどうすればよいだろう？例えば、CF の借入金の返済に1対1対応する形で、「借入金返済モジュール」を作成したとしよう。ただし、この借入金には様々なコベナンツや返済条件が細かく設定されており、返済額を計算するだけで30行以上の計算が必要になったとする。このような場合はモジュールを2つに分け、1つをメインモジュール、もう1つをファンクションモジュールとする。例えば、借入金返済の中で、返済可能現預金が複雑であると考えられる場合、「借入金返済モジュール」に加え、「返済可能現預金モジュール」を作る。

上記2つのモジュールでは、まず返済可能現預金モジュールの中で、返済可能現預金が計算される。そして、次に借入金返済モジュールの中で、計算された返済可能現預金を用いて、返済額を計算する、という形となる。つまり、返済可能現預金の計算が、別の計算モジュールとして外出しされている形となる。しかし、上記の場合、「返済可能現預金」は PL、BS、CFのいずれの項目でもなく、直接的に対応するアウトプット項目が存在しない。これはモジュールはアウトプット項目と1対1対応しなければならないというルールに違反するのではないだろうか？

実はモジュールには、アウトプットと1対1対応するメインモジュールと、メインモジュールの計算の一部を独立させたファンクションモジュールの2つが存在する。ほとんどのモジュールはメインモジュールであるが、複数のメインモジュールで同様の計算をする場合や、メインモジュールの計算があまりに複雑になる場合に、メインモジュールに従属させる形でファンクションモジュールを構築する、と覚えておこう。最も代表的なファンクションモジュールとしては、フラグを計算するためのフラグモジュールがある。フラグについては、第10回のコラム「財務モデルにおけるフラグとは」を参照されたい。

東京モデリングアソシエイツ株式会社
マネージングディレクター
川井文哉

*アイキャッチ　Photo by Christian Fregnan on Unsplash