はじめに
要件定義は、プロジェクト成功の土台を築く重要な工程です。しかし、その全貌を理解し、実務で効果的に進めるのは簡単ではありません。
特に経験の浅い若手エンジニアにとっては、どこから手をつけるべきか迷うことも多いと思います。
そこで、本記事では、業務要件定義からシステム要件定義まで、要件定義の基本的なプロセスを解説します。実践力を高める一助となれば幸いです。
なお、本記事ではTIS社の要件定義フレームワークを参考文献として活用し、実務に即した知識を提供します。
要件定義の概要
要件定義は、ビジネスの目的・目標を達成する「手段」としての業務・システムを決定し、後続のシステム開発工程を通じて実現すべきことを明らかにする工程です。
業務要件定義
ビジネスの目的・目標を達成するために解決すべき業務課題、実現すべき業務を定義する。
システム要件定義
実現すべき業務のために、解決すべきシステム課題、実現すべきシステムを定義する。
（参考）業務要件定義の必要性
業務要件定義って何？
システム開発ベンダーには関係ないんじゃないの？
システム開発ベンダーが作業するのは「システム要件定義」からが多いと思いますが、実際にプロジェクトを経験してみると業務要件定義が不足していて苦労する場面が少なくありません。
そこで、業要件定義の必要性と、システム開発への関係性について簡単に説明しておきます。
業務要件定義は、ビジネスの目的・目標を達成するために解決すべき業務課題、実現すべき業務を定義する、と前述しましたが、例えば、業務改善・改革の場合には、業務要件定義にて、現行業務のムダや非効率を改善した最適な業務を明確にする作業を指します。
このため、システム構築だけでなく、組織や体制の変更だったり、業務プロセスの変更だったりが少なからず発生するため、「システム開発だからベンダーがやってくれるんでしょ？」と思っている業務部門がいると、プロジェクトの協力が得られず、プロジェクト推進に影響を及ぼすリスクが発生します。
また、業務要件は、ビジネスとシステムの橋渡しを担い、ビジネスの目的・目標達成に貢献するシステム構築へと繋がるため、業務要件が曖昧だったり不足があると、システム構築中あるいは本番業務開始後に「こういう機能も必要だった」とか「この機能は必要ないね？」といったことが起こる可能性が高くなってしまいます。
このように、業務要件定義は重要な作業であるにも関わらず、その重要性が見落とされがちで、その後のシステム開発にも大きな影響を与える恐れがあるので、現場でも「業務要件定義がしっかりされているか？」ということを確認することをオススメします。
要件定義の進め方（プロセスフロー）
では、次に要件定義の具体的な進め方について説明します。
業務要件定義
業務要件定義は、以下の手順で行います。
- 業務要求の収集
- 業務用級の整理とモデル化
- 業務要件定義書の作成
- 業務要件の検証・妥当性の確認
- システム要件定義への引き継ぎ
小さくて見づらいかもしれませんが、以下に業務要件定義の全体的な流れを添付します。
資料の上部が作業の流れで、資料の下部が成果物との紐付けになっています。
システム要件定義
次に、システム要件定義は、以下の手順で行います。
- システム要求の収集と整理
- 機能要件の定義
- 非機能要件の定義
- 全体要件の精査
- 全体要件の合意と承認
- 設計工程への引き継ぎ
こちらも更に小さくて見づらいと思いますが、システム要件定義の全体的な流れを添付します。
資料の上下が作業の流れで、中央の成果物と紐付けがされています。
それでは、ここから業務要件定義と、システム要件定義のそれぞれの具体的な手順について説明をしていきます。まずは業務要件定義から。
1. 業務要求の収集
1-1. 現行業務の調査
プロジェクトの対象となる業務に対して、現行業務のプロセス・ルール・データを調査します。
・現行の業務構造・業務の流れ・業務の依存関係の調査
・現行の業務ルールの調査
・現行のデータを調査
・(As-Is)ビジネスモデル定義
・(As-Is)組織一覧
・(As-Is)用語集
・(As-Is)業務俯瞰図
・(As-Is)業務階層定義
・(As-Is)データフロー
・(As-Is)アクター一覧
・(As-Is)業務フロー
・(As-Is)イベント一覧
・(As-Is)状態遷移モデル定義
・(As-Is)業務ルール定義
・(As-Is)概念データモデル定義
1-2. 現行システムの調査
以下を目的に、前述の業務に関係する現行システムの機能を調査します。
・ビジネス・業務とシステムの繋がりの明確化
・システム機能の構成要素と全体構造の把握
・システム実装に埋もれた業務ルールの抽出
・(As-Is)システム機能一覧
・(As-Is)CRUD
・(As-Is)システム機能俯瞰図
1-3. 課題の抽出と原因分析
システム化企画資料などに記載されている課題を抽出し、その上で、ステークホルダーにヒアリングし課題の抜け漏れがないか確認します。
また、抽出された課題の原因分析を行います。
1-4. 課題解決後のゴール定義
期待効果を得られる適切な解決手段を検討するために、課題解決後の状態を明確にします。
1-5. 課題解決の実現手段検討
定義された「課題解決後のゴール」の実現に向けた具体的な手段を検討する前に、改善方針を検討します。
その上で、課題原因を解消し、ゴールを達成する実現手段の定義を行います。
課題分析〜実現手段検討の流れは以下のようなイメージです。
・業務課題一覧（ゴール定義済み）
2. 業務要求の整理とモデル化
前述のプロセスで整理した実現手段から業務要求を整理し、To-Beの業務プロセスモデルを定義します。そして業務要求の実現対象を決定します。
2-1. 業務要求の整理
前述のプロセスで整理した実現手段から業務要求を整理します。
・業務要求一覧
・システム要求一覧
業務要求一覧（サンプル）
システム要求一覧（サンプル）
2-2. 業務要求のモデル化
システムが実現・支援する業務のプロセスを明確化するために、To-Be業務プロセスモデルを作成します。
また、システム要件の検討対象を明確化するために、モデル化した業務要求からシステム機能を抽出します。
・(To-Be)ビジネスモデル定義
・(To-Be)組織一覧
・(To-Be)用語集
・(To-Be)業務俯瞰図
・(To-Be)業務階層定義
・(To-Be)データフロー
・(To-Be)アクター一覧
・(To-Be)業務フロー
・(To-Be)イベント一覧
・(To-Be)状態遷移モデル定義
・(To-Be)業務ルール定義
・(To-Be)概念データモデル定義
※成果物サンプルは、現行業務の調査結果と同じものとなります。
システム機能一覧
2-3. 業務要求の優先順位付け
要件定義計画で設定した要求の優先順位付け基準・方法に問題がないか確認し、必要に応じて見直しを行う。
設定した優先順位付け基準・方法で業務要求の優先順位付けを行う。
・業務要求一覧(優先順位付け済み)
2-4. 業務要求の実現対象決定
業務要求内容をステークホルダーに説明し、適切であることを確認する。その上でプロジェクトリソース制約に収まるよう、優先順位をベースに実現対象の業務要求を選定し、ステークホルダーと合意する。
・業務要求一覧(実現対象合意済み)
3.業務要件定義書の作成
実現対象の業務要求（＝業務要件）を対象に、これまで検討してきた資料（As-IsとTo-Beのモデル）を活用して業務要件定義書にまとめます。
・業務要件定義書
4.業務要件の検証・妥当性確認
業務要件定義書をもとに、業務要件の検証を行い、顧客と合意します。
・業務要件定義書（承認済み）
・合意、承認記録
5.システム要件定義への引継ぎ
業務要件定義で解決せず先送りとした課題や、業務要件定義で抽出されたシステム要求事項が、システム要件定義で漏れなく取り扱われるように整理します。
以上が、業務要件定義です。
ここからが、システム要件定義となります。
6. システム要求の収集と整理
6-1. 現行システムの調査
機能面では画面や帳票の構成や項目を確認し、非機能面ではハードウェアやネットワーク等の構成図から今回のプロジェクトに関係する箇所をまとめます。
・現行システムの資料（As-Is）
6-2. 課題の抽出と原因分析
システム化企画資料や業務要件定義、現行システムの調査結果をもとに、解決すべきシステム課題を整理します。
さらに、ステークホルダーとの確認を通じて未認識の課題を洗い出し、プロジェクトスコープに含めるべき課題を選定します。
その後、課題の原因を分析し、分析結果をステークホルダーと共有します。
・システム課題一覧
システム課題一覧
6-3. 課題解決の実現手段検討
課題解決の実現手段検討では、まず課題解決後の理想状態を明確化し、ステークホルダーと合意します。
その後、複数の解決手段を多角的に検討し、方向性を決定します。
さらに、選定した方向性に基づき具体的な実現手段を詳細化し、それがゴール状態を達成できるかをステークホルダーと確認して合意します。
このプロセスを通じて、解決手段の妥当性を確保します。
・実現手段方向性検討資料
・システム課題一覧（合意済み）
6-4. 機能の整理
課題解決の実現手段をシステム要求として一覧化し、システム機能の振る舞いや関連や整合性を確認します。
・システム要求一覧
・システム機能一覧(検証済み)
・システム機能俯瞰図
・システムフロー
システム機能俯瞰図
システムフロー
7.機能要件の定義
システムの機能要件を、画面、帳票、外部インターフェース（IF）、バッチ機能、そして論理データモデルに分けて詳細に定義します。（設計工程以降の工数見積もりや開発範囲を明確にするために重要）
（作業手順）
・まず、画面、帳票、外部IF、バッチごとに、それぞれの要件を具体化します。
・次に、取り扱うデータは論理データモデルで整理し、データの流れを明確にします。
・もし、方式設計で定められた標準（入出力共通仕様、画面や帳票の標準、命名規約、処理パターンなど）が要件に合わない場合は、方式設計担当者と調整しながら修正します。
※機能要件定義は、顧客に提供を約束する部分を明確にし、その実現方法は設計工程で具体化するという考え方で進めます。
なお、個別要件は以下の通りです。
画面機能
画面機能が提供する各画面を一覧化し、画面間の遷移を明確にします。また、画面ごとの入出力項目やレイアウトなど、画面に関する具体的な要件を定義します。
帳票機能
帳票機能が提供する帳票を一覧化し、帳票ごとの出力項目、レイアウト、編集仕様などの要件を明確化します。
外部インターフェース（IF）機能
接続先の外部システムとのインターフェース機能を一覧化し、接続先システム、接続方法、入出力の種類など、IFに関する要件を具体化します。
バッチ機能
バッチ処理の概要、入力・出力内容、処理サイクルなどを明確にし、バッチ機能に関する要件を定義します。
論理データモデル
各機能で利用するエンティティや項目、エンティティ間のリレーションなどを整理し、論理データモデルとして明確に定義します。
・画面機能要件定義
・帳票機能要件定義
・外部IF機能要件定義
・バッチ機能要件定義
・CRUD図
・論理データモデル定義
8.非機能要件の定義
非機能要件では、システムの動作や品質に関する要件で、性能、セキュリティ、可用性、操作性など、機能以外の期待される性質や制約を定義します。
8-1. モデルシステムの選定
非機能要求グレードで定義された3つのモデルシステムから、開発するシステムに最も近いものを選びます。
このモデルを基に、非機能要求の対応レベルを調整・設定し、具体化を進めていきます。
8-2. 可用性要件の定義
可用性要件では、業務継続性や目標復旧水準を設定し、障害時の業務やシステム復旧の基準を明確にします。
稼働率は運用時間中のサービス提供割合として算出し、災害対策では大規模災害への対応要件を定義します。
また、耐障害性として、障害発生時にもサービスを維持するための要件を設定し、業務の安定性を確保します。
・可用性要件定義
8-3. 性能・拡張性要件の定義
性能・拡張性要件では、業務処理量、性能目標値、リソース拡張性、性能品質保証を定義します。
業務処理量は通常時やピーク時の業務量や将来的な増加率を設定し、性能目標値は業務特性に応じた基準値を設定します。
リソース拡張性は業務増加に対応できる拡張計画を策定し、性能品質保証ではシステムが目標性能を満たすか検証する試験方法を検討します。
・性能・拡張性要件定義
8-4. 運用・保守要件の定義
運用・保守要件では、システムが安定して稼働するための方針や作業内容、障害発生時の迅速な復旧対応方法を定義します。
具体的には、メンテナンス作業の方針や内容、障害発生時の復旧手順、環境準備やマニュアルの整備を検討します。
さらに、運用・保守契約に関する事項やサポート体制、ユーザとベンダ間の役割分担も設定します。
その他、内部統制やサービスデスク、インシデント管理といった運用管理方針も含め、全体的な運用体制を整備します。
・運用・保守要件定義
8-5. 運用監視要件の定義
運用監視要件では、監視対象から発信するべき情報とその監視間隔を整理し、監視システムの有無も確認します。
ソフトウェアについては、システム全体、プロセス、データベースの機能監視レベルを設定し、ハードウェアに関しては、ストレージやサーバ、端末/ネットワーク機器の監視レベルを決定します。
また、ネットワーク監視では、パケットレベルで監視範囲や監視情報を確認します。
・運用監視要件定義
※TISのサンプル無し
8-6. バックアップ要件の定義
バックアップ要件では、データ復旧範囲、バックアップ利用範囲、バックアップ自動化の範囲、取得間隔、保存期間、バックアップ方式を設定します。
復旧地点や時間に応じて取得間隔を決定し、可用性とデータ保全を考慮して適切なバックアップ方式を選定します。
・バックアップ要件定義
8-7. ネットワーク要件の定義
ネットワーク要件では、既存回線が新システムに転用可能かを判断し、WAN・LAN構成や外部システム接続構成を確認します。
これには、使用プロトコル、拠点数、トラフィック量などが考慮され、保守作業に必要な保守回線の要件も確認します。
・ネットワーク要件定義
※TISのサンプル無し
8-8. 移行要件の定義
移行要件では、システム移行に関する要件を定義します。
移行時期や方式、移行対象設備・業務データの設定を行い、展開先拠点や業務に応じた移行方法（一斉または段階的）を決定します。
また、移行計画には作業分担、リハーサル戦略、トラブル対応体制などを含め、円滑な移行を目指します。
・移行要件定義
8-9. セキュリティ要件の定義
セキュリティ要件では、システムのセキュリティ要件を定義するために、情報セキュリティに関する法令や規定の遵守を確認し、リスク分析を実施します。
セキュリティ診断を行い、認証機能や利用制限、データ暗号化の要件を設定。さらに、不正監視、ネットワーク対策、マルウェア対策などを講じ、Webアプリケーションの脅威に対する対策も検討します。
これらの要件を通じて、システムのセキュリティを確保します。
・セキュリティ要件定義
8-10. システム環境
システム環境の要件では、利用するシステム数や管理対象クライアント数、稼働拠点数や地域的な広がりを確認。顧客から指定されたオープンソースや第三者製品の採用有無を確認し、指定理由や選定背景も考慮します。
さらに、システム設置環境の耐震/免震レベルを設定し、地震時の耐震性を確保します。
・システム環境要件定義
システム環境要件定義（サンプル）
8-11. テスト要件の定義
テスト要件では、テスト工程と各工程の役割分担を明確にし、品質管理のための評価指標として品質メトリクスを設定・適用します。
これにより、テストの進行管理と品質の向上を図ります。
・テスト要件定義
※TISのサンプル無し
→ 全体テスト計画の資料が参考になると思います。
8-12. 非機能要件の制約条件の定義
非機能要件の制約条件は、ビジネス制約と技術制約に分けられます。
ビジネス制約は法令や社内規程、提携先とのインターフェースに関連し、技術制約は適用製品やサービスに関するもので、これらの制約を明確にすることが重要とされます。
・非機能要件定義（制約条件付与済）
※TISのサンプル無し
8-13. 非機能要件の対応レベル決定
非機能要求の対応レベルをシステムの事業重要性やリスク、開発コスト、スケジュール、技術的制約を基に評価し、全体最適を目指します。
必要に応じて、お客様と共に重要項目を再検討し、補正を加えて対応レベルを決定します。
・非機能要件定義（対応レベル確定済）
※TISのサンプル無し
9.全体要件の精査
要件の検証と妥当性確認では、機能要件と非機能要件が矛盾なく、漏れなく記述されていることを確認します。
また、業務要件と照らし合わせ、機能が実際の業務に対応し、定義した制約条件のもとで実現可能であることを確認します。
10.全体要件の合意と承認
定義されたシステム要件を実現するために必要となる工数・コストをやスケジュールを試算し、費用対効果から実施対象とする要件を顧客と合意し、決定する。
・概算見積り
・概算スケジュール
・合意、承認記録
※TISのサンプル無し
11.設計工程への引継ぎ
システム要件定義で解決せず先送りとした課題や、システム要件定義で抽出された設計時に定義すべき事項など、設計工程で漏れなく取り扱われるように整理します。
【成果物サンプルのExcel版】
今回紹介した要件定義のサンプル資料は、Excel版も用意されていますので、そのまま実務でも活用できます。
以下のリンクからどうぞ。
さいごに
以上、業務要件定義からシステム要件定義の進め方を説明しました。
ここに記載したのは、TIS社の要件定義フレームワークや、研修テキストをもとにしています。どなたでも閲覧できますので、「もっと勉強したい！」という人は以下の研修テキストも確認してみてください。
TIS社が要件定義の研修テキストを無料で公開してくれており、要件定義初心者だけでなく、経験者も復習に良いと思います。
1.要件とは?
2.要件定義で何が起こっているか?
3.要件定義の概念プロセス、成果物
4.要件定義の基礎知識
5.特定種類のPJでの要件定義
かなりボリュームがあるので理解して実務に落とし込むには苦労するかもしれませんが、これらを実践できるようになると上流工程に対応できるエンジニアとして価値がより一層高まりますので頑張ってください。
基本的なプロセスを押さえながら、実際の現場で少しずつ試していく中で、自然と自分なりのやり方が見つかると思います。その一歩を応援しています。
関連記事
システム方式設計書の書き方（TIS社の公開資料を引用しながら解説）