要件定義とは

システム開発の初期段階では必ず登場する「要件定義」は、その出来栄えがプロジェクトの成否を大きく左右すると言われるほど重要な工程です。プロジェクトの工期遅延の原因の55%が要件定義のミスから生じているという調査結果もあるほどです。

ここでは、要件定義とは何か・要件定義で行うべきこと・その作成までの流れ・重要なポイント・書き方などについて解説していきます。

【参考】：失敗しない要件定義とリスク対策（IPA）

要件定義のインプットは「ユーザー（クライアント）の要求や要望」です。アウトプットは「ユーザー（クライアント）の要求や要望に対する解決策である要件定義書」です。

システム開発のゴールは、ユーザー側の要求を実現することであり、そのためのシステム開発において、ユーザーの要求に応えるために実装する機能や性能の要件を定め、それらを具体的にどう進めるのかを決定します。ゴールが明確になっていないと、解決法は定まらず、プロジェクト計画も立てられません。

ゴールの認識やベクトルがユーザー（クライアント）側と開発側で一致していることが、プロジェクトの成功に欠かせません。

このゴールイメージに食い違いがあると、プロジェクトが失敗する確率が高まります。どんなに精緻で、どんなに素晴らしいプロジェクト計画が作れても、ゴールの認識が異なれば、出来上がったシステムはユーザー（クライアント）に評価はされません。わかりやすくまとめると、「要件定義はユーザーの要求に対する解決策」と言えるでしょう。

要件定義は何のために行うのでしょうか？それは、ユーザー（クライアント）の要求をシステム化の要件として整理し、開発側とユーザー（クライアント）双方の合意をとるためです。特に受託開発においては、この「合意をとる」ということが非常に重要です。

システム開発プロジェクトで炎上するケースでは、両者の合意が取れておらず、出来上がったシステムが「要求したものと違う」とユーザーの怒りを買う場合が少なくありません。こうした事態を避けるには、要件定義の内容について必ずユーザーの合意、承認を得ておくことが必要です。

システム開発の実際のステップはユーザーに対する「システム提案」から始まり「受注」を経て、要件定義からスタートします。「要件定義工程」の次は「基本設計」です。

すなわち、要件定義のアウトプットは基本設計のインプットになるということです。この「要件定義」に手抜きがあると、「基本設計」工程で「基本設計に必要な情報が不足している」という事態を招き、設計フェーズが止まってしまいます。

設計フェーズに正しいインプットを提供するためには、システム開発の視点も欠かしてはなりません。ユーザーとの合意、システム開発視点の両立は簡単なことではありません。この難しいことに立ち向かうのもシステムエンジニアの役割なのです。

システムエンジニア（SE）とは？仕事内容や年収、必要スキルを解説！

要件定義書と仕様書は同じではないかという見方をする人がいます。要求仕様書というものも存在しますので、混同しがちです。

要件定義書は一般的に、開発側がクライアント（ユーザー）から提示されたRFP「Request for Proposal」（提案依頼書）を元にして作成をします。要求仕様書はクライアント（ユーザー）が開発側（ベンダー）に対して依頼する開発要件を文書化したものです。要求仕様書を精査し、要件定義書の要件を満たしている場合は、それを要件定義書として採用する場合もあります。

RFP(提案依頼書)を作成するメリット、デメリットと活用方法について

要件定義の進め方

要件定義を適切に行うことが、システム開発プロジェクト成功のために重要です。どのような手順で要件定義を行えばよいのかについて解説をしていきましょう。要件定義の流れから紹介していきます。

適切な要件定義を進めるには、きちんと手順を踏むことです。要件定義の正しい手順、基本的な流れについて以下、順を追って解説します。

1.ユーザー要求についてヒアリングする ITベンダーでは、クライアントからRFPの提示を受け、そこからシステム開発案件がスタートするケースが大半です。提案要請を受けた営業担当はシステムエンジニア同行で、改めて詳細のヒアリングを行い、社内に持ち帰って大まかな要件定義に基づく提案書を作成し、クライアントに提示します。

2.ユーザーの要求を細分化する システム開発の受注に至ると、開発側はクライアントにアプローチし、システム化の対象について全体像を把握し、ユーザーヒアリングを通じてユーザー要求の細分化を行い、要件を固めていきます。それらを実際の業務フローに落とし込み、実装する機能に関する洗い出しを行います。

この段階で、ユーザー要求の取りこぼし、業務フローの漏れがないよう十分に配慮をしなければなりません。

3.要件定義書の作成 機能要件の細分化ができたら、要件定義書の作成に入ります。要件定義フェーズで作成するそれぞれのドキュメントは、「基本設計フェーズ」のインプットになります。設計フェーズを意識しつつ、ユーザー要求、要件に漏れや齟齬がないよう、クライアント側と開発側の双方が納得し、合意できるよう要件定義書の作成には細心の注意を払います。

RFPとRFIとの違いとは？エンジニアがシステム開発に活用するコツ

要件定義は手順に従って進めることも大切ですが、守るべき重要なポイントがいくつかありますので、ここではそのポイントを挙げていきます。

1.クライアントの要求は漠然としている 多くの場合、クライアントは自ら機能レベルに落とし込んだ要求を具体的に示してくれるわけではありません。そのため、要求から必要な機能に落とし込むには、クライアントの漠然とした要望や課題、問題点を開発側で引き出し、具体化することが重要です。

また、要件定義を行う上では、クライアント側の関係する人すべてからヒアリングをする必要があります。従って、要件定義の前提として、全面的な協力を得られることが精度の高い要件定義を行う上で欠かせません。

さらに、要件定義についてはクライアントのIT部門の合意のみで、利用部門の合意を得られていない場合には、最終的に大きな手戻りが発生し、検収をしてもらえないケースが起こり得ます。対象システムのオーナーが誰であるのかを最初に確認し、システムオーナーと要件定義内容について合意をとれるようにしておきましょう。

2.要件定義はシステムエンジニアが行う 要件定義のアウトプットは基本設計フェーズのインプットです。基本設計や詳細設計を知らない人に要件定義をさせるのは無理があるでしょう。業務知識は必要ですが、システム開発スキルのない人が要件定義を行うと、システム目線が欠けており、設計フェーズやプログラミングにまで悪影響が及ぶ可能性があります。

要件定義でミスがあると、大きな手戻りが発生したり、工数の大幅な増加を招いたりする原因となります。よくありがちなのは、基本設計・詳細設計の経験がない上級SEやコンサルタントに要件定義を任せた結果、技術的裏付けを得ずに理想論に走ってしまい、結果としてプロジェクトが失敗するケースです。

コンサルタントや上級SEが要件定義に参加するのは構いませんが、システムエンジニアのベテランを必ず交えるようにしましょう。

3.曖昧な記載は厳禁 要件定義の内容に曖昧な部分があると、その解釈も人によって異なり、結果的に設計ミスをする可能性があります。曖昧な部分は、期限を決めて必ず曖昧さを除去しなければなりません。システム更改のプロジェクトで、よくありがちなのは「〇〇の機能については変更せず、既存システムと同様とする」などと、中身を書かないことです。

既存システムの〇〇機能について、クライアントも開発側も完璧に理解しているならともかく、そうでないならこうした定義は厳禁です。初めての人でも分かるように、変更しない機能であっても曖昧にせず、その機能を明らかにするのも要件定義の重要なポイントです。

4.必要な機能であること 要件定義のユーザーヒアリングで、「あったら嬉しい」というレベルの要求が次々と出てくることがあります。ユーザーは「せっかくヒアリングをしてくれているのだから、何でもぶつけてみよう」という気になり、さほど重要ではないことまで挙げてくることが往々にしてあります。

すべての要求に応えると、予算やスケジュールの枠を超えてしまいますので、要求を聞く際には、その必要度合いを確認し、機能要件に優先順位を付けるようにし、最終的に必要な機能に絞れるようにしておきます。

他、「非機能要件」では定義が難しく、特に性能やセキュリティなどについては、実現が困難な目標を定めてしまう、後々開発側の首を絞めることになりかねませんので、実現性の観点から専門分野のエンジニアの参画を求めるとよいでしょう。

要件定義書に記載する項目

ここまで要件定義の流れや、気を付けるべきポイントについて解説しました。ここからは、要件定義書に記載すべき項目（成果物）について解説していきます。併せて、「機能要件」と「非機能要件」の違いについても確認しておきます。

【参考】：ユーザーのための要件定義ガイド第 2 版（IPA）

要件定義書のアウトプットが基本設計のインプットになることから、要件定義の要はシステムに関する項目だということは理解できたと思います。

かつ、要件定義書はクライアント側の合意や承認を得る必要があることから、クライアントにも分かりやすい内容でなければなりません。以下、システムに関する項目について挙げていきます。

1.システムの概要と背景・目的など クライアントに対して、開発するシステムの概要や背景、予算やスケジュール、実装する機能、業務フロー（現行とシステム導入後）などについて確認と合意を得るためのドキュメントです。どのような項目を盛り込むかは、個々に異なりますが、テンプレートやサンプルを利用する場合は以下のサイトが手助けになります。

【参考】：IPA公式サイト_超上流から攻めるIT化の事例集：要件定義

2.機能要件に関する内容 機能要件はヒアリングしたクライアントの要求内容であり、これがプロジェクトのゴール（実現目標）となります。機能要件はシステムのゴールを記述しますが、システム化によって何がどう変わるのかが分かる内容であることが求められます。

3.非機能要件に関する内容 非機能要件は、クライアントが機能要件以外で求めている要件を指します。例えば、システムの性能（レスポンスや拡張性など）・セキュリティ・保守サービスなどに関する要件です。非機能要件は、機能要件と同じく重要なシステム開発のゴールです。できるだけ、数値化できるものは数値で示すようにします。

機能要件とは？非機能要件との違いや書き方をわかりやすく解説

プロジェクトの成否を左右する非機能要件の一覧について詳しく解説！

要件定義はシステムエンジニアの勲章

要件定義の精度がシステム開発の成否を左右することは理解できたと思います。

要件定義で、システムエンジニアはクライアントの要求を完全に理解し、その背景や業務、システムに必要な機能などを設計書に落とし込めるレベルまで漏れなくまとめなくてはなりません。これは大変な作業ですが、やりがいのある仕事です。

そして、システムがクライアントの要求通りに完成して、クライアントからお褒めの言葉を頂いた時に、エンジニアとしての無常の喜びを感じるでしょう。システムの成功の鍵を握る要件定義書が自身の勲章と呼べるようになるよう、システムエンジニアとしてのスキルアップを目指してください。