はじめに
この記事は本番環境でやらかしちゃった人 Advent Calendar 2021 21日目の記事になります。
本当は全く違う記事を用意していたのですが、ちょっとコレは世に出すのは危険すぎると判断し、急遽前日の夜に差し替えた記事になります。どんだけやらかしネタのストックあるんですかね。
発端
これは十数年前、私が火消しで急遽参画したプロジェクトの話になります。
当時の上司から、ちょっとの間だけ別案件の応援に行ってくれと頼まれたので快くOKしたはいいけど、いざ現場に入ってみると早速先方の担当者からの山のような数のクレームと、表題のような致命的な不具合の数々。
システムと実際の仕様が全然違うということもあり、プログラムの修正も大概辛かったのですが、並行して誤って投入されたデータの数々を正常化する作業もやらねばならなく、誤支給などがあった各エンドユーザーに電話してめちゃくちゃ怒られながら状況をヒアリングする毎日はめちゃくちゃ辛かったですね……
惨劇はなぜおこってしまったのか
本案件で納品した給与システムは特にベンダー案件にありがちな、パッケージ製品をベースにカスタマイズを加えるタイプのものでした。
一般的な給与体系の企業であればカスタマイズ無しにしてもそこまで大きく燃えることはないような気もするのですが、本件の納品先の給与体系は聞くところによるとシフト勤務の種類が20種類以上とか、給与支払日が人によってバラバラな上に月2回ある人もいたりと、かなり独特であり、カスタマイズ無しには対応できないものでした。
そういう独特な給与体系にも関わらず、要件定義の場には業務を理解している人は同席しなかったため、ほぼパッケージでOKという話のまま進んでしまい、ほぼカスタマイズの入っていないものを納品してしまったことが一番の原因でした。
また、実際に導入の際もほぼ実績のあるパッケージだからということで、テスト運用もまともに行っていなかったということです。まぁちゃんとテスト運用してたら必ず出ていた問題でしょうしね・・・・・・
二度と惨劇を起こさないためにどうしたのか
可能であればなのですが、私が上流工程から参画する場合は、要件定義の場にはシステム化する業務をある程度理解している人をそれぞれ同席してもらうようにお願いしています。同席が無理であればアンケートや個別でのヒアリングなどでなるべく声を拾い上げる形にはしています。
これは、要件定義の場に出てくるシステム担当者の方々が必ずしもシステム化する業務部分を把握しているとは限りませんので。
あとはプロトタイピング等でなるべく早い段階でユーザーへ可視化できるようにはしています。
これは単に後になればなるほど作り直すのが面倒というのもあるのですが・・・・・・