Modelmap 事業内容解説 ~解決策編①~

<Modelmap 事業内容解説 ~解決策編①~>

この記事では、これまで問題編で解説してきた根本的な課題と現状に対して、Modelmapがどのように問題を解決しようとしているか詳しく説明をしていきたいと思います。問題編①、問題編②、解決策編①を合わせて結論だけ短くまとめると以下のような形になります。

① 金融業界、特に M&A 業界では、エクセル職人達が毎回0から数式を頑張って書いている。
② 世界中のエクセル職人は 200 万人以上いると推定され、人件費ベースで毎年 2 兆円以上のコスト！
③ 諸悪の根源はエクセルだ！自由すぎるフォーマットと、見えないデータリンクに振り回されている。
④ 解決策として、エクセルと相互変換が可能な仕組みを持つ計算ツリー（Modelmap）を開発。

<エクセル特殊部隊>

前回の問題編②にて、諸悪の根源はエクセルであり、計算を使いまわすことができないため、世界中のエクセル職人達が、プロジェクトごとに計算式（コード）を毎回使い捨てているとう壮絶な現状を説明しました。

私達は、エクセルの専門部隊ですが、業界の中でもやや特殊な部隊でした。フツウ、エクセル部隊というものは投資銀行内に存在しており、基本的に 0 からエクセルを使って財務モデル（スパゲッティ）を作るシゴトです。しかしながら、私達はコンサルティングファームに所属し、 0 から作るのみだけではなく、他人が作った財務モデルの解読（レビュー）や、再構築（リファクタリング）も行う部隊でした。

「！？」

そうです。これまで問題編にてご紹介してきたような麺が絡まったスパゲティを1本1本紐解いてレビューを行い、計算が間違っていないか、前提値が変更された際にリスクが存在しないか、時間をかけてレポーティングし、計算ミスによる10億円の損失を未然に防いできました。また、財務モデルの計算が間違っている、または設計がイケていないことによる、必要な計算や機能が拡張できない場合は、受領したモデルから新しいモデルを作り直すという特殊な業務を行っていました。いかにエクセル職人が多いとはいえ、このような業務を行っていたのは、業界広しといえど私達がいたチームのみだったと思います。

このような事情から、私達がいたチームでは（普通に働いてたら死んでしまうため）独自の手法を用いて財務モデルに係る業務を行っていました。外部ツールや内部の独自ツールの使用は勿論のこと、それに加えて主に 2 種類のテクニックを用いていました。

①独自のルールに基づき、計算したい項目をモジュール単位で作成
②計算過程の表示に、樹形図（ドライバーツリー）を使用

<①独自のルールに基づき、計算したい項目をモジュール単位で作成>

財務モデリングを行う際にエクセルを使用することの問題点として、エクセルの自由度が高すぎるため、フィーマットがきちんと定義されておらず、エクセル職人達が思い思いに自由なフォーマットでモデルを作成することが大きな問題だと指摘しました。私達のチームでは、厳格に定義されたフォーマットを使用し、計算を行う上でも厳しいルールを設定することで、誰が作成しても完全に統一されたモデルとなるような工夫がなされていました。その中でも、最大の特徴は、計算をモジュール単位で作成するというルールです。そうです。

厳密にフォーマットを決めて、モジュール単位で計算すれば、モジュール単位で計算が交換可能です。

モジュール単位で作成されてさえいれば、プロジェクトごとにモジュールを使いまわせますことができます。メンテナンスや保守もモジュール単位で行うことができ、極めて効率的です。新規のプロジェクトで財務モデルが必要な際には、過去の財務モデルからモジュールをコピー。新しいモデル上でモジュールを組み合わせて、必要に応じて編集し、新しいモデルとして再構築できます。ある意味、20年以上の遅れを経て、やっと財務モデリングという分野にエンジニアリング技法の一部が導入されたとも言えます。

<問題編にてご紹介したフツーの人が作る財務モデル>

<私達のチームが作る財務モデル。青文字のヘッダごとにモジュール単位で計算。>

<②計算過程の表示に、樹形図（ドライバーツリー）を使用>

財務モデルのレビューや再構築に用いられる手法として、計算過程を表示する際に、ドライバーツリーと呼ばれる樹形図を用いて説明をしていました。例えば、下記は固定資産税の計算を示したドライバーツリーの例です。

上記の見方は、左側がアウトプット、右端に位置する黄色部分がインプットとなります。上記の例で言えば、ある該当年度の固定資産税を計算するためには、下記のインプット一覧が必要となります。

a. 固定資産取得価額
b. 前年度取得減価率
c. 前年度以前取得減価率
d. 評価額下落率
e. 固定資産税率
f. 減免率
g. 減免税率適用開始日
h. 減免税率適用終了日

上記のように、固定資産税を樹形図形式に分解することによって、計算の前提および構造、そして何をインプットとして計算されるかというのを明確に定義することが出来ています。私達は、上記のような樹形図をドライバーツリーと呼び、

I. 受領した（スパゲッティ）モデルの構造がどうなっているのか
II. 構築するモデルの構造はどうあるべきか

を議論するためのディスカッション資料として上記のような樹形図を作成・使用していました。特に II のケースでは、上記の樹形図をそのままモデル計算の仕様書として使っていました。

ちなみに、複雑なスパゲッティモデルからどうやってこれを作っていたか？前回の問題編で2回言ったことをもう一度言います。肉眼で、1つ1つセルを追いかけて確認です。肉眼最強ですね。私達たちは、エクセル上でセルの計算を確認しながら、マインドマップのソフトウェアを立ち上げて樹形図を手動生成していました。私達は働いていた当時から、「ん？これ自動生成できんじゃね？」と常々思っていましたが、これを実現できるソフトウェアが内部にも外部にも存在しなかったため、仕方なく手動で行っていました。（ちなみに、私達が居たチームでは未だに同じやり方をしていると聞いています）

樹形図を生成する過程はやや手動であるものの、この手法を補助的に用いることで、エクセル内の見えないリンクやセル内の複雑な計算構造を分かりやすく表すことができています。

<Modelmap の生成>

上記2つのノウハウを駆使して、エクセルの専門家として数千時間を費やした私たちはある点に気づきました。上記でご紹介したドライバーツリーはただの概念図ですが、計算をもっと厳密に定義できるのではないか、つまりエクセルではなく樹形図内で直接計算できるはずだ、という点です。色々と試行錯誤の結果、私達は樹形図上で項目ごとに特定の属性を与え、計算を厳密に定義することに成功しました。コンサルティングチームで使用していたドライバーツリー（概念図）と、計算が定義されたツリー（Modelmap) を見比べてみましょう。