品質管理は定性情報分析ができる有識経験者が望ましいのですが・・・【プロジェクト管理のチェックポイント（３／１３）品質管理】
連載モノ第３弾デス。経験談に基づきですが、重要と思われるプロジェクト管理上のチェックポイントを整理しましたので、参考になる方がいらっしゃれば幸いです。
【基本の基本】
・品質管理方針が策定されているか？その方針は有名無実化していないか？
・品質管理計画はタイムリーに策定されているか？
・品質向上に向けての努力を実施しているか？
・ユーザ部門からの品質チェックが効率的にできるようになっているか？
・品質基準は定義してあるか？
・ユーザ部門へ要件定義内容は十分説明されているか？
・設計・開発・テスト方針は内容的に十分なものであるか？
・それらはタイムリーに策定され、実施は効率的に行われているか？
【解説～考え方】
進捗管理と異なり、品質管理には、より高い経験やスキルが求められると思っています。
進捗管理は基本的にはどのように管理するかの手順をよく理解し実践できることが重要です。もちろん進捗を把握するために時には悪い状況も情報収集するわけですから収集先から煙たがられたりするわけで、人格とまでは言いませんが、それなりの話術なりテクニックも必要です。
ただ、品質管理はもっといろいろ要ると思います。
プロジェクト管理を十分経験した！という方々には釈迦に説法ですが品質管理とは「品質保証」「品質コントロール」の２つの機能をこなすということです（世の中にいっぱい情報ソースはあると思いますのでここではその解説は省略させていただきます）。
ブログエントリということであまり大作に書くわけにもいかないので私なりに要約してそのポイントをひらたく解説させていただきますと、要は、
・進捗情報の「偽り」や「認識誤り」を効率的に暴き出すこと
・定量的な進捗情報だけでは把握できない定性的な情報をより多く現場から引き出すこと
・品質達成（確保）状況を定量的データで説明してあげられること
・品質面の改善を進捗させるように現場に意識させ、それを励行させること
・品質を期待以上でも期待以下でもない適正レベルにコントロールすること
が本質的なポイントかと思います。
バグ検出密度がいい例ですが、定量的にバグの発生数の推移や解消度合を引合いに、システム設計・開発の状況がいかにいい塩梅かを説明していくわけです。
密度自体は「進捗管理者」が集計したデータを使えばいいわけですが、問題は上述ポイントの通り、数値化された定量的情報の集計・統計に加え、「どうしてそのような進捗になっているのか」を定性的に分析し説明できる「技術」も求められるのです。
極論ですが、「出来た」と言われれば進捗管理上は「完了」です。「やってる」と言えば「作業中」です。ですが、その成果を品質管理者がチェックします。結果、「完了のつもり」だったり「まだ着手できてないじゃん」という話が明らかになるのです。
進捗管理上の「進捗」と「品質の達成度合」が釣り合っているかどうかは、やはり、「定性的情報」に基づき品質管理者がチェックすべきだと思うのです。
「進捗管理」では、例えば大規模プロジェクトでは特にそうであるように、「大局的に順調なの？」という点がクリアに報告できることも肝要ですが、「品質管理」においては、「局所的にそこがどのくらい順調なのか／どの程度の問題があるのか」も定量的な話とは別に定性的に詳細まで説明できる必要があるように思います。
【まとめ】
嫌われ役になる可能性も高いため、このような活動には経験が（求められる程度に）豊富かどうかは重要な要件だと考えます（経験が十分じゃなくてもプロジェクトの状況、難易度によってはなんとかなるケースがありえるとは思いますが）。
品質管理の１つの重要な論点として、「品質管理機能がどこまで本質的な成果物品質（仕様や要件）を管理できるのか」というポイントがあるのですが、今日はひとまず、それは次回の成果物管理のテーマに繰り越すことにして、「ファンクションには深い理解がないけどそれでも品質管理をする」という方向でどのようなルーティン（本エントリが概要レベルである点は恐縮ですが）＝品質管理プロセスであるべきか、についてはこのように思う次第です。
キーワード記事*