要件定義書とは？要求仕様書・RFPとの違いも紹介【2024年最新版】

システム開発の現場で必ず必要になるのが、要件定義書です。要件定義書がなければ課題解決につながるシステムを組み上げることができなかったり、何度も修正や手戻りが発生し、システム開発のコストや時間が大幅にかさんでしまったりする可能性もあります。
この記事では、そんな要件定義書の作成を上手に成功させるためのポイントや、似たような仕様書との役割の違いについて、解説します。自社で初めてシステムの開発や改修を考えているが、何から始めて良いのかわからない、要件定義書の必要性がわからないという方は、参考にしてください。

【関連ページ】
システム開発にかかる費用・相場感や、あなたの目的別にシステム開発会社をお探しいただけます。 
システム開発の費用・相場
システム開発会社一覧

要件定義書は、開発会社がシステムを開発する際にあらかじめクライアントに共有する、具体的なシステムの機能要件をまとめたものです。要件定義書を作らずにシステムを開発してしまうと、クライアントの意図しない機能がシステムに盛り込まれていたり、必要だった機能が実装されていなかったりといった問題が起こり得ます。

こういったトラブルを回避し、事前の情報共有を丁寧に行うために作成するのが要件定義書の役割で、技術的な知識がない人にも情報を共有できるよう、比較的わかりやすい表現を用いて情報を記述します。どんな機能がシステムに盛り込まれるのか、どれくらいの予算やスケジュールになるのかを明らかにします。

要件定義書は自動で生成されるものではなく、担当者が責任を持って書き上げるものです。基本的にはシステムの開発を担当する会社やチームが開発前に作成し、クライアントとの意思疎通を図ります。上でも触れていますが、要件定義書の目的は開発者がこれから作ろうとしているものの仕様や情報をまとめたものなので、開発者が何をしようとしているのかをクライアントが完結に把握する上で必要です。

要件定義書の丁寧な作成は、システム開発を成功に導く上でも非常に重要です。独立行政法人情報処理推進機構（IPA）の調査によると、システム開発の失敗や遅延の要因の5割は、要件定義の不備にあることがわかっています。要件が曖昧なまま開発を進めてしまうと、手戻りや仕様変更が多発し、多くのコストがかかってしまうためです。正確な要件定義書を作成、およびクライアントの理解があることで、開発を成功に導けます。

※出典：独立行政法人情報処理推進機構（IPA）「「ユーザのための要件定義ガイド　～要求を明確にするための勘どころ～」のご紹介　https://www.ipa.go.jp/sec/old/users/events/events_tokyo_20170310-2.pdf

要件定義書と似たような書類として、提案依頼書（RFP）や要求仕様書といったものが挙げられます。これらは似たような情報を含む書類であり、作成時期もほぼ同一ですが、具体的には微妙な違いがあります。ここでは、RFPや要求仕様書が要件定義書とどのように異なるのか、その役割や作成時期、項目の違いをもとに解説します。それぞれを比較した表も作成しているので、合わせて確認してください。

提案依頼書は通称RFPと呼ばれ、要件定義書とは異なり発注者が作成する文書です。主にシステム開発の外注先を決定する前に作成する文書で、具体的な機能予見などをまとめ、複数のシステム開発会社に共有します。要求定義書に基づいて開発会社は要件定義書を作成し、発注者はそれをコンペにかけた上で、最終的な依頼先を決定します。主な項目としては、

・どんなシステムを作りたいのか
・どんな課題を解決したいのか
・実装したい機能は何か

といったものが挙げられ、アバウトながらも基本的な項目は要件定義書と共通するものがあります。

要求仕様書は、発注者が開発会社に向けて作成する、どんなシステムを開発したいか、どんな課題を解決したいかをまとめた文書です。具体的なシステムの機能などの情報はそこそこに、なぜシステム開発を依頼するに至ったのか、という「Why」の部分にフォーカスを置いています。要件定義を行う前に作成し、開発会社に共有することで、システム開発がニーズに則ったものとなるよう目的を共有し、スムーズな要件定義やシステム開発を行えるよう促します。具体的な記載項目としては、

・システム開発の背景、現状
・理想のゴール
・ゴール達成に必要な要素・機能

などが挙げられ、要件定義書と比べると抽象的です。

「自社にあった会社が見つからない」「会社選びに時間が割けない」とお悩みの方は、お気軽に「アイミツ」にお問い合わせください。数あるシステム開発会社からあなたの要望にあった会社をピックアップして無料でご紹介いたします。

要件定義書の内容についてはプロジェクトごとにさまざまですが、その大まかなフレームワークについてはある程度定まっています。要件定義書は大きく分けて、

・依頼概要
・業務要件
・機能要件
・非機能要件
・コミュニケーション方法

という5つのグループに分類の上内容を固めていくこととなります。中でも特に重要なのが

・機能要件
・非機能要件

の2つで、開発会社とクライアントで齟齬がないよう丁寧に擦り合わせる必要があります。

依頼概要は、文字通りシステム開発依頼の概要をまとめる項目です。そもそもなぜシステムの開発を依頼するに至ったのか、開発の背景に触れた上で、これからどのような課題を解決しようとしているのか、その目的地についてもここで明らかにしておきます。また、要件定義書の中で頻出する専門用語や単語などはここで定義づけや解説を行なっておき、情報共有にブレやミスがないよう備えておきます。具体的な項目としては、

・導入先の環境
・導入時の制約
・システム構成図

なども背景などと合わせて紹介します。システムをどんな環境で運用する予定なのか、運用に当たって、注意すべき制約はあるのかを明文化し、システム構成図と合わせてわかりやすく記述することで導入後のトラブルを回避します。

業務要件の項目では、システムを導入する先の業務フローや要件についてまとめておきます。現在どのような業務フローを備えていて、システムはそのフローのどこに導入する予定なのか、業務のスケールはどれくらいで、どんな場所で使用しどれほどの時間をかけて取り組むものであるのかなどを明文化します。これを明らかにしておくことで、開発者とクライアントがシステム開発にあたってのバックグラウンドを共有できるので、ニーズに適したシステムの開発を促せます。ほかにも具体的な項目としては、

・作業を管理する上での目安
・システム化の範囲

などを明文化しておくことが大切です。どんな指標に基づいて業務を遂行するのかが分かれば、それに基づくシステム開発が行えます。また業務のどれくらいの範囲にシステムを導入するかを定義しておくことで、システムの規模感を掴みやすくなります。

機能要件は、システムがクライアントの課題を解決するために実装し、直接的に問題解決に役立つ機能群を指すものです。ユーザーが直接触れることになる機能なので、開発会社はユーザーにとってわかりやすい名称で機能を整理し、明文化する必要があります。主な記載事項としては、

・システムの機能
・表示画面
・情報項目

などが挙げられます。システムの機能は、機能要件項目の中で最も多くの尺を必要とする項目です。どんな機能をそのシステムに実装するのか、ということをここで紹介するので、クライアントが必要としている機能が盛り込まれているかを、過不足なく確認しなければなりません。

表示画面は、ユーザーがシステムを利用するにあたってどんな画面を見ながら使うことになるか、ということを定義するものです。最終決定案がここで決まるとは限りませんが、おおむねこのような使い勝手である、ということはこの時点で決まるので、実際の使用シーンに耐えうるものかどうかを確認しましょう。情報項目では、システム内でデータがどう処理され、ログに残るかを記述します。

非機能要件は、直接ユーザーがシステムを利用する上で触れるケースは少ないものの、システムが役割を果たすためには不可欠な機能群をまとめたものです。例えばマシンのセキュリティ対策や、パフォーマンスの安定性、拡張性などをどのように担保するかをここで定義します。

非機能要件が不十分な場合、システムを構築しても、中長期的にその使い勝手に問題が出てくる場合があります。突然サーバーがクラッシュしたり、初歩的なサイバー攻撃でシステムがダウンしてしまったりと、多くの不安要素を抱えながら利用しなければなりません。ほかにも非機能要件として、

・上位互換性
・テスト
・引き継ぎ

といった項目が設けられます。システムの老朽化に伴うアップデートのしやすさや、テストをどのように実行するのか、引き継ぎ業務をどう行うかなどを定義し、末長く利用できるシステムとしての信頼性を高めます。

コミュニケーション方法は、クライアントと開発会社、あるいは社内でどのようにコミュニケーションをとるかの方法を定義づけるものです。コミュニケーションの方法は多様化しており、電話やメールに加え、社内SNSやメッセンジャーを使った方法など、組織によってその方法は多様です。

ただ、コミュニケーションが多様化すると、連絡事項の確認もれや情報共有の不備が発生してしまいやすくなるため、ある程度プロジェクトや連絡相手に合わせてその方法を限定した方が業務効率の観点からは有効です。具体的な項目としては、

・コミュニケーションツール
・コミュニケーション担当者
・相談窓口

などの事項を決めておくのが有効です。どのツールを使ってお互いに連絡を取り合うのか、誰がどんな連絡を伝達するのか、困ったときには誰に相談するのかなどを決めます。

ここで、実際の要件定義書のサンプルについて紹介します。どのような規模で、どんな決め事があるのかを確認しておきましょう。

●札幌市
開発内容：文書管理システム再構築に係る設計・開発業務
開発規模：
・文書管理システム
・ 電子決裁システム
・公文書館システム
・文書保存センターシステム
・目録公開システム
・電子掲示板システム
開発期間：11ヵ月
文書のライフサイクルを改善し、保存期間の延長や廃棄・移管の手続きを効率化する。

参考URL：https://www.city.sapporo.jp/kikaku/it-keiyaku/documents/r1_bunsyo_kaihatu_youkenteigisyo.pdf

●電力広域的運営推進機関
開発内容：容量市場システム(一次開発)の設計開発及び運用保守業務委託
開発規模：電力広域的運営推進機関の事務所およびバックアップ拠点を対象としたシステム
開発期間：4年
データの入力や出力、審査機能を実装した業務フローを提供。

参考URL：https://www.occto.or.jp/choutatsu/2018/files/181219_youryousystem_youkenteigi.pdf
https://www.occto.or.jp/choutatsu/2018/files/181219_youryousystem_youkenteigi_besshi1.pdf

●環境省
開発内容：指定登録機関が構築、運用する指定登録機関 Web システム
開発規模：Webシステムの設計から開発、運用保守
開発期間：3年
動物愛護管理法に基づき、マイクロチップ 装着・情報登録の義務対象となる事業者や所有者が利用するWebシステムや、ワンストップサービスの提供

参考URL：https://www.env.go.jp/content/900517405.pdf

要件定義に失敗しないためには、あらかじめポイントを押さえた業務の遂行が必要です。主なポイントは

・要件定義の作成サンプルを事前に確認する
・不明瞭な点の確認は怠らない

の2つで、初めてシステム開発を依頼するときほど、注意すべきポイントと言えます。要件定義書に慣れていな場合、その読み方にも苦労することとなるため、事前に正しい文書の読み方や、どんなところに気をつけるべきかを把握しておきましょう。

要件定義の作成サンプルは、あらかじめ社内で共有しておきましょう。要件定義書の完成形に対する認識が共有できていないと、何をゴールや基準と考えれば良いかがわからず、話が平行線で進まなくなるためです。

要件定義書には絶対的なフォーマットがないため、プロジェクトの内容や規模に合わせ、最適なゴール地点をあらかじめ定めておくことが重要です。開発会社とクライアントの意思疎通を図る上でも、最初に話し合っておきましょう。

要件定義書を作成する段階で承認が得られれば、開発会社はその要件からブレないようシステムの開発に着手します。逆に言えば、要件に当てはまらない仕様や機能は実装されないため、事前に不明点を指摘できることが大切です。

不明瞭な点を明らかにする上では、5W2Hなどの手法が挙げられます。5W1Hという基本の問いに合わせ、「how much」という予算面の疑問も解消できる問いをぶつけることで、予算の問題が発生することを回避できます。

つづいては、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

この記事では、要件定義書の役割や具体的な書き方について紹介しました。要件定義書は多くの項目が設けられているため、一つひとつを確認するのは非常に面倒な作業でもあります。ただ、要件定義が正しく行われていないと、ニーズに則ったシステムを開発してもらえないため、過不足なく確実な要件が設けられていなければなりません。開発会社との意思疎通においても大きな役割を果たすため、その読み方を訓練しておきましょう。

アイミツでは、そんなシステム開発をあなたのニーズに合わせて確実に遂行できる会社を、厳選して紹介しています。システム開発を検討の際には、お気軽にご相談ください。

【相談前にまずは会社一覧を見たいという方はこちら】
システム開発会社一覧

【費用感を知りたいという方はこちら】
システム開発の費用・相場