---
name: function-usecase-map
description: >-
  Persona・ビジョン・要件メモから、Actor がユーザーに見える機能を通じて達成するユースケースを
  Mermaid 図にする。全体俯瞰と機能別図を `docs/usecase-map.md` へ出す。Triggers on
  ユースケース図, 利用関係, function-usecase-map, usecase-mapper, usecase map.
context: fork
disable-model-invocation: true
allowed-tools: Bash(node:*), Bash(pnpm:*), Bash(git:*), Bash(which:*), Bash(ls:*), Bash(mkdir:*), Bash(python:*), Read, Glob, Grep, Agent, Write, Artifact, Skill
rank: core
categories:
  - design
---

# ユースケーススケッチ生成

Persona・ビジョン・要件メモ・議事録などから、プロダクトや機能のユースケースを**スケッチ段階で可視化**し、`docs/usecase-map.md` にまとめる。  
このスキルの主役は **Mermaid のユースケース図っぽい図**。機能一覧やユースケース一覧は、図を描くための補助情報として扱う。

> 人間向けの概要・使い方は [`README.md`](README.md) を参照。

---

## 基本方針

- **コードベース前提にしない**。入力が文書だけでも成立させる
- **Persona 起点**で考える。各ユースケースは「誰が」「何を達成したいか」を中心に書く
- **実装依存情報は出さない**。API、エンドポイント、画面パス、DB、内部フロー、技術構成は出力対象外
- **ドメイン一覧ではなく機能一覧**を作る。これは図を描く単位を揃えるための補助整理
- **全体俯瞰モード** と **機能別詳細モード** の 2 つに対応する
- **推測で実装を捏造しない**。不明点は「未確定」「仮説」と明示する

---

## Step 0: モードを確定する

ユーザーの依頼文から、今回の出力モードを決める。

### Mode A: 全体俯瞰

プロダクト全体を見たいときに使う。

- 出力するもの:
  - アクター、ペルソナ一覧
  - 機能一覧
  - ユースケース一覧
  - 全体のユースケース図
  - 機能ごとのユースケース図

### Mode B: 機能別詳細

特定機能だけ深掘りしたいときに使う。

- 出力するもの:
  - 対象 Actor / Persona 一覧
  - 対象機能の情報
  - 対象機能のユースケース表
  - 対象機能の簡単な説明（200字以内）
  - 対象機能のユースケース図本体
  - 必要なら「前提 / 未確定事項」

ユーザーが明示していない場合は以下で判断する:

- 「全体像」「俯瞰」「全部」→ Mode A
- 「この機能だけ」「予約機能だけ」「認証まわりだけ」→ Mode B

---

## Step 1: 入力ソースを読む

入力はコードである必要はない。以下を単独または複数組み合わせて使う。

| 入力種別 | 例 | 主に拾う情報 |
|---|---|---|
| Persona / Segment 定義 | persona doc, interview synthesis | アクター、状況、達成したいこと |
| Vision / Concept | vision doc, concept memo | 何を実現するプロダクトか、何を優先するか |
| 要件メモ | 要求一覧、ユーザーストーリー | 機能候補、利用シーン |
| 議事録 / ヒアリング | MTG メモ、インタビュー | 生の利用文脈、困りごと、目的 |
| 既存コード / 仕様書 | 任意 | 補助的に機能名や既知の挙動を確認するためだけに使う |

### 抽出する要素

- **Actor / Persona**: 誰が使うか
- **Situation**: どんな状況で使うか
- **Goal**: 何を達成したいか
- **Function**: その goal を支える機能のまとまり
- **Use case**: Actor が Function を使って達成する具体的な行為

### 抽出しない要素

- API / endpoint
- DB / schema
- 画面パス / コンポーネント構成
- 内部処理フロー
- 実装済み / 未実装 の断定

---

## Step 2: 機能一覧を組み立てる

ユースケースを図にしやすくするため、まず**機能一覧**に整理する。

### 機能一覧の作り方

1. Persona の目的や JTBD を読む
2. 目的達成に必要な行為を抽出する
3. 近い行為をまとめて「機能」に束ねる
4. 各機能に対して、代表的なユースケースを 2-5 個ほど紐づける

### 機能名のルール

- ドメイン名や内部概念ではなく、**ユーザーに伝わる機能名**にする
- 名詞だけで曖昧なら「何を可能にするか」が分かる表現にする
- 例:
  - `認証` より `アカウントに入る・本人確認する`
  - `通知基盤` より `更新や対応依頼に気づける`
  - `案件管理ドメイン` より `案件の状況を整理して追える`

---

## Step 3: ユースケースへ展開する

各機能について、Persona / Actor 視点でユースケースを書く。

### ユースケースの書き方

- 「アクターがシステムを使って何を達成するか」を一文で書く
- CRUD の粒度ではなく、**目的単位**でまとめる
- 1 機能あたり 2-5 件を目安にする
- 書式は `〜できる` または `〜する`

### 例

- バンドの方向性を共有できる
- 顧客ヒアリング前に仮説を揃えられる
- 次に検証すべき論点を洗い出せる
- 提案のたたき台を短時間で作れる

### 付与する列

| 列 | 内容 |
|---|---|
| UC ID | `UC-F01-01` のように採番 |
| 機能ID | `F01` 形式 |
| 機能名 | 機能一覧と対応 |
| ユースケース | Actor の目的単位の行為 |
| 主アクター | Primary persona / secondary actor など |
| 利用シーン | いつ・どんな文脈か |
| 期待結果 | 何が達成されると成功か |
| 確度 | `Fact` / `Assumption` / `Unknown` |

---

## Step 4: `docs/usecase-map.md` を生成する

以下の構成で Markdown を生成する。

````markdown
# <プロダクト名> ユースケーススケッチ

> Persona が固まった段階で、機能と利用シーンを粗く揃えるための土台。
> 実装仕様ではなく、誰にどんな価値を返すかを確認するための資料。

## 前提
- 参照した入力ソース
- 今回のモード: 全体俯瞰 / 機能別詳細
- 対象 Persona / Actor

## アクター、ペルソナ一覧
| Actor / Persona | 概要 | 主な状況 | 主な目的 |
|---|---|---|---|

## 機能一覧
| 機能ID | 機能名 | 何を可能にするか | 主な対象 Actor | 代表ユースケース数 |
|---|---|---|---|---|

## ユースケース一覧
| UC ID | 機能ID | 機能名 | ユースケース | 主アクター | 利用シーン | 期待結果 | 確度 |
|---|---|---|---|---|---|---|---|

## 全体のユースケース図

```mermaid
flowchart LR
  actor1([案件初期フェーズを前に進める<br/>バンドメンバー])
  actor2([後から参加する<br/>バンドメンバー])
  actor3([バンドリーダー /<br/>バンドマネージャー])

  subgraph F01["F01 ヒアリング準備を揃える"]
    uc101(誰が何を聞くかを揃える)
  end
  subgraph F02["F02 ヒアリング直後の論点を整理する"]
    uc201(論点と示唆を切り出す)
  end
  subgraph F03["F03 誰に提案するかを絞り込む"]
    uc301(候補を比較する)
  end

  actor1 --> uc101
  actor1 --> uc201
  actor1 --> uc301
  actor2 --> uc201
  actor3 --> uc301
```

## 機能ごとのユースケース図

<details>
<summary>F01 方向性を揃える</summary>

### 機能の簡単な説明
（この機能が何のためにあるかを 200字以内で書く）

### ユースケース図本体

```mermaid
flowchart LR
  actor([バンドメンバー])
  subgraph F01["F01 ヒアリング準備を揃える"]
    uc1(誰が何を聞くかを揃える)
    uc2(仮説の粒度を揃える)
    uc3(進行カードを作る)
  end
  actor --> uc1
  actor --> uc2
  actor --> uc3
```

### 前提 / 未確定事項
- 例: 共同編集を含むかは未確定
- 例: 1人利用を優先するかチーム利用を優先するかは仮説段階

</details>
````

### Mode A の補足

- 出力順は `アクター、ペルソナ一覧` → `機能一覧` → `ユースケース一覧` → `全体のユースケース図` → `機能ごとのユースケース図` に固定する
- 一覧は図を描くための前提情報として短くまとめる
- `機能ごとのユースケース図` では、各機能に `機能の簡単な説明` と `ユースケース図本体` を必ず置く
- `機能の簡単な説明` は 200字以内にする

### Mode B の補足

- `全体ユースケース図` は省略可
- 対象機能だけでも、`アクター、ペルソナ一覧` → `機能一覧` → `ユースケース一覧` → `機能ごとのユースケース図` の順序は維持する
- `機能の簡単な説明` は 200字以内にする
- 一覧表は短くてよい
- 代わりに対象機能の `前提 / 未確定事項` を少し厚めに書く

---

## Step 5: Mermaid 図のルール

- 図は Mermaid の `flowchart LR` を使う
- Mermaid には正式な UML ユースケース図記法がないため、**ユースケース図っぽい近似表現**として出す
- アクターは `([ ... ])` のスタジアム型で表す
- ユースケースは `( ... )` の丸ノードで表す
- 機能単位のまとまりは `subgraph` で囲う
- **図はユースケース図だけ**にする。フロー図は出さない
- 表より図を優先する。情報量が多いときも、まず図で関係を見せ、表は補助に回す

### 全体図

- 左に Actor / Persona
- 右に Function ごとの `subgraph`
- 各 `subgraph` の中に主要 use case を 1-3 個だけ置く
- ノードが増えすぎる場合は主要 use case だけに絞る

### 機能別図

- 左に Actor
- 右に use case
- 機能境界は `subgraph` で表す
- 1 図 6-9 ノード程度までに抑える

## Step 6: ユーザーへの案内

完了後は以下を案内する:

```text
docs/usecase-map.md にユースケーススケッチを生成しました。

- Mermaid の全体図と機能別ユースケース図をそのまま Markdown で見られます
- 実装仕様ではなく、何を誰のために作るかの確認用です
- 全体俯瞰と機能別詳細の両方に対応しています
```

## Documenting with prhythm-docs

After the skill run, when the user asks to save or present results（まとめて / ドキュメントにして / スライドにして）:

1. Use `/prhythm-docs` (or follow that meta-skill)
2. Fill `templates/docs/index.md` and `templates/docs/sections.html` in this skill
3. Build the deck: `node skills/prhythm-docs/scripts/build-deck.mjs skills/function-usecase-map/templates/docs/sections.html docs/prhythm/function-usecase-map/index.html --title "…"`
4. Write `docs/prhythm/function-usecase-map/index.md`

Do not dump full catalogs into those files. Markdown is a briefing (Answer / Frame / Evidence / Gates / Next) — see `skills/prhythm-docs/references/md-grammar.md`.