---
note: 受注側の提案から始まる案件で要求フェーズをどう運ぶか。資料の読み替え・検証面談・身分の立て直し
created: 2026-08-17T11:17:58+09:00
---

# 提案型案件の要求フェーズ

「要求は誰のものか」は、提案時点の要求が**誰にも検証されていない仮説**であること、受注後に合意事項として立て直す必要があることを述べた。本文書はその実務展開——提案型案件で「要求フェーズの作成資料と情報項目」の各資料をどう読み替え、どう運ぶか——を扱う。

対象は、受注側の提案から始まる案件(新規サービス、アプリケーション、既存客先への機能提案)である。

## 何が逆転するか

客先発意型は「現状 → 問題 → 要求 → 提案」の順に流れる。提案型は受注側の**価値仮説**から始まり、順序が逆転する。

```
客先発意型:  現状把握 → 問題 → 要求 ──────────────────→ 要件
提案型:      価値仮説 → 客先の現状に照合 → 問題の実在を検証 → 合意事項へ立て直し → 要件
```

順序は崩れてよい。「要求は誰のものか」がプロトタイプの逆流について述べたとおり、崩れてはいけないのは順序ではなく判断であり、**立て直しの工程が後ろに必ず要る**。

## 最大のリスク: 要求の自作自演

提案型で最も起きやすい失敗は、受注側が書いた仮説がそのまま要求として固定され、**客先の誰も所有していない要件**が積み上がることである。検収時に「そもそもこれは誰が欲しかったのか」に誰も答えられなくなる。

これは「要求は誰のものか」の言葉では、仮説が身分を偽って合意事項の位置に座ることである。提案書は相手を説得するための文書であり、通すために強めに書かれた成功基準が混じる。それが要求として居座れば、達成不能な目標を抱えたまま開発が始まる。

対策は一つで、**採用の証跡を取る**こと。要求一覧の「身分・発言者・確定日」は、提案型でこそ必須項目になる。

## 資料の読み替え

「要求フェーズの作成資料と情報項目」の5点は提案型でも作る。ただし次のとおり読み替える。

| 客先発意型 | 提案型での読み替え |
|---|---|
| 業務フロー(As-Is) | **利用シーン記述**: 対象ユーザー像 / いつ・どこで・何のために使うか / 現在その目的をどう満たしているか(代替手段。「何もしていない」も回答である)。既存業務が存在する場合はAs-Isフローも併用する |
| 問題・課題一覧 | **課題仮説一覧**: 同じ項目 + 検証状態列(**未検証 / 客先確認済 / 棄却**)。棄却された仮説は消さずに残す(提案の軌道修正の記録。「なぜこの機能がないのか」に後から答えられる) |
| 要求一覧 | **価値仮説一覧**: 同じ項目構成。客先が「それは欲しい」と発言したものだけが身分を合意事項に変え、要求に昇格する |
| ステークホルダー一覧 | 同じ。ただし**推進者**(客先社内で提案を推す人)の特定を最優先とする。推進者の関心事(社内でどう説明するか、稟議に何が要るか)は要求と同格に扱う |
| 制約一覧 | **前提条件一覧**: 提案が成立するために受注側が置いている前提(稼働環境、既存契約、セキュリティ規程、予算感)。前提が崩れると提案自体が崩れるため、**最初のヒアリングで検証する** |

## ヒアリングは検証面談になる

客先発意型のヒアリングは「客先のみ」項目の回収が中心だった。提案型では全項目が受注側の仮説から始まるため、ヒアリングは仮説を見せて壊してもらう**検証面談**になる。設問の型:

- 「御社では◯◯のとき、△△に困っていると想定していますが、実際はいかがですか」(課題仮説の検証)
- 「仮にこれがあったら、どの業務のどの場面で使いますか」(利用シーンの実在検証。**具体的な場面が出てこない機能は要求に昇格させない**)
- 「これが入った場合、逆に困る方はいらっしゃいますか」(否定的ステークホルダーの発見。導入を止めるのは大抵この人である)

エピソードで裏を取る原則は客先発意型と同じ。想定課題に対して「最近それで困ったのはいつですか」と聞き、実例が出なければ検証状態を棄却側に倒す。

## 身分の立て直し

要件フェーズに入る前に、次の状態を満たす。

- [ ] 採用された各要求に、客先側の**発言者と確定日**が記録されている
- [ ] 優先度と成功基準を**客先が**決めている。受注側の仮置きの数字が残っていない(提案書の「強めの成功基準」はここで洗い直す)
- [ ] 棄却された仮説が記録として残っている
- [ ] 提案書と要求定義の文書が分かれている(「要求は誰のものか」: 片方は仮説、片方は合意であり、同じ文書にすると身分の変わり目が分からなくなる)
- [ ] 提案書に載せた画面・デモが仕様から切り離されている(あれは説得のための絵であり、仕様ではない)

この5点が揃った時点で、以降は客先発意型と同じ流れ(全体要件書 → 領域別要件定義書)に合流する。

## まとめ

- 提案型は価値仮説から始まる。順序の逆転は問題ではなく、立て直しの欠落が問題である
- 最大のリスクは要求の自作自演。対策は採用の証跡(発言者・確定日)
- 資料は5点を読み替えて使う。棄却仮説は消さずに残す
- ヒアリングは検証面談。具体的な利用場面が出ない機能は要求に昇格させない
- 立て直しの5条件が揃うまで要件フェーズに入らない

**この判断は誰が検証するのか。** 提案型では、この問いの答えが「まだいない」状態から始まる。要求フェーズの仕事は、機能を並べることではなく、**この問いに答えられる人を客先の中に作ること**である。