ドメイン駆動設計とOOUXで迎える2019年

概要

DDDが、デザイン界隈で注目されだした「OOUX」という設計手法を吸収合併すると皆んながハッピーになるはず、という主にはUI設計のお話です。

OOUXとは

Object-Oriented User eXperience の略で、端的に言うと、UIを設計する際「（ユーザのアクションでなく）オブジェクト視点で設計するとより直観的なUIが作れるよ」という手法 ¹です。考え方自体はOOPが提唱された時代から（OOUIという呼び名で）あったようなのですが ²、UX界隈では2016年頃から話題にのぼるようになりました。

このアドベントを見ている方はほぼエンジニアだと思うので、UI設計者の進化についての、個人的な解釈・経験に基づく乱暴な説明（下記1〜３）から始め、それをDDDでさらに進化できる！という私の思いの丈（4）を語り、この場を借りてDDUXという言葉を提唱したいと思います ³。

1. UX以前のUI設計
2. UX以後のUI設計
3. Object-OrientedなUI設計
4. Domain-DrivenなUI設計

※ちなみにUIとUXが入り乱れていますが、UX（体験）の設計の一部としてUI（直観的なインタフェース）の設計が求められるという位置付けです。

UI設計者の進化

1. UX以前のUI設計

ユーザ体験という概念を取り入れる以前、UI設計者が目指していたものは単に__使い易さ__でした。これは今でも変わらず大事な指標の一つではありますが、単に直観的に操作できるUIを設計していたわけです。

直観的とはどういうことでしょうか。DDDでも出てきますが、人の頭の中には物事を抽象的かつ関連的に捉えたメンタルモデルがあるとされています。このメンタルモデルと実際の操作が直結する場合、直観的で分かり易い、となります。

しかし、メンタルモデルに近いUIが良いとは言っても、それを導き出す明確な手法があったわけではありません。UIを選ぶ際、「既にある、メンタルモデルに近いUIを選ぶ」ことはできても、全く新しいシステムの操作で、「新たなメンタルモデル構成し易いUIを作る」ことは難しかったでしょう。

具体的な設計手順としては、

1. ユーザのユースケースを洗い出し、ユーザのアクションを明らかにする
2. 明らかにしたアクションを__グルーピング__・__優先度__付けをして、主要画面を作る
3. 作った画面毎に、要件を満たす必要十分を目標に、UIデザインパターンから対象画面の操作として__適切なもの__を選んで当てはめる

という感じでしょう。

何を持って「適切」か。これは先述のメンタルモデルに親しいもの、が答えです。

では、アクションのグルーピングはどうグルーピングするのでしょうか。よく見るのは、アクションなので「動詞」で括っているものです。調べる、追加する、開く、…etc.

グルーピングしたアクションの優先度の付け方はどうでしょうか。指標として「利用頻度」を使うことに疑いを持つ人は多くなかったようです。よく使うのだから目立つところに配置する、ということですね。

具体例：チケット管理システムのUIを考える（UX以前）

Redmineのようなチケット管理システムを例に取って実践してみます。ユーザアクション視点で考えると、トップレベルのアクションは

• チケットを追加する
• プロジェクトのチケット一覧を見る
• 自分のチケット一覧を見る
• チケットを検索する
• ガントチャートを見る

となります。メニューを 「 マイチケット | 新規チケット | チケット一覧 | チケット検索 | ガントチャート 」 として、マイチケットを初期表示するのが素直な__画面割り__でしょう。チケット詳細も含めると画面数は６つです。

動詞でグルーピングの例としては、RedmineではWikiの管理もできますが、トップレベルに「検索する」を用意し、コンテキストメニューとして「チケット検索」「Wikiを検索」を用意するなどです。

2. UX以後のUI設計

単なる使い勝手だけでなく、その上位にくるユーザの体験そのものを設計するという試みがUXです。単なるシステムのユースケースに留まらず、システムを使う前から使った後までのユーザのアクション、思考、それに伴う感情の揺れなどをジャーニーマップとして書き出し、最高の体験を定義します。

UXデザイナによるUI設計の具体的な手順としては、

1. ユーザジャーニーマップを作成し、ユーザのアクションを明らかにする
2. 明らかにしたアクションを__グルーピング__・__優先度__付けをして、主要画面を作る
3. 作った画面毎に、要件を満たす必要十分を目標に、UIデザインパターンから対象画面の操作として__適切なもの__を選んで当てはめる
4. 使っているところを検証して1〜３を繰り返す

1〜３の手順は大きくは変わりませんが、グルーピング、優先度の指標が異なります。アクションは、ユーザの目的でグルーピングし、最高の体験にどれだけ寄与するかを指標に優先度付けします。

ユーザがよく使うからと言って、それが必須であるかは別、というスタンスです。例えば検索窓の利用頻度が高かったら、UX以前のUI設計者は検索窓を一番目立つところに配置するでしょう。一方、UX以後のUI設計者は、ユーザを観察し、インタビューし、ユーザは本当は特定の文言がタイトルに入ったチケットを抽出したかったことを明らかにして、タグ機能を付け加えるのです。さらにユーザが使うタグに時系列があることを見つけたならば、ワークフロー管理機能という潜在需要を見出し、機能追加を提案するでしょう。これは例えば「チームでの業務がサクサク進む」という最高の体験を目指すからこそ生まれるのです。

3. Object-OrientedなUI設計

さて、ようやくOOUXのお話です。おさらいになりますが、OOUXとは、UIを設計する際、ユーザのアクションでなく、オブジェクト視点で設計するとより直観的なUIが作れるという手法です。

設計者は、ユーザのやりたいことを実現する手段を提供しているので、どうしてもやりたいこと＝アクションを手掛かりにUIを設計しがちです。しかし、メンタルモデルの観点から見ると、アクションの対象物、つまりオブジェクトを手掛かりにUIを設計した方が直観的なUIになるというのがOOUXの基本的な主張です。

手順を示します。

1. ユーザジャーニーマップを作成し、ユーザのアクションを明らかにする
2. ユーザジャーニーマップやアクションから、オブジェクトを抽出する
3. オブジェクトに__優先度__付けをする
4. 要件を満たす必要十分を目標に、UIデザインパターンから対象オブジェクトの表現として適切なものを選んで当てはめて調整する
5. 使っているところを検証して1〜３を繰り返す

具体例：チケット管理システムのUIを考える（OOUX）

先程のRedmineのようなチケット管理システムの例をオブジェクト視点で見直してみましょう。

• チケットを追加する

• プロジェクトのチケット一覧を見る
• 自分のチケット一覧を見る
• チケットを検索する
• ガントチャートを見る

のアクションから、チケット、プロジェクト、ユーザ、チケットリスト、ガントチャートというオブジェクトが見えてきます。

チケットは言わずもがなですね。チケットを一覧にしたリスト、これもオブジェクトです。自分のチケット一覧なのか、プロジェクトのチケット一覧なのか、はたまた完了したチケットの一覧なのか、抽出条件というプロパティがあります。

ガントチャートも同様ですね。リストかチャートかの違いはあれど、抽出条件のプロパティを持つオブジェクトです。

プロジェクトのチケット一覧、自分のチケット一覧、検索結果のチケット一覧と、この中ではチケットリストが一番需要が高いので、中心的なオブジェクトをチケットリストとします。リストは行を選択することで詳細を表示するものとします。

画面を開いた時、どんなリストであるべきでしょうか。観察の結果から、第１位は自分のチケット、第２位がプロジェクトのチケットだとします。これらはセグメンテッドコントロールでスイッチできるようにするのが良さそうです。

ユーザは自分の思い通りに絞り込みを行いたいので、抽出条件をリストの上に設置します。

抽出した結果に対して、ガントチャートで見れると便利なので、ガントチャートへ変換ボタンをリストの右に用意します。新規にチケットを作成できないと付けないのでチケットの追加ボタンも画面右下に用意します。

結果、メニューが不要となり、画面は「チケットリスト」「チケット詳細」「チケット新規追加」「ガントチャート」の４つに減りました。

4. Domain-DrivenなUI設計

私はこのOOUXの考え方／手順を知った時、「DDDと親和性高い！」と直観的に感じました。

如何にOOPが現実世界のモデリングとして優れていて、かつモデリングが首尾よくできたとしても、洗練されたシステムができることは約束されません。なので、洗練された（≒複雑性を排除した）システムを設計するための手法としてDDDが生み出されたわけです。

同様に、ユーザジャーニーマップからオブジェクトの抽出が首尾よくできたとしても、いつでも洗練されたUIができるとは限りません。先程の例で、

この中ではチケットリストが一番需要が高いので、

と書きましたが、この優先度付けは曖昧であり根拠としては貧弱でした。

ここを補うピースとしてDDDの中のドメイン、境界づけられたコンテキストといった上位の概念がそのまま利用できると思ったのです。

また、ドメインモデリングは抽象度が高く、実践ドメイン駆動設計に書かれた内容すら実践的とは（私には）言えませんが、このドメインモデリングを助けてくれるのがUXであるとも思ったのです（詳細は割愛しますが上位下位関係分析で導ける本質的な欲求を「関心事」としてサブドメインを分ける方法が機能しそうです）。

私が考える、Domain-DrivenなUI設計手順を示します。

1. ユーザジャーニーマップを作成し、ユーザのアクションを明らかにする
2. ユーザジャーニーマップやアクションから、オブジェクトを抽出する
3. ドメインモデリングを行い、ドメインの関心事を解決するオブジェクトを選択する
4. 要件を満たす必要十分を目標に、UIデザインパターンから対象オブジェクトの表現として適切なものを選んで当てはめて調整する
5. 使っているところを検証して1〜4を繰り返す

具体例：チケット管理システムのUIを考える（DDUX）

Redmineなどのチケット管理システムは様々な関心事を持ちます。
トップレベルのアクションで挙げた使い方を例にドメインを考えると、ここでは

• 関心事として「既存チケットの対応漏れをなくすこと」を持つ 積み残し管理サブドメイン
• 関心事として「予実の乖離をなくすこと」を持つ 進捗管理サブドメイン

を定義しました。

これらのドメインで、チケット、プロジェクト、ユーザ、チケットリスト、ガントチャート というオブジェクトから利用するオブジェクトを選びます。

積み残し管理サブドメイン では、チケットを網羅的に見たり、多角的に見ることが求められます。それには様々な抽出条件で変化するリストが最適です。

進捗管理サブドメイン では、プロジェクトの正確なクリティカルパスを可視化することが求められます。それには時間軸、Exit Criteria、チケットの工数、依存関係が明確にすることが必要で、これらを表現できるものはガントチャート以外にありません。

この様に、ドメイン駆動設計のドメインモデリングから、メンタルモデルに近いUIを導き出すことができるのです。

最後に

いかがだったでしょうか。DDD本、IDDD本のドメインモデリングは抽象論過ぎてわけわからんと、アーキテクチャだけ取り入れて軽量DDDに甘んじていたそこの貴方！是非2019年はデザイナと二人三脚でドメインモデリングに勤しんでみては？？

1. ソシオメディア上野さんの記事は必読です。 ↩

2. というか アラン・ケイがその頃既に提唱していたとか。神すぎる。 ↩

3. 手法の歴史的な進化ではなく、UI設計者の進化なのは内緒。 ↩