プロジェクトの品質は何で決まるか

on

プロジェクトで品質を取り上げると

・テストでバグを出さない
・テストでバグが出たら直す

 とテストまで漫然と進めてきたことをテストの段階になって初めて真面目に考えているんじゃないかと思えるプロジェクトが少なくないのは何故なんなんでしょうねぇ。

例に挙げた

・テストでバグが出たら直す

なんてとても筋が悪い考え方の代表ですし。

・テストでバグを出さない 

 こちらは出さないために何をしてきたかが問われますけれど。もし、出さないための方策をしてこないのにバグを出さないなんて言っているとしたら、これは隠蔽体質があると思って間違いないでしょう。

目標とQCD

プロジェクトがあるとして、そのプロジェクトには目的があるわけで、その目的から定量的な目標を設定するときにはじめて品質を定量的に語れるようになるわけです。場合によっては定性的な目標の場合もありますが、第三者が客観的に理解できる表現でなければ目標とは捉えにくくなるのでその辺の配慮は必要です。

教科書的にいえば、目標はQCDで表します。各辺にバラすとこんな感じですね。

品質　｜－－－－＋－－－－｜コスト

コスト｜－－－－＋－－－－｜納期

納期　｜－－－－＋－－－－｜品質

 で、今はどの辺の長さのバランス、－品質とコストもコストと納期も同じに－、になっているわけですが、実際のプロジェクトではこうはいかないよね、と。

大概、お金がいないとか人が足らないとかいうわけです。無い袖は触れないわけで、でもそれでいいのかといえばそうではなくて。

じゃあどうするかと。

優先順位のスライダー

じゃあ、QCDに優先順位をつけましょう、と。あれもこれも全部はできないのはわかっていますし、それは他者から与えられている条件ですから、

制約条件

な訳です。コントロールできないのであれば、はっきりと、プロジェクトを始める最初に宣言しなければならないことです。

先ほどの各辺にスライダー（△）をつけて、これを目盛りに沿ってスライドさせます。コストを優先（少ない予算で執行）するのであれば、品質はその予算の中でしかリソースを回せません。 

品質　｜－－－－＋－－－－｜コスト
　　　　　　　←△→

コスト｜－－－－＋－－－－｜納期
　　　　　　　←△→

納期　｜－－－－＋－－－－｜品質
　　　　　　　←△→

できることしかできないけれど、できることをこれを理由にやらなくていい、というわけではありません。それは専門家としての倫理に関わることですので。

プロジェクトの品質 

各辺の優先順位のスライダーを決めたら、これは顧客と合意しなければなりませんし、その合意はとても大切なイベントです。

何故なら、プロジェクトとして判断をする際の立ち戻るテーブルだから、です。

そして、この合意こそがプロジェクトの品質を語るものです。業務要件からプロジェクトを企画し、プロジェクトチームを編成してプロジェクトの目標を設定する中で決めていくこれらのプロジェクトのQCDはプロジェクトに求める品質に値するものです。

プロジェクトマネジメントの各管理プロセスに強く影響するのがプロジェクトの品質で、これが無いのに品質管理もへったくれもありはしません。

これが無いから、テストでバグが出たら直すとか寝ぼけたことを言わせることになるのです。

プロジェクトの品質でそれをどう実装していくか、開発プロセスや仕様が織り込まれているかをどう検証するか、実装さているはずの機能をどう証明するかを考えなければなりません。

そのためにプロジェクトの品質が必要になるのです。