# 業務アプリ開発ヒアリングシート

> 配布元: DSS Studio（https://www.dss-studio.net/hearing-sheet）
> 改変・商用利用・再配布自由。クレジット表記不要。
> このシートに記入した内容は、DSS Studio に入力すると図表・仕様書 PDF・動くプロトタイプまで自動生成できます。

---

## ステップ1: 基本情報

- 業種:
- 作りたいシステムの種類（例: 受注管理、経費申請、在庫管理）:
- 顧客名（社内システムなら対象部署）:
- ヒアリング実施者:
- 実施日:

## ステップ2: 業務の全体像

- システムの名前（仮でよい）:
- 目的を一文で（誰の・何の業務を・どう良くするか）:
- 今回やらないこと（スコープ外）:
  -
  -
- 業務のまとまり（例: 受注管理・在庫管理・請求）:
  -
  -
- 一番大事なまとまり:

## ステップ3: 登場人物（アクター）

| 役割（例: 営業担当） | 達成したいこと | 権限の違い（見えてよい情報・してよい操作） |
|---|---|---|
|  |  |  |
|  |  |  |

## ステップ4: 扱う情報（エンティティ）※最重要

登場する「モノ・コト」（例: 受注、商品、顧客、請求書）ごとに記入する。

### エンティティ名:

- マスタ（台帳）か、取引データ（トランザクション）か:
- 項目一覧:

| 項目名 | 種類（文字/数値/日付/選択肢/参照） | 必須? | 重複禁止? | 選択肢・備考 |
|---|---|---|---|---|
|  |  |  |  |  |
|  |  |  |  |  |

- 状態を持つか（例: 申請中 → 承認済 → 出荷済）: はい / いいえ
  - 状態の一覧:
  - 最初の状態:
  - 状態が変わるきっかけ（誰の・どの操作か）:

| 変更前 | 変更後 | きっかけ（誰が何をする） | 備考 |
|---|---|---|---|
|  |  |  |  |

（エンティティの数だけこのブロックを複製する）

## ステップ5: 業務の操作（ユースケース）

「誰が・何を・どうする」の形で挙げる（例: 営業担当が受注を登録する）。

| 操作（誰が・何を・どうする） | 種類（登録/更新/承認/差戻し/キャンセル/参照） | 実行できる条件 | 入力する項目 |
|---|---|---|---|
|  |  |  |  |
|  |  |  |  |

## ステップ6: 業務ルール

| ルール（例: 与信限度額を超える受注は上長承認が必須） | 対象（エンティティ/操作） | 破ったときの扱い（エラー/警告） |
|---|---|---|
|  |  |  |
|  |  |  |

## ステップ7: 画面・帳票の要望

- 必要な画面（一覧 / 詳細 / 登録 / 承認待ち一覧 など）:
  -
- 一覧画面の検索条件と並び順:
- メニュー構成（グループ化・誰にどのメニューを見せるか）:
- 帳票（注文書・請求書など）:
  - 帳票名:
  - 載せる項目:
  - 明細の有無・明細の項目:
  - 合計欄:
  - 発行元の表記:
- 日付・金額の表示形式（例: 2026/07/09、¥1,000）:

## ステップ8: 用語集・自由メモ

| 社内用語 | 意味 | 同義語 |
|---|---|---|
|  |  |  |

- 自由メモ（どの欄にも入らなかった気になること）:

---

## 使い方のコツ

1. **業務語のまま書く** — 「受注」を「オーダーデータ」に翻訳しない。
2. **空欄のまま次へ進んでよい** — 「わからない」の可視化が成果。次回ヒアリングの議題になる。
3. **状態遷移（ステップ4）に一番時間を使う** — 承認フローは認識が最もズレやすい。「承認済のあとに差戻しはあるか」まで聞き切る。
4. **聞いた内容は図にして見せ返す** — 文章のまま合意すると解釈が割れる。図表・動くプロトタイプで確認できる状態＝「見える仕様」については https://www.dss-studio.net/visible-spec を参照。