プロジェクトをの目的はQuality, Cost, Deliveryと書きました。ここでは、プロジェクトの品質をどう保つのだろうう、ということを考えてみました。なかなか、「品質」を保つのは難しいですよ。

品質とは

プロジェクトの品質が高い、とは、プロジェクトの結果に対する関係者の満足度合、と定義できます。つまり、プロジェクトを始めるときに、「こういったものがほしいな～。」と思い、その「ほしいな～。」が想像どおりのものがでてくれば、OKということです。ITシステムであれば、想定していた機能が充足しており、かつ、操作性もよい、ということが品質になってきます。

関係者の思惑の違い

まず、最初の難題として、関係者がプロジェクトの目標、工程について色々な考え方を持っている、ということです。みんなが一丸となって、、というのは、格好がいいのですが、なかなか、そうはいかず、色々なところで紛糾をしてしまうようになります。

経理システムであれば、経理スタッフであれば入力しやすいもの、がいいでしょう。他方、経理部長であれば、経理スタッフのモニタリングがしやすいもの、がほしい、と思うかもしれません。取締役とか偉い人になれば色々指標がわかるもの、内部監査であればきちんと統制が効いているもの、というように、ITシステムに色々と期待するものです。これを全部、相手にしているといつまでたってもシステムの仕様が決まりません。

そういう場合は、当初の一番の原点に立ち返る、キーマンを見出してその人に働きかける、定例会議等で随時目的を確認する、ということがあげられます。

期待値の違い

通常、プロジェクトをする側とそこから利益を受ける側の期待値に差があります。特に、これはプロジェクトに際してコンサルティングを利用するときに起こりえます。利用する側はそれなりな報酬を払うことによりプロジェクトの成果について過大なものになりがちです。それに対して、コンサルティングであってもできることに限りがあります。ここに大きな差があるので、随時ここは修正していくことが大切です。

大切なことは、まず、最初の段階でできる限り具体的にどんなことをするのか、それぞれの役割分担はどうなっているのか、前提を作っておくこと。最初のうちは、「あれができますよ、これもできますよ。」といいがちですが、こうやって期待値を膨らませすぎると、後後その調整に苦労することになります。また、プロジェクトの最初はゴールが不透明だったりもするのですが、少しずつ期待値を合わせていくことが必要です。

ゴール、道筋があいまい

あとは、プロジェクトについて具体的な成果物や方法が当初はあいまいだったりすることもあります。プロジェクトをする場合は目的はあるわけなのですが、それが抽象的な事項で具体的なイメージが持てなかったり、経験がないためそこへの到達点が見えなかったりします。それを具体化する、ということがなかなかできなかったりもします。

システムの開発などでよくとられる手法が要件定義。これは、クライアントからの要望を各部署から聞き、それをまとめて具体的なシステムのあるべき姿を作成します。これに基づきシステムを開発していくことになります。また、成果物のサンプルを早目早目に提出しそれをもとに具体的な成果物を作成していく、という手法も取りえます。つまり、なにもないと、いつまでたったも抽象的な議論から抜け出せませんが、なにか目に見えるものがあれば、それをもとに議論を進めることができます。

まとめ

以上のようにプロジェクトの品質、といっても、人によってとらえ方が違う、特に期待値の差が出てしまう、ということがあります。また、ゴールそのものが不透明である、ということも品質の担保を難しくします。これをうまく解消していくことが必要です。