Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
要件定義 文書情報
要件定義書の文書管理情報を適切に記載し、品質管理と関係者間の情報共有を円滑化にします。
🎯 概要
- 目的: 要件定義書の文書管理情報（文書名、版数、改訂履歴、目的、対象読者、スコープ、用語定義、参照資料等）を明確に記載し、文書の品質管理と関係者間の情報共有を円滑にする
- スコープ: 文書管理情報、文書の目的・対象読者・スコープ、用語定義、参照資料をカバーする。個別の要件内容（機能要件、非機能要件等）は対象外
- 推奨する実施タイミング: 要件定義書の作成開始時に骨子を作成し、要件定義プロセス全体を通じて継続的に更新する
- 関連するステークホルダー: プロジェクトマネージャー、要件定義担当者、顧客担当者、品質管理担当者、開発チーム
📥 重要な前提知識・インプット
- 前提知識:
- 文書管理の基礎知識（版管理、改訂履歴、承認プロセス）
- プロジェクト文書体系の理解（計画書、要件定義書、設計書等の関係）
- 用語定義・用語集の作成方法
- ステークホルダー分析の基礎
- インプット:
- プロジェクト計画書（プロジェクト名、目的、スコープ等）
- 提案書・契約書（対象範囲、成果物定義等）
- 組織の文書管理規程・テンプレート
- 既存システムの関連文書（現行システム仕様書、業務フロー等）
- ステークホルダー一覧（顧客担当者、プロジェクトメンバー等）
- プロジェクト固有の用語リスト
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]要件定義書 文書情報 - 必須要素: 文書管理情報（文書名、版数、改訂履歴）、文書の目的、対象読者、スコープ、用語定義、参照資料
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 文書管理情報の完全性 | 文書名、版数、最終更新日、最終更新者が記載されているか |
| 改訂履歴の適切性 | 改訂日、版数、改訂内容、改訂者が記録されているか |
| 目的の明確性 | 文書の目的が具体的かつ明確に記載されているか |
| 対象読者の網羅性 | 想定される全ての読者（ステークホルダー）が列挙されているか |
| スコープの明確性 | 対象範囲と対象外が明確に区別されているか |
| 用語定義の適切性 | プロジェクト固有の用語、略語が定義されているか |
| 参照資料の完全性 | 参照した全ての資料が版数・作成日とともに記載されているか |
👁️🗨️ レビュー観点:
- 文書管理の適切性: 版管理、改訂履歴が適切に記録され、追跡可能か
- 情報の明確性: 目的、対象読者、スコープが明確で、誤解の余地がないか
- 用語の一貫性: 用語定義が適切で、文書全体で一貫して使用されているか
- トレーサビリティ: 参照資料が適切に記載され、元情報を追跡可能か
- 関係者への配慮: 対象読者に必要な前提知識・参照情報が提供されているか
🧪成果物のサンプル
# 文書情報
## 文書管理情報
文書管理情報は、本書の更新記録である。
外部システム等で正確に記録し、リンク等を指定できるなら、本書に内容を明記する必要はない。
ただしそれらの情報には、本書と同様のアクセス権を付与しなければならない。
| 項目 | 内容 |
| :--------- | :----------------------------------------- |
| **文書名** | [プロジェクト名] 要件定義書 |
| **版数** | 1.0 |
| **最終更新日** | 2025年12月06日 |
| **最終更新者** | [作成者名] ([所属部署]) |
### 改訂履歴
| 版数 | 改訂日 | 改訂者 | 改訂内容 |
|------|--------|--------|----------|
| 1.0 | 2025-10-01 | 山田太郎 | 初版作成 |
| 1.1 | 2025-11-15 | 山田太郎 | 非機能要件の追加 |
| 2.0 | 2025-12-18 | 佐藤花子 | ステークホルダーレビュー結果を反映 |
---
## 文書の目的
本書は、[プロジェクト名]における要件定義の内容を記載し、ステークホルダー間での合意事項を明確化することを目的とする。
**記述例:**
本文書は、販売管理システム刷新プロジェクトにおける要件定義の内容を記載し、発注者と受注者間での合意事項を明確化することを目的とする。本文書に記載された要件は、後続の設計・開発フェーズにおける基準となる。
---
## 対象読者
- 顧客担当者（業務部門、情報システム部門）
- プロジェクトマネージャー
- システムアーキテクト
- 開発リーダー、開発者
- テスト担当者
- 運用担当者
---
## スコープ
本プロジェクトの対象範囲は、プロジェクト計画書を参照する。
---
## 用語定義
| 用語 | 分類 | 定義 |
|------|------|------|
| 受注 | 業務用語 | 顧客からの注文を受け付けること |
| 引当 | 業務用語 | 受注に対して在庫を確保すること |
| バックオーダー | 業務用語 | 在庫不足で即出荷できない注文 |
| 出荷締め時刻 | 業務用語 | 当日出荷の受付締切時刻（例：15時） |
| 受注登録 | ステータス | 注文が登録された状態 |
| 引当済 | ステータス | 在庫が確保された状態 |
| 出荷完了 | ステータス | 商品が出荷された状態 |
---
## 4. 参照資料
本書作成時に参照した資料を記載する。
**記述例:**
| No. | 資料名 | 版数 | 作成日 | 作成者 |
|-----|--------|------|--------|--------|
| 1 | 現行システム業務フロー | v1.0 | 2025-10-15 | 業務部 |
| 2 | 業務改善提案書 | v2.1 | 2025-11-20 | コンサルティング会社 |
| 3 | システム化要望一覧 | v1.5 | 2025-12-01 | プロジェクト推進室 |
---🔄 進め方・プロセス
📝 プロセス1: 文書管理情報の作成
作成対象:
要件定義書の基本的な文書管理情報（メタデータ）を定義する。
具体例:
- 文書名: プロジェクト名を含む正式な文書名を決定する
- 版数: 初版は「1.0」、レビュー前の暫定版は「0.x」等のルールを決める
- 最終更新日・最終更新者: 文書更新の都度、記録する
- 改訂履歴: 主要な変更点を記録する（細かい誤字修正等は除く場合もある）
作成原則:
- 版管理ルールの明確化: 組織の文書管理規程に従い、版番号の付与ルールを明確にする
- 更新の追跡可能性: 誰が、いつ、何を変更したかが追跡できるようにする
- 外部システムとの連携: SharePoint、Confluence等の文書管理システムを使用する場合、そのリンクを明記する
文書化の推奨表現:
- 表形式での整理: 文書管理情報は表形式で整理し、一目で確認できるようにする
- 改訂履歴の別紙化: 改訂履歴が長くなる場合は、別紙に分離し、リンクで参照可能にする
- 承認記録: 必要に応じて承認者・承認日の記録欄を設ける
📝 プロセス2: 文書の目的・対象読者・スコープの明確化
作成対象:
文書を作成する目的、想定読者、対象範囲を明確に定義する。
具体例:
- 文書の目的: 「〇〇プロジェクトにおける要件定義の内容を記載し、ステークホルダー間での合意事項を明確化する」
- 対象読者: 顧客担当者、PM、アーキテクト、開発者、テスト担当者、運用担当者等を列挙
- スコープ: プロジェクト計画書に記載された対象範囲を参照し、必要に応じて補足する
作成原則:
- 目的の具体性: 抽象的な表現を避け、「何のために」「誰が使うのか」を明確にする
- 読者の網羅性: 想定される全てのステークホルダーを漏れなく列挙する
- スコープの明確化: 対象範囲と対象外を明確に区別し、誤解を防ぐ
文書化の推奨表現:
- 目的の記述例提示: 具体的なプロジェクト名・システム名を含めた記述例を示す
- 読者のリスト化: 箇条書きで対象読者を列挙する
- スコープの参照: プロジェクト計画書等へのリンクを明記し、重複記載を避ける
📝 プロセス3: 用語定義の整備
作成対象:
プロジェクト固有の用語、略語、業務用語を定義する。
具体例:
- プロジェクト固有の略語（例: CMS = Content Management System）
- 業務用語（例: 発注伝票、在庫引当、出荷指示）
- システム固有の用語（例: マスタ同期、バッチジョブ、API Gateway）
- 組織固有の用語（例: 本部システム、拠点端末）
作成原則:
- 一般的な用語は除外: 広く知られた用語（例: サーバー、データベース）は定義不要
- 曖昧性の排除: 同じ用語が複数の意味を持つ場合は、本文書での定義を明確にする
- 用語集の別紙化: 用語数が多い場合は、別紙の用語集として管理する
文書化の推奨表現:
- 表形式での整理: 用語・読み・定義を表形式で整理する
- 五十音順/アルファベット順: 検索しやすいように並び順を統一する
- 既存用語集の参照: 組織で共通の用語集がある場合は、それを参照する
📝 プロセス4: 参照資料の整理
作成対象:
要件定義書作成時に参照した資料を一覧化する。
具体例:
- プロジェクト計画書、提案書、契約書
- 現行システム仕様書、業務フロー図
- 業務改善提案書、ユーザーヒアリング記録
- 関連法令・規制、業界標準ガイドライン
作成原則:
- トレーサビリティの確保: 参照資料を明記し、要件の根拠を追跡可能にする
- 版数・作成日の記録: 参照した資料の版数・作成日を記録し、最新版との整合性を確認できるようにする
- アクセス性の確保: 参照資料の保管場所・リンクを明記し、関係者がアクセスできるようにする
文書化の推奨表現:
- 表形式での整理: No.、資料名、版数、作成日、作成者、保管場所を表形式で整理する
- カテゴリ分類: 資料が多い場合は、カテゴリ別（プロジェクト関連、業務関連、技術関連等）に分類する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考規格・ガイドライン:
- IPA 共通フレーム2013『要件定義プロセス』
- ISO/IEC/IEEE 29148（システム及びソフトウェア技術−ライフサイクルプロセス−要求工学）
- PMBOK®ガイド『プロジェクト文書管理』
- 関連する他のガイド:
- 組織の文書管理規程:
- 組織の文書管理規程・版管理ルールを参照する
- ドキュメント管理システム（SharePoint、Confluence等）の利用ガイド
テンプレートサイト: 📄テンプレート集