---
note: 要求フェーズで作る5点の資料と各情報項目。受注側が仮説で埋めてヒアリングで検証する3ステップ運用
created: 2026-08-17T11:17:19+09:00
---

# 要求フェーズの作成資料と情報項目

「要求は何でできているか」は要求の5要素(背景・目的・成功基準・制約・スコープ外)を、「要求は誰のものか」は要求の主体と身分(合意事項/仮説)を扱った。本文書は、その要求を実務でどう収集するか——**どの資料を作り、何を埋め、誰に何を聞くか**を扱う。

対象は客先が存在する案件(受託・社内基幹システム)である。受注前の提案から始まる案件は「提案型案件の要求フェーズ」を参照。

## 進め方の前提

要求の**所有者は客先**だが、**記述者は受注側**である。客先が要求文書を書けることは期待しない。進行は常に次の3ステップで行う。

1. **仮説記入**: 受注側が入手済みの情報(資料・過去案件・ドメイン知識)から全項目を仮説で埋める。この時点の全記述の身分は仮説である
2. **ヒアリング(検証)**: 仮説を見せて壊してもらう。白紙で「教えてください」と聞かない。間違った仮説への訂正のほうが、白紙への回答より速く正確に埋まる
3. **確定**: 客先の発言で上書きし、**発言者を記録**する。発言者の記録が、仮説が合意事項に変わった証跡になる

## 作成資料一覧

最小セットは5点。判断基準は「この資料がないと、何の判断を誤るか」である。

| # | 資料 | ないと誤る判断 | 主な情報源 |
|---|---|---|---|
| 1 | ステークホルダー一覧 | 誰に聞き、誰の承認で確定するか | 窓口担当へのヒアリング |
| 2 | 業務フロー(As-Is) | 問題がどこで起きているか、システム化の範囲 | 業務担当へのヒアリング、現場観察 |
| 3 | 問題・課題一覧 | 何を解決すべきか、投資の妥当性 | 業務担当・管理者 |
| 4 | 要求一覧 | システムが応えるべきことの範囲と優先度 | 決裁者・業務担当 |
| 5 | 制約一覧 | 実現手段の選択肢、スケジュール | 決裁者・情報システム部門 |

作らないもの: KPI検討書・目標施策体系図(要求一覧の列に畳む)、業務用語一覧(全体要件書の用語定義と統合する。同じ情報を二箇所に定義しない)、実行計画書(提案書・契約側の文書)。

書籍等が挙げる10数種のフルセットは大規模SI向けであり、資料の数だけ同期コストが増える。追加するときは「ないと誤る判断」を言えるものに限る。

## 各資料の情報項目

「記入」列: **仮説可** = 受注側が仮説で埋めてよい / **客先のみ** = ヒアリングでしか埋まらない。

### 1. ステークホルダー一覧

| 項目 | 内容 | 記入 |
|---|---|---|
| 氏名・所属・役職 | | 客先のみ |
| 役割 | 決裁 / 承認 / 利用 / 影響を受ける | 仮説可 |
| 関心事・懸念 | その人が何を気にするか(コスト、業務負荷、責任範囲) | 仮説可 |
| ヒアリング要否・実施日 | | — |

設問例:

- 「この業務に関わる方、この変更で影響を受ける方は、他にいらっしゃいますか」(漏れの検出。周辺部門——編集・営業・サポート等——が漏れやすい)
- 「最終的にどなたの承認で進みますか」(成功を判定する者の特定。「要求は誰のものか」の判定の問いに対応する)

### 2. 業務フロー(As-Is)

スイムレーン等の図 + 補足表。図に含める情報:

| 項目 | 内容 | 記入 |
|---|---|---|
| 登場者(レーン) | ステークホルダー一覧と対応させる | 仮説可 |
| 作業ステップ | 誰が・何を・どの順で | 仮説可 |
| 使用手段 | **システム外を含める**(Excel、メール、電話、口頭、紙) | 客先のみ |
| 受け渡される情報 | ステップ間で何が渡るか(ファイル、連絡、承認) | 仮説可 |
| 頻度・件数 | 日次/週次/月次、1回あたりの件数 | 客先のみ |
| 所要時間 | ボトルネック特定用。概算でよい | 客先のみ |

設問例:

- 「直近でこの作業をしたときの手順を、最初から順に教えてください」(一般論ではなく直近の実例を聞く。一般論は理想化される)
- 「システムに入力する前後で、手元で何か管理していますか」(Excel・個人メモの発見。問題はシステムの外に埋まっていることが多い)

### 3. 問題・課題一覧

| 項目 | 内容 | 記入 |
|---|---|---|
| 問題ID | 連番 | — |
| 問題(事実) | 起きていること。**解決策を書かない**。「〜がない」は解決策の裏返しなので禁止。「〜できず、…が起きている」の形で書く | 仮説可 |
| 発生箇所 | 業務フロー上のステップ参照 | 仮説可 |
| 影響 | 定量で(件数、時間、金額、機会損失)。「要求は何でできているか」の成功基準の**現在値**がここから来る | 客先のみ |
| 頻度 | | 客先のみ |
| 現状の回避策 | 今どう凌いでいるか。回避策の存在は問題の実在の証拠 | 客先のみ |

設問例:

- 「最近その問題が起きたのはいつですか。そのとき何が起きましたか」(エピソードで裏取り。答えられない問題は実在しない可能性がある)
- 「それが起きたとき、どう対処していますか」

### 4. 要求一覧

要求フェーズの中心成果物。全体要件書の「背景と要求」に要約を反映し、各領域の要件定義書のユースケースからトレースされる。

| 項目 | 内容 | 記入 |
|---|---|---|
| 要求ID | 連番(要件文書からの参照用) | — |
| 要求 | 達成したいこと。**主語は業務**。解決策を書かない(「要求は何でできているか」の目的の抽象度判定を適用: 反対する人がいない記述は上げすぎ、手段が固定される記述は上げ足りない) | 仮説可 |
| 対応する問題ID | 問題一覧へのトレース。**どの問題にも紐づかない要求は水増しの疑い** | 仮説可 |
| 優先度 | 必須 / 重要 / 任意 | 客先のみ |
| 成功基準 | 現在値・目標値・測り方と時点の3点(「要求は何でできているか」参照)。数値にならないなら達成/未達を二値で言える条件 | 客先のみ |
| 身分・発言者・確定日 | 仮説 / 合意事項。合意事項なら誰の発言か | 客先のみ |

設問例:

- 「この問題が解決したとき、何がどうなっていれば成功と言えますか」(成功基準を客先の言葉で取る)
- 「AとBの両方はできない場合、どちらを先にしますか」(優先度は二択で聞く。並べて聞くと全部「必須」になる)

### 5. 制約一覧

| 項目 | 内容 | 記入 |
|---|---|---|
| 区分 | 法令・規制 / 契約・期限・予算 / 技術・環境(オンプレ要否、既存システム接続) | — |
| 内容 | | 客先のみ |
| 出どころ | なぜその制約があるか(規程名、決裁事項、慣行)。「要求は何でできているか」の判定を適用: **破ったら何が起きるかを1文で書けないなら、制約ではなく前提** | 客先のみ |
| 交渉可能性 | 破れない / 交渉すれば動く | 客先のみ |

設問例:

- 「それは決定事項でしょうか、それともご希望でしょうか」
- 「その期限の根拠は何ですか」(根拠のない期限は希望であることが多い)

## 5要素との対応

資料を埋めると、要求の5要素は次の場所に現れる。

| 5要素 | 現れる場所 |
|---|---|
| 背景 | 問題・課題一覧(影響・頻度が「なぜ今か」の根拠になる) |
| 目的 | 要求一覧の要求文 |
| 成功基準 | 要求一覧の成功基準列(現在値は問題一覧の影響から) |
| 制約 | 制約一覧 |
| スコープ外 | 要求一覧の優先度「任意」と、検討して外した要求の記録 |

資料が埋まっても、**問題→要求→成功基準の線が1本でつながっているか**を最後に確認する。線が切れている典型は「要求は何でできているか」の断線の表を参照。

## 要件フェーズへの接続

- 要求一覧(確定版)の要約を全体要件書の「背景と要求」に記載し、詳細表は別紙参照とする
- 各領域の要件定義書のユースケースに「対応する要求ID」を持たせる。どの要求にも紐づかないユースケースは、追加の根拠をレビューで問う(要件の量の抑制装置として働く)
- 制約一覧のうちシステム全体に効くもの(稼働環境、稼働時間等)は、全体要件書の非機能・制約の節へ引き渡す

## まとめ

- 資料は5点で足りる。増やすなら「ないと誤る判断」を言えるものだけ
- 受注側が仮説で埋め、ヒアリングで壊してもらい、発言者を記録して合意事項に変える
- 問題は事実で書き、エピソードで裏を取る。回避策の存在が実在の証拠
- 要求は問題にトレースし、成功基準の現在値は問題の影響から取る
- 制約は出どころを聞き、前提と区別する

**この判断は誰が検証するのか。** 各資料の「客先のみ」列が、その資料の検証者を示している。仮説可の項目だけで完結した資料は、まだ誰にも検証されていない。