本記事は様々なITプロジェクトやシステム開発に携わってきた西村泰洋さん、相川正昭さん、蓮沼潤一さんによる著書『図解まるわかり 要件定義のきほん』の「第1章 要件定義の基本～特徴と機能、RDの位置づけ～」から、内容の一部を抜粋して編集したものです。
1-1 要件定義の基本的な考え方
システム開発における要件定義
要件定義は、Requirements Definition、または省略されて「RD」と呼ばれています。情報システムで必要とするものを「要件」として定義し、要件定義書にまとめることです。RDを実施する工程をRD工程といいます。
要件定義書は、情報システム開発プロジェクト（以下、「ITプロジェクト」の目的に照らして各ステークホルダーが、情報システムで必要とするものを合意するための文書となります。図1-1では要件定義書とステークホルダーとの関係を示しています。
ステークホルダーが重視する項目や指標が異なる中で、情報システムに対する要求を取りまとめる工程がRDであり、ITプロジェクトの方向性を握る非常に重要な工程ともいえます。
RDを4つの視点で考える
本書ではITプロジェクトにおけるRDを図1-2のように、RDの基本、RDの実践、RDのドキュメント、RD前後の主に4つの重要項目に分けて、成果物と作成方法ならびに工程管理を具体的な事例をもとにして解説していきます。
1-2 DXとRD
システム開発におけるRD
DXとはDigital Transformationの略称で、企業や団体がデジタル技術を活用して経営や事業における変革を実現する取り組みをいいます。デジタル技術を一言で表す「Digital（デジタル）」と変革を表す「Transformation（トランスフォーメーション）」を組み合わせた造語です。デジタル技術は、次のような比較的新しい情報通信技術の総称です（図1-3）。
- AI（Artificial Intelligence：人工知能）
- IoT（Internet of Things）
- Web技術
- AR（Augmented Reality：拡張現実）
- クラウドコンピューティング
- VR（Virtual Reality：仮想現実）
- ブロックチェーン
- API（Application Programming Interface）
このような新たなITや、従来型ITにおいて、コンピュータや情報システムに何をさせるかを定義するのがRDです。
DXでRDが重要視される理由
2022年9月に経済産業省から発表された「デジタルガバナンス・コード」は、企業のDXに関する自主的な取り組みを促すため、デジタル技術による社会変革を踏まえた経営ビジョンの策定・公表など、経営者に求められる対応を取りまとめています。
その中ではDX認定基準を定め、「DX認定取得のために必要と想定されるプロセスのイメージ例」を公開しています。その中でも（2）項「DX戦 略」を策定するプロセスは、ビジネスモデルに基づく戦略検討やシステム化検討、体制構築など、RDで行うべき作業が多く含まれています（図1-4）。つまり、DXを成功させるためには、DXで実現したい事業や業務の企画をユーザー企業が明確にし、要求に適した技術をRDでまとめる必要があります。
1-3 RDの全体像
RDの進め方
RDとは、情報システムで必要とするものを要件として定義して要件定義書にまとめることです。具体的には次の取り組みを行います（図1-5）。
- 業務を分析し、ビジネス要件とシステム化要件を定義する
- 予算とスケジュールで要件を取捨選択する
- 決定した予算とスケジュールと要件を合意・承認する
言い換えると、RDは情報システムで必要な機能を定義し、ITプロジェクトの目的と予算、スケジュールを考慮して要件定義書としてまとめ、ステークホルダー全体で合意する工程ともいえます。
要件の調整
一般的にITプロジェクトの要件は当初の想定よりも膨らむことが多く、その調整に多くの時間を要します。そのため、要件を評価する軸や基準をステークホルダー間で事前に合意しておく必要があります。代表的な評価の軸として、コスト優先、納期優先、ステークホルダーの満足度優先の3つがあります（図1-6）。どの評価軸を優先するかによって、取るべき対策が変わります。
例えば、コスト優先や納期優先を評価軸とするなら、コスト内および納期内に収まるよう要件を減らします。また、満足度優先を評価軸にする場合は、要件を減らすことなく段階的にリリースして要望に応えるなどです。
1-4 システム開発におけるRDの位置づけ
ITプロジェクトのフェーズにおけるRDの位置づけ
ITプロジェクトは、進捗状況の予定と実績を把握し共有するために、スケジュールをフェーズや工程に分けて管理します。本書ではITプロジェクトを次の5つのプロセスに分けています（図1-7）。
- 企画フェーズ：ビジネス構想、システム構想を企画する
- 要件定義フェーズ：情報システムの要件を定義する
- 開発フェーズ：アプリケーションを開発・テストする
- 運用テスト・移行フェーズ：業務運用のテスト、移行を行う
- 運用・保守フェーズ：本番稼働
各フェーズと工程では、目的に沿った成果物が作成され、その内容を検証して次のフェーズ・工程に進みます。ITプロジェクトの品質確保の基本です。
ITプロジェクトのV字モデル
ITプロジェクトの各工程について、プログラミングを底辺にV字で表して設計工程の内容をテスト工程で動作検証を行うように計画することを品質保証のV字モデルといいます（図1-8）。
RDは、その前工程のシステム化計画（Vision Planning/System Planning、以下「VP/SP」）で作成された成果物をもとに要件定義書を作成し、後工程（User Interface Design、以下「UI」）に引き継ぎます。
前後の工程との関連性は極めて強いです。前工程のシステム構想書の品質が悪いと、RDで想定を上回る（下回る）予算・スケジュールの要件が定義されることがあります。また、RDで作成した要件定義書の品質が悪いと、UIで外部仕様を作成できずRDの手戻りが発生することがあります。
1-5 RDのプロセスと成果物
RDのプロセス
RDのプロセスは、図1-9のように、大きくは、ビジネス要件とシステム化要件の2つに分かれます。システム化要件の中にある非機能要件は、特に注意が必要なため、1-8で詳しく解説します。
ビジネス要件では図1-9のように、①ステークホルダーの把握から始まり、②As-Is（現状の姿）把握、③問題・ニーズ把握を実施し、④施策検討の後、⑤To-Be（あるべき姿）検討を実施します。これらのプロセスの詳細については、第3章以降で解説します。
システム化要件では、To-Be検討結果をもとに、⑥機能要件を作成し、⑦データ構造設計、⑧インタフェース設計を実施し、⑨非機能要件をまとめ、最後に⑩運用・移行計画をまとめます。システム化要件の「⑨非機能要件」では、性能、可用性、セキュリティなどのシステム化機能の要件以外を「非機能要件」としてまとめます。
RDの成果物
RDでは成果物として図1-10に示すドキュメントを作成します。これらのドキュメントをどのように作成するかは第3章以降で解説しますが、プロジェクトの特性に従って必要なものを選択します。
ビジネス要件プロセスでは、関係者の間で情報共有ができるように、各種ドキュメントを作成することが重要です。組織が何をしているか、プロジェクトの要求は何か、As-IsとTo-Beは何か、そこで使われている用語はどういう意味か、といったことを確認し、これらのドキュメントを整備していきます。
システム化要件プロセスでは、ビジネス要件をもとに、システム化するために必要な各種ドキュメント（機能、データ、画面、帳票など）の作成をします。また、運用開始時に必要となる運用計画書もRDで作成しておきます。
1-6 ビジネス要件を定義する
ビジネス要件のプロセスと成果物
ビジネス要件では、システム化要件につなげるための要件を定義します。これは、業務要件とも呼ばれています。ビジネス要件のそれぞれの詳細なプロセスや成果物は本書で解説しますが、ここでは概略を説明しておきます。
ビジネス要件の流れは前節で解説しましたが、図1-11のように、それぞれでドキュメントを作成する必要があります。
これらの成果物は、それぞれの目的を達成できるように作成することが重要になります。目的が達成できないような、ぼんやりとした、あるいは粗い粒度で作成すると、後工程で手戻りが発生するリスクが上がります。
ビジネス要件で起こる問題と対処例
実際のITプロジェクトでは、ビジネス要件の開始段階で、多くの企業が次のような問題に直面することがあります。
- 現場は自部門のみの業務しか把握しておらず業務全体を把握できない
- As-Isドキュメントが古い、そもそもドキュメントがない
- 問題、ニーズ、施策がそろっていない
- 施策を全部遂行すると開発費が膨大になる可能性がある
これらを解決するためには、業務全体図を作成し、抜け漏れを確認して、ステークホルダー間で同じ土俵に立って議論できるようにしておきます。また、要求を整理した要求一覧の中での優先順位を決めておき、予算を超過した場合の要件の取捨選択ができるようにしておくことも重要です（図1-12）。
1-7 システム化要件を定義する
システム化要件のプロセスと成果物
システム化要件では、開発プロセスにつなげるためのシステム化要件を定義します。システム化要件のプロセスや成果物の詳細は本書で解説しますが、ここでは概略を説明しておきます。
システム化要件の流れは、図1-13のように小プロセスのそれぞれでドキュメントを作成する必要があります。特に、システム化要件のドキュメントはシステム化をするために必要なドキュメントであることから、システムの特性に合わせて、取捨選択して作成する必要があります。
システム化要件で起こる問題への対処例
システム化要件からは、業務よりもシステムへの比重が大きくなります。
このため、ユーザー企業からするとITベンダーの支援を受けることも増えるので、ユーザー企業側での作業は検証と妥当性確認が主となります。検証と妥当性確認の判断を誤ると、次工程以降で手戻りが発生します。実際のITプロジェクトでは、次のような問題が発生します。
- 業務部門による検証、妥当性確認の判断は難しい
- ユーザー企業側でシステム化要件のドキュメントを作成するのが難しい
業務部門が検証や妥当性の確認ができるようにするためには、ユーザー企業とITベンダーが協力して、業務部門がわかる表現でドキュメントを作成することが多いです。作成に際しては、できる限り業務とシステムを関連づけて説明できるように心掛けながら進めます（図1-14）。
1-8 非機能要件の概要
非機能要件のプロセスと成果物
非機能要件では、図1-15のような非機能要件である可用性、性能・拡張性、セキュリティなどの業務から直接的な想像がしにくい機能であることから、慣れていないと整理するのが難しい要件を定義します。
非機能要件を網羅するには、独立行政法人情報処理推進機構（通称：IPA）が提供している「非機能要求グレード」を1つ1つ埋めていくのがわかりやすいです。ただし、この非機能要求グレードは、最新版で200を超える検討項目があり、すべてを検討するには手間がかかります。そこで、本書ではプロジェクト特性に応じた非機能要件の具体例を本書で解説します。
非機能要件で起こる問題への対処例
非機能要件では、ユーザー企業とITベンダーの認識が乖離することが多いです。ユーザー企業にとって、非機能要件の取りまとめは定常業務とは異なり、ITの専門性が求められ難易度が高い作業となります。
一方、ITベンダーとしても、要件が固まっていない状況では、非機能要求事項の必要性を訴える提案が難しいといわれています。この認識のギャップを埋められずにいると、ユーザー企業とITベンダーで非機能要件が合意できない、非機能要件に漏れが発生するなどの問題が発生するリスクを抱えます。最終的には、主にST工程、OT工程などの後工程で問題が発覚し、システムの処理能力不足、サーバーなどの入れ替えなど、多くの手戻りが発生することがあります。
これらを防ぐため、RD工程の中で、非機能要求グレードを利用してユーザー企業とITベンダーで非機能要件における共通認識を持ち、ドキュメントを作成して合意しておくことが重要となります（図1-16）。
1-9 ステークホルダーの見極め
ステークホルダーの抽出と選定
RDで要件を定義し、評価、取捨選択を適切に行うためには、適正なステークホルダーを選定してRDに参加してもらうことが重要です（図1-17）。ステークホルダーを選定するポイントは次の通りです。
- 情報システムに要求を持つステークホルダーを漏れなく抽出する
- 経営や業務など要求の種類ごとに合意が必要となる対象者を選定する
- 抽出すべき要求を正しく認識しているステークホルダーを認識する
適正な選定ができないと要求事項が収束できずに検討時間がかかるだけです。適正な選定をして要求の抽出や合意形成を行うことが重要です。
選定したステークホルダーの役割
要望・要求事項を要件定義書としてまとめるためには、要望・要求を提示する、要件を整理する、要件を承認するステップを段階的に進めます（図1-18）。
その中でステークホルダーは、それぞれ次のような役割があります。
- 経営者：経営観点の要求を出し、KGIを鑑みて要件を承認する
- PM/PMO：KGI、コスト、スケジュールを鑑みて要件を整理する
- 業務部門：業務遂行上のKPIを鑑みて要求を出す
- システム部門：システム要件（開発/運用）を出し全体を整理する
- ITベンダー：システム化フィージビリティ確認と全体整理を支援する
各ステークホルダーは立場や業務内容が異なることから、要件の粒度や影響度もさまざまですが、それらを見極めて検討すべき内容であるかを判断し、プロジェクト計画に反映することもRDの重要な役割です。
