ただいまIAIのMLで話題になっている、37 SignalsのRyan Singerによるブログ記事「iPhoto ’09 and Domain Language」が面白かったので、覚え書きを。
以下にざっと要点を訳してみます。
.mm {border:1px solid #ccc;background-color:#eee;padding:1em;margin-bottom:1em;}
「ドメイン」とは、何かアプリケーションを使う際に関わっている生活状況（life situation）のこと。たとえばiPhotoのドメインは、“手元に多数の写真があるので、それらを見やすく整理したり、家族や友達と共有する”というシチュエーションだ。
面白いのは、アプリケーションにはその分野ごとに定番のアプローチがあること。デザイナーは、ドメインをひとつの大きなケーキのようなものとみなし、それをいくつかのピースに切り分けるが、iPhoto ‘08以前の写真管理ソフトは、みんな「Photos」と「Albums」という切り分け方をしていた。ただし、他人のソフトをパクったのではない限り、ドメインがあらかじめ切り分けられていることはあり得ない。現実のややこしい状況を扱いやすいレベルでどう切り分けるか、各ピースにどんな名前を付けるかは、デザイナー次第だ。
この切り分け作業を経て、「ドメイン言語」が生まれる。ドメイン言語とは、切り分けたピースとそれに付けた名前から成り立つ、ドメインの切り分け方を示す言葉の集合のこと。ドメイン言語こそが、そのアプリケーションの個性の決め手となる。で、Appleはこの2年ほど、iPhotoのドメイン言語をかなり意図的に変革している。
他と代わり映えしない「Photos」と「Albums」の世界だったiPhotoに、iLife ‘08で「Events」という切り口が加わった。これは大事件だった。Appleは、ユーザが写真をただランダムに見るだけじゃなく、共通項のある写真をまとめて見たり共有したがっていることに気づいたんだ。たとえば、結婚式の写真、旅行の写真、特別なディナーの写真というように、写真はイベントという共通項で括れる。イベントはiPhotoのドメインの一部で、2008年以降、そのドメイン言語の仲間入りをしたことになる。
さらにiPhoto ‘09で、Appleはそのドメイン言語をまたランクアップした。「Events」に加えて、「Faces」と「Places」という切り口が登場したのだ。Appleはこれらの新たなピースを写真管理というケーキから切り出し、写真の探し方や楽しみ方における新たな可能性を開拓したと言える。
僕らデザイナーは大抵、他の同類のアプリケーションと同じドメイン言語を使いがちだ。でも、そうやってドメイン言語をコピーしてしまうことにはご用心。なぜなら、それをコピーするのは、アプリケーションが採るアプローチまでコピーすることに等しいから。
肝心なのは、自分自身の言葉で、自分のユーザの真のニーズを捉えることなんだ。
Ryanが取り上げている、プログラミングの分野での「ドメイン」は、「ドメイン駆動設計（Domain-Driven Design）」略して「DDD」というコンセプトを通じて知られているものです。
DDDについては、以下のオージス総研のウェブページに日本語でのわかりやすい解説がありますので、興味のある方はぜひご一読を。
- DDD難民に捧げるDomain-Driven Designのエッセンス – 株式会社オージス総研
上記の解説で参照されている書籍『Domain-Driven Design: Tackling Complexity in the Heart of Software
また、上記の解説を読むと、DDDはアジャイル開発プロセスやパターン言語を活用するものであり、現在のウェブデザインのトレンドにも非常にマッチする面が多い考え方であることが分かります。そこに目をつけたのは、ウェブ開発とソフトウェア開発のノウハウが融合しているというRailsの世界に身を置いている彼のようなデザイナーならでは、ですね。
なお、この記事はコメント欄でも読みがいのあるディスカッションが行われています。
たとえば、ドメイン言語は我々が使う「日常言語」に即していなければ役立たずだという意見があり、そういう失敗例としてFacebookの“Wall”や “Wall-to-Wall”の分かりにくさが指摘されたりしてます。確かにｗ。
他にも、情報アーキテクチャとDDDの違いや、情報の体系化の切り口が現実を模したメタファー（＝アルバム）から完全にバーチャルなファセット（＝イベント、顔、場所…）へと拡大していること、などについても議論が交わされていて、非常に興味深いです。
私自身、これまでDDDについてまるで知識がなかったので、このRyanの記事をきっかけに、もう少し探ってみたくなりました。
そう、そこが非常に画期的ですよね＞ファセット属性を指定するユーザーの負荷を大幅に低減させたこと
結局、どんな便利なタギング機能があっても、実際こまめにタグを付けるユーザの方が少ないわけなので・・・
その打開策として、たとえばタギングの対象がテキストであれば、形態素解析してシステム側でタグを付けてしまうことも比較的簡単かと思うのですが、画像というノンバーバルな対象についてそういう“自動タギング”的なソリューションが実現しつつあるのは、とても面白いと思います。
iPhoto 09 の Faces と Places に限っていえば、ドメインというより単にファセットではないかと思いました。
もうひとつ言及すべきこととして、ファセット属性を指定するユーザーの負荷を大幅に低減させたことがあげられると思います。顔認識とかで。
定性的な分類をファセット属性として入力するのは、普通は人の判断が必要だから面倒な作業になりますが、そこをなんとかしてしまったのは驚きです。（というかまだ使ってみてないのですけどね）
Apple は、フォルダによる固定的な情報管理から脱皮するために、かなりの努力をしていますね。