特集 Linuxで動く.NET環境「Mono 1.0」の実力（前編） 株式会社ピーデー 川俣 晶 2004/10/05
Page1 Page2 Page3 Page4

Monoが生まれた背景

　まず、Monoとはいったい何かを確認しておこう。ソフトウェアを使うに当たっては、そのソフトウェアがどのような内容であるかを確認するのも重要だが、それに負けず劣らず、いかなるバックグラウンドを持っているかを確認することも重要となる。それはMonoも例外ではない。仮にMonoが、どこの誰が作成したかも分からないが便利だから流通している、というようなソフトウェアだったとすれば業務で使うには不安がある。また、著作権者が独特のポリシーの持ち主で、業務で使用する場合に利用許諾条件に制約が課せられる可能性があるとすれば、それも不安材料になる。そのほか、趣味で素晴らしいプログラムを開発してサポートもきっちり行ってきたものの、実は開発者が学生で、就職した途端にサポートが止まってしまうような状況も困る。はたしてMonoはどうだろうか？

　オープンソースでは、問題が発生した場合、誰でもソース・コードを手直しして対処することができることがメリットとして語られることがあるが、これは裏を返せば誰も直さないソース・コードの問題はいつまでも解消しないことを意味する。果たして誰かが責任を持ってソース・コードをメンテナンスしてくれるか、確認することは重要な意味を持つ。

　Monoは、Mono Projectによって開発されているオープンソース・ソフトウェアである。当初、Monoは、Ximianという企業で開発が開始されたもので、その後XimianはNovellに買収されている。Ximianは、GNOMEプロジェクトの創始者であるMiguel de Icaza氏らによって創業された企業ということらしい。GNOMEとは、オープンソースのデスクトップ環境である。GNOMEのGはGNUのGであることから分かるとおり、オープンソース的な活動においては極めて先鋭的な環境にいた人たちによって始められたプロジェクトということになる。それがマイクロソフトの技術と深い関わりを持つということに、大きな違和感が感じられる。

　しかし、違和感はこれで終わりではない。Ximianを買収したNovellは、かつてパソコンLANのためのネットワークOSのトップシェアを持っていた企業である。日本でLANの普及が始まった1990年代前半、パソコンのLANといえば、NovellのNetwareを使うのが常識だった。Windows NTサーバはまだ産声を上げるか上げないか、という状況であり、Linuxはごく一部の特殊な人たちしか名前を知らなかった時代である。

　ちなみに、イーサネットのアダプタの仕様としてNE2000互換という言葉が使われることがしばしばあるが、このNE2000はNovellがNetwareのために開発、販売したネットワーク・アダプタ・カードの名称である。このことから分かるとおり、当時のNetwareは絶大な影響力を持っていたと。しかし、そのNetwareは技術的に優れたものを持っていたものの、主にWindowsサーバとの競合に敗れた。すでにその名を覚えている者も多くはないだろう。Novellという社名も、もはやNetwareではなく、Linuxのディストリビューションの1つであるSUSE Linuxと関連付けて話題になることが多くなった。Mono Projectを支援しているスポンサーの1つがこのNovellである（オープンソース開発プロジェクトのスポンサーに注意を払う価値については、以下のコラムを付記した）。このような会社が、マイクロソフトの技術と深い関わりを持つということも、大きな違和感を感じさせる。

［コラム］ オープンソース開発プロジェクトの資金源に注意を払う価値 　余談だが、ある程度の規模のオープンソース開発プロジェクトであれば、何らかの形で資金源を持っていると考えてよいと思う。その資金源がどこであるか確認しておくことには価値がある。確かに、オープンソースであれば出来上がったソフトウェアを自由に使うことができるし、そこから改変していくことも自由である。しかし、プロジェクトの運営や、プロジェクトが生み出すソフトウェアの内容について、資金源となっているスポンサーが影響力を行使しようと思えば可能なのである。クリティカルな業務で使うことを考えるなら、誰がどんなメリットを得るためにスポンサーになっているかをよく確認しておく必要があるだろう。

.NETが採り上げられた理由

　さて、少しだけMonoにまつわる違和感の正体について、探索を進めておこう。どうして、先鋭的なオープンソース開発に携わる者たちと、マイクロソフトの技術が接点を持てるのだろうか。そして、どうしてマイクロソフトのライバル企業がマイクロソフトの技術を扱うプロジェクトのスポンサーになれるのだろうか。以下は筆者なりの解釈にすぎないが、簡単にそれに触れておこう。

　この問題について考えるときに意味がありそうな文章がある。2001年12月の日付が付けられている「ECMA 標準の利用 : Miguel de Icaza インタビュー」というインタビュー記事である。これは、マイクロソフトのサイト上にあり、MSDNライブラリのCD／DVD-ROMにも収録されている。この事実だけでもかなりの驚きである。オープンソースに深くかかわる技術者のインタビューが、堂々とマイクロソフトのサイトに掲載され、しかもすべてのMSDN会員に向けてCD／DVDに収録され配布されているのである。

　しかし、この内容を読めば、このMiguel de Icazaという人物が、徹底的なリアリストであり、空虚な理念よりも、動くコードを重視する人物であることが読み取れるように思う。つまり、プロパガンダに左右されずに、他者のソフトウェアも含めて、現実のソフトウェアを冷静に見据えているように思えるということである。

　そのリアリズムの中で重視されることは、他人のソフトウェアを攻撃することではなく、自分のソフトウェアが確実に開発でき、動くことである。もしかしたら誤解をしている人が多いかもしれないが、あるソフトウェアが確実に開発でき、それが動くことは、決して低いハードルではない。彼らが扱うようなシステム寄りのソフトウェアではなおさらである。予算と優秀な技術者さえ集めれば確実にできるというものではないし、実際に完了できなかったプロジェクトの無数の残骸（ざんがい）がわれわれの背後に積み重なっている（だからこそ、プロジェクトを成功させるために、開発プロセスやマネジメントが熱い注目を集めているといえるだろう）。本当に成功を収めたいと思うなら、他者のソフトウェアを攻撃する余裕などあるはずもない。それどころか、使える良いものは、たとえライバルの技術であろうと、積極的に取り込んでいくことが必要とされる。

　ここで注意していただきたいのは、上の文章で「使える良いもの」と書いたことである。あくまで、「使える」ものしか使えない。技術的な非互換性や、ライセンスや特許の問題などで使えないものは、いくら良くても使えない。これまでのマイクロソフトが送り出してきた技術の多くは、Windowsのアーキテクチャと密接に結び付いたものが多く、そう簡単にほかのOS上で活用することはできなかったのも事実である。ライセンス的にも、他OS用として提供されるような性質のものではないものが多かったといえる。つまりは、それらの技術が「仮に」良いものであっても、それらは「使えない」ものだったわけである。

　しかし、Monoが対象とするマイクロソフトの技術は事情がまったく異なる。プログラム言語のC#と、.NETアプリケーションの実行環境の仕様であるCLI（Common Language Infrastructure）は、ヨーロッパの技術標準化団体のECMAによって、ECMA-334 C# Language SpecificationやECMA-335 Common Language Infrastructure（CLI）として標準化されている。公共の標準化団体によって標準化されたということは、それは社会の共有財産になったと考えてよいだろう。マイクロソフトという特定企業の所有物ではなくなったのなら、それを活用することに何の問題もないことになる。

　技術的にも、それまでのマイクロソフトの技術と比較して、Windowsに対する依存性が低くなっている。例えば、クラス・ライブラリはWin32 APIの後継という位置付けになるものであって、Windowsの次世代OSのための技術という側面が強いといえる。後継になるものが、古い世代の技術に依存するのは得策ではないので、依存性の低下は当然の帰結である。しかし、依存性の低さは他OS上での利用のハードルも下げる。つまり、技術的にも「使える」度合いが格段に上がっているわけである。

　つまり、「使えるものは使う」という考え方を取ったとき、C#やその実行環境は、Linux上のオープンソース世界からも十分に採用可能な状態にあるといえる。またライバル企業が採用することにもさしたる問題はないだろう。あとは、それが「良い」と考えるかどうかの問題である。プログラム言語や実行環境の善しあしには、絶対的な評価基準はなく、人それぞれに異なる価値基準はあるだろう。しかし、「マイクロソフト憎し」という感情を除外して冷静に技術を吟味すれば、「良い」という判断が下る可能性は十分にあるだろう。そして、複雑かつ汎用的なシステム・レベルのソフトウェアを開発するに当たって、動くソフトウェアを確実に開発完了するには、（C#だけが良いものだとはいわないが）、いずれかの「良いもの」の助けが必須となるのである。ここに、マイクロソフトのライバルと目されるグループや企業がC#やその実行環境を採用する必然性が発生するといえる。

INDEX
	［特集］Linuxで動く.NET環境「Mono 1.0」の実力（前編）
	1．WindowsとLinuxとを結ぶ「Mono」
	2．Monoが生まれた背景
	3．Monoの機能とインストール
	4．C#コンパイラとVB.NETコンパイラ
	［特集］Linuxで動く.NET環境「Mono 1.0」の実力（後編）
	1．バイナリの互換性を検証する
	2．環境間の相違と対策／Monoと.NET Frameworkとの速度比較
	3．XSPを用いたASP.NET
	4．Apacheを用いたASP.NET

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）