【障害記録】No.5：内部処理におけるデータ区分変換誤りの対応

IT

自分が体験したシステム障害を紹介してトラウマを抉り返す自虐コーナー
※特定避けるため一部脚色・変更しているが、大体ほぼ実体験。

障害No障害分類No
（自分用）発生分類
アプリ/データ/ミドル/ハード案件名個人的ヤバイ度
（５段階評価）

5 B アプリ 内部処理におけるデータ区分変換誤りの対応 ★☆☆☆☆

 

 

 

発生日時 2012/01某日 解決日時 2014/07中 発見者 お客さん 対応者 俺 原因者 俺ではない！（笑）
障害の詳細内容 アップロードファイルからデータを取込んで処理する機能がある。
アップロードファイルは他システムで作成されるため、
取込に際して、自システム用に区分やコードを変換してあげる必要がある。
（保持している区分やコードの体系がシステムで異なる）

アップロードファイルの中に、例えば「データ区分」みたいな項目があったとする。
この区分は、
アップロードファイル："01"（正常データ）、"02"（警告データ）、"99"（エラーデータ）
自システムで　　　　："00"（正常データ）、"01"（警告データ）、"03"（エラーデータ）
というように、システムによって実現値が異なっている。
このため、例えば
アップロードファイルの"01"は自システムに取り込む時に"00"に変換してあげる必要があるわけである。

平たく言うとこの「変換」を間違えていたというのがこの件の本旨である。
しかも間違え方が半端なくて、どうしてそうなったのか全く誰も理解できない程間違えてた。
↑の例で言うと、例えば、
変換元と変換先で、それぞれに存在する実現値のどれかに、誤って変換してしまったってんなら、
まあまだわからんでもない。（例えば"01"⇒"02"とか。）
しかし、実際には変換元にも変換先にも全く存在しない実現値に変換されていた。
その突拍子のなさは↑の例では表現しづらい（実例を出したいが、特定避けるため出せないｗ）が、
まあ、例えば、"01"⇒"XA"とかそんな感じかな。
なにそれ"XA"ってどこから出てきたん？何者なん？
っていう感じ。伝わるかなあ…

実際には、「変換」は、２つ以上の論理項目を組み合わせて行われており、
実現値も↑に書いたような３種類程度では済まないほど多かったので、
ちゃんとマトリクスに取りまとめないと確かに変換は間違えそうだなとおもってはいた。
しかし、それにしたってどうしてそう間違ったんだか全く理解できないほどに間違えてて対応に苦慮した。
変換結果が関連性がなさ過ぎて、「何か特別な意図があるんでしょうか？」とか質問を受けたほどである。
俺が作った（もしくは俺が発注した会社の人がつくった）んならまだしも、
その辺の人らが完全出払った後に残件処理として対応にあたったので、そんなもんわかるわけもない。
（まあ、十中八九「特別な意図」なんてものはないんだろうが）

しかも、この件、
他人が食べ残した案件で、
意味不明の間違え方をしている
というだけでももうやる気が失せてくるのに、
輪をかけてやる気を削いだのは
この項目を使っていない
という点である。

本当にどこにも使っていない。
画面にも表示してないしCSVにも出力していない。
バッチのINPUTにもOUTPUTにもなっていない。
マジで本当にどこにも全く使っていないのだ。
要するに
未使用項目の変換がイカれてるから直す
という
誰も何にも得をしない案件なのである（ただひたすら体力だけを消耗する）

そういうのもあって、この件は（お客さんも了承のうえで）
「他案件の対応を優先」という言い訳によりズルズルと対応が見送られ、
ほとぼりが冷めたころには主担当の人がいなくなっていて、
結果案件発生から完了までにおおよそ２年半を要する長大ストーリーになったのである
（そのうち２年くらいは活動休止期間である。まるでハンｔうわ何をするやめろ）
対応内容・経緯等 「全く使っていない」と書いたが、
本当に全く使っていないならそれが間違ってることすら気づかれないはずである。
何故気づかれたのか？

実はこのアップロード機能にはこの件とは別件の問題があり、
その対応をする際にエビデンスとしてアップロード後のデータのダンプをEXCELに張り付けてお客さんに提示していたため、
そこで気付かれてしまったのである。
⇒その「別件」のエビデンスをお客さんが確認する際に、
　「この件とは関係ありませんが、そもそも項目の変換おかしくないでしょうか？」
　って、言われて、それが発端。。。
システム機能においては一切登場しない項目なのでエンドユーザから指摘があがることはなかっただろう。

その「別件」が発生したのが2012/01某日で、そのときに本件も同時に発生し、
しかし「未使用」ということがわかってからは業務影響のない項目だから、という理由から
対応を後に後に回していたので、結果的に対応完了まで２年半もかかったのである。

実際対応に際して変換パターンをマトリクスにしてまとめてみると、
実業務上発生し得るパターンかどうかは別にしても合計で150程のパターンの検証が必要とわかり、
なんかいろいろやる気をなくした。
輪をかけて面倒なのがアップロードファイルが固定長のファイルであるということか。
（アップロードファイルを作っているのが昔の基幹系システムなので、
　COBOLベースというか、他システムとのデータのやり取りは全て固定長のテキストファイルで行われていたのだ）
最初はEXCELのPADDING関数使ってセコセコ作っていたんだが、面倒になったので、
Javaでテストデータ作成ツールをこしらえたほどである。
蓋を開けてみると、そんな余計な体力すら発生するほど面倒な案件になっていたのだ。

諄いようだがこの項目は使っていないのである。
そんな項目の検証に150パターンもの固定長ファイルを作って（作るツールからして作って）、
単体テストのやり直しをするほど俺もお客さんも正直暇ではない。
しかし対応しないと案件クローズできないので、しょうがないから対応した。
勿論150パターンの検証結果も提示している。
それをお客さんがちゃんと全部見たんだかどうかは知らないが、
なんとか確認してもらってリリースに至ったという次第だ。
正直なところアホくさい案件だったと思う……
反省点・あとがき これを見たSEの方は（いるかどうか知らないが）、
”使ってない項目なんだったら、「業務影響ないから勘弁してくれません？」って交渉して、
　対応無でクローズすればよかったのに”
って、思う方もいるだろう。
対応した本人である俺ですら今でもそう思うんだから恐らく間違いない。
勿論、当時そういう交渉はした。
しかし受け入れてもらえなかったのである。
正確に言うと、「他の有償仕様変更案件を無償対応する約束とバーター」といった
生臭いビジネス交渉を持ちかけられて天秤にかけた結果、
「こっちを対応したほうがマシ」とプロジェクト判断したためである。
まあ、見る人が見ればすぐわかる「変換の誤り」だったので（俺はわからなかったがお客さんはピンときたようだ）、
使っていない項目とはいえ、放置しておくのも気持ち悪いし、
それに将来的にその項目を使うことになったら、、、
という話もあって（そんな予定は今でも出てないが）、
システム的に対応したほうがいいという結論になったという面もある。

「お客さんがピンときた」のは、
この件の担当のお客さんが、アップロードファイルを作っているシステムの担当者だったから。
その辺の「変換」の仕組みに関しては、誰より詳しい人だったからだ。
そりゃその人が見れば一発でわかるねっていうくらい。
一方で、俺たちシステム開発側からすると、
使わない項目だから別にそこまで力をいれて検証しなくてもいい、
と、ナメてかった部分はあっただろう。
そのあたりの意識の差がこの障害を生んだと言っても過言ではない。
実際、そういうナメた立場の人間が、150ものケースをちゃんと精査していたところで、
検証結果には何の疑問も抱かなかっただろう。
（そもそも設計通りならシステム的にはそれが正解なんだから）
そういう意味では、お客さんの「こだわり」を感じた部分である。
でも使ってないからいいじゃんって思ったのはやっぱり事実である。