要件定義の作り方でつまずきやすいのは、いきなり機能一覧を書き始めてしまうことです。発注前の段階では「何を作るか」だけでなく、「なぜ作るのか」「どの業務を変えるのか」「どこまでを初回開発に含めるのか」をそろえないと、見積もりも提案も比較しにくくなります。
要件定義書は、開発会社へ渡すためだけの書類ではありません。社内の利用部門、決裁者、開発会社が同じ前提で話すための合意資料です。この記事では、初めて要件定義書を作る担当者に向けて、要件定義の作り方、作成手順、成果物サンプル、RFPや要求定義との違い、テンプレートを使うときの注意点を整理します。
この記事のポイント
- 要件定義は機能一覧ではなく目的・業務・合意条件を文書にする工程
- 作成手順は要求整理、業務フロー、機能要件、非機能要件、合意条件の順で進める
- 成果物サンプルは目的、用語定義、構成、フロー、要件、互換性、予算まで入れる
- テンプレートは空欄を埋めるだけでなくレビューの抜け漏れ確認に使う
すでに開発会社へ相談する予定がある場合でも、この記事の順に目的と成果物を整理しておくと、初回打ち合わせで確認すべき論点が見えやすくなります。
目次
要件定義の作り方と全体手順
要求と要件を分ける
要件定義の最初の手順は、発注者側の要求と、開発で扱う要件を分けることです。要求は「受注管理を楽にしたい」「問い合わせ対応を減らしたい」「承認漏れをなくしたい」のような、事業や現場の言葉です。要件は、その要求を実現するために必要な機能、画面、データ、運用、品質条件へ落としたものです。
ここを分けずに進めると、要件定義書が要望メモのまま止まります。たとえば「検索しやすくしたい」という要求だけでは、検索対象、検索条件、表示順、権限、検索結果が0件だった場合の表示、データ更新のタイミングが分かりません。要件定義では、この曖昧な要求を、設計や見積もりに使える条件へ変換します。
発注者側が最初にやるべきことは、細かな仕様を決め切ることではありません。まずは現場の要求を集め、似た内容をまとめ、解決したい課題の優先順位を付けることです。そのうえで、開発会社と相談しながら実現方法を要件へ落とし込むと、会話が進めやすくなります。
RFPとの違いを押さえる
要件定義書とRFPは、似ていますが役割が違います。RFPは、開発会社から提案を受けるための資料です。どんな課題があり、どのような提案を受けたいのかを伝え、複数社を比較するために使います。一方、要件定義書は、開発範囲と合意条件を固め、設計・開発・テスト・検収の基準にする資料です。
発注前にRFPを作る場合は、課題、目的、希望スケジュール、予算感、提案してほしい範囲を整理します。ベンダー選定の流れから確認したい場合は、RFPの書き方とサンプルを先に見ると、要件定義書との違いを分けやすくなります。
| 資料 | 主な目的 | 作るタイミング | 主な読み手 |
|---|---|---|---|
| 要求整理メモ | 自社の課題や要望を集める | 企画・発注準備 | 社内関係者 |
| RFP | 開発会社から提案を受ける | ベンダー選定前 | 開発会社・選定担当者 |
| 要件定義書 | 開発範囲と合意条件を固める | 契約前後から設計前 | 発注者・開発会社・利用部門 |
実務では、RFPだけで要件定義が完了するわけではありません。RFPは提案を受けるための入口であり、要件定義書はプロジェクトを動かすための合意資料です。この違いを意識すると、資料の粒度を間違えにくくなります。
作成者と決裁者を決める
要件定義書は、開発会社だけが作るものではありません。業務の現状、優先順位、予算、社内承認の事情は発注者側にしか分からないため、発注者側も作成に深く関わる必要があります。開発会社は、ヒアリング、構造化、技術的な実現方法、抜け漏れの指摘を担う立場です。
現場でよく見る失敗は、発注者側が「プロに任せればよい」と考え、利用部門の声や決裁条件を集めないまま要件定義に入るケースです。この状態だと、開発会社がきれいな資料を作っても、あとから「現場では使えない」「承認者が想定していない」と差し戻されます。
最初に決めるべきことは、細かな仕様ではなく、意思決定者、利用部門の代表、予算を見られる人、運用を担う人を誰にするかです。関係者が多いほど要望は増えるため、最終判断者を決めておくことも重要です。開発全体の流れを把握したい場合は、システム開発の工程と流れもあわせて確認すると、要件定義の位置づけをつかみやすくなります。
成果物から逆算する
要件定義の作り方は、最初に成果物を決めると進めやすくなります。成果物とは、要件定義書そのものだけではなく、プロジェクト概要、用語定義、システム構成、現状フロー、構築後フロー、利用者一覧、機能要件、非機能要件、互換性、スケジュール、予算、検収条件など、後工程で参照される資料のまとまりです。
検索上位の記事でも、テンプレートやサンプル、成果物一覧への関心が強く出ています。これは、読者が「何を書けば要件定義として足りるのか」を知りたいからです。文章をきれいに書くよりも、設計・見積もり・開発・テストで使える情報が入っているかを基準にしましょう。
特に非機能要件は抜けやすい領域です。性能、可用性、運用、保守、移行、セキュリティなどは、発注者側が明確に言語化しないまま進むことがあります。IPAも非機能要求グレードを、ユーザーと開発者の認識違いを防ぐための確認ツールとして公開しています。全項目をそのまま使う必要はありませんが、抜け漏れ確認の観点として参考になります。
要件定義書の作り方と成果物サンプル
目的と現状課題を書く
要件定義書の最初に書くべきことは、プロジェクトの目的です。目的が曖昧なままだと、機能追加の判断がすべて「あると便利」に寄ってしまいます。まずは、現在どの業務にどんな問題があり、システム化によって何を改善したいのかを一文で説明できる状態にします。
サンプルとしては、次のように書くと判断に使いやすくなります。「現行の受注管理はExcelとメールで分散しており、入力漏れと二重登録が発生している。新システムでは、受注情報を一元管理し、営業担当と管理部門が同じステータスを確認できる状態を目指す」。この程度まで具体化されていると、必要な機能や画面の優先順位を決めやすくなります。
目的を書くときは、売上向上、工数削減、ミス削減、問い合わせ削減、リードタイム短縮など、可能な範囲で測れる言葉に置き換えます。数値がまだ出せない場合でも、「何が減れば成功か」「何が増えれば成功か」を決めておくと、あとから効果測定しやすくなります。
業務フローと利用者を整理する
目的が決まったら、現状の業務フローとシステム導入後の業務フローを並べます。ここで大切なのは、理想の流れだけでなく、現場で実際に起きている例外処理も書くことです。承認者が不在のとき、入力ミスがあったとき、取引先からキャンセルが来たときなど、例外が多い業務ほど要件漏れが起きやすくなります。
利用者も、単に「管理者」「一般ユーザー」と書くだけでは足りません。営業担当、経理担当、承認者、外部パートナー、システム管理者のように、役割ごとに見られる情報、できる操作、責任範囲を分けます。権限設計は後回しに見えますが、画面数やテスト範囲、運用負荷に直結します。
画面や操作の認識がずれそうな場合は、要件定義書の前に簡単な画面ラフやプロトタイプを作る方法もあります。文章だけで判断しにくいプロジェクトでは、プロトタイプの作り方を使って主要な画面遷移を確認してから要件へ落とし込むと、手戻りを減らしやすくなります。
機能要件と非機能要件を分ける
機能要件は、システムが利用者に提供する具体的な機能です。ログイン、検索、一覧表示、登録、編集、承認、CSV出力、通知などが該当します。機能名だけでなく、入力項目、表示条件、権限、エラー時の動き、外部連携の有無まで書けると、見積もりの精度が上がります。
非機能要件は、機能そのものではないものの、システムの使いやすさや安全性に関わる条件です。たとえば、画面表示の速度、同時利用者数、バックアップ、監視、障害時の復旧目標、セキュリティ、ログ保存、保守体制などです。非機能要件を曖昧にすると、リリース後に「遅い」「止まる」「運用できない」といった問題になりやすくなります。
テンプレートでは、機能要件をプロセスとインターフェイスに分けて書くと整理しやすくなります。プロセスは業務の流れや処理の順番、インターフェイスは画面、外部連携、CSV入出力、通知などの接点です。既存システムがある場合は、互換性を維持するのか、既存仕様に合わせないのかも同じタイミングで確認します。
| 分類 | 書く内容 | サンプル |
|---|---|---|
| 機能要件：プロセス | 業務の流れと処理順 | 受注登録後、承認者が確認し、確定後に管理部門へ通知する |
| 機能要件：インターフェイス | 画面・外部連携・入出力 | 一覧、詳細、登録画面を用意し、CSV出力に対応する |
| データ要件 | 扱う項目と保存先 | 顧客名、商品、数量、金額、ステータスを保存する |
| 非機能要件 | 性能・運用・安全性 | 営業時間中は利用でき、日次でバックアップする |
| 互換性 | 既存システムとの関係 | 既存の顧客マスタ形式は維持し、旧画面仕様は引き継がない |
最初から完璧に書く必要はありません。重要なのは、決まっていること、未確定のこと、開発会社に相談したいことを分けることです。未確定のままでも、論点として見える状態にしておけば、打ち合わせで潰していけます。
スケジュールと予算を置く
要件定義書には、スケジュールと予算も入れます。まだ正式見積もり前であっても、希望納期、社内承認の期限、リリースしたい時期、使える予算帯を共有しておくと、開発会社は現実的な提案を出しやすくなります。
よくある失敗は、機能の話だけを詰めて、社内レビューや受け入れテストの期間を置いていないケースです。要件定義、設計、開発、テスト、データ移行、操作説明、初期運用までをざっくり並べ、発注者側が確認する日程も入れておきましょう。発注者側の確認が遅れると、開発会社の作業待ちではなくても全体スケジュールがずれます。
予算についても、上限をまったく示さないと、提案の粒度がばらつきます。厳密な金額を出せない場合は、「初期開発では最低限の業務範囲に絞る」「将来的な追加機能は別フェーズにする」など、優先順位の方針だけでも共有しましょう。
成果物サンプルの項目
要件定義書の成果物サンプルは、次の構成をベースにすると使いやすくなります。Word形式のテンプレートを使う場合も、項目を埋めるだけではなく、関係者レビューで何を確認するかを意識してください。
| 章 | 記載すること | レビュー観点 |
|---|---|---|
| プロジェクト概要と目的 | 現在の課題、理想の状態、対象業務、成功条件 | 何のために作るかを全員が説明できるか |
| 用語定義 | 社内用語、業務用語、システム名、略語の意味 | 発注者と開発会社で同じ言葉を同じ意味で使えているか |
| システムの構成要素 | 既存システム、新規システム、外部連携、利用するデータ | 影響範囲や連携先が漏れていないか |
| 現状フローと構築後フロー | 現在の作業手順、導入後の作業手順、例外処理 | 現場の実態と導入後の運用がつながっているか |
| システム利用者の一覧 | 利用部門、承認者、管理者、外部パートナー、権限 | 誰が使い、誰が判断するかが明確か |
| 機能要件・非機能要件 | プロセス、インターフェイス、画面、データ、性能、運用、セキュリティ | 初回リリースに必要な範囲へ絞れているか |
| 互換性 | 既存システムとの互換性を維持するか、引き継がないか | 既存仕様を残す範囲と変える範囲が決まっているか |
| スケジュールと予算 | 要件確認、開発、テスト、調整、デプロイ、予算上限 | 社内確認日と予算制約が見積もりに反映されているか |
この構成で作ると、単なる説明資料ではなく、見積もり、設計、テスト、検収に使える資料になります。特に検収条件は重要です。「画面ができたら完了」ではなく、「どの業務が、どの条件で、誰に承認されれば完了か」を決めておくと、納品時の認識違いを減らせます。
レビューで完了条件を決める
要件定義書は、作成して終わりではありません。関係者レビューを行い、未決事項、保留事項、次工程への申し送りを整理してから設計へ進みます。レビューでは、読みやすさよりも「この内容で見積もれるか」「この内容で設計に進めるか」「この内容で検収できるか」を確認します。
レビュー参加者は、決裁者、利用部門、運用担当、開発会社の担当者を含めるのが基本です。人数を増やしすぎると議論が広がるため、意見を出す人と最終判断する人を分けておくと進めやすくなります。
完了条件のサンプルとしては、「主要業務フローの関係者確認が完了している」「初回リリースに含める機能と後回しにする機能が分かれている」「非機能要件の未決事項が一覧化されている」「見積もりに含まれる範囲と含まれない範囲を確認した」などがあります。ここまで確認できれば、次の設計や見積もりに進む判断がしやすくなります。
