「品質会議は毎月やっている。バグ票も件数も全部出ている。なのに、半年経っても同じ種類の不具合が再発し、客先からは『御社の品質管理はどうなっているのか』と問われる」。受託開発のPMや管理職から、こうした相談を受ける機会が増えています。
ルールを足せば足すほど現場のメンバーは疲弊し、テンプレートだけが増えていく。それでも会議は報告で終わり、是正にはつながらない。これは個人のサボりではなく、品質管理の「動かし方」が設計されていないことが原因です。
本記事では、受託案件の品質管理を最小コストで再起動するための、欠陥発見の流れ・是正判断・記録という3点に絞った運用ルールを解説します。新しい仕組みを買い足すのではなく、いま手元にあるバグ票と週次定例を、判断につながる形に組み直す視点をまとめました。
受託の品質管理が「形骸化」していく典型パターン
形骸化は、ある日突然起きるものではありません。プロジェクト立ち上げ時には機能していた仕組みが、納期圧力と人員入れ替えのなかで、少しずつ「報告のための作業」へ変質していきます。現場でよく見かける症状は次のようなものです。
- 品質会議が「先週のバグ件数報告」だけで終わり、是正の意思決定が行われない
- バグ傾向の把握がリーダーAさんの頭の中にしかなく、Aさんが抜けると誰も状況を語れない
- レビュー指摘票・テスト報告書・QA記録がそれぞれ別ツールに散らばり、振り返りで突き合わせられない
- 過去の不具合履歴がチケットに埋もれ、類似案件の立ち上げで毎回同じ落とし穴を踏む
- 「品質ルール集 v3.2」がSharePointにあるが、現場メンバーは存在を知らない
共通しているのは、「情報は集めているのに、判断と記録に使われていない」という状態です。逆に言えば、ルールを増やさなくても、判断と記録の流れさえ通れば、品質管理は再び動き出します。
なぜルールを増やすほど形骸化が進むのか
「品質が悪いからルールを足す」という対応は、現場でほぼ確実に逆効果になります。理由は3つあります。
第一に、ルールが増えると、現場は「全部のルールを守る」のではなく「どれかを諦める」という選択をします。優先順位が示されないルール集は、結局メンバーごとに守る範囲がバラつき、案件横断で品質を比較できなくなります。
第二に、ルールが多いほどレビューや会議の時間が取れなくなり、「報告のために資料を整えるだけ」の作業が膨らみます。資料が整えば整うほど、本来見るべき欠陥傾向や再発兆候が、表のフォーマットに埋もれて見えづらくなります。
第三に、ルールを足す側（PMOや品質管理部門）と、運用する側（現場PM）の責任分界が曖昧になりがちです。誰がそのルールに対する是正判断を下すのか決まっていないと、ルールはあっても「動かす人」がいない状態になります。
品質管理を立て直すときに最初にやるべきは、ルールを足すことではなく、ルールを「最小限の点」に絞って、運用の流れを整えることです。受託開発の現場では、その最小単位を「欠陥発見・是正判断・記録」の3点に置くと、無理なく動かせます。
最低限の3点運用：欠陥発見・是正判断・記録
3点運用は、品質管理の全体像を作り直すフレームではありません。今あるバグ票・レビュー指摘票・週次定例を、判断につながる形へ通すための「動線設計」です。ひとつずつ見ていきましょう。
1. 欠陥発見：誰が・どこで・どう拾うかを1ページに
最初の論点は、不具合や品質劣化のシグナルを、誰がどこで拾うかを明確にすることです。受託案件で形骸化しているチームほど、ここが「みんなで気を付ける」になっており、結果として誰も見ていません。
整理する観点はシンプルです。レビュー、単体テスト、結合テスト、受入、本番運用という5つの工程ごとに、「拾う人」「拾う対象」「票を起票する場所」を1行で書き出します。例えば次のような粒度で十分です。
- 設計レビューでは、リードSEが観点リストに沿って指摘票を起票
- 結合テストでは、QA担当がバグ票へ起票（再現手順と期待結果は必須）
- 受入テストでは、顧客窓口が受入記録票に記録し、PMが翌営業日中にバグ票へ転記
- 本番運用では、保守担当が障害票を起票し、案件PMが当日中に確認
これを案件キックオフ時に1ページにして共有するだけで、「どの段階で拾い損ねたか」を後から追えるようになります。3軸で傾向を読む詳しい手順は、バグ票を改善につなげる｜不具合傾向の3軸読みで品質を立て直すPM実務 にまとめてあります。
2. 是正判断：誰が・何を見て・いつまでに決めるか
形骸化したチームでもっとも欠けているのが、ここです。バグ票は集まっているのに、それを「次にどう動かすか」を決める場と人が定義されていません。
是正判断のルールは、最低でも次の3項目を決めます。
- 判断する場は、週次品質レビュー（30分）とリリース判定会議（マイルストーン時）
- 判断する人は、案件PMが第一次判断を行い、影響度Highは部門長へエスカレーション
- 判断の対象は、未解決の重大欠陥、再発兆候、品質ゲート逸脱、リリース可否
ここで大切なのは、「全部のバグについて判断しない」ことです。週次30分で扱えるのは、せいぜい5〜10件です。それ以外は現場の通常運用で消化し、レビューには判断が必要な案件だけを上げる、という線引きを最初に決めておきます。
リリース可否や受入基準で迷う場面が多いなら、受入基準とリリース延期を止める品質ゲート設計の実務 で扱っているゲート設計の考え方を、是正判断の場で参照できる形にしておくと議論が早く収束します。
3. 記録：誰が読むかを決めてから書く
3点目は記録です。ここでよく失敗するのは、「あとから読み返せるようにすべて残す」を目指してしまうことです。残す情報が多いほど、書く側のコストが上がり、読まれない記録が積み上がります。
記録は読み手から逆算します。受託案件で品質記録の主な読み手は、おおむね次の3者です。
- 次の案件PMは、類似案件の立ち上げ時に過去の落とし穴を1時間で確認したい
- 部門長や営業は、四半期の品質傾向と顧客対応履歴を10分でつかみたい
- 顧客は、不具合発生時の経緯と是正の根拠を客観的な事実として確認したい
この3者が「読むときに困らない」最低項目だけを、必須項目として固定します。バグ票なら「発生工程・原因区分・是正内容・再発有無」の4項目、リリース判定記録なら「未解決欠陥の件数と影響度・残課題の合意・判定者」の3項目で十分です。
形式が揃った記録が3か月分たまれば、次の品質会議で振り返りの議論が「印象論」から「事実ベース」に変わります。これだけでも、会議の質は明確に変わります。
3点運用を最初に動かすときの落とし穴
3点運用は理屈としては単純ですが、立ち上げ時にいくつかの落とし穴があります。受託案件の現場で実際によくつまずく場面を挙げておきます。
ひとつは、「全案件に一律で導入しよう」とすることです。案件規模もチーム文化も違うため、最初は1案件で2か月だけ走らせて、定着確認をしてから横展開する方が確実です。
もうひとつは、PMOが「3点運用ルール集 v1.0」を作ってしまうことです。これは典型的な逆効果で、せっかく最小化したはずの運用が、また文書のメンテナンス対象になってしまいます。テンプレートはスプレッドシート1枚に収まる粒度で、Wikiに置く程度に留めるのが無理がありません。
そして、是正判断の場（週次品質レビュー）から先に固定することです。会議体さえ動けば、欠陥発見と記録は会議で必要になる情報として自然に整っていきます。逆に、テンプレートから整え始めると、判断の場がないまま記録だけが進み、また形骸化します。
もう一点、現場で見落とされやすいのが、「レビューに上げない案件をどう運用するか」です。週次30分の品質レビューには、判断が必要な案件しか上げないという線引きをするなら、それ以外の案件が静かに悪化していないかをチェックする仕組みも別に要ります。実務的には、月次で全案件を「赤・黄・緑」で色分けし、黄に変わった案件だけを翌週の品質レビューに上げる、という二段構えにすると無理なく回ります。色分け基準は、未解決重大欠陥の件数・テスト消化率・再発率の3つで十分です。
次の一歩：3点運用を体系として身につける
ここまで紹介した「欠陥発見・是正判断・記録」の3点運用は、ひとりのPMが1案件を立て直す視点としては十分機能します。一方で、複数案件を横断して品質マネジメントを設計する立場、たとえば部門のPMOや管理職としては、ケースごとに「どこから手をつけるか」を判断する練習が必要になります。
その体系学習として、【架空PJで学ぶ】品質マネジメント実践 では、レビュー形骸化・テスト後ろ倒し・基準曖昧・再発常態化という4ケースの演習を通じて、リリース可否と対応優先度を「説明して決める」力を鍛えます。本記事の3点運用が、ケース演習のなかでどのように働くかが見えると、自分の案件への当てはめ方も明確になります。
複数案件を抱えるPMとして判断力そのものを鍛えたい場合は、【プロジェクトマネジメント実務】ケース演習で鍛えるPM判断 を組み合わせると、品質判断と全体運営判断を一連の流れで整理できます。
品質管理の形骸化は、ルールを足すほど深まります。まずは「欠陥発見・是正判断・記録」の3点だけで運用を再起動し、現場が判断と記録に時間を使える状態を取り戻すことから始めてみてください。