メモリー不足で配賦処理が落ちる 配賦計算で処理が落ちる典型的な例（外的要因編）その２

配賦計算で処理が落ちる典型的な例（外的要因編）その１の続き、その２です。

メモリー不足で落ちる

R0011201 / duck75

メモリー不足も、管理会計システムではありがちです。管理会計システムは処理時間がかかる！でも書いた通り、管理会計システムのデータ量は膨大なものになります。例えば、全てのデータをメモリー上に置いて配賦計算をするのはまず無理です。少なく見積もってもギガバイト単位のデータが発生しますから、かなりシビアなメモリー量の見積もりが必要です。

実運用に入ってしまってからメモリー不足が発覚してしまう、という状況に陥る原因はいくつかありますが、注意すべき大きな点は2つあると思います。

１．実データでテストをしていない

これは管理会計システムに限りませんが、実際に業務で発生しているデータでテストするのが重要です。実データのデータ量を想定してテストをしていないと、まず間違いなくメモリー不足に陥ります。管理会計システムでは配賦計算で爆発的にデータが発生しますので、全ての配賦計算をオンメモリーで実行するのは無理です。

２．期末月のデータでテストをしていない

実データでテストすればOKか・・・というと、そうでもありません。「実データ」にも色々あります。よくあるケースは、「テスト時期の直近の1ヶ月のデータでテストしました」というパターン。システムの納品は期末月の3月が多いですから、システムテストするのは1月か2月ですよね。で、その直前の1ヶ月のデータとなると、12月か1月のデータになります。12月か1月のデータでテストをすることが多いわけです。

しかし、それではダメなんです。なぜなら、通常月と期末月では会計データの量が違うから。

期末月（決算月）では、通常月では発生しない会計上の仕訳が大量に発生します。普段使わない勘定科目の仕訳もたくさん出てきます。感覚的には、決算月は通常月の5割増くらいのデータが、管理会計システム上は発生します。なので、通常月のデータでは大丈夫でも、決算月になってしまうと落ちるということが良くあるんです。

しかも、決算月ということは、開発終了＆納品してから1年後にこの関門があるわけです。納品して1年後にこのような問題点が発覚すると、その責任の所在がどこにあるのか、という面倒な問題が出てきます。検収は終わっているから別料金で対応するのか？もしくは、開発側がその負担を被るのか？どちらにしろ、面倒な調整になるのは間違いありません。

以上です。
メモリー不足が発覚すると、じゃあメモリー買い足そうって話になって、ハードウエア購入なのでまた稟議書書かなきゃ・・・など、本当に面倒なことになります。事前の見積もりをキッチリ気合を入れてやりましょう。