layers-domain について
layers-domain は、製品が介在する前の現実世界にある概念、用語、プロセス、メンタルモデルを整理するデザインスキルです。コミュニティ間の違いを早計に解消せず記録し、概念モデルの材料を作ります。
主な機能
- 01ドメイン概念と関係のマッピング
- 02用語と意味の衝突の監査
- 03コミュニティ間の境界の特定
- 04名詞の収集と分類
- 05イベントとプロセスの時系列整理
- 06インタビューと資料分析の活用
活用シーン
- 01理解が不十分な領域の概念関係を明確化
- 02集団ごとに異なる用語の使い方を記録
- 03プロセス中心の領域でイベントを整理
- 04概念モデル作成に向けてドメインの知見をまとめる
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ jamiemill/ layers-skills --skill layers-domainインストール後、Claude Code で/layers-domainを入力して読み込まれたか確認します。
詳細
/layers-domain
/layers-intro が読み込まれていることを前提とします。このスキルは一連の手順ではなく、手法のライブラリです。詳しくは、そちらの「これらのスキルの使い方」をご覧ください。
ドメインレイヤーでは、特定のプロダクトとは無関係に現実世界に存在するもの、つまりユーザーが持ち込む概念、用語、プロセス、関係性、メンタルモデルをマッピングします。これは観察であり、設計ではありません。
このレイヤーで決めること
- このドメインの主要な概念と、それらの関係
- 人々が使う言葉と、その言葉が対立したり食い違ったりする箇所
- 自然な境界がある場所、つまり同じ言葉を異なる意味で使うコミュニティ
- このドメインの活動を時間の経過に沿って形作るイベントとプロセス
ドメインがすでによく理解され、異論もない場合、このレイヤーは不要かもしれません。概念モデルに直接進んでください。
分野 — ドメインの作業を誠実に保つために
- 矛盾を解消せず、記録します。 雑然として一貫性のないドメイン用語はデータです。コミュニティ間の隔たりや、後にプロダクトが選択を迫られる箇所を示しています。解消は概念モデルで行い、ここでは行いません。同義語(同じものを異なる名前で呼ぶ)と多義語(同じ名前が、文脈によって異なるものを指す)は、問題ではなく調査結果として記録してください。
- 現実世界に目を向けます。 回答がプロダクトやインターフェースの決定に逸れるたびに、軌道修正してください。問うべきなのは常に、プロダクトが登場する前にドメインがどのように成り立っているかです。
- 実体とインスタンス(名詞の洗い出しにおいて)。実体は、インスタンス化可能(複数存在し得る)、構造化されている(固有の属性を持つ)、かつ有用(人々がそれ自体に関心を持つ)ものです。インスタンスを実体と取り違えないようにしてください。「CAC」「ROAS」「LTV」は実体ではなく、Metric という1つの実体のインスタンスです。各名詞に実体/属性/インスタンスまたは値/不明のいずれかを付け、早まって絞り込まないでください。分類は概念モデルで行います。
- 信念と現実を区別します。 調査で確認した事実ではなく、チームが信じていることをマッピングする場合は、全体を通してその旨を明記してください。それはチームのモデルであり、ユーザーがドメインをどのように経験しているかを必ずしも示すものではありません。
手法
適したものを選んでください。通常は、概念マップと用語監査を中核にします。
| 手法 | 使用する場面 |
|---|---|
概念マップ/バブル図(graph TD/LR) | ドメインが複雑で、十分に理解されていない場合。形式ばらないノードと線で、早まって構造を決めずに概念間の関係を示します。 |
| 用語監査 | 概念ごとに、使われている名称、誰がいつどの名称を使うか、その食い違いが同義性によるものか多義性によるものかを記録します。どちらかを正解として選ばないでください。 |
| 境界づけられたコンテキストのマッピング | コミュニティ内では語彙が共通していても、グループ間で意味が異なる場合。それぞれの境界に名前を付けて説明します。モデルを定義する際に重要になります。 |
| 名詞の洗い出し | 明らかになった名詞をすべて集め、実体/属性/インスタンスまたは値/不明のいずれかを付けます。概念モデルの素材になります。 |
| ドメインイベントストーミング(Brandolini) | プロセスが中心となるドメインの場合。重要なイベントを過去形でタイムラインに並べ、トリガーと結果を記録します。イベントを伴うオブジェクトは、後で状態図が必要になる可能性があります。 |
| 専門家へのインタビュー | ドメインの知識が文書ではなく人に宿っている場合。暗黙知や、意見の分かれる用語を明らかにします。 |
| 文書・成果物の分析 | ドメインから契約書、書式、請求書などが生み出され、自然な構造や語彙が明らかになる場合。 |
| 競合分析 | 確立されたドメインに参入する場合。既存のプロダクトから、他者がどうモデル化しているか、またどこで意見が異なるかが分かります。 |
| シャドーイング | ワークフローを言葉で説明するのが難しい場合。観察によって、人々が実際に何をしているかが分かります。 |
デザイナーと協働する
製品が存在する前に、どのようなドメインをマッピングしているのか、誰がその領域で活動しているのか、そして何を達成しようとしているのかを尋ねるところから始めます。次に、概念を引き出します。名詞(候補となるオブジェクト)、動詞(プロセス)、そして自然な語彙に耳を傾け、特に人々が実際に物事をどう呼んでいるのかを確認します。
その場の問いに合った手法を提案します。関係が不明確ならコンセプトマップ、言葉の意味が争点なら用語監査、ドメインのプロセスが中心ならイベントストーミングです。すべてを行うのではなく、次に役立つことを行います。
記録するのは、残す価値があるものだけです。役に立つと判断したコンセプトマップ、文書化した用語の不一致と境界づけられたコンテキスト、重要なイベント、そして名詞の洗い出しです。これは生の素材であり、完成したドキュメントではありません。
ドメインをマッピングしたら、名詞の洗い出しを /layers-conceptual-model の出発点にします。