「品質基準は誰が決めるのか」という問いから始める——ステークホルダーの”期待値”を品質管理の起点に設計する実践技法

＜目次＞

品質管理の「盲点」——基準を作る前に問うべきこと

品質管理の議論になると、多くのPMはすぐに「チェックリストをどう整備するか」「テスト工程をどう設計するか」に話を進めてしまう。しかしそもそも、「誰にとっての品質か」を定義しないまま管理を始めているプロジェクトが驚くほど多い。

完成物が仕様書通りに動いている。バグ件数もゼロに近い。それなのに、納品後にステークホルダーから「これじゃない」と言われた経験はないだろうか。それは品質管理の失敗ではなく、品質定義の失敗である。

本記事では、品質管理の「起点」をステークホルダーの期待値に置き直し、そこから逆算して管理の仕組みを設計するという、実践的なアプローチを紹介する。

品質を正確に定義するには、まず「品質」という言葉が複数の意味を持つことを理解する必要がある。筆者は品質を以下の三層で整理することを推奨している。

仕様書・設計書・要件定義書に記載された内容に、成果物が合致しているかどうか。最も測定しやすく、伝統的な品質管理が対象とする層。

成果物が、実際の使用場面で意図した目的を果たせるかどうか。仕様通りに作っても、現場で使いにくければ品質が低いと判断される。

ステークホルダーが「当然そうなっているはず」と思っているが、文書化されていない暗黙の期待。この層を見落とすと、納品直前の「これじゃない」が発生する。

品質問題の多くは、①だけを管理して②③を無視した結果として起きる。PMの仕事は、この三層をプロジェクト開始時に明示化し、管理可能な形に変換することだ。

プロジェクト初期に、主要ステークホルダーを集めた「品質定義セッション」を30〜60分設ける。このセッションでは以下の問いを投げかける。

ここで出た回答を、後述する「品質受入基準シート」に落とし込んでいく。ポイントは、ふわっとした表現を数値や状態で言い換えること。「使いやすい画面」を「主要タスクが3クリック以内で完了できる」に変換するような作業だ。

品質受入基準シートとは、「何が満たされたらこの成果物を受け入れるか」をステークホルダーと合意したドキュメントだ。以下の項目を列挙し、担当者と合意日を記録する。

このシートは憲章や要件定義書と同等の「合意文書」として扱い、変更が生じた際は変更管理プロセスを通じて更新することを徹底する。

多くのプロジェクトでレビューが形骸化するのは、「報告の場」になっているからだ。品質レビューは、受入基準シートを照らし合わせながら「基準を満たしているか／いないか」を判断する場として設計する。

具体的には、レビュー前に「品質チェックカード」を配布する。カードには受入基準の項目が並んでおり、参加者が事前に確認・評価を記入してから会議に臨む。これにより会議時間が短縮され、判断の質が高まる。

品質の期待値をどれだけ精緻に定義しても、それをPMだけが把握している状態では意味がない。チーム全員が品質基準を「自分事」として持てるよう、以下の工夫を取り入れてほしい。

品質を管理するツールや手法は数多く存在する。しかし、どれだけ優れたツールを使っても、測るべき「品質」が正しく定義されていなければ、管理は空回りする。

PMに求められる品質管理の本質的なスキルは、テストを設計することでも、バグを集計することでもない。ステークホルダーの期待を言語化し、チーム全員が共有できる「基準」に変換する能力だ。

「品質は誰のためのものか」——この問いをプロジェクトの起点に置き直すことが、品質管理を機能させる最初の一歩になる。