要件定義の成果物とは？必要な項目と作成手順のステップを解説

要件定義の最終的な成果物は「要件定義書」

要件定義の最終的な成果物は「要件定義書」と呼ばれる書類です。要件定義書とは、システム開発において開発側が作成する、発注側の要件や要望をまとめた文書のこと。発注側にヒアリングした内容や、発注側から提出された提案依頼書（RFP：Request for Proposal）をもとに作成します。

要件定義書を作成する目的は、発注側と開発側の認識を合わせ、目的を確実に達成できるシステムを開発することです。要件定義の成果物として要件定義書を作成することで、システム開発における認識のずれを防ぐことができます。

要件定義書のサンプル一覧

要件定義書には代表的なサンプルがあります。一覧にまとめましたので、要件定義書を作成する際には参考にしてみましょう。

参照元：厚生労働省『毎月勤労統計調査オンラインシステムの更改及び運用・保守に係る業務一式 要件定義書』

参照元：厚生労働省『厚生労働省情報提供システムの更改整備及び運用・保守業務一式 要件定義書』

参照元：国土交通省『建設キャリアアップシステム 要件定義書』

参照元：IPA『システム開発調達仕様書（ひな形）』

要件定義書と提案依頼書・要求仕様書の違い

要件定義書と似ている書類に「提案依頼書（RFP）」「要求仕様書」があります。要件定義書と両者の違いは以下のとおりです。

両者とも、発注側が開発側に希望を伝えるための書類です。現状の課題や求める仕様を記載し、技術的な解決法を開発側に求めるために提出されます。

要件定義の成果物に必要な5つの項目

要件定義の成果物である「要件定義書」には決まったフォーマットがありませんが、一般的に必要な項目として以下の5つがあります。

詳しく見ていきましょう。

システムの概要（目的・背景・課題・解決策）

まず必要な項目がシステムの概要です。主に以下の内容を記載します。

システムの概要を明確にすることで、開発の方向性が定まります。方向性を共有できていれば、もし開発途中で開発内容を変更・調整する場合にも、ずれが生じることなく円滑に合意形成が可能です。

業務要件（業務フロー）

業務要件とは、システム化の対象となる業務の定義です。以下2つの業務フローを記述し、どの業務をシステム化するのかがわかるようにします。

フローチャートを活用して視覚的に記載すると、テキストよりもわかりやすいです。

機能要件（必要な機能）

機能要件とは、システムに備える必要な機能です。以下のような内容を記載します。

記載するときには開発用語ではなく、ユーザーが使用するときの機能名で説明します。

非機能要件（セキュリティ・性能・運用）

非機能要求とは、機能以外の要件です。以下の内容について記載します。

非機能要件は、システムを安全かつ快適に利用していくために必要な要素です。どの程度の非機能要件が求められているかを明確にしておきましょう。

実行計画（開発の計画）

実行計画は、要件定義以降の開発を進める計画です。以下の内容を定義します。

具体的に計画を立てることで、開発の実行がスムーズになります。

要件定義の成果物を作成する5ステップ

要件定義の成果物を作成する5ステップを紹介します。それぞれみていきましょう。

1. 現状を把握・分析する

まずは発注側と入念に情報共有を行い、現状を把握・分析します。基本的な方法は以下の2つです。

発注側がどのような課題を抱えているのかを明確にします。ここでわかる課題に対してアプローチするため、重要な工程です。

2. 課題の解決策を検討する

現状や課題が把握できたら、課題に対する解決策を検討します。考えられた方法で本当に課題を解決できるのかをよく確認しながら進めましょう。課題に対して適切な解決策を提示することが重要です。

3. システム化対象のものを要件化する

解決策のうち、システム化対象のものを要件化します。重要な文章どのような業務をシステム化するのか、どんな条件のシステムが必要なのかを定義していきましょう。

4. 要件定義書の構成を決める

要件をわかりやすく伝えられるよう、要件定義書の構成を決めます。大項目・小項目など階層立てることで、わかりやすい構成が作成可能です。構成では前述した必須の項目を入れ込むようにしましょう。

5. 項目ごとにわかりやすくまとめる

項目ごとにわかりやすい言葉でまとめましょう。要件定義書は開発側だけでなく、発注側にも共有する資料のため、誰にでも理解しやすい内容が求められます。知識がない人が読んでもわかるよう、専門用語を使わずに平易な言葉で記述することが大切です。

要件定義書をより良い成果物に仕上げるポイント3つ

要件定義書をより良い成果物に仕上げるポイントを3つ紹介します。それぞれみていきましょう。

構成がまとまっている

要件定義書は、わかりやすい構成にまとめましょう。以下のような工夫を取り入れると、見通しを持って読みやすい構成になります。

構成は発注側の要求について漏れがなく、同意を得られた情報を網羅していることが重要です。構成がまとまっていると、発注側と開発側の両方にとって理解しやすく、円滑に開発を進められます。

専門知識がなくても理解できる

専門知識がなくても理解できるよう、やさしい言葉でわかりやすく記載することが大切です。要件定義書は開発側が作成し、発注側と共有する資料です。認識をすり合わせることが目的なので、両者にとって理解しやすい資料でなければなりません。

書き方や表現方法について悩む場合は、公開されている要件定義書のサンプルを参考にすることをおすすめします。

図解を活用している

要件議定書の作成では図解を豊富に活用しましょう。業務フローや技術的な内容など、テキストだけではイメージしにくい部分が多いためです。検索すると、無料で図解を作成できるソフトやアプリもあります。視覚的要素の有無で、わかりやすさが大きく変わるので、ぜひ取り入れてみてください。

まとめ

今回は、要件定義の成果物についてお伝えしました。

要件定義の成果物は「要件定義書」があり、システム開発における重要な資料となっています。要件定義の成果物について開発者や開発会社、コンサルティング会社に相談したい場合は、「比較ビズ」がおすすめです。一括で無料見積もりができるので、利用してみてはいかがでしょうか。

監修者のコメント

株式会社GeNEE

代表取締役 日向野卓也

東京工業大学環境・社会理工学院卒業。慶應義塾大学大学院経営管理研究科修了。MBA（経営学修士）取得。国内最大手SIerの株式会社NTTデータで大手法人領域（大手流通企業、大手小売企業）の事業開発、事業企画等の業務に従事。米国スタンフォード大学への研修留学を経て、システム/モバイルアプリ開発会社の株式会社GeNEEを創業。

詳しく見る

システム開発における「成果物」はなかなかイメージがしにくいものかもしれませんが、大きくは要件定義書・設計書・仕様書と呼ばれるドキュメント類とシステムを動かすソースコードプログラムの２つに大別されます。

お金を扱う大手金融機関（メガバンク）様や国民の個人情報を扱う官公庁様の場合、一つの設計誤りが致命傷になりかねませんので、外部システムとの連携部分を表すインターフェースや各帳票、各画面等を可能な限り言語化し、ドキュメント類に落とし込んでいきますので、必然とその量は膨大になります。

ドキュメント類の記述量に比例してシステムの規模感、複雑性も増しますので、プロジェクト期間が長くなります。そのため、お客様によっては、設計書や仕様書等を一つの成果物としてフェーズを区切ることもあります。

1年未満で完結するような短期的なプロジェクトでは、要件定義工程〜開発・試験工程を終えた後に出来上がるソースコードプログラムを最終的な成果物として取り扱う場合が多いです。このあたりはお客様との調整、契約の仕方によって成果物の捉え方が変わってきます。

執筆者

比較ビズ編集部では、BtoB向けに様々な業種の発注に役立つ情報を発信。「発注先の選び方を知りたい」「外注する際の費用相場を知りたい」といった疑問を編集部のメンバーが分かりやすく解説しています。