目次
はじめに
「品質マネジメント」と聞くと、「最後にしっかり検査すればいいんでしょ？」「テストで不具合を見つければ大丈夫なのでは？」と感じている方も多いかもしれません。
たしかにテストは大切です。ただ、プロジェクトの現場では、テストをする頃には、すでに結果がほぼ決まってしまっていることも少なくありません。たとえば、最初の打ち合わせで「どこまで作るのか」「何をもって完成とするのか」をはっきりさせないまま作業を始めてしまうと、完成直前になってから「思っていたものと違う」と言われてしまうことがあります。その結果、画面を作り直したり、仕様を追加したりして、時間も費用も余分にかかってしまいます。
「なぜこんなことが起きるの？」と感じたら、まず振り返ってほしいのは、作業を始める前にどこまで決めていたか、という点です。品質は、最後の検査だけで守るものではありません。プロジェクトを始める前の段階で、「何を作るのか」「どんな状態なら合格なのか」「誰がどこまで確認するのか」を具体的に決めておくかどうかが、そのまま結果につながります。
この記事では、品質マネジメントを「テストの話」だけで終わらせず、計画段階で何を決めておけばよいのかを、順番にわかりやすくお伝えしていきます。まずは、品質が後半ではなく“最初”に左右される理由から、一緒に整理していきましょう。
品質マネジメントとは？
品質マネジメントとは、成果物の出来ばえを「なんとなく良い・悪い」で判断するのではなく、あらかじめ決めた基準に沿って管理することです。最初に合格ラインを具体的に決め、その基準どおりに進んでいるかを確認し、基準から外れた場合は修正できる状態にしておく必要があります。ここでは、品質マネジメントで実際に行う3つの行動を順番に整理します。
品質基準を事前に決めること
品質基準を事前に決めるとは、「これができていれば合格」と言える状態を具体的な数値や条件で先に決めておくことです。たとえば、Webサイト制作なら「トップページの表示速度は3秒以内」「スマートフォン表示で文字がはみ出さない」「問い合わせフォームは送信後に自動返信メールが届く」など、確認できる形で決めます。
システム開発なら「同時に100人がアクセスしてもエラーが出ない」「入力ミス時は指定のエラーメッセージを表示する」といった条件を要件書に記載します。完成後に感覚で判断するのではなく、着手前に数値・動作・範囲を文章で明確にしておくことが品質マネジメントの出発点です。
決めた基準どおりに進んでいるか確認すること
決めた基準どおりに進んでいるか確認するとは、作業の途中で実物や数値を基準と照らし合わせてチェックすることです。たとえば「表示速度3秒以内」と決めたなら、開発途中の段階で実際に計測ツールを使って秒数を測ります。「誤字ゼロ」と決めたなら、公開前にチェックリストを使って全ページを目視確認します。
「テスト項目20件すべて合格」と決めたなら、テスト結果表に○×を記録します。会議で「大丈夫そう」と言うだけでは確認になりません。画面、数値、テスト結果など、実際の成果物を使って基準と一致しているかを一つずつ確かめることが必要です。
ずれが出たときに修正する仕組みを持つこと
ずれが出たときに修正する仕組みを持つとは、基準と違う結果が出た場合に「誰が・いつまでに・どう直すか」を決めておくことです。たとえば、表示速度が3秒を超えた場合は開発担当が2営業日以内に原因を調査し、画像圧縮やコード修正を行うと決めます。テストで不合格になった項目は、不具合管理表に登録し、修正後に再テストを実施して合格になるまで完了扱いにしません。
変更が発生した場合は、口頭で済ませず変更履歴に記録し、関係者に共有します。このように、基準から外れたときの対応手順と記録方法を事前に決めておくことが、品質マネジメントの一部です。
プロジェクトで品質トラブルが起きるのはなぜ？
プロジェクトで品質トラブルが起きる原因は、特別なミスではなく、最初の決め方や確認方法にあります。完成の基準があいまいなまま進めたり、やり取りを口頭だけで済ませたりすると、認識のずれが積み重なります。また、変更内容や確認のタイミングが整理されていないと、気づいたときには手戻りが発生します。ここでは、実際によくある原因を具体的に整理します。
完成の基準が数値で決まっていない
完成の基準が数値で決まっていないと、「どこまでできれば完了か」が人によって変わります。たとえば「早く表示されること」「使いやすいこと」とだけ書かれている場合、ある担当者は5秒表示でも問題ないと考え、別の担当者は2秒以内でないと不十分だと判断します。
テスト項目も「だいたい動く」で終わらせてしまい、不具合が残ったまま公開されることがあります。合格ラインを「表示速度3秒以内」「テスト20項目すべて合格」「誤字脱字ゼロ」のように数値や件数で決めていないと、完成確認の段階で認識がずれ、やり直しやクレームにつながります。
口頭確認だけで作業が進んでいる
口頭確認だけで作業が進んでいると、言った内容と実際に作られた内容が一致しないまま進みます。たとえば打ち合わせで「デザインは前回と同じで少しシンプルに」と伝えただけでは、色を変えるのか、余白を広げるのか、文字サイズを小さくするのかが人によって解釈が分かれます。その場では「分かりました」と返事があっても、議事録や仕様書に残していなければ後から確認できません。
数日後に成果物を見て「思っていたのと違う」となり、修正作業が発生します。決定内容を文書やチャットに残さず、作業指示を口頭だけで済ませることが品質トラブルの原因になります。
変更内容が文書に反映されていない
変更内容が文書に反映されていないと、最新の前提で作業している人と、古い前提のまま作業している人が同時に存在します。たとえば「トップページにバナーを1枚追加する」と打ち合わせで決めたのに、仕様書や要件定義書を修正していなければ、デザイナーは追加前のレイアウトで制作を進めます。
テスト担当も古い仕様書を見て確認するため、追加バナーの表示不具合に気づきません。変更が発生したら、該当箇所の文書を修正し、更新日と変更内容を明記し、関係者に共有する必要があります。文書が更新されていない状態で進むことが、手戻りや抜け漏れの原因になります。
途中確認のタイミングが最初から組まれていない
途中確認のタイミングが最初から組まれていないと、完成直前まで問題に気づけません。たとえば、デザイン制作を2週間で行う計画なのに、途中レビュー日を設定していなければ、完成日まで誰も内容を確認しません。最終日に初めて画面を見て「レイアウトが違う」「ボタンの文言が想定と違う」となり、大幅な修正が発生します。
本来は「ラフ提出3日目」「デザイン確定7日目」「コーディング確認10日目」のように、日付を決めて確認機会を設定します。計画段階で確認日をスケジュールに入れていないことが、品質トラブルの原因になります。
プロジェクトの品質は何で決まる？
プロジェクトの品質は、担当者の感覚や経験だけで決まるものではありません。最初に決めた内容がどれだけ具体的か、そしてその内容を全員が同じ基準で確認できるかで結果は変わります。特に「どこまでできたら完成なのか」「どこまで対応するのか」を数値や条件で明確にしているかが分かれ目です。ここでは、品質を左右する具体的な5つの要素を整理します。
① 要件に入れた具体的な数値
要件に入れた具体的な数値とは、成果物の状態を測定できる形で決めておくことです。たとえば「ページ表示は3秒以内」「同時アクセス100人でもエラー率0％」「入力ミス時は0.5秒以内にエラーメッセージを表示する」「誤字脱字は0件」といった基準を要件定義書に明記します。数値が入っていれば、テスト時に計測して合否を判断できます。
反対に「使いやすい」「速い」「問題なく動く」といった表現だけでは、人によって基準が変わります。品質は担当者の感覚ではなく、要件に書いた数値で決まります。
②完成とする受入条件
完成とする受入条件とは、「この状態になったら発注者が完了と認める」という具体的な合格基準です。たとえば「テスト項目30件すべてに合格していること」「指定した5つの画面が実機で正常表示されること」「操作マニュアルPDFが納品物に含まれていること」など、確認できる条件を文書に書きます。受入テストの日程、確認方法、合否の判定基準も事前に決めます。
受入条件が決まっていないと、納品後に「ここも直してほしい」と追加要求が出ます。品質は、受入条件をどこまで具体的に決めているかで変わります。
③作業完了の定義
作業完了の定義とは、「この状態になったらその作業は終わり」と判断できる条件を具体的に決めることです。たとえば「コーディング完了」とするなら、ソースコードを書き終えただけでなく、「レビューで指摘ゼロ」「テスト環境で動作確認済み」「Gitに最新版を反映済み」まで含めるのかを決めます。
資料作成なら「原稿作成済み」ではなく、「上長確認済み」「誤字チェック完了」「指定フォーマットで保存済み」までを完了とする、と文書に書きます。完了の定義が決まっていないと、担当者ごとに「終わった」の基準が違い、品質にばらつきが出ます。
④対応する範囲と除外範囲
対応する範囲と除外範囲とは、「どこまでやるのか」と「どこからはやらないのか」を具体的に書いておくことです。たとえばWebサイト制作なら「トップページ＋下層5ページを制作対象とする」「写真撮影は含まない」「サーバー契約手続きは対象外」と明記します。システム開発なら「ログイン機能と管理画面までを実装する」「外部サービスとの連携は今回の範囲に含めない」と書きます。
除外範囲を書いていないと、後から「それも含まれていると思っていた」と言われ、追加作業になります。品質は、対応範囲と除外範囲を文書で明確にしているかで変わります。
⑤途中確認の基準と回数
途中確認の基準と回数とは、「いつ」「何を」「何回」確認するかを最初に決めておくことです。たとえば、1か月の開発期間なら「1週目に要件確認」「2週目に画面デザイン確認」「3週目にテスト実施」「4週目に最終確認」と日付を決めます。
確認内容も「表示速度を計測する」「テスト項目20件を実行する」「誤字脱字を全ページチェックする」と具体的に書きます。回数を決めていないと、完成直前まで確認せずに進みます。品質は、確認のタイミングと内容を計画段階で決めているかで変わります。
プロジェクトで品質を守るための具体的な動き
プロジェクトで品質を守るには、「気をつける」だけでは足りません。最初に基準を明確にし、途中で確認し、結果を記録し、ずれがあれば修正するという流れを実行する必要があります。どれか1つでも欠けると、後半でまとめて手戻りが発生します。ここでは、品質を守るために現場で実際に行う具体的な動きを順番に整理します。
品質の基準を最初に具体的に決める
品質の基準を最初に具体的に決めるとは、作業を始める前に「合格ライン」を数値や条件で書き出すことです。たとえばWeb制作なら「トップページの表示速度は3秒以内」「スマートフォンで横スクロールが発生しない」「問い合わせフォーム送信後に自動返信メールが1分以内に届く」と決めて要件書に記載します。
システム開発なら「同時アクセス100人でエラー率0％」「入力エラー時は指定メッセージを表示する」と明文化します。会議で口頭合意するだけでなく、文書に残し、関係者全員が同じ内容を確認できる状態にしてから作業を開始します。
作業の途中で基準と照らし合わせる
作業の途中で基準と照らし合わせるとは、完成を待たずに途中段階で実物を確認することです。たとえば「表示速度3秒以内」と決めているなら、開発途中の画面を実際に計測ツールで測ります。「テスト項目30件すべて合格」と決めているなら、機能ごとにテストを実行し、結果を一覧表に記録します。
「誤字ゼロ」と決めているなら、公開前ではなく原稿完成時点でチェックを行います。会議で「順調です」と報告するだけでは確認になりません。数値、画面、テスト結果を使って基準と一致しているかを途中で確認します。
確認結果を記録として残す
確認結果を記録として残すとは、チェックした内容と結果を文書や表に保存することです。たとえば、テストを実施した場合は「テスト項目番号」「実施日」「担当者名」「合否」「不具合内容」を一覧表に入力します。
表示速度を測定したなら、「計測日時」「計測ツール名」「測定結果（秒）」を記録します。口頭で「問題ありません」と伝えるだけでは、後から確認できません。記録を残しておけば、不具合が発生したときに原因を追えますし、誰がいつ確認したかも明確になります。品質を守るには、確認した事実を形に残します。
基準からずれた原因を特定して修正する
基準からずれた原因を特定して修正するとは、基準を満たしていない項目をそのままにせず、「なぜ起きたのか」を調べてから直すことです。たとえば表示速度が3秒を超えた場合、画像サイズが大きいのか、不要なスクリプトが多いのかを確認します。
テストで不合格になった機能は、不具合管理表に登録し、どの画面・どの操作でエラーが出るのかを記録します。原因が分かったら、担当者と期限を決めて修正し、修正後に再テストを実施します。合格になるまで完了扱いにしません。原因を調べずに場当たり的に直すと、同じ不具合が再発します。品質を守るには、原因特定と再確認までをセットで行います。
プロジェクトの品質は範囲（スコープ）・費用（コスト）・納期（スケジュール）とどうつながっている？
プロジェクトの品質は、単独で存在しているものではありません。決めた品質の基準は、対応する範囲、使う費用、守る納期にそのまま影響します。品質をあいまいにすれば作業範囲が広がり、条件を引き上げれば費用が増え、確認が遅れれば納期が延びます。ここでは、品質とスコープ・コスト・スケジュールがどのように結びついているのかを具体的に整理します。
品質の基準があいまいだと作業の範囲（スコープ）が広がる
品質の基準があいまいだと、「どこまで対応するのか」が決まらないため、作業の範囲が広がります。たとえば「使いやすいデザインにする」とだけ決めている場合、ボタンの色変更、レイアウト調整、アニメーション追加など、改善項目が次々に増えます。
最初はトップページのみの修正予定だったのに、下層ページやスマートフォン表示まで対象が広がることもあります。表示速度や対応画面数などを数値や件数で決めていないと、「ここも直したほうがよい」という追加作業が止まりません。品質基準を具体的に決めていないことが、スコープ拡大の原因になります。
品質の条件を上げると費用（コスト）が増える
品質の条件を上げると、追加の作業や確認が増えるため費用が増えます。たとえば「表示速度3秒以内」から「1秒以内」に変更すれば、高性能なサーバー契約や専門的なチューニング作業が必要になります。
「テスト項目20件」から「50件」に増やせば、テスト工数が増え、人件費が上がります。「デザインはテンプレート使用」から「完全オリジナル制作」に変更すれば、デザイナーの作業時間が増えます。品質条件を引き上げるたびに、作業時間・人員・設備費が増え、その分コストも増加します。
品質の確認が遅れると納期（スケジュール）が延びる
品質の確認が遅れると、不具合の発見も遅れます。たとえば1か月の開発期間で、途中確認を行わず最終週に初めてテストを実施した場合、画面表示の不具合や機能エラーがまとめて見つかります。
修正に3日、再テストに2日かかれば、その分だけ納期が後ろにずれます。もし修正箇所が複数の画面に影響していれば、関連部分の再確認も必要になり、さらに日数が増えます。本来は2週目や3週目に確認していれば小さな修正で済んだものが、後半に集中することでスケジュール全体が延びます。品質確認のタイミングを後回しにすることが、納期遅延の原因になります。
プロジェクトマネジメントの品質の考え方はPMBOKとどう違う？
プロジェクトマネジメントにおける品質の考え方は、理論と現場で少し扱い方が異なります。PMBOKでは品質を工程ごとに整理し、文書化や標準化を重視しますが、実際の現場では同時進行で進めたり、簡易な共有で対応したりする場面もあります。ここでは、PMBOKの整理方法と現場の進め方の違いを具体的に比べます。
PMBOKは品質計画・保証・管理に分けるが現場では同時に進む
PMBOKでは品質を「品質計画」「品質保証」「品質管理」の3つに分けて整理します。品質計画は基準を決める工程、品質保証はプロセスが守られているかを確認する工程、品質管理は成果物を検査する工程です。
一方、現場ではこれらを順番に分けて進めることは少なく、同時に行うことが多いです。たとえば、基準を決めながらチェック方法も決め、作業中にテストを実施し、その結果を見て基準を修正することがあります。理論上は工程を分けますが、実務では基準決定・確認・修正が並行して進みます。
PMBOKは文書化を重視するが現場では簡易な共有で進むことがある
PMBOKでは、品質計画書や品質チェックリスト、不具合管理表などを正式な文書として作成し、承認手続きを経て保管します。変更があれば文書を更新し、履歴を残します。一方、現場では必ずしも正式な書式で作らないことがあります。
たとえば、共有フォルダのスプレッドシートにテスト結果を入力したり、チャットツールに確認事項を記録したりします。小規模案件では、品質計画書を作らずに要件定義書の中に基準をまとめる場合もあります。理論では文書化を前提に管理しますが、現場では規模や期間に応じて簡易な方法で共有することがあります。
PMBOKは標準化を目指すが現場では案件ごとに調整する
PMBOKは、どのプロジェクトでも同じ手順で品質を管理できるように、標準化されたプロセスやテンプレートの使用を前提にしています。たとえば、品質計画書の様式、レビュー手順、不具合管理の流れを統一します。
一方、現場では案件ごとに条件が違うため、そのまま当てはめないことがあります。3か月の大規模開発では詳細なテスト計画書を作成しますが、2週間の小規模改修ではチェックリストのみで進めることがあります。チーム人数、予算、納期に応じて確認回数や記録方法を調整します。理論は共通ルールを示しますが、実務では案件規模に合わせて管理方法を変えます。
プロジェクトで品質マネジメントができると何が起きる？
プロジェクトで品質マネジメントが機能すると、結果に直接変化が出ます。完成後にやり直す作業が減り、想定外の費用が発生しにくくなり、関係者の認識のずれも小さくなります。これは精神論ではなく、基準を決めて確認し続けた結果として起きる変化です。ここでは、品質マネジメントができたときに現場で実際に起きる具体的な変化を整理します。
プロジェクトの手戻り作業が減る
品質マネジメントができていると、完成直前に大きな修正が発生しにくくなります。たとえば、途中で表示速度やテスト結果を確認していれば、公開前にまとめて不具合が見つかることはありません。
デザイン案もラフ段階で確認していれば、コーディング後に全面修正する必要がなくなります。要件・受入条件・完了定義を最初に決め、途中で確認していれば、作り直しは小さな修正で済みます。その結果、画面の作り直しや再テストの回数が減り、手戻り作業が少なくなります。
プロジェクトで予定外の追加費用が出にくくなる
品質マネジメントができていると、後からの大幅な修正や追加対応が減るため、予定外の費用が発生しにくくなります。たとえば、受入条件を事前に「テスト30項目すべて合格」と決めておけば、納品後に追加テストを求められる可能性が下がります。
対応範囲と除外範囲を明記していれば、「この機能も含まれていると思っていた」という追加開発が発生しにくくなります。途中で表示速度や不具合を確認していれば、公開後に緊急修正のための残業や追加人員を手配する必要も減ります。基準決定・途中確認・記録を行うことで、想定外の修正費や追加作業費が出にくくなります。
プロジェクトで関係者の認識のずれが起きにくくなる
品質マネジメントができていると、「どこまでできたら完成か」「何を確認するのか」が文書で共有されているため、関係者の認識がそろいます。たとえば、受入条件に「テスト30項目すべて合格」と書いてあれば、発注者も開発者も同じ基準で判断します。
対応範囲に「下層5ページまで制作」と明記していれば、追加ページの有無で意見が分かれません。確認結果を記録に残していれば、「そんな話は聞いていない」という行き違いも起きにくくなります。基準・範囲・確認方法を事前に決めて共有することで、解釈の違いが減ります。
まとめ｜品質は“最後に守るもの”ではなく“最初に決めるもの”
品質は、完成後にチェックして守るものではありません。プロジェクト開始前に「何をもって合格とするか」を数値や条件で決め、その基準に沿って途中確認を行い、ずれがあれば修正する流れを作ることが品質マネジメントです。
たとえば、表示速度を3秒以内と決める、テスト30項目すべて合格を受入条件にする、対応範囲と除外範囲を文書に明記する、といった具体的な決定が出発点になります。これらを決めずに進めると、完成直前に「思っていたものと違う」という問題が発生し、手戻りや追加費用、納期延長につながります。
品質はスコープ・コスト・スケジュールと直結しています。基準があいまいであれば範囲が広がり、条件を引き上げれば費用が増え、確認が遅れれば納期が延びます。逆に、基準を最初に明確にし、途中で確認し、記録を残し、原因を特定して修正する仕組みがあれば、大きなトラブルは防げます。
プロジェクトの品質は、担当者の経験や気合いで決まるものではありません。要件に書いた数値、受入条件、完了の定義、確認回数といった具体的な決定事項で決まります。だからこそ、品質は「最後に守るもの」ではなく「最初に決めるもの」です。この順番を守ることが、安定して成果を出すための前提になります。