【案件日誌⑤】「動いたように見えて何も起きない」を潰した話

システムの不具合には、たちの良いものと悪いものがあります。

たちが良いのは、はっきり止まるものです。エラーが出れば、誰かが気づいて直します。

たちが悪いのは、黙って失敗するものです。保存しましたと表示されるのに保存されていない。一覧が全件のつもりで途中までしか出ていない。気づかれないまま業務が回り、半年後に数字が合わないところで発覚します。

この回は、その静かな失敗を潰していった期間の話です。

「保存しました」と出るのに、保存されていない。

最初に見つけた型がこれでした。画面が送った項目名と、受け取る側が知っている項目名が食い違っている。受け取る側は知らない項目を黙って捨て、残りを保存して「成功」を返していました。

画面には成功と出ます。けれど直した内容は入っていません。テストでも通ってしまいます。通信は成功しているからです。

そこで、受け取る側の設計を全部変えました。知らない項目が届いたら、黙って捨てずにエラーとして返す。対象は42種類の入り口すべてです。

エラーを増やす改修に見えますが、逆です。打ち間違いや直し漏れが、その場で分かるようになりました。静かに失敗するくらいなら、うるさく止まったほうが安全です。

次に見つけたのが、一覧の打ち切りです。件数が多いときに内部で上限がかかり、全部出ているように見えて実は途中までという箇所が6つありました。

これも画面上は正常です。「20件」と出て20件並んでいるので、誰も疑いません。本当は35件あったとしても、気づく手がかりがどこにもない。

件数が業務判断に使われる画面で、これは事故になります。残っている件数を見て今日の作業量を決める人がいるからです。6箇所すべて、実際の全件を数えるように直しました。

同じ考え方で、もうひとつ直したものがあります。画面に出ていた集計値のうち、デモ用に固定で書かれていた数字を、実際のデータから数えるように置き換えました。

見た目は何も変わりません。けれど変わらないことが問題でした。データを変えても数字が動かないなら、その数字は嘘です。そして要件定義の場でその数字を見た人は、「この指標は取れている」と受け取ります。

同じ理由で、外部サービスとの連携についてもまだ繋がっていないことを画面上で明示するようにしました。繋がっているように見せておいて後で説明するより、最初から未接続と書いておくほうが、話が早いのです。

この期間は、修正と検証をひたすら往復しました。

直すと別のところが壊れます。これは避けられません。だから修正のたびにAIによるレビューを回し、画面の自動操作で通しの動作を確かめ、見つかった副作用をまた直す。この往復を何巡も重ねました。

従来なら、ここは人手と時間の勝負になります。レビュー1巡に何人日かかるので、「そこまで丁寧にはできない」という判断が必ず入ります。静かな失敗が世の中のシステムに大量に残っているのは、見つける能力がないからではなく、探す余裕がなかったからです。

AIを主力にすると、この往復の単価が変わります。何巡でも回せるので、「気になるから確かめる」を全部やれるようになる。品質の水準が上がるのではなく、諦めなくてよくなるという感覚に近いものでした。

この作業を要件定義の前にやった理由があります。

静かに失敗するプロトタイプでお客様と議論すると、合意した内容そのものが嘘になります。「保存できていますね」と確認して進んだ要件が、実は保存できていなかった。この手のずれは、後になるほど直す費用が上がります。

動くものを前提に議論するなら、その動くものが正直であることが前提条件です。

次回は、資料から守れない約束を削った話です。こちらは技術ではなく、言葉と契約の話になります。

※本記事の件数は当社側の作業実績です。お客様・システムを特定できる情報は記載していません。進め方や所要時間は案件の規模・体制により異なります。