|
| 1 | +# ユースケース定義ユースケース定義 |
| 2 | + |
| 3 | +ユースケース定義は、モデルベースUIデザインの「序盤」に位置づけられる重要な工程です。このプロセスは、UIの構造設計の基礎を固め、ユーザーにとって魅力的で堅牢なインターフェイスを実現するために不可欠な要素となります。 |
| 4 | + |
| 5 | +## ユースケースとは何か |
| 6 | + |
| 7 | +ユースケースとは、ユーザーが製品と関わる際の「用途」や「システムの振る舞い方」を簡潔に説明するためのものです。UIデザインの観点からは、「ユーザーの用途を定義すること」と理解すれば十分です。これは、システム開発の分野で要件定義や仕様定義の過程で用いられる、ユーザーとシステムの対話方法と条件をモデル化する考え方をUIデザインに応用したものです。 |
| 8 | + |
| 9 | +## ユースケース中心設計の意義 |
| 10 | + |
| 11 | +モデルベースUIデザインでは、従来の「機能一覧」を作成するのではなく、「ユースケース中心設計」を推奨しています。機能一覧には以下の問題点があると指摘されています。 |
| 12 | + |
| 13 | +- **認識の個人差と粒度の曖昧さ**：日本語の「機能」という言葉は、その認識に個人差が生じやすく、機能の粒度が不明瞭になりがちです。マイクロインタラクションレベルから「検索機能」のような大きな括りまで、定義の単位を揃えるのが困難です。 |
| 14 | +- **UIデザインへの制約**：UIの具体的な振る舞い、とくにルック＆フィール（見た目や質感、心地よいアニメーションなど）が「機能」の一部として認識されると、UIデザインの進め方に大きな制約が生じます。ルック＆フィールは、機能要件として適切かどうかの評価にとどまらず、「ユースケースとして適切かどうか」という観点で評価されるべきであり、機能の文脈から切り離して考える必要があります。 |
| 15 | + |
| 16 | +これに対し、ユースケース中心設計は以下の利点をもたらします。 |
| 17 | + |
| 18 | +- **ユーザー用途の反映**：ユーザーの用途や需要を強く反映した、ムダのないUI構築を目指しやすくなります。 |
| 19 | +- **共通言語の確立**：ユースケースはもともとシステム開発の分野から取り入れられた概念であるため、エンジニアリングとの共通言語として機能し、デザイナーとエンジニアが互いの考え方や論理を尊重しつつ、同じ発想や言葉を共有しやすくなります。 |
| 20 | +- **設計の根拠**：今後のあらゆる設計作業の根拠をユースケースに紐づけることで、ユーザーの事情を反映した設計が行いやすくなります。ユースケースに記載されたシナリオや用途のみを実装する姿勢は、ユーザー体験を深く考慮したムダのないシステム構築につながります。 |
| 21 | +- **ユーザーリサーチ成果の活用**：ユーザーリサーチによって形作られたユーザー体験のコンセプトを、形骸化させずに有意義にUIデザインに活用できます。 |
| 22 | + |
| 23 | +## ユースケースの表現方法 |
| 24 | + |
| 25 | +モデルベースUIデザインでは、システム開発で一般的なUMLのユースケース図や詳細な表ではなく、デザイナーにより扱いやすい簡易的な記述方法を採用しています。 |
| 26 | +具体的には、筆者が採用している「**〈誰〉が〈何〉を〈行動〉できる**」という構文を用います。この構文は、「動作主体」「対象物（目的語）」「行動」の3要素を穴埋めすることで、素早く簡単にユースケースを定義できます。 |
| 27 | + |
| 28 | +- **動作主体（誰）**：主に「ユーザー」を指しますが、ペルソナモデルを用意している場合は具体的なペルソナ名（例：Aさん）を用いることで、ユーザー属性に合わせたユースケースを定義できます。また、システムを主語にした行動（例：「システム」が「不正コメント」を「削除」できる）も同様に記述することで、ユーザーのタスクとシステムのタスクを関連付けることができます。 |
| 29 | +- **対象物（何）**：これは「概念オブジェクト」に相当します。ユーザーが関心を持つ「もの」や操作の対象となるものです。行動シナリオやタスク一覧から名詞や目的語に着目して抽出できます。 |
| 30 | +- **行動（できる）**：これは「タスク」に相当します。ユーザーが行う具体的な仕事やシステムの振る舞いを指します。 |
| 31 | + |
| 32 | +## 「〜する」ではなく「〜できる」と表す理由 |
| 33 | + |
| 34 | +ユースケースの表現において、動作主体が「〜する」と断定するのではなく、「〜できる」と可能性を含ませるように表すことが推奨されています。これは、以下の理由からです。 |
| 35 | + |
| 36 | +- **設計コストの増大抑制**：設計図で何かを断定すると、それを必ず実現しなければならないという厳密な設計になり、UIの設計コストが増大します。 |
| 37 | +- **ユーザー行動の制限回避**：ユーザーは人間であり、さまざまな感情や意図を持っています。ユーザーの思考や行動はそのときどきによって左右されやすく、製品に完全集中するわけではありません。ユースケースが可能性と用途の記述であると捉えることで、ソフトウェアがユーザーを縛らない設計を目指すことが重要になります。たとえば、「ユーザーはレシピを検索できる」と記述することで、「（できるけど）検索しない」という可能性も含まれることになり、不要な制約を避けることができます。 |
| 38 | + |
| 39 | +## ユースケース名と分類、採番 |
| 40 | + |
| 41 | +- **ユースケース名**：簡潔なユースケース名を付与することで、見分けがつきやすくなります。構文から想定できる名前を検討し、「投稿したレシピを削除できる」のように「〜できる」で表現することが推奨されます。管理する場合には「投稿」「検索」のように体言止めにすると簡潔で読みやすくなります。 |
| 42 | +- **分類**：ユースケースを分類したい場合、対象物（例：「レシピ」「コメント」「アカウント」）と動作主体（例：「ユーザー」「システム」）を軸にグループ化すると効果的です。 |
| 43 | +- **ユースケース番号**：ユースケースには固有番号を採番することが推奨されます。採番ルールに厳密な決まりはありませんが、「分類名+連続番号」（例：UC_A_1）のような簡素な表記が運用しやすいとされます。ゼロパディングは、将来的なユースケースの最大数を制限する可能性があるため、余程の理由がない限り避けるべきです。 |
| 44 | + |
| 45 | +## ユースケース定義の材料とツール |
| 46 | + |
| 47 | +ユースケース定義の材料となるのは、主にユーザーリサーチによって形作られる「行動シナリオ」と「ペルソナモデル」です。これらを分析し、「名詞（オブジェクト）」と「動詞（タスク）」を抽出することが、ユースケース定義の大きな目標となります。 |
| 48 | + |
| 49 | +ユースケース定義は、箇条書きができれば十分であり、プレーンテキストを編集できるツールなら何でも構いません。Miroのようなホワイトボードツールも有効ですが、ツールの縛りはなく、構文に当てはめて考えられることが重要です。 |
| 50 | + |
| 51 | +## 他の設計工程との連携 |
| 52 | + |
| 53 | +ユースケース定義は、タスク整理（@docs/model-based-ui-design/steering/02-task-analysis.md）や概念設計（@docs/model-based-ui-design/steering/03-conceptual-design.md）の基盤となります。 |
| 54 | + |
| 55 | +ユースケースは、タスクや概念オブジェクトの妥当性や優先度を評価する際にも活用され、最終的にUIデザイン全体に一貫した「芯」を通し、ユーザーの用途を強く反映した設計を実現するための羅針盤となります。 |
0 commit comments