基幹システムの刷新でトラブルが起きやすい典型パターンは、旧システムの機能を、現状のまま新システムに載せ替えるケースだ。既存システムには自社業務や業界慣習に基づく機能を組み込んでいる。こうした機能を「現状のまま」新システムに反映させるのは本質的に難しい。
既存のレガシーシステムを新システムにリプレース（置き換え）する。近年の基幹システム刷新プロジェクトの多くはこのパターンだ。
プロジェクトを始めるきっかけは、メインフレーム、オフコン、OS、パッケージ、ミドルウエアなどのサポート切れが多い。まったく新しいシステムを一から開発するよりも、既存システムの機能をそのままに、新システムへと置き換えるほうがリスクは少ないように見える。
ところが、システム開発トラブルの多くはこのパターンのプロジェクトで起きている。
日本の企業は20年から30年くらい前に、販売管理、生産管理、会計管理などの基幹システムを相次ぎ構築した。試行錯誤し、苦労を重ねながらシステムを構築した企業も多かった。
その後システムを使いこなすにつれ、自社の業務や業界慣習に適合したシステムに進化させていった。
一部には「緑色の画面が古臭い」とか「Excelにデータを落としにくい」といった不満を言う利用者もいるだろうが、数十年前に構築した基幹システムを今も業務運営のベースとして活用する企業は多い。この場合、利用者に新たな機能の要望を聞いてもすぐには出てこない。既に利用者の要望を十分に反映しているためだ。
こうした企業でシステム刷新プロジェクトを立ち上げても、利用部門は「現状の仕組みがそのまま動けばいいので、情報システム部とITベンダーで進めてほしい」と言い出すのが一般的だ。
経営者は「現行システムをそのまま置き換えるだけなら大きな問題はないだろう」と考え、システム刷新プロジェクトを甘く見ることがある。
ところが、この「現状のまま動かすプロジェクト」ほど、トラブルの危険性を秘めたプロジェクトはない。以下、上場企業である中堅部品加工会社（A社とする）が陥ったトラブル事例をベースに、どのような落とし穴があるのかを紹介する。
ハード保守切れがきっかけ
A社がシステムの入れ替えを検討し始めたきっかけは、既存オフコンのハードウエア保守が切れる見込みだったためだ。
既存システムは、情報システム部の社内要員が30年以上にわたってCOBOLで構築してきた。アプリケーションには利用部門の要求に合わせて細かい機能も作り込まれている。ただし、継ぎ足しを繰り返した内製システムのため、設計書はほとんど残っていなかった。
A社は現在使っているオフコンのベンダーに、既存のアプリケーションをWindowsサーバー上に置き換える費用の見積もりを依頼した。ベンダーからは、アプリケーションプログラムを一から書き直すスクラッチ開発による移行の場合、10億円以上の開発費がかかるとの見積もりが届いた。
ハードウエア基盤を入れ替えるためだけに10億円の投資を申請しても、役員会は承認しそうにない。そこで情報システム部は、国産ERP（統合基幹業務システム）パッケージによる刷新を企画した。
ITベンダー4社にRFP（提案依頼書）を出したところ、ある国産ERPパッケージベンダーから「現状システムに合わせるカスタマイズを含めても5億円程度で開発できる」という提案があった。
提案には、現システムでは弱い生産計画系の機能強化も含まれていた。提案にあった機能強化を前面に出して上申したことで、役員会ではすんなり承認された。
情報システム部は利用部門にも入ってもらって要件定義を進めようと考えていた。ところが、利用部門は現行システムに不満を感じているわけではなかった。
利用部門は日常業務を犠牲にしてまで要件定義に加わる必要はないと考え、プロジェクトから次第に遠ざかるようになった。「現状システムと同じことができればそれでいい」。いつのまにか要件定義は情報システム部とパッケージベンダーだけの作業になっていった。
