前回に続いて、システム構築ビジネスの特徴である“あいまい性”がテーマである。仕様が定まりにくく、規模が膨張するソフトの難しさに、プロジェクトは常に悩まされている。
 |
発注仕様書は発注側から見ると明解に見えても、注文を受けて開発する受注側から見ると「あいまいだらけ」というのが現実である。
これはユーザーがITベンダーに出す仕様だけの話ではない。主契約を結ぶITベンダーから、各ITベンダーに渡される仕様も、そして各ITベンダーがパートナー企業や外注先に出す仕様書でさえ、あいまいなものが多い。いずれも、発注者と受注者の間の常識差や経験差が大きく影響していることは否めない。
しかし、最終的に困るのは受注者である。それだけに、発注者から要求仕様や機能仕様が提示されたなら、速やかにあいまいなところを必死に拾い出し、質問し、解決してしまうことが大事である。後に持ち越してはいけない。
 |
発注仕様書について発注側は、ちゃんとしていると思っていることがほとんどだ。当人は、自分がやりたいことを書くのだから、当然仕様をよく知っており、自分で書いた仕様書を読み直しても、なかなか不明瞭なところに気付かないのである。
これは、ITベンダーと外注会社の間でも全く同じである。最近は中国やインドなどへの発注が増えているが、いくら基本コストが安くても、発注仕様があいまいで多数のオンサイトSEや、ブリッジSEが必要になっては、原価低減効果は大幅に減殺されてしまう。
自分の書いた発注仕様書は、「きっとあいまいであるに違いない」と謙虚に考え、どう書けばあいまい性を排除できるかを真剣に考える必要がある。
 |
IT業界の経験則の一つに、「2-4-2-3の法則」がある。
要求仕様段階では開発すべき要件は半分しか見えない（4分の「2」）。全体像が見えたころには要求は2倍に膨らんでいる（4分の「4」）。だが、予算は増えない（4分の「2」のまま）。そのままでは大赤字になってしまうので、ユーザーとITベンダーが折衝し、色々とやりくり算段してこぎつけるのが1.5倍（4分の「3」）の線、ということだ。
仕様は膨張するのが常であり、SEはそれを見越すとともに、ユーザーにもシステム膨張の不可避性をよく理解してもらい、少なくとも当初予算の50％以上の予備費を用意してもらうことだ。そのうえで、ユーザーとITベンダーが一緒になり、必死に膨張抑制に臨むことが何よりも重要である。
 |
実現すべき機能は同じでも、その機能を実現するためのシステム構成や実現方式は“千差万別”だ。当然、かかる費用も1桁以上の差が出る。
例えば性能要件の差である。高性能が要求されれば、より大型のコンピュータが必要になるし、サーバーの台数を増やす必要もでてくる。高信頼性を求められれば、バックアップ機やそれを制御するためのソフトも必要になってくる。ソフトに限っても、ほぼ同じ機能を実現できるパッケージを使うのと、オーダーメードで一から開発するのとでは、ソフト費用に非常に大きな差が出る。
表向きの機能が同じでも、実現すべきシステムの違いがコストに与える影響が極めて大きいのがシステム構築の特徴の1つである。
