プロジェクトマネージャは全体をコントロールしなければならなりません。ステアリング委員会に正確に報告し、ユーザ側の要望をしっかりまとめ、それを確実に開発側に伝わるよう配慮し、開発の進捗状況を把握し、どこに問題があっても速やかに解決しなければならないのです。しかし、よくあるのは、こういうことです。

プロジェクトマネージャが、完全にユーザ側に立ってしまい、ユーザ側から噴出する要望を抑え切れず、どんどん開発側に流してしまいます。開発側は初めは抵抗するのですが、結局押し切られてしまい、無理なスケジュールで開発を進め、品質の低いソフトを納品してしまうのです。このような状態で、ソフトの品質が低いのはISとソフトハウスの責任だ、などとステアリング委員会で、開発メンバを非難するのはお門違いです。プロジェクトマネージャは、すべての責任を負っているのですから、仮にソフトハウスに責任があるとしても、それをコントロールできなかった自分自身が駄目だったのです。

ソフトハウスの能力をチェックし、ソフトハウス内の体制をチェックし、その上で進捗状況を把握しなければなりません。仕様変更においては、負荷のかかり具合を計算して、スケジュールや品質に問題が出ないか、予算は間に合うか等を検討し、大丈夫となって初めて仕様変更の指示を出す必要があります。

普通なら注文すればほったらかしで良さそうにも思えます。確かにソフトハウスに発注した後は、納期に納品されるまではソフトハウスの責任です。しかし、ソフトハウスが仕様を正確に理解しているかどうか、しっかりした技術を持っているか、仕様変更が増えてアップアップになっているではないか、そういったことは、発注元がしっかり管理すべきなのです。きちんと仕様を伝え、ソフトハウスが自信を持って納期内にパーフェクトなものを納めます、と約束したのにも関わらず、まともに動かないソフトを持ってきたとなれば、損害を賠償させることもできます。しかし、お金を払わせればよいというものではありません。予定通りシステムが稼動しないのでは、いくら賠償金をもらっても、やはり困るはずです。

また、品質の確保のためには、できたところから納めさせてチェックするのが妥当です。これは、家を建てる時のチェックとも共通します。欠陥住宅を売りつけられないように、建てている途中で、施工している業者とは無関係の建築士を入れてしっかりチェックすべきだとされています。病院についても、セカンドオピニオンが重要視されてきています。