要求から検収までの客先レビューを6段のフローとして定める。各段で「提示するもの」「客先に求める判断」「完了条件」を固定し、どの段でも判断の対象を混ぜない。文書の層(要求・要件・仕様・設計)と文書単位(「要件定義書は業務領域単位で書く」)を前提とする。
| 段 | フェーズ | 提示するもの | 客先に求める判断 | 完了条件 |
|---|---|---|---|---|
| 0 | 要求検証面談 | 要求資料5点の仮説版(「要求フェーズの作成資料と情報項目」) | 仮説の訂正、エピソードによる裏取り、優先度と成功基準の決定 | 要求一覧が合意事項化(発言者記録済み) |
| 1 | 全体要件レビュー | 全体要件(目的範囲・利用者・領域一覧・共通用語・共通ルール・非機能) | 枠組みの合意: 領域分割の過不足、用語、共通ルール、非機能水準 | 領域分割の確定、全体分の要確認回答 |
| 2 | 領域要件レビュー(領域ごと) | 領域別要件+該当する要確認事項 | ユースケースの過不足 / 業務ルールの数値・条件 / 管理する情報 / スコープ外の落ち | 領域の要確認消し込み、版確定 |
| 3 | プロトタイプレビュー | Figma・モック(非契約と明言) | 操作の流れと構成 | プロトタイプ承認(=フロー承認) |
| 4 | 仕様確認(必要箇所のみ) | 画面仕様書のうち確認依頼箇所のみ(文言・帳票・業務に触れる挙動) | 依頼箇所のみの可否 | 依頼箇所の回答 |
| 5 | 受入テスト・検収 | 受入基準(確認結果・確認日の記入欄付き) | 基準ごとの合否 | 全基準の合格 |
プロトタイプは契約上の納品物・合意物ではないと客先に明示する。明示しない成果物は、見た人の中で最も強い身分(=約束された完成形)に勝手に昇格し、画面が契約物化する。要件定義書から画面を追い出した意味が、プロトタイプ経由で無効化される。
段3で合意するもの・しないもの:
| 合意する | 合意しない |
|---|---|
| 操作の流れと構成(この手順で業務が回るか) | ピクセル単位の見た目・色・文言の最終形 |
| 画面をまたぐ業務フローの成立 | ダミーデータ・未検討部分の細部 |
明言の3点セット:
段3は契約上のゲートとして提案書・WBSに位置づける。これがないと操作フローの合意タイミングが宙に浮く。
判定基準は一つ: 承認の対象(操作の流れと構成)が変わったか。 実現部品の変更は承認対象の外である。
| 変更の例 | 再承認 | 理由 |
|---|---|---|
| 別画面遷移→モーダル、タブ→アコーディオン | 不要 | 器の変更。手順は不変 |
| ボタン位置・文言・色の変更 | 不要 | 見た目(そもそも合意対象外) |
| 削除時の確認ダイアログ追加 | 不要 | 手順は増えるが、要件(削除は確認を経る)の実現。要件側が根拠 |
| 自由順の入力 → 順序固定のウィザード | 必要 | 合意済みの流れの性質(順序を問わない)が変わる |
| 保存と公開の操作を1ボタンに統合 | 必要 | 業務上別の判断が1操作になり、誤操作の意味が変わる |
| 一括操作の廃止・分割 | 必要 | 業務の作業単位が変わる |
| 途中保存の廃止 | 再承認ではなく要件改訂 | 要件(中断再開可)に抵触。仕様の裁量の外 |
パターンは3つ。①手順の構造が変わる(順序の固定/解除、ステップの統合・分割) ②業務上の判断の単位が変わる ③要件の達成条件・例外に触れる(→要件改訂の手続きへ)。どれにも触れない変更は受注側の裁量である。
グレーな変更(例: モーダル化により一覧を見ながらの編集ができなくなる)のために、承認(事前・ブロッキング)とは別に報告(事後・非ブロッキング)のレーンを持つ。
この承認は何への承認か。 承認を取るとき・求められたとき、対象が一文で言えないなら、その承認は後で必ず拡大解釈される。