企業で使われているシステムやアプリケーションにおいて、レガシーなものが使い続けられているというのは、さほどめずらしいことではない。しかし、「どう しても代替がきかない」場合は別として、「特に問題ないから」などと、単にずるずると使い続けるのはあまり賢明とは言えないだろう。ハードウェアのように それ自体が経年劣化をしてしまうものでなくとも、ITを取り巻く状況、そして、企業を取り巻く環境の変化などにより、「使い続けることのリスク」はいずれ 浮かび上がってくるものだ。

とりわけ最近よく耳にするのは、十数年前に導入したグループウェアを使い続けていた企業が、「従来バージョンのサポート終了」という問題に直面して いるという話である。しかも、やっかいなのは、単純に新しい環境に乗り換えればすむわけではないということ。そうした企業の多くは、製品をそのまま利用す るのではなく、社内の情報共有基盤の“完成”を目指しつつ、自社独自の拡張や改善を積み重ねて、現在の環境に至っている。新バージョンや別の製品に乗り換 えるにしても、これまでの資産をそのまま活用できなければ、コストと手間をかけて蓄積してきたものが無駄になってしまう。

しかも、仮に現在の環境を“そのまま”移行できたとしても、それはそれで、あまり喜ばしいことではないかもしれない。“完成形”を目指したとはい え、結局のところ、前述のような状況の変化に追いつくことができず、実は“理想形”には到達していないのが実情というケースが多いからだ。つまり、仮に 「サポート終了」という事態が生じなくても、「ユーザにとって使い勝手が悪い」「パフォーマンスが低い」「運用管理のできる技術者が減っている」「コンプ ライアンス対応などが困難」といった問題により、限界は目前に迫っていたということになる。

これは例えるなら、情報共有基盤の“九龍城砦”化と言えるかもしれない。その場その場の目的は利便性の向上や快適さの追求だったとしても、結果的に は無秩序な増築・改築を行っていた…というわけだ。当然ながら、そうして肥大化した建物には様々なリスクが潜むこととなる。もちろん、古い（伝統のある） 建物を大事にして、増築や改築を施しつつ、住み続けるというのは決して悪いことではない。しかし、それには新しい建物を作るよりも高い延命コストが必要に なるというのも、よくある話だろう。

何より、新しい建物へ移行した場合には、今の時代に即した“快適な生活”が期待できるものだ。日本オラクルでは最近、特に“Notesマイグレー ション”への対応に力を入れているが、それはNotes利用環境からオラクル環境への移行作業を支援するというだけにとどまるものではない。まず、今の時 代にふさわしい“情報共有のあるべき姿”を提示しつつ、それを実現するための「新しい基盤と運用方法の構築」、そして、「スムーズな移行」を実現できるよ う、自社が有する様々な製品/ツールやノウハウを駆使した万全な体制でサポートしてくれる。

では、マイグレーションによってもたらされる“快適な生活”とは具体的にどのようなものなのか。そもそも、企業内での情報共有においては次のような課題が生じていないだろうか？
「必要な時に必要な情報が必要な人に届かない」
「情報共有のためのツールの使い勝手が悪い」
「双方向のコミュニケーションが少ない」
「ファイル形式の情報の漏洩が心配」
日常業務において、こうした数々の問題があることは誰もが薄々感じているはずなのに、なぜ放置されているのだろう？
そもそも情報を共有しようという思考がないなど、社員の意識やビジネス文化にも原因があるのだが、実は電子メール依存/偏重の情報共有基盤を維持し続けている限りは解消しにくい問題なのである。
日本オラクルでは、企業がNotesからオラクルへのマイグレーションを行う動機として、前章で説明したようなリスク回避に加えて、こうした情報共 有における課題が解決できる点も前面に押し出している。マイグレーションは単なるグループウェアのリプレースにとどまるものではなく、ゼロベースで“新し い情報共有基盤”を構築し、全体最適化を図ることで、情報共有における課題の抜本的な解決にもつながるというわけだ。

マイグレーションによって構築される“新情報共有基盤”の全体像は、下図のようなイメージとなる。基本的な考え方としては、情報共有に必要な要素を電子 メールやスケジュール、文書管理といった機能ごとに縦割りにするのではなく、複数のレイヤー（階層）に分けて管理することで最適化を図るというものだ。こ れにより、グループ企業を含めた高い拡張性を確保できるとともに、高負荷、大量データ処理、連続運用にも容易に対応可能な基盤が実現する。データ管理とア プリケーション、そして、ポータルといった層に切り分けることで、Web2.0などの最新技術も取り入れやすく、しかも、情報のライフサイクル管理やセ キュリティ対策といった面においても有利な体制が整えられるのだ。

前述のとおり、日本オラクルではマイグレーションを単なる移行や引越ではなく、新しい情報共有基盤を一から築き上げることと捉えている。もちろん、 それによって過去の資産が無駄になってしまうということはない。企業によって移行前のDB環境は千差万別となるはずであり、日本オラクルではその状況に応 じて、最も効率的に移行できる環境や手段を提案してくれる。

例えば電子メール及びスケジュールに関しては、コラボレーションツール製品「Oracle Beehive」への移行が最適だ。「Oracle Beehive」は電子メールやスケジュールはもちろん、インスタント・メッセージング、チーム・ワークスペース、カンファレンスなど、企業の統合コラボ レーションに必要なすべてのサービスを備えており、オンプレミス（サーバ型）、もしくはOracle On Demand（SaaS型）で利用できる。“軽い”システムが実現できる上、クロスプラットフォーム型のオープンな標準ベースアーキテクチャにより、オラ クル製品はもちろんのこと、あらゆる製品との連携・共存が可能な点が特長だ。

DB環境に関しては様々な移行方法が考えられるが、代表的に2つの例を下図に挙げておこう。リッチテキストや添付ファイルなどのデータ中心、すなわ ち文書中心DBであれば、無償提供される移行ツール（サンプルプログラム）を利用し、データをOracle UCMへ格納することで、高速大量処理が可能で不正防止対策の万全な専用システムが構築できる（ 詳しくは、資料ダウンロードの「Enterprise2.0時代のNotesマイグレーション～ブラザー工業」を参照 ）。

また、関数などが多数埋め込まれているロジック中心DBの場合も、同様にWeb Center Suite、BPM Suiteへ移行することで、汎用的な開発／実行プラットフォームで新規開発が行えるようになる（ 詳しくは、資料ダウンロードの「三菱UFJインフォメーションテクノロジー事例」を参照 ）。

ビジネスの急速な変化、グローバル化という状況に企業がさらされている現在、何より必要なのは、社員1人ひとりの生産性向上を図り、少ない資源で高 い成果を上げることだ。すなわち、業務プロセスを支えるためのシステムを、変化への迅速な対応力と高い拡張性を備えたものにしておくことが不可欠と言える だろう。そうしたシステムを実現している企業は意外に少ない。既に実現していると考えている企業でも、それは思い込みにすぎない可能性もある。
とりわけ、長年にわたって既存環境をベースに改善・拡張を続けてきた企業では技術的な限界を感じていないだろうか。また、文書管理システムやファイ ルサーバなど、個別最適のシステムが併存することで、運用コストが無意味に増加していないだろうか。そのような疑問を感じているようなら、新しい情報共有 基盤を構築し、全体最適化を図ることを、この機会に検討すべきだ。もちろん、移行を段階的に進めていくことも可能なので、まずは気軽にOracle Direct（0120-155-096）から相談を始めてみてはいかがだろうか？