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

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

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

進め方の前提

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

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