リリース時点で障害件数はゼロ。テストも入念に回し、チームも「今回はうまくいった」と手応えを感じていた。それなのに、リリース後にじわじわと「思っていたものと違う」という声が上がり始める——私が実際に経験した、いちばんやっかいな品質問題です。この記事では、バグではない「品質の欠陥」がどこに潜んでいたかから始めて、PMBOK第7版の原則⑧「品質」を読み解きます。
この記事でわかること
- バグゼロなのに満足されない、その正体
- 品質の原則が言う「成果物だけではない品質」の意味
- 成果物だけでなくプロセスの品質を確保する視点
SIerでPMをしている筆者が、PMPの学び直しを機に「品質=テストの仕事」と思っていた昔の自分を振り返りながら書いています。
品質の原則が言う「品質」は、成果物に欠陥がないことだけでなく、そこに至るプロセスの質も含めて、期待に応える状態を作ることを指します。要件をどう固めたか、認識をどうすり合わせたか、意思決定をどう積み重ねたか——そうしたプロセスの質が、最終的な満足を大きく左右します。欠陥のなさは品質の一部にすぎない、というのがこの原則の視点です。
障害ゼロなのに「違う」と言われた
PMに成り立ての頃に担当したある案件は、私にとって自慢できるはずの出来でした。リリース時点で障害件数はゼロ。テストも入念に回し、成果物の品質という意味では文句のつけようがない。チームも「今回はうまくいった」と手応えを感じていました。
ところが、リリース後にじわじわと「思っていたものと違う」という声が上がり始めます。バグではありません。動作は完璧。でも、顧客が期待していた姿と、出来上がったものにズレがあったのです。原因をたどると、要件定義の段階での認識合わせが不十分だったことに行き着きました。曖昧なまま「たぶんこういうことだろう」で進めた部分が、そのまま欠陥のない成果物になっていたのです。
この経験から、私は成果物の品質チェックだけでなく、要件定義工程そのものにレビュー基準を設けるようにしました。たとえば「合意形成の証跡(誰が何にOKを出したか)が残っているか」を確認する。プロセスの品質を可視化することで、「欠陥はないのに満足されない」という一番やっかいなズレを、作る前に減らせるようになりました。
品質はテスト工程の仕事だと思っていた
「品質を上げる=バグを減らす」私は長くそう捉えていました。だからテスト工程には力を入れる一方で、要件定義の「合意の質」には無頓着だったのです。
でも、この狭い理解のままだと、プロセス品質の欠陥をまるごと見逃します。バグゼロは必要条件であって、十分条件ではない。「正しく作ったか」だけでなく「正しいものを、納得のうえで作っているか」まで見て、初めて品質と呼べる。視野をテスト工程の外まで広げることが、遠回りに見えて確実でした。
なぜテストでは検出できないのか
成果物のバグは、テストで見つけて直せます。でも、要件定義での認識のズレや、合意なきまま進めた意思決定は、テストでは検出できません。それらは「欠陥のない成果物」として完成し、リリース後に「これじゃない」となって初めて表面化します。だから、作る過程そのものの品質を見ておく必要があるのです。
品質のために続けていること
- 成果物の品質だけでなく、意思決定や合意形成のプロセスの質も点検する
- 「誰が何にOKを出したか」の証跡(議事録・承認記録)が残る仕組みにする
- 品質基準を、テストだけでなく工程ごとに明文化する
よくある質問(FAQ)
Q. 品質保証(QA)と品質管理(QC)は違うもの?
はい。品質管理(QC)は「できた成果物に欠陥がないか検査する」こと、品質保証(QA)は「そもそも欠陥が生まれにくいプロセスを整える」ことです。この原則はQAの発想に近いです。
Q. 「品質」と「価値」はどう違う?
品質は「きちんと作れているか」、価値は「役に立っているか」です。高品質でも使われなければ価値は出ませんし、逆もあります。セットで意識すると判断がぶれません。
振り返って
品質の原則とは、バグの少なさだけでなく、要件・合意・意思決定というプロセスの質まで含めて期待に応えることでした。あなたの案件で、「欠陥はないのに満足されない」リスクは、どこに潜んでいそうですか? 一度、作る過程の合意の質を見直してみると、見えてくるものがあります。
関連記事
- PMBOKとは?なぜ今あらためて学ぶのか ― この連載の入口から
- 「複雑さ」の原則:要素は単純なのに制御不能になる理由 ― 次に読むならこちら
- 「価値」の原則:仕様どおりに作っても満足されない理由 ― 品質と混同しやすい原則
コメント