要件定義書とは、要件定義のヒアリングで決まった内容を、開発チームと発注者の双方が確認できる形で文書にまとめたものです。初めて作成を任されると、何を書けばいいのか、どんな項目が必要なのか分からず、見本が欲しいと感じる人も多いのではないでしょうか。
この記事では、飲食店オーナーからオンライン予約システムの開発を依頼された場面を例に、要件定義書に必要な項目と書き方の手順、仕様書との違いを解説します。
- 要件定義書が、なぜ必要とされる文書なのか
- 要件定義書に最低限必要な項目
- 要件定義書の書き方の基本的な手順
- サンプル・テンプレートを使うときに気をつけたいこと
<この記事もおすすめ！>
\株式会社PRUMのメディア/
「IT業界の要件定義書」とは、
システムに必要な機能や条件をまとめた文書
飲食店オーナーへのヒアリングを通じて、予約機能の範囲やキャンセルの扱いといった要件が固まったとしましょう。この決まった内容を、口頭のやり取りだけで終わらせず、文書として残したものが要件定義書です。
要件定義書は、発注者と開発者の「認識のズレ」を防ぐ文書
ヒアリングの場では「そういうことですね」と双方が納得したつもりでも、時間が経つと記憶が曖昧になったり、細部の解釈が食い違ったりすることがあります。
- 文書がない場合：
あとになって「言った」「言っていない」という水掛け論になりやすい - 要件定義書がある場合：
飲食店オーナーと開発チームの双方が、同じ文書を見ながら「当日キャンセルにはキャンセル料が発生する」といった条件をいつでも確認できる
こうして、双方が同じ内容を確認できる状態を作ることが、要件定義書の大きな役割です。
要件定義書と仕様書は、工程が違うため中身も違う
要件定義書と仕様書は混同されがちですが、作成される工程が異なります。
- 要件定義書：
要件定義の工程で作成される、「何を作るか」をまとめた文書（例：予約機能が必要） - 仕様書：
基本設計・詳細設計の工程で作成される、「どう作るか」を具体的に記述した文書（例：予約フォームの入力項目、データベースへの保存形式）
どちらも似た響きの言葉ですが、指しているタイミングと中身が違うと覚えておきましょう。では、要件定義書には具体的にどんな項目を書けばいいのか、次に見ていきます。
「IT業界の要件定義書」に最低限必要な書くべき項目とは
要件定義書には、プロジェクトによって細かい項目の違いはあるものの、最低限押さえておきたい共通の要素があります。
業務要件・機能要件・非機能要件の3つを区別して書く
要件定義書の中心になるのが、次の3つの要件です。
- 業務要件：
解決したい業務上の課題や目的（例：電話予約対応にかかる人件費を減らしたい） - 機能要件：
システムに実装すべき機能（例：予約機能、キャンセル機能、管理画面での空席確認機能） - 非機能要件：
機能以外に満たすべき性能や条件（例：同時に100件アクセスがあっても表示が遅延しない、深夜のメンテナンス時間以外は常時利用できる）
この3つを区別せずに書いてしまうと、「なぜこの機能が必要なのか」という背景と、「実際に何を作るのか」という中身が混ざってしまい、後から読み返したときに意図が伝わりにくくなります。3つを分けて整理しておくことで、それぞれの項目が何のために存在するのかが明確になります。
スコープ（対象範囲）と対象外もあわせて明記する
要件定義書には、「何を作るか」だけでなく、「何を作らないか」もあわせて明記しておくことが重要です。たとえば、次のような一文です。
- 「Web予約フォームのみ対応し、電話予約システムとの連携は今回のスコープ外とする」
こうした対象外の範囲を先に明記しておくことで、開発の途中で「電話予約とも連携できるはずでは」という認識のズレが生まれるのを防げます。後から追加の要望が出てきた際にも、今回のスコープに含まれるかどうかを文書に沿って判断しやすくなります。ここまでで必要な項目が分かったところで、実際にどう書き進めればいいのか、手順を見ていきましょう。
「IT業界の要件定義書」の書き方、基本的な作成手順について
要件定義書は、いきなり項目を埋めていくのではなく、次のような順序で書き進めると整理しやすくなります。
現状業務の整理から始め、課題とゴールを明確にする
まずは、現状の業務がどうなっているかを整理することから始めます。飲食店の例であれば、次のような現状を洗い出します。
- 電話予約の対応に1日あたりどれくらいの時間がかかっているか
- 予約の聞き間違いによるトラブルがどの程度発生しているか
そのうえで、「電話対応の負担を減らし、予約ミスをなくす」というゴールを明確にしておくことで、この後の項目を決める際の判断基準ができます。
決まった項目を、テンプレートに沿って言語化していく
現状とゴールが整理できたら、業務要件・機能要件・非機能要件・スコープといった項目を、テンプレートに沿って一つずつ言語化していきます。
この段階では、ヒアリングで聞き取った内容をそのまま書き写すのではなく、「なぜその機能が必要なのか」という背景も添えて書いておくと、後から読み返す関係者にも意図が伝わりやすくなります。
項目を埋め終えたら、発注者と一緒に内容を読み合わせ、認識のズレがないかを確認して完成させます。ゼロから項目を組み立てるのが難しい場合は、既存のサンプルやテンプレートを活用する方法もあります。
「IT業界の要件定義書」で、サンプル・テンプレートを使うときに気をつけたいこと
要件定義書のサンプルやテンプレートは、Web上でも複数公開されています。ただし、そのまま使うのではなく、いくつか気をつけたいポイントがあります。
IPAが公開している資料は、項目整理の参考になる
IPA（情報処理推進機構）は、非機能要件を整理するための「非機能要求グレード」など、要件定義に関連する資料を公開してきました。特に非機能要件は、業務要件・機能要件に比べて項目を洗い出しにくいため、こうした公的機関の資料を参考にしながら、自分のプロジェクトに必要な項目を検討すると抜け漏れを減らせます。
テンプレートはそのまま使わず、
プロジェクトの規模に合わせて取捨選択する
サンプルやテンプレートには、大規模なプロジェクトを想定した項目まで幅広く含まれていることがあります。小規模な開発でそのすべてを埋めようとすると、かえって作業が煩雑になり、本来重視すべき項目の検討に時間を割けなくなってしまいます。テンプレートはあくまで項目の抜け漏れを防ぐためのチェックリストとして使い、自分のプロジェクトの規模や関係者の数に応じて、必要な項目を取捨選択することを意識しましょう。
まとめ：要件定義書は、認識のズレを防ぐための共通言語
要件定義書とは、ヒアリングで決まった内容を、発注者と開発者が同じ形で確認できるようにまとめた文書です。業務要件・機能要件・非機能要件を区別し、スコープを明記したうえで、現状整理からゴールの明確化、テンプレートに沿った言語化という手順で書き進めることで、実務で使える要件定義書に仕上げていくことができます。
サンプルやテンプレートは、あくまで参考として活用し、プロジェクトの規模に合わせて内容を調整することも忘れないようにしましょう。
