品質を数字で説明できないPMへ｜最小限測る指標と語り方

2026 8/12

2026年8月12日

リリース前のレビューで、上長からこう問われた経験はないでしょうか。「で、このシステムの品質は大丈夫なの？」。テストの進捗なら「消化率は9割です」と即答できます。ところが「品質は？」と問われた瞬間、言葉に詰まってしまう。品質を数字で説明できないという感覚は、多くのプロジェクトマネージャーが抱える共通の悩みです。

進捗は測れているのに、品質は測れていない。あるいは測ってはいるものの、その数字が「安全」を意味するのか自信が持てない。だから報告は「たぶん大丈夫です」という主観的な言い回しになり、上長も顧客も、どこか腑に落ちないまま本番を迎えます。

とくに専任のQAを置けず、PM自身がテストの進捗も品質も見ている体制では、この悩みは深刻になります。品質を語る専門用語を持たないまま、感覚で「大丈夫そう」と判断せざるを得ないからです。本記事では、なぜ品質を客観的に語れないのかを構造から解きほぐします。そのうえで、少人数の体制でも無理なく測れる最小限の指標と、それを「説明」に変える語り方のフレームを整理します。指標の細かい算出式やツール設定には踏み込まず、現場で判断に使える軸に絞ってお伝えします。

「品質を数字で説明できない」とは、現場で何が起きている状態か

まず整理したいのは、進捗と品質はまったく別の軸だという事実です。消化率のような進捗指標は、予定と実績の足し算・割り算で誰が計算しても同じ値になる客観的な数字です。予定100件のうち90件を実行したら消化率90%、という具合に、そこに解釈の余地はほとんどありません。

一方で品質は、テストを全部消化したからといって高いとは限りません。浅いテストを100%消化しても、深い不具合はそのまま残ります。進捗は「作業がどこまで進んだか」、品質は「成果物がどれだけ信頼できるか」を表す別軸の概念です。この二つを混同したまま報告すると、「作業は終わったが、信頼できるかは分からない」という宙ぶらりんの状態が生まれます。

次に多いのが、「バグは出ていません」という報告が、かえって不安を招くケースです。バグ件数がゼロという同じ数字でも、意味が正反対になることがあるためです。

出尽くしのゼロ: 十分にテストを重ねた結果、これ以上は出ないところまで来たゼロ
到達できていないゼロ: テストが浅く、そもそもバグのある場所までたどり着けていないゼロ

前者は安心材料ですが、後者は危険信号です。にもかかわらず、報告書の上ではどちらも「バグ0件」と書かれます。バグ件数という単一の数字は、良い状態も危険な状態も同じ顔で表れます。だからこそ、件数だけを切り出して「ゼロなので安心です」とは言えないのです。

身近な例で考えてみましょう。二つのプロジェクトが、どちらも「バグ0件」で報告してきたとします。片方は網羅的なテストを重ねた末のゼロ、もう片方は納期に追われて主要画面をなぞっただけのゼロ。報告書の数字は同じでも、本番で起きることはまるで違います。数字を額面通りに受け取ると、この差を見逃してしまうのです。

そして忘れてはならないのが、説明責任は「納得感」で決まるという点です。目的は、小数点以下まで完璧な数値を出すことではありません。上長や顧客が納得し、リリースするかどうかを自信を持って意思決定できる状態をつくることです。裏を返せば、完璧な統計がなくても、判断に必要な材料をそろえて筋道立てて語れれば、説明責任は果たせます。専任のQAを置けない体制でも、語り口を変えるだけでこの状態には近づけます。逆に言えば、どれだけ精緻な数字を並べても、相手が意思決定できなければ「説明した」ことにはならないのです。

なぜ品質を数値で語れないのか｜PMを縛る6つの構造

多くのPMが品質を数字で説明できない背景には、担当者個人の努力不足では片づけられない、構造的な要因があります。ここでは現場で繰り返し観察される6つの構造を整理します。自分のプロジェクトがどれに当てはまるかを確認してみてください。

構造	何が起きているか	典型的なサイン
①測っていない	品質を表す数字をそもそも記録していない	進捗表はあるが品質欄がない
②数字を解釈できない	消化率100%を品質OKと誤読する	「全部終わったので大丈夫」と言ってしまう
③数字の独り歩きが怖い	出した数字が一人歩きして責められる不安	あえて曖昧にぼかして報告する
④完了基準が曖昧	どうなれば終わりかを事前に決めていない	「一通り終わったら」で走り出す
⑤バグ件数ゼロが目標化	バグを出さないこと自体が目的になる	報告のために深掘りを避ける
⑥単一指標偏重	一つの数字だけで良し悪しを断じる	消化率だけで品質を語る

これらは独立して起きるのではなく、連鎖します。④完了基準が曖昧だから②数字を正しく解釈できず、②誤読を恐れるから③数字を出すのが怖くなり、結果として①そもそも測らなくなる、という流れです。とくに⑤は見落とされがちです。バグを出さないことが評価されると、担当者は無意識に深掘りを避け、出尽くしていないのに「ゼロ」を報告してしまいます。

数字を出す文化が育たない最大の理由は、実は測定技術ではなく心理にあります。数字を出さないのは、測れないからではなく、出した数字に縛られるのが怖いからという側面が大きいのです。「消化率90%」と言った瞬間に「残り10%はいつ終わる」と詰められる、そんな経験が数字を遠ざけます。裏を返せば、完了基準を先に握り、数字の読み方をチームで決めておけば、この連鎖の多くは断ち切れます。数字は責めるための道具ではなく、判断を助ける道具だという共通認識が出発点になります。

もう一つ根深いのが、⑥の単一指標偏重です。消化率という一つの数字だけを追うと、その数字が満点に近づくほど安心してしまい、ほかの危険信号が見えなくなります。数字は一つに絞るほど扱いやすくなりますが、扱いやすさと実態の正しさは別物です。品質のように多面的な対象を一つのメーターで表そうとすること自体に無理があると、まず認めるところから始めましょう。次章からは、この6つの構造を一つずつほどいていきます。

消化率100%は「品質OK」ではない｜最大の誤読

品質の議論でもっとも根深い誤読が、消化率100%を品質保証と同一視することです。消化率は、予定したテストをどこまで実施したかを示す進捗指標にすぎません。100%は「計画したテストをすべて実行し終えた」という事実を表すだけで、そのテストが品質を保証できる設計になっているかは含みません。もとの計画が甘ければ、100%消化しても甘いテストを全部やっただけです。

さらに注意したいのは、消化率100%は「実行が完了した」ことを意味するのであって、pass/fail（合否）を含まない点です。全ケースを実行し終えても、その中に未修正のFail（不合格）が残っていることは珍しくありません。実行済みと合格は別物なのです。消化率は必ず検出バグ（未解決件数）とセットで見ないと、実行済みという事実だけが安心材料に化けます。テストの実行と進捗の可視化の考え方は、テスト進捗管理の基礎知識も併せて確認すると整理しやすくなります。

進捗と品質は、次のように問いの立て方から異なります。両者が答えられる問いを混同しないことが、誤読を防ぐ第一歩です。

観点	消化率（進捗）	品質
測る対象	実行したテストの割合	成果物の信頼できる度合い
100%の意味	計画分をすべて実行した	何も保証しない
答えられる問い	どこまでやったか	どれだけ安全か
落とし穴	実行＝合格と誤読する	単一の数字では表せない

計画そのものの質を問わないまま消化率だけを追うと、「消化率を上げること」がいつのまにか目的化します。すると、確認が容易で不具合の出にくいケースばかりが並び、面倒でバグの潜みやすい条件は後回しにされがちです。数字は順調に伸びていくのに、リスクの高い部分は手つかずのまま、という事態が起こります。消化率を見るときは、必ず「そのテストは何を確かめる計画だったのか」という中身とセットで捉える必要があります。

同じ誤読は、カバレッジ（網羅率）でも起こります。ここで言うカバレッジは、主にコードカバレッジ、つまりコードの構造をどれだけ通したかを表す指標です。代表的なものに、すべての命令を最低1回通す命令網羅（C0）と、分岐の各方向を最低1回通す分岐網羅（C1）があります。一般にC1のほうがより強力とされますが、いずれもコードを「どう通したか」を測るものである点は共通です。

高橋寿一『知識ゼロから学ぶソフトウェアテスト』は、コードの構造網羅の文脈で、カバレッジ100%を達成しても見逃すバグが構造的に存在すると指摘します。要求仕様そのものの誤りや機能の欠落、ループやデータの扱い、割り込みに関する不具合は、コードを通す網羅率をいくら上げても捕まえられないためです。網羅したのはあくまで「書かれたコード」であって、「書かれるべきだった仕様」ではないからです。

コードカバレッジ100%は「通った経路の網羅率」であって、バグが存在しないことの証明ではありません。そして少人数体制がまず意識すべきは、コードカバレッジよりも、要求仕様を漏れなくテストできているかという「テスト設計の網羅性」です。限られた工数の中では、コードの隅々を通す前に、確かめるべき要件がテストケースに落ちているかを優先すべきです。「コードカバレッジが高い＝安全」という等式は、ここで明確に切っておく必要があります。

少人数体制でも品質を語れる｜最小限で測る指標の選び方

品質を語るコツは、一つの数字で断じないことです。少数の指標を組み合わせ、その値そのものより「傾向（推移）」で語ると、専任QAがいなくても実態に近い説明ができます。とはいえ、兼任で手が回らない現場に多くの指標を求めるのは非現実的です。まず削ぎ落とすところから始めます。

まず最優先で見るべきは「消化率」と「検出バグの推移」の2つだけで十分です。この2つはExcel1枚に、日付ごとの実行数と検出バグ件数を並べるだけで運用でき、専用の計測ツールも複雑な設定も要りません。列は「日付」「その日の実行数」「累計実行数」「その日の検出バグ数」「未解決バグ数」があれば十分で、あとはそれをグラフにするだけです。重大度分布やコードカバレッジは、この2つが回り始めてから足す「余力があれば」の第二階層と位置づけます。最初から全部やろうとして続かないより、2つを毎日埋め続けるほうが、はるかに価値のある線が残ります。指標を増やすかどうかは、その数字を見て次のアクションが変わるかどうかで判断してください。見ても打ち手が変わらない数字は、測っても報告の飾りにしかなりません。

階層	指標	見るポイントと落とし穴
最優先	消化率＋検出バグ数	消化率は単独では読めない。必ずバグ件数とセットで見る
最優先	検出バグの推移	収束傾向を追う。ただし減少＝品質向上とは限らない
余力があれば	バグの重大度分布	件数より「重いバグが片付いたか」を見る
余力があれば	コードカバレッジ	あくまで補助線。網羅率＝安全ではない

バグは、件数の多寡そのものより「推移」と「重大度」で語ります。まず推移から見ていきましょう。ここには一つ、強い注意点があります。バグ検出数の低下は、品質向上とは限りません。テスト担当者のネタ切れ、未テスト領域の残り、欠陥の潜伏でも、検出数は同じように下がるからです。グラフが右肩下がりになったからといって、素直に「良くなった」と読んではいけません。

したがって収束は完了基準の一要素にとどめ、それ単独を合格の根拠にしてはいけません。「検出数が下がったこと」に加えて、「新しい観点のテストを投入しても、もう出なくなったか」まで確かめて、初めて収束が意味を持ちます。逆に、まだ試していない観点が残っているなら、検出数の低下はネタ切れの裏返しかもしれないと疑うべきです。判断に迷ったら、「もし今から半日、別の切り口でテストを足したら、まだバグは出そうか」と自問してみてください。出そうだと感じるなら、それはまだ収束していない証拠です。この問いは、専門的な統計を使わずとも、収束の本物と偽物を見分ける実務的な物差しになります。

高橋寿一『知識ゼロから学ぶソフトウェアテスト』は、G.J.Myersの言葉として「プログラムのある部分でエラーがまだ存在している確率は、すでにその部分で見つかったエラーの数に比例する」を紹介しています。よくバグが出た場所ほど、まだ残っている可能性が高いという経験則です。これは、検出バグの分布を「次にどこを追加で掘るか」の判断材料に使えることを意味します。バグが集中した機能は、収束したように見えても、もう一段深く掘る価値があります。逆に、これまで一度もバグが出ていない機能は、堅牢なのか、それとも十分にテストできていないのか、いったん立ち止まって見極めるべきです。

補助線として使うコードカバレッジについても、目標値の扱いには注意が要ります。Copeland『ソフトウェアテスト技法』は、カバレッジの目標値を絶対視することへのMyersの批判を紹介しています。カバレッジ目標だけを追うと、テスト担当者が「欠陥を見つける力は弱いが、目標の数字だけは達成しやすいテスト」を無意識に作ってしまう、という指摘です。カバレッジは「まだ通していない箇所」を洗い出す地図としては有用ですが、数字を満点にすること自体を目的にした瞬間、テストは形骸化します。指標はあくまで判断の材料であって、達成すべきゴールではないと心得ておきましょう。

次に重大度です。重大度で語ると、同じ件数でもまったく意味が変わります。軽微なUI崩れが数件残っているのと、決済が止まる致命バグが残っているのとでは、リリース判断は正反対になります。「バグ残り5件」という総数だけを見て安心したり不安になったりするのは、この差を潰してしまう見方です。重大度別に「致命は何件、重要は何件、軽微は何件」と分けて数えるだけで、報告の解像度は一段上がります。

ただし、重大度（Severity＝障害が起きたときの影響の大きさ）だけで機械的に決めないこともポイントです。優先度や発生頻度も添えて見ます。致命的な障害でも、発生条件がごく稀で回避策があるなら、判断は変わります。逆に影響は中程度でも、全ユーザーが必ず踏むなら優先度は跳ね上がります。重大度は「起きたときにどれだけ痛いか」、発生頻度は「どれだけ起きやすいか」を表し、この掛け合わせで実際のリスクの大きさが決まります。片方だけを見て判断すると、稀な致命バグに振り回されたり、頻発する軽微バグを軽視したりする落とし穴にはまります。

なお、バグ密度などの基準値を「業界平均はこの値だから合格」と断定するのは危険です。基準値は組織や案件の性質、規模、開発言語によって大きく異なります。参考として、IPAのソフトウェア開発分析データ（メトリクス）のような公開データはありますが、これをそのまま自プロジェクトの合格ラインに転用しないよう注意してください。あくまで自分たちの過去実績との比較で傾向を読むのが実務的です。指標の選び方や設計を体系的に詰めたい場合は、テストメトリクスの実装手順や品質KPI設定の具体的手順が参考になります。

数字を「説明」に変える｜上長・顧客が納得する語り方のフレーム

指標をそろえても、それだけでは「説明」になりません。数字を説明に変える鍵は、測るより先に完了基準を関係者と握っておくことです。基準があって初めて、「その基準に対して、今どこまで来たか」という形で品質を語れます。基準がないまま数字を並べても、その数字が多いのか少ないのか、良いのか悪いのか、誰にも判断できません。「消化率95%」も、基準が「主要シナリオを全消化し、致命バグゼロ」と決まっていて初めて、合格に近いのか遠いのかを語れます。基準は、テストを始める前に、上長や顧客を巻き込んで合意しておくのが理想です。走り出してから決めようとすると、都合のよい基準に引き寄せられ、結局「たぶん大丈夫」に逆戻りしてしまいます。完了基準の決め方は、テストの完了基準の決め方が具体的です。

同じ品質でも、語り方次第で相手の納得感はまるで違います。悪い報告は作業の話から始まり、良い報告は基準の話から始まります。

要素	悪い報告	良い報告
起点	作業の進み具合から話す	事前に握った完了基準から話す
進捗の語り	「消化率9割です」	「基準の9割まで到達しました」
バグの語り	「バグは残っています」	「致命は解消、軽微が残っています」
リスク	触れない	残りリスクを重大度別に言語化
結論	「たぶん大丈夫です」	「この条件付きでリリース可能です」

なぜ単一の基準で「終わり」と言い切れないのか。Copeland『ソフトウェアテスト技法』は、Boris Beizerの「いつ終了するかを判定するための、単一の、正当かつ合理的な判断基準は存在しない」という見解を紹介しています。消化率だけ、あるいはバグ収束だけで判断すると、必ずどこかに穴が残ります。だからこそ、消化率・バグの収束・重大度といった複数の基準を束ねて語る必要があります。

具体的に語り口を比べてみましょう。悪い報告は「テストはほぼ終わりました。バグもいくつか直したので、たぶん大丈夫だと思います」となります。聞き手には、何がどこまで確認されたのか、何が残っているのかが伝わりません。一方の良い報告は「事前に合意した完了基準に対して9割まで到達。致命度のバグはすべて解消し、残るのは軽微な表示崩れが数件で、いずれも回避策があります」となります。同じ状況でも、後者なら上長はその場で判断できます。

良い報告は、残っているリスクを重大度別に言語化し、「何が残り、それがどれだけ危険か」まで伝えます。「致命はゼロ、重要が回避策付きで残り、軽微が数件」という粒度で示せれば、聞き手は自分でリリースの是非を判断できます。判断を相手に委ねられる報告こそ、説明責任を果たした報告だと言えます。重大度やカバレッジ、完了基準といった用語の定義を関係者とそろえたいときは、JSTQB（ソフトウェアテスト技術者資格認定）の用語集が裏取りに使えます。報告の組み立て方そのものは、テストレポートの書き方も併せてご覧ください。

この語り方の土台にあるのは、「良い・悪い」という主観語を、「基準に対してどこ」「重大度ごとに何件」という客観的な位置情報に置き換える発想です。主観語は聞き手によって解釈が割れますが、位置情報は誰が聞いても同じ絵が浮かびます。品質そのものを一つの点数に圧縮するのではなく、複数の軸での立ち位置を並べて見せる。これが、専任QAがいなくても相手を納得させられる語り方の核心です。

完了基準を関係者と握れなかった週もあるはずです。走り出してしまった案件では、後から基準を差し込む余地がないことも少なくありません。その場合の次善策は、基準がなくても、残存リスクを重大度別に言語化して報告することです。「致命はゼロ、重要が残り、うち1件は回避策あり、軽微が数件」と伝えるだけでも、「たぶん大丈夫」よりはるかに意思決定に耐えます。基準を握れないなら、せめてリスクの中身を見える形にして相手に渡す、という発想の転換です。

それでも自前で品質を可視化しきれないときの選択肢

兼任でテストの計測や集計まで手が回らない、あるいは自分たちのテストに見落としがないか不安が残る、という状況もあります。そうしたときは、第三者の視点で品質を棚卸しし、可視化してもらう選択肢があります。判断のために、まずどちらのケースに当てはまるかを整理しておきましょう。

内製で進めやすいケース: 完了基準を関係者と握れている／消化率と検出バグの推移を継続記録できている／重大度の判断がチーム内でぶれない
第三者を検討したいケース: 計測・集計に恒常的に手が回らない／テスト設計の網羅性を客観的に確かめたい／属人化して他者が品質を説明できない

費用対効果を判断するなら、コスト同士を並べて比べるのが有効です。本番でバグが1件流出したときの手戻り工数と、顧客からの信頼を失うことによる見えにくいコスト。これらと、事前に品質を棚卸しするコストを対比してみてください。具体的な金額は案件で異なるため断定できませんが、流出時の損失が棚卸しの費用を上回りやすい局面かどうかは、PM自身の肌感覚で判断できるはずです。とくに一度失った信頼の回復には、次の受注や継続契約にまで響く長い時間がかかります。

判断を先送りにしがちなのは、棚卸しのコストが目の前の「見えている出費」であるのに対し、流出のコストが「まだ起きていない損失」だからです。人はどうしても、目の前の出費を重く、将来のリスクを軽く見積もりがちです。だからこそ、両者を同じ土俵に並べて比べる視点が要ります。自分たちで数字をそろえきれないと感じたときは、その視点を持ったうえで、内製で粘るか外の力を借りるかを冷静に選べば十分です。

第三者の活用は「丸投げ」ではなく、自分たちが品質を語るための数字をそろえる手段だと捉えると、判断を誤りません。外に出すのは作業であって、説明責任そのものは手元に残る、という線引きが大切です。第三者にそろえてもらった数字を、最後に上長や顧客へ語るのはPM自身です。だからこそ、外部の力を借りる場合でも、どの指標をどう読むのかという判断軸は、これまで見てきた通り自分の中に持っておく必要があります。

よくある質問

消化率100%なら品質は大丈夫ですか？

いいえ。実行完了を示すだけで合否は含みません。未修正のFailが残ることもあり、必ず検出バグ件数とセットで確認します。

品質報告は何から測ればよいですか？

まずは消化率と検出バグの推移の2つで十分です。Excel1枚で運用でき、重大度分布は余力が出てから足します。

バグ件数ゼロは良い報告ですか？

一概には言えません。出尽くしのゼロか、テストが浅く到達できていないゼロかで意味が正反対になるためです。

まとめ｜品質を数字で説明できない状態から抜け出す3ステップ

品質を数字で説明できない状態は、才能や経験の不足ではなく、進捗と品質の混同という構造から生まれます。裏を返せば、構造を理解して手順を踏めば、専任QAがいなくても抜け出せます。道筋は、次の3ステップに整理できます。

進捗と品質を切り分ける: 消化率は進捗であって品質ではないと、まず自分の中で線を引く
最小限を完了基準とセットで測る: 消化率と検出バグの推移の2つを、事前に握った完了基準に照らして記録する（重大度は余力があれば）
基準に照らして語る: 「基準に対して収束したか」「重いバグは片付いたか」で品質を語り、残りリスクを重大度別に言語化する

最後に、始め方のハードルを下げておきます。初回は推移がなくても構いません。今回のリリース分について、検出バグの件数と重大度の内訳だけを添えれば十分です。線が1本もない状態からでも、点は打てます。2回目以降で点が線につながり、それが推移になります。完璧なダッシュボードを目指す必要はありません。まずは今リリースの1点から始めてください。

テスト体制や品質の可視化に手が回らず、見直しを検討されている方は、テスト体制の見直しをテスター10に相談するところから始めてみてください。