オフコンのサポート停止を受けて、オープン系のパッケージソフトに移行する企業は多い。だが、パッケージベンダーが突然、サポート停止を宣言するリスクは意外に知られてない。停止の理由はベンダーの廃業や買収、OSの更新に追従できないなど様々だ。ユーザー企業はパッケージ導入に当たり、サポート停止のリスクを勘案しておく必要がある。

 東芝、三菱電機と並んで1980年代にオフコン御三家の一角を占めていたNEC が2015年、オフコンの新規モデルの販売を停止した。ユーザーはシステム移行の準備におおわらわだろう。

 オフコンやメインフレームなどのレガシーシステムの販売やサポート停止を受けて、オープン系のパッケージソフトを使ったシステムに切り替える企業が増えている。

 企業がパッケージを選ぶ典型的な理由としては「オープン系のプログラム言語でシステムを開発できる要員がいない」「スクラッチ開発すると高く付き、いくらかかるか分からない」が挙げられる。レガシーシステムのベンダーや代理店がパッケージの利用を推奨していることも一因だろう。

 ところが、レガシーシステムからオープン系のパッケージに切り替えた企業から「こんなはずではなかった」という悲鳴に近い不満を聞くケースがある。ベンダーが突然、パッケージソフトのサポートを停止すると宣言してきたという話だ。レガシーシステムに続き、オープン系のパッケージでもサポート停止に見舞われたら、泣き面に蜂というほかない。

 今回はパッケージベンダーからサポート停止を宣言されたA社の事例を紹介する。

図 A社がオフコンからオープン系への移行で陥ったトラブル
パッケージソフトが突然サポート終了に
[画像のクリックで拡大表示]

オフコンからパッケージへ切り替え

 A社は中堅の機械部品商社である。かつて運用していた販売管理システムは、オフコン用パッケージをベースに自社でカスタマイズして構築したものだった。開発言語はCOBOLと簡易言語である。

 A社が使っていたオフコンのメーカーは、7年前にオフコンのサポートを停止した。これに合わせてA社も、オフコンを購入した代理店が推薦したB社製のオープン系販売管理パッケージを使ったシステムに切り替えた。

 A社の情報システム部は、新システムのカスタマイズ開発も、オフコンの時と同じく自社主体で行いたかった。だがA社には、オープン系のプログラミング言語に精通した情報システム部員がいない。

 そこでA社は仕方なく、パッケージベンダーのB社にカスタマイズを依頼した。依頼に当たりA社は「オフコンと比べ、システムの機能を落とさないように」と要望。このためB社はパッケージを大幅にカスタマイズした。

 パッケージソフトの使い勝手はオフコン用ソフトよりも劣ったが、B社が大幅にカスタマイズした結果、実用上大きな問題のないシステムになった。

 当初はユーザ部門からの不満の声もいくつか聞かれたが、時間が経つにつれ不満やクレームはなくなった。A社は当分の間、本システムを使い続けるつもりでいた。

突然のサポート停止、原因はOS

 ところが最近になってB社が、現在のパッケージソフトのサポートを停止するため、新しくリリースした同社製の別の販売管理パッケージに乗り換えてほしいと言ってきた。

 サポートを停止する理由は、現行のパッケージがWindowsの最新バージョンに対応できない作りになっていたためという。B社は、度重なる機能追加で複雑になった現行のパッケージを最新のOSに合わせて改造するより、新たにパッケージを開発し直した方が対応しやすいと判断したようだ。

 A社の担当者は最初にこの話を聞いた際、それほど大きな問題になるとは思わなかった。いくら新しいパッケージとはいえ、同じベンダーが開発する製品なら移行は簡単だろうと考えたためだ。B社とはパッケージソフトのメンテナンス(保守)契約を交わしていたため、新パッケージも無償で購入でできると思い込んでいた。

 大幅にカスタマイズした機能の移行作業についても、ソースコードやデータを変換するコンバージョンツールを使えば簡単に移行できるだろうとA社の担当者は考えた。

 OSのバージョンアップはオフコン時代にもあった。その時はオフコンメーカーが用意したコンバージョンツールを使うことで簡単に移行できた。コンバージョンの作業もオフコンの代理店が無償で実施した。

 A社の担当者はこうした過去の経験から、今回もパッケージベンダーのB社がコンバージョンツールを用意して実施するものと信じて疑わなかった。

次ページ以降は日経 xTECH Active会員(無料)の方のみお読みいただけます。