プロジェクトの品質管理：品質計画・品質保証・品質コントロールを現場の手順に落とす

品質は最後にまとめて検査する工程ではない

品質を工程の最後に置く検査項目として扱う現場は珍しくありません。しかしPMBOKガイド第8版（2025年11月公開）は、これと異なる位置づけを示しています。第8版で6つに整理された原理・原則の1つが「品質をプロセスと成果物に組み込むこと」です（第8版の全体像はPMBOK第8版の変更点にまとめています）。品質は工程の末尾に置く検査項目ではなく、プロセスそのものに組み込む対象として、原理・原則のレベルで位置づけられています。

第8版の7つのパフォーマンス領域（ガバナンス・スコープ・スケジュール・ファイナンス・ステークホルダー・リソース・リスク）に、独立した「品質」領域は含まれていません。PMI日本支部が2026年6月に開催した勉強会のレポートでは、品質にかかわる計画がスコープのパフォーマンス領域に関連づけられていることが議論されています。要求事項を定義しなければ、何を満たせば品質基準を達成したことになるのかが決まらず、品質マネジメントが成立しないという理由からです。品質は独立した管理項目である前に、スコープを定義する作業と一体で決まるものだという整理です。

この考え方はPMBOKに限りません。スクラムの原典であるスクラムガイドも、スプリント実行中に守るべき原則の1つとして「品質は低下しない（Quality does not decrease）」を掲げています。そして完了の定義（Definition of Done）を「インクリメントが製品に求められる品質基準を満たした状態を、正式に記述したもの」と定義し、開発者はこの完了の定義に従うことで品質を作り込む責任（Instilling quality by adhering to a Definition of Done）を負うとしています。完了基準の運用そのものは進捗管理の実務手順で扱っているため、ここでは品質側から見た運用に絞ります。

以下では、品質マネジメントの実務で広く使われる3つの区分、品質計画（Plan Quality Management）、品質保証（Manage Quality）、品質コントロール（Control Quality）を骨格として使います。この3区分はPMBOKガイド第6版の知識エリア構成に基づくものです。第8版はプロセスを非規範的な参照情報として整理し直していますが、品質計画で合格基準を数値化し、品質保証でプロセスを監査し、品質コントロールで成果物を検査するという役割分担そのものは、現場の品質作り込みの手順として今も機能します。

品質計画：合格基準を作業着手前に数値で決める

品質計画の実務上の中心は、何を満たせば成果物が合格かという基準を、作業に着手する前に数値で決めておくことです。「操作がわかりやすいこと」ではなく「初めて使うユーザーが、5分のマニュアル閲覧後に主要3機能の操作を完了できること」。「エラーが出ないこと」ではなく「受入テストケース全件を実行し、重大度『高』の不具合が0件であること」。数値や具体的な条件に落とせない基準は、検査する人によって合否の判定が割れます。

アジャイル開発では、この合格基準はプロダクトバックログ項目ごとの受入基準として書かれ、スプリント終了時に完了の定義と照らして判定されます。ウォーターフォール型の開発では、WBS辞書に各ワークパッケージの完了条件として書き込む形になります。粒度は違っても、「作業に着手する前に、誰が見ても同じ判定にたどり着く基準を決めておく」という原則は共通です。

基準は、使う側・発注側が主体的に作成し合意するものだという点も押さえておく必要があります。作る側だけで決めた基準に、使う側が事後的に同意するだけの運用では、使う側が本来必要としている条件が抜け落ちるリスクがあります。ワークパッケージ単位で完了条件を書くWBS辞書の考え方と同じで、成果物ごとに「何を満たせば完成か」を、作る前に合意しておくことが品質計画の実務です。

品質保証（QA）と品質コントロール（QC）：プロセスを見るか、成果物を見るか

品質保証と品質コントロール（QA・QC）は、同じ「品質を守る」活動でも見ている対象が違います。品質保証は、品質基準や運用手順が適切に守られているかというプロセスの適切さを検査する活動です。品質コントロールは、できあがった成果物を合格基準と照らし合わせて検査する活動です。プロセスを見るか、成果物を見るかという軸で分けると実務に落としやすくなります。

品質コントロールで見つかった個々の不具合をその場で直すのは品質コントロールの役割です。これに対し、根本原因を掘り下げ、同種の不具合が別の成果物でも起きないようにプロセス自体を直すのが是正処置で、品質保証の役割にあたります。品質コントロールで集まった不具合データを分析し、この是正処置につなげる。「なぜこの種類の不具合が繰り返し起きるのか」というプロセス側の問いに答えて手を打つのが、品質保証の実務でとくに重要な部分です。

是正処置と対になるのが予防処置です。是正処置がすでに発生した不具合への事後対応であるのに対し、予防処置はまだ発生していないリスクに対して先回りで手を打つことを指します。「過去に同種の不具合が起きた」からレビュー観点を追加するのが是正処置、「この工程は経験の浅いメンバーが多く不具合が起きやすい」という予兆の段階でレビュー回数を増やすのが予防処置です。この計画・実行・確認・改善の回し方はPDCAサイクルの考え方そのものでもあります。

レビューを工程に組み込む：ツールのワークフローに落とす

品質コントロールを「テスト工程の最後にまとめて実施する」計画では、レビューが後工程に集中し、発見が遅れます。実務では、成果物ができあがった時点でその都度レビューを通す運用にするほうが、問題を早く見つけられます。この運用を機械的に回す方法の1つが、プロジェクト管理ツールのワークフローにレビュー専用のステータスを組み込むことです。

Jiraのワークフローは、作業がいまどの状態にあるかを表すステータスと、ステータス間を移動するためのトランジション（遷移）で構成されます。Atlassian公式ドキュメントは「Statuses: the steps in your team's process that describe the state of a task」「Transitions: usually, how a piece of work moves between statuses」と説明し、ある課題が2つのステータス間を移動するには対応するトランジションが存在しなければならないとしています。「未着手」から「完了」に一足飛びに動かすのではなく、その間に「レビュー中」というステータスを挟み、レビューが完了して初めて次のステータスへのトランジションを許可する設計にすれば、レビューを経ずに完了扱いになることを防げます。

コードを伴う成果物では、プルリクエストを使ったレビューが標準的な運用です。Bitbucketの公式ドキュメントでは、レビュー担当者を指定する方法として、リポジトリ管理者があらかじめ既定のレビュアー（Default Reviewers）を設定する方法と、変更されたファイルに応じて自動的にレビュアーを割り当てるCODEOWNERSファイルによる方法が説明されています。レビューが完了すると担当者が承認（Approve）し、Premiumプランでは一定数の承認がないプルリクエストのマージを禁止する設定も可能です。承認前提のワークフローを設定すれば、「レビューをうっかり飛ばした」という人的ミスをツール側の制約で防げます。

こうした設定は、品質計画の段階で決めた合格基準と対にして使うと効果が上がります。何を満たせば合格かが数値で決まっていないまま承認フローだけを整えても、レビュー担当者が何を見ればよいかが定まらず、承認が形骸化します。

品質管理表に書く項目

品質計画・品質保証・品質コントロールの3つを1つの文書につなげるのが品質管理表です。基準の識別（対象成果物、品質基準ID、合格基準の内容）、検査計画（レビュー・検査のタイミング、実施者、合否判定基準）、結果の記録（実施日、結果、発見した不具合の内容）、是正処置の追跡（根本原因、対応した是正処置、再検査の結果）の4区分で構成します。

効果を左右するのは、検査のタイミングを成果物ごとに個別に決めておくことです。「テスト工程でまとめて見る」という一括りの計画では、コストの高い後工程に検査が集中します。ワークパッケージ単位で完了基準を書くWBSの考え方と同じで、成果物ごとに「いつ、何を、誰が確認するか」を先に割り振っておくことが、レビューを分散させる方法です。

現場で繰り返される5つの失敗

第1は、合格基準を数値化しないまま検査に入ることです。「使いやすいこと」のような主観的な基準のままレビューを始めると、担当者によって合否が割れ、同じ指摘が何度も蒸し返されます。基準を数値に落とす作業は、品質計画の段階で終わらせておく必要があります。

第2は、品質保証と品質コントロールを区別しないことです。成果物の不具合をその場で直すだけで終わり、「なぜ繰り返し起きるのか」というプロセス側の問いに答える工程が抜け落ちます。個々の不具合対応と、プロセスの是正は別の作業として扱う必要があります。

第3は、レビューをテスト工程の最後にまとめて置くことです。発見が遅れるほど、直すべき範囲は広がります。成果物ができた時点でその都度レビューを通す設計に変えることが対策になります。

第4は、ツールのワークフローがレビューを経ずに完了扱いにできる設計のままになっていることです。ステータスやトランジションでレビューを必須にしていないと、忙しい局面で最初に飛ばされるのがレビューになります。

第5は、是正処置を個々の不具合対応で終わらせ、プロセス改善につなげないことです。同じ原因の不具合が別の成果物で再発していないかを横断で確認する仕組みがないと、品質保証が形だけの検査になります。

まとめ：合格基準・検査・プロセス改善をひとつなぎにする

WBSで成果物とその完了条件を洗い出し、資源管理で誰がいつ作業するかを割り当て、進捗管理で完了基準への到達を追う。品質管理はこの流れに、「何を満たせば合格か」という基準と、「基準を満たしているかをいつ・誰が確認するか」という検査の仕組みを足す役割を担います。

合格基準を数値で決め、レビューをツールのワークフローに組み込み、見つかった不具合をプロセス改善につなげる。この3つを1つの流れとしてつなげることが、手戻りを早期に抑える実務の骨格になります。リスク管理で「まだ起きていない問題」に備え、品質管理で「作業のたびに合否を判定する」体制を作れば、プロジェクト実務の骨格はひととおり揃います。