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