見積画面では3,981円。請求画面では3,980円。同じ明細なのに、合計が1円だけずれていた。
消費税の端数処理が画面によって違う。これはバグだと思った。再現手順を整えて、キャプチャを撮って、起票した。我ながらきれいなバグ票だった。翌日、開発リーダーから返ってきたのは一言だった。
「それ、仕様です」
QAをやっていると、この返事に何度も出会う。バグだと思って起票したものが、仕様だと言われる。あの瞬間の、恥ずかしさと納得のいかなさが混ざった気持ちは、何年やっても慣れない。
見積は四捨五入、請求は切り捨てだった
調べてもらうと、見積画面は消費税を四捨五入、請求画面は切り捨てで計算していた。だから端数の出る明細では、必ず1円ずれる。理由も聞けば筋が通っていた。数年前、経理部の要望で請求側だけ切り捨てに変えた経緯があるという。
じゃあ仕様書のどこに書いてあるんですか、と聞いた。返ってきた答えが忘れられない。
「たしか、当時の定例の議事録に書いてあったはず」
仕様書には「消費税を加算する」としか書かれていなかった。端数処理の方式は、どこにもない。つまり私が読める範囲のドキュメントを正とするなら、四捨五入も切り捨ても、どちらも「仕様通り」になってしまう。
「仕様です」の根拠を、誰も見せられなかった
バグ票はクローズされた。ステータスは「仕様」。でも、もやもやが残った。仕様だと言うなら、その仕様はどこにあるのか。
開発リーダーの記憶。経理部との口約束。数年前の議事録。それらはすべて「実装がこうなっている理由」ではあるけれど、「次にこの画面を触る人が読める仕様」ではない。現に私はバグ票を1枚無駄にしたし、来年入ってくる新人も、たぶん同じ起票をする。
このとき気付いたのは、この現場ではバグか仕様かの判定が、ドキュメントではなく人の記憶で行われている、ということだった。答えられる人が異動したら、この仕様は誰にも証明できなくなる。
「仕様だから直さない」と「仕様が書かれていない」は別の問題
それ以来、「仕様です」と返ってきたときの動き方を変えた。事象のバグ票はクローズしていい。そのかわり、必ず根拠を聞く。「どのドキュメントを見れば分かりますか」と。
出てくればそれでいい。私の確認不足だ。出てこなければ、それは実装のバグではなく、ドキュメントのバグだと考えることにしている。だから「仕様書に端数処理の記載がない」という改善起票に切り替える。事象は仕様でも、書かれていないことは直せる。
AIにテストケースを作らせる時代になって、この区別は前より重要になったと感じる。AIは渡された仕様書を正として動くから、書かれていない口伝の仕様は、AIにとって存在しないのと同じだ。人間なら「あの人に聞けば分かる」で回っていたものが、AIを挟んだ瞬間、ぜんぶ「仕様通り」の顔をして通過してしまう。
バグ票が「仕様です」で終わった数だけ、書かれていない仕様がある
バグだと思ったら仕様だった、という経験は、QAなら誰でも持っていると思う。私は長いこと、あれを恥ずかしい失敗として数えていた。でも今は、ドキュメントと実装の間にある穴を1つ見つけた瞬間だった、と数え直している。
あなたの現場で最近「仕様です」でクローズされたバグ票、その仕様の出どころは、どこに書いてあっただろうか。