1月15日,マイクロソフトはWindows98のサポート期限を2006年6月まで延長することを発表した。だが,有償サポート契約を結んでいないとその恩恵は受けられないことや,セキュリティに関する修正プログラムの提供内容に制約があるなど,必ずしもホッとしていられないユーザーも多いだろう(関連情報)

 私はちょうどこの時期「どうする既存資産」という日経システム構築の特集を担当しており,ソフトウエアのバージョン・アップの問題が情報システム運用の大きな負担になっている声をいくつも聞いていた。

 サポート切れの問題は,クライアントOSに限らない。サーバーOSからミドルウエア,フレームワーク,アプリケーションまで市販製品を組み合わせて企業情報システムを構築するスタイルが主流になっている現在,以前よりもこの問題は深刻である。

 サポートが切れた製品は,セキュリティ・ホールや不具合が見つかった場合に対処の手段がない。また,ハードウエアや他のソフトウエアを更新した際に,サポート切れのソフトでは動作保証を得られない。その結果,リプレースの可否やスケジュールが縛られてしまう。

過去のユーザー事例で,利用製品のバージョンとサポート期限を調べてみる

 実際,既存システムで使われている製品はどの程度までメーカー・サポートを受けられるのか。日経オープンシステムのバックナンバーをひっくり返して調べてみた。まず,5年前(99年4月)に稼働したソフト開発・運用会社の「プロジェクト管理システム」。システム構成図から利用製品を拾い上げ,メーカーのサポート期限と照らし合わせてみると・・・

OSは,
Windows NT4.0
→2002年6月にメインストリーム・サポート終了,2003年6月に延長フェーズ終了,2005年12月にサポート終了
Windows95
→2000年12月にメインストリーム・サポート終了,2001年12月に延長フェーズ終了,2002年12月にサポート終了

DBMSは,
Oracle8
→2001年9月にフルサポート終了,2004年9月にアシスタンス・サポート終了

 5年前のシステムとしては,妥当な組み合わせだろう。だが現在では,OS,ミドルウエアとも,修正プログラムを入手できる期限がほぼ終わっている。バージョン・アップを行っていない限り,不具合に対処できない,またはセキュリティ面で脆弱なシステムになってしまっているはずだ。

2年前のシステムならどうだろうと思い,別のバックのナンバーを探してみた。2001年11月に稼働した小売り会社の「モバイル受注閲覧システム」で同じことを調べてみた。

OSは,
Windows NT4.0
→2002年6月にメインストリーム・サポート終了,2003年6月に延長フェーズ終了,2005年12月にサポート終了
Solaris7
→2004年いっぱいで技術サポート(修正プログラム提供など)終了,その後3年で問い合わせの受け付け終了

DBMSは,
Oracle8i
→2004年12月にフルサポート終了,2007年12月にアシスタンス・サポート終了

アプリーション・サーバーは,
WebSphere V3.5
→2003年11月にサポート終了

グループウエアは,
ロータス ドミノ R4.6
→2003年1月にサポート終了
ロータス ドミノ R5.0
→2005年4月にサポート終了

 一部製品はサポートが終了。その他も,そろそろ更新を考える時期に入っている。ただし,このシステムは社内にあった購入済みのライセンスを流用しているためか,この時期にしてはOSのバージョンが若干古い。そこで,同じ時期に入手できる最新バージョンに置き換えてみると・・・

Windows 2000 Server
→2005年3月にメインストリームサポート終了,2007年3月にホットフィックスサポート終了
Solaris8
→未定(Solaris次期バージョン出荷後2年間が修正プログラム提供期間)

 若干余裕は出る。ただ,この小売り会社のように,OSは既存のライセンスを流用するケースも多いので,2年前に立ち上げたばかりのシステムとはいっても,注意を払っておく必要はあるだろう。

まずはリスクを正しく把握する

 サポート切れの問題は,ソフトウエアに限らない。ハードウエアは,保守部品を入手できなくなった時点で修理の手段が無くなる。保守部品の入手期限は,メーカーごとに製品の「補修用性能部品の最低保有期間」を決めている。

 複数の主要メーカーに問い合わせたところ,サーバーやクライアントPCの保守部品の保管期間は,製造中止後(または販売中止後)概ね5~6年だという(ただし,個別契約やオプションで期間をのばせるケースもあるので,個別に確認が必要だ)。つまり,メーカー・サポートを確実に求めるなら,稼働後5~6年でシステムはハード/ソフトともかなりの部分を入れ替えなければならないことになる。

 SAP R/3を導入しているある製薬会社は,サポート期限を守ることをポリシーとし,1年半に1回のペースでバージョン・アップを繰り返しているという。しかしこれは少数派で,サポート切れの製品でも不具合がないから使っている会社の方が多い印象を取材では受ける。バージョン・アップによって動作検証やソース・コードの修正が必要になることも多く,新規開発に匹敵するプロジェクトに膨れ上がることも少なくないからだ。新バージョンを購入するなら,そのコストも必要だ。

 もちろん,短いサイクルで新製品を投入し,サポート切れに伴いバージョン・アップを促すメーカーの戦略に乗らざるを得ない状況は困ったものだ。メーカーにもサポートの充実を望みたい。しかし,現実問題として,障害発生時やセキュリティ・ホール発覚時にどこからもサポート受けられないシステムは恐い。

 OSやDB/APサーバーのような大型製品だけでなく,ユーティリティ・ソフトや各種ミドルウエア,アプリケーションまで含めれば,企業情報システムは毎年何らかのサポート期限を迎えているのではないか。しかも,ある大手メーカーのサポート担当者は「OEM製品や他社の特許技術を使った製品などの場合,契約形態の変更により,サポート期間を短縮せざるを得ないこともある」と明かす。そうしたリスクの増大が気になる。

 さて,リスクに対処するにはどうすればよいだろうか。まずはリスクを正しく把握することが第一歩ではないだろうか。自社システムでお使いの製品のサポート期限を一つずつ確かめてみてはいかがだろう。リプレースを考えたり,拡張計画を立てたりする際の材料になるはずだ。

(尾崎 憲和=日経システム構築)