品質の定義が曖昧で揉めるPMへ──受け入れ条件を先に固める合意の型

テストが終わった。リリース日も近い。
なのに最後の最後で、関係者がこう言い出す。

• これ、思ってたのと違う

• 使い勝手が悪い

• 品質が不安だから延期したい

• いや、要件は満たしているはずだ

この揉め方、根性やコミュ力の問題じゃない。
品質の定義が曖昧なまま、開発が走ってしまっただけ。

僕はこの手の案件で、途中から頑張って品質を上げるより、先に受け入れ条件（Acceptance Criteria）を固めて合意するほうが、結果的に早くて安全だと感じています。今日はその型を、簡単ではあるが、今日から使える形に落とします。

品質が曖昧な現場で起きていること

揉める現場は、だいたい次の3つが同時に起きています。

1) 仕様の合意と品質の合意が混ざっている

仕様（何を作るか）と、品質（どの状態ならOKか）は別物です。
仕様は満たしていても、品質がダメなら本番で事故る。
品質はOKでも、期待する利用体験がズレていれば不満が出る。

2) 誰の不安を潰すのかが決まっていない

現場が求めているのは、状況説明より安心です。
安心の正体は、どうなったら不安が消えるかの言語化です。

3) 合格基準が脳内に散っている

利用部門は体感で判断し、開発側は仕様準拠で判断し、運用は事故を恐れて判断する。
基準が分散したまま最終局面に入ると、必ず衝突します。

受け入れ条件を先に固める合意の型

ここからが本題です。
僕がよく使うのは、受け入れ条件を3層に分けて、順番に合意する型です。

層A：必須条件（Must）

これが落ちたらリリースしないライン。
例：ログインできる／注文完了できる／主要画面が表示される／データ不整合が起きない

ポイントは、機能要件の羅列にしないこと。
本番で事故る条件だけを、短く置く。

層B：品質条件（Quality Gate）

動くけど怖い、を潰すライン。
例：性能（何秒以内）／エラー率（何%以下）／監視・アラート（何が検知できる）／ロールバック（何分以内）

ここを置くと、運用・SRE・インフラ側の不安が減ります。
逆にここが無いと、運用は最後に止めたくなる。

層C：体験条件（Experience）

ユーザー部門の思ってたのと違う、を潰すライン。
例：入力項目が多すぎない／業務フローが成立する／現場の回避策が不要／1日の処理が詰まらない

体験条件は感覚になりやすいので、シナリオで固定するのがコツです。
つまり、誰が・いつ・何をして・成功とみなすか、を短い業務シナリオにします。

合意の順番が重要：仕様より先に基準を揃える

合意形成で失敗しやすい順番はこうです。

• 仕様を全部決める

• 作ってから、品質をどうするか揉める

おすすめは逆。まず基準です。

1. 受け入れ条件（Must / Quality Gate / Experience）を置く

2. その条件を満たすために、仕様を詰める

3. テストと検証を、その条件に合わせて設計する

この順番にすると、途中で仕様が揺れても、守るべきラインが残ります。結果として炎上しにくい。

そのまま使えるテンプレ

案件のキックオフか、要件定義の合意タイミングで、これを1ページで出します。

• Must（落ちたら延期）

  • 例：

• Quality Gate（怖さを潰す）

  • 性能：

  • 監視：

  • 障害時：ロールバック手順／所要時間：

• Experience（現場の納得）

  • 業務シナリオ1：誰が／いつ／何をして／成功条件は何か

  • 業務シナリオ2：

さらに、各項目にオーナーを振ります。
Mustは開発責任者、Quality Gateは運用責任者、Experienceは業務責任者。
オーナーがいない基準は、最後に誰も守れません。

Before / After（よくある揉め方を変える）

Before

ユーザー：なんか使いにくい
開発：要件通りです
運用：事故る気がする
PM：じゃあ追加テストします（期限は変えない）

これ、全員が正しい。だから揉める。

After

ユーザー：業務シナリオ2で処理が詰まる
開発：Experience条件の成功条件が未達。ここを直す
運用：Quality Gateの監視が不足。ここを追加
PM：Must/Quality Gate/Experienceのどれを満たせばGoか、合意済みなので決められる

揉めなくなる理由は単純で、争点が言語化されるからです。

1週間の最小実装

全部のプロジェクトを変える必要はありません。最小で十分です。

• 明日やる1つ：次の定例で、受け入れ条件3層をホワイトボードに書く（10分）

• 今週やる1つ：Experienceを業務シナリオ2本にする（各5行でOK）

• 来週やる1つ：Quality Gateのうち、監視とロールバックだけ先に確定する

これだけで、終盤の揉め方が変わります。

よくある失敗（逆噴射ポイント）

• 受け入れ条件を網羅リストにして重くする
  → Mustは絞る。多いと誰も読まない。

• ExperienceをUIの好みの話にする
  → 好みは割れる。業務シナリオで固定する。

• Quality Gateを後回しにする
  → 運用の不安が最後に爆発する。先に置く。

まとめ

品質で揉める現場は、品質が低いのではなく、品質の合意が無いだけ。
受け入れ条件を Must / Quality Gate / Experience の3層に分け、順番に合意する。
それが、PMが最後に燃えないための型です。

最後に問いを置きます。
あなたの現場で、今いちばん曖昧なまま残っている受け入れ条件は、Must / Quality Gate / Experience のどれですか？

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！

個別に整えたい人へ（キャリア相談）

僕は普段、30代エンジニアのキャリア停滞を抜け出す支援をしています。
現場の詰まりをほどいて、評価・役割・選択肢を整えるために、状況を一緒に棚卸しできます。

▼相談はこちら（ココナラ）：