スケジュール通りに進まず一向に終わりの見えないプロジェクト、無事カットオーバーを迎えたがほとんど利用されないまま何年も放置されているシステム、稼動直後からトラブルを発生し利用者に大混乱を引き起こすシステム、運用が複雑で機能拡張もままならないシステム……このようなシステムの話題がたびたびメディアで取り上げられている。

このような失敗プロジェクトには、そもそもシステムに求められる要件を十分に詰めきれないままSIerへの発注を行ってしまったものや、要件を明確にしたつもりでいても、SIerとの間での意思疎通が図れず、要件に関する認識に違いが生じたことに原因があるものが多い。

このように要件が曖昧なままシステム設計/構築を始めると、完成間近になって「こんなはずではなかった」ということになる。慌てて機能の追加や変更を要求することになるが後の祭りである。影響範囲が大きく仕様変更を繰り返す。これではいつまで経ってもシステムは完成しない。

ついには仕様の追加/変更をあきらめ、その皺寄せは運用に送られる。運用部隊では無理な運用を強いられ、運用費用は大きくなるばかり。また、複雑な運用手順はオペレーションミスを発生させるリスクをはらんでいる。このように運用を考慮していない設計が、障害時の対応をより複雑なものにしている。

機能拡張のニーズがあっても、どこにどう手を入れていいのやら。付け焼刃で機能追加/修正を繰り返したためにシステムは複雑化し、機能拡張のための調査や設計開発に要する費用も膨らむ一方である。最近の調査では、企業における全システム投資のうち、運用保守に充てられる費用は6割を占めている。しかし、現場は想像以上に多忙を極めている。

このような事態を防ぐには、どうしたらよいのだろうか。本稿では、SIerにシステムを発注する際、発注側はどんなことに気をつけるべきなのか。開発の終盤に機能追加要求などを行うことを回避するには、どのように発注すべきなのか。発注のタイミング、要件定義書、SIerに提供すべきデータなどについて、発注側が注意しなければならないポイントをまとめる。

マイコミからのお知らせ

5月29日発売の『システム開発ジャーナル Vol.4』に特集2「SIerに仕事を頼む前に読む - "IT調達力"の鍛え方」が掲載されています。そちらもぜひ、あわせてお読みください。