product-design

プロダクトデザイン

余白の議論をする前に、何を、なぜ作るのかを決めます。

次の2つのルールは、必ず守ってください。

表層からデザインを始めてはいけません。まず、ビジネスが実際にモデル化しているものを明らかにします。

ビジネスモデルを情報アーキテクチャに置き換えてはいけません。ドメインは表層が何を主張できるかを制約します。一方、表層の構成は、ユーザーの検索・取得タスクと意思決定タスクによって決まります。（P-14）

このスキルでは、まずプロダクトの意味を扱います。根拠に基づいた枠組みを ux または design-prototype に引き継ぐこともできますが、発見に実装やプロトタイプは必要ありません。フレームワーク、テーブル、コンポーネントの名前をすべて取り除いてみてください。プロダクトに関する洞察が残らなければ、その調査結果はエンジニアリングスキルに属します。

他のスキルとの関係

スキル	問い	タイミング
product-design	この表層はどうあるべきで、その理由は何ですか？	枠組みを定める前または最中
ux	インタラクションはどのように動作し、どんな感触であるべきですか？	デザインまたは構築中
ux-audit	構築された表層は、そのルールに従っていますか？	表層が完成した後
design-prototype	具体化したインタラクションをどのようにテストできますか？	プロトタイプが役立つ場合

最小限の実行モードを選ぶ

モード	完了の基準
Discover	エビデンスマップ、ビジネスモデル、ユーザーモデルの仮説、構造上の診断
Frame	Discover ＋ビューモデル、情報アーキテクチャ、スコープ、未決事項
Materialize	Frame ＋依頼された仕様書やプロトタイプ

ユーザーからデザイン成果物、プロトタイプ、またはリポジトリの変更を依頼されていない限り、成果物を作成・変更しないでください。

大規模な作業では、references/pattern-base.md と references/layer-model.md を全文読んでください。範囲の狭い質問では、関連するパターンだけを確認し、どの範囲を調べたかを明記してください。

ステップ1 — ビジネスモデルの根拠を固める

表層を診断する前に、何が事実なのかを明らかにします。広範なリポジトリを調べる場合は、委任が可能で有用であれば、互いに独立したエビデンス領域を並行して調査します。主担当エージェントは、矛盾の整理に引き続き責任を持ちます。

次の内容をまとめます。

• 概念、役割、状態。現在の表層では隠されているバリエーションも含めます（P-04）。
• 最終的なビジネス上の事実を生み出すのは誰か、何がライフサイクルを完了させるのか（P-12）。
• 各状態によって、誰に何をする義務が生じるか（P-01）。
• 各アクションによって、どのビジネスイベントが発生するか（P-02）。
• ビジネスに存在しない概念（P-06）。
• エビデンスの出所、矛盾、確信度。

ドメイン型やステートマシンは強力なエビデンスとして扱いますが、唯一の真実としては扱いません。関連するサービスの動作、権限、ポリシー、本番環境の事実、利用可能であればユーザーからのエビデンスも確認します。コードは古くなっていたり、偶発的に生じたものだったり、不完全だったりする可能性があります。

チームが想定するプロダクトモデルを、そのまま前提にしてはいけません。ドメインとユーザーのエビデンスに照らして確認するまでは、仮説として扱ってください。

Step 2 — ユーザーのビューモデルを構成する

グラウンディングによって、製品が何を主張できるかは制約されますが、ユーザーがどのように見るべきかは決まりません。観察されたユーザーのエビデンスと、デザイン上の仮説を分けてください。

• 状況と目的 — 「これを開いたとき、私は……する必要があります」。
• 検索対象 — ユーザーがスキャン、比較、確認する、安定した対象。
• 紐づく証拠 — 結合を再構築せずに各対象を検証できるもの。
• 最初のスキャン — クリックせずに答えられる2〜4個の質問。
• 二次的な軸 — 時系列、来歴、実行、内部状態。目的が実行監査でない限り、フィルターまたはドリルダウンとして扱ってください。
• エビデンスと確信度 — 主張を観察済み、報告済み、推測済みとして示し、重要な前提をどう検証できるかを明記してください。

モデル	デザインにおける役割
ビジネス／ドメインモデル	真実、有効性、完全性、越えてはならない境界を定義します
ユーザービューモデル	グループ化、順序、ラベル、デフォルトの展開状態を定義します
実行モデル	来歴と監査の詳細を提供します。ページを無条件に与えることはありません

最上位セクションの案が、runs、reports、エビデンスのバージョン、テーブル名など、単なるドメインまたは実行に関する名詞である限り、先に進まないでください。ユーザーが探している対象（P-14）を使って書き直してください。

Step 3 — 構造上の誤りを診断する

好みに関係なく問題となる点を挙げてください。たとえば、次のようなものです。

• 判断のための受信トレイにエラーしか表示されず、エラーログのように見える（P-04）。
• ボタンが、実際には存在しないビジネスイベントを約束している（P-05）。
• 1つのページがトリアージデスクと閲覧スペースを兼ねており、どちらの役割も果たせていない（P-07）。

エビデンスによって裏付けられる構造上の誤りがない場合は、診断を捏造せず、その旨を報告してください。

Step 4 — 依存関係に沿って判断を整理する

回答の形を変える判断だけを表に出してください。それぞれについて、推奨案、エビデンス、影響を示してください。制約を与える下流の判断より先に、上流の判断を解決してください。

回答によって作業が大きく変わる場合は、作業を妨げる質問として個別に尋ねてください。互いに独立した判断は、1つのメモにまとめてください。ユーザーが自律的な進行を許可した場合は、推奨されるデフォルトに沿って進め、前提を明示してください。グラウンディングを通じて入手できる情報をユーザーに尋ねないでください。

レビュー、承認、受け入れのための画面では、まずライフサイクルを完了するのがシステムなのか、人間の判断なのかを明確にしてください（P-12）。

Step 5 — 不確実性の解消に役立つ場合はプロトタイプを作成する

ユーザーがプロトタイプを依頼した場合、または文章によるフレームだけでは操作性、情報密度、階層構造を誠実に決められない場合に限り、design-prototypeを使用してください。これはMaterializeモードに該当します。

• もっともらしいデータを使い、空の状態、ブロックされた状態、大規模な状態を含めてください。
• ビジネス上の裏付けがないものは、モック上でNEWと表示してください。
• 修正をエビデンスとして扱ってください。現在の画面を超えて一般化できる場合に限り、Pattern Baseの候補とします。

ステップ 6 — スコープを誠実に定める

区分	意味
✅ すでにモデル化され公開済み	既存の機能を再構成する
⚠️ モデル化済み、未公開	ドメイン上のリスクは低めですが、エンジニアリングコストの検証は必要です
❌ 未モデル化	ドメインの拡張と、明示的なコスト／リスク評価が必要です

ユーザーの一連の作業を完了できる場合は、一貫性のある ✅ + ⚠️ の範囲を優先してください。概念がすでに存在するという理由だけで、不完全または誤解を招く範囲をリリースしないでください。価値、安全性、または意味上の完全性を実現するために必要であれば、❌ の機能が最初に投資すべき対象になることもあります（P-10）。

❌ の項目と、想定されるコスト要因をすべて仕様書に記載してください（P-11）。黙って除外してはいけませんが、ドメインモデルだけからコストを推測できるかのように装ってもいけません。

締めくくり — カバレッジを記録し、学びを提案する

ユーザーが許可した範囲で締めくくります。

1. 仕様書を作成する場合は、references/trace-schema.md にあるリアリティチェックログを含めます。読み取り専用の作業では、書き込む代わりに、重要な前提と根拠を回答内で報告します。
2. 想定外の発見を references/canon.md と照合し、その教訓が一般化できる場合に限り、Pattern Base の候補を提案します。
3. リポジトリの編集が許可されており、候補の重複がなくレビュー可能な場合に限り、references/pattern-base.md に追記します。
4. カバレッジの状況を記録します。確認したソースとライフサイクル領域、入手できなかった根拠、信頼度が低いままの主張、新たなギャップが見つかったかどうかを記載します。

新たなギャップがゼロというのは、調査した範囲内で見つからなかったということにすぎません。実装やメンタルモデルに未確認の部分がないことを証明するものではありません。

成果物

成果物	作成するタイミング	テンプレート／場所
設計仕様書	Materialize モードで依頼された場合	templates/design-spec.md。ユーザー指定のパスを使うか、確認します
インタラクティブプロトタイプ	依頼された場合、または不確実性の解消に必要な場合	仕様書の隣に design-prototype を使って作成します
リアリティチェックログ	作成する仕様書の中	references/trace-schema.md
パターン候補	一般化可能な、想定外の教訓が得られた場合	仕様書／回答内。レビューと許可の後に限り追記します

アンチパターン

• スクリーンショットをもとに設計する、またはドメインモデルをサイトマップとして扱う。
• 状態やアクションを、そのラベルではなく、果たすべき責務やイベントで読み取る。
• コードからユーザーモデルを推測し、それを観察済みの事実として提示する。
• 概念が欠けている問題をレイアウトの問題として扱う。
• 入手可能な根拠からすでに答えが得られる質問をする。
• 概念が存在することを、エンジニアリングコストの見積もりとして扱う。
• プロトタイプの作成、仕様書の作成、Pattern Base の変更を自動で行う。
• ローカルな修正やエンジニアリング上の発見を、共有のプロダクトガイダンスに追加する。

完全な例については、 references/worked-example.md を参照してください。