バグ票を起票して数日後、Slackに短い返事が届く。「直しました」。この3文字ほど、QAをざわつかせる報告はないと思っている。「動きません」なら、これから調べればいい。でも「直しました」は、もう終わったことになっている。
修正確認は一発OKだった
そのバグは、電話番号の欄にひらがなが入力できてしまうという、よくあるものだった。「でんわばんごう」と入れても、そのまま登録できてしまう。ついでに言うと、この画面は性別の選択肢が「男性・女性」ではなく「男・女」のボタンだった。トイレかよ、と心の中で突っ込んだ。それくらい年季の入ったシステムだった。
起票して、数日後に「直しました」が届いて、私は該当画面でもう一度ひらがなを入力した。今度はきちんとエラーになった。期待どおりだ。
再試験は15分で終わり、バグ票をクローズした。その日の私は、いい仕事をしたつもりでいた。
数日後、頼んでいない場所が変わっていた
一週間ほどして、運用担当から問い合わせが来た。「昔からのお客様の情報が、更新できなくなったんですけど」。編集画面を開いて保存を押すと、触ってもいないFAXの欄でエラーになるという。バグ票は起票されていない。誰もFAXの欄なんて直していないはずだった。
調べてみると、原因はあの修正だった。開発者は電話番号のチェックを直すついでに、電話・FAX・携帯でバラバラに書かれていた入力チェックをひとつにまとめていた。悪意はない。むしろ親切心だ。「似たようなコードがあったので、共通化しておきました」と言われた。
でも、それらは似たようなコードではなかった。電話番号は半角の数字とハイフンだけ。FAXの欄は「(代)」や「内123」のような表記が昔からの運用で許されていて、古いデータには全角ハイフンの「－」や全角の「（代）」、なかには番号の後ろに「（株）」と書かれたものまで生きていた。誰かがメモ代わりに使っていたのだろう。
そもそも電話番号自体、そんなにきれいな世界ではない。市外局番は2桁から5桁まであって、「03-1234-5678」もあれば「0466-12-3456」もある。同じ番号でも、人によってハイフンを打つ位置がずれる。桁と区切りを厳密に見ようとするほど、正しい番号まで弾かれていく。違って見えた数行は、書いた人の癖ではなく仕様だった。共通化は、その違いと歴史を、表記ゆれとして消してしまった。
バグは確かに直っていた。でも、変更はバグ修正だけではなかった。そして私が再試験したのは、バグ票に書かれた範囲だけだった。
「直しました」には、判断材料が何もない
なぜ見落としたのか。再試験の範囲を、バグ票から決めていたからだ。バグ票に書いてあるのは事象だけで、何をどう直したかは開発者の頭の中とコミットログの中にしかない。「直しました」という報告は、完了形なのに情報量がほとんどゼロなのだ。
何を変更したのか。なぜその直し方を選んだのか。どこまで手を入れたのか。全部が抜けている。それでも「直りました」という結果だけは確認できてしまうから、クローズできてしまう。
もっと怖いのは、報告した本人も影響するとは思っていないことだ。共通化した自覚はあっても、FAXの欄に全角記号交じりの番号が生きていることまでは知らない。誰も嘘をついていないのに、試験の範囲だけが静かにずれていく。
再試験の範囲は、報告ではなく差分で決める
それ以来、「直しました」が来たら、直した内容を聞き返すことにしている。「どのファイルを変更しましたか」でもいいし、可能ならコミットの差分をそのまま見せてもらう。1ファイルのつもりが5ファイル変わっていれば、再試験は1画面では済まない。
影響範囲の洗い出し自体は、いまはAIがかなり得意になった。差分を渡せば、影響しそうな機能を列挙してくれる。ただし、その前提には「差分を渡す」という行為がある。「直しました」の3文字だけでは、AIにも人間にも何も判断できない。報告されていない変更に気付けるかどうかは、ツールの性能ではなく、報告を疑う習慣があるかどうかで決まる。
まとめ
「直しました」は修正の完了報告であって、変更内容の報告ではない。この2つを区別するようになってから、私のデグレの見逃しは目に見えて減った。
あなたの現場の「直しました」には、何が書かれているだろうか。