2.2.4. 利害関係者要件の確認

1. 概要

　要件定義とは、システム開発における最も重要な初期フェーズの一つであり、その中でも「利害関係者要件の確認」は極めて重要なプロセスです。このプロセスでは、システム開発に関わる様々なステークホルダ（利害関係者）の要求を収集・整理し、それらの要件の実現可能性や妥当性を検証した上で、合意形成を図ります。

　利害関係者要件の確認は、システム開発プロジェクトの成功を左右する重要な要素であり、ここでの失敗はプロジェクト全体の失敗につながる可能性があります。適切な要件定義と利害関係者間の合意形成は、後工程での手戻りを防ぎ、効率的なシステム開発を実現するための基盤となります。

2. 詳細説明

2.1. 利害関係者（ステークホルダ）の特定と分析

　要件定義において、まず重要なのは関連するステークホルダを正確に特定することです。ステークホルダとは、システム開発によって影響を受ける、または影響を与える可能性のある個人やグループを指します。主なステークホルダには以下が含まれます：

• システム発注者・経営層（予算決定者）
• システム利用者（エンドユーザー）
• システム運用・保守担当者
• システム開発者
• 関連部門の担当者
• 外部パートナー・取引先

　ステークホルダを特定した後は、それぞれの影響力と関心度に基づく分析を行い、適切なコミュニケーション戦略を立てることが重要です。

図1: ステークホルダ分析マトリックス

2.2. 要件の実現可能性と妥当性の検証

　収集した要件に対しては、以下の観点から検証を行います：

1. 技術的実現可能性：現在の技術で実現できるか
2. コスト的実現可能性：予算内で実現できるか
3. スケジュール的実現可能性：期間内に実現できるか
4. リソース的実現可能性：必要な人材・設備等を確保できるか
5. 妥当性：ビジネス上の目的達成に貢献するか

　この検証プロセスでは、アカウンタビリティ（説明責任）が重要となります。各要件の必要性や優先度について、明確な説明ができることが求められます。

2.2.1. 機能要件と非機能要件の検証

　要件の検証においては、機能要件（システムが「何を」するか）だけでなく、非機能要件（システムが「どのように」機能を提供するか）の検証も重要です。主な非機能要件には以下があります：

• 性能要件（レスポンス時間、スループットなど）
• 信頼性要件（可用性、障害対応など）
• セキュリティ要件（認証、アクセス制御など）
• 運用・保守要件（バックアップ、監視など）
• 拡張性要件（将来的な機能追加の容易さなど）

2.3. 情報システム戦略との整合性確認

　定義された要件が組織の情報システム戦略と整合しているかを確認することも重要です。具体的には以下の点を確認します：

• 組織の中長期的なIT戦略・計画との整合性
• 既存システムとの連携・統合の観点
• セキュリティポリシーとの整合性
• 組織の業務プロセス改善目標との一致

2.4. 要件のトレーサビリティの確保

　トレーサビリティとは、要件の出所や根拠を追跡できる能力を指します。適切なトレーサビリティを確保することで、以下のメリットがあります：

• 要件の変更時に影響範囲を特定しやすくなる
• 要件の優先順位付けの根拠が明確になる
• 後工程でのテスト項目との紐付けが容易になる
• 要件の漏れや矛盾を発見しやすくなる

　トレーサビリティを確保するためには、要件管理ツールの活用や要件トレーサビリティマトリックス（RTM）の作成が効果的です。

図2: 要件トレーサビリティマトリックス（RTM）の例

2.5. 利害関係者間の合意形成

　様々なステークホルダ間で要件について合意を形成するためには、以下のアプローチが有効です：

1. ファシリテーション技術の活用：中立的な立場から議論を促進し、建設的な合意形成を支援
2. プロトタイピングやモックアップの活用：抽象的な要件を可視化することで理解を促進
3. 優先順位付け手法の活用：MoSCoW法やKJ法などを用いた要件の整理
4. 段階的な合意形成：全体像から詳細へと段階的に合意を得る

表1: 要件の優先順位付け手法比較

2.5.1. 効果的なファシリテーション手法

　要件定義におけるファシリテーションは、多様なステークホルダの意見を引き出し、建設的な議論を促進するために重要です。効果的なファシリテーション手法には以下があります：

• ブレインストーミング：自由な発想を促進し、多様なアイデアを集める
• ワールドカフェ：小グループでの議論を組み合わせて全体の合意を形成する
• 名目集団法：個人の意見を匿名で集め、バイアスを排除する
• アフィニティダイアグラム（KJ法）：多数の意見やアイデアを整理・分類する

2.6. 要件変更のルールの策定

　要件定義後も、ビジネス環境の変化や技術的制約などにより要件変更が発生することは珍しくありません。そのため、事前に要件変更のルールを策定しておくことが重要です。主なルールとして以下が挙げられます：

1. 変更提案の提出方法と必要情報
2. 変更の影響度評価プロセス
3. 承認プロセスと承認権限者
4. 変更に伴うスケジュールやコストへの影響の扱い
5. 変更履歴の管理方法

　要件変更のルールを明確にすることで、変更が生じた際の混乱を最小限に抑え、プロジェクトの進行に与える影響を管理することができます。

図3: 要件変更管理プロセスのフロー図

3. 応用例

3.1. 金融機関におけるオンラインバンキングシステム刷新

　ある金融機関でのオンラインバンキングシステム刷新プロジェクトでは、以下のように利害関係者要件の確認が行われました：

1. ステークホルダの特定と分析：
   • 経営層、営業部門、システム部門、顧客サポート部門、コンプライアンス部門、エンドユーザー（顧客）代表、外部ベンダー
   • 影響力と関心度に基づくステークホルダマップの作成
   • 各ステークホルダグループに対する適切なコミュニケーション戦略の策定
2. 要件の収集と整理：
   • 各部門へのインタビューとアンケート
   • 競合他社分析とベンチマーキング
   • 顧客フィードバックの分析
   • 機能要件と非機能要件（特にセキュリティ要件）の明確な区分
3. 実現可能性の検証：
   • 新技術（生体認証など）の導入可能性評価
   • セキュリティ要件と利便性のバランス検討
   • コスト・期間の制約内での実現可能性評価
   • 既存システムとの統合に関する技術的課題の洗い出し
4. トレーサビリティの確保：
   • 要件管理ツールの導入
   • 各要件と経営目標・規制要件との紐付け
   • 要件トレーサビリティマトリックスの作成と定期的な更新
5. 合意形成：
   • ワークショップ形式でのファシリテーション
   • プロトタイプを用いたユーザーインターフェース検証
   • MoSCoW法による要件の優先順位付け
   • 段階的リリース計画の策定と合意
6. 要件変更のルール策定：
   • 変更管理委員会の設置
   • 変更提案フォーマットの標準化
   • 変更による影響度評価方法の確立
   • 変更承認プロセスの明確化

　このプロジェクトでは、特に規制要件とユーザー利便性のバランスが課題となりましたが、適切なステークホルダ分析と優先順位付け手法の活用により、バランスの取れた要件定義が実現されました。要件変更のルールを明確に定めたことで、プロジェクト途中での規制変更にも柔軟に対応することができました。

3.2. 製造業における生産管理システムの刷新

　ある製造業企業では、既存の生産管理システムの刷新において、以下のように利害関係者要件の確認が実施されました：

1. ステークホルダの特定と分析：
   • 経営層、生産部門、品質管理部門、物流部門、購買部門、IT部門、工場現場作業者
   • 現場作業者の声を重視するため、工場ごとの代表者を選定
   • 海外拠点も含めたグローバルなステークホルダ分析
2. 実現可能性と妥当性の検証：
   • IoTセンサーとの連携可能性
   • レガシーシステムからのデータ移行の実現性
   • コスト削減目標との整合性
   • 複数拠点での運用に関する技術的・運用的課題の検証
3. 情報システム戦略との整合性確認：
   • グローバル標準化戦略との整合
   • デジタルトランスフォーメーション計画との連携
   • データ活用戦略との整合性
4. アカウンタビリティの確保：
   • 各要件に対するビジネスケースの作成
   • 投資対効果（ROI）の算出
   • 要件と経営目標との紐付けの明確化
5. 合意形成：
   • 現場作業者を含めたワークショップの実施
   • 優先順位付けのためのスコアリング手法の活用
   • プロトタイプの現場検証
   • 複数拠点の代表者によるレビュー会議

　このプロジェクトでは、グローバルな複数拠点での運用という複雑性がありましたが、各拠点の代表者を巻き込んだ合意形成プロセスにより、標準化と現場の特殊性のバランスを取った要件定義が実現されました。

4. 例題

例題1

以下は要件定義プロセスに関する問題です。

あるシステム開発プロジェクトにおいて、複数のステークホルダ間で要件の優先順位について意見の相違が生じています。プロジェクトマネージャーとして、この状況を解決するために最も適切なアプローチはどれですか？

1. 最も地位の高いステークホルダの意見を優先する
2. すべての要件を受け入れ、開発期間を延長する
3. ファシリテーション技術を活用し、要件の優先順位付けワークショップを実施する
4. プロジェクトマネージャーが独自に判断して優先順位を決定する

解答と解説

【解答】正解は c. です。ファシリテーション技術を活用し、要件の優先順位付けワークショップを実施することで、ステークホルダ間のコミュニケーションを促進し、合意形成を図ることができます。

【解説】a. は特定のステークホルダのみを優遇するため不適切、b. はプロジェクトの制約を無視している、d. はステークホルダの参画を排除しており、アカウンタビリティの観点で問題があります。

例題2

以下はトレーサビリティに関する問題です。

システム開発プロジェクトにおける要件のトレーサビリティに関する記述として、最も適切なものはどれですか？

1. トレーサビリティは開発終了後のドキュメント整理のためだけに必要である
2. トレーサビリティを確保すると、要件変更時の影響範囲を特定しやすくなる
3. トレーサビリティは技術的な要件にのみ適用すべきである
4. トレーサビリティを確保すると開発速度が低下するため、小規模プロジェクトでは不要である

解答と解説

【解答】正解は b. です。トレーサビリティを確保することで、要件変更時に影響を受ける範囲（ドキュメント、設計、コード、テストケースなど）を特定しやすくなります。

【解説】a. は誤りで、トレーサビリティは開発の全工程を通じて重要です。c. は誤りで、機能的要件と非機能的要件の両方にトレーサビリティを適用すべきです。d. も誤りで、小規模プロジェクトでもトレーサビリティは重要であり、適切なツールを使えば大きな負担にはなりません。

例題3

以下は要件変更のルールに関する問題です。

プロジェクト進行中に要件変更が提案された場合の適切な対応として、最も適切なものはどれですか？

1. すべての要件変更を無条件に受け入れる
2. 要件定義段階が終了した後は一切の変更を受け付けない
3. 事前に定めた要件変更のルールに基づいて、影響度を評価し、承認プロセスを経る
4. プロジェクトマネージャーの判断のみで要件変更の採否を決定する

解答と解説

【解答】正解は c. です。要件変更は適切なプロセスを経て検討されるべきであり、事前に定めた要件変更のルールに基づいて影響度を評価し、正式な承認プロセスを経ることが重要です。

【解説】a. はプロジェクトの制約（スコープ、コスト、スケジュール）を無視しており不適切です。b. は現実的ではなく、ビジネス環境の変化に対応できません。d. はステークホルダの参画を排除しており、アカウンタビリティの観点で問題があります。

No.	確認項目	確認ポイント	確認	備考
ステークホルダ関連
1	ステークホルダの特定	プロジェクトに関わるすべてのステークホルダが特定され、リスト化されているか	□
2	ステークホルダ分析	影響力と関心度に基づくステークホルダ分析が実施されているか	□
3	ステークホルダからの要件収集	すべての主要ステークホルダから要件が収集されているか	□
要件の内容関連
4	要件の明確さ	要件は明確かつ検証可能な形で文書化されているか	□
5	要件の網羅性	機能要件と非機能要件の両方が網羅されているか	□
6	要件間の整合性	要件間の依存関係や矛盾点は解消されているか	□
実現可能性関連
7	技術的実現可能性	現在の技術で実現可能か、技術的リスクは評価されているか	□
8	コスト的実現可能性	予算内で実現できるか、コスト見積もりは妥当か	□
9	スケジュール的実現可能性	期間内に実現できるか、スケジュールは現実的か	□
整合性・トレーサビリティ関連
10	情報システム戦略との整合性	要件は組織の情報システム戦略と整合しているか	□
11	トレーサビリティの確保	要件のトレーサビリティは確保されているか（RTMの作成など）	□
12	セキュリティポリシーとの整合性	要件は組織のセキュリティポリシーと整合しているか	□
合意形成・承認関連
13	優先順位付け	要件の優先順位付けが適切に行われ、合意されているか	□
14	ステークホルダ間の合意	主要なステークホルダ間で要件について合意が形成されているか	□
15	正式な承認	要件定義書は正式に承認されているか（署名等）	□
変更管理関連
16	要件変更のルール	要件変更のルールは明確に定義されているか	□
17	変更管理プロセス	変更管理のプロセスとフローが確立されているか	□
18	変更履歴の管理	要件の変更履歴を管理する仕組みはあるか	□
アカウンタビリティ関連
19	要件の根拠	各要件の必要性や根拠が明確に説明できるか	□
20	責任の明確化	各要件の責任者（オーナー）は明確になっているか	□

表2: 利害関係者要件確認のチェックリスト

5. まとめ

　利害関係者要件の確認は、要件定義の中核を成す重要なプロセスです。このプロセスでは、以下の点が特に重要となります：

1. 適切なステークホルダの特定と分析
2. 要件の実現可能性、妥当性、情報システム戦略との整合性の検証
3. アカウンタビリティ（説明責任）の確保
4. 要件のトレーサビリティ（追跡可能性）の確立
5. 効果的なファシリテーションによる合意形成
6. 明確な要件変更のルールの策定と運用

　これらのポイントを押さえた要件定義プロセスを実施することで、システム開発プロジェクトの成功確率を高めることができます。要件定義は単なる文書作成ではなく、プロジェクトの方向性を定め、関係者間の共通理解を形成するための重要な活動であることを忘れてはなりません。

　適切な利害関係者要件の確認を行うことで、後工程での手戻りを最小化し、効率的かつ効果的なシステム開発が可能となります。また、利害関係者間の信頼関係構築にも寄与し、プロジェクト全体の円滑な進行を支援します。