第3回：管理会計システム構築における考慮点（2）

気が付けば年の瀬です

あっという間に師走になってしまいましたね。個人的にはとにかく忙しい年でした。
弊社は12月が期末ですので、期末対応と年末リリースの案件が並行して進んでいて大わらわです。
私が携わるお客様側の予算編成時期とかぶることが少ない、という点では助かっていますが。

実は、私の担当している部門は、今年立ち上がった組織です。
部門の立ち上げ当初は、昨今の経済・社会状況を見るにつけ、果たして計画に沿った実績を上げることができるか不安だったものですが、おかげさまで良い結果を出すことができました。
日頃管理会計を扱っているせいか、当たり前に会計上でPCDAを自然と考えられるのがちょっぴり強みになったと勝手に考えているのですが、実際のところは「運」に助けられた部分も大きいかもしれないですね…。
驕ることなく精進していかねば、と日々自戒です。

さて、そんな手前味噌はさておき、前回予告の通り、今回は管理会計システムを作るうえで頻出する要件「配賦(はいふ)」に関わる勘所をお伝えしていきたいと思います。

勘所4．配賦のパターンとパフォーマンス

配賦というと、いくつかのパターンがあります。私が手掛けたことがあるシステムの例では大きく分けて二つですね。コストの配賦と、粒度詳細化のための配賦です。
他にも、製造業等では原価計算の時に間接原価を配賦する事などもあるかと思いますが、当コラムでは上記の2点にフォーカスします。

①は、管理部門の経費（いわゆる販管費）を各部署へ人数比や売上比等で割り振るケースです。

どの勘定科目を、どのような条件で割り振るかは企業によって様々でしょうけれども、基本的な算出方法は、

配賦する対象値（配賦元）×配賦率（配賦基準の値を元にした比率）＝配賦結果値

となります。

①、②いずれも、パフォーマンス面で恐ろしい落とし穴が待っている場合がありますのでそれぞれについて書いてみます。

配賦計算の落とし穴…①コストの配賦層

管理会計システムの基本的な要件として、前回述べたように、PDCAサイクルを回すために他システムから連携された実績データと比較する、ということが含まれるので、データウェアハウス（DWH）を含んだ作りになるのが常です。
DWHといえば、その名の通りデータの倉庫ですね。
そしてこのDWHには、予算と対比する実績データをできるだけ細かいレベルで取り込む事が求められる場合があります。
分析時に、より細かいレベルまで追跡できるようにしたい、というニーズがあるからです。
連携される元データ自体の粒度に依存しますが、それこそ伝票レベルでの取込をするケースもあります。

さて、DWHに上記のような細かい粒度でデータを保持することにしたとき、たとえば数千万・数億件の実績データが入ってきたとします。
RDBに取り込むのが常なので、伝票1件＝1レコードとして考えてみましょう。
そのうち、間接部門の経費データに絞ってカウントした場合に、1000万件のレコードがあったとします。これを、5000万件の売上伝票毎に配賦をすることになったとしたらどうでしょうか？

これは極端な例ですが、

1000万件×5000万件＝500兆件

という、莫大なレコードが生成されることになります。
こんな計算を、例えば日次の処理でできるかというと…相当なハイスペックのハードウェアを導入でもしない限りまず不可能です。

また、データボリュームの問題回避の手段として、計算途中の中間レコードを作らず、結果をサマリしてしまう、という手も無くは無いですが、末端のデータ毎に配賦をしようとする限り、計算回数はごまかせないですから、処理として相当の時間がかかることは避けられず、なおかつ途中の計算の経緯を追跡できなくなるので、何がどう配賦されたのか、非常にわかりづらくなります。

このように、あまり細かいレベルでの配賦をしてしまうと、爆発的な計算量が必要になるケースがあり、小手先で回避しようとしても、他の制約が出て来るなど、機能的に問題が生じます。

配賦のニーズを取り込む場合、必須でパフォーマンスの予測を立てないと、大変危険です。
管理会計やBIの分野で長年やってきて、「配賦のニーズを取り込むのに非常に苦労した」という話は私自身の実体験としても何度かありましたし、同業の技術者からも何度も話を聞いたことがあります。
（大袈裟な話ではなく「配賦のニーズあり＝危険」というイメージが刷り込まれている技術者すらいるかもしれません。）

配賦計算の落とし穴…②粒度詳細化の配賦

前段で、DWHを含んだ作りになるということを書きましたが、予算と実績の粒度が異なるケースはよくありますよね。
顧客毎の予算や、伝票毎の予算といった細かい部分まであらかじめ計画に入れるのは至難ですから当然です。

しかし一方で、DWHを構成する場合は、分析のために取り込むデータの粒度をできるだけ合わせるというのがセオリーです。サマリレベルでは対比ができるが、粒度が細かくなると、対比すべき予算が無い、という具合です。

これを補うべく、当初サマリで作成した予算を、実績の構成比で詳細化する方向へ配賦する、といったケースが前述のパターン②に当たり、ここでもやはりデータボリュームや計算量に悩まされるケースが有り得ます。

ある実例では、予実分析を行うため、DWHに予算と実績を取込み、「セグメント」別の予算を立てたい、という業務要件がありました。
予算毎に一意な番号を付加して、関連するセグメントに対して配賦率を設定し、実績が上がった際には予算執行したものとして、この番号で計上して自動配賦する、という方式です。
そして、このとき構築したDWHには、組織を除いて三つ以上のセグメントが存在しました。

この機能を用いて予算を入力する例として、例えば「顧客×商品×地域」といった異なるセグメントについて、一つの予算が関わるセグメント毎の配賦率を入力しておき、後々、実績は連携された際に自動で配賦計算するといった形になります。

このとき、顧客10社、商品10種類、10の地域に影響する予算だったとします。
すると、それぞれ10個ずつの配賦率が設定され、一つのレコードを詳細化するべく配賦計算すると10×10×10で、1000倍に膨れ上がります。

元データが10レコードなら、10×1000で1万レコードにもなってしまう計算です。
これも、かなりパフォーマンスを担保するのに頭を悩ませなければならない案件となりました。

勘所5．配賦は仮想の値

パフォーマンスもそうですが、そもそも伝票レベルで発生した金額、たとえば100円の文具を、プロフィット部門のコストとして分散させたとき、対象となる配賦率のデータがあまりに細かく0.000001パーセントのデータにまで配賦され、0.0001円という仮想の値が出てきたとして、その結果に、どこまでリアリティがあるでしょうか？

配賦結果というのは管理会計上の仮想の値です。
以前、何かの読み物で「ある会社が、配賦を細かくやりすぎて、結局実態がよくわからなくなり、その会社は結局無くなってしまった」などという逸話を目にしたことがあります。

やりすぎると実態と離れて行く部分も出て来ることを念頭におき、計上のルール含めて無理のない範囲に留めないと、システムに落とし込む事もできなくなってしまう、ということを考慮して、要件や設計を纏めて行くことをお勧めします。

…と、いうわけで今回は過去にもっとも苦労したポイントのいくつかを書きましたが、皆様の今後のシステム導入・構築において、多少でも参考になれば幸いです。

次回は、管理会計（予算編成）システム関連で用いられるいくつかの製品を取り上げ、特徴を比較してみたいと思います。