1. 概要
システム要件定義は、システム開発の初期段階で実施される重要なプロセスです。このプロセスでは、開発するシステムが満たすべき要件を明確にし、関係者間で合意を形成します。システム要件定義では主に「システムの境界の定義」「システム要件の定義」「システム要件の評価」「システム要件の共同レビュー」という4つの主要タスクを実施します。
これらのタスクを適切に実行することで、システム開発の方向性が明確になり、後工程での手戻りを減らすことができます。また、顧客や利用者の期待と合致したシステムを構築するための基盤となるため、システム開発の成功に直結する極めて重要なプロセスです。
flowchart TD
A[システム要件定義] --> B[システムの境界の定義]
B --> C[システム要件の定義]
C --> D[システム要件の評価]
D --> E[システム要件の共同レビュー]
style A fill:#f9f9f9,stroke:#333,stroke-width:2px
style B fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style C fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style D fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style E fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
図1: システム要件定義の4つのタスクの関係図
2. 詳細説明
2.1. システムの境界の定義
システムの境界を定義するとは、開発対象となるシステムの範囲を明確にすることです。具体的には、以下の点を明らかにします。
- システムが担当する業務の範囲
- 外部システムとの接点（インターフェース）
- 人間とシステムの役割分担
- 自動化する範囲と手動で行う部分の区別
この定義により、システムが何を行うべきか、何を行わないのかが明確になります。また、システムの責任範囲を明確にすることで、ステークホルダー間の誤解を防ぎ、適切な見積りや計画立案の基礎となります。
例えば、病院の電子カルテシステムを開発する場合、「診療記録の管理」「処方箋の発行」「検査結果の管理」は境界内としますが、「会計処理」は既存の会計システムとの連携部分のみを境界内とし、会計システム自体は境界外と定義するといったことを行います。
flowchart LR
subgraph SB[開発対象システムの範囲]
A[サブシステムA]
B[サブシステムB]
C[サブシステムC]
end
SB -- インターフェース1 --> D[外部システムX]
SB -- インターフェース2 --> E[外部システムY]
style SB fill:#e6f7ff,stroke:#0099cc,stroke-width:2px
style A fill:#d4edff,stroke:#0066cc,stroke-width:1px
style B fill:#d4edff,stroke:#0066cc,stroke-width:1px
style C fill:#d4edff,stroke:#0066cc,stroke-width:1px
style D fill:#f2f2f2,stroke:#999999,stroke-width:1px
style E fill:#f2f2f2,stroke:#999999,stroke-width:1px
図2: システム境界定義の概念図
2.2. システム要件の定義
システム要件の定義では、システムが満たすべき要件を具体的に定義します。システム要件は通常、以下のカテゴリに分類されます。
- 機能要件：システムが提供すべき機能
- 非機能要件：性能、信頼性、使用性、セキュリティなど
- 制約条件：法的要件、標準規格、既存システムとの互換性など
- ビジネス要件：ビジネス目標、優先順位など
システム要件定義では、各要件を曖昧さのない形で文書化し、要件間の矛盾や重複がないかを確認します。また、要件の優先順位付けを行い、開発リソースの効果的な配分の基礎となる情報を提供します。
例えば、ECサイトのシステム要件として「商品検索機能では、商品名、カテゴリ、価格帯による複合検索が可能であること」（機能要件）、「ピーク時（1万アクセス/分）でも検索結果を2秒以内に表示できること」（非機能要件）などを明確に定義します。
| 要件の種類 | 説明 | 例 |
|---|---|---|
| 機能要件 | システムが提供すべき機能 |
・ユーザー認証機能 ・データ検索機能 ・レポート出力機能 |
| 非機能要件 | 品質特性に関する要件 |
・応答時間（3秒以内） ・可用性（99.9%） ・同時接続ユーザー数（500人） |
| 制約条件 | 開発・運用上の制約 |
・特定のフレームワーク使用 ・既存システムとの互換性 ・法規制への準拠 |
| ビジネス要件 | ビジネス目標に関する要件 |
・コスト削減目標 ・業務効率化目標 ・市場投入時期 |
表1: システム要件の種類と例
2.3. システム要件の評価
定義されたシステム要件は、適切に評価される必要があります。評価の主なポイントは以下の通りです。
- 完全性：必要な要件がすべて含まれているか
- 整合性：要件間に矛盾がないか
- 実現可能性：技術的・経済的に実現可能か
- 検証可能性：要件が満たされたかどうかを検証できるか
- 明確性：誤解なく解釈できるか
- トレーサビリティ：上位の要求とのつながりが明確か
評価の過程では、ステークホルダーとの対話を通じて要件の妥当性を確認し、必要に応じて修正や詳細化を行います。
例えば、「システムは高速であること」という要件は明確性に欠けるため、「通常使用時のレスポンスタイムは1秒以内、ピーク時でも3秒以内であること」のように、測定可能で検証可能な表現に改善します。また、「全ての取引履歴を無期限に保存する」という要件は、技術的・コスト的な実現可能性の観点から評価し、「直近5年分のデータをオンラインで即時検索可能とし、それ以前のデータはアーカイブから24時間以内に取得可能とする」などの現実的な要件に修正することがあります。
graph TD
A[システム要件の評価] --> B[完全性]
A --> C[整合性]
A --> D[実現可能性]
A --> E[検証可能性]
A --> F[明確性]
A --> G[トレーサビリティ]
B --> B1[すべての必要要件が含まれているか]
C --> C1[要件間に矛盾がないか]
D --> D1[技術的・経済的に実現可能か]
E --> E1[要件達成を検証できるか]
F --> F1[誤解なく解釈できるか]
G --> G1[上位要求との関連が明確か]
style A fill:#f9f9f9,stroke:#333,stroke-width:2px
style B fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style C fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style D fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style E fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style F fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style G fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
図３：システム要件評価の主なポイント
2.4. システム要件の共同レビュー
システム要件の共同レビューは、定義された要件をステークホルダー（発注者、利用者、開発者など）が一堂に会して確認するプロセスです。主な目的は以下の通りです。
- 要件の正確性と完全性の確認
- 関係者間の認識の統一
- 見落としや誤解の早期発見
- 公式な承認の取得
共同レビューでは、要件の優先順位や相互依存関係についても議論し、システム開発の方向性について合意を形成します。このプロセスを経て承認された要件は、次工程であるシステム設計の基礎となります。
例えば、金融システムの共同レビューでは、業務部門、IT部門、コンプライアンス部門、セキュリティ部門など多様な視点を持つステークホルダーが参加し、それぞれの立場から要件の妥当性を検討します。ここで見落としていた法規制対応の要件が発見されたり、複数の部門間で要件の解釈に相違があることが判明したりすることで、要件の質を高めることができます。
graph TD
A[システム要件の共同レビュー] --- B[発注者/経営層]
A --- C[エンドユーザー/業務部門]
A --- D[開発チーム]
A --- E[IT運用部門]
A --- F[品質保証部門]
A --- G[セキュリティ部門]
A --- H[コンプライアンス部門]
style A fill:#f9f9f9,stroke:#333,stroke-width:2px
style B fill:#ffe6cc,stroke:#ff9900,stroke-width:1px
style C fill:#ffe6cc,stroke:#ff9900,stroke-width:1px
style D fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style E fill:#e6f2ff,stroke:#0066cc,stroke-width:1px
style F fill:#e6ffcc,stroke:#66cc00,stroke-width:1px
style G fill:#e6ffcc,stroke:#66cc00,stroke-width:1px
style H fill:#ffe6e6,stroke:#cc0000,stroke-width:1px
図４：システム要件の共同レビューに参加するステークホルダー
3. 応用例
3.1. 銀行システムのリニューアルプロジェクト
ある銀行のオンラインバンキングシステムのリニューアルでは、システムの境界定義において、モバイルアプリとウェブインターフェースの両方をカバーするが、ATMシステムとの連携は別プロジェクトとして扱うことを明確にしました。システム要件定義では、セキュリティ関連の非機能要件を最優先事項とし、多要素認証やリアルタイム不正検知機能などの要件を詳細に定義しました。
システム要件の評価では、特に性能要件（24時間365日の可用性、ピーク時のレスポンスタイム）と法規制要件（個人情報保護法、金融取引関連法規への準拠）の実現可能性を慎重に検討しました。
共同レビューには、銀行の経営層、IT部門、顧客代表、セキュリティ専門家、開発ベンダーが参加し、特に災害時の業務継続計画とその技術的実現方法について活発な議論が行われました。このレビューの結果、当初見落とされていた災害時のデータセンター切り替えにおける認証情報の同期に関する要件が追加され、システムの堅牢性が向上しました。
3.2. 製造業における生産管理システム開発
自動車部品メーカーの生産管理システム開発では、システムの境界定義において、生産計画、在庫管理、品質管理を含むが、会計システムとは明確なインターフェースを介して連携することを決定しました。
システム要件定義では、既存の紙ベースのプロセスを電子化する際の業務フロー変更を詳細に定義し、現場作業者のユーザビリティを重視した要件を多く盛り込みました。また、将来の海外工場への展開を視野に入れ、多言語対応や時差を考慮した設計要件も定義されました。
システム要件の評価段階では、特に工場のネットワーク環境下での応答性能と、生産ラインの機器との連携における信頼性の検証に重点が置かれました。一部の要件は、現実的な技術制約を考慮して見直されました。例えば、「すべての生産ラインの状態をリアルタイムで監視する」という要件は、工場内の無線LAN環境の制約から「主要な生産指標は30秒ごとに更新」という要件に修正されました。
共同レビューでは、生産現場のベテラン作業者も参加し、実際の業務フローとシステム要件の整合性を確認することで、現場に受け入れられるシステムとなるよう調整が行われました。この過程で、現場作業者の知識や経験が組み込まれ、理論上は効率的だが実務では使いにくい機能の改善が図られました。
graph TD
subgraph 生産管理システム[開発対象: 生産管理システム]
A[生産計画モジュール]
B[在庫管理モジュール]
C[品質管理モジュール]
end
subgraph 外部システム[既存/外部システム]
D[会計システム]
E[人事システム]
F[調達システム]
end
A --> D
B --> D
B --> F
C --> E
style 生産管理システム fill:#e6f7ff,stroke:#0099cc,stroke-width:2px
style 外部システム fill:#f2f2f2,stroke:#999999,stroke-width:2px
style A fill:#d4edff,stroke:#0066cc,stroke-width:1px
style B fill:#d4edff,stroke:#0066cc,stroke-width:1px
style C fill:#d4edff,stroke:#0066cc,stroke-width:1px
style D fill:#ffe6cc,stroke:#ff9900,stroke-width:1px
style E fill:#ffe6cc,stroke:#ff9900,stroke-width:1px
style F fill:#ffe6cc,stroke:#ff9900,stroke-width:1px
図５：製造業の生産管理システム – システム境界の例
4. 例題
例題1
問題： システム要件定義における「システムの境界の定義」について、適切な記述はどれか。
- システムの境界は、プログラムモジュール間のインターフェースを詳細に定義したものである
- システムの境界定義は、テスト工程で実施するべきタスクである
- システムの境界定義では、開発対象となるシステムと外部システムとの接点を明確にする
- システムの境界は、システム設計完了後に決定するべきものである
【解答】c. システムの境界定義では、開発対象となるシステムと外部システムとの接点を明確にする
【解説】システムの境界定義は、開発対象システムの範囲と外部との接点を明確にするタスクです。a.はモジュール設計レベルの話で境界定義より詳細な内容、b.とd.はタイミングが誤っており、境界定義はシステム要件定義の段階（テストや設計より前）に行うべきものです。
例題2
問題： あるWEBショッピングシステムの開発プロジェクトでシステム要件定義を行っている。以下の記述のうち、「システム要件の評価」のタスクとして最も適切なものはどれか。
- 顧客の注文処理機能の画面遷移図を作成した
- 決済システムとの連携方法について技術的な実現可能性を検証した
- データベースのテーブル設計を行った
- システムのクラス図を作成した
【解答】b. 決済システムとの連携方法について技術的な実現可能性を検証した
【解説】システム要件の評価では、定義された要件の実現可能性や整合性などを評価します。決済システムとの連携方法の技術的実現可能性を検証する作業は、要件の実現可能性を評価するタスクに該当します。a, c, dはいずれも設計工程で行うタスクであり、システム要件定義段階では行いません。
例題3
問題： システム要件の共同レビューに関する記述として、最も適切なものはどれか。
- 開発部門内の技術者だけで実施し、効率的な開発方法を決定する
- プロジェクトマネージャーと顧客担当者のみで行い、その結果を他のステークホルダーに報告する
- 主要なステークホルダーが参加し、要件の正確性と完全性を確認して合意を形成する
- テスト担当者のみで実施し、テスト可能性の観点から要件を評価する
【解答】c. 主要なステークホルダーが参加し、要件の正確性と完全性を確認して合意を形成する
【解説】システム要件の共同レビューは、顧客、利用者、開発者など主要なステークホルダーが参加して行うべきものです。目的は要件の正確性・完全性の確認と関係者間の認識統一です。特定の役割の人だけで行うのではなく、多様な視点からレビューすることで、要件の品質を高めることができます。
例題4
問題： 以下の要件のうち、非機能要件に分類されるものはどれか。
- 売上データをPDF形式でダウンロードできること
- システムは平均応答時間が2秒以内であること
- ユーザーがパスワードを忘れた場合にリセットできる機能を提供すること
- システムは従業員マスタを参照して権限管理を行うこと
【解答】b. システムは平均応答時間が2秒以内であること
【解説】非機能要件は、システムの品質特性に関する要件です。b.の応答時間は性能に関する要件であり、非機能要件に分類されます。a.はファイル出力機能、c.はパスワードリセット機能、d.は権限管理機能であり、いずれも機能要件に分類されます。
例題５
問題：以下の要件を「機能要件」と「非機能要件」に分類してください。
- 商品の在庫数をリアルタイムで表示できること
- システムの計画メンテナンス以外の稼働率は99.9%以上であること
- ユーザーは検索結果をCSV形式でダウンロードできること
- システムは同時に1000ユーザーのアクセスに対応できること
- 管理者は新しいユーザーアカウントを作成・編集・削除できること
- 災害発生時、データ復旧は4時間以内に完了すること
- ユーザーはパスワードを90日ごとに変更するよう促されること
- システムは標準的なブラウザ（Chrome、Firefox、Safari、Edge）で動作すること
機能要件: 1, 3, 5, 7
非機能要件: 2, 4, 6, 8
5. まとめ
システム要件定義は、システム開発の方向性を決定づける重要なプロセスです。システム要件定義の主要なタスクは以下の4つです。
- システムの境界の定義：開発対象となるシステムの範囲と外部との接点を明確にする
- システム要件の定義：機能要件、非機能要件、制約条件などを具体的に定義する
- システム要件の評価：定義された要件の完全性、整合性、実現可能性などを評価する
- システム要件の共同レビュー：ステークホルダーが要件を確認し、合意を形成する
これらのタスクを適切に実施することで、顧客のニーズを満たすシステムの開発基盤が確立されます。要件定義の品質はシステム開発全体の成否を左右するため、十分な時間と労力をかけて実施することが重要です。また、要件の明確化と関係者間の合意形成により、後工程での手戻りを減らし、プロジェクトの効率的な進行に貢献します。
システム要件定義は単なる文書作成作業ではなく、ステークホルダー間のコミュニケーションを通じて、システムの目的や範囲に対する共通理解を構築するプロセスです。この段階で丁寧に合意形成を行うことで、開発の後工程でのリスクを大幅に低減することができます。また、システム要件定義で作成された文書は、その後の設計、実装、テスト、運用保守の各工程における指針となり、プロジェクト全体を通じて参照される重要な成果物となります。
情報処理技術者として、システム要件定義の各タスクの目的と意義を理解し、実践できることが求められます。特に、多様なステークホルダーの要求を適切に引き出し、整理し、評価するスキルは、システム開発の成功に不可欠です。
mindmap
root((システム要件定義))
システムの境界の定義
業務の範囲
外部システムとの接点
人間とシステムの役割分担
自動化する範囲と手動部分
システム要件の定義
機能要件
非機能要件
制約条件
ビジネス要件
システム要件の評価
完全性
整合性
実現可能性
検証可能性
明確性
トレーサビリティ
システム要件の共同レビュー
正確性と完全性の確認
関係者間の認識統一
誤解の早期発見
公式な承認の取得
図６：システム要件定義の４つのタスクと主なポイント