1. 概要
1.1. 要求分析とは
要求分析とは、システム開発の初期段階において、ユーザーやステークホルダーの要求を明確にし、整理・分析するプロセスです。これはシステム開発の基盤となる重要な工程であり、要求工学（Requirements Engineering）の中核を成す活動です。適切な要求分析が行われなければ、後工程でのやり直しや、完成したシステムがユーザーのニーズを満たさないという深刻な問題が生じる可能性があります。
1.2. 要求分析の重要性
要求分析は、以下の理由から非常に重要視されています：
- 開発の初期段階で問題を発見することによるコスト削減
- ステークホルダー間の共通理解の形成
- 適切なシステム化範囲の決定
- プロジェクトの成功確率の向上
- ユーザーニーズ調査の結果を正確にシステム要件へ反映
2. 詳細説明
2.1. 要求分析の基本的な手順
要求分析は一般的に以下の手順で進められます：
- 要求項目の洗い出し：ステークホルダーからの要求を漏れなく収集する
- 分析：収集した要求を精査し、整理・分類する
- システム化ニーズの整理：実現すべき要求を明確化する
- 前提条件や制約条件の整理：システム開発における制約や前提を明確にする
これらの手順を適切に実施することで、システム開発の基盤となる要求を確実に捉えることができます。
flowchart TD
A[要求項目の洗い出し] -->|ステークホルダーからの\n要求収集| B[分析]
B -->|要求の整理・分類| C[システム化ニーズの整理]
C -->|実現すべき要求の明確化| D[前提条件や制約条件の整理]
D -->|要求仕様書作成| E[要件定義]
style A fill:#d9f0ff,stroke:#0066cc,stroke-width:2px
style B fill:#d9f0ff,stroke:#0066cc,stroke-width:2px
style C fill:#d9f0ff,stroke:#0066cc,stroke-width:2px
style D fill:#d9f0ff,stroke:#0066cc,stroke-width:2px
style E fill:#f0f0f0,stroke:#666666,stroke-width:2px,stroke-dasharray: 5 5
subgraph 主な手法
A1[インタビュー\nアンケート\n業務観察\nワークショップ] -.- A
B1[要求の分類\n優先順位付け\n現状分析] -.- B
C1[現状指向型アプローチ\n目的指向型アプローチ\n課題定義] -.- C
D1[予算的制約\n技術的制約\n法的・規制上の制約\nスケジュール的制約] -.- D
end
subgraph 成果物
A2[要求一覧] -.- A
B2[要求分析書] -.- B
C2[システム化ニーズ定義書] -.- C
D2[制約条件一覧] -.- D
E2[要求仕様書] -.- E
end
図1：要求分析の手順フロー図
2.2. 要求項目の洗い出し
要求項目の洗い出しでは、以下のような手法を用いてユーザーや関係者から要求を収集します：
- インタビュー
- アンケート
- ワークショップ
- 既存システムの分析
- 業務観察
- ブレインストーミング
この段階では、ユーザーニーズ調査を通じて、漏れのないように要求を収集することが重要です。また、暗黙知となっている要求や、ユーザー自身も気づいていない潜在的なニーズを引き出す技術も求められます。
要求分析の最初のステップとして重要なのが、ステークホルダー分析です。システムに関わるすべての利害関係者を特定し、それぞれの要求や期待を把握することで、要求項目の洗い出しをより効果的に行うことができます。
| 手法 | 概要 | 適用場面 | 長所 | 短所 |
|---|---|---|---|---|
| インタビュー | ステークホルダーに直接質問し、要求や課題を聞き出す方法 |
• 詳細な要求の把握 • 潜在的なニーズの抽出 • 業務プロセスの理解 |
• 深い洞察が得られる • 対話的に詳細を引き出せる • 背景情報も収集できる |
• 時間がかかる • インタビュアーのスキルに依存 • 回答者のバイアスが入りやすい |
| アンケート | 多数のステークホルダーから一度に情報を収集する方法 |
• 広範囲の意見収集 • 定量的データの収集 • 初期段階での方向性確認 |
• 多数の意見を効率的に収集 • 定量的な分析が可能 • 匿名性による率直な意見 |
• 深い洞察が得にくい • 追加質問ができない • 回答率の問題 |
| 観察法 | 実際の業務環境でユーザーの行動を観察する方法 |
• 実際の業務プロセスの理解 • 暗黙的なワークフロー把握 • ユーザビリティ課題発見 |
• 実際の行動が観察できる • 潜在的な問題点を発見 • 暗黙知を引き出せる |
• 時間と労力がかかる • 観察者効果の影響 • 解釈にバイアスが入りやすい |
| ワークショップ | 複数のステークホルダーが集まり、協働で要求を整理・抽出する方法 |
• 複数視点からの要求抽出 • 共通認識の形成 • 要求の優先順位付け |
• 多様な視点を一度に収集 • 相互理解と合意形成 • クリエイティブな解決策 |
• 準備と進行に手間がかかる • 発言力の強い人に偏りやすい • 日程調整が難しい |
| プロトタイピング | システムの試作品を作り、ユーザーからフィードバックを得る方法 |
• UI/UX要件の具体化 • 要求の検証 • イメージ共有 |
• 具体的なフィードバック • 早期の問題発見 • イメージのずれを防止 |
• 作成コストがかかる • プロトタイプへの執着 • 一部機能のみの評価 |
| ドキュメント分析 | 既存の業務資料や仕様書を分析して要求を抽出する方法 |
• 現行システムの理解 • 業務ルールの把握 • 過去の経緯の理解 |
• 人的リソース負担が少ない • 客観的な情報の取得 • 歴史的経緯の把握 |
• 文書の古さや不正確さ • 暗黙知が文書化されない • 解釈の誤りリスク |
| ブレインストーミング | 自由な発想で多くのアイデアを出し合い要求を引き出す方法 |
• 創造的な解決策の模索 • 新しい視点の獲得 • チーム内の共創 |
• 多様な要求を短時間で収集 • 従来にない発想の誕生 • 参加者の当事者意識向上 |
• 実現可能性の検証が必要 • 整理・分類に時間がかかる • 具体性に欠けることがある |
表1：要求分析における収集・分析手法一覧
2.3. 分析
収集した要求に対して、以下のような分析を行います：
- 要求の分類（機能要件・非機能要件など）
- 要求間の関連性の把握
- 優先順位付け
- 矛盾点の洗い出し
- 現状分析による問題点の特定
特に現状分析では、現行システムや業務の問題点を明らかにし、改善すべき点を特定します。これにより、新システムで解決すべき課題が明確になります。
要求の分析では、機能要件だけでなく非機能要件（性能、セキュリティ、可用性、保守性など）も重要です。非機能要件はシステムの品質特性に関わるもので、ユーザーが明示的に要求しないことも多いため、要求分析の段階で意識的に抽出する必要があります。
要求の優先順位付けには、MoSCoW法などの手法が用いられます。これは要求を Must（必須）、Should（重要）、Could（あれば良い）、Won’t（今回は対象外）に分類するもので、開発リソースの効率的な配分に役立ちます。
- 利用者認証機能
- データベースへの保存機能
- 個人情報保護法への準拠
- レポート出力機能
- 検索機能の高度なフィルタリング
- ユーザー設定のカスタマイズ
- ダークモード対応
- 追加の統計情報表示
- ショートカットキーのカスタマイズ
- 他システムとの連携機能（次期フェーズで対応）
- AIによる予測分析機能
- モバイルアプリ版の開発
表2：要求の優先順位付け手法（MoSCoW法）
2.4. システム化ニーズの整理
分析結果を基に、システム化すべきニーズを整理します。この段階では、以下のアプローチが用いられます：
- 現状指向型アプローチ：現在の業務や既存システムを出発点とし、その改善を図る方法
- 目的指向型アプローチ：あるべき姿を設定し、そこから逆算して必要な機能を導き出す方法
これらのアプローチを適切に組み合わせることで、バランスの取れたシステム化ニーズを整理することができます。また、この段階で課題定義を行い、システムが解決すべき具体的な問題を明確化します。
システム化ニーズの整理にあたっては、UMLやBPMNなどの標準的なモデリング言語を活用することで、関係者間での認識共有が容易になります。特にユースケース図やアクティビティ図は、システムの機能要件を視覚的に表現するのに役立ちます。
| 比較項目 | 現状指向型アプローチ | 目的指向型アプローチ |
|---|---|---|
| 基本的な考え方 | 現在の業務や既存システムを出発点とし、問題点を改善する | あるべき姿（理想的な状態）を設定し、そこから逆算する |
| 出発点 | 現状の業務フロー・システム | 目標・ビジョン・戦略 |
| 特徴 | 漸進的・段階的な改善 現実的で実現性が高い |
抜本的・革新的な改善 創造的で理想を追求する |
| メリット |
• 現状業務に基づくため理解しやすい • リスクが比較的小さい • 短期間での実現が可能 |
• 大幅な業務改善が可能 • 競争優位性を高める可能性 • 長期的な視点での最適化 |
| デメリット |
• 抜本的な改革は難しい • 現状の問題を引き継ぐ可能性 • 長期的な視点が不足しがち |
• 実現可能性の検証が必要 • リスクが比較的大きい • 現場の抵抗が大きくなりやすい |
| 適した状況 |
• 既存システムが一定程度機能している • 業務プロセスが確立されている • 短期間での開発が求められる • リスクを最小限に抑えたい |
• 既存システムの問題が根本的 • 新規事業や新サービスの立ち上げ • デジタルトランスフォーメーション • 業界標準や競合との差別化 |
| 主な分析手法 |
• 業務フロー分析 • 問題点分析 • ギャップ分析 |
• ゴール指向要求分析 • ビジネスモデル分析 • シナリオ分析 |
表3：現状指向型アプローチと目的指向型アプローチの比較表
2.5. 前提条件や制約条件の整理
システム開発における前提条件や制約条件を明確にします。代表的な制約条件には以下のようなものがあります：
- 予算的制約
- 技術的制約
- 法的・規制上の制約
- スケジュール的制約
- 組織的制約
これらの条件を明確にすることで、実現可能で現実的なシステム要求を定義することができます。
2.6. 要求仕様書の作成
要求分析の結果は、要求仕様書としてドキュメント化されます。要求仕様書には以下の内容が含まれます：
- システムの目的と範囲
- 機能要件
- 非機能要件
- 前提条件・制約条件
- ユーザーインターフェース要件
- 外部インターフェース要件
要求仕様書は、開発チームとユーザー間の合意形成のための重要な文書であり、以降の開発工程の基礎となります。要求仕様書の品質を確保するために、「明確性」「完全性」「一貫性」「検証可能性」「追跡可能性」といった観点からのレビューが重要です。
mindmap
root((要求仕様書))
1 システム概要
1.1 目的
1.2 適用範囲
1.3 用語の定義
1.4 参考資料
2 システム要件
2.1 機能要件
2.1.1 機能一覧
2.1.2 画面一覧
2.1.3 帳票一覧
2.1.4 データ項目一覧
2.2 非機能要件
2.2.1 性能要件
2.2.2 信頼性要件
2.2.3 使用性要件
2.2.4 保守性要件
2.2.5 移植性要件
2.2.6 セキュリティ要件
3 ユーザー要件
3.1 ユーザー種別
3.2 ユーザー特性
3.3 業務フロー
4 システムモデル
4.1 ユースケース図
4.2 クラス図
4.3 シーケンス図
4.4 状態遷移図
5 外部インターフェース
5.1 ユーザーインターフェース
5.2 ハードウェアインターフェース
5.3 ソフトウェアインターフェース
5.4 通信インターフェース
6 前提条件と制約条件
6.1 ハードウェア制約
6.2 ソフトウェア制約
6.3 法的・規制上の制約
6.4 予算的制約
6.5 納期的制約
7 付録
7.1 承認記録
7.2 変更履歴
図2：要求仕様書のテンプレート例
3. 応用例
3.1. 企業情報システムでの応用例
大手小売業のECサイトリニューアルプロジェクトでは、以下のような要求分析手順が適用されました：
- 要求項目の洗い出し：
- マーケティング部門、営業部門、IT部門へのインタビュー
- 顧客アンケートの実施
- 競合サイトの分析
- 分析：
- 機能要件と非機能要件の分類
- 顧客動向データに基づく優先順位付け
- 現状分析によるサイト離脱率の高いページの特定
- システム化ニーズの整理：
- 目的指向型アプローチによる「購入完了率10%向上」という目標設定
- その達成に必要な機能の特定
- 前提条件や制約条件の整理：
- 既存の商品データベースとの連携が必須
- 6ヶ月以内のリリースが必要
- モバイルデバイス対応が必須
これらの手順を踏むことで、明確な要求に基づいたECサイトの再構築が実現しました。
3.2. 公共システムでの応用例
自治体の住民情報システム刷新プロジェクトでは、以下のように要求分析が行われました：
- 要求項目の洗い出し：
- 窓口担当者への業務観察とインタビュー
- 住民へのサービス満足度調査
- 法改正に伴う新たな要件の確認
- 分析：
- 現状分析による窓口業務のボトルネック特定
- 複数部署間での情報連携の問題点分析
- 課題定義による「窓口待ち時間30%削減」などの具体的目標設定
- システム化ニーズの整理：
- 現状指向型アプローチと目的指向型アプローチの併用
- マイナンバー連携など法的要件の整理
- 前提条件や制約条件の整理：
- 個人情報保護法の遵守
- 既存システムとの並行運用期間の設定
- 災害時のバックアップ体制の確保
この結果、住民サービスの向上と業務効率化を両立したシステムの要求仕様が完成しました。
4. 例題
例題1
ある製造業の在庫管理システム刷新プロジェクトにおいて、要求分析の手順に従って作業を進めることになりました。要求項目の洗い出しの段階で、どのような手法を用いるべきか、また収集すべき要求項目にはどのようなものがあるか説明してください。
要求項目の洗い出しでは、以下の手法を用いるべきです：
- 現場担当者（倉庫管理者、物流担当者など）へのインタビュー
- 物流プロセスの現場観察
- 既存システムの操作ログ分析
- ワークショップの開催（各部門の代表者を集めた横断的な検討）
- 類似業種の在庫管理ベストプラクティス調査
収集すべき要求項目としては、以下のようなものが考えられます：
- 在庫管理の正確性向上（リアルタイム性）
- バーコードやRFIDなどのタグ管理方式
- 発注点管理の自動化
- 季節変動を考慮した在庫予測機能
- モバイルデバイスからの在庫確認機能
- 他システム（会計、購買、生産管理）との連携要件
- レポーティング機能（在庫回転率、適正在庫など）
- ユーザーインターフェースの使いやすさ
これらの要求をユーザーニーズ調査を通じて収集し、現状分析と照らし合わせることで、システム化すべき要件を明確にしていきます。
例題2
要求分析における「現状指向型アプローチ」と「目的指向型アプローチ」の違いを説明し、それぞれのアプローチが適している状況を挙げてください。
「現状指向型アプローチ」と「目的指向型アプローチ」の違いは以下の通りです：
- 現状指向型アプローチ
- 現在の業務や既存システムを出発点とし、その問題点や改善点を特定して新システムの要件を定義する
- 現状の詳細な分析から始まり、ボトルネックや非効率な点を改善することに重点を置く
- 段階的な改善を目指す場合に適している
- 目的指向型アプローチ
- あるべき姿（理想的な状態）を設定し、そこから逆算して必要な機能や要件を導き出す
- 業務の抜本的な見直しや再設計を伴うことが多い
- 創造的で革新的なシステム開発を目指す場合に適している
現状指向型アプローチが適している状況：
- 既存システムが一定程度機能しており、部分的な改善が必要な場合
- 業務プロセスが確立されており、大きな変更が難しい場合
- リスクを最小限に抑えたい場合
- 短期間での開発が求められる場合
目的指向型アプローチが適している状況：
- 既存システムの問題が根本的で、抜本的な見直しが必要な場合
- 新規事業や新サービスのためのシステム開発
- デジタルトランスフォーメーション（DX）のような大規模な変革
- 業界標準や競合との差別化を図りたい場合
実際のプロジェクトでは、これら2つのアプローチを状況に応じて併用することで、バランスの取れた要求分析が可能になります。
例題3
ある金融機関のモバイルバンキングアプリ開発プロジェクトにおいて、要求分析の結果を要求仕様書にまとめることになりました。この要求仕様書に含めるべき主要な項目を5つ挙げ、それぞれについて簡単に説明してください。
金融機関のモバイルバンキングアプリの要求仕様書に含めるべき主要項目は以下の通りです：
- システム概要と目的
- アプリの目的（「いつでもどこでも銀行取引を可能にする」など）
- 対象ユーザー（個人顧客、法人顧客など）
- システムの範囲（対象とする取引や機能の範囲）
- 機能要件
- 口座残高照会機能
- 振込・送金機能
- 入出金明細照会機能
- ローン・投資商品申込機能
- プッシュ通知機能
- ユーザー認証機能（生体認証含む）
- 非機能要件
- セキュリティ要件（暗号化、不正アクセス検知など）
- 性能要件（レスポンス時間、同時接続数など）
- 可用性要件（稼働率、メンテナンス計画など）
- 拡張性要件（将来的な機能追加の容易さ）
- ユーザビリティ要件（操作性、画面設計ガイドラインなど）
- 前提条件と制約条件
- 対応OSとバージョン（iOS 13以上、Android 10以上など）
- 銀行基幹システムとの連携条件
- 金融規制に関する遵守事項（個人情報保護法、金融商品取引法など）
- 開発期間・予算の制約
- 外部インターフェース要件
- 銀行基幹システムとのAPI連携仕様
- クレジットカードシステムとの連携
- 電子マネーサービスとの連携
- プッシュ通知サービスとの連携
これらの項目を要求仕様書に明確に記載することで、開発チームとステークホルダー間の認識を一致させ、成功するモバイルバンキングアプリ開発の基盤を形成します。
5. まとめ
要求分析の手順は、システム開発の成功を左右する重要なプロセスです。基本的な手順として、要求項目の洗い出し、分析、システム化ニーズの整理、前提条件や制約条件の整理の4つのステップがあります。
要求項目の洗い出しでは、ユーザーニーズ調査を通じてステークホルダーの要求を漏れなく収集します。分析では、収集した要求を整理・分類し、現状分析によって問題点を特定します。システム化ニーズの整理では、現状指向型アプローチや目的指向型アプローチを用いて、システム化すべき要件を明確にし、課題定義を行います。前提条件や制約条件の整理では、システム開発における制約や前提を明確にします。
これらの手順を適切に実施し、その結果を要求仕様書としてドキュメント化することで、ユーザーのニーズを満たすシステム開発の基盤が構築されます。
要求工学（Requirements Engineering）の知識と技術を活用しながら、一連の要求分析手順を確実に実施することは、応用情報技術者として必須のスキルです。適切な要求分析が、システム開発プロジェクトの成功確率を大きく高めることを忘れないようにしましょう。