『日経コンピュータ』2002.4.8号にマイクロソフトがノーツユーザのためのマイクロソフト製品への移行支援プログラム広告を掲載している。また同社Webサイトにも同様のコンテンツがある（「ノーツ／ドミノユーザ支援サイト - .NET Wave」）。このエッセーでは同サイトの「比較資料／技術資料」のページを中心にマイクロソフトの議論の正確さを検証する。

ここに来てマイクロソフトが打倒ノーツに本腰を入れたのは、これまであいまいだったExchange2000の製品戦略が.NET Frameworkへの統合という方向性に明確化されたためだろう。しかしノーツからの移行キャンペーンに対してはひとことで反論することができる。「Exchange2000はWindowsでしか動かないが、ノーツはAS/400でもSolarisでもAIXでもHP-UXでもLinuxでもOS/2でもMacでも動く」。以上。

マイクロソフトもこのことはさすがに自覚しているらしく「設計・導入に関わるアーキテクチャや機能の比較」のページではExchange2000がWindows2000上でしか動作しないことが書かれている。サーバのサイジングについてWindows2000環境に限ってExchange2000の方が収容可能なメールボックス数がノーツより多いと書かれてあるが、ノーツならUNIXへ移行することで根本的な解決を図ることができるのに対して、Exchange2000はどこまで行ってもWindows2000の限界に拘束される。これをExchange2000の長所と書いているマイクロソフトの論理は残念ながら自己破綻している。

また同ページ上でマイクロソフトはExchange2000の優位点としてActiveDirectoryとの統合をあげている。筆者が某企業でExchange2000の全社展開を見送らざるを得なかったのは、まさにExchange2000を導入するにはActiveDirectoryを事前に全社展開しなければならないためだった。両者の密な統合は同社が主張するように長所にもなるが、大きなハードルになる場合もある。いわば「諸刃の剣」なのだが、同社のWebサイトにそのことは明記されていない。

そもそもメッセージング・システムのアカウントとOSレベルのアカウントは連動していることが適切だろうか。OSレベルのセキュリティーの堅牢性を確保するために、両者は独立して管理すべきものだというのも一つの考え方だろう。ノーツの場合、OSレベルのアカウント管理とノーツのドミノディレクトリ管理は、連動させることもできるし切り離すこともできる。しかしExchange2000は連動させる選択肢しかない。しかも連動させることができるのはWindowsプラットフォームのActiveDirectoryだけである。

このように考えるとExchange2000の長所としてActiveDirectoryの統合を取り上げるのはやや無理がある。一昨年、筆者はこのような経緯でExchange2000の導入を断念せざるを得なかったことをマイクロソフトの技術者に正直に話したのだが、ユーザの声は残念ながら同社の中で見事に黙殺されたようである。

またネットワーク・トラフィックについて「ドミノ R5 環境における複製処理はNSFファイル丸ごと行うため、ネットワークに多くのパケットが流れます」という記載があるが、これも意図的に誤解を生む表現をしているとしか言いようがない。ノーツの複製処理は差分更新なので、たしかに複製の単位は各NSFファイルごとであるが、毎回ファイル丸ごとのデータがネットワーク上に流れるわけではない。しかもノーツが複製するのはディレクトリ情報だけではなく、ノーツのデータベースが管理するあらゆる情報を同じ仕組みをつかって複製できる。コンテンツに関わらず統一的な複製のしくみが提供されている点がノーツの分散データベースとしての最大の特徴であるが、マイクロソフトはこの点を無視している。

データ保管の効率性についての議論も、同社はメールシステムとデータベースの区別を意図的にあいまいにしている。Exchange2000で１通のメールを100ユーザに発信した場合、データストアに作成されるメッセージは１通だけだが、ノーツの場合は100個のコピーが各ユーザのメールデータベースに作成される。この点を称してマイクロソフトはノーツのストレージは効率が悪いと非難している。

しかしノーツユーザなら、そんな情報は掲示板データベースで集中管理し、文書リンクだけをメールで送信すべきであると答えるだろう。これはシステムのアーキテクチャの問題ではなく、企業内の情報管理ポリシーの問題である。100人の社員に伝えるべき情報をメールで送信するという考え方自体、企業内の情報管理として間違っている。

メールはあくまで一過性の情報を交換する手段であり、長期間蓄積すべき情報はメールではなく掲示板などの共有ストレージ上で情報の管理者を明確にして集中管理すべきである、というのが情報管理の基礎ではないか。しかしマイクロソフトのExchange2000擁護論には、個々の情報には固有の寿命があるという、企業内情報管理の実務上の知識が欠落している。そもそも寿命を意識せずに情報を管理することなどできるだろうか。

一過性の情報と永続的な情報、その差異を人間が意識しながら管理してはじめて、純粋な情報共有技術としてのデータベースや共有ストレージは生きた道具になる。マイクロソフトのExchange擁護論は技術偏重で、じっさいにExchangeが企業内でどう活用されているか、具体的な視点が欠如している。

ここに情報共有ツールとしてのExchangeとノーツの導入実績の差が図らずも露呈している。ユーザに揉まれて育ってきたノーツは情報管理の実務上のノウハウを反映した製品になっているが、Exchange2000はOfficeのような個人利用者向け製品がユーザの声を反映させるのに見事に成功しているのに対して、技術偏重でユーザの意見を反映することに失敗しているのかもしれない。よく言われることだが、マイクロソフトは事業者向けシステム提供企業として未熟だと言わざるを得ない。

次に「構成・維持管理に関わる機能や作業の比較」のページを見てみると、アカウント管理については先ほどのページと同様のひとりよがりな議論が引き続き展開されいている。OSのアカウント管理とメッセージングのアカウント管理が統合されているか、分離されているかはユーザが選択すべきものであって、ツール自体が決定すべきものではない。Exchange2000はユーザに選択権を与えず、両者を統合してしまっているが、ノーツはどちらでも選択できる。たしかに統合を選択した場合のノーツの管理作業は煩雑だが、選択肢がないExchange2000のような製品よりはユーザの意思を尊重した製品であると言える。

ノーツのIDファイルに関する議論には、少し調査すれば回避できる単純な事実誤認が含まれている。ノーツはIDファイルがなくても一般のPOPメーラによるメール送受信が可能だし、メール以外のノーツデータベースにはWebブラウザからユーザ名とパスワードの入力だけでアクセス可能である（SSLもサポートしている）。IDファイルが必要になるのはクライアントとしてWebブラウザではなくノーツクライアントを使う場合だけだ。にもかかわらずマイクロソフトのページではIDファイルの管理がエンドユーザにとってさも重大な負荷であるかのように書かれている。

パスワード管理についても同社は単純な事実誤認をもとにノーツを批判し、同社の技術陣の調査力の低さを露呈している。ノーツのエンドユーザが管理しなければならないパスワードは最大２つである。ノーツの利用にかかわるパスワードは３つある。（１）OSへのログイン時のパスワード（２）ノーツのIDファイルを使用するためのパスワード（３）ノーツインターネットパスワード。このうちユーザが使う必要があるのは（１）と（２）の組み合わせ、または、（１）と（３）の組み合わせのどちらかである。ところが同ページではエンドユーザがつねに（１）（２）（３）の３種類すべてを管理しなければならないかのように書いている。

このパスワード管理については、むしろマイクロソフト社がOSレベルのパスワードとアプリケーションレベルのパスワードを統合する手段を与えてこなかったことが問題ではないか。ログインの必要なクライアントサーバ型アプリケーションやWebアプリケーションはノーツ以外にも無数に存在する。それらのログインがOSレベルのものと異なることについて、企業内のWindowsユーザはなかば諦めているのが実態だ。

これはマイクロソフト社がサードベンダー製のアプリケーションと自社OSのシングルサインオンを容易に実現するAPIを提供してこなかったことに起因する。それをノーツの機能制限であるかのように論じるマイクロソフトの議論は自己破綻をきたしている。

マイクロソフトが主張するように、OSレベルとアプリケーションレベルのシングルサインオンがそれほど重要なら、どうしてこれまで積極的に実現のための技術支援をサードベンダーに対して行なわなかったのだろうか。筆者個人はアプリケーションのログインはOSと統合されている必要はないと考えるが、同社はそれを必要だと考えているようだ。しかしその主張と、同社がそのための情報公開や技術支援を怠ってきたという事実は矛盾している。

また、ユーザ環境ファイルに関わる問題について、同ページで指摘されているようにノーツをノーツクライアントで利用する場合、環境ファイルをローカルに持つという点は事実だし、コンピュータの交換時に少なからず問題が起こることも事実だ。

ノーツの場合、１台のマシンで複数のノーツIDを切り換えてログインすることができる。そのためノーツの環境ファイルは、個々のユーザ固有の情報を保管するものと、そのマシンに導入されているノーツを動かすための環境設定の２種類が用意されている。ただしそれら環境ファイルは個々のマシンのローカルディスクに保存されている必要はなく、ファイルサーバの共有フォルダで一括管理することも可能だ。

コンピュータの交換の場合にノーツは「問題が起こりやすい」とあるが、たしかにノーツのクライアント環境を新しいPCに移行するのは共通して使えるファイルサーバか、64MB以上のリムーバブルメディアがなければ難しい。「問題が起こりやすい」のではなくノーツの場合は「常に問題が起こる」のだ。

ただ、新しいPCを使い始める場合の問題はノーツに限ったことではないだろう。ノーツユーザが会社で使っているPCには、ノーツの環境設定ファイルだけでなく、作業中のExcelやWordファイル、個人的に利用しているフリーウェアやシェアウェアなど、ノーツ以外にも移行する必要のあるファイルが無数にある。つまりノーツの移行は新しいPCに環境を移行する際の問題の一部分でしかない。

そもそもレジストリを始めとして、ユーザ固有の環境をローカルに保存するという考え方を提供しているのはマイクロソフト自身だ。ちなみにノーツはレジストリを一切使わず、すべての設定情報をnotes.iniというテキストファイルに保管しているため、notes.iniさえ異動できれば、元のPCの環境情報を移行できる。また、ノーツのローカルデータベースやIDファイルはどのディレクトリに保存してもよい。レジストリに情報を書き込んだり、フォルダの特定の階層構造を要求する他の大多数のWindowsアプリケーションよりも、環境移行に関してはよほど良心的と言えないか。

また、出張の場合に関して言えば、携帯するノートPCにデータベースを複製して持ち歩くというのがノーツ利用者の一般的なスタイルであり、とくに問題が起こるわけではない。むしろExchange2000ユーザはメールを読むたびにサーバに接続しなければならない分、問題がより大きいと言えないだろうか。メールは全てクライアントのOutlook側に保存しているという反論が聞こえてきそうだが、ならば新しいPCへの移行のときメールデータも移行する必要があり、ノーツと同様の問題が発生するはずである。このようにマイクロソフトの議論は各所で自己矛盾をきたしている。

セキュリティ管理について、同社は再度ライバル製品の知識不足を恥ずかしげもなく露呈している。ノーツはフォルダ内のアイテム単位でアクセス制御ができるだけでなく、アイテム内のさらにフィールド単位でのアクセス制御も可能である。また、ノーツを使いながらインターネットで証明書を利用するということは現実には起こりえない。インターネット証明書を使う必要があるなら、ノーツクライアントを使わずにWebクライアントからノーツを利用するだろう。ドミノサーバはSSLが利用できるので「ノーツ専用の証明書」（IDファイルのことを差しているのだろう）は不要だ。上述のパスワード管理にしてもそうだが、ライバル製品を批判するなら正確な調査を行なってからにした方がよい。

「既存のメールボックス 3,000 個に対して、特定の設定を変更する場合の作業」についても不正確な情報が掲載されている。既存のNSFファイルの設定を一括変更するには、そういうスクリプトをLotusScriptで記述すればよいだけである。メールファイルを１つひとつ手作業で設定する必要などまったくない。むしろ「既存のメールボックスに対しても、非常に簡単に一括で設定を変更でき」るというExchange2000のサーバ管理者は、簡単に全ユーザに影響を与えてしまえるのだがら、よほど慎重に管理作業をする必要があるだろう。

「負荷分散や障害対策を考慮したサーバーの追加」についてはこのエッセーの最初に書いたとおり、それほど負荷分散や障害対策が問題になるなら、Windowsプラットフォームを捨てて、UNIXへ移行するという選択肢がノーツにはある。Exchange2000はWindows2000上で問題を解決するしか選択肢がない。

「ログ収集」について。果たしてメール本文までログに残そうという企業が、そのログ収集処理をExchange2000 Serverに負担させるだろうか。おそらくはログ収集専用のサーバを別途構築するだろう。本文までログ収集するにはかなりの処理能力が必要であり、それをメッセージングサーバと同一のサーバに負担させるのは現実的なシステム設計ではない。

「データベース管理」について。ノーツの場合「デフラグは、データベースごとに手動で行う」とあるが、これも単なる事実誤認である。ノーツの通常の運用では、夜間のサーバ負荷が軽い時間帯にデータベース圧縮タスクをスケジューリングする。このタスクは全てのデータベースを一括して圧縮し、かつ不整合を修正する。こんなことも正確に調査せずにマイクロソフトの技術者はノーツとの比較記事を書いている。いかに同社の技術者が信用できないかがよく分かる。

また「オンラインバックアップ」について、Exchange2000の利点としてWindows標準のNTBackupを利用できる点が挙げられている。しかし同ページでマイクロソフトが再三にわたって強調しているような負荷分散や障害対策が問題になる規模の企業で、NTBackupでバックアップを実施している企業がどれほどあるだろうか。ほとんどの企業がARCserve、BackUpExecなどサードベンダー製のバックアップ機能に特化したパッケージを利用しているはずだ。NTBackupが「標準」だというのはマイクロソフトの独断であり、企業ユーザにとってはむしろARCserveやBakUpExecが「標準」だろう。

その次にアプリケーションのバージョンとOSのバージョンの整合性について、ノーツの方が管理が困難である旨が書かれているが、企業のシステム管理者にとってマイクロソフト製品のバージョン管理と、ノーツなどサードベンダー製パッケージのバージョン管理のどちらが容易だろうか。Internet ExplorerやWindowsのセキュリティーパッチのことを考えてみよう。定期的にリリースされるノーツのマイナーバージョンアップと、問題が発覚するたびに不定期にリリースされ、しかもどのパッチがどの範囲の問題を解決するのかについての情報を整理するのがきわめて困難なマイクロソフトのマイナーバージョンアップのどちらが管理が容易か。マイクロソフトは果たしてユーザの声を直接聞いたことがあるのだろうか。

最後に「利用者 (エンド ユーザー) が利用する機能の比較」 のページを見てみたい。ここではExchange2000のクライアントであるOutlook2000とノーツクライアントR5が比較されている。たしかに機能点数や一般的な操作性についてはOutlook2000の方が優れている。

ただしOutlook2000とノーツクライアントはそもそも別種のツールである。Outlook2000はメールソフトに共有ストレージの閲覧機能が追加されたツールであるが、ノーツクライアントはノーツデータベースの閲覧ツールであり、そのデータベースの一つがたまたまメールであるに過ぎない。ノーツクライアントはデータベースの閲覧のために機能が標準化されているので、メールに限定したときの操作性が劣るのは当然の結果だ。メッセージングツールという前提でOutlook2000とノーツクライアントを比較すれば、Outlook2000に有利な評価結果が出るのはむしろ当然のことである。

同ページでOfficeとの統合、Explorerとの統合についてOutlook2000の優位性が書かれているのはすべてマクロソフト製品なのだから、わざわざ書くまでもなく誰もが認めることである。ノーツの発売元であるIBMは自社の製品どうしの相性が良いなどという当たり前のことをわざわざ自社のWebサイト上で誇り顔に主張するようなことに時間を費やさないだろうが。

「添付ファイルの編集と保存」についてはいまだにマイクロソフトはノーツの添付ファイルの編集結果が保存されないというR４時代の機能制限を信じているようだ。一昨年、ノーツの管理者経験があると称するマイクロソフトの技術者と打合せしたときも、その技術者は「ノーツは添付ファイルを保存できませんよね」と主張していたが、R５になってからは可能になっている。

一昨年に筆者はそのことをマイクロソフトに伝えたのだが、あれから２年経った今もなお、マイクロソフトはその間違いを正すことができていない。やはり１ユーザである筆者の声は同社の中で黙殺されたようである。マイクロソフト社内の情報共有やCRMが正常に機能しているのか疑いたくなる。情報共有がうまくいっていない同社が提供する情報共有ツールとしてのExchange2000やSharePoint Portal Serverを、果たして各企業は導入してもよいのだろうか。

ロータス社がIBMの一部門に吸収された今、マイクロソフトがノーツを批判するときに相手にしているのはIBMということになる。しかしながら同社の「ノーツ／ドミノユーザ支援サイト」を読む限り、ノーツに関して調査不足のまま不正確な情報を公開する同社の厚顔無恥ぶりがよく分かる。

この事実はそのままマイクロソフトという企業とIBMという企業の、事業者向けソリューション提供企業としての信頼性の指標になる。多数の事実誤認を含むコンテンツを平然と公開するマイクロソフトが、ナレッジマネージメントや自社製品のセキュリティー強化を主張しても、企業ユーザはその言葉を額面どおりに受け取れない。しかも筆者のような１ユーザの声は同社の内部では黙殺するのが流儀のようなのだ。

他方IBMはライバル製品に対する不毛な批判に時間を浪費することなく、WebSphere上のJ2EEアーキテクチャーとノーツの統合に地道に取り組み、OSに縛られない大規模システムの可搬性を追及している。

マイクロソフトはこのような調査不足のコンテンツを発信することによって、他ならぬ自社の一企業としての信用を傷つけていることに、いつ気づくだろうか。