2024.03.01
「要件定義」は、顧客満足度の高いシステムを開発するために重要となるプロセスです。しかし、「要件定義をどのように進めれば良いか」「何を決めるべきか」など疑問を抱える方も多いのではないでしょうか。
今回は、システム開発における要件定義とは何か、基本から分かりやすく解説します。要件定義で決めるべき要素や流れ、ポイントもお伝えするため、ぜひ参考にしてください。
- もくじ
1．システム開発における要件定義とは
要件定義とは、これから開発するシステムに求められる要素を明確に定義するプロセスのことです。正しい方向性で開発を進めていくために、クライアントが求めるシステムのあるべき姿を明確にする重要なプロセスといえます。
要件定義はシステム開発の初期に行われ、その内容を踏まえて以降の設計や実装などのプロセスを進めていきます。そのため、要件定義に不備があれば以降のプロセスを正しく進めることはできません。要件定義は、システム開発の成否を左右する重要なプロセスです。
1-1 要件と要求の違い
要件定義に関わる言葉で、「要件」と「要求」の2つがあります。両者は混同されがちですが、厳密には異なる概念です。これらの違いを押さえておきましょう。システム開発における「要求」とは、「クライアントがシステムで実現したいこと」です。つまり、要求はクライアント目線の概念であり、開発者の目線は含まれません。
一方、システム開発における「要件」とは、「システムがどうあるべきか」です。要件は、要求を踏まえて定義する必要があるものの、開発者の目線も含まれます。
つまり、クライアントが抱える「要求」が前提としてあり、それを開発者が整理・分析してシステムとして実現するための「要件」に落とし込みます。この工程が要件定義です。
1-2 要件定義と設計の違い
要件定義と同じく、システム開発に欠かせないプロセスとして「設計」があります。これらの違いも整理しておきましょう。
システム開発における「設計」とは、「どのようにシステムを実現するか」を具体化するプロセスのことです。設計は、要件定義を踏まえて検討する必要があり、プログラムの流れやデータベース構想などのより具体的な要素に落とし込みます。
つまり、要件定義で「システムがどうあるべきか」を明確化したうえで、設計で「具体的にどう実現するか」を決めるのです。
2．要件定義で決めるべき要素
要件定義でどのようなことを決めるべきなのか、把握しておきましょう。要件定義で決めるべき主な要素は、次の4つです。
2-1 前提条件・制約事項
まず、システム開発の前提条件や制約事項を明確にしておきましょう。たとえば、クライアントの予算やスケジュール、開発プロジェクトの人員やスキルなどです。つまり、クライアントがどうしても譲れない要望や、開発プロジェクトの事情などを明確にします。
こうした前提条件や制約事項は、以降のプロセスにも大きく影響を及ぼします。そのため、要件定義の段階で認識の相違がないようにしておくことが大切です。
2-2 機能要件
要件定義においては、必ず「機能要件」を定義します。機能要件とは、クライアントがシステムに対して明示的に要求している機能のことです。つまり、それがなければクライアントのニーズには応えられない、必ず実装しなければならない機能といえます。
機能要件がクライアントのニーズと食い違っていると、そもそもリリース自体が難しくなるでしょう。
2-3 非機能要件
要件定義では機能要件にフォーカスされがちですが、「非機能要件」も重要です。非機能要件とは、クライアントが明示的に要求する機能ではないものの、システムに備わっているべき性質のことです。応答速度やデータ容量、セキュリティ、ユーザビリティ（使いやすさ）など、非機能要件は多岐にわたります。
「操作に対する応答はXX秒以内に行われること」のように、クライアントが明示的に求めることは多くありません。しかし、あまりに応答時間が長ければ、クライアントからのクレームにつながるでしょう。こうした問題が後から生じることを防ぐために、システムがどのように振る舞うべきかを、非機能要件で明確にしておくことが大切です。
非機能要件についてより詳しく知りたい方は、次の記事を参考にしてください。
2-4 技術要件
要件定義の段階で「技術要件」も決めておくことが望ましいといえます。技術要件とは、「どのような技術を用いるのか」を明確にする条件のことです。
たとえば、既存システムへの機能拡張といった案件の場合、互換性を保つことが大前提となるケースが多いです。この場合、すでに運用されているハードウェア・ソフトウェアと互換性のある技術を選定しておく必要があるでしょう。
ただし、後工程の設計段階で技術的な課題に直面し、技術要件を変えざるを得ないケースも考えられます。そのため、必ずしも要件定義段階で最終確定するわけではありません。
3．要件定義の大まかな流れ
要件定義の流れを知っておきましょう。要件定義は、大まかに次の3ステップに沿って進めていきます。
3-1 要求のヒアリング
まずは、クライアントから要求をヒアリングする必要があります。クライアント側・開発側で打ち合わせを開催し、システムに何を求めているのかを抽出します。
システムに対するイメージがまだ固まっておらず、クライアントの要求が漠然としているケースも少なくありません。その場合も、できる限りクライアントから多くの情報を引き出し、潜在的な要求を抽出しましょう。
3-2 要求の分析
クライアントから抽出した要求を整理し、分析を行います。「技術的に実現できるのか」「運用上のリスクはないか」「より良い解決策はないのか」など、開発者の目線も含めて分析することが大切です。
ただし前提条件・制約事項の関係上、すべての要求を実現できるとは限りません。そのため、優先順位の高い要求から盛り込むことを考えると良いでしょう。
要求には「必ず実現してほしい」という必須要求、「実現すれば嬉しい」という希望要求があります。このように各要求を分類すると、優先順位が付けやすくなるでしょう。
3-3 要件定義書の作成
要求の分析結果を踏まえて、要件定義事項をまとめた「要件定義書」を作成します。要件定義書には、そのシステムを開発する目的や、クライアントが解決したい課題なども盛り込みます。作成した要件定義書はクライアントに共有し、フィードバック事項があれば反映が必要です。
クライアントから合意が得られれば、要件定義書の完成となります。設計以降の開発プロセスは、要件定義書の内容に沿って進めていきましょう。
4．システム開発を成功につなげる要件定義のポイント
要件定義が正しく行えないと、システム開発の成功にはつながりません。システム開発を成功につなげるために、要件定義のポイント3つを押さえておきましょう。
4-1 実現性を念頭に置く
要件定義では、本当に要求のとおりに実現できるのか、システムの実現性を念頭に置きましょう。あまりに高い理想を要件定義に盛り込んでも、予算やスケジュールの都合上、実現できないことも考えられます。実現不可能な要件に沿って開発プロジェクトを進めると、後工程で破綻してしまうでしょう。そのため、前提条件や制約事項を考慮して、実現性の高い要件を考えることが大切です。
4-2 トレーサビリティを確保する
要件定義と、後工程のトレーサビリティ（追跡可能性）を確保することが、品質向上のために重要です。各要件と関連する後工程の要素を正しく紐付けし、相互に連携が取れるようにします。要件管理ツールを活用してトレーサビリティを確保すれば、要件に変更が生じた際にもスムーズに対応が可能です。
トレーサビリティについては、以下の記事でも詳しく解説しています。
4-3 クライアントに伝わる表現を心がける
要件定義書は、クライアントも必ず目を通します。そのため、クライアントにも伝わる表現を心がけましょう。特に、IT業界でないクライアントの場合は、業界用語を使用しても伝わらないケースがあります。このように伝わらない表現を多用すると、余計なやり取りに手間がかかってしまうため、できる限り避けると良いでしょう。
まとめ
要件定義とは、これから開発するシステムに求められる要素を明確に定義するプロセスのことです。要件定義を適切に行えるかどうかで、システム開発の成否が変わることも考えられます。
要件定義で決めるべき要素や進め方を正しく把握し、システム開発を成功させましょう。要件定義の際には、今回の内容をぜひ参考にしてください。
なお、要件定義だけでなくソフトウェア開発のさまざまな工程を学んでいる方には、勉強用アプリ「テス友」がおすすめです。オリジナルの模試問題が400問以上あり、分かりやすい解説や用語集もあります。ソフトウェア開発の理解を深めたい・ソフトウェアテスト資格を取得したい方は、ぜひご利用ください。
ソフトウェアテスト資格完全攻略「テス友」
「ソフトウェアテスト資格完全攻略 テス友」は、Qbookに登録することでご利用いただける、テスト技術者資格認定の勉強用アプリ/ウェブサービスです。
