この記事では UXデザインのときに、まず最初に、ユーザーのメンタルモデルを、オブジェクト指向的に分析・定義することを、提案してる。このアプローチを、OOUXアプローチと呼ぼう。
オブジェクト指向やUXの意味は、人によって地味に異なるので、OOUX という言葉は誤解を生むのかも知れない。
要件（と呼ばれるウィッシュリスト）から、ソフトウェアの仕様を定義する立場で仕事を請けているんだけれど、このアプローチは有効だと思った。
[エンジニアは]ワイヤフレームやプロトタイプを見た時に、デザインをリバースエンジニアリングしてオブジェクトを抽出します。そして彼らは、「オブジェクトXはオブジェクトYとどのように通信するのか。オブジェクトAは複数のオブジェクトBで構成されていのか。オブジェクトの属性は何か。このクラスのオブジェクトはあのクラスのオブジェクトを継承するのか。」と思うでしょう。
ユーザのメンタルモデルを模倣するオブジェクトを定義することで、チームのコミュニケーションの土台となります。共通言語を手に入れられるのです。
ソフトウェアが対象にするものが、技術的なレイヤーから見て高ければ高いほど、この種の作業は必要になる。OOUX は、このための共通言語の表記の仕方とアプローチの提案なのだ。
脱 UML
似たようなアプローチとして、ドメイン駆動設計がある。オブジェクト指向的に問題ドメインをとらえることで、要件が分かるしコミュニケーションとれる、という考え方だ。ドメイン駆動設計では UML っぽい図をつかって表記する。これは悪くはないんだけれど、うまく伝わらない感がある。記号にルールがあって説明が必要になるし、後述するけど multiplicity がうまくイメージしてもらえないときがある。
OOUX のアプローチ
手順としては、まず要件のリストのようなものから、オブジェクトを抽出する。たいていは名詞がオブジェクトになるんだけれど、暗黙に想定しているオブジェクトがあったりする。
次に、オブジェクトの属性を挙げていく。さらに、他のオブジェクトを参照するのであれば、それを書いておく。これらを優先順位付けしろ、話はそれからだ、という手順だ。
メソッドやメッセージのやりとりは、ここでは定義しないようだ。これは欲しいなぁと思うので、今後自分が使うときには、なんか記載するようにするかも知れない。
さて、このとき UML を使わない。
- レシピ
- 材料
- 材料
- 材用
- ...
- 手順
- 材料
- 名前
- 説明
みたいに書く。
レシピには1以上の材料が必要だろうから、1..* とかって矢印を引きたくなるんだけど、そうしない。
本当はUMLとやってることは同じだ。けど、1..* よりも具体的に材料、材料、材料、...と書いておくほうがイメージが湧く。
設計するにあたって、あるいは、いざ実装し始めてから、以下の様な会話をして泣いたことが何度もある。
「ここって複数なんですか？」
「ほとんどは、1つしかないよ」
「3つっていうのは絶対にない？」
「たまにある」
「それは表示する必要がある？」
「もちろん」
「100個の場合も？」
「まあね。でも、ほとんどは1つだから、気にしなくていいよ。」
気にしますね。とっても、気にします。たとえ1ケースであっても、99999オブジェクトを参照する可能性があるなら、ちと考えたくなるものです。
SNS を使うようなのは、これがしょっちゅうある。ほとんどのユーザーのフォロワーは100人くらいで収まるけど、たとえば @takapon_jp には 14万人のフォロワーがいる。
UML の 1..* と書いてあるよりも、
- レシピ
- 材料
- 材料
- 材料
- ... 最大1000 ...
- 手順
のほうが、UMLに馴染みがない人にも、可視化できるというわけだ。
実装がオブジェクトになるかどうかは、また別の話。RDB で管理するとか、KVS とかは、今は別の話。開発の工数や、成果物の効果によって、つまり費用対効果を考えて、10個までに制限するとかいう議論はあるけど、今は、その前の話をしている。
発注側が意識しているかどうか別にして、現時点の想定では上限の無い 1..* が、まずは要件の草稿になっていることが明らかになるのだ。
さっそく使ってみた
マーケットプレース（楽天とかね）みたいなのを考えることがあった。このとき店舗オブジェクトを考える。この店舗にいくつか種類があって、abstract 店舗から、concrete 店舗を4種類派生させるような感じだった。けど、UMLにせずに、
通販店舗、デジタル商材店舗、...みたいにあえて、コピペで書いていった。そうしたら、どうもビジネス主体（会社とか）が、複数の店舗を持つことができて、かつ、ビジネス主体ごとに売上を管理する必要がある、みたいなことが明らかになった。最初のウィッシュリストには、どこにもそんなことは書かれていない。
1年ほど前に、似たような状況でUMLを使って説明し、ほんとにこういうの要らないの？と確認したときた時には、完全にスルーされた。あとから会社単位の売上管理が必要だと言い始める、という、だるい展開だった。
1年前と先週の違いは、図の描き方だけではないので、必ずしもOOUXのアプローチの優位性を示さない。けれど、よさそう、という印象を持った。機会があれば、かつ適切そうであれば、今後もこのアプローチを使っていこうと思う。
OOUX が目指していないであろうこと
原文ページのコメント欄や、SNS での言及をみていると、OOUX のスコープを把握できない人がいるように見える。
前提として、この記事は、同じ種類のコンテンツが大量にあるような、ウェブサイトの見え方/体験の設計という意味で、UX デザインという言葉を使っている。選挙（選挙区ごとに結果が出ますね）、レシピ、DIY とか。この種のウェブサイトのコンテンツでは、クラスとインスタンス、という考え方が比較的あてはめやすい。
20年ほどの昔、オブジェクト指向で要求を分析し、オブジェクト指向で設計し、オブジェクト指向で実装すると、分析・設計・実装で共通のオブジェクトを使える、という夢を見ていたことがありました。が、実際には、そうはいかない。
OOUX もドメイン駆動開発も、メンタルモデルをオブジェクトにマッピングしましょう、という考え方だ。決して、いきなり実装しようとはしていない、と私は解釈している。実装するときのモデルとは大きく異なることがあるだろう。
さらに、単純にマッピングできないこともあると思う。当初は想定さえしていなかったような、暗黙のコンセプトが、オブジェクトとして浮き彫りになることもある。
「それは 0以上なのか、1個なのか、N個なのか？」が自分には分からないが、知らなければならないとき、OOUXで紹介された記述の仕方が使えるのだ。
