第8回：管理会計システムにおける失敗談2

早くも9月ですね

さて。。。あっという間に9月です。これを書いている時点ではなんとなく涼しい日もあり、早くも夏終了な雰囲気が感じられる今日この頃ですが、皆様いかがお過ごしでしょうか。

それにしても、当たり前すぎて若干書くのをためらうところですが、今年の夏も暑かったですね！
なぜかわかりませんが今年は妙にガリガリ君を食べたい気分になる日が多く、かなりの頻度で食していました。特に梨味推しです。
我が家ではエアコンが壊れて部屋が水浸しになるという大参事と、10年ちかく住んだ部屋から引っ越すなど夏としては微妙ながらも印象深いイベント（？）がありました。
弊社社屋も近々移転を予定していますので、公私ともに一区切りというところでしょうか。
このコラムも今回が最終回ということでもうひとつ区切りになりますが、ここまで根気強く読んでいただいた方、是非最後までお付き合いいただけますと幸いです。

当初6回予定からの延長戦も２回目となりますが、前回に引き続いて、管理会計システムの失敗談として更にいくつかのエピソードをお届けします。

管理会計システム構築における失敗談

前回書いたのは、「製品知識・ノウハウの重要性」に関するものだったり、「多次元DBにおける中間階層入力の難しさ」というところからくる失敗談でしたね。製品知識や特殊な製品機能に関する理解という点では管理会計システム構築上の独自性のようなものがあっての話でしたが、今回は、どちらかというと人材やプロジェクトマネジメント上の話になります。
管理会計システム以外にも共通する部分かと思いますが。

失敗談その3：「自分以外がほぼ素人」

さて、こちらは8年程前、あるお客様向けに管理会計システム構築を行う事になったときの話です。
いくつかの管理会計システム構築に携わって、若干技術に自信がついた頃、トータルで20人月分ほどの案件をいただきました。
当時Essbaseという製品の技術を覚え堂々とお客様と話ができるようになってきていた事や、社内に同等の技術スキルをもった人材がほぼいなかった時期だったという事もあって、私は小さなプロジェクトながら半分PM、半分PLのような形で関わることになりました。
なにぶんニッチな技術であることや、能動的な人集めに経験が不足していた当時、プロジェクトにアサインできたのは入社直後や当時の新人を含む経験年数2年以内の技術者3名だけという、かなり頼りない状態です。

この時点で、システム開発のプロジェクトに携わった方ならすぐにお分かりかと思いますが、相当無茶な要員構成だったのは間違いありません。はっきりと意識していたわけではありませんが、「自分ができるようになったから、人も頑張ればできるだろう」「何かあっても俺がなんとかしてやる」という少々無茶な気負いもどこかにあったかもしれません。
（イザとなったら根性でなんとかしようという、おもいっきり昭和の思考ですね！今は違いますよ、念のため！）
最初にEssbase案件でお世話になったお客様から紹介いただいたことや、是が非でも取って更に経験値を上げたいという思惑もあって、無茶を承知で受注した、という側面もありました。

そんな中始まったプロジェクト初期、メンバーに技術を教え込みながら日々お客様と打ち合わせて要件を決め、なんとか基本設計を終わらせたところまでは比較的順調でしたが、詳細設計に入ってから、徐々に問題が出てきます。
この段階ではデータベース、画面、ETL処理、その他運用系のバッチ処理諸々の細かい仕様を詰める必要があったわけですが、納得のいく設計品質を維持しつつ分担できる程メンバーが育っていない中、とにかく余裕が無くなっていきます。
技術が分かるからといっても物量はどうにもなりません。そして、じわじわと押していくスケジュールをなんとかしようと、止む無くメンバーに任せた事が発端となってトラブルが生じます。

この案件で発生したのが、「配賦処理によるデータ爆発」でした。以前、このコラムにも挙げた部分ですね。
このケースの場合、基本的には組織内の配賦でしたが、各組織階層毎に、配賦する・しないの区分が多く、いわば「多段階配賦」のような処理が必要、かつ元データもかなり粒度が細かく、単月で数十万レコードくらいだったデータが配賦処理によって膨れ上がり、Essbaseに取り込むには多すぎるレベルに達していました。（1月分のロードデータが1ギガバイトを越えていました。）
試しにこれを集約すると…処理時間が24hを越えた時点であきらめ、配賦後のデータ粒度をよりサマライズされた形にさせていただくよう調整するに至り、プロジェクト的にはリリース遅延が確実となりました。。。

お客さんが希望されるままに詳細仕様を作ったメンバーは、配賦処理の結果、レコード件数がどれくらい増殖するのかを十分に想定することができなかったんですね。
また、私も他の部分や他メンバーへのレクチャーで手一杯で、レビューがおろそかになってしまった事も問題を大きくした要因でした。
そもそもこうした事態に陥る可能性を想定して見積もりが出来ていなかったのも自分のミスであって、PM/PLを任された自分としては、もう泣くに泣けない状況です。

このケースは、マネジメント的な観点では、自分が出来るとしてもメンバーが技術に習熟していない場合にアラートが上がってこない、キャッチできない状況が発生しやすい事（あたり前なんですけどね…）、そして管理会計システム構築という観点では配賦に起因したボリューム増大の影響度という勘所を押さえていなかった事でトラブルになった、という例になります。

特に、技術分野としてニッチな多次元データベースに関するパフォーマンスチューニングや勘所といった情報はあまり世に出てないですし、あまり経験したくない話だろうとも思いますが（笑）、だからこそ尚の事、この手の経験をもった人材は本当に希少で価値があります。ハード・ソフトともまだまだ性能が向上していってますし、遠い未来にはパフォーマンスを気にしなくてもよい日がくるかもしれませんが、まだまだこうしたノウハウは有効な環境にありますので、今後、技術者を育てる機会のある方は、是非、パフォーマンスチューニングに関する知識を十分に学んでもらう必要がある事は念頭に置いていただければ。

それと…案件に関わるエントリーレベル技術者の比率は限界値を設定すべきということも（笑）

失敗談その4：「あけてびっくり旧バージョン」

こちらも管理会計に関わらず、システム開発に共通する話かもしれませんが、この例は新規構築ではなく、既存システムの改修における失敗談です。

4年程前にやった案件での失敗ですが、あるお客様が利用されているEssbaseで構築されたシステムの追加開発をご依頼いただきました。こちらはトータル30人月前後の案件で、要件定義フェーズから私が参画し、その後の開発を弊社で請け負う形となりました。

さて要件定義フェーズで諸々話を伺いつつ、既存環境の調査を行ったところ（これ以前に、できれば調査だけで十分な工数を頂けたらよかったところですが。。。）かなり古いEssbase環境で、この時点でまだWindowsNTが使われている状態でした。
Essbaseのバージョン5と、ExcelAdd-inを利用したVBAマクロでガチガチに作り込んだ大量の定型帳票画面をもつシステムです。ここに対して、追加機能を実装して欲しいというのが開発の趣旨で、そこに含まれる要件は、現行で分析可能なデータを、更に増やす方向、あきらかにデータボリューム増大とパフォーマンスの担保が難しい要件でした。

ボリューム増大といえば、これまでの案件でさんざん痛い思いをしてきたので、そこはあらかじめ、これらのリスクを納得いただいて進めることができたのですが、さて、ここで生じた問題は、、、
あまりに古いバージョンを使っていたがために、私が把握している機能が使えない、あるいはバグFixパッチや、関連情報が更に少なく、開発担当メンバーが手詰まりになってしまう事象が多発したという事でした。

ExcelAdd-inのクライアントは日本語環境で文字化けし、APIもおかしな動きをする箇所がちらほら。
おまけに、「既存帳票の実装を基にして、追加分を開発します」という方向で行ったのがあだとなり、完全に素人実装とわかるレベルのマクロを解析して拡張するハメになりました。。。
Exceladd-inを利用したAPI自体の使い方はそう難しいものではないのですが、既存画面は、Excelセル位置のハードコーディングがやたらと多く、動きを追跡するだけでも相当な労力で、「”マクロの記録”でやったんじゃないか？」と疑いたくなるような出来です。
初期の構築に携わった方々にもそれなりのご苦労があったのだろうと思いますが。

結局、この問題そのものは、必死でパッチを探したり、実装上で様々な回避策を検討して最終的には要望に応えた形に収まったものの、これらの対策を事前検討できていなかった分、時間のロスが生じているわけですから、必然的に検証の為の時間が十分に取れないという問題が生じました。
検討が不十分な対応も多くあり、結合テストに入ったものの相当数のバグが発生して、またしてもスケジュールは押して行きます。

それらに加えて、実は更にこの案件でも人の問題が。
サブリーダーを任せて居たメンバーがこなくなるという事態が生じました。
（プライベートの事情に起因した心の病でした。。。決して高稼働だったり仕事でのプレッシャーという理由ではなかったですよ！念のため！）
また、そのうえ責任者として名前のあった別案件に一緒に関わっていた他社さんが炎上するという事態が同時に発生するという恐ろしい状況に。。。

さて、ここからまた私の稼働時間が人生上経験したMax値に向かってウナギ昇りしていくわけですが、これ以上は苦労自慢になってしまうのでホドホドにしておきましょうかね（笑）

このケースは、新しいバージョンから入った技術者が旧バージョン製品を利用せざるを得ない状況下では、多大な工数がかかる場合がある、という話ですね。
様々なシステムで、様々な製品が使われているので、似たような事例はあるかもしれませんが、管理会計システムで使われる製品の場合、製品自体が高価なためにそうそう入替ができなかったり技術者の絶対数が少ないことでとくに旧バージョンを利用しなければならないとき、これらのノウハウも事前に自前で十分検証を行わないと大変危険だ、という事です。

さて、以上最終回となりましたが、いかがでしたでしょうか。

また機会があればいずれお目にかかる事があるかもしれませんし、あるいは管理会計システムの現場で是非お会いできればと思います。
また、業務にかまけて締切破り等多大なご迷惑をおかけした担当の相川さん、ごめんなさい。綺麗にイラストもつけていただいて大変感謝しております。

そして、8回にわたり、拙いコラムにお付き合いくださった皆様、ありがとうございました。
今後、よいシステム開発を進めていただけるであろうことをお祈りいたします。

終わり