「要求は誰のものか」は、提案時点の要求が誰にも検証されていない仮説であること、受注後に合意事項として立て直す必要があることを述べた。本文書はその実務展開——提案型案件で「要求フェーズの作成資料と情報項目」の各資料をどう読み替え、どう運ぶか——を扱う。
対象は、受注側の提案から始まる案件(新規サービス、アプリケーション、既存客先への機能提案)である。
客先発意型は「現状 → 問題 → 要求 → 提案」の順に流れる。提案型は受注側の価値仮説から始まり、順序が逆転する。
客先発意型: 現状把握 → 問題 → 要求 ──────────────────→ 要件
提案型: 価値仮説 → 客先の現状に照合 → 問題の実在を検証 → 合意事項へ立て直し → 要件
順序は崩れてよい。「要求は誰のものか」がプロトタイプの逆流について述べたとおり、崩れてはいけないのは順序ではなく判断であり、立て直しの工程が後ろに必ず要る。
提案型で最も起きやすい失敗は、受注側が書いた仮説がそのまま要求として固定され、客先の誰も所有していない要件が積み上がることである。検収時に「そもそもこれは誰が欲しかったのか」に誰も答えられなくなる。
これは「要求は誰のものか」の言葉では、仮説が身分を偽って合意事項の位置に座ることである。提案書は相手を説得するための文書であり、通すために強めに書かれた成功基準が混じる。それが要求として居座れば、達成不能な目標を抱えたまま開発が始まる。
対策は一つで、採用の証跡を取ること。要求一覧の「身分・発言者・確定日」は、提案型でこそ必須項目になる。
「要求フェーズの作成資料と情報項目」の5点は提案型でも作る。ただし次のとおり読み替える。
| 客先発意型 | 提案型での読み替え |
|---|---|
| 業務フロー(As-Is) | 利用シーン記述: 対象ユーザー像 / いつ・どこで・何のために使うか / 現在その目的をどう満たしているか(代替手段。「何もしていない」も回答である)。既存業務が存在する場合はAs-Isフローも併用する |
| 問題・課題一覧 | 課題仮説一覧: 同じ項目 + 検証状態列(未検証 / 客先確認済 / 棄却)。棄却された仮説は消さずに残す(提案の軌道修正の記録。「なぜこの機能がないのか」に後から答えられる) |
| 要求一覧 | 価値仮説一覧: 同じ項目構成。客先が「それは欲しい」と発言したものだけが身分を合意事項に変え、要求に昇格する |
| ステークホルダー一覧 | 同じ。ただし推進者(客先社内で提案を推す人)の特定を最優先とする。推進者の関心事(社内でどう説明するか、稟議に何が要るか)は要求と同格に扱う |
| 制約一覧 | 前提条件一覧: 提案が成立するために受注側が置いている前提(稼働環境、既存契約、セキュリティ規程、予算感)。前提が崩れると提案自体が崩れるため、最初のヒアリングで検証する |
客先発意型のヒアリングは「客先のみ」項目の回収が中心だった。提案型では全項目が受注側の仮説から始まるため、ヒアリングは仮説を見せて壊してもらう検証面談になる。設問の型:
エピソードで裏を取る原則は客先発意型と同じ。想定課題に対して「最近それで困ったのはいつですか」と聞き、実例が出なければ検証状態を棄却側に倒す。
要件フェーズに入る前に、次の状態を満たす。
この5点が揃った時点で、以降は客先発意型と同じ流れ(全体要件書 → 領域別要件定義書)に合流する。
この判断は誰が検証するのか。 提案型では、この問いの答えが「まだいない」状態から始まる。要求フェーズの仕事は、機能を並べることではなく、この問いに答えられる人を客先の中に作ることである。