ITシステム発注者から見たプロジェクトマネジメント

ITシステム開発の品質といった場合、何を思い浮かべるでしょうか？
一般的には

• 完成したシステムの障害（バグ）が少ないこと
• 完成したシステムの処理性能がよいこと
• 完成したシステムの使い勝手がよいこと

といったようなことが考えられそうです。

プロジェクト管理における品質管理を考えたときの「品質」は、少なくとも「管理」出来るものでないといけません。つまり、数値化など目に見える形の「品質」にしないと「管理」のしようがないのです。上記のうち、「使い勝手がよい」というのは数値化が難しいため、品質管理の対象にはしづらいです。

例の上２つは、数値化できそうなので品質指標になりそうですが、ここに一つ落とし穴があります。確かに数値化できるものではありますが、最終的な成果物となるシステムが出来上がらないことにはこの数値が分かりません。つまり、プロジェクトを遂行している途中の段階では数値が分からないため、プロジェクト管理の品質管理に使う数値として最適といえるものではないです。これらは、最終的な成果物の目標値としてシステムを作っていくという観点では意味があるものですが、あくまで最終目標の数値であって、プロジェクト進行過程における品質の数値としては意味を持ちづらいのです。
（上記の例で「完成したシステムの〜」と敢えて入れているのは、実は意味があります。理由は後ほど説明します。）

では、品質管理としてはどのような数値が望ましいのでしょうか。

下図を参照ください。



「品質管理」を考える際には、「成果物」に対する「品質管理」と「作業」に対する「品質管理」の２つの観点から考える必要があります。「成果物」に対する「品質管理」は「成果物」が出来上がらないとチェック出来ないのに対して、「作業」に関する「品質管理」は「成果物」の作成途中でチェックが可能になります。

では、「成果品」に対する「品質管理」に意味がないかというとそうではありません。最初の例で「完成したシステムの〜」と意図的に入れたのはそのためです。つまりプロジェクトの最終目標の「成果物」となる完成したシステムではなく、途中の段階の「成果物」に対する「品質管理」をすればいいのです。
もう少しわかりやすくいえば、システムの障害（バグ）をなくすために、最終的なテストだけでなく途中の段階で「単体テスト」とか「結合テスト」といったテストを実施していると思いますが、これらは最終的なシステムの部分的な「成果物」であるプログラムをテストしているわけですが、こういった開発途中でのテストを実施することで、プロジェクトの進行途中での品質管理をすることが可能になります。
もちろん、最初に書いたとおり、「品質管理」をするためには数値化が必要なので、計画時に途中の段階での目標数値を設定して、プロジェクトの実施段階においてその目標数値が守られているかを確認していくわけです。

もう一方の「作業」に対する品質管理ですが、こちらは最終的な「成果物」に対して直接的に品質をあげるためのものではありませんが、「成果物」を作成する作業の品質をあげることで間接的に「成果物」の品質をあげていくというものになります。
例としては、レビューの時間や指摘件数であったり、会議の開催にあたって何日前までに関係者に資料を配付して会議終了後の何日までに議事録を作成したりといったものになります。

いずれにしても、数値目標を設定しただけでは「管理」とは呼べないので、定例会議等でその数値を確認して目標を達成していなければ是正をしていくといったことが必要になります。