1990年代、ノーツは企業の情報共有基盤として広く普及した。特に大企業や官公庁は導入率が高く、都市銀行にいたっては導入率は100％だった。それだけ情報共有基盤として優れていたといえるが、時代がすすむにつれて、ノーツがもたらす弊害が顕在化していった。
　ここ数年、「ノーツマイグレーション」という言葉が定着したのも、ノーツを利用してきた多くの企業が、その弊害から何とか脱却したいと考えているからにほかならない。では、その弊害とはそもそも何なのか。ユニファイジャパン株式会社 代表取締役社長 堀学 氏は次のように説明する。

「1つはコストです。バージョンアップのライセンスに多額の費用がかかりますし、ノーツ技術者の減少でエンジニアにかかるコストも高騰しています。しかし、より本質的な問題はノーツが持つ閉鎖性に起因するものです。ノーツを導入した企業は、エンドユーザーコンピューティングの結果として、多数のカスタムアプリケーションを抱えています。このため、情報システム部門から見ると、ノーツのシステムは部門固有の統制されていない情報システムになっているのです。したがって、全社共通の情報基盤を構築するとき、ノーツシステムがその阻害要因となっているのです」（堀 氏）

　また、多くの企業では、こうした矛盾を情報システム部門が裏で支えていると堀 氏は指摘する。

「独自のプログラムを書いてノーツのデータを抜き出し、基幹システムに流し込むなど、ノーツ単独ではできないことを情報システム部門が裏で手作業で支えています。今後、システム連携やアプリケーション連携が進めば進むほど、情報システム部門の負荷はますます大きくなるでしょう」（堀 氏）

　こうした状況からノーツから移行したいと考える企業は少なくないが、現実の移行は思うように進んでいないようだ。ある調査では、グループウェア全体におけるノーツのシェアはいまだに20％以上、従業員5000人以上の大企業にかぎると55％にもなる。しかも、60％以上がサポートの切れたバージョンを使い続けているというデータもあるのである。

では、ノーツからの脱却が容易に進まない原因は何だろうか。1つはノーツ移行の取り組み方にあると堀 氏は指摘する。

「ノーツは部門特有のツールとしては非常によくできています。それだけ浸透しているツールを、たんにコストが高いという理由だけで変えようとしても、モチベーションは続きません。ノーツ移行においては『何のためにやるのか』という目的を明確にすることが重要です。全社の情報基盤を整備し、生産のリードタイム短縮や販売の効率化などにつなげるといった企業全体のコンセンサスを作ることが重要なのです。

　ただし、現状のものをこちらからあちらに移すのが移行ですから、そこだけとらえると付加価値が見えづらいのも事実です。したがって、いかにコストをかけないで移行を実現するかも非常に重要なポイントです」（堀 氏）
　現実に、ノーツ移行においてはコストの見積もりが難しいケースが多い。そもそも、ほとんどの企業は自社が抱えるノーツアプリケーションの実態さえ把握できていない。したがって、まずはコストをかけて「ノーツ資産の棚卸し」から始めなければならない。
　棚卸しが完了すれば、ようやく移行に必要なコストが見えてくる。そこではじめて、バージョンアップするか新しいプラットフォームに移行するかを検討できるのである。ただし、仮に後者を選んでも課題は多い。

「従来のノーツ移行のソリューションは、ノーツアプリケーションを新しいプラットフォーム上で作り直すものがほとんどです。当然コストがかさみますし、新たに作り直すことで操作性が変わり、移行後に新たな教育コストが発生することも少なくありません。したがって、特に重要な業務にかかわるアプリケーションについては、業務の継続性をいかに維持するかが非常に重要なのです」（堀 氏）

ユニファイジャパンが提供するノーツ移行ソリューション 「Composer」は、従来のソリューションとはかなり異質だ。まず、ノーツのすべての機能を移行するわけではない。メールやスケジューラなどは、オープンなグループウェアやエンタープライズメールに移行することを前提としている。

　Composerが移行するのは、独自のワークフローやビジネスロジックを持つ複雑な業務アプリケーションだ。その特長について、堀 氏は次のように説明する。

「Composerの特長は大きく3つあります。1つはコスト削減と移行期間の短縮を実現したことです。一般的なスクラッチ開発に比較するとコストは1/4～1/5、期間は1/3くらいですみます。その理由は、ツールを使って既存のノーツ資産を新しいWebアプリケーションに自動変換するからです。

　2つ目は、ユーザーインターフェイスの再現性の高さです。ノーツアプリケーションの見た目と操作性をほとんどそのまま継承できますので、移行後の再教育が必要ありません。

　3つ目は、コストを見積もるツールが用意されていることです。このツールを使うと、自動変換で対応できる部分とできない部分を事前に調査できます。当然、手作業による部分が最もコストがかかるわけですが、それを事前に確認できるので、精度の高い見積りをコストをかけずに短期間で出せるのです。」（堀 氏）。

　実際に、ツールによる変換では90％を超える変換率を実現しているという。残りの数パーセントは人間による手作業が必要になるが、その部分についても、変換後のコード内に変換できなかった箇所が明示される仕組みになっている。
「コンバータを通すと、ノーツアプリケーションが.NET環境のアプリケーションに変換されます。具体的には、ビジネスロジック部分はC#で書かれたコードになり、ユーザーインターフェイスはASP.NETのコードに変換されます。そして、自動変換できなかった部分は、ソースコード中にコメントとして表示されます。我々はそれを『TODO』と呼んでいます。エンジニアはこのTODOの部分を分析し、新しいプラットフォーム上に手作業で実装することになります」（堀 氏）

　ユーザーインターフェイスの再現性の高さについては、実際のサンプルを見てもらうのが早いだろう。100％同じではないが、日付指定のカレンダーや文字入力のテキストフィールドの操作性やデザイは、移行前よりもむしろ洗練される印象さえ受ける。
なお、Composerではマイクロソフトの.NETが採用されている。その理由について、堀 氏は次のように説明する。

「そもそもノーツ移行の目的は、情報活用基盤として耐えうるプラットフォームを構築することです。その意味で、.NETはWeb環境を構築するオープンでメジャーなプラットフォームです。

　また、移行後はお客様サイドで必要に応じて維持・メンテナンスしていただくことになりますが、.NETであれば、高年齢化・高コスト化しているノーツのエンジニアに比べれば、人材の調達ははるかに容易です。このように、コスト、維持・メンテナンス性、将来の拡張性のすべてにおいて、.NETは有利であると思います」（堀 氏）。

　ツールを活用して低コスト・短期間のノーツ移行を実現したComposerは、全従業員が利用する業務アプリケーションの移行や限られた移行期間など、条件が厳しくなるほどその効果を発揮する。

「大手の製造業のお客様で、全従業員が利用する申請系ワークフローの業務アプリケーションを短期間で移行した事例があります。

　すべての従業員が利用するシステムですので、移行後も従業員に負担をかけないことが求められましたが、既存アプリケーションの見た目と操作性がそのまま引き継がれたため、再教育はまったく必要ありませんでした。また、コストに関しても、見積もり段階で他ベンダーが提案したスクラッチ開発に比較すると1/10程度で済みました」（堀 氏）。

　申請系の業務アプリケーションは企業独自のものが多いため、それが新しくなると、従業員への再教育が必要になる。会社の規模が大きくなればなるほど、そのコストは膨らむ。見た目・操作が変わらないことは、移行後のコストにも大きく影響するのである。

　またComposerでは、評価のためにアプリケーションの一部をコンバージョンすることも可能だという。一部とはいえ、自社アプリケーションの移行後の見た目・操作性を事前に確認できるのは、ユーザーにとって大きな安心材料となる。

　「ノーツマイグレーション」にはさまざまソリューションがあるが、ツールによってここまで自動的に変換できるソリューションはほとんどない。ノーツ移行を検討している企業はもちろん、ノーツの移行がうまくいかず頓挫したままになっている企業にとっても、有力な選択肢が登場したといえよう。