Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
🧭実践ガイド
🐾具体的なステップ
以下に示すステップは、定義ではなく、おすすめのサンプルです。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
📘インプット
- 要件定義書
✅すること
| タスク名 | 実施内容 | 目的 |
|---|---|---|
| 要件確認 | 要件が目的・ニーズに沿っているか確認 | 正しい業務目標に沿った要件であることを保証 |
| 矛盾・曖昧さの検出 | 要件間の矛盾や曖昧さをレビューで発見・修正 | 後工程での手戻りや誤実装を防ぐ |
| レビュー・承認 | 利害関係者全員によるレビューと承認取得 | ステークホルダー全員の共通理解を確保 |
| トレーサビリティ確認 | 上位要求から要件、テスト項目までの対応を確認 | 要件変更時に影響範囲を正確に把握 |
| 記録保持 | 修正履歴・レビュー記録を保存 | 透明性のあるプロジェクト管理と責任追跡 |
🚫しないこと
| NG項目 | 説明 | なぜ問題か |
|---|---|---|
| 設計詳細確認 | 画面設計や処理ロジックの妥当性確認を含めること | 妥当性検証は業務目的に沿っているかの確認であり、設計詳細に引きずられると本来の目的が曖昧になる |
| 開発後テスト | 実装済みシステムの動作確認を行うこと | 妥当性検証は要件定義段階の確認であり、後工程作業を先取りすると効率が悪くなる |
| 部署単位評価 | 部署ごとに偏ったレビューを行うこと | 全体最適の妥当性確認ができず、他部門との齟齬が生じる |
| 承認省略 | ステークホルダー承認を取らずに要件確定すること | 誰も正式に合意していない要件は後工程でトラブルの原因となる |
❤️🔥マインドセット（プロセスへの臨み方）
- 「正確に作ること」より「正しいものを作ること」を優先する
- 関係者の理解・合意を成果と考える
- 要件は 契約書ではなくコミュニケーション手段であることを意識
- 妥当性検証は防止策ではなく保証策として位置づける
😵💫よくある失敗例
- 一部ステークホルダーしかレビューしていない → 要件漏れや誤解が発生
- 妥当性検証を設計段階で行ってしまう → 業務目的が反映されず設計に引きずられる
- 矛盾や曖昧な要件を放置 → 後工程で仕様衝突や手戻りが発生
- 承認を形式だけで済ませる → 真の理解・合意が得られずプロジェクト進行中に問題発生
- トレーサビリティが不十分 → 変更の影響範囲が追跡できず、テスト漏れ・誤実装につながる