要件定義とは？概要と重要性、進め方から成果物までご紹介

エンジニアの仕事内容を調べていると、『要件定義』という工程を目にすることがあると思います。簡単に説明をすると、『クライアント企業などが開発をしたい内容をまとめる工程』になりますが、要件定義をしっかりとしておかないとプロジェクトの遅延や予算超過など、損害が発生する可能性が出てきます。

この記事では、要件定義の概要と重要性、進め方などをご紹介しています。ぜひともご確認ください。

1. Contents

   • 1 要件定義とは
   • 2 要件定義の重要性
   • 3 システム開発における要件定義の位置づけ
     • 3.1 企画
     • 3.2 要件定義
     • 3.3 基本設計・詳細設計
     • 3.4 実装・テスト
   • 4 要件定義で定義すべき２つの要件
     • 4.1 機能要件
     • 4.2 非機能要件
   • 5 要件定義の進め方
     • 5.1 事業サイドの要求を整理する
     • 5.2 業務フローやシステムに求められる要件の整理
     • 5.3 利害関係者との合意形成
   • 6 要件定義のサンプル・成果物例
   • 7 要件定義と似た言葉の違い
     • 7.1 要件定義と基本設計の違い
     • 7.2 要件定義と要求定義の違い
   • 8 まとめ

   要件定義とは

クライアントから提案依頼書（RFP）などが支給され、それを元にヒアリング等を実施し、どんなシステムを作って欲しいのか明確化していったとします。

しかし、それをそのまま開発を行うプログラマーに伝えても、開発を行うことは困難です。なぜなら、クライアントはシステム開発に詳しくないため、システムを開発するために必要な情報が欠けているからです。

そのため、実際にシステムとして開発できる形に落とし込んでいく必要があります。

受注側から、開発可能なものとして現実的な提案を行い、クライアントとの合意形成を行っていくことで、そうした要件が決まります。このうち、業務要件、機能要件、非機能要件といった内容を確定していく工程を要件定義と呼び、合意の取れた内容を書面などにまとめたものを要件定義書と呼びます。

要件定義は、開発しようとするシステムの規模によって、必要とする情報量が変わります。ですが、規模の大小に関わらず、このフェイズは発生することになります。

1. 要件定義の重要性

要件定義では、システムを開発する上で、業務として発生する要件全てを明らかにします。

要件定義が確定することで、受注側は、やること、やらなくていいことが明らかになります。こうして明らかになった要件を、クライアントに分かりやすく伝え、そこで決まったものを作成することで、必要とするシステムが手に入ることなどを理解して貰う必要があります。お互いの認識齟齬を減らすことができれば、やり直し等による予算の超過やスケジュールの遅延を避けることができます。更には、クライアントの満足のいくシステムを納品できる可能性は高まります。

1. システム開発における要件定義の位置づけ

実際にシステム開発を行う上で、要件定義がどのような位置づけにあるのか見ていきます。

1. 企画

企画はクライアントが作成するものです。商品開発や、サービスを立ち上げる際などに、まずは企画書を作成します。例えば、どの程度のユーザーが想定され、ユーザーにとってどのような価値があるのか、またそれにより、どれほどのビジネスチャンスが生まれるかなどをまとめたものです。企画が通り、プロジェクト化することで、初めて課題（開発すべきシステム）が生まれ、開発依頼の機会が訪れます。

1. 要件定義

上記でプロジェクト化した内容の業務要件をまとめ、開発するシステムの機能要件、非機能要件を定めます。また、この工程では、やること、やらないことを決め、インターフェースやDBなど開発上の細かなことは決めません。

1. 基本設計・詳細設計

基本設計とは、クライアントのために作成されるもので、外部設計とも呼ばれます。クライアントが理解できる範囲で可能な限り細かな仕様を決めていきます。反対に詳細設計はシステムを開発するプログラマーが作成するもので、内部設計とも呼ばれます。基本設計を受けて、作成すべきシステムをどのように実装するかを決めます。

また、要件定義、基本設計、詳細設計を合わせて上流工程と呼びます。これらの工程が定まることで、開発すべきシステムが確定し、予算やスケジュールを確定させることができます。

そのため、この段階で、再見積もりという形で予算やスケジュールを改めて決定することもあります。

1. 実装・テスト

ここからはいわゆる下流工程と呼ばれるものです。詳細設計書に基づきプログラミングを行い、実際のシステムを構築していきます。基本的にはプログラマーが担当しますが、企業によってはシステムエンジニアも開発に加わります。また、テックリード（リードエンジニア）と呼ばれるエンジニアチームのリーダーがいる場合、システムエンジニアは連携を取りながら、滞りなく開発が進むようにマネジメントをおこないます。

プログラミングが終わったシステムをテストします。テストには『単体テスト』、『結合テスト』、『総合テスト』があります。

また、企業やプロジェクトによっては、起こりうるトラブルなどを詳細に想定しておこなう『運用テスト』という工程を組む場合があります。加えて、単体テストはプログラマーや『テスター』と呼ばれるエンジニアがチェックをすることが一般的で、システムエンジニアは結合テスト、あるいは総合テストからチェックをおこないます。

1. 要件定義で定義すべき２つの要件

システム開発の全体の流れを確認したところで、要件定義の段階で決めておくべき２つの要件について説明します。

1. 機能要件

機能要件とは、開発するシステムに関する要件全てのことです。例えば、動画配信サービスを開発する場合なら、管理者側の機能要件や、一般ユーザーの機能要件など、そのサービスを運用する上で必要な機能を全て洗い出します。管理者側の機能としては、ログイン機能が必要だとか、ユーザーへのメール送信機能が必要といったことなどです。また、一般ユーザーとしては、会員登録機能とか、決済機能や、検索機能が必要といったことです。前述したように、ここでは機能の細かなことは決めません。

1. 非機能要件

機能要件以外の全ての要件についても確定する必要があります。例えば、動画配信サービスを開発する場合なら、どの程度のユーザー数を想定しているのか、動画の読み込み速度はどの程度にするか、24時間稼働する必要があるかなどです。

1. 要件定義の進め方

では、要件定義の進め方について詳しく見ていきましょう。

1. 事業サイドの要求を整理する

要件定義の開始段階は、クライアントと初めましての状態です。この段階では、クライアントがどんな事業を行っていて、何を欲しているのか、ほとんど何も知らない状態です。クライアントによっては、提案依頼書（RFP）などを支給してくれる場合もありますが、いずれにしてもヒアリングを行う必要があります。まずはクライアントがなぜシステムを開発したいと思ったのか、その理由を知る必要があります。背景や、課題、理想とする状態など、クライアントの事業サイドの要求を整理し、プロジェクトのゴールをこの段階でしっかりと定めます。

1. 業務フローやシステムに求められる要件の整理

次に、具体的にどの業務に対してシステムが使用されるのかを、業務フロー図などを用いて確認していきます。その業務を誰が何の目的で行っていたのか。システムを代替することで、どの程度効率化され、ミス防止が期待できるか、実際にどんなシステムを用いるのか、など一つ一つ項目をまとめます。クライアントの業務フローを確認するこの工程を、業務要件とも呼びます。

1. 利害関係者との合意形成

限られた予算の中で開発を行う場合、どうしても予算上の問題が出てきます。クライアントと受注側で認識のずれが生じれば、衝突することもあるかもしれません。例えば、受注側では必要と思っている機能を、クライアントは必要と感じていない場合が考えられます。反対に、クライアントが欲しいと言っている機能が、そこまで必要なものではなく、また予算の都合で作成できない場合もあるでしょう。どんな場合でも、クライアントと十分に話し合い、合意形成しながら進めていく必要があります。

1. 要件定義のサンプル・成果物例

要件定義が終わる頃には、要件定義に必要な全ての項目が決まり、ドキュメント（要件定義書）が完成します。成果物として、クライアントに納品を定めている場合は、納品します。クライアントの業務形態、開発するシステムにより様々のため、要件定義書に定まった形はありませんが、サンプルとして、下記の要件定義書を紹介します。

参照：建設キャリアアップシステム要件定義書

1. 要件定義と似た言葉の違い

要件定義としばしば混同される用語として、基本設計と要求定義について簡単に解説します。

1. 要件定義と基本設計の違い

ウォーターフォール型開発では、要件定義の次の工程として、基本設計があります。ウォーターフォール型開発では、基本設計に進んでから、その前の工程である要件定義に戻ることはできません。

そうした前後関係があるように、要件定義の内容を受けて、基本設計のフェイズが始まります。基本設計では、要件定義で決められた各要件の詳細を確認していきます。

例えば、動画配信サービスを作成する場合、管理側の機能やユーザー側の機能を開発します。その際に必要な機能の洗い出しは要件定義で行います。

基本設計では、そこで決まった機能のインターフェースやDBなど実装すべき全てを決めます。

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

要求定義は、要件定義のフェイズで行います。両者はほとんど同じ内容になりますが、要件定義を受注側が行うのに対し、要求定義はクライアントが行います。

要求定義は、要件定義をよりスムーズに行うためにあると便利です。要件定義が必須なのに対し、要求定義は必須ではありません。

1. まとめ

要件定義では、クライアントと初めましての状態から、プロジェクトのゴールを定め、作成すべきシステムを決めます。

この段階で十分なコミュニケーションを取っていないと、言った言わない問題が発生したり、予算の超過や、スケジュールの遅延といったトラブルが発生する可能性が増します。

プロジェクトが成功するかしないかは、このフェイズにかかっていると言っても過言ではありません。

要件定義の経験を十分に積んでいれば、そのことを肌身で感じているかもしれませんが、これからの方はこの記事を参考に、理解を深め、プロジェクトを成功に導く助けとしていただければ幸いです。