Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
🧭実践ガイド
🐾具体的なステップ
以下に示すステップは、定義ではなく、おすすめのサンプルです。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
実際の現場では、成果物=プロセスの目的を達成できるように、適切にアレンジしてください。
📘インプット
- ToBe業務フロー
- 業務一覧
- 業務ルール一覧
- 制約条件一覧
- 用語集
✅すること
| タスク名 | 目的 | タスク内容（詳細） |
|---|---|---|
| 業務要件の分析 | 業務要件の意図を正しく理解し、機能化の前提を整える | ・業務要件一覧を精査し、「誰が・何のために・どのような処理を行いたいのか」を明確化する。 ・業務ルール・ToBeフローを参照し、システム化すべき処理単位を抽出する。 ・システム化の目的・価値（削減時間、ミス防止、統制強化など）を把握する。 |
| システム化対象の明確化 | 業務とシステムの境界を定義し、責任範囲を明確にする | ・業務フロー上で「人が行う処理」と「システムが行う処理」を区分する。 ・業務担当、他システム、外部サービスとのインタフェースを洗い出す。 ・非システム化（除外）範囲を明記し、関係者と確認する。 |
| 機能の抽出 | 業務要件を実現するための機能候補を洗い出す | ・業務フロー、業務ルールごとに「必要な操作」「処理結果」「トリガー（イベント）」を整理する。 ・入力系／処理系／出力系の観点で網羅的に抽出する。 ・外部システム連携やバッチ処理も含める。 |
| 機能の分類・階層化 | 類似機能を整理し、理解しやすい構造を作る | ・抽出した機能を「業務プロセス単位」または「システム構成単位」でグルーピング。 ・上位機能（機能グループ）と下位機能（個別機能）を整理。 ・階層構造（例：機能ツリー／DFDレベル0→1）として可視化。 |
| 機能一覧の作成 | 関係者が共通認識を持てるように文書化する | ・各機能に対して以下の情報を整理： - 機能ID／名称／概要／主担当（業務側）／対応業務要件ID - 入出力概要／主要処理内容／優先度／対象システム ・必要に応じて機能間の依存関係・関連図を付与。 |
| レビューと合意形成 | 関係者間の理解齟齬を防ぎ、合意を形成する | ・業務担当者・開発側（設計者） ・PMによる合同レビューを実施。 ・トレーサビリティ（業務要件⇔機能）を確認。 ・曖昧な表現や重複機能を排除し、承認記録を残す。 |
🚫しないこと
| NG項目 | 説明 | なぜ問題か |
|---|---|---|
| 設計レベルの詳細化 | 入出力項目や画面構成まで書き込む | 基本設計との境界が曖昧になり、要件定義の責務を超える |
| 技術選定の先行決定 | 要件段階で実装手段を確定する | 技術的制約変更時に巻き戻しが発生する |
| 現行システムの単純踏襲 | AsIs機能を流用してしまう | 課題が温存され、ToBe業務が実現できない |
| 検討の独断進行 | 開発側だけで機能を決める | 実務に合わない機能となり、後戻りコスト増 |
| 機能の重複・命名不統一 | 部署ごとに異なる粒度・用語で整理 | 誤解や設計の二重実装が発生する |
❤️🔥マインドセット（プロセスへの臨み方）
- 「業務を支援する最小限の機能を定義する」
- 「システムの目的は業務効率化・品質向上である」
- 「機能は業務要件を実現する手段である」
- 「技術や手段ではなく“なぜ必要か”を起点に考える」
- 「関係者全員の共通理解を優先する」
😵💫よくある失敗例
- 業務担当者のレビュー不足 → システムが現場運用に合わない
- 粒度が不揃い → 基本設計で再整理が必要になり手戻り
- 画面単位で定義 → 要件定義の抽象度を逸脱
- 業務要件とのトレーサビリティ欠如 → 要件漏れ・重複機能が発生
- 用語の不統一 → 関係者間で誤解が生じる