OSとデータベースの標準化を推進

 ミノルタは基幹システムの再構築プロジェクトがスタートした2000年8月当時から,新基幹システムのOSはWindows 2000,データベース・ソフトはSQL Server 2000と決めていた。コスト面で有利なことはもちろんだが,それよりも重要視したのは,「各拠点にあるシステムのOSやデータベース・ソフトを標準化したかった」(ミノルタ財務管理本部の龍田義樹情報システム部長)からだ。

 1998年まで,ミノルタのアジア・日本,北米,ヨーロッパの各拠点の基幹システムは,それぞれの地域で独自に開発を進めてきた。そのため,OSやデータベース・システムがばらばらになっていた。例えばサーバー・マシンは,複数メーカーのUNIX,オフコンのAS/400,PCサーバーなどが混在していた。データベース・ソフトも,国内はOracle,北米はInformix,ヨーロッパはDB2/400と異なっていた。これでは各拠点のシステムを連携させ,統合化していくのは確かに難しい。

 そこで,「各拠点で統一したものを使っていくことで,ノウハウの共有や効率的な運用ができるのではないかと考え,今後グループ会社のシステム構築のOSにはWindowsサーバーにそろえることにした」(龍田部長)。

 最終的に,「Windows 2000 Advanced ServerにするかWindows 2000 Datacenter Serverにするかどうかで悩んだ。しかし,今後の情報システムのインフラを強化するために,信頼性と可用性が高いWindows 2000 Datacenter Serverを採用した」(龍田部長)という。

 データベース・ソフトは,「Windowsと親和性が高く,コスト面でも優位」(龍田部長)という理由でSQL Serverが採用された。移行過程にあるヨーロッパと北米の拠点は,現時点でとりあえずSQL Server 7.0 Enterprise Editionを利用している。だが,今回構築した日本・アジアでは,Windows 2000 Datacenter Serverの固有機能や大きなメモリー空間をフルに利用できるSQL Server 2000 Enterprise Editionを導入した。

Datacenter認定アプリの問題で一部の運用管理ツールの利用を断念

 大胆な構想に基づく新基幹システムの構築に当たりミノルタは細心の注意を払ったが,現実には2つの問題に直面した。1つは,Windows 2000 Datacenter Server認定アプリケーションの問題により,これまで使い慣れていた一部の運用管理ツールを断念したことだった。

 Windows 2000 Datacenter Server認定アプリケーションとは,Windows 2000 Datacenter Serverプラットフォーム上で十分な信頼性や可用性を証明する厳しいテストをクリアしたアプリケーションを指す。

 それまで日本IBMのバックアップ・ソフト「ADSM」やコンピュータ・アソシエイツのジョブ・スケジューリング・ソフト「Unicenter TNG」などの運用管理ツールを使っていたが,Unicenter TNGとADSMの後継製品「Tivoli Storage Manager」のどちらも,当時はWindows 2000 Datacenter Serverの認定アプリケーションではなかった。

 ミノルタはソフトウエア・ベンダーと再三交渉した結果,「Unicenter TNGは認定してもらえたが,Tivoli Storage Managerは認定されなかった」と情報システム部の北川雅昭氏は話す。ミノルタはTivoliの代わりに,認定済みのバックアップ・ソフトとして「Backup Exec for Windows NT/Windows 2000 アドバンスド・サーバ版」の導入をやむなく決めた。

6時間で済むデータ移行が2日を要す

 もう1つの問題は,R/3のデータ移行の作業中に起きた。ミノルタはデータを移行させる段階で,移行対象となるES7000のパーティションに通常より多い12個のCPUを割り当て,移行作業を早く終わらせるテストを実施した。実際にこのテストを2回繰り返したところでは,特にトラブルもなく6~8時間で移行作業が終了した。

 ところが,いざデータ移行の本番では,移行作業の開始から8時間過ぎても処理があまり進まず,完了する気配が全くなかった。ネットワークに流れる移行データをモニターしながらあらゆる個所を調査してみたが,なかなか原因が分からなかったという。

 苦労して突き止めた原因は,少し意外なものだった。データ移行の本番で初めて使用したウイルス対策ソフトによる問題だったのである。ES7000上で動作するウイルス対策ソフトが,転送されてくる移行データの書き込みに対してウイルスのチェックをしていたため,移行処理のパフォーマンスが著しく低下してしまった。

 直ちにウイルス対策ソフトの機能を停止して移行作業を再開したら,今度はテストのときと同じようなパフォーマンスが得られた。ただし,6~8時間で終わると見込んでいたデータの移行作業は,結局2日間もかかってしまった。ゴールデン・ウイークの移行期間内にすべての作業を完了できたので事なきを得たが,ひやりとする出来事だった。

(小野 亮=akono@nikkeibp.co.jp)