【現場ですぐ使える】要件定義書の書き方とコツ|目次・項目・ヒアリングサンプル例

要件定義書って何を書けばいいかよくわかりません。

と言った悩みに答えます。

この記事を読むことで、要件定義書を書く上で、必要な【目次・項目・ヒアリングサンプル】を理解できます。記事後半では、要件定義を上手に書き上げるためにどんなスキルが必要かも合わせて解説します。

要件定義は型を覚えることで、どんどん推進の質とアウトプットを上げることができます。

✔記事の信ぴょう性

グルー

SE＋社内SE歴15年以上。現大手EC運営企業の管理職　兼　社内SE講師。

グローバル（15か国以上導入）へ大規模ERPシステム開発・導入を実施。

2018年よりSE講師として100名弱の部下・生徒の教育を実施。

※本記事ではシステム開発のある程度基本的知識がある方に便利なテンプレをまとめました。
システム開発の基礎をしっかり身につけたい方は以下の記事をご覧ください。
・独学でコツコツ勉強したい人向け＝システム開発におすすめの書籍
・基礎をしっかり短期間で学びたい人向け＝SEにおすすめプログラミングスクール（無料あり）

✔目次

要件定義に必要な成果物の全体像をおさえよう
1. 要件定義書：全体目次イメージ
要件定義書：業務要件
要件定義書：機能要件
要件定義書：非機能要件
要件定義の各成果物を書いていく流れ
要件定義書時の注意点＆コツ
要件定義書作成に必要なスキルとは？どう上達することが出来る？
【現場ですぐ使える】要件定義書の書き方とコツ|目次・項目・ヒアリングサンプル例まとめ

要件定義に必要な成果物の全体像をおさえよう

要件定義書として構成する(書くべき関連）要素は、

業務要件
機能要件
非機能要件
の3つで構成されます。

要件定義書：全体目次イメージ

要件定義書の目次をご紹介します。

以下の目次イメージでまずはどんな項目のアウトプットが最終的に必要かを理解しましょう。

業務要件
・背景と目的
・システム概要
・システム全体像
・システム機能構成
・今回のスコープ
・タイムライン

機能要件
・要件一覧と概要
・画面要件
・帳票要件
・外部IF(インターフェース)要件

非機能要件
・システム方式
・性能要件
・拡張性要件
・セキュリティー要件
・テスト要件
・移行要件
・トレーニング要件
・運用・保守要件

最終成果物として、上記の項目を埋めることが出来れば、要件定義は完了します。

要件定義書のサンプルは以下記事で、ワード・エクセル両方のサンプルを紹介しています。

要件定義書：業務要件

業務の要求に基づき求められる【ビジネス・業務視点の観点】を記載します。業務要件をクリアに文章化することにより、問題発生時、【そもそも、この機能は本当にリリースまでに必要なのか？】の検討・議論をする際に立ち返るポイントになります。

業務と詰めるべき一番大事な点です。

上記のヒアリングを実施することにより、以下の目次の項目を文章化していくことが出来ます。

・システム化の背景と目的
・システム概要
・システム化の範囲
・AS-IS業務フロー
・To-Be業務フロー
・マイルストーン

順番的には、

システム化の背景・範囲のヒアリングを実施
【今回のシステムの背景を理解させてください。】

AS-ISの業務フローのヒアリング
【まずは、既存の業務を正しく理解したいです。業務フローを使って教えていただけますか？】

TO-BEの業務フローのヒアリング
【今回の達成したい目的を加味した、将来の業務フローに関して今時点の構想を教えてください。もし、まだあまり具体的でなければ関係者でウォークスルーでもやりませんか？】

システム化の範囲の検討
【ウォークスルー中：もし、今回のシステム化しなければいけない課題等ある部分は是非、ポイントが明確になるように詳しく教えてください】

システム概要の構想協議
【抽出した課題から：今回抽出した課題を元にそれぞれセッションを開きトピック事に深堀して機能か要件の整理をさせてください】

To-BEの業務フローの詳細化（範囲が広い場合はプロセス単位等でヒアリングを検討）
【実現したい機能をさらにイメージがわくようにフローや既存の画面等使いながら詳細の話をヒアリング更にさせてください】

がお勧めです。

要件定義書：機能要件

業務要件に基づき、システム化に必要な、ソフトウェア要件・機能要件を記載していきます。

ここまでのヒアリング内容に基づき、システム化の機能要件に関して明文化していきます。

・システム全体像
・要件一覧と概要
・画面要件
・帳票要件
・外部IF(インターフェース)要件
・テーブル定義書
・コード定義書
・データ一覧

システム全体像

システム化の範囲に基づき、新しいシステムがどのような構成になるのか？を記載します。

要件一覧と概要

システム化したい要件を一覧にしていきます。詳細はこの時点で必要ありませんが、どのような要件なのか認識齟齬がないように記載と合意が必要です。

画面要件

この時点でモックイメージまで作れればこしたことはありません。既存システムであれば、今ある画面設計書を流量するなどして画面要件を記載していきます。

帳票要件

帳票に関しても同様で、今回の業務要件に基づきどのようにな項目の修正が必要なのか？を帳票要件に記載していきます。

外部IF(インターフェース)要件

外部インターフェース要件は、システム間のデータ連携に必要な改修必要インターフェースを明文化します。どんなインターフェースが対象になるか機能・画面・帳票要件から洗い出します。

テーブル・コード・データ要件

上記の要件深堀を実施することにより、どんなデータが必要かを洗い出します。ここまでの必要な情報が必要が揃えば機能要件は全て洗い出せたことになります。

データに関しては、移行データがある場合はこの完成形のシステムが必要なデータ情報に基づき、既存のデータベースのデータとどうマッピングするのか？等別途検討が必要になります。

よくある失敗

要件定義時に様々な要望課題が出てきます。

その際に、
・システム移行の過渡期の話と、
・本来解決したい業務課題
を混合する場合があります。

このケース、あのケースどうなるの？と言った根掘り葉掘り様々なケースをディスカッションするのは大変いいことですが、本質の課題なのか？そうでないかの判別は非常に重要です。

要件定義を進めるためには、過渡期の課題なのか？本質的な業務の課題の話なのかを整理しつつ議論が必要です。

要件定義書：非機能要件

インフラや性能・セキュリティの視点で業務ユーザーには直接機能として関係はないが、サービスレベルの合意で非常に重要な要素を合意し記述していきます。

非機能要件でヒアリングすべき項目も沢山あります。

・システム方式
・システムの規模
・性能要件
・拡張性要件
・継続性要求
・セキュリティー要件
・テスト要件
・移行要件
・トレーニング要件
・運用・保守要件

しかし、機能要件とはアプローチが異なり、かなり機械的にヒアリング・文章準備を実施することが出来ます。

要件定義の各成果物を書いていく流れ

ここまでは、要件定義の様々な項目をご紹介しました。

要件定義って、成果物だらけで、何からどうやって準備すればいいの？

沢山の項目がありすぎ具体的にどう準備していったらいいかわからない！

って、なってると思いますが、心配はいりません。

各成果物に必要なインプットを理解する事で、そのインプットを順序だてて用意すれば要件定義書が出来上がります。

要件定義書作成には、何をどんな順序で準備するかが重要です。

要件定義書を書いていく段取り・方法

最終的な成果物を作っていく大きな流れは以下です。

情報収集を行う→文章化する→要件定義書の完成！

ポイント
機能要件と非機能要件では、要件定義書を書くために必要な情報収集のアプローチが異なります。

業務要件・機能要件は、業務提供資料・ディスカッションがベースとなります。一方、非機能要件はヒアリングをベースに実施していきます、。

機能要件の情報収集の流れ

機能要件を特定する王道の流れとしては、
・AS-ISの業務フローを説明してもらう
・To-BEの業務フローを説明してもらう
・To-BEの業務フローでシステム化するプロセスを特定する
・そのプロセスでシステム化する機能を合意する
・システム化の要件を明確化する

とってもシンプルに聞こえますが、これが体系立てて実施するのが難しです。

先にお伝えした、業務がいけていないケース＝そもそも上記のアプトプットを作る必要性・システムに説明する役割を理解していません。

そんなケースには、もちろん相手との立場や本人の力量もみながら、社内SE/情シスが成果物のたたき台を作成してあげる必要があります。

この際に重要な事は、明確に要件ＦＩＸする合意プロセスを必ず入れる！事です。

システム開発の失敗の殆どは要件定義で仕込まれます。

非機能要件書き上げるためにヒアリングシートを準備

非機能要件は、ヒアリングシートベースにかなり機械的に進めることが出来ます。

農林水産省のシステムをアクセンチュア社が実施したサンプルが公開されています。

この非機能要件書の項目に沿って業務にヒアリングし構築することで機械的に作成可能です。

IPAが作成してくれているガイドでかなり網羅的に準備が可能です。資料を手元にDLしておくと便利です。

非機能要求グレード本体（日本語版）DLはこちら

以下の様なエクセル入りですぐにテンプレートとして活用できます。

非機能要件サンプル

札幌市のシステム開発で利用された非機能要件のシートも網羅的で分かり易いです。

非機能要件一覧 – 札幌市のサンプル

この２つを眺め、あなたの開発に必要そうな観点を洗い出しＱＡを作成すればＯＫです。

要件定義書時の注意点＆コツ

要件定義書作成時の抑えておきたい、幾つかの注意点やコツがあります。

要件定義書作成時の注意点・コツの観点

・主体性・やる気の無い業務ユーザーには、ある程度支援する覚悟（やさしさ）
・ディスカッション内容を文字（記録）に残す
・明確に【業務要件合意プロセス】を設ける

主体性・やる気の無い業務ユーザーには、ある程度支援する覚悟（やさしさ）

要件定義の情報の起点は、業務・サービス変革をしたい業務ユーザーです。その一番情報フローのスタートが詰まってしまうと、何もかも進みません。

どんどん検討を進めてくれるユーザーであればいいのですが、そうでない場合は、社内SE・情シスで身を乗り出し要件検討を推進してあげるしかありません（事業・企業的にそのシステム開発に本当に効果が見込まれる場合）。

その場合は、本来業務ユーザーが用意すべき、業務フロー等をたたかれ台として社内SE・情シスで作ってあげる必要があります。

ディスカッション内容を文字（記録）に残す

正直、システム開発を完了させるのと、そのシステムでビジネスに貢献する、は別物です。

いくら業務の要望通りのシステムを作成しても、業務・ビジネスに役立たたないときもあります。

しかし、システム開発を完了させることは必ずできます。

それは、決められた要件を合意し、それを作ることです。システム開発において、”決められた要件”を明確にするために、１にも２にも文章化（記録）が重要です。

明確に【業務要件合意プロセス】を設ける

社内SE・情シスが身を乗り出し、本来業務が作成すべき成果物の支援をした場合、
・主体性がない
・責任化の欠落
・運用が回らない場合人のせいにする
等発生します。

こういった情報を回避しつつ、更に、決められた要件でシステム開発を実施するために、どんなシステム開発でも最も重要なイベントが、【業務との要件合意プロセス】です。

この工程無くして、システム開発の成功はありえません。

逆説的には、どんなにいけていないシステム要件でも、合意してしまえばその通りに作ることが出来ます。。。

大事なのでもう一度、必ず承認プロセスを会議・メールなど記録に残す！記憶に残すだけでは足元救われます！

要件定義で業務ユーザーとの合意形成は、記憶ではなく、記録に残す。。。このが生き死に関わる。。。
— グル@社内SE講師 (@it_compass_guru) September 11, 2020

要件定義書作成に必要なスキルとは？どう上達することが出来る？

以下の記事でシステム開発に関して必要な書籍をご紹介しています。

その中で特に、要件定義を上手く進める為に必要なスキルは、

・ヒアリングを上手に行い良質なインプットを得るスキル
・ヒアリングした内容を整理するスキル
・ヒアリング結果を明確なアウトプットで表現する技術

です。

ヒアリングを上手に行い良質なインプットを得るスキル

要件定義でまず必要な情報は、業務知識です。これは、今お仕事されている業務の経験次第です。

その他に必要な情報が、システム開発したい業務要望になります。要件を上手く引き出す為に、ヒアリングスキル＝コミニケーションスキルが必要なります。

ヒアリングスキル
11冊目：相手の本当の気持ちを・意図を理解する能力【要求仕様の探求学】

情報を深堀するなぜなぜ分析
15冊目　SI・ソフトウェア事業のなぜなぜ分析

ヒアリングした内容を整理するスキル

ヒアリングした内容を元に、情報を整理しアウトプットに結び付ける必要があります。様々な情報を整理する技術を身に着けることで状況によって使い分けることが出来ます。

情報整理スキル
アウトプットの精度を爆発的に高める「思考の整理」全技術

ヒアリング結果を明確なアウトプットで表現する技術

情報収集・整理とあわせて磨きたいスキルがアウトプットスキルです。

システム開発において紙に書いてない事は、存在しないと同じです。

アウトプットスキル
13冊目：【SEのための図解の技術、文章の技術】決めごとを文章にする能力