要件確定と変更統制の強化

1. なぜ要件で迷うのか（本質）

• 要求（目的）と要件（仕様）の線引きが曖昧で、人によって解釈が違う
• 受入基準がなく、「終わった／終わっていない」の判断が割れる
• 変更の入口がバラバラで、影響評価や承認の流れが決まっていない

これは「努力不足」ではなく、定義と言語化、そして統制の不足です。標準に沿って構造化すれば、迷いは大幅に減らせます。^1,2

2. 迷わないための原則（3つ）

1. 分けて定義する： 要求→要件→受入基準を分離し、粒度を揃える（機能／非機能）。²
2. 合意を残す： 決定事項はDecision Logで「何を・なぜ・誰が・いつ」を一枚に記録。¹
3. 変更を統制する： 変更起票→影響評価(QCD)→承認(CCB)→計画反映→受入基準・トレーサ更新の一方向フローに載せる。^1,3

※ 原則は組織規模や開発手法（アジャイル／ウォーターフォール）に合わせて軽重を調整します。

3. 設計サイクル（定義 → 合意 → 統制）

3.1 定義：要求→要件→受入基準を“線”でつなぐ

• 用語・命名・粒度ルールを決める（要件ID・非機能タグ等）。
• 各要件に受入基準（Given/When/Then 等）を付与し、「判定可能」にする。²
• トレーサビリティを設計（要件↔設計↔テスト↔欠陥）。

3.2 合意：Decision Logでブレを止める

• 会議の議事録に埋もれさせず、1枚テンプレで決定事項を記録。
• 「前提／背景」「採用理由」「影響」「代替案」を短く残す。
• 誰でも参照できる場所に集約（Confluence / SharePoint 等）。¹

3.3 統制：変更を“同じ入口・同じ手順”で扱う

• 変更起票は一本化（フォーム or チケット）。
• 影響評価はQCDで数値化し、承認レベルを閾値で分岐（例：A=PMO、B=PM）。^1,3
• 承認後はWBS／ロードマップへ反映し、受入基準更新→テスト／トレーサ更新→設計&テストまで連鎖させる。

4. 最少セット（これだけで回り始める3つ）

• 要件構造ガイド： 用語集・命名規約・粒度ルール・非機能タグ・トレーサ設計
• 変更管理計画： 変更の入口、影響評価(QCD)、承認(CCB)、計画反映、AC/トレーサ更新の手順
• Decision Log＋レビュー標準： 合意記録1枚テンプレとレビュー運営要領

まずは“最少セット”で運用開始 → 実データで改善 → 標準を更新、の軽量ローンチで定着させます。

5. DreamOnの役割（伴走支援の範囲）

• 現状診断（粒度・整合・変更入口の棚卸）とギャップ可視化
• 要件構造ガイド／変更管理計画／Decision Logのテンプレ提供と初期整備
• レビュー・CCB・合意形成のファシリテーション設計と立ち上げ支援
• 運用トレーニング（要件記述・AC作成・影響評価）と定着フォロー

参考文献

1. 1. Project Management Institute (2017). PMBOK® Guide – Sixth Edition — 統合変更管理／コミュニケーション／ステークホルダー。
2. 2. ISO/IEC/IEEE 29148:2018 — 要件の明確化・一意識別・受入基準・トレーサビリティの定義。
3. 3. IPA（2023）『システム開発プロジェクト実践ガイド 要件定義編』— 要件定義完了条件と変更手順の確立。