Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
用語定義
プロジェクト固有の業務用語や略語を明確に定義し、ステークホルダー間の共通理解を確立。要件定義書の読解性向上とコミュニケーションの齟齬を防止します。
🎯 概要
- 目的: プロジェクト固有の業務用語、略語、システム用語を明確に定義し、ステークホルダー間での共通理解を確立することで、要件定義書や設計書の読解性を向上させ、コミュニケーションの齟齬を防止する
- スコープ: 業務用語、ステータス・区分値、略語、システム固有用語の定義をカバーする。一般的なIT用語や広く知られた業務用語は対象外
- 推奨する実施タイミング: 要件定義の初期段階から継続的に実施。ヒアリング時に業務用語を収集し、要件定義書の作成と並行して整備する
- 関連するステークホルダー: プロジェクトマネージャー、要件定義担当者、業務担当者（顧客）、設計・開発担当者、テスト担当者
📥 重要な前提知識・インプット
- 前提知識:
- 対象業務領域の基礎知識
- 用語集の作成方法
- ドメインモデリング・概念モデリングの基礎
- 業界標準用語・規格用語の理解
- インプット:
- 業務ヒアリング議事録・インタビュー記録
- 既存システムのマニュアル・業務手順書
- 業務フロー図・業務記述書
- 顧客が使用している社内用語集（既存の場合）
- 業界標準用語集・規格文書
- データ項目定義書（既存システムの場合）
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]要件定義書 用語集
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 網羅性 | 要件定義書・設計書で使用する業務用語が漏れなく定義されているか |
| 定義の明確性 | 各用語の定義が具体的で、誤解の余地がないか |
| 一意性 | 同じ概念に対して複数の用語が使われていないか |
| 曖昧性の排除 | 文脈によって意味が変わる多義語が適切に定義されているか |
| 分類の適切性 | 用語が適切に分類されているか（業務用語、ステータス、略語等） |
| 検索性 | 五十音順またはアルファベット順で整理され、検索しやすいか |
👁️🗨️ レビュー観点:
- 業務担当者による確認: 業務用語の定義が業務実態と合致しているか
- 一貫性: 要件定義書本文と用語定義の整合性が取れているか
- 可読性: 非専門家（開発者、テスター等）が理解できる平易な定義になっているか
- 完全性: 略語に対する正式名称、英語表記等の補足情報が適切に記載されているか
🧪成果物のサンプル
# 用語集（Glossary）
## 目的
本書は、[対象業務領域]で使用する業務特有の用語を定義する。
---
## 用語一覧
| 用語 | 分類 | 定義 |
|------|------|------|
| [用語1] | 業務用語 | [定義] |
| [用語2] | 業務用語 | [定義] |
| [ステータス1] | ステータス | [説明] |
| [ステータス2] | ステータス | [説明] |
**記述例:**
| 用語 | 分類 | 定義 |
|------|------|------|
| 受注 | 業務用語 | 顧客からの注文を受け付けること |
| 引当 | 業務用語 | 受注に対して在庫を確保すること |
| バックオーダー | 業務用語 | 在庫不足で即出荷できない注文 |
| 出荷締め時刻 | 業務用語 | 当日出荷の受付締切時刻（例：15時） |
| 受注登録 | ステータス | 注文が登録された状態 |
| 引当済 | ステータス | 在庫が確保された状態 |
| 出荷完了 | ステータス | 商品が出荷された状態 |
---
## プロジェクト固有の略語
| 略語 | 正式名称 | 説明 |
|------|----------|------|
| [略語1] | [正式名称1] | [説明] |
| [略語2] | [正式名称2] | [説明] |
**記述例:**
| 略語 | 正式名称 | 説明 |
|------|----------|------|
| CRM | Customer Relationship Management | 顧客関係管理システム |
| EDI | Electronic Data Interchange | 電子データ交換 |
| SLA | Service Level Agreement | サービスレベル合意書 |
| RFP | Request For Proposal | 提案依頼書 |
---🔄 進め方・プロセス
📝 プロセス1: ヒアリング・既存資料からの用語収集
作業対象:
業務ヒアリング、既存システムの資料、業務フロー図などから、プロジェクト固有の用語を網羅的に収集する。
具体例:
- 業務ヒアリングで登場した専門用語・業界用語
- 既存システムのマニュアル・業務手順書に記載された用語
- 業務フロー図に記載されたステータス名、区分値
- 顧客が使用している略語・社内用語
- データ項目定義書のフィールド名・ドメイン名
作業原則:
- 継続的な収集: ヒアリングの都度、用語を記録し、継続的に用語集を更新する
- 曖昧性の早期発見: 同じ用語を異なる意味で使っているケースを早期に発見し、定義を統一する
- 網羅性の確保: 要件定義書の各セクション（機能要件、非機能要件、業務フロー等）から漏れなく用語を抽出する
- 優先順位付け: 頻出する用語、誤解しやすい用語を優先的に定義する
文書化の推奨表現:
- 用語候補リストの作成: 収集した用語を暫定リスト化し、定義が必要な用語を選別する
- 出典の記録: 各用語がどの資料・ヒアリングで登場したかを記録する
- 未定義項目のフラグ: 定義が未確定の用語にはフラグを付け、後続プロセスで確認する
📝 プロセス2: 用語の分類と整理
作業対象:
収集した用語を分類し、整理する。
分類の例:
- 業務用語: 業務特有の概念・行為を表す用語（例：受注、引当、出荷、バックオーダー）
- ステータス・区分値: データのステータスや分類を表す用語（例：受注登録、引当済、出荷完了、商品区分）
- 略語: 正式名称の短縮形（例：CMS = Content Management System、EC = Electronic Commerce）
- システム用語: システム固有の技術用語（例：マスタ同期、バッチジョブ、API Gateway）
- 組織固有用語: 組織内で独自に使用される用語（例：本部システム、拠点端末、営業所コード）
作業原則:
- 分類の一貫性: 同じ基準で用語を分類し、分類が曖昧な用語は複数のカテゴリに属することを許容する
- 重複の排除: 同じ概念を指す複数の用語がある場合、どれを正式用語とするか決定する
- 類義語の整理: 類似する複数の用語がある場合、使い分けの基準を明確にする
文書化の推奨表現:
- 分類別用語リスト: 分類ごとに用語を整理したリストを作成する
- 類義語・関連語の記載: 各用語に関連する類義語や対義語を記載する
📝 プロセス3: 用語の定義作成
作業対象:
各用語に対して、明確で具体的な定義を作成する。
定義作成の原則:
- 明確性: 定義は簡潔で、誤解の余地がないように記述する
- 具体性: 抽象的な表現を避け、具体的な説明を含める
- 独立性: 定義自体が他の未定義用語に依存しないようにする（または依存する用語も定義する）
- 平易性: 非専門家（開発者、テスター等）が理解できる平易な言葉で記述する
- 業務実態との整合: 業務担当者に定義内容を確認し、業務実態と合致していることを確認する
具体例:
- 良い定義: 「引当: 受注に対して在庫を確保すること。引当済の在庫は他の受注に割り当てられない」
- 悪い定義: 「引当: 在庫を確保する処理」（曖昧で、確保のタイミングや制約が不明確）
文書化の推奨表現:
- 定義の記述: 用語ごとに「用語」「分類」「定義」を表形式で整理する
- 補足情報の記載: 必要に応じて、英語表記、略語の正式名称、関連用語、使用例を記載する
- 図表の活用: 複雑な概念は図表を用いて視覚的に説明する
📝 プロセス4: 業務担当者による確認とレビュー
作業対象:
作成した用語定義を業務担当者（顧客）にレビューしてもらい、業務実態との整合性を確認する。
具体的な進め方:
- レビュー資料の準備: 用語一覧表をレビュー用に整理し、業務担当者に配布する
- レビュー会の実施: 業務担当者と用語定義をレビューし、誤りや不明確な点を指摘してもらう
- 修正・調整: 指摘事項に基づき、定義を修正・調整する
- 合意記録: レビュー結果と合意内容を記録する
レビューのポイント:
- 業務実態との整合性: 定義が業務の実態と合致しているか
- 定義の明確性: 定義が明確で、誤解の余地がないか
- 用語の一貫性: 要件定義書本文と用語定義の整合性が取れているか
- 網羅性: 重要な業務用語が漏れていないか
文書化の推奨表現:
- レビュー記録: レビュー日、参加者、指摘事項、対応内容を記録する
- 承認記録: 業務担当者の承認を得た用語定義であることを明記する
📝 プロセス5: 用語集の整備と継続的な更新
作業対象:
用語集を最終的に整備し、要件定義書に組み込むとともに、継続的に更新する仕組みを確立する。
具体的な進め方:
- 索引の作成: 五十音順またはアルファベット順の索引を作成し、用語を検索しやすくする
- 要件定義書への組み込み: 用語集を要件定義書の一部として組み込む（または別紙として参照可能にする）
- 継続的な更新: 要件定義の進行に伴い、新たな用語が登場した場合は用語集を更新する
- 変更管理: 用語の定義変更が発生した場合は、変更履歴を記録し、関係者に通知する
文書化の推奨表現:
- 索引の作成: 五十音順/アルファベット順の索引を作成する
- 分類別リスト: 分類ごとに用語をグループ化したリストを作成する
- 変更履歴: 用語の追加・修正・削除の履歴を記録する
- 参照リンク: 要件定義書本文から用語集への参照リンクを設ける
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考規格・ガイドライン:
- ISO/IEC/IEEE 29148（システム及びソフトウェア技術−ライフサイクルプロセス−要求工学）
- IPA 共通フレーム2013『要件定義プロセス』
- 『ドメイン駆動設計』（ユビキタス言語の考え方）
- 関連する他のガイド:
- ツール・テンプレート:
- 用語集テンプレート
- 業界標準用語集（該当する場合）
テンプレートサイト: 📄テンプレート集