• 2018-07-09
ウズマスター戦記
ウズマスター戦記 https://www.uzumax.org/2018/07/blog-post.html

大炎上の思い出:日付項目の意味

ふと物思ったので、今日は大障害の思い出を記述しておこう。

プロジェクト概要

あれは2017年頃のプロジェクトだった。
VBで書かれた旧システムから、Javaで書かれた新システムへリプレースするという案件だった。

現行システムの設計書は存在せず、新システムの仕様は「現行通り」という、絵にかいたような炎上条件を満たしたプロジェクトだった。

赤字金額は8億円。
プロジェクト完了後、会社の幹部クラスは全員降格させられた。

プロジェクト完了と言えば聞こえは良いが、実際には期日が来ただけでマトモに要件を満たしていない。

今回はその思い出である。

融資内定日

あのプロジェクトに決定的に不足していたのは、業務そのものに対する理解、業務知識だった。

あのシステムは金融系で、住宅金融ローンを組む際の審査や契約の進捗状況を管理する為のシステムだった。

金融系の様々な単語が飛び交う案件であったが、そのシステム内にこういう単語が存在する。

  • 融資内定日

しかしながら、この単語の意味をみんな分かってなくて「融資することを内定した日でしょ?」くらいにしか思っていなかったのである。

融資内定日の意味

実際に業務を分析すると、実は「融資内定日」なんて項目はこのシステム内に存在してはいけないことが分かった。

正解は、

  • 融資決定日:融資内定が決定した日
  • 融資変更日:決定した融資内定の内容が変更された日

つまり、融資内定日に関連する値は、

  • 初期値
  • 最終確定日

の2つがシステム中にあるわけよ。

しかし、融資内定日が2種類あるってことが分かってなくて、設計時は「融資内定日」の1コしか無い状態で進行した。

そしてそのまま意味が良く分からないまま旧システムから新システムへのデータ移行が行われた。

運用設計も良く分からないまま期日が来てしまい、システムの運行が始まった。

結果

新システムには「融資内定日」しか無いから、

  • 融資内定日には融資決定日を入力する。
  • 融資変更日は別の画面に入力する。←意味不明

という運用ルールが制定された。

しかし、移行データは

  • 融資変更日に値があったら、融資変更日を融資内定日に移行する。
  • 融資変更日に値が無かったら、融資決定日を融資内定日に移行する。

というまるで食い違ったロジックで移行された。

だから、新システムの「融資内定日」には、

  • 新システム移行前である2017年03月31日前までに作成されたデータであれば、融資変更日もしくは融資決定日が登録されている。
  • 新システム移行後である2017年04月01日移行に作成されたデータであれば、融資決定日が登録されている。

という感じに、同じ画面、同じDB項目なのに意味が違う項目が入っちゃってるという。

あのプロジェクトが一事が万事こんな感じで、「日付形式の文字列」という点は担保されていたけど、「その日付にどのような意味があるのか?」という部分はチンプンカンプンで意味不明だった。

結末

こんなんじゃ過去のデータが分からなくて意味不明だから移行をやり直せ、とクライアントより怒りの命令が飛んできたが、その時には既に運用がスタートしちゃってて、データが揺れ動いていて何がなんやら。

  • 2017年03月31日のデータを04月01日に登録した。

とかもあるから意味分かんない。

まあ、条件を一個一個分析していけば理論上は正解に辿り着けるはずなんだけど、何せ業務を理解していないから正解なのかどうかも良く分からんという。

で、何だっけな。
その日付のズレが原因で監査法人に提出する数字が合わなくなって決算が実施出来なかったところまでは見届けたけど、そこで離任してその後は知らぬ。

それから三ヶ月くらいして風の噂を聞いたところ、結局上記の再移行によるデータ修正は実施しようにもどうすれば良いか分からなくて、クライアントはとりあえず画面にデータを突っ込んで、人間が目で見て意味を判断して運用しているそうだ。
データ間の整合性が崩れているから統計的な集計作業は出来ないままである。

教訓

プロジェクトメンバーは技術者集団だったから「日付形式ではない文字が入力されたらエラー」などの制御は可能だった。

しかし「業務とは何たるか?」が腹に落ちていなかったらかこんなことになっちまった。

業務理解を甘く見てはイカンな。

0 件のコメント:

コメントを投稿

お気軽にコメント下さい。