メールマガジンバックナンバー

【管理会計システムの勘所】
システムエグゼ 管理会計コンサルティング部の古川潔が、管理会計システムの構築に関わる諸々について、様々な観点からご紹介致します。

◇第7回 「管理会計システムにおける失敗談1」 【 エグゼ通信79号】

がんばれ日本経済(と、主に私の保有株)

今年は桜がずいぶん早く咲いたり、これを書いている時点で、もう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の特徴として、夜間処理等で、階層化された分析軸の中間や上位の項目に計算した集約値を保持する事ができ、そのまま同じ領域へライトバックもできます。
(例えば、図1のように、階層化された分析軸があったとき、末端の項目に入力するだけでなく、中間にも書き込める)



これを活用し、「中間階層へトップダウンの予算を入力してもらい、末端から入力されるボトムアップの予算と比較する」というニーズを取り込む事になりました。


確かに、ニーズそのままでの実装はできたのですが、この実装をしたことで、ある現象に悩まされることになります。

これが開発や検証を難しくし、さらには運用を難しくする一つの要因となりました。


少々細かい話になりますが、たとえば、中間の予算が入力されたとします。
しかし、続いて誰かが、それよりも下位の項目に、予算を入力してしまいました。(図2)


この状態で集約処理を実行すると、上位の値は下位の値で上書きされます。
単純なモデルならこの動きは当たり前ですが、これで、組織と勘定科目の2次元になったとして、例えば上位と下位に入力された「勘定科目」が異なる場合どうでしょうか。
代表的なのは「販売及び一般管理費」(販管費)の勘定科目ですね。



図3のように、ある「本部」の広告宣伝費として、100000が入力されました。
それしか入力されなかった場合、広告宣伝費の上位科目である販管費は同じ金額が入ります。
しかし、そこで「本部」の下位組織にあたる「部門A」で、人件費200000が入力されました。
このとき、「部門A」の販管費は200000です。
計算順序の指定にもよりますが、このデータベースで集約をそのまま実行すると、「本部」の販管費が200000(部門Aの位置から単純に上書きされる)か、本来入力した100000だけでなく、部門Aで入力された200000との合算の300000いずれかになります。
平たく言うと、「組織階層の下位の合計値と上位の合計値に不整合が生じやすくなる」、という状態に陥ります。


これが複数のセグメントを持つようなキューブの場合、計算の経緯は更にに複雑化して不整合の追跡が非常に難しく時間のかかるものとなり、結果として、そうした不整合を解消するために、馬鹿にならない時間を要することになります。


そもそもEssbaseはデータベースなので、ユーザインタフェース側で何らかの制御機能を実装しない限り「そういうことも出来てしまう」という自由度の高さも併せ持っています。
ユーザインタフェース側とデータベース間できっちり連動可能な予防機能を実装するか、「中間階層への入力を許さない」事で回避できるものではありますが、構築当時の私も、関わった方々も、この事象の発生を事前に認識できていなかった点で「失敗」ですね。。。

また、この案件は「失敗談その①」で書いた案件の次の案件だったので、駆け出しSEにはまだまだ未知の領域だったともいえますがともあれ、Essbaseでは、「うかつに中間階層にデータを入力してはいけない」という事を実地で学んだ貴重な案件となりました。


今現在は運用ルールでの回避がされているため、うまく回っていますが、いずれ「入力値を末端に限定する」か、もしくは「入力レベル制御機能」の追加を提案したいなと考えています。




…と、今回はここまでです。


いかがでしたでしょうか。多次元データベースを使う機会なんて、普通はそうそう無いでしょうから今回は特に「なんのこっちゃ」という方も多いかもしれないですね。。。
上記のような失敗をする中では、例によって口論、連日の徹夜、納期遅延等、トラブルが多々発生し、それはもう様々な熱いドラマがあったので本当はもうちょっと面白おかしく書きたかったのですが、あれこれ考えて書いてみると意外に真面目な書きっぷりになってしまいました。
「また失敗では…?」と言わずにご容赦を。


…そして、あー時間が!ということで次回は最終回ですね。
更に私の失敗の歴史が続きますがお楽しみに。



第6回へ戻る  第8回へ続く

「管理会計システムの勘所」バックナンバー

第1回「管理会計とシステム」

「管理会計ってなんですか?」という方々向けに、まず会計管理を簡単にご紹介します。また、管理会計にはどういったソリューションが存在しているのかについて、昨今のトレンドのトレンドと合わせてご紹介します。

掲載:2012年10月31日発行 / エグゼ通信73号

第2回「管理会計システム構築における考慮点(1)」

会計管理システムへの要望と言えば? 実際の構築事例を交え、お客様のニーズに答えるシステム構築のポイントを『組織』、『セグメント』、『インプット』の観点からご紹介します。

掲載:2012年11月29日発行 / エグゼ通信74号

第3回「管理会計システム構築における考慮点(2)」

今回は、ある基準で費用を配分処理する『配賦』に関わる勘所です。 管理会計システムを作るうえで頻出する要件について、2つのパターンの事例を交えつつ、システム導入・構築の勘所をご紹介致します。

掲載:2012年12月21日発行 / エグゼ通信75号

第4回「管理会計の製品群と特徴」

今回は管理会計系製品について、専門家から見たメリットとデメリットのポイントをご紹介します。 大規模企業、中小規模企業、それぞれの管理会計システムで重視するべき機能とは?

掲載:2013年1月30日発行 / エグゼ通信76号

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

会計の現場で、あまりにも使われている『Excel』。今回はその利便性を、昔話を交えつつ改めて分析します。
多次元データベースの特長と運用のポイントもご紹介!

掲載:2013年3月1日発行 / エグゼ通信77号

第6回「管理会計システムの未来」

管理会計の目的は、企業のパフォーマンスを内側から測ること。
今回は現状のシステムおよび業務の課題を挙げつつ、管理会計システムの未来について考えます。

掲載:2013年4月2日発行 / エグゼ通信78号

第7回「管理会計システムにおける失敗談1」

今回は管理会計システム構築における「失敗談」!
実際の現場で起こった様々なトラブルの原因から解決まで赤裸々にご紹介します。

掲載:2013年8月8日発行 / エグゼ通信79号

最終回「管理会計システムにおける失敗談2」

大好評の連載もとうとう最終回!
積み重ねた経験から見える管理会計システムの未来とは?

掲載:2013年10月8日発行 / エグゼ通信80号

※ 記載されている会社名、製品名は、各社の登録商標または商標です。
※ 当ページに記載の情報はメルマガ配信当時のものであり、このページの閲覧時には変更されている可能性があることをご了承ください。

  • セミナー・ イベント情報
ページの先頭へ