はじめに
NewsPicks のソフトウェアエンジニアの三浦です。NewsPicks アカデミア というプロダクトの開発チームリーダーをやっています。NewsPicks Advent Calendar 2018 の12日目を担当します。
今回は、ソフトウェアエンジニア視点でのプロダクトづくりについて、 UX デザイン(以下 UXD)とドメイン駆動設計（以下DDD）を中心に書いてみようと思います。
なぜ UXD と DDD を同時に論じようと思ったのか
結論から先に書くと UXD と DDD は親和性が高いのではないか？と考えたからです。
伝統的なソフトウェア開発のプロセスを挙げると、
- 要件定義
- 基本設計
- 詳細設計
- 実装
- テスト
- リリース
のような構成になると思います。
しかしこのプロセスで開発したソフトウェアはユーザにとって魅力的なものになるでしょうか？
昔よくあった、やたら入力項目が多かったり UI パーツの配置が直感に反していたり入力エラーで入力した内容が全部消えてしまったりなどなど罠だらけのアプリケーションはまさにこのプロセスにそって作られたものが多いと思いますが、なぜそのようなものがつくられてしまったのでしょうか？
その一因として、上記プロセスが目指しているものは発注者の要求を満たすソフトウェアをつくることであり、エンドユーザへの提供価値が第一となっていないからではないかと思います。
しかしソフトウェアはユーザがつかうものであり、発注者を向いたソフトウェア開発は構造としてズレているように感じます（発注者がエンドユーザに向き合い、それをしっかり要件に落とすことができればもちろん話は別です）。ユーザへの提供価値最大化は昨今のソフトウェア開発において必須です（あたりまえっちゃーあたりまえな話ですが）。そう考えると、ソフトウェア開発プロセスにユーザの体験価値を設計する UXD のプロセスを組み込むとよさそうです。
UXD によって体験価値が設計されると、プロダクトやサービスの領域、そこで使われる名詞、価値を構成する要素などなどが自ずと定まってくるはずです。例えば商品販売で考えると、
- 領域 = 「EC」など
- 名詞 = 「商品」「注文」「決済」などの単語
- 要素 = 「EC サイト」「受注管理サブシステム」「顧客管理サブシステム」など
となるかもしれません。これらは DDD でいうところのドメイン（領域）、ユビキタス言語（名詞）、境界づけられたコンテキスト（要素）と対応付けられそうです。
以上を踏まえ、UXD によって設計された価値を前提に DDD でソフトウェアの設計をすることによる両者の親和性は高そうだと考え、このようなテーマで記事を書くに至りました。
UXD
UX とは
Wikipedia によると、
ユーザーエクスペリエンス（英: user experience）とは、人工物（製品、システム、サービスなど）の利用を通じてユーザーが得る経験である。
とあります。
有形無形問わず、人がつくったプロダクトやサービスを通してユーザが得る体験のことを指します。
いわゆる UX というと UI とセットで論じられることが多いと思いますが、UI がない UX もあります（例えば宅配など）。
UX の種類
UX について学ぶ過程で前述のとおり UI のない UX もあることに気づき、UI/UX という表現に違和感を持つようになりました。一方でいい UX を実現するための要素としていい UI が大きな貢献をしうることもわかります。そうすると UX にもいくつか種類がありそうなことに気づきます。例えば、
- スマホアプリやウェブサービスの特定の画面や機能を触って生まれるプロダクトの局所的な UX （これがいわゆる UI/UX と表現される所以）
- プロダクトを一通り使って（複数の画面や機能を触って）生まれるプロダクト全体の UX
- プロダクトを触る前の広告やカスタマーサポート等のサービスなど、プロダクト以外で生まれる UX
などです。それぞれローカル UX、プロダクト UX、サービス UX みたいに呼ぶのがいいでしょうか。
上記のような UX の分類は僕が勝手につくったものですが、他にも分類の観点はあり、例えば期間で分類するものもあります（利用前の「予期的 UX」、利用中の「瞬間的 UX」、利用後の「エピソード的 UX」、利用時間全体の「累積的 UX」）。
UXD とは
UXD は「ユーザが嬉しいと感じる体験を実現する製品やサービスのデザイン」と定義できると思います。ポイントは「嬉しい」で、価値を担保するには「嬉しい」体験である必要があると言えます。
デザインというとグラフィックデザインのようなビジュアル的なデザインを想起しますが、UXD はどちらかというと「設計」に近いと思います。design の日本語訳の一つは「設計」で、例えばシステムデザイン＝システム設計となります。UXD において UI デザインやグラフィックデザイン、インタラクションデザイン、モーションデザインなどはその一部となります。
そして UXD とそれによって生み出される UX は異なることに注意する必要があります。UXD をクラスに例えると、UX はインスタンスです。UXD は多くのユーザへ向けたものであり、UX はユーザ個別で主観的なものであるということです。すなわち自分の経験だけに基づいた主観的な UXD というものは成立しないということになります。
また、UXD によって生まれる UX がどんなものかはしっかり定義しておく必要があります。これは前述した UX の種類という観点も有用だと思っていて、例えば局所的な UX ばかりに目がいった設計にならないように注意することも大事だと思います（そんなもの現実的にはないと思いますが、例えば局所的な UX だけ優秀なアプリは極端な話さわっていて気持ちいい以外の価値がないアプリだということになります）。
プロセスとそれによって得られるもの
おおまかに主要プロセスを挙げると次のようになると思います。
- 調査・分析（ユーザリサーチ）
- コンセプトデザイン
- プロトタイピング
- 評価
- 制作・運用指針作成
上記プロセスを通して
- ユーザモデリング（ペルソナ、ジャーニーマップなど）
- 体験価値モデリング（KA法、上位下位分析、UXD コンセプトシート、ストーリーボードなど）
などの成果物を得ることにより、DDD の前提知識とすることができそうです。例えばここで定義したユーザモデルはアクターやビジネスルールとして利用できますし、体験価値モデルからユースケースや概念モデルなどをつくれそうです。
DDD
DDD とは
DDD の定義は書籍でも明確に謳われていないせいか、明確な定義がないように思えます。そんな状況下でこちらの記事はよくまとまっていて、
ドメイン駆動とは？
- ドメイン(＊1)の中核となる複雑さと機会に焦点を当てる
- ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する
- 明示的にそれらのモデルを表現するソフトウェアを書く
- 境界付けられたコンテキスト(＊2)の中のユビキタス言語(＊3)で話す
(＊1)domain
知識、影響力、または活動の領域。
ユーザーがプログラムを適用する対象エリアは、ソフトウェアのドメインである。つまり業務アプリケーションに限って言うなれば、「アプリケーションの対象となる業務領域」とでも言うとわかりやすいでしょうか。
(＊2)bounded context
特定のモデルが定義され適用される境界（通常、サブシステム、または特定のチームの作業）の説明。
(＊3)ubiquitous language
ドメインモデルを中心に構造化された言語。
チームのすべてのアクティビティをソフトウェアと結びつけるために、境界付けられたコンテキスト内のすべてのチームメンバーが使用する。
まずは「チームで使う共通言語」ぐらいの和訳でとらえておくのがわかりやすいと思っています。
としています。
誤解を恐れず一言で言えば、技術的な要素なしで非エンジニア含めたチーム全体での共通の知識のみを用いてシステム設計する、と表現できるかもしれません。
DDD の成果物は大小様々だと思いますが、最低でも概念モデルとユースケース、コンテキストマップくらいはつくることになると思います。
そして実際の実装となるとヘキサゴナルアーキテクチャ、クリーンアーキテクチャなどに基づいて進めていくことになります。
これらのアーキテクチャは DDD の特徴である関心の分離を実現するもので、それによって UXD で定義した体験価値と技術的要素をうまく分離できます。
最後に
ここまでざっくりと UXD と DDD がどんなものか、UXD の出力が DDD の入力となりうるかを書いてきました。
UXD で定義した体験価値を DDD によっていかに実装へ落とし込むか、この課題設定は個人的になかなか興味深いなーと感じています。
今回はかなりざっくりとした内容となりましたが、いつかより詳細なプロセスに踏み込んだ上で UXD と DDD について書いてみようと思います。
明日は @kohei1218 による2018年これだけは知っておきたいiOSライブラリ31選です。ぜひご覧ください！