品質管理の基本：PMが知っておくべきレビューと検収の型

読了時間：約7分

「テストが終わってリリースしたら、すぐにバグ報告が大量に来た」——これはPMが品質管理を「テストチームに任せること」だと思っているときに起きやすい失敗です。品質管理はテスト工程だけのことではなく、計画段階から受け入れ完了まで全工程を通じた活動です。この記事では、PMが押さえるべき品質管理の基本を解説します。

この記事の結論 品質管理の本質は「作り終わってからチェックする」ではなく「作り方を設計する段階から品質を作り込む」こと。レビューの種類・受け入れ基準・バグトラッキングの3点を整備しておくことで、リリース後の品質問題を大幅に減らせる。AIは大量のチェックリスト確認・テストケース生成の補助として特に効果を発揮する。

品質計画とは

品質計画とは、「このプロジェクトで何をもって品質が確保されたと判断するか」を事前に定義する活動です。

品質計画で決める3点：

品質基準：何を満たせば「合格」とするか（バグ件数の上限、応答速度、など）
レビュー・検査の種類と実施タイミング：いつ・誰が・何をチェックするか
不合格時の対応フロー：問題が発見されたらどう処理するか

品質計画を立てずにプロジェクトを進めると、「リリース直前になって品質基準が人によって違う」という事態が起きます。特に顧客との検収では「自分たちはOKだと思っていたが顧客がNGと言う」というトラブルが頻発します。

リスク管理の基本と合わせて読むと、品質問題の発生リスクを早期に特定する方法も理解できます。

検査・レビューの種類

プロジェクトで実施するレビューには複数の種類があります。それぞれの目的と実施タイミングを把握しておくことが大切です。

レビューの種類	目的	実施タイミング
要件レビュー	要件の抜け漏れ・矛盾を発見	要件定義完了時
設計レビュー	設計内容の妥当性・実現可能性を確認	設計書完成時
コードレビュー	実装の品質・セキュリティ・保守性を確認	開発中・PR提出時
単体テスト	個々の機能が仕様通りに動作するかを確認	開発中
結合テスト	機能間の連携が正しく動作するかを確認	全機能開発後
受け入れテスト（UAT）	顧客・利用者の視点で要件を満たすかを確認	リリース前

PMが特に意識すべきは要件レビューです。ここで発見できなかった問題は、後工程に行くほど修正コストが指数関数的に増大します。「設計段階で気づけばよかった」は、要件レビューを省略したときに起きるセリフです。

受け入れ基準の設定方法

受け入れ基準（Acceptance Criteria）とは、「この条件を満たせば成果物として受け入れる」という合格ラインです。曖昧な基準は必ずトラブルの原因になります。

良い受け入れ基準の書き方

受け入れ基準は、誰が読んでも同じ解釈ができるように具体的に書くことが大切です。

NG例（曖昧）

・動作が速いこと
・使いやすいこと
・バグがないこと

OK例（具体的）

・トップページの表示速度が3秒以内であること（Google PageSpeed Insightsで計測）
・スマートフォン（iOS・Android最新2バージョン）で正常に表示されること
・Critical/Highのバグが0件であること（Medium以下は別途合意）
・お問い合わせフォームから送信した内容が担当者のメールに届くこと

受け入れ基準テンプレート

【受け入れ基準】
プロジェクト名：〔プロジェクト名〕
合意日：〇月〇日
合意者：〔顧客名〕・〔PM名〕

■ 機能要件
□ 〔機能名〕：〔具体的な動作条件〕
□ 〔機能名〕：〔具体的な動作条件〕

■ 非機能要件
□ 表示速度：〔ページ・条件・目標値〕
□ 対応ブラウザ：〔Chrome・Safari・Edge・バージョン〕
□ 対応デバイス：〔PC・スマホ・タブレット〕

■ バグの合格基準
・Critical（サービス停止レベル）：0件
・High（主要機能に影響）：0件
・Medium（軽微な動作不良）：〇件以下
・Low（表示崩れなど）：次バージョン対応を許容

■ 検収プロセス
1. 我々がテスト完了後に検収用環境を提供
2. 顧客による確認期間：〇営業日
3. 指摘事項の修正後、再確認
4. 最終合格の判断：顧客〔担当者名〕

バグ・不具合トラッキングの基本

バグ管理で重要なのは、発見したバグを「いつ・誰が・どうするか」まで一元管理することです。口頭やSlackだけでバグを共有していると、修正漏れや対応状況の把握が困難になります。

バグ票の最低限の記載事項

項目	内容
バグID	管理番号（連番）
タイトル	問題の概要（1行で）
再現手順	どうやれば発生するか（箇条書きで）
期待動作	本来どうなるべきか
実際の動作	実際に何が起きているか
優先度	Critical / High / Medium / Low
担当者	修正する人
期限	いつまでに修正するか
ステータス	未対応 / 対応中 / 修正済み / 確認待ち / クローズ

優先度の判断基準

優先度	基準	対応期限の目安
Critical	サービスが使えない・データが失われる	即日対応
High	主要機能が正しく動かない	翌営業日まで
Medium	機能は動くが期待通りではない	次のスプリント・リリースまで
Low	軽微な表示崩れ・改善要望	余裕があれば対応

AI活用による品質チェックの効率化

AIはテストケースの生成・チェックリスト作成・バグ説明文の整理で特に効果を発揮します。

テストケース生成のプロンプト例

以下の機能に対して、テストケースを一覧形式で作成してください。

【機能概要】
ユーザーがメールアドレスとパスワードでログインする機能

【テストの観点】
・正常系（正しいIDとパスワードでログインできる）
・異常系（誤ったパスワード、存在しないID、空欄など）
・境界値（パスワードの文字数制限など）
・セキュリティ（連続ログイン失敗時のロックアウト）

【出力形式】
テストID / テスト内容 / 入力値 / 期待結果 の表形式で出力してください。

受け入れテスト観点の洗い出しプロンプト例

以下のWebサービスの受け入れテストで確認すべき観点を、
機能要件・非機能要件・セキュリティ・UXの4カテゴリに分けてリストアップしてください。

【サービス概要】
中小企業向けの勤怠管理SaaS
主な機能：出退勤打刻・残業申請・月次集計・CSV出力

【利用環境】
PC（Windows/Mac）・スマートフォン（iOS/Android）
ユーザー：社員全員（最大100名）・管理者2名

AIが出したチェックリストを土台に、プロジェクト固有の要件を追加・削除して完成させます。ゼロから考えるより抜け漏れが少なく、時間も大幅に短縮できます。

まとめ

品質計画は作り始める前に立てる：何をもって合格とするかを事前に定義し、顧客と合意しておく
レビューの種類とタイミングを設計する：要件・設計・コード・テスト・受け入れ——それぞれのレビューが持つ目的を理解して実施する
受け入れ基準は数値で書く：「使いやすい」ではなく「〇秒以内」「バグ0件」のように誰でも同じ解釈ができる形式にする
バグはツールで一元管理する：Notionでも Jiraでも何でも良いが、再現手順・優先度・担当者・期限を必ず記載する
AIでテストケースと観点を生成する：出力を叩き台として人間が精査する使い方が効果的で、抜け漏れも減らせる