「要件定義書」とは?サンプルやテンプレートで書き方を徹底解説!

システム開発をする上で必要になってくる文書が「要件定義書」です。顧客の要望をヒアリングして進め方をまとめるものですが、どういった書き方をするべきなのかサンプルが欲しくなることもあるでしょう。今回はサンプルやテンプレートを交え「要件定義書」の書き方を解説します。

「要件定義書」とは?サンプルやテンプレートで書き方を徹底解説!のイメージ

目次

  1. 1「要件定義書」とは
  2. 2「要件定義書」を書く目的
  3. 3要件定義すべき項目の内容
  4. 4要件定義の進め方
  5. 5「要件定義書」のサンプル・テンプレート
  6. 6「要件定義書」と「要求仕様書」の違い・使い分け
  7. 7「要件定義書」がシステム開発の成功のカギ

「要件定義書」とは

「要件定義書」とは、「開発するスケジュールを開発側と顧客側で合意したこと」をまとめたものです。少しわかりにくいですが、単なる設計図やスケジュール表ではありません。

まず、顧客(お客様)が「こういった目的があるから、こんなシステムを開発して欲しい」という要望が届きます。勿論、機能だけでなくセキュリティ等についての要望もあるでしょう。開発側は顧客からヒアリングしたこれらの要望から、どういった手法で、いつくらいの期間をかけてそのシステム(成果物)を開発するのかを考えなければなりません。

方法やスケジュールといった内容を開発側が提案し、顧客がそのことに合意します。何度も打ち合わせを重ね、その合意内容をまとめた成果物が「要件定義書」なのです。

「要件定義書」は開発するエンジニアが書くことが多い

結局「要件定義書」は誰が書くのかというと、それは開発する側のシステムエンジニアです。以前は顧客側が作るものでしたが、最近はエンジニア側が作るように状況が変わってきています。この記事でも、エンジニアが「要件定義書」を書く前提で解説します。

逆に、「要件定義書」を読むのはITに詳しい人であるとは限りません。あまりに難しいIT用語を使っていたり、開発側にしか分からない書き方をしたりすると、読む方は混乱して思わぬトラブルに繋がりかねません。「要件定義書」は必要なものですが、書き方には工夫が必要です。

開発側と顧客側の同意がないと「要件定義書」にはならない

意外と見落としがちなのが、「要件定義書」は「合意内容」をまとめたものであるという点です。単純に相手からの要望をヒアリングしたものをまとめるだけでも、スケジュールや開発の進め方をまとめるだけでも、その文書は「要件定義書」とは言えないのです。

進め方や開発の目的・具体的な開発の方法等、すべての内容において開発する側と顧客側が合意していることが前提となります。書き方やヒアリングも大切ですが、「要件定義書」には「合意した内容」を書きましょう。

「要件定義書」を書く目的

「要件定義書」については分かりましたが、どうしてわざわざ合意したことを書くのでしょうか。顧客にも色々な要望があり、開発する側は当然それにこたえなければなりません。その要望をどう叶えるのか、仮に無理だという場合はどこまで妥協しすり合わせるのかをまとめていく必要があります。

何をどういう形で合意したことになっているのかはお互い分かっていなければなりません。上記でも説明したように、「要件定義書」はこうした要望をまとめた「成果物」なのです。

「要件定義」の内容をまとめたのが「要件定義書」

システムを開発するのに絶対必要なのは「要件定義」または「システム要件定義」です。「要件定義」は「最終目的」「ヒアリングを含めた調査」「内容の検討」「スケジュール」のことを指し、これらの結果や決定をまとめたものが「要件定義書」という形になります。

これらはすべて開発する側がやることですが、実際にシステムを使うのは顧客です。つまり、顧客ともこの要件定義の内容を共有しなければやり取りも上手くいきません。お互いの情報を共有する上でも、「要件定義書」は絶対に必要なものなのです。

「要件定義書」がシステム開発のスタートライン

「要件定義書」の完成でようやくシステム開発のスタートとも言えます。「要件定義書」の出来によってそのプロジェクトの成功か失敗かが決まってくるといっても過言ではありません。開発側と顧客、お互いがどんな形で開発を進めていくのかという認識を共有するのが「要件定義書」の役割なのです。

要件定義すべき項目の内容

【要件定義すべき項目】

最終目的 最終的に何を目指すのか・どんなものを作るのか
事前調査 その目的は達成可能か否かをヒアリングや統計で調査
内容の検討 調査結果をもとに、デザインや細かい内容を考える
スケジュール 最終目的を達成するための運用を含めた日程

要件定義で必要な項目と内容はこのようになっています。IT系のシステムに限らず、一般的な開発の工程は大きく分けて「要件定義」「設計」「製造」「検査」の4項目です。「要件定義書」の書き方がどのようなものであっても、必ず内容はこれに沿ったものである必要があります。

詳しい「要件定義書」の目次サンプルやテンプレートについては後述しますが、良い「要件定義書」はこれらの基本事項をきちんと分かりやすくまとめているものを言います。誰が見ても分かりやすいものを作成できれば、必ずプロジェクトを成功に導けるはずです。

要件定義の中身はとても基本的なこと

上記の項目を見ても分かるように、要件定義の内容はかなり基本的なことばかりです。たとえば、Webサイトを作るとして「3億人の人にアクセスしてもらう」ことが「最終目的」になりますし、「3億人は日本の人口を超えているから不可能では」と判明するのが「事前調査」です。

これは単純な例ですが、どんなシステムでも必ずこのような目的や内容の検討というのが背景にあります。勿論要望をヒアリングすることも大切ですが、それが現実に通るかどうかは別です。基本的であっても、とても大切な「基礎の基礎」を決めるのが「要件定義」なのです。

要件定義の進め方

「要件定義」をするべき内容は分かりましたが、では実際どのように進めていけばよいのでしょうか。実際の企業でも要件定義の進め方が上手な人はいます。誰でも初めての要件定義が上手くいくわけではないでしょうが、基本の進め方さえ押さえれば話をスムーズに進めることが出来ます。

実際、要件定義の進め方については特に決まった手法は存在しません。会社によって「大体こんな感じの進め方で」と決まっていることもあれば、案件によっても進め方が変わっていく可能性もあります。その人のやりやすい進め方のスタイルもあるので、柔軟な対応が求められます。

「要件定義」が済めば「要件定義書」にそのことをまとめます。書く人のスタイルやその案件について書き方は様々ありますが、最初は基本に則った書き方をするべきでしょう。目次も含め、この後紹介する具体的なサンプルを参考にしたり、テンプレートを使ったりするのも手です。

要件定義の進め方はまずゴール(目的)を決めることから

要件定義の進め方は様々あると説明しましたが、基本的な進め方というのは存在します。一番良いのは「ゴールを決めること」です。つまり「最終目的」を何より最初に明確にするのが一番分かりやすい進め方なのです。

先に「いつまでに何を達成させる」という目的や目標を設定すれば、「いつまでに何を作ればいいのか」ということを逆算することが出来ます。これは要件定義の進め方に限らず、様々なプロジェクトの進め方にも当てはまります。

要件定義書の書き方は階層構造が基本

【階層構造の例】

大見出し
 中見出し
  小見出し
大見出し2
 中見出し2
  小見出し2

要件定義で決め、お互いの合意を得たことを「要件定義書」をまとめることになります。その際書き方は階層構造が分かりやすいとされています。この記事もそうなっていますが、一つの項目で「大見出し」「中見出し」「小見出し」の順に分かれていっていることを「階層構造」と言います。目次のように見出しだけを並べてみると階層になっているのが一目瞭然です。

いずれの見出しも、数が多すぎると読んでいる方は内容の全体を掴めなくなってしまいます。見出しの数は大体5つ前後、どんなに多くても10項目以下に抑えておきましょう。もっと具体的なサンプルとテンプレートはこの後の「『要件定義書』のサンプル・テンプレート」の項で紹介します。

「要件定義書」のサンプル・テンプレート

「要件定義書」の具体的なサンプルと、そのまま使えるテンプレートを取り上げます。項目が多い分、書くべき内容も自然と多くなるので「要件定義書」には目次をつけましょう。目次のサンプルもありますので参考にしてみて下さい。

要件定義の進め方が色々とあるように、要件定義書の書き方も様々です。書き方が分からない最初の内はここにあるようなサンプルやテンプレートを見ながら作成するのも良いでしょう。

「要件定義書」のサンプル

こちらは「要件定義書」のサンプルです。本文だけでなく目次のサンプルもここで一緒に紹介しています。ここでは簡単なサンプルを載せているので、大まかなイメージを捉えるくらいで活用してみて下さい。

「要件定義書」の目次サンプル

【要件定義書の基本的な目次サンプル】

目次に記す項目 その項目の内容
システムの概要 どんなシステムなのかについての説明
機能要求 そのシステムは何が出来るのかの説明
入力要求とシステム要求 どんな形で入力・出力できるのかについての説明
システム導入後の業務フロー 導入した後はどのように業務を進めるのかについて
品質・性能要求 求める品質と性能の明確化
セキュリティ要求 求めるセキュリティの明確化
システム導入の目的と目標 導入後何をするのか・何をどこまで到達させるのかについての明確化

プロジェクトによって若干違いますが、基本的な要件定義書の目次サンプルはこのようになります。目次サンプルだけでもかなりのボリュームですが、どれも開発においてかなり重要な項目です。プロジェクトによって必要な項目があれば付け足ししていきましょう。

かなりのページ数になることから、要件定義書には目次をつけなければなりません。本文を作成した後でも良いので、必ず目次も作成するようにします。また、これらの項目の前に「はじめに」として要件定義書の位置付けを説明するのも良いでしょう。

「要件定義書」本文のサンプル

【本文サンプル】

2. システムの概要
2.1 システムの開発範囲
 今回のシステムは、主に基幹系業務(販売、生産、購買)を中心とした情報との共有に関わるものを対象とする。尚、売上推移も範囲に含む(当該においては別紙のフローを参照)。

2.2 業務要件
 今回のシステム化において重要な項目は以下の4点である。
 (1)各店舗の営業情報の管理及び共有
   進捗を各店舗の店長と本社の営業担当者が綿密に管理・共有することで、市場の推移を正しく反映し、今後生産計画を正確に作成できるよう支援をする。

 (2)…

要件定義書の本文の簡単なサンプルです。「2」という大見出しから「2.1」「2.2」…とさらに細かく分かれていっているのが分かるでしょう。経営理念等本文の内容によっては、他の部署や相手側のヒアリングを実施してから書く必要もあります。

ビジネスにおいて実態を掴むために、ヒアリングというのはとても大切なものです。要件定義や要件定義書を作成する際は特に重要です。ヒアリングを行う際は、きちんと裏付けもとるようにしましょう。

そのまま使える「要件定義書」のテンプレート

そのまま使うことが出来る「要件定義書」のテンプレートを紹介します。会社によってテンプレートが決められている場合はそちらに従うようにしましょう。ここで取り上げるのはかなり基本的な要件定義書にテンプレートなので、内容やプロジェクトによって変えていくのがお勧めです。

「要件定義書」のテンプレート1

【本文のテンプレート】

1(大見出し。「システム要件」等の目次にある項目名を入れる) 
1.1(中見出し。システム化する範囲など大見出しの項目に関することを書く)
(何の項目についてなどの説明文)
 (1)(各項目の説明)
 (2)
 (3)
 (4)

1.2(中見出し2)
 (1)
 (2)
 (3)
 (4)

1.3(中見出し3)
 (1)
 (2)
 (3)
 (4)

「要件定義書」の本文のテンプレートです。基本の書き方に合わせて大見出しと中見出しをつけた階層構造のテンプレートにしました。この後の項目も、見出しの番号を変えることでそのまま使いまわせます。

「要件定義書」のテンプレート2

【本文のテンプレート】

1.(大見出し)
1.1(中見出し)
(項目の説明)
ID                
開発社名  
運用開始日  
入力  
出力  
備考  

1.2(中見出し)
(項目の説明)
ID                
開発社名  
運用開始日  
入力  
出力  
備考  

表を用いた本文のテンプレートです。IT系のシステム開発でIDやコード等を書く必要がある際はこのような形のものを使うと、より見やすい文書を作成できます。他にも推移などを載せたい場合はグラフを使うとパッと見て分かるのでお勧めです。

特にID等は相手の情報に関わるものなのでヒアリングが必要な項目になります。ヒアリングを実施する際は要件定義書に書く旨も了承を得ておかなければなりません。

「要件定義書」と「要求仕様書」の違い・使い分け

「要件定義書」とかなり名前が似ているものに「要求仕様書」というものがあります。こちらもシステム開発の際に使われるものですが、「要件定義書」とは全く違うので注意しましょう。

「要求仕様書」は顧客が書くもので、読むのは開発するエンジニアです。内容は要望をまとめたものになっていますが、あくまで要望なので本文は全体で抽象的です。

「要件仕様書」の内容は顧客が「こういったシステムが欲しい」という要望

「要求仕様書」とは顧客が「こんな感じのものをいつくらいに開発して欲しい」というイメージと要望をまとめたものです。「要件仕様書」と違って専門家が書いているわけではないので、内容はやや抽象的なものになりやすいでしょう。

この「要求仕様書」を読んで、開発側はこの要望を叶えるために「要件定義」をすることになります。「要件仕様書」の詳しい書き方やテンプレートとサンプルは別のページで紹介されていますので、そちらも併せてご覧になるのをお勧めします。

Thumb「要求仕様書」の書き方や例文・サンプルを紹介|要件定義書との違い
システムなど新商品を開発する場合、設計者が要求仕様書を作成し、それを元に開発担当者が作業を行...

「要件定義書」と「要件仕様書」の違い

要件定義書 システム開発に向けて決められた要件定義について、開発側と顧客側の双方が合意した内容をまとめたもの
要求仕様書 顧客が「このようなシステムを開発して欲しい」という要望をまとめたもの

「要件定義書」と「要求仕様書」の違いをまとめるとこうなります。名前こそは似ていますが、中身は全く違うのが分かるでしょう。また、「要件定義書」はエンジニアが書くこともありますが、「要求仕様書」は100%顧客側が書くものであるという点も違っています。

「要件定義書」がシステム開発の成功のカギ

「要件定義書」の書き方と目次を含めたサンプル・テンプレートについて解説しました。この文書や「要件定義」は実際にITの世界に入って初めて存在を知った、という人も多いのではないでしょうか。

かなりのボリュームなのでテンプレートでもないと作るのが大変ですが、これがないと開発ができません。基礎をしっかり固めて、易しい書き方をすることで良い要件定義書を作ることができます。「要件定義書」の出来がプロジェクトの行方を左右するため、面倒臭がらずにきちんと書くことが重要です。

関連するまとめ

Original
この記事のライター
ふにょり
文章書きとお絵描きと猫とゲームが大好きです

人気の記事

人気のあるまとめランキング

新着一覧

最近公開されたまとめ