不具合報告で"余計なこと"をした話

＼オカウチワニが1人でやっている okauchiwani-hitori Advent Calendar 2025 9日目の記事です!!!／

今日は、自分が過去にやらかした「不具合報告で余計なことをしてしまった話」を供養します。
"正しさ"に無責任になってしまった結果、逆に手戻りを起こしてしまった話。今回はまさにその典型例でした。

余計なひと言を添えた結果

もう10年以上前の話ですが、ある検索画面でユーザーが想定する動きにならない挙動が発生しました。仕様書には明確な「あるべき姿」が書かれておらず、こちらから期待する動作を示す必要があります。ここで何を思ったのか、

[期待する動作]
A案とB案という2つの正しい振る舞いがあります。どちらを選ぶかはお任せします。

ここまで、無責任な物言いではなかったんですが、要はそう言うことです。どうあるべきかを案を出すだけ出してどちらが一般的なのか、良いユーザビリティかも示さずに。

B案は"捨て案"だったのに B案で修正されてしまった

その後、修正確認をしたのですが、修正された挙動を確認するとまさかのB案。

完全に私のせいです。口頭でのコミュニケーションが十分行えないが本当のあるべき姿はチームの中に存在していてA案の方がよりベター。B案はただの「可能性」として挙げただけで、もしもA案で実現できない場合にB案でも良いのではないかというぐらいで、自分の中でも"捨て案"のつもりでした。

それがどのように検討されてB案が選ばれたかはわかりません。テストチームと開発チームが会社も地理もとても遠い関係性でしたし、翻訳も入ってニュアンスも多少変わっていた可能性もありますし、人間なのでB案だけ目に入った可能性もあります。プロジェクトも巨大だったので1つ1つの不具合修正の正しさをやりとりする時間はほとんどなかったと記憶しています。

なぜ"余計な案"を書いてしまったのか？

今回の反省点は"あるべき姿が曖昧なとき、選択肢を提示することが助けになる"と思い込んでいたという点です。でも、実際には逆でした。

まず状況を整理しておくと、普段の関係性がギクシャクしていたから、この報告で相手を迷わせてやろうという意識はありません。当時のプロジェクトでは開発とテストは別の会社になっており、現代の開発に比べれば、コミュニケーション量は決して多くはありませんが、良い意味で仕事的な関係性があったと記憶しています。

そのプロジェクトの起票ルールに案の提示は必要ではありませんでしたが、勝手に相手の立場を考えて、求められていない行動をしてしまいました。

今回のケースでは"選択肢を増やした"ことで、開発者の思考をミスリードさせる形になり、B案を実装させてしまったことを詫びて、A案に修正をして頂きました。

じゃあ、どうするのが良かったのか？

今回のように、仕様のあるべき姿が曖昧な場合にQAができるのは、限られたコミュニケーションで最低限の情報を伝えると言うことです。話をダラダラ続けて「で、結局何が言いたいんだっけ？」なんて言っている本人でもわからなくなんてザラです。
情報が増えれば増えるほど「どれが望まれているんだろう？」と迷ってしまいますよね。今回は2つの案だけでしたが、それでも相手がどのような状況で読むのかはこちらでは推測することしかできません。

今回のように案を複数提示したことで、意図せぬ混乱を引き起こしたという悪い状況につながりました。良かれと思ったが行動が裏目に出てしまい、とても反省しました。

まとめ

この事例の学びは、

• 選択肢を増やすと、意思決定が別方向へずれてしまうことがある
• 限られたコミュニケーションの中では“手ごころ”がノイズになりかねない

という、とてもシンプルだけれど深いものでした。
不具合報告において大事なのは、キレイ過ぎる文章でも、気の利いた提案でもなく、
"今なにが問題なのか"をまっすぐ届けることなんだと思います。