要件定義における成果物一覧と書き方（要件定義書サンプルあり）

システム開発の上流工程である要件定義では、顧客が抱える課題に対してどのようなシステムを作るのかを概要レベルで決定する。

要件定義が必要なのは「作ったはいいが使えないシステム」という状況を防ぐためで、システム開発におけるWhyとWhat（何のために何を作る）を明確にする工程だともいえる。

では、要件定義でどんなアウトプットを出せばいいのだろうか？

そこで今回は、要件定義で作成する成果物についてサンプルを紹介しながら説明していく。

要件定義書のサンプル

最初に、要件定義工程の最終的なアウトプットである「要件定義書」のサンプルを紹介する。

下記の資料は、調達仕様書（競争入札の際に発行するシステム仕様を記載した文書）だが、業務要件・機能要件・非機能要件が細かくまとめられているので参考になる。

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

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

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

また、IPAが作成した下記資料も、要件の書き方や記入例が詳しく説明されていて参考になる。

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

サンプルを見ると分かるように、要件定義書に決まったフォーマットは存在しない。しかしながら要件（業務要件・機能要件・非機能要件）を整理していることに変わりはないため、どういったフォーマットを用いるかは組織やプロジェクトによって決めれば良いだろう。

要件定義の成果物一覧

それでは、要件定義の成果物について１つずつ説明していく。

前もってお伝えしておくと、ここで紹介するのは大規模システム開発もサポートできる手堅い資料であるため、人によっては資料の多さに驚くかもしれない。

システム開発の規模に比例して作成する資料は多くなるが、逆に規模が小さければ資料も少なくて良い。ここで紹介する資料の中から必要なものを選んで作成すると良いだろう。

なお、ここで取り上げる資料はあくまでサンプルであるため、実際の業務ではあなたの部署の過去資料を参考にすることをお勧めする。

要件定義工程のおもな成果物は下記の通り。

1.業務要件に関わる成果物

業務要件では下記のような成果物を整理する。

これらを簡単に説明していく。

1-1.システム化の目的・背景・狙い

システム化あるいはプロジェクトを行う理由を説明した資料。進む方向性とも言え、この段階で上位者と認識の齟齬があると後述の手段（業務改革やシステム化）がひっくり返されることもあるため最も重要な資料だと言える。

ユーザー企業にヒアリングをしながら問題点・影響・原因・対策を整理していくのだが、実はこの作業は要件定義より前の「企画（システム構想とも呼ばれる）工程」にて行われていることが多い。

なお、混乱されがちな目的・背景・狙いの意味は下記の通り。（参考）日経BP『目的・背景・狙いとは何か？』

目的

なぜシステム投資を行うのか、何を達成しようとしているのか。

背景

前述の目的で書いた事柄がなぜ起きているのか（問題点や原因）。

背景

システム構築によってどのような効果を期待しているのか。

1-2.ビジネスプロセス関連図

出典：IPA『ユーザのための要件定義ガイド 第2版』,p.384

対象とする業務の全体象を把握するための資料。

作成する際に気を付ける点としては、
・関係部署やシステム関係が分かるようにする
・プロジェクトスコープが分かるようにする
・細かい業務手順は「業務フロー」に書く

なお、業務資料の関係性は下記のようになる。

出典：IPA『ユーザのための要件定義ガイド 第2版』,p.379

ビジネスプロセスを変えることは影響も大きいため、小規模なプロジェクトはビジネスプロセスは変更せずに、業務の”手段を変える”（手作業→システム自動化等）というスコープになることが多い。

1-3.業務機能構成表

出典：IPA『ユーザのための要件定義ガイド 第2版』,p.386

ビジネスプロセスから業務作業までを階層的に整理した資料。関係する業務の抜け漏れを防ぐために整理する。

当資料には業務概要を記載し、具体的な内容は「業務処理定義」に記載する。

1-4.ビジネスプロセスフロー

出典：IPA『ユーザのための要件定義ガイド 第2版』,p.390

ビジネスプロセスの流れが分かる資料。

ここでは業務の根本的な機能・目的を見える化するために、手段であるシステム利用等は記載しない。例えば、注文をメールで受けるか、オンラインシステムで受けるかは手段の違いでしかない。ビジネスプロセスとしては「注文を受ける（受注）」である。

必要に応じて現行（AsIs）を整理する。

1-5.システム化業務フロー

出典：IPA『ユーザのための要件定義ガイド 第2版』,p.394

業務の流れやシステムの利用タイミングといった業務手順が分かる資料。業務フローの一部をシステム化するプロジェクトは多いため、業務フローを作成した経験のある人も多いと思う。

当資料には手段（注文をメールで受けるのかシステムで受けるのか等）も記載する。また、通常の業務フローだけでなく、例外的な業務フロー（例えばクレーム対応等）も整理しておくと、機能要件の抜け漏れを防ぐことができる。

必要に応じて現行（AsIs）を整理する。

1-6.業務処理定義

出典：IPA『ユーザのための要件定義ガイド 第2版』,p.397

業務フローでは書ききれない詳細な業務内容が分かる資料。

各業務のIPOや5W2Hの観点で抜け漏れがないように整理していくと良い。

2.機能要件に関わる成果物

業務要件の整理が完了した後はシステム機能要件を整理していく。下記のような成果物を整理することが多い。

2-1.システム方式

システム方式はプラットフォームとも呼ばれ、システムの稼働環境を中心に整理する。

2-1-1.ハードウェア構成図

出典：農林水産省『ハードウェア構成図』

今回のシステムを実現するうえで必要なハードウェア構成を明確にする資料。メインフレームが少なくなってきた現在ではサーバ構成図とも呼ばれる。

仮想化によって１つの物理サーバ上に複数の仮想サーバーを建てることが多いため、物理サーバと仮想サーバが分かるように整理すると良い。

2-1-2.ソフトウェア構成図

出典：農林水産省『ソフトウェア構成図』

今回のシステムを実現するうえで必要なOSやミドルウェアを明確にする資料。各サーバ（仮想サーバ）毎に導入しているものを整理する。

2-1-3.ネットワーク構成図

出典：@IT『トラブル予防は現状の把握から』

今回のシステムを実現するうえで必要なネットワーク構成を明確にする資料。

ネットワーク構成図に記述するべき代表的な項目は以下のとおり。
(A)外部との接続ポイント
(B)代表的なネットワーク機器の接続
(C)代表的な共有機器の接続
(D)共有機器の接続に必要なアドレス

2-1-4.アプリケーション機能構成図

出典：IPA『機能要件の合意形成ガイド～システム振舞い編～』,p.36

開発するシステム機能が階層的に分かる資料。
システム化業務フローと紐づけられるようにIDを採番しておくと良い。

抜け漏れに気付くために、下記のような表形式で管理することも多い。

出典：IPA『機能要件の合意形成ガイド～システム振舞い編～』,p.19

2-2.画面要件

要件定義では、画面要件として下記の3つを整理する。

2-2-1.画面一覧

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.17

開発する画面を一覧にまとめた資料。
下記のようなツリー形式で表す場合もある。

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.18

2-2-2.画面遷移図

出典：経済産業省『LPガス保安技術者向けWebサイト 管理更新システム』,p.79

画面の流れが分かる資料。見える化することで画面の抜け漏れに気付きやすくなる。

2-2-3.画面レイアウト

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.26

画面のイメージを共有するための資料。

上記のように要件定義ではざっくりとしたレイアウト・機能・項目であっても見積りができれば細かいところは設計工程で決めれば良い。

2-3.帳票要件

2-3-1.帳票一覧

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.21

プロジェクトで開発する帳票を一覧にまとめた資料。

2-3-2.帳票概要

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.25

帳票の出力場所や、業務上の用途が分かる資料。

2-3-3.帳票レイアウト

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.28

帳票の具体的なイメージを明確にする資料。
上の図は設計レベルまで細かく書かれているが、要件定義では見積りができるレベルで良いので、ざっくりとしたレイアウトや項目が分かれば良い。

2-4.バッチ要件

バッチ要件として整理するのは「バッチ処理一覧」のみで、バッチ処理フローやバッチ処理定義を整理するのは基本設計フェーズとなる。

2-4-1.バッチ処理一覧

出典：IPA『機能要件の合意形成ガイド～バッチ編～』,p.23

プロジェクトで開発するバッチ機能を一覧にまとめた資料。
上記資料には書かれていないが、見積りをするうえでは処理の複雑度が重要となるため、入出力ファイル数や項目数は把握しておいた方が良いだろう。

2-5.テーブル・ファイル要件

テーブルファイル要件は下記を整理する。

2-5-1.テーブル関連図（ER図）

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.16

業務で扱うデータ構造が分かる資料で、別名はER図。

業務担当者に実業務で使用しているデータ（エクセルファイル等）を提供してもらって整理していくことが多い。なお、要件定義工程では主要なテーブルが記載できていれば良く、処理に必要なテーブルは基本設計や詳細設計にて追記していく。

テーブル関連図は業務部門との認識合わせが特に難しいため、絵や実際の値に書き出して認識を合わせていくと良い。下記資料が参考になる。（なお下記資料ではER図=概念データモデルと表現している）

> IPA『ユーザーのための要件定義ガイド』p.186

2-5-2.テーブル・ファイル一覧

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.19

前述したテーブル関連図をもとに、主要なテーブルを一覧にまとめた資料。

下記のように作られ方からテーブルを分類しておくと、設計工程でCRUD図を整理する際に役立つ。種別の意味合いは下記の通り。

2-5-3.テーブル・ファイル定義

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.22

前述したテーブル一覧を元にテーブル内の主要なデータ項目を一覧にまとめた資料。

主要な項目は業務担当者にヒアリングをしたり、業務資料を提供してもらいながら整理をしていく。

要件定義工程では必要なディスク量を見積る必要があるため、下記内容ぐらいはテーブル毎に整理した方が良いだろう。
・およその項目数と桁数
・保管期間

2-6.外部インターフェース要件

システムを構築する上で必要な外部システムとの連携（インターフェース）について整理する。

要件定義で外部インターフェースを整理するのは、インターフェースの数に比例して改修箇所やテスト範囲が拡大し、見積りのブレにつながるからである。

2-6-1.外部システム関連図

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.20

関連システムとのデータ連携を図解した資料。
今回のシステム開発対象を色分けし（上記の場合は受注管理システム）、どのシステムに影響を及ぼす可能性があるのかを整理する。

例えば、上記図でいうと「集配信システム」は、受注管理システムと直接的なインターフェースがあるわけではない。だが、もし両システム間にある「販売管理システム」がデータを横流ししているだけならば集配信システムまでのテストをしておく方が無難だろう。

外部システム関連図を整理することでこういったリスクに気付くことができる。

2-6-2.外部インターフェース一覧

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.17

関連システムとのデータ連携を一覧にまとめた資料。
見積りに影響しやすいので5W2Hで整理しておきたい。

2-6-3.外部インターフェース定義書

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.23

関連システムとのデータのやりとりについて、主要なデータ項目を一覧にまとめた資料。
テーブル定義と同じく、およその項目数と保管期間を整理しておく。

なお、要件定義工程で送受信のどちら側でデータをバックアップするのかは決めておいた方が良い。一般的には受信側がバックアップを取得するが、これは受信側の障害発生時に自システム内でデータを取り込み直せたり、改修時にテストデータとして活用したり、といった理由からである。

3.非機能要件に関わる成果物

機能要件と並行して「非機能要件」についても整理していく。非機能要件は軽視されがちだが事業に大きな影響を与える可能性があるため、要件定義の重要な検討事項として位置付けられている。

非機能要件を整理する資料として、当サイトではIPAが考案した非機能要求グレードを参考にした。（無料で利用可能）

非機能要求グレードについて

出典：IPA『非機能要求グレード 実践セミナー』,p.15

非機能要求グレードを利用することで、
・可用性
・性能・拡張性
・運用・保守性
・移行性
・セキュリティ
・システム環境・エコロジー
の６つに分類して整理することができる。

６つの分類は、下記図のように細分化されているので抜け漏れの心配なく整理できる。

出典：IPA『非機能要求グレード 実践セミナー』,p.15

非機能要求グレードの使い方

出典：IPA『非機能要求グレード 実践セミナー』,p.37

上の図にあるように、非機能要求グレードは３つの流れで要件を整理する。

項目が多すぎて心が折れそうになるが、上記の(1)と(2)の重要項目だけでも効果は大きいので、時間が無い場合は重要項目に絞って実施したい。

ここからは１つ１つの分類について簡単に説明を載せておく。詳細な説明は「利用ガイド解説編」p.22以降をご覧いただきたい。

3-1.可用性

システムを継続的に利用するための要求。

ハードウェアやソフトウェア起因による障害、あるいは災害等によって、予期せぬシステム停止が発生する。こういった障害の回避策あるいは影響の軽減策について、要求を整理する。

3-2.性能・拡張性

システムの性能および将来のシステム拡張に関する要求。

3-3.運用・保守性

システム運用保守に関する要求。

運用保守の方法や手順を整理する中で、購入機器や開発機能が追加になることがあるため、要件定義での検討が必要となる。

3-4.移行性

現行システム資産の移行に関する要求。

3-5.セキュリティ

情報システムの安全性の確保に関する要求。

3-6.システム環境・エコロジー

システム設置場所やエコロジー(CO2排出量や消費エネルギー等）に関する要求。

資料作成に役立つアイコン提供サイト

要件定義で整理すべき３つの要件（業務要件・機能要件・非機能要件）について成果物の一例を紹介してきた。ここで資料作成に役立つサイトを紹介しておく。

下記は図解に役立つアイコンを無料で提供してくれているサイト。

icooon-mono
業務フロー作成のアイコンに便利

CISCO『Network Topology Icons』
ネットワーク構成図のアイコンに便利

さいごに

要件定義工程の成果物を紹介してきた。

あまりの資料の多さに嫌気がするが、どんな資料をつくるのかはプロジェクトの特性によっても異なるし、組織のルールによっても異なる。このため、最初に述べたようにまずは部署の過去資料を確認してほしい。

また、要件定義では細かい仕様まで決める必要はない。例えば画面ならばざっくりしたレイアウト・機能・項目について書けていれば良く、細かく整理するのは設計工程となる。

以上、参考になれば幸いだ。

要件定義工程の関連記事はこちら。

要件定義工程の進め方

2021年2月7日

要件定義の目的は「プロジェクト5W2Hを明確にして失敗を減らすこと」

2021年2月6日

要件定義における成果物一覧と書き方（要件定義書サンプルあり）

2021年2月5日

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

参考文献

IPA『ユーザのための要件定義ガイド 第2版』

IPA『機能要件の合意形成ガイド～システム振舞い編～』

IPA『機能要件の合意形成ガイド～画面編～』

IPA『機能要件の合意形成ガイド～帳票編～』

IPA『機能要件の合意形成ガイド～バッチ編～』

IPA『機能要件の合意形成ガイド～データモデル編～』

IPA『機能要件の合意形成ガイド～外部インタフェース編～』

IPA『非機能要求グレード』

IPA『非機能要求グレード 実践セミナー』

経済産業省『LPガス保安技術者向けWebサイト 管理更新システム』

農林水産省『ハードウェア・ソフトウェア構成図』

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

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

@IT『トラブル予防は現状の把握から』

日経BP『目的・背景・狙いとは何か？』

マイナビニュース『3秒が許容範囲 – Webサイトのパフォーマンスが重要な理由』

Wikipedia『7Pay』