検証をしていると、データが勝手に変わる瞬間に出会うことがある。今回は顧客マスタのCSV取込機能だった。取込は成功する。エラーも出ない。でも、北海道のお客様だけ郵便番号が6桁になっていた。
取込は成功しているのに、桁が足りない
事象はこうだ。顧客一覧のCSVを取り込むと、「0600042」と入っているはずの郵便番号が「600042」で登録されていた。北海道や青森など、郵便番号が0で始まる地域だけ桁が足りない。それ以外の地域は正常だった。
エラーは一件も出ていない。処理としては全件成功している。私はこの手の不具合が一番怖いと思っている。落ちてくれれば誰でも気付く。静かに壊れるデータは、運用が始まってから発覚する。
バグ票を書く前に、メモ帳でCSVを開いた
最初は取込処理を疑った。数値変換で0を落としているんじゃないか。よくあるパターンだ。
ただ、バグ票を書く前に一つだけ確認した。取り込んだCSVの原本を、Excelではなくメモ帳で開いたのだ。
すると、CSVの中身がすでに「600042」だった。
取込処理は何も悪くなかった。渡された時点で、0は消えていた。犯人はもっと手前にいた。CSVを用意した担当者が、中身を確認するために一度Excelで開いて、列幅を整えて、そのまま保存していた。Excelは「0600042」を数値として解釈する。数値の先頭の0には意味がないので、黙って落とす。
悪意はどこにもない。むしろ「見やすくしておきました」という善意だった。
データは、通り道で変わる
なぜ見落とすのか。機能テストは、取込機能そのものばかり見てしまうからだ。
でも実際のデータは、出力されて、人の手を経由して、取り込まれるという旅をする。その旅の途中にExcelが一度挟まるだけで、郵便番号、社員番号、電話番号の先頭の0は消える。テスト時に気付きにくいのは、テストデータは自分たちで丁寧に作るからだ。きれいな経路しか通っていないデータで試験して、合格を出してしまう。
これはAIにも気付きにくい観点だと思う。仕様書には「担当者がExcelで開いて保存した場合」なんて書いていない。だからAIが作る試験書にも、この観点は出てこない。運用の癖は、現場にしか落ちていない。
再発防止は、機能と運用の両方に打つ
対策は取込側だけでは足りなかった。
取込側には、郵便番号が7桁でなければ警告を出すチェックを入れた。運用側には、CSVをExcelで開いて保存しないこと、確認はメモ帳かビューアで行うことをルール化した。どちらか片方では、またいつか再発する。
これはバグではなかった。でも、業務では事故になる。QAが守るのは機能ではなく、業務のほうだ。
まとめ
データは嘘をつかない。でも、表示と善意は嘘をつく。
あなたの現場のCSVも、誰かのExcelを一度通っていないだろうか。