はじめに
こんにちは！
品質支援課の間宮です。
「この挙動って、不具合扱い？」
「いや、このリリースなら許容じゃない？」
開発現場で、こんなやり取りをした経験がある方は多いと思います。
私が関わっているプロダクトでも、まさに同じ状況が続いていました。
不具合や気になる挙動を見つけるたびに、PO・企画・開発・QAで集まって、
これは“不具合”なのか
今回のリリースでは“許容”なのか
修正すべきなら、どのくらい優先度を上げるべきなのか
を毎回議論して整合していました。
しかし、このやり方だと「判断の軸」がチームで揃っていないため、最終判断がどうしても“感覚値”に寄ってしまいます。
「気になるから直したい」「今はスピード優先で後回し」
どちらの意見にも理由はありますが、基準が曖昧なままだと、いつの間にか“プロダクト品質”に対する認識がロールごとにズレていきます。
この記事では、そんな状況を改善するために
品質基準ガイドラインをつくり、品質判断した話を紹介します。
同じように「品質判断が感覚になりがち」なチームのヒントになればうれしいです。
課題
当時、QAとしてテストを進めるなかで以下の課題を抱えていました。
① 判断の不統一
・不具合か許容かの判断が毎回ブレる
・優先度判断がロールごとに異なる
・同じ事象でも、人によってチケット化の判断が変わる
② 非機能要件（特にパフォーマンス）の曖昧さ
・「遅い」「重い」など感覚的な議論が発生
・改修要否を定量的に判断できない
・QAが“すべての遅延”を報告することになり工数が増加
③ コミュニケーション／整合コストの増大
・各ロール間のすり合わせが毎回必要
・判断の根拠が属人的になりがち
・QAの指摘の厳しさ／緩さが“個人基準”に見え心理的安全性が下がる
実際に取り組んだこと：品質基準ガイドラインの策定
ちょうど新機能のMVP開発が進んでいたタイミングで、
この課題を解消するために 「品質基準ガイドラインをつくりませんか？」 とチームに提案し、策定を進めることになりました。
MVPとして“OKとするライン”はどこか
ユーザー体験として“最低限守るべきこと”は何か
当たり前品質となる具体的な内容は？
魅力的品質となる具体的な内容は？
これらを軸に、機能要件・非機能要件の両面から基準を整理していきました。
また、
「絶対クリア必須」のルールではなく、判断の拠り所として柔軟に運用できるガイドライン
として設計し、状況に応じて動ける形にしました。
スモールスタートとして試しにやってみるようを大事にしました。
具体例：ユーザー待機時間の基準づくり
議論が特に印象的だったのは、レスポンス時間に関する基準です。
QA：「API通信あり／なしで具体的な数値基準を設けたい」
企画：「UXとしてはn秒以内に収めたい」
開発：「APIありでn秒は厳しいがm秒なら現実的」
全員：「ではMVP時点ではどうする？」
それぞれ妥当な理由があり、ロールごとに実現できるラインをヒヤリングしたうえで
最終的に、以下のように定義しました。
API通信を含む場合と含まない場合のそれぞれで、
レスポンス（起点となるユーザーの操作〜処理が完了するまで）が0秒を起点とし◯秒以内である。
“ユーザービリティ的にどれくらい待てるのか”を起点に議論できた、良いプロセスでした。
結果
品質基準ガイドラインを導入したことで、チームに次のような変化が生まれました。
① テスト・品質判断が圧倒的にラクになった
基準を満たしている → OK
基準を超えている → 要報告
という明確な線引きが生まれ、曖昧な判断や“とりあえず全部報告”が激減。
② 整合コストが大幅に減少
影響範囲の議論
優先度の合意
修正可否の判断
これらがスムーズになり、MTGやSlackでの往復回数も目に見えて減りました。
③ ロール間の心理的安全性が上がった
QAの指摘が“個人の価値観”ではなく“チーム基準”に基づく
開発側も「どこまで対応するべきか」が事前にわかる
議論の衝突が減り、建設的な関係性が築きやすくなった
結果として、開発スピードとQAの負荷のバランスが取りやすくなり、
チーム全体の“品質に対する共通認識”が強くなりました。
振り返り
今回は 実装後に基準を作る 流れでしたが、
理想は 仕様策定の段階で品質基準を固める ことです。
品質基準 → 仕様設計 → 実装
という順番が守れると、品質が“後追いの補正作業”ではなくなります。
品質はあとから付け足すものではなく、
最初から作り込むもの。
今後は上流工程での合意形成にもっと力を入れ、
チーム全体で品質をデザインしていける状態を目指したいと思います。