仕様？不具合？判断に迷ったときの相談のしかた

テスト中に期待と異なる動きを見つけても、それが不具合なのか、意図された仕様なのか、すぐには判断できないことがあります。

このようなとき、「不具合と確信できるまで報告しない」「ひとまずすべて不具合として起票する」のどちらかに偏ると、問題の共有が遅れたり、確認のやり取りが増えたりします。

大切なのは、QAが一人で正解を決めることではありません。確認できた事実と判断に足りない情報を整理し、チームが次の行動を選べる状態をつくることです。

この記事では、仕様か不具合か迷ったときに何を確認し、起票と相談をどう使い分けるかを紹介します。

最初に整理するのは「仕様か不具合か」ではなく差分

判断に迷ったら、まず期待する結果と実際の結果の差を整理します。

期待する結果の根拠には、仕様書、デザイン、受け入れ条件、既存機能の挙動、プロダクト全体のルールなどがあります。ただし、資料に書かれていないからといって、すぐに「仕様」とは限りません。仕様の検討から抜けている可能性もあります。

反対に、自分が自然だと思う動きと違うだけで、不具合とは限りません。自分の予想と、確認できた仕様やチームの意図を分けて扱います。

一律の正解はありませんが、次のように考えると判断しやすくなります。

状況	最初の行動
期待する結果が明確で、実際の結果との差を説明できる	不具合として起票する
期待する結果や仕様の意図が分からない	関係者へ相談する
データ消失、決済、セキュリティなど影響が大きい可能性がある	分類を待たず、すぐに共有する

重要なのは、「仕様か不具合か決まってから共有する」という順番にこだわらないことです。影響が大きい問題は、調査中であることを明記したうえで早く知らせます。チームによっては、先にチケットを作成し、そのチケット上で仕様を確認する運用もあります。

どの方法を選ぶ場合も、プロジェクトで決めている報告ルールがあれば、まずはそれに従います。

「これは仕様ですか？」だけでは、相談された側が最初から状況を調べる必要があります。判断に使える情報を添えて相談しましょう。

たとえば、次のように伝えます。

○○画面で保存ボタンを押しても完了メッセージが表示されません。データ自体は保存されています。仕様書にはメッセージの記載がありませんが、同じ操作を行う△△画面では表示されます。画面ごとに挙動を変える意図があるか確認したいです。

この例では、次の情報を分けて伝えています。

原因の予想がある場合も、事実とは分けます。「○○が原因です」と断定せず、「○○が関係している可能性があります」のように、未確認であることが伝わる表現にします。

相談先は、問題を見つけた場所ではなく、足りない情報によって考えます。

複数の役割に関係する場合は、個別に同じ説明を繰り返すより、関係者が見られる場所で相談したほうが認識を揃えやすくなります。

会話で仕様と分かった場合も、その場だけで終わらせないことが大切です。仕様書やチケット、デザインなど、チームで参照する場所へ判断結果を残します。

不具合として対応する場合は、相談で分かった期待結果や影響をチケットへ反映します。具体的な書き方は、不具合起票で気を付けるポイントでも紹介しています。

仕様として扱う場合でも、利用者が迷う、既存機能と一貫していない、といった懸念がなくなるとは限りません。「仕様だから問題なし」で終わらせず、品質上のリスクがあれば別の改善案として共有します。

仕様か不具合か迷ったときは、分類を急ぐより、まず次の点を整理します。

QAがすべての答えを持っている必要はありません。判断に必要な情報を集め、分からないことを明確にして相談することも、品質を支える大切な仕事です。