第5回：管理会計とExcel/管理会計システムの運用

管理会計システムの勘所

2013.03.01

予算編成時期です

さて今年も予算編成の時期がやってきました。会計期間が異なる企業もあるかと思いますが、日本の多くの企業で、ご担当の方々はてんてこ舞いなのではないでしょうか。
これまでに我々が携わったシステムが唸りを上げて回らなければならない季節でもあるので、私も運用をご支援させていただいているあちこちのお客様先にちょこちょこお邪魔しているところです。

また、システム屋という商売上、お客様にいかに予算をとっていただくかを考えて諸々の提案活動を画策していかなければならないうえに、当年度開始時点の予算で確保した情報投資予算を使い切りたいというお客様からのご依頼も多くいただく時期なので、まさに繁忙期です。
弊社内でも忙しい自慢が色々聞けるので、何か活気が出てきて面白いですね。

個人的には、アベノミクスのおかげで景況感も悪くない状況に思えますので、はりきって情報化投資予算の動向に注目したいところです！（死活問題なので！）

管理会計とExcel

さて今回は、これまでの内容が少々お堅い感じで書いていた気がしますので、少々くずしつつ、予算編成の現場で非常にというか異常にというか、イヤもはや使われ過ぎていると言って過言ではない、我らが「Excel様」について、管理会計と絡めて書いてみたいと思います。
（あくまで一個人の視点ですのでご了承を！）

Excelといえば表計算ですが、その表計算ソフトウェアの歴史をちょっとみてみると、当たり前といえばそうなのですが、8bitマシンの頃からあったんですね。

私が初めてコンピュータに触ったのは、小学3年生の頃に新し物好きな父が酔狂なのか誰かに乗せられたのか（笑）、科学技術的なモノなどとても似つかわしくない我が家に唐突に買ってきた富士通さんの「FM-7」というマシンが最初でした。（犬猫を拾ってきたより衝撃的でした。）

なにせ子供なので、当時はゲームを作ったり遊んだりという用途しか知らなかったのですが、そんな折、たまたま実家の隣に越してきた小規模なシステム開発屋さんのところに出入りするようになり、そこで「Lotus1-2-3」だのなんだのという単語を耳にし、初めてゲーム以外の用途があることを知ったという事を薄らと記憶しています。
（もう30年ちかくも前の話なんですよね…書いてて軽くめまいが…。）

脱線気味になりました。

…で、そんな昔からある表計算ソフト、当初はデータベースという言葉すらマイナーな時代ですし、当然、スタンドアロンな環境で、ファイルベースでデータを保持するのが当たり前で、統制なんて言葉も聞かれない状態、アプリケーションもシェアを巡って群雄割拠状態だったところから、ネットワークの発展と共に「データの一元性・一貫性」の重要度が叫ばれ始めた後も黎明期からの流れを汲んだ直系として今現在生き残っているのがExcelなんですね。

昨今めっきり目にする機会が少なくなった紙媒体に「方眼紙」というものがありましたが、思うにExcelは、その方眼紙の代替のような使い方ができるがゆえに生き残っている感じですよね。
方眼紙自体、使い勝手がよくて私は大好きだったんですが、Excelのインタフェースがすごいのは、そんな方眼紙の代わりになるくらい「使い勝手の良い道具として優れている」という点が大きいと思います。
「データを共有する」という概念の無い時代に生まれたものですが、あまりにインタフェースがわかりやすいために、未だに生き残っているという状態なんでしょう。

…まだ脱線してますね。昔の話を含めすぎると長くなりそうなので端折ります。

さて、そのExcelが、管理会計の現場で未だに使われているのは、やっぱり手軽なツールゆえですよね。
そのうえセル関数やマクロ機能等を考えたら、単体のアプリケーションとしては「超」が付くくらい高機能です。
そしてやはり、同じく手軽ではある「テキストエディタ」には無い、「縦横軸」を持っていて、二次元表現ができることが強みなのと、この機能が、管理会計を行う上で「データを任意のセグメントで分類・管理する」という用途に、ものすごくマッチしているからなんだろうと思います。

二次元の表を、何枚も重ねれば三次元相当のデータを保持できますし、そのフォーマットと類似していながらも中身だけが異なるデータを入れてあげれば、さらに別の「次元」でデータを区別できるわけです。
これを管理会計システムでよく用いられる「セグメント」等に置き換えて考えると、

・1枚のExcelシートで表現される「ある部門の売上や経費の実績値」という表が
・1つのExcelブック内に、組織別のシートとして保持されている。
・そのブックが、更に商品別に存在する。
・更にそのブック群のセットが、顧客別に存在する。
・更にその顧客別に存在するブックが、地域別に存在する…。
・更に（略）

…という1ブックで3次元分、4次元分、5次元分のデータを保持するのが非常に簡単なんですね（作るだけなら）。
管理方法が煩雑にさえならなければ、本当にこれだけで良いですし。

ただし、上記のように細かくデータの区分別にExcelブックを分けて行くと、単にファイルで管理しているだけの場合、ひとつひとつのファイル間には「それを作成した人の頭の中以外に、何の関連性や制約も無い」という状態ですから、誰でも一部分だけを変更できるし、それが他のブックとの関連性を壊すことになっても何の警告も発信されず、誰かの頭の中では、「一つの変更に連動して全体に変更を加えるべき」と思っていたとしても、アプリケーション的にまったく統制できないカオス状態になります。…やっぱりここが弱点なのですよね。
（これに絡んで「スプレッドシート統制」なんていう言葉もあるくらいですし。）

書いているうちに、Excel間のカオス化を抑制し統制する、ブック間制約というか、ルール設定(マスタ化？）的な仕組みが、管理含めて簡単に出来たら、更にExcelの天下は揺るがなくなるんじゃないかなー、等と妄想が膨らんできました。
（既に機能として存在するなら、私の研究不足ということで流していただけれれば。。。）
当社ではこれまでの実績をもとに、部門の強みをパッケージ化する取り組みを行っているのですが、そこで誰かやってくれないでしょうかね…（笑）

管理会計システムの運用

さて、結構脱線気味に進んでいますが、ここで話題を変えて、「管理会計システムの運用」について軽く書いてみます。

私は、自分で構築に携わったものを中心に、管理会計システムの運用支援をかれこれ10年以上やっていますが、運用で一番大変なのは、やっぱり「組織やセグメントの改変」と、「パフォーマンス」ですね。これはEssbaseばかり触っているが故の感想かもしれませんが。

Essbaseを始めとする多次元データベース（特に集計値を保持するタイプの所謂MDB）の良いところを挙げると「データ取得が強烈に速い」ところなんですが、この速さは、データ保持機構からくるもので、普通のRDB（関係性データベース）ではユーザが「検索」をかけた時点で実際の検索処理や集約処理を始めるのに対して、「検索条件にマッチする位置に、集約した答えが既にある」状態をつくっているから速いんですね。
が、ここが最大の特徴でもあり、ネックにもなる諸刃の剣です。

事前に答えを作るということは、その答えを作る処理時間をどこかで確保しているということで、それが「夜間処理」等の、いわゆるバッチ計算時間というわけです。
この事は、一方で「計算時間をユーザがリクエストしたタイミング以外で確保しているだけ」とも言えます。
（「だけ」とか書くと誰かに怒られるかもしれませんが。。。）

そして、この時間は計算対象となるデータが多ければ多いほど、比例して長大化していきます。
いかに利用する際のスピードを求めるためとはいえ、多次元データベース上で計算するのに必要な時間が「サービス外時間を越えてしまう」という状態になっては元も子もありません。
トレードオフの関係なんですね。

また、これらの集約時間は、多次元データベースの定義構造上（一般的に、例えば組織や顧客のセグメント等を定義する際に階層構造をつくりますが）で、「集計値をデータベース上で計算しなければ答えの出せない部分」の数がどれくらいあるかによって、爆発的に増大することがあります。

「集約するのに48時間以上かかる」なんていうケースもあったりしました。
そんな規模のデータベースで、マスタが変わり、セグメントの階層構造が変わるたびに「集約を作り直さなければならない」となると笑っていられない手間ですよね。

更に、それほどの時間がかかる処理が、追加データの不備等に起因して「40時間経ったところでコケてやり直し」なんてこともあり、そんな事が続いて、数日間、意図せず日の出に挨拶できちゃうような、全く嬉しくない状況を経験したことがあります。
（アルコール抜きで変なテンションになれるオモシロ体験ができた事や、こうして話のネタに出来ている点では大変感謝すべきですが！）

つまるところ、ユーザのニーズを満たすために必要な運用・メンテナンスの時間がどれだけかかるかを考慮して、パフォーマンスバランスのよい多次元データベースを作ることの重要さは、運用のしやすさ・運用コストに直結するので、そういった点からも、多次元データベースは業務的な面だけみて構築する事ができないハードルの高さというやっかいな側面がある、というお話です。

皆様も、多次元データベースのパフォーマンスの恐怖を是非一度体験してみては！
…等とはとても言えませんね。