docs: モデルベースUIデザインのドキュメントを追加

UIの設計プロセスを体系化するため、モデルベースUIデザインの基本概念と
ユースケース定義に関するドキュメントを追加。
これにより、チーム内でのUI設計アプローチの共通理解を促進する。

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

Author: gn-t-k

docs/model-based-ui-design/README.md

@@ -0,0 +1,54 @@
+# モデルベースUIデザインの基本概念
+
+モデルベースUIデザインは、ロジカルに設計を積み重ねていくことで、矛盾のないUI構成を目指すデザインプロセスです。
+
+## モデルベースUIデザインの目的
+
+### 矛盾のないUI構造の構築
+
+「モデル」を活用して情報を整理しながらUIを設計することで、確実な構造設計を行い、矛盾のある構造をあらかじめ排除し、確実に成り立つ構造の上で適切なルック＆フィールの表現を探ることを目指します。
+
+### 高品質なUIの実現
+
+設計の基礎を盤石にすることで、最後のルック＆フィール（見た目や質感）の設計段階での迷いを減らし、魅力的な表現を検討するための余裕を生み出します。UIデザイン全体の作業において、ルック＆フィールは全体の約1割を占めるに過ぎませんが、ユーザーに注目されるのはこの部分であるため、その品質を高める基盤となる9割の設計を重要視します。
+
+### 効率的な設計プロセスの確立
+
+いきなり見た目や振る舞いの詳細から始めるのではなく、まず「どのようなユーザーに、どのような価値を訴求するのか」や「どのようなコンテンツを扱うのか」といった基本的な情報をモデルとして定義します。これにより、具体的な実寸大の構造物を作る前に、緻密な構造設計を効率的に行うことができます。
+
+### 変化に対応しやすいUI設計
+
+UIを単なる「絵」としてではなく、ソフトウェアの原理に基づいて構築されるものと捉え、UIを構成するさまざまな部品や振る舞い方、コンテンツ、概念を「モデル」として定義し、適切に組み合わせながら設計することを基本姿勢とします。これにより、変化しやすいソフトウェアの特性に対応し、堅牢な構造を築くことを目指します
+
+## モデルベースUIデザインのプロセス
+
+モデルベースUIデザインのプロセスは、一直線に進む線形的なものではなく、時には複数の設計を同時に進め、互いの成果を利用しながら次の工程に必要な成果物を作成していく進め方を取ります。
+
+このプロセスは大きく以下の3つの段階に分けられ、それぞれ異なる成果物の構築を行います。これらの各工程を通じて、**評価**と**プロトタイピング**が適宜実施され、設計の品質が段階的に高められていきます。
+
+### 序盤：環境調査と基本設計
+
+製品やユーザーを取り巻く環境を調査し、具体的な設計に必要な情報を整理することが目的です。
+
+主な活動は以下のとおりです。
+
+- ユーザーリサーチを実施し、ユーザーの行動シナリオやペルソナモデルを用いた**ユースケース定義**を行います。（詳細は@docs/model-based-ui-design/use-cases-definition/README.mdを参照）
+- ユーザーが達成したい「目的」やそのための「手段」を明確にする**タスク整理**を行います
+
+### 中盤：UIの構造設計
+
+情報設計のテクニックを駆使して、UIの基盤となるモデルを形作ることが目的です。
+
+主な活動は以下のとおりです。
+
+- UIのコンセプト定義を伴う**概念設計**を行い、設計の足場を固めます。
+- 具体的なUIを形作る前に、コンテンツに基づく構造がどのように成り立つのかに着目し、**ナビゲーション構造設計**を行います。いわゆる画面遷移ではなく、構造そのものに焦点を当てます。
+
+### 終盤：表現設計と大詰め
+
+これまでの工程で作成された成果物に基づき、プラットフォームの特性に適合する形を探り、UI全体の形を整えることが目的です。
+
+主な活動は以下のとおりです。
+
+- **プラットフォームへの適合**を検討し、UIのルック＆フィール（見た目や質感）やインタラクション（操作）のあり方を決定します。
+- UI全体の形を整えるとともに、構造設計とインタラクションの深化を図ります。

docs/model-based-ui-design/use-cases-definition/README.md

@@ -0,0 +1,85 @@
+# ユースケース定義
+
+## ユースケース定義の目的
+
+モデルベースUIデザインにおけるユースケース定義の主な目的は、ユーザーの状況を反映した設計を行いやすくすること、そしてムダのないUI構築を目指すことにあります。具体的な目的は以下の通りです。
+
+### 「機能」ではなく「ユースケース」で考える
+
+従来のシステム開発で用いられる「機能一覧」は、「機能」の認識に個人差が生じやすく、粒度が不明確になる問題があります。また、UIの具体的な振る舞いまでが「機能」の一部と認識され、ルック＆フィール（見た目や操作感）の評価が機能要件の文脈でなされ、ぎこちない成果物になりがちです。
+
+モデルベースUIデザインでは、この「機能一覧」の作成を推奨せず、代わりにユーザーの用途＝ユースケースを今後のあらゆる設計作業の根拠とすることを推奨しています。
+
+ユースケースは、ユーザーが製品に関わる際の「用途」や「システムの振る舞い方」を簡潔に説明するものであり、UIデザインの視点では**ユーザーの用途を定義すること**と理解されます
+
+### ユーザーの用途や需要を強く反映したUIの構築
+
+ユースケースを中心とした設計方針（ユースケース中心設計）により、ユーザーの用途や需要を強く反映し、**ムダのないUIの構築**を目指しやすくなります。
+
+基本的に、ユースケースに書かれていることのみを実装し、書かれていないことは実装しない姿勢をとることで、用途が不明瞭なままユーザー体験の考慮が希薄な**ムダなUIとなる可能性を低減**します。
+
+### UIデザイン視点の維持と評価の明確化
+
+ルック＆フィールに関わる問題も「ユースケースとして適切かどうか」という観点で評価できるようになり、**UIデザインの視点を保ちやすくなる**メリットがあります
+
+### 共通言語としての活用
+
+ユースケースという概念は元々システム開発の分野から取り入れられたものであり、**エンジニアリングとの共通言語にしやすい**メリットがあります。これにより、エンジニアとデザイナーが互いの考え方や論理を尊重しつつ、共通の概念や言葉を持つことが可能になります。
+
+### 設計作業の効率化とユーザーリサーチ成果の活用
+
+UIデザインの初期段階でユースケースを定義しておくことで、その後の設計や議論でユースケースを参照しやすくなり、常にユーザーの用途とユーザー体験を考慮できるようになります。
+
+ユーザーリサーチによって形作られたユーザー体験のコンセプトを、**形骸化させずに有意義にUIデザインに活用**できます。
+
+## ユースケース定義のプロセス
+
+モデルベースUIデザインにおけるユースケース定義の具体的なプロセスは以下の通りです。
+
+### 1. 設計材料の準備
+
+まず、ユーザーの**行動シナリオ**と、**ユーザー属性をまとめたペルソナモデル**を用意します。これらは主にユーザーリサーチ業務によって形作られます。
+
+ユーザーリサーチの結果をUIデザインに効果的に繋げるためには、これらのモデルをUI設計のための分析材料として活用する工夫が必要です。
+
+### 2. ユースケースの記述方法の採用
+
+システム開発分野で一般的なユースケース図ではなく、**〈誰〉が〈何〉を〈行動〉できる構文**を使用します。この構文は、行動主体、目的語、行動の3要素を穴埋めする形式で、素早く簡単にユースケースを定義できます。
+
+### 3. キーワードの抽出と定義
+
+「行動シナリオ」から、構文を構成する〈誰〉〈何〉〈行動〉の3要素を抽出します。
+
+「名詞」は、モノ、場所、結果、対象などを表し、「オブジェクト」または「概念オブジェクト」となり、「〈何〉」の候補になります。
+
+「動詞」は行動を表し、「タスク」となり、「〈行動〉」の候補になります。
+
+「〈誰〉」には、用意したペルソナモデルの具体的なペルソナ（例:「Aさん」）を当てはめます。ペルソナがない場合は「ユーザー」とすることも可能ですが、管理権限を持つユーザーと一般ユーザーのように区別が必要な場合は、「一般ユーザー」「管理権限持ちユーザー」などと具体的に区別します。
+
+ユーザー以外のパターンとして、**「システム」の振る舞い**も同じ構文で表すことができます（例:「〈システム〉が〈不正コメント〉を〈削除〉できる」）。
+
+ユースケースの表し方は、「動作主体が〜する」と断定するのではなく、**「〜できる」**と可能性を含ませる表現を用います。これは、UI設計が厳密になりすぎたり、ユーザーの思考や行動を制限する仕組みができやすくなったりするのを避けるためです。
+
+### 4. ユースケース名の付与
+
+ 定義したユースケースには、見分けがつきやすいように**簡潔なユースケース名**を付与します。
+
+ 「〈誰〉が〈何〉を〈行動〉できる」構文から想定できる名前を検討し、「〜できる」と表すことが推奨されます（例:「新規レシピを投稿できる」）。「〜する機能」という表現や「〜する」という断定的な表現は避けるべきです。
+
+### 5. ユースケースの分類
+
+似たようなシナリオを持つユースケースは、「レシピ」「コメント」のような**対象物**と「ユーザー」「システム」のような**動作主体**を軸にグループ分けすると整理しやすくなります。
+
+### 6. ユースケース番号の採番
+
+ユースケースには**固有の番号を採番する**ことを推奨します。
+
+採番ルールは、プロジェクトの規模や扱いやすさに合わせて複雑になりすぎない表記（例: 分類名+連続番号、特定の接頭辞、アンダースコア区切り）を検討します。数字の桁揃え（ゼロパディング）は、見栄え以外のメリットが少ないため、特別な理由がない限りは避けるべきです。
+
+### 7. タスク整理との連携と継続的な見直し
+
+ユースケース定義は、同時期に進められる**タスク整理**と密接に関連します。
+
+タスク整理の過程でCRUD（Create, Read, Update, Delete）を用いてタスクを分類する際にも、**ユースケースを対応させ、その妥当性や優先度を評価**します。 もし対応するユースケースが見つからなければ、そのユースケースを追加で定義すべきか検討します。逆に、ユースケースの追加が不要であれば、対応するタスクも不要と判断し、タスク定義から除外します。
+
+ユースケース一覧は、構造設計の過程で**いつでも修正・加筆**できます。