システム要件定義とは？サンプル付きで成果物作成までの流れやポイントを解説

要件定義は、ITプロジェクトを成功させるために必要不可欠な工程です。顧客に要求される機能や性能、制約条件を明らかにし、要件を定義します。要件定義を進めるためには、要求定義やソフトウェア要件定義との違いや具体的な成果物のサンプルを知らないと、品質に影響を及ぼす可能性があります。今回は、システム要件定義の概要や要求定義との違い、成果物作成までの流れなどを解説します。

1.システム要件定義とは

要件定義とは、システム開発やWebサイト構築、ソフトウェア開発において必要な機能や顧客の要求条件を明確に定義する開発工程の1つです。下記は、ウォーターフォール開発の開発工程です。

1. システム化計画

2. 要件定義

3. 基本設計

4. 詳細設計

5. 実装

6. テスト

2番目に位置する要件定義は、プロジェクトを成功させるために重要な工程であり、開発内容や範囲を明確にするための基盤となります。

経営層やユーザーとなる企業の目標や要望を理解し、それらを具体的なシステムやソフトウェアの機能・必要な性能・操作性・品質・制約条件に落とし込みます。この工程によって、システムの利用目的や目標が明確になり、開発の方向性や運用体制・スケジュールが定まります。

この工程は、プロジェクトの成功のために大きく関わるため、十分なリソースを割いて行うことが重要です。また、顧客とのトラブル防止やスムーズな開発を実現するために欠かせません。

これらの項目を成果物としてまとめたものをシステム要件定義書と呼びます。システム要件定義書はシステムの開発側が作成するものですが、開発側だけでなく顧客への説明にも使用するため、専門的な知識がない人でもわかるような書き方が求められます。

2.要件定義と要求定義の違い

要件定義と似た用語として、要求定義と呼ばれるものがあります。どちらもプロジェクトの開始前に行われる重要な工程ですが、それぞれの役割は異なります。

要件定義では前述の通り、システムの利用目的や目標に基づいて、システムに必要な機能や要求条件・性能・品質などを明確に定義する工程です。

一方で要求定義とは、利用ユーザーや関係者からの要望を収集し、整理する作業です。そのため、システムを利用する顧客が担当する工程です。

現場の業務で解決したい課題や問題などを洗い出し、システムにすることによってなにを実現したいのかを決定し、要求定義書という成果物を作成します。

あくまで、要望や希望を書いたものであるため、全ての機能がシステムで実装されるわけではありません。開発側はその要求定義書をもとに要件定義を作成し、開発の大枠を決定します。

このように、どちらもシステム開発に必要な工程ですが、要件定義と要求定義では役割が異なります。

関連記事

要件定義と要求定義の違いは？進め方と注意するべきポイントなどを徹底解説！

3.システム要件定義とソフトウェア要件定義の違い

要件定義の中でも、システム要件定義とソフトウェア要件定義を分けて行うことがあります。この2つの違いについて解説します。

端的に言うと、ソフトウェア要件定義はシステム要件定義の一部分のことです。

ソフトウェア要件定義とは、開発プロジェクトのなかでソフトウェアに関する要件だけを定義します。システム要件定義とは、ソフトウェア要件定義も含めた、システムの全体的な要件を定義する工程のことです。

そもそもソフトウェアとは、開発するシステム上に存在するプログラムです。ゆえにシステム開発では必要に応じて、ソフトウェア・ハードウェア・ネットワーク・運用体制などの要件定義を行います。

4.システム要件定義から成果物作成までの流れ

要件定義は、システム開発の工程のうちの1つですが、成果物である要件定義書作成までにはどのような手順が必要なのでしょうか。ここでは、要件定義書作成までの流れについて解説します。

ステップ1:ユーザーから要求をヒアリング

はじめに、発注側である顧客の業務要件や要求定義を明確にするために、顧客のヒアリングを行います。ヒアリングは、要求が整理できるまで複数回行います。

発注側の担当者だけでなく、作成するシステムを利用する予定のユーザーもヒアリングの対象です。

誰かの要望を聞いていなかったり、一部の大きな意見を過度に反映したりしていると後になって不満が噴出し、要件定義をやり直すことになる可能性が生まれます。そのため、ヒアリングの対象の洗い出しも必要です。下記は、関係者の例です。

• 経営者

• 業務部門

• 情報システム部門

ヒアリングでは、ビジネス概要からビジネスを推進するうえでの課題や問題を解決するために必要な機能や、ユーザーがシステムで何をどう解決していきたいかを細かく詳細に行います。そのほかにも、システムそのものの機能だけでなく既存システムや外部サービスとの連携が必要かや、将来的に連携させたいのかを確認します。

また、システムを取り巻く環境についても確認しておくことが重要です。具体的には、セキュリティに関する規定や要望、制約などです。

ステップ2:要求内容の分析

ヒアリングより、システムに必要な要求が明らかになれば要求内容を1つずつ吟味し、実現可能な要求なのかを整理します。技術的に実現できないことをはじめ、予算や工期なども考慮しなければならないため、全ての要求が実現可能になることはほとんどありません。

その際は、実現不可能な理由と代替案を検討し、顧客に提示します。何度かやりとりを繰り返し、お互いに納得ができる方法を探します。

代替案1つにしても、開発のしやすさも考慮して提案しましょう。技術的に難易度が高いものであれば、技術力によってはバグの発生リスクや開発工数の長期化によって費用が高くなる可能性が発生するためです。

ステップ3:要件定義書の作成

顧客との折衝を繰り返し、要求内容が全て定まったら要件定義書を作成しましょう。要件定義書は、次の工程であるシステム基本設計や詳細設計のベースになります。

システム概要をはじめ導入目的、システム導入後の業務フローなどの詳細な項目を要件定義書に含めましょう。ここでは、要件定義書の作成について説明します。

プロジェクト課題と目標の明確化

発注側から得たデータを分析し、プロジェクトで解決する課題や指標となる目標を明確にします。顧客の悩みを明確にするためには、最先端技術への知見や顧客の業界知識など、幅広い知識が必要です。

システム要件の定義

予算や工期、技術を考慮しながら発注側の要望および業務要件をシステム要件に落とし込み、実現できる要望と実現不可能な要望を明確にします。ここで開発するシステムの全体像を決定し、以下のような項目を定義しましょう。

• システム構成

• システム概要

• システム導入の目的や解決できる課題

機能要件定義

発注側が要求し、システムに必ず搭載する機能のことを機能要件と呼びます。機能要件は、システム導入後の業務効率が直結することもあるため、丁寧に作成することを心がけましょう。

機能要件とは、例えばシステムで処理するデータの種類や帳票作成の自動化などです。また、予算や工期に合わせて、機能ごとに優先順位をつけておくことも必要です。

非機能要件定義

非機能要件とは、機能要件以外のことをいいます。IPAでは、非機能要件を下記の6つに分類しています。

ここには操作性が含まれていませんが、操作性に関する画面レイアウトやウイルス対策ソフトなども非機能要件に含まれます。これらの非機能要件は、実際に使うユーザーの満足度に直結するため、しっかりと定義する必要があります。

プロジェクト計画の立案

ここではシステム開発プロジェクトの計画を立案します。予算やスケジュールの見積もり、開発メンバーと工数を決定します。この段階では、プロジェクト全体でどの程度の人月が必要なのかを把握しておくことが必要です。

実際の作業の内容を大まかにイメージできていることで、適切なプロジェクト計画が決定します。もし、曖昧であれば開発途中でリソースが不足する可能性が高くなるでしょう。

要件定義書作成

ここまでで決定した内容をベースとして最終的に要件定義書を作成しましょう。要件定義書に記載する項目は下記の通りです。

5.システム要件定義に必要なスキル

上流工程である要件定義を行うために必要なスキルについて解説します。

顧客の要求を引き出すコミュニケーションスキル

顧客から適切に要求を引き出すためには、ヒアリング能力とコミュニケーションスキルが求められます。

顧客には、改善してほしい内容の全てを説明できていない場合も少なくありません。

そのため、システム完成後にほしい機能が搭載されていないとなればトラブルにつながります。

細やかなところまで、顧客の意図に寄り添って要求を引き出していくコミュニケーションスキルが必要です。また、ユーザーの言いなりになるのではなく、実現可能か判断する力も必要になるでしょう。

無理難題な要求をされた場合にも、断ることができるように開発に関係する知識が求められます。

スケジュールとリスク管理スキル

要件定義は、開発工程の一部分ですがプロジェクト全体の進行を考えなければいけません。そのため、スケジュール管理スキルが必要です。また、顧客の要求を全て叶えられない場合もあるため、納期や予算・実現可能な内容なども含めて検討できるリスク管理スキルも求められます。

下流工程で顧客との意見が食い違いするようなトラブルを避けるためには、上流工程である要件定義で全体的なスケジュールを考えながら、トラブルやミスを最小限にするために大切なスキルです。

実現可能なシステム設計を把握するスキル

スムーズなシステム開発を行うためには、顧客の要求の内容をシステムとして具体的にイメージできるスキルが必要です。そのため、開発の知識や技術も求められます。

実際に要件定義の段階で、担当者が実現可能だと思って受注したものの、開発メンバーが苦労するようなことは多くあります。そして納期や予算の再検討が必要となることもしばしばです。このような事態を防ぐためには、要件定義の段階で完成したシステムの動きを明確にイメージできれば、適切にプロジェクトを進められるでしょう。

6.システム要件定義書作成のポイント

顧客とのやりとりをスムーズに行うためや、プロジェクトを成功させるためにはシステム要件定義書の質は重要です。ここでは要件定義書作成のポイントについて解説します。サンプルや例も記載していますので、ぜひ参考にしてみてください。

成果物サンプルや例を活用する

システム要件定義書は、成果物のサンプルや例を参考にすると作成しやすくなるでしょう。

もし、社内に過去の成果物がある場合は積極的に活用してください。ほかにも、インターネット上でも実際の成果物の閲覧が可能です。下記は、IPAや経済産業省のサンプルです。

• IPAのサンプル例やフォーム

• 経済産業省の要件定義書サンプル

• 環境省自然環境局総務課の要件定義書サンプル

フレームワークを利用する

記載内容の抜け漏れを防止するために、フレームワークを活用しましょう。フレームワークを活用することで曖昧さがなくなり、ヒアリングの精度も向上します。ヒアリングにおける代表的なフレームワークは5W2Hです。

• Why：なぜシステム化を行いたいのか、背景となるエピソードなど

• What：課題や改善したいポイントは何か、開発によって何を実現したいか

• Where：要求を満たすための開発範囲はどこからどこまでか

• Who：システムの利用者は運用者は誰なのか

• When：いつまでに開発が必要なのか

• How：どのように要求と要件を実現するのか

• How much：システムの実装に関する予算はいくらで組むのか

要件定義書の内容に間違いがあると、下流工程のスケジュールを圧迫しかねません。品質の低下につながるため、抜け漏れがないように努めましょう。

ユーザーの業務やシステムを理解する

発注側のユーザーの業務や業界、既存システムの仕様理解は要件定義において重要です。業務の流れや使用システム、問題点を把握することで新しいシステムに搭載すべき機能を考案しやすくなるためです。

ニーズを理解できていないまま、システム要件定義書を作成しても何度も修正が必要となってしまい、リソースを圧迫するでしょう。

専門用語は避けてわかりやすい書き方にする

システム要件定義書を作成する際は、専門用語の多用に注意が必要です。システム要件定義書は、開発側と発注側の情報共有のための成果物です。

関係者の中でもそれぞれ専門分野が異なるため、わかりづらい内容だと合意内容の認識に違いが生じる恐れがあります。

関連記事

基本設計と詳細設計の違いは？進め方や注意点などシステム開発の工程別に解説！

7.まとめ

今回は、ITプロジェクトに関わる企業のシステム担当者やこれから新しいシステム開発を検討している経営者、システムエンジニアとしてキャリアアップを目指している方に向けてシステム要件定義について解説しました。

上流工程の2番目の工程である要件定義は、プロジェクトを成功させるために重要な工程であり、十分なリソースを割いて行うことが重要です。

そして、要件定義で決定した事項はシステム要件定義書として、顧客と共有します。システム要件定義書は開発側が作成するものですが、顧客への説明にも使用するため、専門的な知識がない人でもわかるような書き方が求められます。

IPAや経済産業省には要件定義書のサンプルも掲載されていますので、ぜひ参考にして成果物を作成してみてください。

本記事が皆様にとって少しでもお役に立てますと幸いです。