４月１１日金曜日午後7時、俣野努氏セミナー開催レポート
MAZDAが世界に誇る「Miata」のデザイナーの俣野氏。元々、日本の大学で工学部に在籍していものの、車のデザインをしたい一心でロサンゼルスにあるカーデザイン界トップの「Art Center College of Design」で学位を修得。現在、サンフランシスコの「Academy of Art University」のIndustrial Design Departmentのトップとして、後進のインダストリアル・デザイナーの育成にあたっておられます。
今回のセミナーは、右手と左手の組み方によって、左脳派、右脳派の人間に分ける事ができるという実験から始まり、話は俣野氏の経歴、そして彼のデザインスタンスの話へと移りました。下記では俣野氏のデザイン理念と実践方法を中心に紹介していきます。
●中身から生むデザイン
表面的なデザインは一時的にはもてはやされるが、長期的に見た場合、消費されてしまうデザインとなってしまう。その点、その車のエンジンなどの機能を含めた性質から考えられた「中身から生むデザイン」は何年経っても人の目を引付ける事のできるものになる。これは、無理のないコンセプト立てができることにより、量産されるまでのコンセプトにぶれが少なくなるからである。例えば、フロントが極端に尖っているスポーツカーのデザインは一見良く見えてしまうが、フロントが極端尖っていることによって、リアからフロントへの線を引いた時の軸が下へと向いてしまい、車が急ブレーキをかけているようなイメージを消費者に与える事となり、時間が経った時に、飽きられてしまうと考えられる。実例として、Miataは運動性の高い車として、この中身からデザインという手法をとっているため、スポーツカーとして長期的に愛される車となっている。他の例をとして、「筋肉質な車」としてデザインされたRX-7は、後の消費者アンケートの結果、体を鍛えるのが趣味というオーナーが7割を占めていた。
●環境から生まれるデザイン。
センターコンソールにあるエアコンスイッチ、オーディオの位置は各国によって違う。これによりどこの国の車かを知る事が出来る。また、この違いは各国のスイッチのニーズの違いによって発生するもので、環境から発生しているデザインだと言える。また、アメリカの車と日本車の違いの例に、生まれ育った国の駐車場の大きさ、道路の広さなどの環境距離感によって、各国のデザイナーはそれぞれの感覚をもってデザインしているといえる。実例として、日本では駐車はバックから入れることが多いが、米国は駐車場自体が広いため、車は全くの逆で頭から入れられる。よって、アメリカ市場に向けてデザインされていたMiataの場合、停車中の車を見る歩行者から注目されるのは車のリア・フェイスとなるり、また、運転中に関しても後ろの運転者から見えるのは、同じくリア・フェイスであり、リア・フェイスにこだわった車にしている。更に、Miataのインテリアの基本色であるベージュを例にとっても、アメリカデザインチームがイメージする色と、日本チームのイメージする色では異なってた。
●俣野氏のデザインスタンス実践方法
俣野氏は彼のデザインスタンス実践方法の一つとして、自分がそのモノになって考えるという方法を紹介。例えば、電気のスイッチ。汚い手で触って欲しくなかったら、汚れにくい材を使う。乱暴に扱って欲しくなかったら、切り替え部分をスムーズになど、自分自らをそのモノ置き換える事で内側からデザインを生む事が可能となる。
講演終了後、懇親会へと移り興奮冷めやまぬ参加者に囲まれ、質問攻めにあうも一つ一つの質問に丁寧に答える俣野氏。参加者一同、普段とは違う分野から、しかも、世界のトップを走るデザイナーから直に話を聞く事ができた、とても意義有る時間となったのではないかと思います。
＊会場に来られなかった方のために、セミナーの様子をUstreamで見る事ができるようになりました。ご興味のある方は以下のＵＲＬからご覧ください。http://www.ustream.tv/channel/jtpa-geek-salon
(開催レポート by Sunny Tsang）
————— 以下はセミナーの告知文です ——–
月: 2008年3月
3/21/2008 ギークサロン「Erwan Loisant 氏と Flock について語る」参加レポート (by Ryosuke Matsuuchi)
サロンは 19:30 に開始しましたが、途中の 21:00 ごろの中締めを挟んで、夜中の 24:00 ごろまで実に様々な話題が飛び出しました。下記のレポートは、中締めの前・後の内容を順不同で要約したものです。Erwan さん、本当にありがとうございました。
■1. Erwan Loisantさんの経歴
2006年、東京都立大学とナント大学(パリ)の博士課程にて Navigation-based Image Retrieval という研究課題 (例: http://www.dbsj.org/Japanese/DBSJLetters/vol3/no1/papers/Loisant.pdf)
に取り組んでいた彼は、論文を目的とした研究ではなく、実際にユーザーに使われる仕事がしたいと考えるようになっていた。
そのとき学業の傍ら取り組んでいた Flock Extension の開発がきっかけとなり、Flock 社のブログを通じて応募のメールを出してみたところ、Erwan さんが XUL に詳しいこともプラスとなって1日で面接＆採用決定、次の日にはビザの準備を開始という展開に。 Erwanさんは入社後、Blog Editor
(http://www.flock.com/user-guide/blog/posting.html) や Web Clipboard
(http://www.flock.com/user-guide/1.0/advshar.html) の開発エンジニアとして活躍中です。
Flock は、FireFox をベースに、People Sidebar、Blog Editor、Feed Reader、Media Minibar などの機能が追加された Web ブラウザです。 先日、iPhone SDK が1日で10万ダウンロードを記録したことが話題になった一方で、Flock は現在、延べ約 3 百万ダウンロードを達成しています
(http://www.flock.com/node/61397)。
Flock社の設立は2005年、最初はガレージでみんな作業していました
(http://www.flickr.com/photos/foolswisdom/61079990/)。 現在は Redwood City とカナダの Victoria にオフィスがあるそうです。 (参加者の廣島さんいわく、Redwood City にもある Beard Papa’s (http://www.muginohousa.com/index.php) のシュークリームは絶品とのこと)
■2. Flock社のビジネスモデル
Flock はどうやって利益を上げるのか？ との問いに、「検索が中心です」と答える Erwan Loisant さん。 Google, Yahoo! などの検索広告の流通をめぐる市場の成熟により、 FireFox や Opera のようにブラウザを無料で配布しつつブラウザ開発者が利益を上げる仕組みができつつあります。 Flock 社のブログの Bart Decrem さんのエントリ (http://www.flock.com/blog/creating-sustainable-value) によれば、Webブラウザにはまだまだ改善の余地があり、「We firmly believe that doing right by our users is the best way to build a sustainable, successful company.」とのこと。
現在、Flock のライセンスは GPL (GNU General Public License)。 「それを利用したソフトも GPL で再配布しなければいけない」という厳しいものです。 Erwan さんは、「Flock の Philosophy として、利用したら貢献すべき、というのがあると思います」とのこと。これに対して MPL (Mozilla Public License) や(New) BSD License の場合は そこまでの制限はありません。
参加者の奥井さん曰く「オープンソースというと即『うちの製品はオープンソースではないので、オープンソースの技術は使ってはいけない』と勘違いしている人も多いのには困る」との体験談、まだ GPL 以外の形態のライセンスの認識が浸透するには時間がかかりそうです。
■3. FireFox/Flock Extension の開発手順
Erwan さんは Mozilla の歴史について簡単に紹介してくださったあと (Mozilla の名前の由来は “Mosaic Killer” を Godzilla (ゴジラ) 風に縮めたものだそうです)、さっそく FireFox Extension の開発手順の紹介へ。 開発プラットフォームとして FireFox Extension を選ぶことの Pros, Cons については、Pros としてはマルチプラットフォーム対応が容易であること、JavaScript は特別な開発環境を必要としないこと、 Cons としては multi threading が使えないこと (FireFox API の多くは残念ながら thread safe ではない)や、ドキュメントがあまり整備されていない点があるとのことだそうです。
次に、XPI package の仕組みなどについての紹介があったあと、 具体的に Extension のソースコードを紹介しながら Erwan さんがその開発手順を解説してくださいました。 Flock は、大きく分けて「UIモジュールの追加 (例: People Sidebar, Blog Editor, Feed Reader, Media Minibar, …)」「新しいサービス (twitter とか facebook とか) への対応」という 2 つの方法で拡張することができ、その拡張モジュールは JavaScript または C++ で記述可能です。 たとえば、Flock の API の flockIBlogWebService というインターフェースを使って、 ブログへの投稿をする UI を自分で自由に作ることができます。 基本的な手順は、.idl で定義されているインターフェースを拡張して、 JavaScript や C++ を用いてその実装を提供するという流れです。(具体的なインターフェースについては http://developer.flock.com/ とか http://developer.mozilla.org/ を参照してください。)
続いて、Erwan さんによる XLU (ズルー、と発音) 開発のデモ。 XLU は Mozilla, Flock などで利用されている UI 記述マークアップ言語で、Linux, Mac, Windows のどれでも動作するのが利点です。 ブラウザの中だけではなく、XLURunner (http://developer.mozilla.org/en/docs/XULRunner)
のようなツールを用いてスタンドアロンのアプリとして実行することもできます。 大変便利なマークアップ言語ですが、 Erwan さんによれば「XLU がスタンダードになることはおそらくないでしょう、 Mozilla はそれを意図してはいない」とのことです。
Flock では FireFox に搭載されている技術の一つである XPCOM を使って、JavaScript のモジュールと C++ のモジュールが相互に動作できるようにしています。 Erwan さんによると、「Singleton パターンを実現するためには従来は XPCOM を使うしかなかったけれど、 FireFox 3 からはそれが必要なくなる (新しい JavaScript の仕様でサポートされる？) のでその目的では XPCOM は使わなくてもいいと思う。けど、サービスを作るには必要だから、知ってて無駄ではありません」とのこと。
ブックマークは従来 Flock 独自で開発していたものの、FireFox 3 から登場する Places (http://wiki.mozilla.org/Places) に統合していく予定。 del.icio.us などのサービスも今後 Places を使うようになりそうなので、今後は ブックマークを複数の場所で管理する必要性は減っていきそうです。
この Extension の仕組みを使えば 基本的に何でもできてしまうので、 FireFox や Flock のExtension をインストールするときは (悪いモジュールではないかどうか) よく注意してください、とのことだそうです。
■4. Flock社内の開発プロセス
Flock や Mozilla の Extension を開発するとき、 javascript のデバッグはどうやっているのか、との問いに対しては、Erwanさんいわく「基本はログ出力ですね」。 ブラウザの about:config ページにてjavascript.options.showInConsole を true に設定し、DOM Inspector や Firebug を使いながら開発しているそうです。 Flock社には、Venkman を使っている人もいるそうです。「step実行ができない javascript と、デバッガ環境が充実した C++ と、どっちが生産性が高い？」という質問も出ましたが、C++ は環境ごとにコンパイルしなおす必要がある点がやはりデメリット。
Flock 社内では、trac (http://svn-mirror.flock.com/trac/flock/browser) と Bugzilla を使っていて、svn commit があるたびに自動的に build と automated test が走る仕組みになっているとのこと。 それぞれの Automated test は javascript で書かれていて、テストの成功・失敗を自動的に報告するようになっています。 Test driven とまではいかなくともこの種の自動テストの仕組みは、品質を落とさずにスピーディーに開発をすすめる上では重要な仕組みのようですね。
Mozilla や Flock について自分に必要なバグ修正がある場合は、 たとえば
http://www.mozilla.org/owners.html とかで該当モジュールの関係者 (Peers) を探し、その人に irc.mozilla.org や irc.flock.com で直接コンタクトをとって、 “Hi, do you know who can review bug ###?” とかきいてみるのが有効とのこと。 bug report に「私も困ってます」みたいなコメントを書くのもいいかもしれません。
■5. 今後の技術
ブラウザの未来形は？ という質問には、Erwanさん曰く「スタンダードにならないとひろがらないと思います。 例えば SilverLight とかは一時的なものになりそうですね。 たぶん、HTML 5 がその未来を指し示していると思う」。