動かないコンピュータForum


動かないコンピュータ・フォーラム 第32回

システム・コストの節約は「動かないコンピュータ」を呼ぶか

動かないコンピュータ・フォーラム 主宰者
中村 建助=日経コンピュータ編集

日経コンピュータを読む理由No.1 「動かないコンピュータ」連載が単行本になりました

 【「日経コンピュータ Express Mail 2003/07/10」にて、今回の新テーマを7月10日中に公開予定、と予告しましたが、事情により1日遅れとなりましたことをお詫びします。】

 長引く不況の影響を受けて、システム・コストの節約に頭を悩ます企業が増えているようだ。記者が取材していても、システム・コストをどうやって削減すべきかについての話を聞くことが多い。

 本誌は最近、「システム・コストはまだ削れる」「ITコスト99の謎」と、システム・コストに関連した二つの特集を企画したが、読者からの反響も高かった。

 しかし、システム・コストの削減は良いことばかりなのだろうか。暴論かもしれないが、記者はシステム・コストの削減が「動かないコンピュータ」を増やす可能性もあると考えている。そこで、今回のフォーラムでは、システム・コストの節約と動かないコンピュータの問題について考えてみたい。

 いつものように、今回のフォーラムに対する、皆さんからのご意見をお待ちしています。皆さんのご意見は、このページの下方にある「Feed Back!」から書き込んで頂けるようになっています。

「とにかくコストを下げる」は危険

 システム・コストの節約が、「動かないコンピュータ」を増やしかねない最大の理由は何か。合理的なシステム・コストの削減の基準が、現状では存在していないことである。“まず経費削減ありき”で本来必要なシステム・コストまで削ってしまえば、様々な問題が起きて当然だからだ。

 特に記者が問題だと思うのは、システムの開発コストの削減である。ソフトの開発過程は特に、どの程度のコストが必要なのかを事前に把握することが難しい。プロジェクトの途中で開発コストを削減しようとすれば、大幅な設計変更を実施せざるを得ない。そうなれば開発に大幅な手戻りが発生して、かえって開発コストは当初の見込みよりも拡大する可能性すらある。

 プロジェクトの予算が削減されることになれば、人件費の安い外注先を利用して開発コスト削減の影響を減らそうとするベンダーも出てくる。外注企業を利用すること自体に問題はないが、予算の削減を第一に考えて外注分を増やせばソフトの品質の低下につながりかねない。

 システム・コストを節約するために、ベンダー選定の際に見積もり価格ばかりを重視する傾向が強くなるのも問題だ。必要以上に高いコストでシステムを開発するのは論外だが、安価な見積もりを提出したベンダーがシステム構築のパートナーとして最適である保証はないからである。

システムが利用できずコストが増える

 少し前に記者は、既存の基幹系システムを再構築しようとしたある中堅企業を取材した。この中堅企業は、開発コストの削減を最優先してシステムを開発しようとして、「動かないコンピュータ」を生んでしまった。

 この企業は、長年にわたって基幹系システムの再構築を考えていたが、開発コストがネックとなった。この不況の折、この中堅企業の業績も好調とは言い難かった。同社はいったん既存のシステムを開発したベンダーのA社に再構築を任せようと考えたが、ベンダーが提示した「数億円」という見積もり金額が高すぎると判断した。

 そこでA社に再構築を任せることは断念して、「数千万円で基幹系システムの再構築を手掛ける」という、別のベンダーB社に開発を任せることにした。コスト優先でベンダーを決めたわけだ。

 システムを開発することになったB社は、この中堅企業の望む費用でシステムを開発する条件として、「開発は共同作業で進めること、完成したシステムをパッケージ化して外販すること」の2点を要求した。開発コストの削減を最優先していた中堅企業はこの条件を了解した。

 しかし、B社によるシステムの再構築は順調には進まなかった。B社が、この中堅企業の業務をよく知らないままシステムの開発を進めたため、多くの手戻りが発生した。その結果、テスト期間を十分に取ることができず、大量のバグを残したままでシステムを稼働させることになったのである。中堅企業とB社は必死になってバグを解消しようとしたが無理だった。

 最終的に、この中堅企業はB社の開発したシステムの利用をあきらめて、また別のC社に基幹系システムの再構築を任せることにした。

 だが、この中堅企業は、利用しなかったシステムの開発費をB社に支払った。正常に稼働しなかったとはいえ、B社はシステムを完成させており、共同開発である以上、システムの完成度が低かった原因は中堅企業にもあると判断したからだった。

開発の凍結にも落とし穴

 システム・コストの削減によって、システムの開発自体が凍結されたり、白紙になったりするケースもある。こうしたケースも、場合によっては思わぬ追加開発やシステム投資の増加を招く可能性がある。

 IT関連の変化は速い。現在は最先端の技術であっても、開発を凍結しているうちに陳腐化して、稼働時点で見れば割高なシステムを開発することにもなりかねない。システム投資を凍結している間に、企業そのものが変化して、当初考えていたシステムが実体に合わないものになることもあり得る。

 たとえば今年2月には、住友信託銀行、松下電器産業、花王、全日本空輸(ANA)4社が共同で開発を進めていた人事システムで、ANAが新システムへの移行をしばらく見合わせることが明らかになった。開発作業への参加は継続し、開発費用も負担するものの、ANAは「情報システム関連の投資を全面的に見直している」ことを理由に、このシステムへの移行を凍結した。すでにこの人事システムは、3社が先行して利用する形で4月から稼働を開始した。

 ANAがいつからこの人事システムの利用を開始するのかは不明だ。だが、あまり長い間移行を凍結していると、システムの要件の前提となっている同社の人事体系や組織構造が変わる可能性がある。そうなれば、この共同人事システムを利用するとしても、再度、変更した組織や人事体系に併せて追加開発しなければならない。仮にANAがこういった状況を迎えた場合には、「人事システムを共同化することで、開発を効率化しコストを削減する」という当初の狙いを完全には実現できないことになる。

 日本企業の変革も徐々にではあるが大胆なものに変わりつつある。社内体制の変化などにとどまらず、不採算事業の売却や有望企業の買収など、社外を巻き込んだ大規模な変化が生じるようになってきている。りそなグループのように、システム戦略の根幹を占めるシステム統合計画を白紙で再検討するような例もある。システム部門では想定していなかったような、大規模なシステム投資の見直しが現実に起きる時代だということはしっかりと認識しておくべきだろう。

 ここからが本題です。ITコストの節約という努力をシステム・トラブルの増加に結びつけないためには、どのような方法が有効なのでしょうか。

 まず自分たちの手で合理的なコストの削減基準を設けることなのでしょうか。それとも、不合理なコストの削減要求に対しては、「一時的にはコストが削減できたように見えても…」と強く異を唱えることなのでしょうか。

 システム・コストの削減を「動かないコンピュータ」に結びつけないためにはどうすべきなのかに対する、皆さんからのご意見をお待ちしています。


 今回のテーマへの投稿は7月28日(月曜)で締め切らせて頂きました。ありがとうございました。みなさまのご意見を基にした総括記事は、7月31日木曜に当サイトで公開する予定です。