管理会計システムは処理時間がかかる！

管理会計システムに於いて、システム構築の最初に絶対にやっておくべきことがあります。
必要な処理時間の目途を付けておくことです。

管理会計システムのデータは莫大な大きさになります。

例として、サイゼリヤの管理会計システムを考えてみましょう。
※もちろん、私は中の人ではないので全て妄想です。

管理会計システムでは、各データの組み合わせのレコードを大量に作ることになります。

サイゼリヤは、店舗数が約800店舗。
これを収支管理単位にすると仮定しましょう。

勘定科目数は、中の人でないとわからないことですが、普通ならまあだいたい200個という感じでしょうか。
※公表されている貸借対照表（B/S）や損益計算書（P/L）の勘定科目数を、
　実際に経理の現場で使っている勘定科目数だと思ってはいけません。
　公表される財務諸表の勘定科目は、一般に、かなり集約されて表示されています。

そして、それぞれの勘定科目を「変動費」と「固定費」に分けて把握する必要があります。

更に、組織。
出費や売上が、どの組織として生まれたものかを把握する必要があります。
組織体系も、サイゼリヤのホームページではわからなかったのですが、管理会計として扱う組織数は10個と仮定しましょう。

そうすると。
管理会計としては、全ての単位の組み合わせのデータを作る必要がありますから、

800（店舗） * 200（勘定科目） * 2（変動費/固定費） * 10（組織） = 3,200,000

となります。
おそらくこのメッシュのデータを少なくとも毎月ごとに必要になると思いますので、
320万レコードが毎月発生する事になります。

そして、1レコードが500バイトと仮定すると。

500Byte * 320万レコード = 1.49GB

つまり、一ヶ月あたり約1.5GBのデータが、少なくとも発生するという事です。
結構でかいでしょ？

で、この1.5GBのデータを作成するために、様々な配賦計算をしたりします。
配賦計算では全てのレコードを網羅して行う計算が多いため、この1.5GBを何十回も走査するわけです。

というわけで、管理会計システムの配賦計算は、すごく時間がかかるのが一般的です。

実際、中小企業御用達の会計ソフト「勘定奉行」でも、配賦計算の処理時間の目安を聞いたところ

「まあ、だいたい1時間くらい見て頂いた方がいいですね～」

という答えが返ってきました。
※もちろん、データの整備状況によるのでしょうが。

ということで、管理会計システムは、バッチ処理の時間がすごくかかるのが普通です。
なので、処理時間を短縮するためのパフォーマンスチューニングが重要になります。

具体的な対策としては、

１．DB上のインデックスの適切な付与
２．HDDのストライピング
３．SSDの導入
４．極力、処理をメモリ上で済ます
５．帳票毎に、帳票出力専用の集計テーブルを作成

のような対策が考えられます。

１．DB上のインデックスの適切な付与

これは、仕事ができるSEさんなら「やって当然」という認識でしょうが、
巷のシステムには、
「よくわかんないから、各カラム単独のインデックスを全てのカラムに付けました」
とか、
「めんどくせーからプライマリーキーのインデックスしか付けてねーよ」
といったものが実は多いと個人的に感じています。
「やって当然のインデックス最適化を確実にやる」
ということが重要です。

２．HDDのストライピング

ストライピングも重要ですね。
ただ、今時のシステムは「RAID5+ホットスワップ」がスタンダードのような気がするので、
実質的にはあまり選択の余地が無いかもしれません。

３．SSDの導入

これは業務システムにはあまり導入例が無いような気がしますが、
管理会計システムには、SSDの導入を是非検討して頂きたいところです。
「何回も書きこんでると壊れちゃうんでしょ？」ってイメージは私もあるのでなんとなく不安ですが、
例えば、処理結果のテーブルだけはHDDに持たせて、途中のワーク系のテーブルだけSSD内に置くとか。
考えれば導入の仕方は色々考えられると思います。

４．極力、処理をメモリ上で済ます

今はメモリも安くなりましたから、全てメモリ上に読みこんでしまって、ディスクに対する読み書きを極力減らすという事も考えられます。
が、これには注意が必要です。
というのも、メモリ上で全てを済ましてしまうと、運用時に途中計算がわかりにくくなるのです。
もちろん、同じ処理をデバッガーを起動しながらやればわかることはわかるのですが、
何しろ相手は一ヶ月あたり320万ものレコードです。
デバッガーでの調査にも限界があります。

なので、処理の途中経過は、ポイントごとになるべく物理テーブルに落としておくべきです。
そうすると保守性がかなり向上します。

無用なディスクアクセスを減らすのはもちろん良いことですが、
運用者と綿密に打ち合わせて、ポイントを決めて、物理テーブルに落とすようにしましょう。

５．帳票毎に、帳票出力専用の集計テーブルを作成

ここまでは対象データを「作成するため」の処理を念頭に置いて書いてきましたが、
当然、その莫大なデータを対象に帳票出力するわけで、帳票出力にも時間がかかります。
一ヶ月あたり1.5GBですから、例えば通年の帳票を出そうとすると12倍の18GBのデータを、読み込んで、集計等を行って、帳票出力することになります。

帳票出力のボタンを押すたびに、この18GB全てを対象に処理すると、ボタンを押してから帳票が出るのに1時間かかる、なんていう状況も大いにあり得ます。
ですので、帳票の種類の数だけ集計テーブルを作って、帳票出力する際にはその集計テーブルからデータを読み込んで出力する、という作りにすることも検討した方が良いでしょう。
データが冗長化してイヤな感じはしますが、現実解としてはこれを選択せざるを得ない事が多いと思います。

以上です。

なお、ここでは「データは月毎に作成」という仮定を置きましたが、
サイゼリヤのような外食産業の場合、経営者としては日別のデータが欲しいはずです。
また、ここではメニューの概念を完全に無視しましたが、当然、メニュー毎にどのくらい儲かっているか、も知りたいはず。
つまり、メニューも収支管理単位として扱いたいハズです。
メニュー数は、今ざっと数えたところ100個強といったところでした。

なので、上記の「一ヶ月あたり320万レコード、1.5GB」というのはかなり小さく見積もった数字で、
大きく見積もると、これが更に増えて、

320万レコード * 30（日） * 100（メニュー数） = 32億レコード
1.5GB * 30（日） * 100（メニュー数） = 4.5TB

ということで、一カ月当たり、 32億レコード・4.5TB のデータが生成される、という可能性もあります。

さすがにテラバイトの単位になるともうお手上げな感じもするので、何かをあきらめる必要が出てきますね。
「組織毎の数字を見るのはあきらめる」とか、「日別にデータ生成するのは売上高だけにする」とか。

このように、処理時間がボトルネックとなって実現できないことが結構出てきます。
もし管理会計システムの開発案件に携わるなら、プロジェクト開始時点から、この辺の感覚を持っておいた方が良いでしょう。