Life is beautiful

　Windows95の開発の総責任者であるDavid Coleから開発の主要メンバーに緊急召集がかけられたのは、Windows95の開発も大詰めを迎えた1994年末のことである。

　Shell（デスクトップ、エクスプローラ、スタートメニューなどのユーザーインターフェイス）の開発を担当していたSatoshiは、いままでの経験からこの手の緊急招集が良い知らせでないことはないことは知っていた。

　David Coleが深刻な顔をして緊急招集の理由を説明し始める。Windows95そのものの開発は順調に進んでいるが、Windows3.1との互換性の維持が思うように進んでいないのである。

「このままだと、９５年中にリリースすることはできない」

　深刻な問題である。既に当初の予定より１年以上遅れているWindows95のリリースをさらに遅らせて95年のクリスマスシーズンを逃すことはOffice95を同時にリリースして一気に32ビットOSでの主導権を握ろうとしているMicrosoftの戦略上許されることではない。しかし、かといってWindows3.1との互換性をないがしろにすることは、絶対にできない。ユーザーが持っているWindows3.1用のアプリをそのまま走らせることが出来るからこそ、Windows95への移行がスムーズに進むのだ。互換性が維持できなければ、AppleやIBMに付け入るスキを与えてしまう。

　「この状態を打開するために、各部署から人を出してスワットチームを作って欲しい。３ヶ月以内に、市場に出ている売れ筋のWindows3.1用のアプリ全てがWindows95上できちんと走るようにして欲しい。どんな手段を使っても良いからかならずそれを実現するのが君らの役目だ」

　そう言いながらDavid Coleが我々に渡した資料には、ゲーム、教育、ビジネス、などの各ジャンルの売れ筋のソフトのリストが書かれており、Windows95上でちゃんと動作しないものに印がしてある。その数が異常に多い。事態はかなり深刻だ。

　Shellの開発が既に一段落していた私は、すぐにスワットチームに加わる。たまたま、息子たちの幼稚園で使っていたという理由で、Learning Companyの教育ソフトの互換性を担当することにする。Learning Companyは、このジャンルでは常にベストセラーランキングに名を連ねるソフトを何本も持つ、教育ソフトの大手である。その会社のソフトがどれもWindows95で動かないのだ。

　さっそく調査を始める。確かにどのソフトもWindows95上ではちゃんと動かない。調べてみると、Windows3.1用のソフトであるにも関わらず、32ビットのレジスタを使ったインストラクションを使っており、それが32ビットレジスタの上位16ビットが全て０に初期化されていることを前提にしているため、システムが32ビット全てを使うWindows95上で走らせると、暴走してしまうのだ。

　その情報を持って、Kernel（メモリやプログラムを管理する部分）を担当するKevinに話に行く。「16ビットのソフトを起動する前に、全てのレジスタの上位16ビットを０にしてくれれば互換性が高まるはず」というSatoshiの説を訴える。最初はKevinも難色を示すが、結局のところ「それで互換性が高まるのであれば」と納得してもらう。

　変更を加えてもらったKernelでWindowsを立ち上げ、問題のソフトの一つ、Reader Rabbitを走らせてみる。先ほどよりは少し先に進めるが、やはり途中で暴走してしまう。別の問題があるのかも知れない。

　さらに解析を進めると、先ほどと同じような症状だが、今度はシステムコールをした後のレジスタの上位16ビットが０でないことに起因している。再度Kevinに相談に行く。

　「これは完全にアプリ側のバグだよ。システムコールを呼ぶと幾つかのレジスタの内容が破壊されるのはWindowsの仕様だよ。それをちゃんと理解せずに、システムコールの後もレジスタの上位16ビットが０のままであることを前提にしているプログラムを作る方が悪いんだよ」とKevinは言う。

　「しかし、そうは言っても、Windows3.1との互換性のためには出来る限りのことをするのが僕らの仕事ではないのか。」と食い下がるSatoshi。

　結局、Learning Companyのアプリが呼び出しているシステムコールのうち、問題となるものを見つけ出し、そこで破壊されては困るレジスタの値だけを保存するようにシステム側を変更することで合意する。

　しかし、実際にその作業を開始したSatoshiは、すぐにそれが気の遠くなるような作業であることに気が付く。システム側に２０箇所ほど変更を加えても、まだReader Rabbit一つ完璧に動かすことができない。こんな場当たり的な方法では効率が悪すぎる。

　時間はどんどんと過ぎて行く。スワットチームのどのメンバーたちも似たような壁にあたっており、「Windows95上で動かないソフトのリスト」は一向に短くならない。

　そんな作業を繰り返しながら、Satoshiは問題を起こすLearning Companyのプログラムにある一定のパターンがあることに気が付く。たぶん、彼らの使っているコンパイラが32-bitのデータを扱う時に生成するコードなのだろう。

　そこで、パターンをアプリ全体から探しだす作業をしてみた。アプリ一つあたり、数箇所から数十箇所に、そのパターンが現れる。アプリがそのコードを実行する前に、レジスタの上位ビットが全てゼロにしてなっていないと暴走するのだ。

　それを検証するために、Satoshiはメモリ上に展開されたReader Rabbitに変更を加えてみることにした。問題となるパターンの部分のコードを効率化してプログラムサイズを少し小さくし、あまったスペースに問題となるレジスタを０にしてしまうインストラクションを挿入したのだ。

　そうやって変更を加えた状態で走らせると、すべてがキチンと動作する。やはり予想通り、このパターンのコードが問題なのだ。

　Windows95上で初めてキチンと走るReader Rabbitを見ているSatoshiの頭に、突然一つのワイルドなアイデアが浮かぶ。急いでKevinのオフィスに走る。

　「Kevin、Kernelがアプリをロードするとき、それがあるソフトの特定のバージョンだっていうことは判別できるものなの？」
　「簡単だよ。モジュール名、日付、コードのチェックサムを見れば、すぐに判定できる。」
　「だったら、ある特定のアプリのコードをメモリーにロードした時に、指定した場所に変更を加えてから実行させるってことも出来る？」
　「もちろん、技術的には可能だよ。でもサードパーティのプログラムを実行時に勝手に変更するっていうのはまずいんじゃない？」
　「David Coleが『どんな手段を使っても』って言ってたじゃないか。やるしかないよ。」

　そこからSatoshiとKevinの共同作業が始まる。Windows3.1用に作られたサードパーティのプログラムをロード時にダイナミックに変更して、Windows95で動くようにしてしまうというウルトラCだ。SatoshiがReader Rabbitに加えるべき変更点をデータ化し、Kevinがそのデータを読み込んでパッチをあてる様にKernelのローダーを変更する。Reader Rabbitが新しいKernelの元で動くようになった時には、既に朝であった。

　その週のスワットチームのミーティングで、SatoshiとKevinはLerning Company製のソフト全てをWindows95上で動かすことに成功したこと、そして、その仕組みはLearning Company製のソフトに限らず、他のメーカーのソフトにも適用可能なことを発表する。

　スワットチームの何人かが、サードパーティのプログラムに勝手にパッチをあてることに懸念を示す。話し合いの結果、互換性問題の具体的な内容をそのアプリのメーカーに開示し、ダイナミックにプログラムに変更を加えることに対して文書で許可をもらえばOK、ということになる。

　スワットチームの他のメンバーもこの仕組みにすぐに飛びつく。この方法を使えば、「アプリ側のバグ」のためにWindows95上で動かなくなってしまったアプリを救うことが出来るのだ。

…

　翌年７月。予定通りの日付にWindows95をリリースした開発チームにDavid Coleが感謝の言葉を述べ、テーブルの上のシーツを取り除く。ドンペリが５０本あらわれる。「優勝した野球チームがビールをかけ合うのであれば、Windowsチームはドンペリだ。」という彼の約束どおりである。皆、一本ずつドンペリを手に持ち、頭から掛け合い、ラッパのみをする。シャンパンまみれになったSatoshiとKevinががっちりと握手をする。

（ITProの「本当はすごい『Windowsの互換性維持』」という記事で蘇った記憶に刺激されて書いたエントリー。事実には基づいているが、かなり脚色も入っているし、思いっ切り美化もしているので、その辺りは少し差し引いて読んでいただきたい。）

　会社にいるときは主にパソコンの前で仕事をしているのに、家に帰ってもついつい、すぐにパソコンに向かってしまう私だが、そんな私に投げかける妻の言葉が、少しづつ変化している。

結婚当時
「ねえ、パソコンばかりいじってないで、私の言うことも聞いてよ」

数年前
「ねえ、インターネットばかりしてないで、私の言うことも聞いてよ」

最近
「ねえ、ブログばかり書いてないで、私の言うことも聞いてよ」

　妻には申し訳ないが、これは大変興味深い現象である。確かに最近はブログを書いているケースが多いのだが、ブログを書くにはパソコンもインターネットも必要なのだ。それなのになぜ、もう「パソコンをいじっている」とか、「インターネットをする」と言わなくなって来たのだろう。

　私はこれこそ、パソコンやインターネットが、特別なものではなくなり、テレビや電話と同じく我々の生活の一部になった証拠だと思っている。例えば、日曜の朝のこんな会話を想像して欲しい。

「おっはよー」
「朝から元気いいのね」
「今、何してた？」
「『笑っていいとも』見てた」
「そっか。いまから『ダ・ビンチ・コード』見に行かない？」

　これが、テレビや映画が特別なものだった昭和４０年ごろだと、こうであったはずだ。

「おっはよー」
「朝から元気いいのね」
「今、何してた？」
「テレビ見てた」
「そっか。いまから映画見に行かない？」

　デバイスとかサービスが本当の意味で我々の生活の一部になって来ると、逆に言及されなくなるのである。

　全く同じ変化が、パソコンやインターネットに関しても起こっているのである。「パソコンをいじる」、「インターネットにアクセスする」といった行動がだんだん特別なものではなくなり、人は「アマゾンで買い物をしていた」とか「ブログを書いていた」というインターネット上での行為そのものを言及するようになってきたのである。

　その意味では、妻に「ブログばかり書いていないで…」と言及されてしまうブログは、まだまだ我々の生活の一部になったとは言えない。

　ブログが特別なものではなくなった時代には、妻のセリフはどう変化するのだろう？

  昨日のエントリーへのコメントでも引用されていたが（参照）、Naotakeさんの「ユーザー・エクスペリエンスの日本語訳としては、『おもてなし』が良いのでは」という指摘は結構正しい。ユーザー・エクスペリエンスを提供しているの良い例を引き合いに出そうとすると、どうしてもディズニー・ランドやセブン・イレブンなどの接客業を引き合いに出したくなるのも、うなずける。

　そう考えてみると、単一のデバイスだけでユーザーにとって価値のあるユーザー・エクスペリエンスを提供するのは難しく、ネットワークを通じて複数のデバイスを繋いで、なんらかのサービスを提供することが必須である、という前からの私の持論も、そのあたりの感覚から来ているのだということが良く分かる。

　その意味でも、この業界で明らかに一歩抜きん出いるのはアップル。iPod（デバイス）+iTunes（ソフト）+iTune Music Store（サービス）を巧みに組み合わせたユーザー・エクスペリエンスは、他のどのメーカーのものよりも一歩も二歩も上手（うわて）だ。

　UIEvolutionも、"User Expereience Matters"をモットーにする会社なので、アップルに負けない仕事をしなければならないと日々頑張っている。オンデマンドTV、ESPN Mobileと、サービス事業者向けのユーザー・インターフェイスの設計・勢作に力を入れているのは、まさにそのためだ（ちなみに、オンデマンドTVはスクエニとの共同開発）。

　ちなみに、"User Experience Matters" を日本語訳すると、「おもてなしは大切」。そんな接客業のような言葉をモットーにするテクノロジーの会社は、たぶんうちぐらいのものだろう^^。「おもてなし」に興味のあるソフトウェア・エンジニアの方は、ぜひともこちらを参照いただきたい。

　日本からシアトルに戻って、その足ですぐラスベガスへ、という強行軍をしていため、このブログの更新も少し滞ってしまった。ラスベガスでのカンファレンスの感想は、CNETのブログに書いたのでそちらを参照していただきたい。

　写真は、宿泊したMGMのとなりにオープンしたばかりのHootersが経営するカジノ。Hootersは、ぴちぴちのTシャツを着たセクシーなウェイトレスを売りにするレストランバー・チェーンだが、最近はエアラインやカジノ・ホテルにも積極的に進出しているのだ。

　以前に「セクシーさで従業員を選ぶのは不当差別に当たる」と訴えられたのだが、優秀な弁護士を雇い「Hootersのウェイトレスは雑誌のモデルと同じ。彼女たちのセクシーさは、Hootersならでわのユーザーエクスペリエンスを提供するために必要不可欠なもの。不当差別には当たらない」と弁明してしのいだことで有名だ。

　アメリカの法廷もユーザー・エクスペリエンスの大切さを理解してくれたということか…。

【追記】今気がついたのだが、Hootersは今月の１７日で航空ビジネスから撤退してしまったようだ（参照←英文の記事だが写真は見る価値がある）。それもこれもオイルの値段が高騰しているせいなのだが、Hooters Airに限らず、どの航空会社もかなり苦しいのだろう。

　機会があるたびに、「コンシューマー向けのウェブ・サービス・ビジネスを運営していく上で、一番大切なのは、ユーザーにとって価値のあるものが使えば使うほどサーバー側に蓄積していくような仕組みを提供すること」と分かったようなことを言い続けている私だが、気がついてみれば私自身が、思いっきり「ミイラ取りがミイラになる」状況に陥っている。

　まずは、以下の文章を読んでいただきたい。

　そもそもは、中島さんがなんとなくうちのnobさんにすすめられてはじめたブログが気がつけば2年たっていて、だんだんブログを書くことが仕事のような状況になってきたこと。Life is beautiful　を2年近く書いてきて、これが今、なくなったら僕はショックで立ち直れない。大切な自分の資産であり、それがあるから、仕事の中で個人に自信を持つことができるとおっしゃっていたのがきっかけ。TypePadがずっとなくなることがないよう、50万円ぐらいだったら永代使用料を払ってもいいぐらいだってｗ。だから、頑張ってくださいと中島さんにおっしゃっていただきました。有料のサービスでユーザーの方にそういっていただけるなんて、なんて幸せなサービスなんでしょう。とかいっておいて、あとはTypePadチームのみなさんよろしくお願いします。（shuiro note:ピヨピヨより引用）

　その通りなのである。これまで書き綴ってきたこのブログの数々のエントリーは、私にとってかけがいのない財産であり、そんな財産を維持・運営しているSix Apartという会社も、やはり私にとってとても大切な存在である。特にブログの場合は、エントリーだけでなく、それらに張られた数々のリンク、トラックバック、ブックマーク、コメントをすべてひっくるめての価値が高いので、内容だけコピーして他のブログサービスに引っ越すことなど想像もできない。まさに、消費者向けのサービスとして理想的な形に収まっている。

　そんな中で出てきたのが、ブログの永代使用料という発想。これは、死後のブログを「ネット上のお墓」として未来永劫アクセス可能にすることを保障するサービスである。「お骨なんかは海に撒いてもらえば良いし、お墓もいらないから、このブログだけは未来永劫アクセス可能にして欲しい」、と結構本気で考えてのことである。

　２００年後ぐらいに、ひょんなことからこのブログにたどり着いた誰かが、「２００年前にこんなことを考えていた人がいるのか～。今のテクノロジーを使えば簡単に商品化できるじゃん。」と実際に私のアイデアに基づいた製品を作ってくれるかも知れない。それは、ギークにとっての究極のロマン…

　先週の末に日本に来たのだが、外で人と会ってばかりいるので、なかなかUIE Japanのオフィスに顔を出すことができなかった。今日になってやっと皆と時間を過ごすことが出来たのだが、やはりもの作りの現場は楽しい。エンジニアたちが見せてくれるプロトタイプを見ながらあれよこれよとブレストしていて給料がもらえるのだから、こんな幸せな商売はない。５～６月ぐらいには、新しいサービスを二つぐらい公開できそうなので、乞うご期待！

　ちなみに、今日のメインテーマはさらなる人材募集。第一弾でウェブ・エンジニアの方たちを集めたのだが（参照）、今度はそれに加えて組み込みエンジニアの募集。

　UIE Japan 採用情報

　UIE/UIEJは世界でも類を見ない「ネットに繋がった組み込み機器向けのウェブ・アプリケーション・サービス」を end-to-end で本気で実現しようとしている会社（参照）。スクリプト言語でサーバー側のプログラムを書けるWeb2.0なエンジニアから、組み込みデバイス側でハードに直結した部分のプログラムを書けるエンジニアまで幅広く必要としているのだ。

　「スクリプト言語？甘えてんじゃないよ、必要とあらばアセンブラでハードを直接叩くのが俺達の仕事」、「VRAMにアクセスするときはV-Syncの割り込みと同期させなきゃダメだよ」みたいな、限りなくハードに近い部分でソフトウェアを作ることのできるスーパー・エンジニア大募集である。

　日本のお家芸である組み込み機器。携帯電話だけでなく、テレビ、カーナビ、DVDレコーダー、ステレオなどのさまざまなデバイスがネットにつながり、色々なウェブ・サービスへのアクセスポイントになった時には、映像や音楽の楽しみ方、人とのコミュニケーションの仕方、ゲームの楽しみ方、などが大きく変わることは明らかである。それを実現するためには、「ウェブ」と「組み込み」という全く異なる二つのタイプのスーパー・エンジニアをひとところに集めて、彼らのクリエイティビティを最大に発揮できる環境に置いてあげる事が一番。UIE Japanとはそんなことを考えている会社である。自分こそはスーパーエンジニアと思う方、ぜひとも応募していただきたい。

　先日、「サーチエンジン最適化遊びのススメ」というエントリーを書いて、「スパムはやめてくれ」などと一部の人に叱られてしまった私だが、６日後の今日になって「サーチエンジン最適化」でググると、一ページ目は逃したが、二ページ目のトップ、１１位に入っている（参照）。なかなかの健闘である。（【追記】７日目現在は１０位^^）

　では、私がどうやってあのエントリー（そして、一つ前の「Fカップ」のエントリー）をサーチ結果の上位に入れたか、種明かしをしよう。

　実は俗に良く言われるところのSEOは一切施していない。トラックバックなどもいっさい打っていない。ただ、エントリーを書いただけだ。「え？」と思うかもしれないが、本当だ。

　Googleのサーチビジネスに関して勉強してみると明らかになることだが（推薦図書：「ザ・サーチ」）、Googleが一番嫌うのは、ユーザーにとって価値のあるサイトではなく、SEOを人為的に施したサイトが上位に来ることである。インターネット黎明期のサーチと、Googleのサーチの根本的な違いはそこにあり、それが故にGoogleはあれほど成功しているのである。

　つまり、「人為的なSEOなど施せないようにすること」がGoogleのサーチに関わるトップ・サイエンティストたちに与えられた使命であり、そこがGoogleの生命線なのである。一時的にある種のSEOが効果を表したとしても、それはGoogleにとっては「退治すべきバグ」になるだけのことである。効果が高ければ高いほど、「次に退治する標的」になりやすく、悪質なSEOとみなされると「Google八分」にされてしまう可能性だってある。

　そこで私が到達した仮説は「人為的なSEOなんて、（ごく基本的な、『ちゃんとしたHTMLを生成しておく』以外のことは）しても仕方がないのではないだろうか？それよりも、中身の濃いエントリーを書いて、より多くの人に読まれ、多くの人に実際にリンクを張ってもらうことがGoogleのサーチ結果の上位のポジションを取る一番の近道なのではないだろうか？」というものである。

　その仮説を証明するために、あえてSEOのたぐいは一切施さず（注：ただしTypepadのMETAタグの自動生成を禁止したりはしていない）、その代わりに少し内容を刺激的にして、物議をかもしだすことを狙って書いたのが、例の二つのエントリーなのである。

　この実験結果を見るかぎり、妙に人口的なSEOを施すよりも、内容で勝負した方が良いという私の仮説は正しいように思える。

　こう考えてみると、「SEOビジネス」というものが、かなり「えせ科学」っぽく思えてくる。「あなたのサイトのトラフィックを増やすにはSEOを施す必要があります」と言うコンサルタントのセリフが、えせ科学者の「この水は分子構造が普通の水とは違い、これを飲むと体の中の悪いものが排除されます」というセリフと妙に重なる。

　「結局のところ、サイトの内容を充実させて人を集めるしかありません」ではコンサル料は取れないからSEOなのだろうが、それがまた「水道の水で結構ですから、毎日沢山飲むことが健康の秘訣です」と言っても儲からないセールスマンが訳の分からない水を高く売りつけている姿と良く似ている。

（あ、また物議をかもし出すエントリーを書いてしまった^^;）

　今回の日本行きの飛行機の中で読んだのは、John Battleの「The Search」（日本語訳は「ザ・サーチ」）。Googleと、その中心となるサーチビジネスに関して書かれた、とても中身の濃い本である。勉強になるだけでなく、ビジネス・ドキュメンタリー書としてのエンターテイメント性も十分に持ち合わせた読み応えのある本だ。

　その本に、最近私が強く感じていたことを、とても明確に表す文章に出会って、思わず強くうなずいてしまった。

　この感覚はすごく良く分かる。新聞やテレビなどの従来型のメディアから情報を得たとしても、それをe-mailで会社の誰かに伝えたり、ブログで引用したりリンクを張ったり出来ないことがものすごくもどかしく感じられるのである。仕方がないので同じ情報をネットで探して、それを引用したりしているのだが、そんなことをしているとこの本の著者と同じく「最初からネットで情報を得た方が便利じゃん」と感じてしまうのである。

　情報をニジマスに例えれば、従来型のメディアは「釣った魚を持ち帰れない釣堀」のようなものである。「せっかく釣ったニジマスは、家に持ち帰って燻製にして近所の人に配ってこそ価値があるのに、それができないなら最初から川（＝インターネット）で釣りをした方がいいよ」という話である。

（ちなみに、ニジマスは燻製よりも塩焼きの方がずっとおいしいと思うのだが、塩焼きは冷えてしまうとおいしくないので、ここはあえて冷えても大丈夫な燻製で。でも、塩焼きだったらやっぱり鮎かな…って、どんどん話がそれて行くので今日はこのくらいにしておこう。あ、また食べ物にたとえてしまった^^;）

　ようやく野球シーズンも始まり、街に活気があふれてきたシアトルだが、私が毎年この時期に楽しみにしているのが、シアトルマリナーズが放映するTVコマーシャル。ユーモアにあふれた映像がマリナーズファンの心をくすぐる。

　今年のコマーシャルはイチローの独特のセットアップフォームをおちょくったもので、なかなかの秀作。YouTubeにコピーを見つけたので、リンクを下に張っておく。

http://www3.youtube.com/watch?v=OE23BxwwSN4&search=seattle

　ちなみに、YouTubeはこんな形でしばしば取り上げられるが、この例のように明らかに著作権法に引っかかるようなコンテンツがアップロードされている点が問題である。そんな問題を抱えながらも、つい最近$8M（約８億円、ちなみにM=Million）の追加投資をSequoia Captalから受けたことがニュースになったばかりだが（参照）、ビジネスになるかどうか分からないWeb2.0企業としては適切な投資額とvaluationである。このくらいの投資額にとどめておけば、Yahooから数十Mダラーのオファーが来た時にきれいにexitできる（exitとはベンチャー企業が上場もしくは買収により「ベンチャー企業状態」から抜け出すこと）。Yahooがdel.icio.us、Flickrの買収に費やした金額（どちらも数十万ドル）を考えれば、このくらいが妥当なのかもしれない。

　そう考えると、Facebookが$750M（約７５０億円）の買収を蹴ったことは理解しにくい。MySpaceが$580M（約５８０億円）で買収されたことを考えれば、$750Mは十分とは思えるのだが。BusinessWeekによると（参照）、ファウンダーたちは$2B（約２０００億円）ぐらいでの買収をめざしているとのことだが、そこまで行くとさすがにネットバブル2.0だ。

　そう考えると、あちら側の企業（Yahoo）があちら側の企業を買うときは、数十Mダラー（数十億円）しか出さないが、こちら側の企業（News Corp、Viacom）があちら側の企業を買うときは数百Mダラー（数百億円）を出す、という妙なパターンが見えてくるのだが、ここにものすごく違和感を感じるのは私だけではないはずだ。

　CTIA2006が先週ラスベガスで開かれたことは、すでにこのブログに書いたが、一つ大切なことをアナウンスし忘れていた。米DisneyがUIEngineで作ったRPGゲーム「The Chronicles of Narnia」が、GameSpotとCNetの主催するモバイル・エンターテイメント・アワードの「RPG/Adventure」ゲーム部門で堂々の二位に選ばれたのだ（参照）。一位を取ったのは同時に全部門での金賞に輝いた「Doom RPG」である。

　The Chronicles of Narnia は米DisneyとUIEvolutionが共同開発したAJAXスタイルのRPGゲーム。世界１７カ国、３００機種に向けてほぼ同時にリリースされたのだが、UIEngineがJava・BREWといったプラットフォームの違いや端末ごとのクセやバグを吸収するので、ゲームそのものは一つだけ作れば良かった、というのが売りである。技術的には「Doom RPG」よりはるかに面白いことをしているのだが、今回のアワードは純粋にゲーム性に関するものなので、しかたがない。

　ちなみに、このRPGゲームを共同開発する際に、うちのエンジニアが最初に作ったのは、UIEngine上にRPGゲームを作るためのツール。これを使えば、プログラマーでなくともRPGゲームが作れてしまうのだ。そのうちウェブ・ベースのものでも公開したいと考えているので、少々お待ちいただきたい。