ビジネスとITのギャップを埋めるのは誰？：情シスをもっと強くしよう（1）（2/4 ページ）

[林浩一，＠IT]

費用対効果低下のサイクル

開発ベンダ　「要件定義の結果ですが、想定の金額をかなり超えて、開発にかかる費用は約10億円になります」

発注企業　「え？ それじゃあ、当初の見積額の2倍じゃないですか！」

開発ベンダ　「申し訳ありませんが、御社からの要求機能が当初の想定から大幅に膨らんだためです」

発注企業　「だからといって、こんな額を急に出されても困ります。何とか費用を抑えることはできないんですか？」

開発ベンダ　「それについては提案があります。機能の一部に弊社パッケージを採用すれば8億円くらいで済むのですが、どうされますか？」

　これはシステム開発を、要件定義から請け負っている開発ベンダと、発注側の情シス部門との間のやりとりです。多少脚色していますが、実際の事例に基づくものです。

　読者の皆さんもよくご存じのように、システム開発プロジェクトが大幅に遅延したり、予算を超過したりするケースは非常によく起こっています。この例のように、実現するべき要件が膨らんでしまって、予算を大幅に超過してしまうのはその典型例です。

　このような場合、超過した費用を受注側が全額負担する場合もありますが、発注側に負担が求められるケースも珍しくありません。どちらがどの程度負担をするべきか、遅延の原因がどちらにあるのかを示すための資料作成に余計な時間と労力を使ってしまい、手を打つタイミングを逸してさらに事態が悪化することもよくあります。

　システム開発の実感を持っていない経営者の多くは、出来上がるシステムに対して、「その開発に必要なコストが高過ぎる」という感覚をもともと持っています。そのうえ、大きなコスト超過の話を聞かされると、ITに対する不信感が増し、投資に対してより慎重になっていきます。

　このために情シス部門は体制が不十分な中で、常に必要な額に足りない予算でシステムを作ることを求められています。そのため、少しでも安い開発ベンダに成果物責任を持ってもらう形で丸投げすることになります。

　しかし、最初にいくらコストを圧縮しても、無理な予算で進めた開発が破たんすれば、その効果はすぐに相殺されてしまいます。一方で、「最初に予算を圧縮した分の機能・品質面で不十分なシステムとなるため、結局費用対効果が低下してしまう」という悪循環が起こります。

　次に開発ベンダの視点を見てみましょう。

業者依存深刻化のサイクル

開発ベンダ　「ご要望いただきました御社の現行システムのデータベースの設計情報の提供ですが、見積もったところ、約1億円になります」

発注企業　「え？ でもこの現行システムは御社に作ってもらったものですよ。その設計データの情報を出してもらうのに、何でそんなに費用がかかるんですか？」

開発ベンダ　「もともと設計書は納品物に入っていませんでしたから、新規に作成する必要があります。構築後の修正個所などを確認し、正確な情報にするにはそれなりの工数がかかるのです」

発注企業　「しかし、その設計データがないと今後の改修が大変になるんですよ。何とかなりませんか？」

開発ベンダ　「では、その改修についても弊社にやらせてください。御社のシステムを知らない他社にお願いするより、結局コストも安くなると思いますがいかがでしょう」

　こちらは別の開発ベンダと発注側企業とのやりとりですが、やはり実際の事例に基づきます。

　コスト削減の要請が厳しくなるにつれて、システム開発は開発する側にとって“非常にリスクの高い仕事”になっています。受注する開発ベンダが専門家だといっても、開発プロジェクトには見通せない出来事が必ず起こり、その対応を間違うと期間やコストがすぐに超過してしまうからです。

　そして、その出来事を見通せなかったことについて、発注側は受注側の責任ととらえ、開発範囲の修正などに応じない、というケースはよくあります。そのリスク分を見積もりに含めることができればよいのですが、RFPによるコンペのような場合には「まず受注すること」を優先するため、そうしたいざというときの部分は削り、ぎりぎりの運営を強いられることになります。

　開発で収支が合わなくなってしまった開発ベンダは、1回の開発だけで収支を合わせられず、その後の保守や追加開発を行うことで「全体で収支を考えるビジネスモデル」を採らざるを得なくなります。特に独自のパッケージ製品やハードウェア製品を入れることができれば、その保守を含めた収益で、長期的にビジネスを安定化させることが可能になります。いわゆるベンダロックインです。

　このようなトータルサービス化はそれがユーザー企業の求めるものならば、必ずしも悪いわけではありません。

　ただし、特定業者への依存度が高くなってしまうと、いろいろな弊害が発生します。上述のエピソードは極端な例ですが、どうかと思うような割高の見積もりはよく見られます。また、このビジネスモデルでは開発されるシステムの機能や品質は少々低くてもよくなってしまう、ということにも注意が必要です。

　受注側としては、多少問題が残っていても後から追加開発すればよいからです。

　そう割り切ってしまえば、開発側に優秀な要員を配置する必要もなくなります。結果として、緊張感が失われ、システム開発が失敗するリスクは高くなり、ますますメインである開発以外での収益に依存する悪循環になります。この状態が続くと、ユーザー企業はトータルで見ると、“高い追加開発と保守のコストをかけて品質の低いシステムを改修し続ける”ことになってしまいます。

　続いて、開発技術者の視点に移ります。