Chatwork 株式会社　プロダクト本部 エンジニア採用広報　高瀬 和之 (@Guvalif)　 "情報設計" と "体験設計" の 観点から捉える UI 構築の考え方 

自己紹介 - 高瀬 和之 (たかせ かずゆき) 2019 年に Chatwork 株式会社へ フロントエンド・エンジニア としてジョインし、 リリース基盤やビデオ通話アプリケーションの開発に従事 2020 年から エンジニア採用広報に転身 し、技術イベント運営や エンジニア採用を主業務とする。パラレルワークで講師業 も営む 　：@Guvalif YouTube にて アーカイブ配信中！ 2 

※※※ 登壇を見るにあたって ※※※ 本資料は抽象度の高いトピックが含まれます 一度に理解しきるのでは無く、脳内インデックスを作るイメージで ご視聴いただければ幸いです (適宜チャットからも質問まで 💬) 

速習 Domain Driven Design UI の構造化戦略 "情報設計" を汎用サブドメインに対応づける "体験設計" を支援サブドメインに対応づける 1 2 3 AGENDA アジェンダ 4 

1 速習 Domain Driven Design 

そもそも DDD とは何か？ 6 Minimal Imple- mentable Modula- rized Iterative 1. 対象領域における 必要最小限かつ実装にも反映可能な "モデル" に焦点を当てて ... 2. 概念 (およびその集合) に応じて モジュール化 して ... 3. 反復的 に設計すること cf. 『エリック・エヴァンスのドメイン駆動設計』 ド メ イ ン 

DDD のよくある誤解 7 󰢃 誤解 󰢏 正しい解釈 DDD を実践するには、 現実を写実的にモデリングする 必要がある 実装にも反映可能なモデル にこそ価値があり、 モデルを深堀りする中で、写実的な側面からは 見いだせない構造が見つかることにも価値がある DDD を実践するには、 クラス機構を用いる 必要がある 概念に対して凝集度を高く保つ ことができるなら そもそもオブジェクト指向ですらなくてもよい DDD を実践するには、 レイヤー化アーキテクチャを用いる 必要がある レイヤー化はモジュール分割の一手段 で しかなく、モデリングの一環ではない DDD を実践するには、 スクラム開発を用いる 必要がある モデルが 恒常的にリファクタリングされる ことは 前提だが、アウトカムが定期的にある必要はない 

問題空間 A 問題空間 C 問題空間 D 問題空間 E 問題空間 B キーワード：問題空間 (サブドメイン) と解決空間 8 問題空間 (サブドメイン) 解決空間 対象領域 (ドメイン) をそのまま扱うと 広大かつ難解な場合において、 対象領域を分割した際の一単位 単一もしくは複数の問題空間に対して、 どのように概念をモデル化して 実装しているか (≒ How) の影響範囲 cf. 『実践ドメイン駆動設計』 対象領域 (ドメイン) 解決空間 - - - - 

キーワード：問題空間 (サブドメイン) の種類 - コアドメイン - 事業戦略やプロダクト戦略の観点から、もっとも取り組む価値のある問題 - 支援サブドメイン - コアドメインと一蓮托生ではあるが、コアドメインから分離可能な問題 - 汎用サブドメイン - コアドメインには関わらないが、対象領域全体としては考える必要のある問題 cf. 『実践ドメイン駆動設計』 9 

2 UI の構造化戦略 

アプリケーション設計は "メンタルモデル" が大事 特定の状況で、ものがどのように振る舞うかを経験的に記憶し、 必要に応じて取り出せるまでに形成された心理的なモデル。 同じような状況下での物事の判断や理解に利用することができる。 例えば見たことのない道具を使う場合、人はその形状などから内部機構を 瞬時に想像して (メンタルモデルを得て) 使い方を推測する。 逆に実際の機構とかけ離れたメンタルモデルを持たせるデザインは、 ユーザーにとって利用しにくくなる恐れが強い。 11 cf. メンタルモデル (sociomedia.co.jp) IMPORTANT 

情報設計 の実装 体験設計 の実装 メンタルモデル の実装 コンテキストマップ 12 対象領域の 部分 領域 (UI の関心ごとにフォーカス) 汎用サブドメイン 支援サブドメイン コアドメイン 依存 依存 or Interface を通じた間接依存 対応 対応 部分対応 UI の関心ごとに応じて 解決空間 を分割し、対応する 問題空間 を図示したもの → 主張：このような構造を意識することで、UI の保守性を高めることができる IMPORTANT 

コラム：クリーンアーキテクチャに関する誤謬 レイヤー化アーキテクチャの Typical な例ではあるが、誤解を恐れず言えば、 最外殻以外にも UI の関心ごとは存在する ことに注意！ 13 cf. The Clean Architecture (blog.cleancoder.com) 

メンタルモデルの置き場所に正解は無く、必ずしもサーバーサイドである必要も無い コラム：メンタルモデルの置き場所に関する誤謬 14 解決空間 (クライアント) 解決空間 (サーバー) 例) Notion や Figma など、 メンタルモデルが クライアント優位な場合 解決空間 (サーバー) 解決空間 (クライアント) 認証 / 永続責務などを BaaS 的に薄く構成 デザイン / ユースケース※ / モデル などが 一様に存在し、設計戦術が高い効果を持つ デザインなどを 薄く構成 API / ユースケース※ / モデル などが 一様に存在し、設計戦術が高い効果を持つ 例) Stripe や Auth0 など、 メンタルモデルが サーバー優位な場合 ※ ユーザーストーリーに対応づく、モデルの進行役を担うモジュールのこと 

3 "情報設計" を 汎用 サブドメインに対応づける 

"情報設計" ::= 意味と表示に関する規格整理 とここでは定義 16 cf. アプリケーションとウェブサイト、UI デザインにおける情報設計の違いとは？(fixel.co.jp) 意味 表示 _コンテンツ_ _概念操作_ 導線設計 デザイン パターン 検索 分類 デザイン原則 モデリング 

なぜ "情報設計" を汎用サブドメインに対応づけたいか？ 特に、アプリケーション設計 (≠ コンテンツ設計) の場合だと： - 概念操作 × 意味 - 概念操作 × 表示 それぞれに関わる規格整理が必要。なおかつ： - 分類 - デザイン原則 - デザインパターン といった項目は、(固有の) メンタルモデルに依存しない普遍的な法則 が適用可能 17 

デザインシステム "デザインシステム" の役割は、情報設計を体系化し、チームの共有知とすること 󰢃 React などによる、ただの Component 集として用いる 󰢏 情報設計の各項目を、互いの関連性を伴って体系化する Component 集として用いる場合であっても、 Props などからメンタルモデルへの依存を調べ、体系に組み込むべきかを判断できる 18 interface Props { message: Message; } interface Props { type: 'plain' | 'secret'; line: 'single' | 'multi'; } 固有型が現れるなら、メンタルモデルへの依存を持つ可能性が高い 固有型が現れず、デザインパターンのみを想起させる 

デザインシステムの参考例 - デザイン原則 - デザインパターン - デザイン基盤 上記のみを、簡潔に体系化してみた例 (学生向けインターンシップで活用) 19 cf. Palupunte Design System (勉強会時のみ共有) 

標準化仕様 情報設計を汎用サブドメインに対応づけた方が良いもう一つの理由として、 さまざまな標準化団体 (および発行される仕様) の存在が挙げられる： - IETF (ietf.org) - W3C (w3.org) - WHATWG (whatwg.org) - etc … つまり、情報設計が (固有の) メンタルモデルに依存する ことは、 標準化仕様を逸脱し、開発者やユーザーへ混乱を招く 可能性が高い 20 

ケーススタディ：Tailwind CSS (Utility CSS) の取り扱い 　Rapidly build modern websites without ever leaving your HTML. 誤解を恐れず言えば、上記のキャッチコピーは設計思想を十分に説明していない - 十分に意味づけされた CSS は、メンタルモデルに依存する可能性が高い - それゆえに、単一責任の原則 から、再利用性が担保されづらい - 似ている CSS ≠ 同じ CSS，ということ - 情報設計のみを Utility として分離 して、再利用性を担保する … といったところに本質がある (Tailwind CLI はそのためのツールセットでもある) 21 cf. CSS Utility Classes and "Separation of Concerns" (adamwathan.me) 

4 "体験設計" を 支援 サブドメインに対応づける 

"体験設計" ::= 要求に関するインタラクション整理 とここでは定義 インタラクションとは、ユーザーとの相互作用のこと： - 要求を満たすルック & フィールの定義 ≒ 機能の実現 - ユーザーの 行動を適切にナビゲートする 状態管理の定義 - ポジティブ感情を誘起する 仕掛けの定義 - etc… これらを整理するのが体験設計の役割 (※ 厳密には、プロダクトの外部環境も体験設計の考慮範囲です) 23 

なぜ "体験設計" を支援サブドメインに対応づけたいか？ 端的に言えば、体験設計に際して "メンタルモデル" を考慮したい場合が多いから - メンタルモデルに 直接依存 する場合 - メンタルモデルに Interface を通じて間接依存 する場合 (API 連携も含む) どちらであっても、支援サブドメインとして対応づく 24 メンタルモデル (解決空間) 体験設計 (解決空間) 名前を入力してください ユーザー名モデル 表明 1：アルファベットのみか？ 表明 2：文字数が 1 〜 30 文字か？ ︙ 利用 表明違反の 通知 Error: 文字数が不足しています！ 

Ubiquitous UI メンタルモデルに依存する Component を、 情報設計におけるデザインパターンと区別する意味で、Ubiquitous UI と呼称してみる 25 IMPORTANT export function Message({ message }: Props): ReactElement { const [date, dateTime] = useMemo(() => TimeSecond.toDateStrings(message.postedAt), []); const name = useUserAccountNameQuery(message.postedUserId); return ( ); } メンタルモデルへの依存の例 

体験設計に際して、メンタルモデルの別解釈が表出しうる 例えば、オークションアプリにおける "残り時間モデル" の取り扱いはその際たる例： - メンタルモデル → ある 特定の時刻 を表現したい - 体験設計 → 非同期的なカウントダウン を表現したい 26 ○○ モデル (別解釈) AAA BBB CCC ○○ モデル XXX YYY 体験設計者 視点 ○○ 視点 体験設計 (解決空間) メンタルモデル (解決空間) 

ケーススタディ：コマンドとクエリの分離 メンタルモデルを 操作する箇所 と、結果を受け取る箇所 は、異なる可能性がある (特に、Component が非正規形データを必要とする場合に顕著) → これらを分離する ことで、メンタルモデルを扱いやすくかつコンパクトに保つ 27 コ マ ン ド ク エ リ ○○ モデル XXX YYY 操作責務 Command Query 結果集計責務 (※ 必要に応じて用意) 

ケーススタディ：Redux の取り扱い 28 model ia-domain ux-domain use-case repository api- service Action Selector Middleware Store Container 他 Chatwork における Redux を用いた現行アーキテクチャ例 UI において、メンタルモデル (の振る舞い) を考慮する必要が多い場合に、 Redux のような状態管理システムを導入する価値が高くなる 体験設計の実装 情報設計の実装 メンタルモデル 

ケーススタディ：GraphQL の取り扱い 29 model- type ia-domain ux-domain use-case repository model Mutation Query GraphQL Resolver Container 他 GraphQL へのアーキテクチャ移行例 UI において、メンタルモデル (の振る舞い) を考慮する必要が少ない場合に、 GraphQL はもっとも真価を発揮する 体験設計の実装 情報設計の実装 メンタルモデルの型 

ケーススタディ：SSR 系フレームワークの取り扱い 30 model ia-domain ux-domain use-case repository Command Query SSR 系フレームワークへのアーキテクチャ移行例 そもそも解決空間がクライアントとサーバーに分離しないため、 メンタルモデル (別解釈含む) とのインピーダンス・ミスマッチを防ぎやすい 体験設計の実装 情報設計の実装 メンタルモデル Container 他 

まとめ 01 UI の構造化は、"情報設計" / "体験設計" / "メンタルモデル" を それぞれ意識すると良い 02 簡単なところから試すのであれば、メンタルモデルの型を手がかりに、 Component を区分けしフォルダ分けするだけでも良い 

働くをもっと楽しく、創造的に