01
QA確認の目的は「答えを調べてもらうこと」ではない
QA確認の目的は、テスト中に判断できなかった仕様や動作について、開発者・仕様作成者へ判断材料を渡し、必要な回答を得ることです。質問者が確認できる情報を整理せず、「これは仕様ですか？」だけで相手へ渡すと、状況確認の往復が増えてしまいます。
確認した事実、資料に書かれていること、現在の解釈、判断してほしい論点を分けて書く。
QA確認は、必ずYesかNoだけで答えられる必要はありません。回答者が「認識どおりです」または「正しくはこの条件です」と短く返せる状態を目指します。すでに期待結果が明確で、実際の動作が異なる場合は、不具合報告として起票する方法を検討します。
02
QA確認で扱う3つのケース
QA確認は仕様書の不足だけに限定されません。テスト中に判断が止まる代表的なケースは、次の3つです。
仕様確認
仕様に書かれていない条件や境界値について、どの期待値を採用するか確認します。
動作確認
観測した動作を正常として受け入れるか、不具合として扱うかを確認します。
仕様矛盾
複数の仕様書で異なる内容が定義されている場合に、採用する仕様を確認します。
03
まず押さえたい、QA確認の6項目
長い説明より、質問と判断材料の役割を分けることが重要です。次の6項目を使うと、回答者が論点を追いやすくなります。
質問
誰に、何を判断してほしいかを一つの主要論点として書きます。複数の独立した質問は分けて起票します。
確認した状況・事実
条件、入力値、画面表示など、実際に確認したことを書きます。期待や原因の推測は混ぜません。
参照情報
確認した仕様書と章節に加え、該当箇所に何が書かれているか、何が書かれていないかを示します。
現在の解釈
現時点で妥当と考える期待値を、確定仕様と断定せず根拠とともに書きます。
確認理由・影響
回答によって変わるテスト結果、合否判定、表示内容、請求金額などを具体的に書きます。
周辺確認・補足
比較した条件や類似画面など、判断に役立つ確認結果を補足します。未確認の範囲も明示します。
04
具体例：クーポン適用時の送料無料判定
次は、送料仕様とクーポン仕様の組み合わせから期待値を決められなかった場合の記載例です。金額例は、回答者が境界条件をすぐ理解するための判断材料として使っています。
QA #2048
定額クーポン適用時の送料無料判定額を確認したい
wataru nakayama が 2026/08/13 10:30 に追加。初版
説明
質問
送料無料条件の5,000円は、定額クーポン値引き後の商品合計へ適用する認識でよいでしょうか。
確認した状況・事実
商品合計5,200円に500円の定額クーポンを適用すると、値引き後の商品合計は4,700円になります。
参照情報
送料仕様書 Rev.3.1「2.2」には「商品合計金額が5,000円以上の場合、送料を無料とする」、クーポン仕様書 Rev.2.4「4.1」には「定額クーポンは商品合計金額から値引きする」とあります。送料無料判定と値引きの処理順序は記載されていません。
現在の解釈
値引き後の4,700円を判定額とし、送料600円が発生すると考えています。
確認理由・影響
回答により、クーポン利用時の送料表示と請求金額の期待値が変わります。
周辺確認・補足
クーポンを使用しない商品合計5,200円の注文は、送料無料になる想定で準備しています。
この記載が回答しやすい理由
- 回答者が判断する論点を、値引き前後のどちらで判定するかに絞っている
- 二つの仕様に書かれた内容と、記載されていない処理順序を分けている
- 回答によって送料表示と請求金額の期待値が変わることを示している
05
QA確認で起きやすい4つの失敗
「これは仕様ですか？」だけで聞く
対象の動作、確認条件、参照した仕様、判断してほしい点が分からず、聞き返しが必要になります。
複数の論点を一度に詰め込む
送料、税、ポイントなど独立した質問を混ぜると、回答がどの論点に対応するか曖昧になります。
仕様書の確認を丸投げする
文書名だけを示すのではなく、該当箇所の記載内容と不足している判断を整理します。
現在の解釈を確定仕様として書く
「〜と考えています」と未確定であることを示し、回答者が訂正できる余地を残します。
06
回答依頼前のチェックリスト
- 題名だけで、確認したい対象と論点が分かる
- 質問者が確認できる資料と事実を整理している
- 参照資料の章節だけでなく、具体的な記載内容を書いている
- 確認済みの事実と現在の解釈を分けている
- 回答によって何の判断や期待値が変わるか分かる
- 回答者が短い判断または訂正で返せる論点になっている
