プロジェクトが佳境に入り、ある程度の成果物ができました。その成果物の検収を受ける段階になって問題となるのが品質です。
PMBOK流に言うと、品質とは、ユーザの要求仕様に合致していることを言います。品質マネジメントに、品質保証と品質コントロールというプロセスがあります。
品質保証とは、品質計画で定められた手順、基準どおりに行なわれているかどうかをチェックすることです。品質コントロールとは、品質計画で決められた目標水準に達しているかどうかをチェックし、達していなければ改善することを意味します。
つまり、品質保証は、正しく行なわれているかどうかを見ること、品質コントロールは、要求水準に達しているかどうかを見ることです。
この2つのプロセスを通して、プロジェクトで正しいことが行なわれているようにすることを品質マネジメントと定義しています。
しかし、本当でしょうか？
要求仕様に合致していれば良いのでしょうか？
IT業界で考えると、プロジェクトの成功とは、作り上げたシステムが動くことです。多少予算オーバー、納期オーバーになっても、動けば成功したと考えられています。
逆に、動かないシステムは、失敗と呼ばれます。
これを考えれば、要求仕様に合致していても動かなければ失敗です。
そこで、もう1つの基準が必要になります。ユーザが満足しているかどうかということです。
ただ満足させればよいというものではなく、PMBOKでも言っているように、、ユーザの要求水準以上のものを作り満足させることは、gold platingと呼び、悪いことだとしています。
テスト段階になって、あるいは、テスト結果を踏まえて、変更要求がたくさん出されます。すべての変更要求を実現するわけではないですが、当初の要求仕様にないものは、
要求仕様にありません。スコープ外です
とまずは対応して、変更要求を受け付けるプロジェクトが大半ではないでしょうか。
変更要求がこの段階で出るということは、要求仕様の決定時の品質が問われることになります。
あるサービス業のERPプロジェクトで、私は、あるチームのリーダーをしていました。テスト終了時に、別のチームの変更要求の数が膨大にのぼり、マネジメントチームとしてどのように対応するか考えなければならなくなりました。
当然（？）、私のチームでも変更要求が出されたのですが、数では比較にならない状態でした。
そこで、エンドユーザも含めてヒアリングを行ないました。
すると...
ユーザ側、業務側メンバーの大半が、「これは後で決めましょう。」と言われ、要求仕様を決定する時に決めなかったもので、変更要求ではないという回答でした。
おいおい、重要なことを先送りするなよな...
また、あるメンバーは、「この仕様は、こう解釈して...」
「えっ？解釈？確認しなかったのか？」
「はい...」
これでは、品質マネジメントができていない状態です。
結局、仕様変更ではない変更を受けざるを得ないと判断しました。
しかし、これにより、カットオーバーが延期になることは目に見えています。最終的には、チーム毎（モジュール毎）にカットオーバーを段階的に行なうことにして対応しました。
データ移行がややこしくなりましたが。
この例でも分かるように、品質マネジメントは、日々の小さな積み重ねです。検収を受ける段階になって問題となるようでは、マネジメントしているとは言うことができません。
コメントする