layers-conceptual-model

/layers-conceptual-model

/layers-intro が読み込まれていることを前提とします。このスキルは手順書ではなく、テクニック集です。詳しくは、そちらの「これらのスキルの使い方」を参照してください。

概念モデルは、最も見過ごされている、基盤を支えるレイヤーです。プロダクトが認識するオブジェクト、それらの関係、取り得る状態、そしてそれらを表す語彙を定義します。これは、インターフェースとは独立して、プロダクトがドメインをどのようにモデル化するかを意図的に決めるものです。

これは、ユーザーの雑然としたメンタルモデル（それはドメインレイヤーです）でも、データベーススキーマ、ワイヤーフレーム、フローでもありません。しかし、このモデルとエンジニアが構築するものとの隔たりは重要です。検討されていない大きな隔たりは、UX の負債（ユーザーがモデルと矛盾するプロダクトに直面すること）であると同時に、技術的負債（システムの進化が難しくなること）でもあります。

---

このレイヤーで決めること

• プロダクトが認識するオブジェクトと、それぞれの境界
• それらのオブジェクトの関係（多重度、および一つのオブジェクトが複数の役割を担う場合の役割名）
• ユーザーがそれぞれのオブジェクトに対して、またはそれを使ってできること
• オブジェクトが取り得る状態と、重要な状態遷移
• プロダクトの語彙（概念ごとに名前を一つ、名前ごとに概念を一つ）

これらのいずれも実際には未決でないなら、今はこのレイヤーが必要ないかもしれません。無理に取り組むのではなく、そのように伝えてください。

---

規律 — モデルの健全性を保つもの

どの順番でも、作成するものにこれらを適用してください。このレイヤーで特に価値が高い部分です。

• 実在するオブジェクトのみ。 真のオブジェクトは、インスタンス化できる（複数作成できる）、構造化されている（独自の属性を持つ）、そして有用である（ユーザーがそれ自体を重要視する）ものです。これにより、二つの誤りを見つけられます。一つは属性をオブジェクトに昇格させること、もう一つは、より頻繁に起こるインスタンスをオブジェクトと取り違えることです。「CAC」や「ROAS」はオブジェクトではなく、一つのオブジェクトであるMetricのインスタンスです。複数の名詞が同じ種類に属する場合は、その型をオブジェクトとしてモデル化し、個別の名前はインスタンスまたは値として扱ってください。
• 実際には関係である属性。 属性が単にモデル内の別のオブジェクトの名前や ID であるなら、それを重複させず、関係としてモデル化してください。
• 一つのオブジェクトが複数の役割を担う場合は、役割に名前を付ける。 「一人の User に（紹介者として）属する」であって、「一人の User に属する」ではありません。
• 推測による追加はしない。 すべてのオブジェクト、属性、アクション、関係は、明示されたユーザーニーズに結び付けられるべきです。ここでのスコープクリープは、上位のすべてのレイヤーに波及します。（戦略上の語彙に結び付いていても根拠にはなりません。戦略上の言葉は、まだオブジェクトではありません。）
• オブジェクトにできること ≠ 最初から独立したオブジェクトにすべきこと。 「実在するオブジェクトのみ」というテストで分かるのは、あるものをオブジェクトにできるということです。プロダクトがそれを、永続的で状態を持ち、後から参照される第一級のエンティティとして扱うべきかどうかではありません。そう昇格させるのはコストを伴う設計上の賭けです。具体的な用途で正当化してください。どのフローや業務によって、それを永続化し、状態を持たせ、再び参照する必要が生じるのでしょうか。 それが何もなければ、それは一時的なものか、時期尚早なものです。また、検証されていない戦略上の賭けによってのみ存在するオブジェクトには、暫定と印を付けてください。それを仮説としてモデル化し、「確定」させず、その賭けを検証するまでは上位のレイヤーをそれに基づいて構築しないでください。
• 動詞の精度。 汎用的な動詞（編集、削除、更新）が、現実の結果が異なる操作を覆い隠していませんか。「住所を編集する」は、入力ミスの修正（上書きで問題ない）と、引っ越しの記録（履歴を保持すべき）を混同します。汎用的な動詞が実質的に異なる意味を持ち得る場合は、操作を分けて名前を付けてください。「住所を修正する」と「住所変更を登録する」は、冗長なのではなく、正確なのです。
• 実装は設計ではない。 何かがどのように保存、生成、計算されるかという話に逸れたら、ユーザーが何をできるか、そしてそれを参照していたものに何が起きるかに話を戻してください。本当に絡み合った問題は、時期尚早に答えを押し付けず、エンジニアリングの相談事項として挙げてください。

---

手法

実際に判断が必要なものに合う手法を選んでください。すべてを実行する必要はありません。

手法	用途
名詞の掘り起こし＋OOUX（Sophia Prater）	調査やドメインのメモからオブジェクトを抽出します。自然な言葉から情報を掘り起こす場合のデフォルトです。上記の「実在するオブジェクトのみ」というテストを使い、名詞をオブジェクト／属性／インスタンスまたは値／除外項目（UI 要素、曖昧な抽象概念、名詞のように見せたアクション）に分類します。
オブジェクトの定義	1つのオブジェクトを明確にします。それが何か（ユーザーの視点からの一文）、その属性、関係性（多重度＋役割名）、アクションを定義します。
まずフローをスケッチする（前に進めてから、振り返る）	何かを永続的なオブジェクトとすべきかどうかが不明な場合に使います。永続化が必要なもの、状態を保持するもの、後で再び参照するものを確認するため、フローをブレッドボード化し（/layers-interaction-flow）、その後で必要なものだけを形式化します。実在するオブジェクトと一時的なものを見分けるのに、最も手早い方法であることもよくあります。
関係性オブジェクトマップ（erDiagram）	オブジェクトと関係性をまとめて確認し、欠落・逆転・不要なつながりを見つけます。||＝ちょうど1つ、o{＝0個以上、|{＝1つ以上です。多側にカラスの足を付け、ラベルは最初のエンティティから2つ目のエンティティへと読みます。
状態遷移図（stateDiagram-v2）	ステータスによってユーザーができることが変わるオブジェクトに使います。状態、遷移、各状態で禁止されることを明示します。
アクション（CTA）一覧	すべてのオブジェクトにまたがる、ユーザーが実行できるアクションを1か所に列挙します。これはプロダクトの行動喚起の語彙です。オブジェクトごとではなく、まとめて列挙することで、（1つの操作に対する「追加」「作成」「新規」のような）不整合や、（異なる操作を1つの動詞に隠すような）過度な単純化が明らかになります。
ユビキタス言語リスト	命名を整理します。意見が分かれる概念ごとに、選んだ用語、採用しなかった代替案、その理由を記録します。UI、ヘルプテキスト、API 名、社内での会話のすべてで、1つの概念につき名前は1つ、1つの名前につき概念は1つにします。
セマンティック IxD／アクション文法（Rosenberg）	多数のアクションやオブジェクトにわたって、動詞の一貫性と正確さを検証します。
イベントストーミング — コマンド／ポリシー（Brandolini）	プロセスの多いドメインで使います。起きることから始め、関係するオブジェクトをさかのぼって確認します。
カードソーティング	ユーザー間やチーム間で語彙が不明確、または意見が分かれている場合に使います。
既存プロダクトを実際に操作する	再設計の場合に使います。現在のUIから暗黙のモデルを読み取り、ユーザーの実際の考え方と比較します。

また、影響が及ぶオブジェクトについては、/layers-intro の時間に関する判断（中間的なアクション状態、読み取りモデルの遅延、関係性の時間的性質、削除の意味、履歴）も確認してください。

---

デザイナーとの進め方

上記の判断のうち、今まさに検討が必要なものを見極めます。状況に合う手法を提案してください。掘り起こせる素材があるなら名詞の掘り起こし、再設計ならプロダクトの実操作、オブジェクトが既知でその形だけが未確定なら、オブジェクトの定義から始めます。ツールキットをすべて使うのではなく、次に役立つことを行います。

記録するのは、決着したオブジェクトの定義（仮説検証やフローの確認待ちで暫定のものも含む）、実際の関係性やライフサイクルを表す図、用語の決定、未解決の質問（実体が曖昧だったオブジェクト、エンジニアリングに判断を委ねた事項）だけにします。デザイナーが読み返さないようなレポートは書きません。

ドメインの調査がまだなら、証拠が得られるまではこのモデルは仮説だとはっきり伝えます。

オブジェクトとアクションが安定したら、次はユーザーがそれらの間をどう移動するかを設計します — /layers-interaction-flow。