ちょっと、複雑な注文を考えましょう。例えばパソコンです。パソコンは、店頭に出ているスペックと同じ物を買うだけではありません。基本仕様に対して、CD-RドライブをDVDドライブにするとか、128MHzのメモリにさらに128MHzを増設するとか、CPUを最新のものにするとか、Diskを増設するとか、ディスプレーは今もっているのを使うから要らないとか、オプションを重ねた注文をすることができます。必ずしも店の在庫に客の注文と同じ物があるわけではないですから、メーカーにオーダーが流れます。メーカーでは、客の希望通りに、組み立てて出荷します。
また、自動車も販売店で実際に見て車種を決めますが、そこで持ち帰れるわけではなく、メーカーへ注文し、組み立てられたら納品という流れになります。ここでも、カーナビを付けるか、CDにするかMDにするか、カセットデッキはどうするか、シートは基本仕様のままでいくのか、車体の色はどうか、外車であればハンドルは右か左かといったところを細かく検討して注文します。
パソコンであっても、自動車であっても、実際に目で見たのとは別の商品として届けられます。そこで、問題になることはほとんどないでしょう。DVDにしたはずが、CD-Rだったということはあるかもしれませんが、注文通りの仕様になっていれば、まずクレームは発生しないと思います。
また、いろいろなオプションを組み合わせる時に、欲しいものは何でも付けてしまうということは、通常有り得ません。たいていの場合、予算が決まっているからです。パソコンなら25万円、自動車なら130万円といった、消費者それぞれの都合による上限が決まっています。ですから、あれを付ければこちらは駄目、これを削ればあれが付けられるといった葛藤の中、あれこれ工夫し、どうにか納得のできる購入ができるようにします。購入時はあきらめて、余裕ができたら、新しいパーツを組み込もうという考えもあるでしょう。カーナビは、あとで買えばいいやとか、Diskは容量が足りなくなったら買い足そうと思うことで、初期購入額を抑える努力をするはずです。
まず、関係部署間の問題です。部門Aはこうしたい、部門Bはそれでは駄目だ、といった各部門のエゴがぶつかりあって、仕様がまとまらないことがあります。また、情報システム化は、業務そのものの再構築も並行して行いますから、今まで部門Cで担当していたことを部門Dでやった方がよい、とか、顧客の要望に応えるために新たに出荷予定日を知らせる機能をつけて、それを部門Eで担当してもらおうといった話が出てくると、新しい仕事が増える部門は反発します。ですから、｢4-1.参画させるメンバーと体制｣で述べたプロジェクトマネージャーがきちんと調整したり、会社全体を考えた仕組み作りを推進することが重要なのです。
次に、予算の問題です。情報システムは、注文をつければ、それなりに作れてしまいます。開発担当者が｢それは無理です｣と答える場合、技術的に不可能というよりは、予算、納期、パフォーマンスから無理がある、という意味にとった方が正しいです。ほとんどの社員は、現行の情報システムのどこかしらに不満を持っており、機会がある度に改善要望を提出しています。ですから、新規開発となると俄然、不満点をすべて解決しようとするものです。ですから、とにかく、注文をつけまくるのですが、注文を増やせば増やすほど、それは費用に跳ね返ってくるのです。自分の車やパソコンを買う時はしっかり妥協するのに、経費節減の必要性があれば昼休みに照明を消したりエアコンの温度を調整したり、生産性をあげるために業務改善を繰り返したりするのに、会社の情報システムに関しては、どうしたわけか妥協をしなくなります。予算は限られているのですから、しっかり取捨選択をしなければなりません。プロジェクトマネージャー、メンバー全員が、この点を認識する必要があります。
それに、開発が始まってから、仕様を変更することもよくあります。確かに、机上だけで仕様を決めれば、後になって、これでは駄目だとなることがあるのもわかります。しかし、スケジュールの後期の仕様変更が多くなれば、プログラム修正、作り直し、テストのやり直しのため作業時間が増大し、その分、費用に加算されます。また、同時にスケジュールの遅延を招きますし、品質の低下も否めません。このようなリスクをきちんと把握していなければ、情報システムの購入は失敗するだけです。中には、失敗していても失敗していないふりをして、上層部にうまく誤魔化して報告してしまうプロジェクトもありましたから、困ったものです。