要件定義書と要求仕様書の違いとは？
システム開発プロジェクトに加わると、「要件定義書」や「要求定義書」、時には「要求仕様書」といった言葉を聞く機会が増えます。では、「要件定義書」や「要求仕様書」は何の目的で作成され、両者にはどういった違いがあるのでしょうか？
システムエンジニアを目指す方は、それらの目的や意味、違いをしっかり押さえておく必要があります。ここでは「要件定義書」と「要求仕様書」の違いを題材として、システム開発の基本について解説していきます。
要件定義書とは
システム側であるシステム開発担当者が作成する「要件定義書」には、次の2つの側面があります。
1.クライアント側からの要求事項をとりまとめた「要求仕様書」の内容を実現するために、システムに必要な機能と実装方法を取りまとめたシステム仕様書
2.開発システムに求められている機能について、プログラムの機能・データベース・通信などを含めて定義した仕様書
「要件定義書」は、システム開発における基本設計や詳細設計のベースとなり、「クライアントの要求に応えるための羅針盤」と言えます。「要件定義書」には「機能要件」に加え、「非機能要件」としてシステムの性能・信頼性・拡張性・セキュリティなどを記述します。
要求仕様書とは
「要求仕様書」には次の2つの側面があります。
1.クライアントの要求、希望などを記述した仕様書
2.クライアントの要求や希望の中でも、システム開発で必要なものを示した仕様書
要求定義は「発注側として何を実現したいのか」を明らかにすることです。この漠然とした要求を、システム開発で実現する内容に落とし込み、ドキュメントにしたものが要求仕様書です。
要求仕様書の作成主体はあくまでもクライアント側ですが、クライアント側に作成スキルがないケースでは、開発者側が作成するケースがあります。
これまでシステム開発の主流だった「ウォーターフォールモデル」では、クライアント側の「要求定義」を「要件定義書」で実現手段に置き換えて表現し、基本設計や詳細設計に引き継いでシステム開発を進めていました。
一方、最近主流の「アジャイルモデル」では、開発工程の境界が曖昧で、実際にシステムを作りながら、クライアント側の確認を取り、「ここはこうしてほしい」という要求を仕様書に記述していきます。アジャイルモデルではこれが要求仕様書であり、要件定義として表現を変えながら開発を進めていきます。
以上を整理すると、クライアント側の「ここはこうしてほしい」という要求定義を示したものが「要求仕様書」であり、システムに求められる機能、その実装方法を整理したものが「要件定義書」です。
要件定義書と要求仕様書、要求定義書の違い
要件定義書と要求仕様書についてそれぞれ解説しましたが、他に「要求定義書」と呼ばれるものを用いることがあります。どれも名称が似ていますが、そもそも要件定義書は正式に書くと「システム要件定義書」であり、要求定義書は「業務要求定義書」の略です。
クライアント側の要望内容を取りまとめた「要求仕様書」と呼ばれるものもありますので、それぞれの違いを押さえておきましょう。
■要件定義書 クライアント側の要望に沿い、「システムに対する要望内容はこれでよろしいですね」とクライアント側の合意、承認を得るためのもので「システム側」が作成します。
■要求定義書 システムに求める詳細の仕様や機能などをシステム側に伝える文書です。開発システムに対するオーダーが記載されており、「クライアント側」が作成します。
■要求仕様書 クライアント側の要望内容を書き留めたもので、本来はクライアント側が作成すべきものですが、システム側が作成するケースが多くあります。要求仕様書がシステム開発に必要な内容をすべて満たしていれば、要件定義書の代用となることもあります。
IT業界に精通した専任アドバイザーと豊富な求人で、
あなたの転職活動を丁寧にサポートします。
要件定義書や仕様書作成を担当するエンジニアは？
要件定義書や要求仕様書はシステム開発側が担当しますが、これらの書類を作成するのはどのエンジニアが担当するのでしょうか。また、システム開発においてどの段階で任されるのか、エンジニアの年収情報と併せて紹介します。
システムエンジニアが担当することが多い
要件定義書や仕様書の作成は、システム開発においてプログラムの前段階である「上流工程」と呼ばれる仕事です。この工程はシステムエンジニアが担当することが多く、それを元に下流工程を担当するプログラマーなどにシステム作りを依頼し、理想通りのシステムを開発していきます。
どの段階で要件定義書作りを任される？
前述の通り、要件定義書などの作成はシステム開発における前段階に行われます。ウォーターフォールモデルでは、ここをしっかりと明確化させることで修正の手間を取る「後戻り」を防ぎます。
一方、アジャイルモデルではスピード重視且ついつでも微調整ができるよう、「とりあえず作ってみる」というイメージで開発を進めます。
どちらも要件定義書は上流工程で作成されますが、前者はしっかりと作り込み、後者は要件定義書にそこまで時間を要しません。
システムエンジニアの年収
ここでは、要件定義書などの作成を担当するシステムエンジニアについて深掘りするために、平均年収や年収アップの方法について紹介します。
「マイナビエージェント 職種図鑑」でのシステムエンジニアの平均年収は431万円、経済産業省2017年発表の「IT関連産業の給与等に関する実態調査結果」から近い職種のSE・プログラマ（ソフトウェア製品の開発・実装）を参考にすると、平均年収568万円と分かりました。
国税庁2020年発表の「民間給与実態統計調査」における民間企業平均年収は433万円なので、システムエンジニアは一般平均年収と比較して、やや高めの年収を目指せることが分かります。
システムエンジニアはスキルや実績を積むことで、年収を上げやすい職種です。要件定義書や仕様書作りはシステム開発ではとても重要な部分であるため、ここをしっかりと作れるようになると開発もスムーズに進み、評価にも繋がりやすくなります。
さらなる年収アップを望む場合は、資格取得や好条件での転職なども有効です。
【参考】：マイナビエージェント 職種図鑑 ※【平均年収 調査対象者】2020年1月～2020年12月末までの間にマイナビエージェントサービスにご登録頂いた方 【参考】：IT関連産業における給与水準の実態① ~ 職種別（P7） 【参考】：民間給与実態統計調査-国税庁
開発工程モデル
前述したようにシステム開発のプロセスにはさまざまなモデルがありますが、代表的な開発工程モデルである「ウォーターフォールモデル」と「アジャイルモデル」について改めて解説します。
ウォーターフォールモデルではクライアント側は自らの思い、希望をRFP「Request for Proposal」（提案要請書）として表現し、システム側はその思いや希望を要件定義書に記述し、クライアント側の確認を取っていました。
一方、アジャイルモデルでは、都度「要求仕様書」の形でクライアント側の要求を記述します。つまりは、「要求仕様書」はアジャイルモデルにてよく利用される仕様書とも言えます。
ウォーターフォールモデル
「ウォーターフォール」（Water Fall）は「滝」のことです。滝のように上から下に向かって流れるイメージの通り、「ウォーターフォール」は工程を細かく分けて、上流工程から下流工程へと順番に進めていく開発手法です。
ウォーターフォールモデルのメリットは、1つの工程が完了した後に次の工程に進むため、状況の把握や進捗管理が比較的行いやすい点です。そのため、品質をある程度担保できるのもメリットの1つです。
一方でデメリットは、システムに不具合が発見されると、そのリカバリーに時間やコストを要する点です。さらに要件定義や基本設計まで遡って修正する必要が生じると、大幅な納期遅延が発生し、多大なコスト増となります。
ウォーターフォールモデルにおいては、途中で不具合が発生すると、以降の工程に進めないことから、スピードが求められるシステム開発には不向きと言われます。
アジャイルモデル
「アジャイル」（agile）は「俊敏」を意味する英語で、スピードを優先するプロジェクトに適した開発工程モデルです。「アジャイルモデル」では、作るシステムの概要が決まったらすぐに開発工程に入り、機能ごとに「計画→設計→実装→テスト」のサイクルを繰り返しながら開発を進めます。
ウォーターフォールモデルでは後戻りがないという前提で工程が進められますが、アジャイルでは後戻りを前提として工程が進められるため、設計工程では詳細は決めず、全体を作る中で必要に応じて修正が行われます。
アジャイルモデルのメリットは開発スピードの速さですが、工程の進捗、状況の把握が難しく、管理しにくいのがデメリットです。
近年はアジャイルモデルが増えていますが、ウォーターフォールの案件もまだ多くあります。エンジニアによって両者の得意不得意もあるかもしれません。転職する際は、企業がどちらの開発モデルを採用しているのかもチェックしておきましょう。
ぜひ『マイナビIT エージェント』をご活用ください！
要件定義書についてより詳しく
要件定義書の作成には、開発プロジェクトのリーダーやディレクター、エンジニアなどのプロジェクトを指揮する人が中心となり、開発プロジェクトを進める上で必要な項目を列挙していきます。
それらの内容を「要件定義書」に落とし込んで、関係者に周知徹底を図ります。では、この要件定義書について、より詳しく見ていきましょう。
要件定義と基本設計の違い
要件定義と基本設計は混同されがちですが、工程は異なります。基本設計は要件定義をより明確化するフェーズに当たります。具体的にはアウトプットとして、業務フロー図・機能一覧・画面遷移・画面レイアウト・インタフェース一覧などの実際のシステムの根幹部分の仕様を決定するのが基本設計フェーズです。
要件定義書に盛り込むべき内容
要件定義書はシステム開発において要となる重要なドキュメントですが、その内容についてはシステムの特性や規模、企業などによってまちまちです。ここでは必要最低限の内容について記載していきますので、テンプレート的なものやサンプルが必要な方は以下のサイトを参照してください。
【参考】： IPA公式サイト_超上流から攻めるIT化の事例集：要件定義
1.システムに関する記載
要件定義書にはまず、どんなシステムを作るのかが分かるように、システム概要・システムの導入目的・業務フロー図などのシステムに関する記載を行います。システム概要では、業務要件は顧客視点で、システム要件は開発視点で記述します。
導入目的は、顧客目線で記述することにより、顧客要望が浮き出されます。このシステムによってどのような顧客要望が実現できるのかを説明します。
業務フロー図はシステム導入前と後の変化を分かるように意識します。このことで、システムの必要性がより客観的に理解しやすくなります。
2.機能要件に関する記載
機能要件はすなわちクライアントの要求内容そのもので、これがプロジェクトのゴールとなります。開発プロジェクトの初期段階で共有される機能要件は、システムのゴールについてクライアントと合意形成を行い、開発プロジェクト計画を承認してもらう上で重要なものとなります。
あいまいさを払拭し、より鮮明で具体的であることが求められます。
3.非機能要件に関する記載
機能面以外の要件を非機能要件と言います。ここは、RFPに明記されていなければクライアントから具体的に示されることは少なく、最初は漠然としています。とは言えシステムの出来栄えに関わる重要な要件であり、クライアントの合意が必要です。
たとえば、システム稼働後に「レスポンスが遅い」「セキュリティに脆弱性が見つかった」などとして、時には損害賠償請求を受けることがあり得ます。
非機能要件は、機能要件と同様に重要で、機能要件が固まり次第非機能要件を決定します。非機能要件では、システムの性能、セキュリティや保守・運用サービスなどについて記載し、プロジェクトのゴールをより明確にしていきます。
エンジニア転職のご相談はぜひ
『マイナビIT エージェント』へ！
要求仕様書についてより詳しく
システム開発では大きな役割分担としてSE（システムエンジニア）が設計を行い、その設計書に基づいてプログラマーがプログラムを作成する形でシステム開発が進められます。要求仕様書にはシステム開発の全体の指示書的としての役割があります。
要求仕様書は特に定型フォーマットが決まっていませんが、システム設計書や仕様書が作成されることを踏まえて、システム設計に必要なことが細部まで記述されている必要があります。
【参考】：厳密な仕様記述入門（IPA）
要求仕様書に書く項目
要求仕様書とは、クライアントがシステム開発側に対して開発を依頼する際のシステム要件を文章化したもので、要望や要求事項・予算・リリース目標などが主で、具体的な実現方法は書かれていません。
クライアント側にシステム開発に強い担当者がいれば、要求仕様書はクライアント側で作成すべきですが、そうでない場合は、開発担当側の関与が必要になる場合があります。要求仕様書に記述が必要な項目は、概ね以下の通りです。
1.システム化の目的 何のためにシステムを開発するのか、その効果はどの程度なのかを具体的に記載します。
2.基本方針 システム開発に関する基本方針を記載します。 設計方針やテスト方針などを記載します、
3.機能一覧 おおまかな機能について記載をします。詳細機能は詳細設計書などの仕様書に記載されるため、要求仕様書では機能のアウトラインを記載します。
▪システムの用途：システムの利用シーンを想定して用途を記載 ▪対象のユーザー：対象となるユーザーと利用環境などを想定して記載 ▪ハードウェア構成：サーバ・ネットワーク・周辺機器などの実装仕様を記載 ▪ソフトウェア構成：必要なソフトウェア・OS・ミドルウェアなどの実装仕様を記載 ※実装仕様とはコンピュータ、ストレージデバイスなどの実際のハードウェアやオペレーティングシステムなどのこと ▪目標性能：達成すべきシステム性能を挙げる
要求仕様書に記載する機能一覧は、開発側及びクライアント側の両者に分かりやすく、図表などで示すなどの工夫をします。用語などにも注意し、クライアント側の担当者に理解しやすいレベルを意識しましょう。
4.その他
要件定義書に代わるものとして要求定義書を用いる場合には、開発体制・開発スケジュール・開発環境・開発予算などの項目も網羅します。
システムエンジニアの役割を理解して開発を進めよう
ここまで、要件定義書と要求定義書、要求仕様書について解説してきました。システムの開発における要件定義とは、エンジニアがシステム構築のために定義する仕様のことであり、要求定義とはクライアントがシステム（エンジニア）に対して求める仕様の定義のことです。
要件定義はシステムの基本設計者や詳細設計書の元となり、要求定義はビジネスに関する基本設計や詳細設計、オペレーションなどが主となります。
言葉が似ており、混同しやすいところですが、システムエンジニアはクライアントと開発側の橋渡し役でもありますので、その自覚を持ち、正しい知識を得た上でシステム開発を進めましょう。
システムエンジニアとしてキャリアアップを図るなら、要件定義書の書き方やエンジニアとしてのスキルはもちろん、実績を正しく評価してくれる企業選びも重要です。転職を検討する際は1人で求人を探すよりも、転職エージェントのサポートを受けることで転職活動がスムーズになるでしょう。
そこでぜひご活用いただきたいのがマイナビIT エージェントです。
マイナビIT エージェントは、IT・Webエンジニア向けの無料の転職⽀援サービスです。
IT・Webエンジニアの転職事情に詳しいキャリアアドバイザーが、あなたのご経験やスキルをお伺いし、転職活動のプランをご提案致します。
アドバイザーは企業側の人事担当者と直接連携を取れますので、求人票に載っていない企業情報も確認することができます。残業時間や給与面など、働き方などをしっかり確認の上で応募企業を選んでいくのが良いでしょう。
・資格やプログラミングの勉強をしているけれど、企業が求めるレベルに達しているのかわからない ・スキルアップをして市場価値を上げていける企業の選び方を知りたい ・数多くあるITエンジニアの職種の中で、自分に向いている仕事は何か知りたい
こうした悩みを抱えていらっしゃる方は、まずは無料登録でキャリアカウンセリングをおすすめ致します。
エンジニア転職のご相談はぜひ
『マイナビIT エージェント』へ！
新着記事やエンジニアに役立つ情報をお届け！
日々のキャッチアップをお手伝いします！
編集部オススメコンテンツ
アンドエンジニアへの取材依頼、情報提供などはこちらから
