
システム開発の上流工程である要件定義では、顧客が抱える課題に対してどのようなシステムを作るのかを概要レベルで決定する。
要件定義が必要なのは「作ったはいいが使えないシステム」という状況を防ぐためで、システム開発におけるWhyとWhat(何のために何を作る)を明確にする工程だともいえる。
では、要件定義でどんなアウトプットを出せばいいのだろうか?
そこで今回は、要件定義で作成する成果物についてサンプルを紹介しながら説明していく。
要件定義書のサンプル
最初に、要件定義工程の最終的なアウトプットである「要件定義書」のサンプルを紹介する。
下記の資料は、調達仕様書(競争入札の際に発行するシステム仕様を記載した文書)だが、業務要件・機能要件・非機能要件が細かくまとめられているので参考になる。
厚生労働省『毎月勤労統計調査オンラインシステムの更改及び運用・保守に係る業務一式 要件定義書』
厚生労働省『厚生労働省情報提供システムの更改整備及び運用・保守業務一式 要件定義書』
また、IPAが作成した下記資料も、要件の書き方や記入例が詳しく説明されていて参考になる。
サンプルを見ると分かるように、要件定義書に決まったフォーマットは存在しない。しかしながら要件(業務要件・機能要件・非機能要件)を整理していることに変わりはないため、どういったフォーマットを用いるかは組織やプロジェクトによって決めれば良いだろう。
要件定義の成果物一覧
それでは、要件定義の成果物について1つずつ説明していく。
前もってお伝えしておくと、ここで紹介するのは大規模システム開発もサポートできる手堅い資料であるため、人によっては資料の多さに驚くかもしれない。
システム開発の規模に比例して作成する資料は多くなるが、逆に規模が小さければ資料も少なくて良い。ここで紹介する資料の中から必要なものを選んで作成すると良いだろう。
なお、ここで取り上げる資料はあくまでサンプルであるため、実際の業務ではあなたの部署の過去資料を参考にすることをお勧めする。
要件定義工程のおもな成果物は下記の通り。
1.業務要件
1-1.システム化の目的・背景・狙い
1-2.ビジネスプロセス関連図
1-3.業務機能構成表
1-4.ビジネスプロセスフロー
1-5.システム化業務フロー
1-6.業務処理定義書
2.機能要件
2-1.システム方式
2-1-1.ハードウェア構成図
2-1-2.ソフトウェア構成図
2-1-3.ネットワーク構成図
2-1-4.アプリケーション機能構成図
2-2.画面要件
2-2-1.画面一覧
2-2-2.画面遷移図
2-2-3.画面レイアウト
2-3.帳票要件
2-3-1.帳票一覧
2-3-2.帳票概要
2-3-3.帳票レイアウト
2-4.バッチ要件
2-4-1.バッチ処理一覧
2-5.テーブル・ファイル要件
2-5-1.テーブル関連図
2-5-2.テーブル・ファイル一覧
2-5-3.テーブル・ファイル定義
2-6.外部インターフェース要件
2-6-1.外部システム関連図
2-6-2.外部インターフェース一覧
2-6-3.外部インターフェース定義書
3.非機能要件
3-1.可用性
3-2.性能・拡張性
3-3.運用・保守性
3-4.移行性
3-5.セキュリティ
3-6.システム環境・エコロジー
1.業務要件に関わる成果物
業務要件では下記のような成果物を整理する。
1-1.システム化の目的・背景・狙い
1-2.ビジネスプロセス関連図
1-3.業務機能構成表
1-4.ビジネスプロセスフロー
1-5.システム化業務フロー
1-6.業務処理定義書
これらを簡単に説明していく。
1-1.システム化の目的・背景・狙い
システム化あるいはプロジェクトを行う理由を説明した資料。進む方向性とも言え、この段階で上位者と認識の齟齬があると後述の手段(業務改革やシステム化)がひっくり返されることもあるため最も重要な資料だと言える。
ユーザー企業にヒアリングをしながら問題点・影響・原因・対策を整理していくのだが、実はこの作業は要件定義より前の「企画(システム構想とも呼ばれる)工程」にて行われていることが多い。
なお、混乱されがちな目的・背景・狙いの意味は下記の通り。(参考)日経BP『目的・背景・狙いとは何か?』
目的
なぜシステム投資を行うのか、何を達成しようとしているのか。
背景
前述の目的で書いた事柄がなぜ起きているのか(問題点や原因)。
・現行システムは構築から8年が経過し新たな業務への対応が困難であり、それを手作業で補っているため事務のミスが増加している。
・新業務に関する事務の比率が増加しており、今後さらに事務負担の増大が予想される。
・現行システムのインフラの多くは既にサポート期間が終了しており、維持管理上の深刻な課題となっている。
狙い
システム構築によってどのような効果を期待しているのか。
・システム化が未着手の○○業務への対応による効率化
・上記の○○業務システムと基幹システムとのデータ連携
・手作業によるデータ・チェック作業の自動化による人為ミスの減少
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の観点で抜け漏れがないように整理していくと良い。
・Input(入力) :作業に必要なもの
・Process(処理):作業の内容
・output(出力) :作業後に作成されるもの
What:何を入力し、何を出力するのか
Who:入力元、出力先、作業者は誰か
When:時間、時期、作業にかかる時間
Where:入力元、出力先、作業者の場所
Why:なぜ必要な作業なのか
How:どうやって作業をするのか(手段)
How many(How much):業務量はどの程度か
2.機能要件に関わる成果物
業務要件の整理が完了した後はシステム機能要件を整理していく。下記のような成果物を整理することが多い。
2-1.システム方式
2-1-1.ハードウェア構成図
2-1-2.ソフトウェア構成図
2-1-3.ネットワーク構成図
2-1-4.アプリケーション機能構成図
2-2.画面要件
2-2-1.画面一覧
2-2-2.画面遷移図
2-2-3.画面レイアウト
2-3.帳票要件
2-3-1.帳票一覧
2-3-2.帳票概要
2-3-3.帳票レイアウト
2-4.バッチ要件
2-4-1.バッチ処理一覧
2-5.テーブル・ファイル要件
2-5-1.テーブル関連図
2-5-2.テーブル・ファイル一覧
2-5-3.テーブル・ファイル定義
2-6.外部インターフェース要件
2-6-1.外部システム関連図
2-6-2.外部インターフェース一覧
2-6-3.外部インターフェース定義書
2-1.システム方式
システム方式はプラットフォームとも呼ばれ、システムの稼働環境を中心に整理する。
2-1-1.ハードウェア構成図
2-1-2.ソフトウェア構成図
2-1-3.ネットワーク構成図
2-1-4.アプリケーション機能構成図
2-1-1.ハードウェア構成図
今回のシステムを実現するうえで必要なハードウェア構成を明確にする資料。メインフレームが少なくなってきた現在ではサーバ構成図とも呼ばれる。
回線、ルータ、スイッチ、負荷分散装置、ファイアウォール等
・ストレージ
ディスク装置、テープ装置等
・サーバー
CPU、メモリ、入出力機構等
仮想化によって1つの物理サーバ上に複数の仮想サーバーを建てることが多いため、物理サーバと仮想サーバが分かるように整理すると良い。
2-1-2.ソフトウェア構成図
今回のシステムを実現するうえで必要なOSやミドルウェアを明確にする資料。各サーバ(仮想サーバ)毎に導入しているものを整理する。
Windows、Mac-OS、Unix、Linux、iOS、Android等
・データベース
Oracle、DB2、SQLServer、MySQL、PostgreSQL等
・Webサーバ
Apache、Nginx、IIS等
・アプリケーションサーバ
WAS、Tomcat、WebLogic、JBoss、Interstage等
・データ連携
WebSphere-MQ、HULFT、全銀系ソフト等
・統合運用管理
JP1、Systemwalker、Tivoli、A-AUTO等
出典:Wikipedia『ミドルウェア』を元に記載
2-1-3.ネットワーク構成図
今回のシステムを実現するうえで必要なネットワーク構成を明確にする資料。
ネットワーク構成図に記述するべき代表的な項目は以下のとおり。
(A)外部との接続ポイント
(B)代表的なネットワーク機器の接続
(C)代表的な共有機器の接続
(D)共有機器の接続に必要なアドレス
2-1-4.アプリケーション機能構成図

出典:IPA『機能要件の合意形成ガイド~システム振舞い編~』,p.36
開発するシステム機能が階層的に分かる資料。
システム化業務フローと紐づけられるようにIDを採番しておくと良い。
抜け漏れに気付くために、下記のような表形式で管理することも多い。

出典:IPA『機能要件の合意形成ガイド~システム振舞い編~』,p.19
2-2.画面要件
要件定義では、画面要件として下記の3つを整理する。
2-2-2.画面遷移図
2-2-3.画面レイアウト(概要)
2-2-1.画面一覧

出典:IPA『機能要件の合意形成ガイド~画面編~』,p.17
開発する画面を一覧にまとめた資料。
下記のようなツリー形式で表す場合もある。

出典:IPA『機能要件の合意形成ガイド~画面編~』,p.18
2-2-2.画面遷移図
画面の流れが分かる資料。見える化することで画面の抜け漏れに気付きやすくなる。
2-2-3.画面レイアウト

出典:IPA『機能要件の合意形成ガイド~画面編~』,p.26
画面のイメージを共有するための資料。
上記のように要件定義ではざっくりとしたレイアウト・機能・項目であっても見積りができれば細かいところは設計工程で決めれば良い。
2-3.帳票要件
2-3-2.帳票概要
2-3-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-2.テーブル・ファイル一覧
2-5-3.テーブル・ファイル定義
2-5-1.テーブル関連図(ER図)

出典:IPA『機能要件の合意形成ガイド~データモデル編~』,p.16
業務で扱うデータ構造が分かる資料で、別名はER図。
業務担当者に実業務で使用しているデータ(エクセルファイル等)を提供してもらって整理していくことが多い。なお、要件定義工程では主要なテーブルが記載できていれば良く、処理に必要なテーブルは基本設計や詳細設計にて追記していく。
テーブル関連図は業務部門との認識合わせが特に難しいため、絵や実際の値に書き出して認識を合わせていくと良い。下記資料が参考になる。(なお下記資料ではER図=概念データモデルと表現している)
2-5-2.テーブル・ファイル一覧

出典:IPA『機能要件の合意形成ガイド~データモデル編~』,p.19
前述したテーブル関連図をもとに、主要なテーブルを一覧にまとめた資料。
下記のように作られ方からテーブルを分類しておくと、設計工程でCRUD図を整理する際に役立つ。種別の意味合いは下記の通り。
受注、発注などの業務活動によって発生・増加する情報を管理するテーブル
リソース系
商品マスタ・倉庫マスタ等、イベント系テーブルから参照される実際に存在するモノを管理するテーブル
サマリ系
売上高など、業務活動によって発生した情報の集計結果を管理するテーブル
2-5-3.テーブル・ファイル定義

出典:IPA『機能要件の合意形成ガイド~データモデル編~』,p.22
前述したテーブル一覧を元にテーブル内の主要なデータ項目を一覧にまとめた資料。
主要な項目は業務担当者にヒアリングをしたり、業務資料を提供してもらいながら整理をしていく。
要件定義工程では必要なディスク量を見積る必要があるため、下記内容ぐらいはテーブル毎に整理した方が良いだろう。
・およその項目数と桁数
・保管期間
2-6.外部インターフェース要件
システムを構築する上で必要な外部システムとの連携(インターフェース)について整理する。
要件定義で外部インターフェースを整理するのは、インターフェースの数に比例して改修箇所やテスト範囲が拡大し、見積りのブレにつながるからである。
2-6-2.外部インターフェース一覧
2-6-3.外部インターフェース定義書
2-6-1.外部システム関連図

出典:IPA『機能要件の合意形成ガイド~外部インタフェース編~』,p.20
関連システムとのデータ連携を図解した資料。
今回のシステム開発対象を色分けし(上記の場合は受注管理システム)、どのシステムに影響を及ぼす可能性があるのかを整理する。
例えば、上記図でいうと「集配信システム」は、受注管理システムと直接的なインターフェースがあるわけではない。だが、もし両システム間にある「販売管理システム」がデータを横流ししているだけならば集配信システムまでのテストをしておく方が無難だろう。
外部システム関連図を整理することでこういったリスクに気付くことができる。
2-6-2.外部インターフェース一覧

出典:IPA『機能要件の合意形成ガイド~外部インタフェース編~』,p.17
関連システムとのデータ連携を一覧にまとめた資料。
見積りに影響しやすいので5W2Hで整理しておきたい。
What:データ形式等(XML、TEXT等)
Who:入出力するのはどの機能か
When:送受信の頻度やタイミング
Where:入出力するのはどのシステムか
Why:なぜ必要なデータなのか
How:送受信手段(API、FTP、HULFT等)
How many:データ量
2-6-3.外部インターフェース定義書

出典:IPA『機能要件の合意形成ガイド~外部インタフェース編~』,p.23
関連システムとのデータのやりとりについて、主要なデータ項目を一覧にまとめた資料。
テーブル定義と同じく、およその項目数と保管期間を整理しておく。
なお、要件定義工程で送受信のどちら側でデータをバックアップするのかは決めておいた方が良い。一般的には受信側がバックアップを取得するが、これは受信側の障害発生時に自システム内でデータを取り込み直せたり、改修時にテストデータとして活用したり、といった理由からである。
3.非機能要件に関わる成果物
機能要件と並行して「非機能要件」についても整理していく。非機能要件は軽視されがちだが事業に大きな影響を与える可能性があるため、要件定義の重要な検討事項として位置付けられている。
2019年、セブン&アイ・ホールディングスのグループ企業が始めた7Pay事業は30億円を投じたにも関わらず、不正利用によってわずか3ヶ月でサービス終了となる事態となった。
(参考)Wikipedia『7Pay』
2012年のマイナビニュース記事によると、性能面では画面表示が3秒を超えると
・1秒遅くなるとページビューが11%減少
・顧客満足度が16%低下
・コンバージョン率が7%減少
というように売上に大きな影響を与える。
非機能要件を整理する資料として、当サイトではIPAが考案した非機能要求グレードを参考にした。(無料で利用可能)
非機能要求グレードについて

出典:IPA『非機能要求グレード 実践セミナー』,p.15
非機能要求グレードを利用することで、
・可用性
・性能・拡張性
・運用・保守性
・移行性
・セキュリティ
・システム環境・エコロジー
の6つに分類して整理することができる。
6つの分類は、下記図のように細分化されているので抜け漏れの心配なく整理できる。

出典:IPA『非機能要求グレード 実践セミナー』,p.15
非機能要求グレードの使い方

出典:IPA『非機能要求グレード 実践セミナー』,p.37
上の図にあるように、非機能要求グレードは3つの流れで要件を整理する。
(2) 重要項目について、グレード表を用いて、項目毎の要求レベルを設定する
(3) 重要項目以外について、項目一覧表を用いて、項目毎の要求レベルを設定する
項目が多すぎて心が折れそうになるが、上記の(1)と(2)の重要項目だけでも効果は大きいので、時間が無い場合は重要項目に絞って実施したい。
ここからは1つ1つの分類について簡単に説明を載せておく。詳細な説明は「利用ガイド解説編」p.22以降をご覧いただきたい。
3-1.可用性
システムを継続的に利用するための要求。
ハードウェアやソフトウェア起因による障害、あるいは災害等によって、予期せぬシステム停止が発生する。こういった障害の回避策あるいは影響の軽減策について、要求を整理する。
・稼働率
・目標復旧時間
・大規模災害次の復旧
3-2.性能・拡張性
システムの性能および将来のシステム拡張に関する要求。
・性能目標(レスポンスやスループット)
・拡張性の有無(ディスク等のリソース)
3-3.運用・保守性
システム運用保守に関する要求。
運用保守の方法や手順を整理する中で、購入機器や開発機能が追加になることがあるため、要件定義での検討が必要となる。
・運用時間
・バックアップ
・運用監視(サーバー死活監視等)
・マニュアル作成
・メンテナンス許容時間
3-4.移行性
現行システム資産の移行に関する要求。
・移行方式の規定(一括or段階的)
・移行時のシステム停止可否
・設備やデータ移行の有無
3-5.セキュリティ
情報システムの安全性の確保に関する要求。
・利用者の公開範囲
3-6.システム環境・エコロジー
システム設置場所やエコロジー(CO2排出量や消費エネルギー等)に関する要求。
・法律や条例などの制約有無
・耐震の必要性
資料作成に役立つアイコン提供サイト
要件定義で整理すべき3つの要件(業務要件・機能要件・非機能要件)について成果物の一例を紹介してきた。ここで資料作成に役立つサイトを紹介しておく。
下記は図解に役立つアイコンを無料で提供してくれているサイト。
icooon-mono
業務フロー作成のアイコンに便利
CISCO『Network Topology Icons』
ネットワーク構成図のアイコンに便利
さいごに
要件定義工程の成果物を紹介してきた。
あまりの資料の多さに嫌気がするが、どんな資料をつくるのかはプロジェクトの特性によっても異なるし、組織のルールによっても異なる。このため、最初に述べたようにまずは部署の過去資料を確認してほしい。
また、要件定義では細かい仕様まで決める必要はない。例えば画面ならばざっくりしたレイアウト・機能・項目について書けていれば良く、細かく整理するのは設計工程となる。
以上、参考になれば幸いだ。
要件定義工程の関連記事はこちら。
参考文献
経済産業省『LPガス保安技術者向けWebサイト 管理更新システム』
厚生労働省『毎月勤労統計調査オンラインシステムの更改及び運用・保守に係る業務一式 要件定義書』
厚生労働省『厚生労働省情報提供システムの更改整備及び運用・保守業務一式 要件定義書』
マイナビニュース『3秒が許容範囲 – Webサイトのパフォーマンスが重要な理由』
コメントを残す