UIEngineという名前の由来

　２０００年にMicrosoftを退社し、UIEvolutionという会社を作った私であるが、今回はMicrosoft内での失敗の経験を生かし、Netdocsとは少し異なるアプローチを採ることにした。

　まず最初に決めたのは、ベンチャー企業を立ち上げたのだからあたり前の様に聞こえるかもしれないが「Microsoftの外で作る」ことである。その当時に私が考えていた、『インテリジェンスを持ったXMLドキュメント』、『あたかも全てがクライアント側で動いているかのようにスムーズに動くウェブアプリケーション』、『ユーザーやアプリケーションをデバイスの呪縛から解き放つ』、などのコンセプトを突き詰めて行くとどうしても『OSのコモディティ化』と『Microsoft Officeに代表されるリッチクライアントアーキテクチャの否定』に繋がるのである。どんなに賢い人たちが集まっていようと、（もしくは賢い人たちが集まっているからこそ）現時点で会社の利益の大部分を生み出している商品をコモディティ化したり否定するプロダクツを内部で作ることは出来ない、ということをやっと理解したのがこの時期である。

　次に決めたのは、クライアント側のソフトウェアを究極にまで小さくし、かつ、その大きさを将来のバージョンアップの際にもできるだけ保つ様に努力することである。OSにしろブラウザーにしろ、それまで私が関わってきたソフトウェアすべてが、最初は少数の人数で作るので楽しいし全体も把握できるのだが、機能を追加するたびにしだいに大きくなり、ある時点で一人の人間に把握できる臨界点を超えてしまう。そうなると、エンジニアの数も増やさなければならなくなり、それに応じてますます機能が追加され、あっというまに何百万行のソースコード、何メガバイトのプログラムになってしまうのである。

　クライアントとサーバーの両方のCPUが使え、かつ、ドキュメントそのものがインテリジェンスを持てるようになるのであれば、クライアント側にあらかじめ置いておかなければならないユーザーエイジェント（つまりブラウザーに相当する部分）は実はものすごく小さくて済むのではないか、というのが私の発想であった。別の言い方をすれば、サーバーから指示されたユーザーインターフェイスを表示するために最低限必要な機能（つまり、文字を書く、線を描く、ビットマップを表示する、ユーザーの入力を受けて状態遷移を起こす、非同期でサーバーと通信する、などの基本機能）だけを持つ、ウェブアプリケーションのユーザーインターフェイス表示専用のユーザーエイジェント（これが UIEngine という名前の由来である）を作れば、描画エンジンをさまざまなOSやCPUに移植するのもものすごく簡単になるし、携帯電話やスマートカードのようなCPUの能力やメモリー容量の少ないデバイスにでもインタラクティブなウェブアプリケーションを配信することが可能になる、と考えたのである。