---
note: 要求検証から検収までの6段レビューフロー。各段の提示物・判断・完了条件、プロトタイプの非契約明言、再承認の判定基準と2レーン運用
created: 2026-08-17T18:39:29+09:00
---

# 客先レビューのフロー — 何をいつ提示し、何を合意するか

要求から検収までの客先レビューを6段のフローとして定める。各段で「提示するもの」「客先に求める判断」「完了条件」を固定し、どの段でも判断の対象を混ぜない。文書の層(要求・要件・仕様・設計)と文書単位(「要件定義書は業務領域単位で書く」)を前提とする。

## フロー全体

| 段 | フェーズ | 提示するもの | 客先に求める判断 | 完了条件 |
|---|---|---|---|---|
| 0 | 要求検証面談 | 要求資料5点の仮説版(「要求フェーズの作成資料と情報項目」) | 仮説の訂正、エピソードによる裏取り、優先度と成功基準の決定 | 要求一覧が合意事項化(発言者記録済み) |
| 1 | 全体要件レビュー | 全体要件(目的範囲・利用者・領域一覧・共通用語・共通ルール・非機能) | **枠組みの合意**: 領域分割の過不足、用語、共通ルール、非機能水準 | 領域分割の確定、全体分の要確認回答 |
| 2 | 領域要件レビュー(領域ごと) | 領域別要件+該当する要確認事項 | ユースケースの過不足 / 業務ルールの数値・条件 / 管理する情報 / スコープ外の落ち | 領域の要確認消し込み、版確定 |
| 3 | プロトタイプレビュー | Figma・モック(**非契約と明言**) | 操作の流れと構成 | プロトタイプ承認(=フロー承認) |
| 4 | 仕様確認(必要箇所のみ) | 画面仕様書のうち確認依頼箇所のみ(文言・帳票・業務に触れる挙動) | 依頼箇所のみの可否 | 依頼箇所の回答 |
| 5 | 受入テスト・検収 | 受入基準(確認結果・確認日の記入欄付き) | 基準ごとの合否 | 全基準の合格 |

## 運びのルール(全段共通)

- **議題リスト = 要確認台帳そのもの。** 会議は要確認の消し込みとして進め、回答と回答者名を必ず記録する(要求の所有の証跡)
- **見た目・操作感の意見はどの段で出ても拒否しない。** 裏にある業務要求だけをその場で拾い、表現の話は段3へ送る
- 段3で要件に跳ね返る発見(「この流れでは業務が回らない」)が出たら、要確認として台帳に**逆流**させ段2に戻す。プロトタイプは要件の検証装置を兼ねる
- 版の確定は段ごとに行う(段1で全体要件、段2で各領域)。確定後は変更管理(改訂履歴)に乗る

## 順序の規律

- **段1は1回で終える。** 枠(領域分割・用語)が揺れたまま段2に入ると、以降のレビューのたびに枠の議論が再燃する。用語・約束事を全体要件に一元化しているのはこのため
- **段2は領域ごとに並走できる。** ある領域が段3にいる間に別領域が段2でよい。ただし共通ルール・共通用語に触れる回答が出たら全領域に波及するため、その場で台帳に展開する
- 段0が受注前に食い込む提案型案件では、段0の完了(要求の所有権移転。「提案型案件の要求フェーズ」参照)を契約の起点とする

## 段3の合意範囲 — 「非契約と明言」の意味

プロトタイプは**契約上の納品物・合意物ではない**と客先に明示する。明示しない成果物は、見た人の中で最も強い身分(=約束された完成形)に勝手に昇格し、画面が契約物化する。要件定義書から画面を追い出した意味が、プロトタイプ経由で無効化される。

段3で合意するもの・しないもの:

| 合意する | 合意しない |
|---|---|
| 操作の流れと構成(この手順で業務が回るか) | ピクセル単位の見た目・色・文言の最終形 |
| 画面をまたぐ業務フローの成立 | ダミーデータ・未検討部分の細部 |

明言の3点セット:

1. プロトタイプ冒頭に一文: 「本プロトタイプは操作の流れを確認いただくためのもので、最終的な画面デザインを保証するものではありません。細部は実装時に変更されることがあります」
2. 議事録に「本承認は操作フローの承認であり、画面詳細の確定ではない」と記録する
3. 契約・提案書のゲート定義にも同じ定義で書く(段3 = フロー承認)

段3は**契約上のゲート**として提案書・WBSに位置づける。これがないと操作フローの合意タイミングが宙に浮く。

## 段3以降の変更 — 再承認の判定

判定基準は一つ: **承認の対象(操作の流れと構成)が変わったか。** 実現部品の変更は承認対象の外である。

| 変更の例 | 再承認 | 理由 |
|---|---|---|
| 別画面遷移→モーダル、タブ→アコーディオン | 不要 | 器の変更。手順は不変 |
| ボタン位置・文言・色の変更 | 不要 | 見た目(そもそも合意対象外) |
| 削除時の確認ダイアログ追加 | 不要 | 手順は増えるが、要件(削除は確認を経る)の実現。要件側が根拠 |
| 自由順の入力 → 順序固定のウィザード | **必要** | 合意済みの流れの性質(順序を問わない)が変わる |
| 保存と公開の操作を1ボタンに統合 | **必要** | 業務上別の判断が1操作になり、誤操作の意味が変わる |
| 一括操作の廃止・分割 | **必要** | 業務の作業単位が変わる |
| 途中保存の廃止 | 再承認ではなく**要件改訂** | 要件(中断再開可)に抵触。仕様の裁量の外 |

パターンは3つ。①手順の構造が変わる(順序の固定/解除、ステップの統合・分割) ②業務上の判断の単位が変わる ③要件の達成条件・例外に触れる(→要件改訂の手続きへ)。どれにも触れない変更は受注側の裁量である。

## 承認と報告の2レーン

グレーな変更(例: モーダル化により一覧を見ながらの編集ができなくなる)のために、承認(事前・ブロッキング)とは別に**報告(事後・非ブロッキング)のレーン**を持つ。

- 裁量内の変更は次回定例で「変更しました」と事後報告に載せる
- 客先が「それは困る」と言った変更だけ、その場で承認レーンに昇格させる
- 裁量の範囲を守りつつ、客先のサプライズをゼロにする。検知コストが最も安い運びである

## まとめ

- レビューは6段。各段で提示物・判断・完了条件を固定し、判断の対象を混ぜない
- 議題は要確認台帳の消し込み。回答者の記録は必須
- プロトタイプは非契約と明言し、合意は「操作の流れと構成」に限定する
- 再承認は「流れと構成が変わったか」だけで判定する。器・配置・見た目は裁量
- 裁量内の変更は事後報告レーンに載せ、サプライズをなくす

**この承認は何への承認か。** 承認を取るとき・求められたとき、対象が一文で言えないなら、その承認は後で必ず拡大解釈される。