第7回：管理会計システムにおける失敗談1
管理会計システムの勘所
がんばれ日本経済（と、主に私の保有株）
今年は桜がずいぶん早く咲いたり、これを書いている時点で、もう5月間近だというのにかなり寒い日があったり、東北では雪まで降っていたらしいですね。
ちょうど友人が旅行に行っていて、この時期に大雪に遭遇するレア体験をしたようです。
無事帰ってこられたようで何よりですが。夏はどんな気候になるのかが、ちょっと気になります。
それはさておき、昨今、景気が回復基調で良い感じですね。日経平均も大分上がってきて、株式市場という形では確実に景気上昇を感じていらっしゃる方も多いのではないでしょうか。
実際、日経平均も一年くらい前と比べれば明らかですし。ただ一方では円安の影響でエネルギーが高騰し、漁師さん達が大変な思いをしているというような話もあるので良い事ばかりではないようですが。
個人的には塩漬けになっていた保有株の価格も上昇しているのでホッとしているところだったりします。
それでも、よくわかってない頃に「勉強だ」と買った株が大きく下げたまま塩漬け状態（俗に言われる「アホルダー」というやつですかね…。）なので、トータルではまだまだマイナスで、昨年の底と比較して倍くらいには持ち直した、というところです。
特に変な買い方もしていないせいか、ポートフォリオが日経平均と連動しまくりで、見ているだけでも面白いですね。
この連日、各企業さんの「業績予想を上方修正」というニュースが多く見られる気もしますし、ベンチャー企業への投資も活発になっているというような話も聞きます。
引き続き景気が上昇して幸せになれる人が増えるといいですね。
それといつもの事ですが、できればじっくり銘柄を選ぶ時間が欲しいです（笑）
管理会計システム構築における失敗談
さて、今回は延長戦「失敗談」です。オマケの話としては微妙なテーマですが、コラム開始時点での構成に入っていなかったため、苦肉の策という事でお許しを。
でも大事ですよね、失敗経験も。できれば成功だけ経験したいところですが、経験してこそ得られる物もあるということで。また、なぜか多次元データベース「Essbase」案件での失敗ばかりを載せることになりそうですが、それもまたご愛嬌ということで！
尚、失敗要素があった案件がいくつかあるのですが、それぞれの案件で失敗した要因は、全て違う性質のものです。
失敗談その1：「自分自身が素人すぎた…。」（製品知識・ノウハウの重要性）
これはそもそも管理会計云々以前の問題でもありますが。
私が弊社に入社してからまだ1年も経たない頃、10年くらい前の話です。
そのシステムは、私が開発として携わった2つ目の案件だったと思います。
1つ目の案件で多次元データベース（Essbase）という製品を覚えてから初めて設計工程から関わった案件でした。
（関わる人数が少ないので、その時点ですでにほぼPL（リーダー）とSEを兼務せねばならないという状態でしたが…）
プロジェクト内容は、ソースデータとなるPostgreSQLデータベースから、Essbaseを用いて、営業案件・工事の予実管理・社員の稼働実績等の評価データを扱うデータマート（DWHから切り出した、データのサブセット）をそれぞれ作成し、Excel Add-inで参照する画面を実装するというものでした。
10年前当時のスペックのサーバでも、集約に結構な時間がかかる規模のキューブ（10Gくらいだったと記憶してます。）を実装したのですが、ここで苦労したのは、1つ目の案件で得ていた製品技術の基礎を、更に組み合わせて応用を考えるのに時間が掛った点ですね。
特に、「ユーザインタフェースとの間での取得パフォーマンスのよいキューブの作り方」だったり、「計算時間の短縮」だったり。。。技術覚えたての状態では結構なハードルです。
BI系の製品は特に、扱うデータの性質によってパフォーマンスが非常に悪くなるケースがあります。それぞれの製品で、いざチューニングをしようというとき、「何ができて、それらをどんなときにどう設定すると効果的なのか」を知っている、というのは非常に重要だとこの時に学びました。
あるいは、ユーザニーズに合わせてどういうキューブを作ったらよいのか、という勘所をまだ十分には持っていない状態ですから、設計する裏で、ほぼプロトタイピングに近い実験と検証を繰り返す必要があり、かといってユーザを不安にさせないよう出来るだけ早く課題を解決することにも苦心したりと、自分の中でも挑戦の連続でした。
また、この案件では、ソースとなる「営業案件情報」（一般的な変更履歴型）のトランザクションデータをもとにして、「時系列の受注ステータス遷移に変換する」という工夫が必要でした。トランザクションデータ間で、いわゆる「穴埋め」をして、各月毎の連続データに変換しなければならなかったわけです。
過去の経験で、基本的なSQLでクエリを作るということをやってはいましたが、「変更履歴データを時系列に展開する際の、効率のよいETL処理のやり方」などという知識も無かった当時、数百行に渡るSQL文からなるViewをかろうじて作り上げたものの、複雑すぎてメンテナンスにとても時間がかかり、仕様変更に非常に弱いモノが出来上がるという、今にして思えば布団をかぶって「あーーーー！」と悶絶したくなるシロモノです。
昔作ったプログラムソースを見たり、人に見せるときにも同じ恥かしさを感じますよね（笑）
システム開発に直接携わった二つ目の案件でコレは仕方ない部分もあるかなと思えますし、当時の私としては得た物も多かったですが、間違っても「成功」とは言えない経験でした。
特に、パッケージを用いた開発では、新しく耳慣れない製品を使った構築を行うケースがあると思いますが、くれぐれも、「手練れ」といえる技術者を確保して案件を進める事をお勧めします。（過去の自分の経験を棚に上げるようでもありますが…）
失敗談その2：「中間階層エントリーの恐怖」（多次元DBにおける中間階層入力の難しさ）
二つ目も、Essbase案件に関わる失敗です。この案件で構築したシステムは今も元気に稼働しているので、「失敗」と言い切ってしまうと語弊もあるのですが、「もう少し違う方法があったのでは…？」と思う点で、私の中では失敗に入ります。
多次元データベースEssbaseでは、ExcelAdd-inを使ったユーザインタフェースから、直接、データベースへライトバック（書き込み）が出来る事が売りのひとつです。
また、Essbaseの特徴として、夜間処理等で、階層化された分析軸の中間や上位の項目に計算した集約値を保持する事ができ、そのまま同じ領域へライトバックもできます。
（例えば、図１のように、階層化された分析軸があったとき、末端の項目に入力するだけでなく、中間にも書き込める）
これを活用し、「中間階層へトップダウンの予算を入力してもらい、末端から入力されるボトムアップの予算と比較する」というニーズを取り込む事になりました。
確かに、ニーズそのままでの実装はできたのですが、この実装をしたことで、ある現象に悩まされることになります。
これが開発や検証を難しくし、さらには運用を難しくする一つの要因となりました。
少々細かい話になりますが、たとえば、中間の予算が入力されたとします。
しかし、続いて誰かが、それよりも下位の項目に、予算を入力してしまいました。（図2）
この状態で集約処理を実行すると、上位の値は下位の値で上書きされます。
単純なモデルならこの動きは当たり前ですが、これで、組織と勘定科目の２次元になったとして、例えば上位と下位に入力された「勘定科目」が異なる場合どうでしょうか。
代表的なのは「販売及び一般管理費」（販管費）の勘定科目ですね。
図3のように、ある「本部」の広告宣伝費として、100000が入力されました。
それしか入力されなかった場合、広告宣伝費の上位科目である販管費は同じ金額が入ります。
しかし、そこで「本部」の下位組織にあたる「部門A」で、人件費200000が入力されました。
このとき、「部門A」の販管費は200000です。
計算順序の指定にもよりますが、このデータベースで集約をそのまま実行すると、「本部」の販管費が200000（部門Aの位置から単純に上書きされる）か、本来入力した100000だけでなく、部門Aで入力された200000との合算の300000いずれかになります。
平たく言うと、「組織階層の下位の合計値と上位の合計値に不整合が生じやすくなる」、という状態に陥ります。
これが複数のセグメントを持つようなキューブの場合、計算の経緯は更にに複雑化して不整合の追跡が非常に難しく時間のかかるものとなり、結果として、そうした不整合を解消するために、馬鹿にならない時間を要することになります。
そもそもEssbaseはデータベースなので、ユーザインタフェース側で何らかの制御機能を実装しない限り「そういうことも出来てしまう」という自由度の高さも併せ持っています。
ユーザインタフェース側とデータベース間できっちり連動可能な予防機能を実装するか、「中間階層への入力を許さない」事で回避できるものではありますが、構築当時の私も、関わった方々も、この事象の発生を事前に認識できていなかった点で「失敗」ですね。。。
また、この案件は「失敗談その①」で書いた案件の次の案件だったので、駆け出しSEにはまだまだ未知の領域だったともいえますがともあれ、Essbaseでは、「うかつに中間階層にデータを入力してはいけない」という事を実地で学んだ貴重な案件となりました。
今現在は運用ルールでの回避がされているため、うまく回っていますが、いずれ「入力値を末端に限定する」か、もしくは「入力レベル制御機能」の追加を提案したいなと考えています。
…と、今回はここまでです。
いかがでしたでしょうか。多次元データベースを使う機会なんて、普通はそうそう無いでしょうから今回は特に「なんのこっちゃ」という方も多いかもしれないですね。。。
上記のような失敗をする中では、例によって口論、連日の徹夜、納期遅延等、トラブルが多々発生し、それはもう様々な熱いドラマがあったので本当はもうちょっと面白おかしく書きたかったのですが、あれこれ考えて書いてみると意外に真面目な書きっぷりになってしまいました。
「また失敗では…？」と言わずにご容赦を。
…そして、あー時間が！ということで次回は最終回ですね。
更に私の失敗の歴史が続きますがお楽しみに。
