「今週の不具合件数が先週の倍になっています」——そう報告を受けたとき、「増えましたね」「気をつけて」以上のことが言えなかったとすれば、品質問題の初動として遅れをとっています。
品質問題への初動が遅れる最大の理由は、「バグ数だけを見ている」ことです。件数が増えたことは分かっても、「どこで何が起きているのか」「リリースに響くのか」「顧客にいつ何を伝えるのか」が整理されないまま、対応が後手に回ります。本記事では、品質問題が見え始めたPMが初動でやるべき4つのアクションを整理します。
品質問題はバグ数だけでは判断できない
バグ管理表の件数が増えているのは事実の一部に過ぎません。品質問題の深刻さは、件数ではなく「どこで起きているか」と「何への影響があるか」で決まります。
テスト工程の初期に集中して出るバグは、ある程度織り込み済みです。しかし、修正済みのはずの箇所に再発しているバグ、特定機能に集中しているバグ、受け入れテスト直前にゼロから増えているバグは、構造的な問題のサインである可能性があります。
また、重要度の高い機能でのバグ1件が、重要度の低い機能のバグ20件より影響が大きいこともあります。件数ではなく「業務上どの機能に影響しているか」で判断してください。
初動1：発生箇所と傾向を見る
品質問題が見え始めたら、最初にバグ管理表をもとに「どこで何が起きているか」を整理します。
確認する観点は3つです。第1に発生箇所の集中度——特定の機能・モジュール・担当者に偏っていないか。第2に重複・再発の有無——修正済みとなっていたものが再度起きていないか。第3に発生のタイミング——いつから増え始めたか、どのテスト工程で多いか。
この整理は、担当者に「バグ管理票を機能別・重要度別に並べ直してください」と頼むだけで始められます。
初動2：残課題とリリース影響を分ける
件数と発生箇所が見えたら、次に「このバグがリリースに何を与えるか」を分けます。
リリースを止める可能性があるバグ（主要業務が動かない、データ破損のリスクがある）と、回避策があるバグ（特定の操作順序を変えれば回避できる）と、後回しにできるバグ（UI上の軽微な表示崩れなど）の3分類を作るだけで、会議での議論の密度が変わります。
「全部対応しないとリリースできない」という発言が出てきたら、上記3分類を確認してください。「全部」の中に優先度が高いものと低いものが混在しているケースがほとんどです。
初動3：顧客へ伝える材料を整理する
品質問題が見え始めたとき、「顧客にいつ、何を伝えるか」の判断がPMに求められます。
原則は「事実として整理できてから、見通しとセットで伝える」です。件数が増えているという事実だけを伝えると、顧客の不安だけが先行します。「現在〇件の不具合が確認されています。このうちリリースに影響するものはX件で、対応予定は〇日です」という形にしてから伝えることで、顧客は判断材料として受け取れます。
逆に、整理が終わる前でも伝えるべき状況があります。それは、リリース日や受け入れ計画に影響が確定的になったときです。そのタイミングで顧客への連絡が遅れると、信頼を大きく損ないます。
初動4：是正アクションを決める
問題の整理が終わったら、是正アクションを決めます。
発生箇所が特定の機能に集中していれば、その機能の担当者のサポート体制を見直す必要があります。再発が多い場合は、修正後の確認プロセスが機能しているかを見直します。件数が急増していれば、追加テスト工程の設定や、テスト担当者のリソース増強が選択肢に上がります。
「何とかしてください」という漠然とした指示ではなく、「〇〇機能の再発防止を優先する」「修正後のレビューを必ず2名で行う」という具体的な取り決めを、チームと合意してください。
品質問題を隠さないための報告
品質問題が出始めたときに報告を遅らせるPMがいます。「まだ確認中だから」「解決できそうだから」という理由で判断を先送りすると、後から「なぜ早く言わなかった」という話になります。
上司やステークホルダーへの報告は「事実・影響・対応状況」の3点セットで。解決していなくても、把握していることと対応に動いていることが伝われば、信頼は保てます。
品質問題の初動を終えたあと、PMとして継続的に監視すべき指標があります。バグの「日次発生数」「修正後再発率」「重要度高の累積残件数」の3点を毎日確認することで、品質問題がコントロール下にあるかどうかを客観的に把握できます。これらの数字が悪化していれば、対策が機能していないサインです。改善傾向にあれば、顧客への報告で「対応が進んでいる」という根拠として使えます。
初動完了後に一つのクイックウィンを出す
4つの初動と並行して、または完了後に、顧客の安心感を高める「クイックウィン」を一つ出すことをおすすめします。
クイックウィンとは、完全な問題解決ではなく、顧客が「対応が動いている」と実感できる最初の実績です。たとえば「重要度高の不具合X件のうち、本日Y件をクローズしました」という一文を顧客に送ることで、状況が改善に向かっているという印象を与えられます。
一度に全部を解決しようとするより、「今日一つ前に進んだ」という状態を顧客にこまめに伝え続けることが、品質問題が続く期間の顧客の不安を和らげる実践的な方法です。
品質問題を組織の学びにつなげる
品質問題が収束したあとは、再発防止のための振り返りを行う機会です。何が起きたか・なぜ起きたか・どう防ぐかの3点を、関係者で確認することが重要です。
「犯人探し」にならないよう、振り返りはプロセスの問題に焦点を当ててください。「誰が見落とした」ではなく「どのプロセスで漏れが起きたか」を確認し、次のプロジェクトで使えるチェックポイントや確認プロセスを具体的に決めます。
振り返りの内容を記録し、次のプロジェクト開始時に参照できるようにしておくことが、組織としての品質管理レベルを上げる最も確実な方法です。PMが案件ごとに学びを蓄積していくことが、長期的なキャリア価値にもつながります。
PMは品質の専門家である必要はありませんが、品質問題の状況を把握して顧客に伝える役割を担います。技術的な詳細はQAやエンジニアに任せ、PMは「何が問題で、どう対応していて、いつ解消見込みか」を常に整理して伝え続けることに集中することが、品質問題期間中の最も重要な仕事です。
品質問題が起きたとき、PMは「自分の管理が悪かった」と自責しがちです。しかし、品質問題は多くの場合、見積もり・要件定義・開発フローなど、複数の要因が重なって発生します。一人で抱え込まず、上司やPMOに状況を共有して「チームとして対応している」という状態を作ることが、最も早い解決につながります。品質問題は、PMの個人的な失敗ではなく、チームで対処する案件上の課題として扱うことが大切です。
品質問題への初動対応を習慣化することが、「炎上しにくいPM」への近道です。4つの初動を体で覚えるほど反復すると、次の品質問題では初動が速くなり、問題が深刻化する前に対処できるようになります。
品質問題の初動から是正・顧客対応まで体系的に理解したい方には、炎上予防・立て直しパックが参考になります。受託開発PMが実際に直面する品質問題への対処法を、実務ベースで学べます。PJ炎上 初動ナビでは、品質問題の深刻度と次に取るべきアクションを診断できます。