品質とはユーザの要求水準を満たすこと

一般的に言えば、品質とは、成果物に対する品質と、プロセスに対する品質の2種類あります。品質といえば、成果物に対する品質ばかりに目が行きがちですが、プロセスの品質を保つことも重要なポイントです。
ITプロジェクトで、品質とは、どのような意味があるでしょうか。
バグのないシステムを作る?
ユーザーの要求水準を満たす?
発生した課題がすべて解消される?


いろいろと考えなければならないポイントが多いですが、一番重要なことは、ユーザー、顧客の要求水準を満たすということです。
PMBOKでは、ユーザーの要求水準以上のことはするな!と書いてあります。これをGold Platingと呼んでいます。要求にはないが、便利だと思う機能を付加したりすることが、これに当ります。
では、ユーザーの要求水準とは何か?
ここを明確にしないプロジェクトがあまりにも多いような感じを受けています。これを明確にするのが、計画です。
計画では、品質目標を設定しますが、できるだけ客観的な数値に置き換えることができるものが望ましいと考えています。
品質目標を設定しないままに、課題数のトレンドを追ってみたり、課題の発生原因別に分析することは、無意味とは言いませんが、何のために分析するのか分からなくなります。
また、例えば、要件定義書を作成しますが、その中に書かれるべき内容を予め決めて、その項目が満たされているかどうかを判断することも品質管理だということができます。
余談ですが、私のブログに、「要件定義書 テンプレート」というキーワードで検索して来られる方が時々います。ただ単に、要件定義書のフォーマットを求めて来ているのではないと思います。
要件定義書に書くべき内容のテンプレートを探しているのではないかと推測していますが、これは、プロジェクトによって異なるので、テンプレート化はできないと思っています。
マネジメントプロセスに関しても、何をどのように管理するか、例えば、誰が問題提起して、どのような文書を作り、誰が承認するかということを決めて、その通り、プロジェクトが進んでいるかどうかをチェックするのが品質管理です。
ある製造業のERPプロジェクトで、前フェーズが終了し、部分カットオーバーしました。新フェーズに入り、私がPMを引き継いだのですが、引き継ぎ早々、トラブルに見舞われてしまいました。
ユーザの運用担当者へ前フェーズのシステムを移管していたのですが、その運用担当者から不満の声が上がってきました。
要件定義書を読んでも、なぜ、このようなシステム構成にしているのか、なぜ、このようなアドオンを開発しているのかわからないという内容でした。
プロジェクトチームからの引継ぎでは、アドオンのプログラム内容の説明はあったが、業務的な背景が抜けており、将来、業務が変更された場合、どのようにプログラムを変更すれば良いか判断がつかないと言うことです。
前PMからは、運用担当者への引継ぎも何も問題なく終了していると報告を受けていましたし、前フェーズの要件定義を実施したメンバーは、プロジェクトから既に離れており、誰もフォローできない状況でした。
運用担当者の言うことはもっともだと感じましたが、困ってしまいました。
幸なことに、要件定義を行なったメンバーが新たにアサインされたプロジェクトがまだ計画段階でしたので、急遽そのプロジェクトのPMに事情を説明し、数日間メンバーを借りて、新たな説明文書を作成し、業務的な背景を説明することができました。
この例は、品質の問題だけではなく、いろいろな問題が複合的に原因となっていましたが、何とか切り抜けることができました。
最初に、顧客が欲している情報は何か、その要求水準は何かを特定し、それに沿った成果物を作るのが重要だとつくづく感じました。言うまでもありませんが、顧客の言うとおりにすべて行なえといっているわけではありませんので、お間違えなく。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*