「品質管理をやってほしい」と言われたものの、具体的に何をすればいいのかわからない。
プロジェクトの品質を守るのが大事なのはわかっている。でも、
- テストの話は開発チームの領域だし…
- レビューはやっているけど、それが品質管理なのか…？
- そもそも「品質」って何を指しているのかが曖昧…
こんな状態のまま、なんとなくプロジェクトが進んでいる。そんなPMも多いのではないでしょうか。
さらに厄介なのは、品質の問題は「低すぎる」だけではないということです。品質が高すぎる、つまり過剰品質もまた、プロジェクトにとっては問題になります。
品質が低ければ手戻りが発生し、品質が高すぎれば工数とコストが膨れる。どちらに転んでもQCDに影響が出ます。
では、なぜこうした問題が起きるのか。多くの場合、その原因は次の2つが整理されていないことにあります。
- 品質の定義が決まっていない
- 品質を守るための 仕組みがない
この記事では、事業PMの視点から、品質管理の考え方と具体的にやるべきことを解説します。
この記事でわかること
- 品質管理の本当の目的
- 品質管理で何を管理するのか
- 品質を守るための具体的な2ステップ
品質管理とは「品質を守るための管理」
そもそも、品質管理って何のためにやるのでしょうか？
「品質を高めるため」と思うかもしれません。しかし、品質管理の目的は品質を高めることではないのです。
品質を高めるのは、要件定義や設計といった上流工程の役割です。要件をきちんと定義し、設計で作り込むからこそ、品質の高いシステムやドキュメントが生まれます。
では、品質管理は何をするのか。
品質管理の目的は、 作り込んだ品質を守ること です。
もう少し噛み砕くと、品質管理でPMがやることは大きく2つです。
- 品質の定義をする — 「何をもって品質OKとするか」の基準を作る
- 仕組みを作る — レビューやチェックポイントなど、品質を守るための仕掛けを用意する
基準がなければ、品質が良いのか悪いのか判断できません。仕組みがなければ、品質の問題に気づけません。
この2つを揃えることで、品質は「なんとなく」ではなく「意図的に」守れる状態になります。
品質管理では何を管理するのか？
品質管理の目的がわかったところで、次は「何を管理するのか」を整理します。
プロジェクトにおいて、品質を管理する対象は大きく2つです。
- ドキュメント — 要件定義書、設計書、テストケースなどの成果物
- システム — ソースコードと、最終的に動くシステム
それぞれ、品質を確認する手段が異なります。
ドキュメントの品質 → レビューで確認する
ドキュメントの品質は、レビューを通して確認します。
要件定義書であれば「業務フローとの整合が取れているか」「要件に抜け漏れがないか」。設計書であれば「要件を満たす設計になっているか」。こういった観点でレビューすることで、ドキュメントの品質を確認していきます。
システムの品質 → テストで確認する
一方、システムの品質はテストを通して確認します。
単体テスト、結合テスト、総合テストなど、段階ごとにテストを実施し、要件を満たしているかどうかを検証していきます。
つまり、品質管理においてPMが意識するのは、この2つの管理対象に対して、品質の基準を定義し、それを確認するための仕組みを作ることです。
ここからは、その具体的なやり方を2つのSTEPで解説します。
STEP1：品質の定義・基準を作る
このSTEPでやること
・ドキュメントとシステムそれぞれの品質基準を定義する
品質管理の第一歩は、「何をもって品質が良い・悪いと判断するのか」を言語化することです。
基準がなければ、品質の判断は人によってバラバラになります。ある人は「十分だ」と思い、別の人は「足りない」と感じる。この状態では、低品質も過剰品質も防げません。
だからこそ、まず品質の基準を言語化し、関係者で合意しておくことが重要です。
ドキュメントの品質基準
ドキュメントの品質基準は、着手前に「どういう状態であればOKか」を決めることがポイントです。
そして、作業者とレビュアーの間で、このゴールを共有しておきます。ゴールが共有されていないと、作業者は「ここまでやればいいだろう」と思って作り、レビュアーは「全然足りない」と感じる。こうしたギャップが手戻りの原因になります。
具体的には、成果物ごとにレビュー観点を事前に決めておきます。
要件定義書の場合：
- 業務フローとの整合性が取れているか
- 要件に抜け漏れがないか（課題・対応方針を網羅しているか）
- 見積・設計のインプットとして十分な粒度か
- 用語・表記が統一されているか
設計書の場合：
- 要件定義書の内容を満たす設計になっているか
- 処理フローに論理的な矛盾がないか
- 例外処理・エラーケースが考慮されているか
- 他システムとの連携仕様が明記されているか
このように、成果物ごとに「何を確認すれば品質OKと言えるか」をリスト化しておくことで、レビューの観点がブレなくなります。
事後的な基準としては、「レビューを通過していること」がドキュメントの品質基準になります。つまり、上記の観点でレビューされ、指摘事項が解消された状態 ＝ 品質OK です。
具体例：成果物が曖昧なときの品質基準の作り方
ここで、実際のプロジェクトで品質基準を作った事例を紹介します。
コンテンツ制作系システムの改修プロジェクトで、要件定義をさらにIT観点で具体化する「IT要件定義」フェーズをベンダーに依頼したときの話です。
IT要件定義は、成果物の形が事前に明確ではありません。要件定義書のように「こういう項目を埋めればOK」というテンプレートが決まっているわけではなく、成果物自体が曖昧になりがちです。成果物が曖昧だと、品質の定義もしづらくなります。
まず、基本的な品質基準として次のような観点を提示しました。
- 要件内容に漏れがないこと
- 設計のインプットとして十分な粒度であること
しかし、これだけでは「十分な粒度」の認識が揃いません。そこで行ったのが、最初の成果物を完成度20%の段階で一度レビューする という方法です。
具体的には、最初の1つ目の成果物が20%ほど出来上がった段階で、構成と内容の書きっぷりについてレビューを実施しました。「このレベル感・この構成で進めてよいか」を双方で確認し、合意します。
つまり、実際の成果物そのものを品質の基準値として使ったのです。
成果物が曖昧な場合の品質基準の作り方
- まず基本的な品質観点を提示する（漏れがないこと、後工程のインプットとして十分であること）
- 最初の成果物を完成度20%でレビューし、構成・粒度の認識を合わせる
- そのレビュー結果を基準値として、残りの成果物を作成する
テンプレートが決まっている成果物であれば、レビュー観点を事前にリスト化すれば十分です。しかし、成果物自体が曖昧な場合は、このように実物を使って基準を擦り合わせるアプローチが有効です。
システムの品質基準
システムの品質基準は、要件を満たしていること が基本です。
要件定義で定義した要件が、システムとして正しく実装されているかどうか。これがシステム品質の判断基準になります。
事後的な基準としては、「テストを通過していること」です。テストケースが要件をカバーしており、そのテストをすべて通過していれば、品質基準を満たしていると判断できます。
ここで注意したいのは、テストケースの品質です。テストケースが要件をカバーしていなければ、テストを通過しても品質を保証したことにはなりません。テストケース自体のレビューも、品質管理の重要なポイントです。
STEP2：品質を守る仕組みを作る
このSTEPでやること
・レビューをWBSに組み込む
・品質チェックポイントを設ける
・テスト計画の位置づけを理解する
STEP1で品質の基準を作りました。しかし、基準だけ作っても、それを使う仕組みがなければ意味がありません。
品質基準を「絵に描いた餅」にしないために、仕組みとしてプロジェクトに組み込んでいきます。
① レビューを仕組みとして組み込む
レビューは、ドキュメントの品質を確認するための最も基本的な手段です。
しかし、「レビューやっておいて」と口頭で依頼するだけでは、形骸化しやすい。忙しくなると後回しにされ、結局レビューなしで次の工程に進んでしまう。こうした事態を防ぐために、レビューをWBSのタスクとして明示的に組み込みます。
ポイントは、レビュータスクを入れるだけでなく、誰が・いつ・どの観点でレビューするかを事前に決めておくことです。
レビューを仕組み化するために決めておくこと
- 誰がレビューするのか（レビュアーの指名）
- いつレビューするのか（WBS上のタイミング）
- どの観点でレビューするのか（STEP1で作った品質基準を使う）
STEP1で作った品質基準は、ここで活きてきます。レビュー観点として品質基準を使うことで、「何をチェックすればいいか」が明確になり、レビューの質も安定します。
STEP1で紹介したコンテンツ制作系システム改修のプロジェクトでは、IT要件定義の成果物ごとにレビュータスクをWBSに組み込みました。成果物が複数あったため、「成果物Aの作成 → 成果物Aのレビュー → 成果物Bの作成 → 成果物Bのレビュー」という形で、作成とレビューをセットにしてWBSに並べています。
こうすることで、レビューが「空いた時間にやる」ものではなく、WBS上で工数と期間が確保されたタスクとして扱われます。レビュー観点にはSTEP1で定義した品質基準を使い、20%レビューで合意した粒度・構成が各成果物で維持されているかを確認しました。
② 品質チェックポイントを設ける
レビューは個々の成果物に対するチェックですが、もう一つ、プロジェクト全体の流れの中に「品質チェックポイント」を設けることが重要です。
品質チェックポイントとは、フェーズの区切りで「次に進んでよいか」を判定するタイミングのことです。
例えば、次のようなタイミングです。
- 要件定義 → 設計に進む前
- 設計 → 開発に進む前
- 開発 → テストに進む前
各チェックポイントで、「前工程の成果物がSTEP1で定義した品質基準を満たしているか」を確認します。基準を満たしていなければ、次の工程には進まない。
前工程の成果物が中途半端なまま次に進むと、手戻りのコストは後工程になるほど大きくなります。要件定義の不備が設計で見つかればまだ軽傷ですが、テストフェーズで発覚すると影響範囲は一気に広がります。
品質チェックポイントは、PMが品質を「守る」ための最も重要な仕掛けです。成果物の品質を確認してからゲートを開ける。この仕組みがあるだけで、プロジェクトの安定感は大きく変わります。
なお、チェックポイントは工程の区切りだけとは限りません。STEP1の具体例で紹介した「完成度20%でのレビュー」も、品質チェックポイントの一つです。
工程が始まってすぐの段階で、成果物の方向性や粒度を確認する。これにより、工程の終盤になってから「思っていたのと違う」という手戻りを防げます。
先ほどのコンテンツ制作系システム改修のプロジェクトでは、この2種類のチェックポイントを両方設けました。
- 工程の序盤：最初の成果物が20%出来た段階で方向性レビューを実施。構成・粒度の認識を合わせた
- 工程の区切り：IT要件定義フェーズの完了時に、全成果物が品質基準を満たしているかを確認。設計フェーズに進んでよいかをゲート判定した
品質チェックポイントの置き方
- 工程の序盤：成果物が20%ほど出来た段階での方向性レビュー（早期の軌道修正）
- 工程の区切り：要件定義→設計、設計→開発など、次の工程に進む前のゲート判定
③ テスト計画の作成
システムの品質を守るためには、テスト計画を立てることも重要です。
テスト計画では、テストの種類（単体テスト・結合テスト・総合テストなど）、テストの実施時期、合格基準などを事前に定義しておきます。
テスト計画の詳細な立て方は本記事のスコープ外ですが、品質管理の文脈で押さえておきたいポイントは次の通りです。
- テスト計画は 開発着手前に立てる（テストフェーズに入ってからでは遅い）
- 各テストがどこまでの品質を保証するか決めておく
- テストの合格基準を 事前に定義しておく
テスト計画も、品質を守るための仕組みの一つです。開発チームやベンダーと協力しながら、プロジェクトの早い段階で計画しておきましょう。
実体験：品質基準がないと「過剰品質」が起きる
品質管理の話をすると、多くの人が「品質が低い」ことをイメージします。不具合が多い、要件を満たしていない、手戻りが発生する。こうした問題です。
しかし、品質の問題はそれだけではありません。実際に経験したのは、品質が高すぎる という問題でした。
あるプロジェクトで、メンバーに調査タスクを依頼しました。調査の概要は指定しましたが、アウトプットの形式や内容の粒度までは決めていませんでした。
その結果、出来上がったのは想定をはるかに超えるリッチな調査資料でした。図解も入り、網羅性も高く、資料としての完成度は非常に高かった。
しかし、その分だけ工数も膨れていました。
求めていたのは「判断に必要な情報が整理されていること」であって、完璧な調査レポートではありませんでした。品質（Q）は過剰に満たされましたが、コスト（C）と納期（D）を失ったのです。
品質基準がないと、低品質だけでなく過剰品質も起きる。どちらもQCDのバランスを崩す原因になります。
この経験から学んだのは、品質の基準を事前に定義し、関係者で合意しておくことの重要さです。「ここまでやればOK」というラインが明確であれば、作業者は迷わず、過剰に作り込むこともありません。
これはまさに、STEP1で解説した「品質の定義・基準を作る」ことの実践例です。品質基準は、品質を上げるためではなく、適正な品質を守るために必要なものなのです。
まとめ
品質管理とは、品質を高めるための管理ではありません。
品質管理の目的は、 作り込んだ品質を守ること です。
そのためにPMがやることは、次の2つです。
- 品質の定義・基準を作る — 何をもって品質OKとするかを言語化し、関係者で合意する
- 品質を守る仕組みを作る — レビューの仕組み化、品質チェックポイントの設置、テスト計画
品質の基準がなければ、品質が良いのか悪いのか判断できません。仕組みがなければ、品質の問題に気づけません。
そして、品質基準は「品質を上げるため」ではなく、「適正な品質を守るため」に必要です。低品質だけでなく、過剰品質もまた、QCDのバランスを崩す原因になります。
品質管理は地味な管理です。進捗管理や課題管理に比べると、成果が見えにくい。でも、品質の問題はプロジェクトの後半になるほどインパクトが大きくなります。
だからこそ、プロジェクトの早い段階で品質の基準と仕組みを整えておく。それが、PMとして品質を守るための第一歩です。
まずは次のプロジェクトで、最初の成果物が20%できた段階でレビューを入れてみてください。それだけでも、品質の守り方が変わるはずです。
おまけ：NGパターン
最後に、品質管理でありがちなNGパターンを紹介します。当てはまっていないか、確認してみてください。
NG① 品質の定義がない
何をもって品質が良い・悪いと判断するかの基準がない状態です。
基準がないと、次の2つの問題が起きます。
- 低品質：品質が足りていないことに気づけず、後工程で手戻りが発生する
- 過剰品質：必要以上に作り込み、工数とコストが膨れる
特に上流工程では、過剰品質のリスクにも注意が必要です。開発フェーズであれば設計どおりに作ればよいので品質の判断はしやすい。しかし、要件定義や調査など「正解がない作業」では、基準がないと作り込みすぎるリスクが出てきます。
成果物ごとに「どういう状態であればOKか」を言語化し、作業者とレビュアーで合意しておくことが対策です。
NG② レビューをしない
ベンダーや開発チームに任せきりにしてしまい、成果物のレビューをしないケースです。
- 設計書をレビューせずに開発に進む
- テストケースをレビューせずにテストを実施する
その結果、開発やテストのフェーズになってから品質の低さに気づく。この段階での手戻りは、上流で対処するよりもはるかにコストがかかります。
レビューは「やったほうがいい」ものではなく、品質を守るための仕組みの一部です。WBSにタスクとして組み込み、必ず実施する。上流でのレビューを丁寧に行うことが、プロジェクト全体の品質を守ることにつながります。
レビューは後工程での手戻りを防ぐための投資です。上流でレビューに使う工数は、後工程での修正コストに比べればはるかに小さいものです。
関連記事