システム開発（ソフトウェア開発）の上流工程でおこなう「要件定義」。
この工程では、発注者の抱える業務課題について開発者が現状を正しく把握し、課題や問題点をもれなく抽出できていなければなりません。
では、具体的にどのような要件定義書を作れば、要件定義を成功させることができるのでしょうか？

本記事では、要件定義をスムーズに進めるためのコツから、「良い要件定義書」を書くための重要ポイントまで徹底解説いたします。

要件定義書・要件仕様書とは？関連ドキュメントの違い

システム開発やDXプロジェクトでは、「要件定義書」「要件仕様書」「要求定義書」「要求仕様書」など、似た名称のドキュメントが数多く登場します。しかし、これらは作成目的や視点、関与する関係者が異なり、同じ意味で扱ってしまうとプロジェクト内で認識のずれが生じやすくなります。

本章では、それぞれの役割を工程視点で整理し、要件定義書がどの位置づけにある資料なのかを明確にします。

要件定義とは何か

要件定義とは、業務上の課題や目的を踏まえ、「システムで何を実現するのか」「どこまでを対象範囲とするのか」を明確にする工程を指します。単に機能を列挙する作業ではなく、業務要件・機能要件・非機能要件を整理し、関係者の合意を形成するプロセスとして捉えることが重要です。

要件定義の段階では、業務担当者・IT部門・ベンダーなど複数の立場が関わるため、専門用語に偏らず共通理解を得られる表現が求められます。また、この工程で整理された内容が後続の設計や開発の前提条件となるため、目的や背景を含めた整理が欠かせません。

要件定義書と要件仕様書の違い

要件定義書と要件仕様書は名称が似ているため混同されがちですが、目的や利用される工程、読み手の視点が異なります。

要件定義書は、業務課題やシステム化の目的、対象範囲を整理し、関係者全体の共通理解をつくるための資料です。一方、要件仕様書は、設計や開発に向けて機能や条件をより具体的に整理するドキュメントとして扱われることが多く、技術的な観点が強くなります。

プロジェクトを円滑に進めるためには、両者の役割を分けて理解しておくことが重要です。

観点	要件定義書	要件仕様書
目的	プロジェクト全体の方向性・合意形成	設計・開発に向けた具体化
視点	業務・企画寄り	技術・実装寄り
主な読み手	業務部門・IT部門・意思決定者	開発者・設計担当者
内容の粒度	概念整理・方針レベル	詳細条件・仕様レベル
作成タイミング	要件定義工程	設計前後または並行

このように、要件定義書は「何を実現するか」を共有する資料であり、要件仕様書は「どのように実現するか」に近づくための整理といえます。実務では両者が一体化している場合もありますが、役割の違いを意識して使い分けることで、関係者間の認識齟齬を防ぎやすくなります。

要求定義書・要求仕様書との違い

要求定義書や要求仕様書は、ユーザー側や業務部門の視点で「実現したいこと」や「期待する成果」を整理した資料として扱われるケースが多くあります。システム要件として具体化する前段階で作成されることもあり、現場の課題やニーズを言語化する役割を担います。

名称は似ていますが、要件定義書とは整理の粒度や立場が異なる点に注意が必要です。

観点	要求定義書・要求仕様書	要件定義書
視点	ユーザー・業務側	システム化を前提とした整理
主な目的	実現したいことの整理	実装可能な要件への落とし込み
内容	課題・期待・要望中心	業務要件・機能要件・非機能要件
作成主体	業務部門・発注側	IT部門・ベンダー・PM
工程	企画・構想段階	要件定義工程

要求定義書や要求仕様書は、あくまで「要求」をまとめた資料であり、その内容をもとにシステム視点で整理し直したものが要件定義書と考えると理解しやすくなります。企業やプロジェクトによって用語の使い方は異なるため、名称だけで判断せず、誰がどの目的で作成した資料なのかを確認することが大切です。

案件定義書との関係

案件定義書という呼び方が使われることもありますが、一般的な開発プロセスで正式な工程名称として定義されているわけではありません。プロジェクトの背景やスコープ、予算感などを整理する初期資料として扱われるケースが多く、要件定義に進む前の検討段階で作成されることがあります。 要件定義書との違いは、システム要件そのものよりも「案件として成立するか」「どのような方向性で進めるか」といった検討内容が中心になる点です。実務では、案件定義書で方向性を固めた後に要件定義書へと落とし込む流れを取ることもあり、両者は連続したプロセスの中で整理される資料といえるでしょう。

プロジェクトの要である要件定義とは

要件定義書の作成の進め方

要件定義書は、思いついた内容を書き並べるだけでは実務で使える成果物にはなりません。現状の業務やシステムの前提を整理し、課題や要求を段階的に具体化しながら、関係者の合意を形成していくプロセスとして捉えることが重要です。

本章では、要件定義書を作成する際の基本的な流れを、実務での進め方に沿って整理します。

現状業務とシステムの整理

要件定義の初期段階では、現行の業務構造やシステム環境を俯瞰的に整理し、「どの前提で要件を検討するのか」を明確にします。

既存フローを理解すること自体が目的ではなく、業務の役割分担やデータの流れ、システム間の関係性を整理し、後続の要件検討の土台をつくることが重要です。

整理の観点	確認する内容	要件定義へのつながり
業務構造	部門ごとの役割や責任範囲	対象範囲や業務要件の明確化
データの流れ	入力元・更新タイミング・参照先	機能要件や連携条件の整理
システム構成	利用中のツールや連携関係	置き換え・統合判断の材料
運用ルール	承認フローや例外対応	非機能要件や運用設計の基礎

整理を通じて、要件定義の前提条件を関係者間で共有できるようになります。業務ヒアリングや既存資料の確認をしながら、構造的な視点で情報を整理しておくことが、後工程の手戻りを防ぐポイントです。

課題・要求の深掘りと優先順位づけ

現状を整理した後は、関係者から挙がった課題や要求を具体的に掘り下げ、優先度を整理していきます。単なる要望の羅列ではなく、業務への影響度や実現可能性を踏まえた判断が求められます。

• 業務上のボトルネックや非効率な作業を洗い出す
• 部署ごとの目的や期待値を明確にする
• 現行システムで実現できていない理由を確認する
• 短期対応と中長期施策を切り分ける
• コストや影響範囲を踏まえて優先順位を決める

要求の背景を理解せずに優先順位を決めてしまうと、本来解決すべき課題から外れてしまう可能性があります。関係者との対話を重ねながら整理することで、実務に即した要件につながるでしょう。

要件の分類と文書化の手順

整理された要求は、業務要件・機能要件・非機能要件といった形で分類し、要件定義書として構造化していきましょう。表現の美しさよりも、要件の粒度や関係性をそろえることが重要です。

• 要求内容を業務要件・機能要件・非機能要件に振り分ける
• 抽象的な表現を避け、条件や判断基準を明確にする
• 重複や矛盾がないかを確認する
• 用語や表現をプロジェクト内で統一する
• 管理番号や変更履歴をつけ、追跡可能にする

要件の分類を意識して文書化することで、設計工程へ引き渡した際の解釈のずれを防ぎやすくなります。要件定義書は単なる記録ではなく、後工程の基準となるドキュメントとして整理していくことが大切です。

関係者との合意形成

要件定義書は作成して終わりではなく、関係者間で認識をそろえて初めて有効な成果物になります。業務部門、IT部門、開発担当者など、それぞれの立場によって重視する観点が異なるため、レビューやディスカッションを通じて意図を共有することが重要です。 合意形成では、細かな仕様の是非だけでなく、「対象範囲は適切か」「優先順位に納得できているか」といった視点を確認します。最終的に承認プロセスを経て確定させることで、後工程の判断基準として活用できる状態になるのです。

要件定義をスムーズに進める３つのコツ

「要件定義は難易度が高い」と言われる理由として、成果物となる「要件定義書」に書くべき内容がはっきりと定義されておらず、プロジェクトによって差異がある、というのがあります。（「要件定義書」については後項で解説します。）

QualityCubeではこれまでのご支援経験から、以下の３つを「要件定義をスムーズに進めるためのコツ」と考えました。

• 既存の業務フローとシステムについて知る
• 要求定義書と要件定義書のすり合わせをする
• 開発担当者を明確にしておく

既存の業務フローとシステムについて知る

発注者の要望は実に様々ですが、システムや業務フローに課題があり、直面している問題を解決したいという要求は少なくありません。
したがって要件定義段階でまず必要になるのは、現在用いられているフローや既に使われているシステムを正しく理解することです。そのうえでどこに課題があり、どのように解決するべきかを明確にします。
なかには、現行システムの設計書通りに業務を行っていないケースもあるので特に注意が必要です。

要求定義書と要件定義書のすり合わせをする

システム開発において、発注者が作成するドキュメント書類を「要求定義書」、この発注者の要求をもとに開発者が作成する書類を「要件定義書」と呼びます。
要求定義書では、発注者が解決したいと考えている課題や、導入したいシステムについての要求をまとめるのに対して、要件定義書では開発者の視点で要件や作業工程を決めていきます。
発注者の描いた夢をもとに、開発者が理想となるシステムの姿を整理していくのです。

しかしながら、プロジェクトによっては発注者が要求定義書を作成していないケースもあり、その場合、発注者に対して開発者がヒアリングを行うことで要求を把握する必要があるので、注意が必要です。

こうして要件定義書が完成したら、漏れがないか発注者と開発担当者とで認識合わせをすることが重要です。
一般的なウォーターフォール型開発では、手戻りが重大なタイムロスになりますから、要件定義の段階でしっかりと作り込みを行うことで手戻りを防いでいきます。

開発担当者を明確にしておく

プロジェクトの開発担当者を明確に決めておくことも重要です。
他のプロジェクトと兼務の開発者は、当プロジェクトにどのくらいの工数を割けるか、明確にしておきます。曖昧なままにしておくと、後々コミュニケーションのすれ違いが増えていく可能性があります。ムダな調整が増えると、本来するべき業務の進行に支障が出る可能性があります。
したがってこの段階で役割分担を明確にしておき、開発担当者が不明確なままの業務をなくします。
開発固定のタスクに関して開発担当者と責任分担が適切に決まっていれば、不要な業務で工数を圧迫する恐れもなくなります。
そのためには、WBS（Work Breakdown Structure：作業分解構成図）を作成し、誰がいつまでに、何を完成させるかを明確にしましょう。

上記の３つをしっかりと守れているかどうかが、要件定義の成否を分けると言っても過言ではありません。
貴社の要件定義はどうでしょうか？照らし合わせてみてください。

要件定義の成果物：「要件定義書」

ここでは、前項で触れた「要件定義書」について解説していきます。
冒頭でご紹介した別エントリでも述べていますが、改めて「要件定義書」とは、要件定義において成果物とされるドキュメント書類の名称です。
前項で「書くべき内容がはっきりと定義されておらず、プロジェクトによって差異がある」ことが難しいと言われる理由と述べましたが、QualityCubeが「要件定義書に書くことが望ましい項目（中身）」として挙げているのは、主に以下の通りです。

要件定義の成果物	成果物の中身	概要
要件定義書	システム概要	どのようなシステムを開発するか？
	全体図	ソフトウェア・ハードウェアで構成させる全体の構成図
	業務要件	要求一覧、As-Is（現状）To-Be（新規）業務フロー/業務一覧
	システム要件・納品対象	システム化対象を明文化した文書、納品書一覧など
	機能要件	画面・帳票・バッチ・データ・外部インターフェース要件など
	非機能要件	可用性、性能・拡張性、運用・保守性、移行性、セキュリティなど
	総合・受け入れテスト設計図	テスト計画書・仕様書・設計書など
	WBS	システム開発プロジェクトの開発工程構成図

要件定義書に記載すべき必須項目

またその中でも、とりわけ必ず記載すべき「必須項目」と言えるものは次の4項目です。

• システム概要：目的や目標を決める
• 業務要件：業務フローを作成する
• 機能要件：必要となる機能を決める
• 非機能要件：システムの裏側を決める

システム概要：目的や目標を決める

システム概要には、「システム開発に至った背景」や「システム開発の目的と目標」の記載が必須です。
目的は、「システム開発によってどのような効果や結果を求めるか」という内容。
目標は、それが「どのような結果になったとき達成されたといえるか」を定義する指標です。
定量的なゴールを定めておくことで、発注者とシステム開発者、また関係者全員の認識に齟齬が発生しないようにしておくことが大事です。

業務要件：業務フローを作成する

システム開発の目的と目標を達成するには、実際の業務はどうあるべきかを考えます。
業務の流れを文書で書くと非常に分かりづらいため、ここでは「業務フロー」を作るのがよいでしょう。
まずは「現状の業務フロー（As-Is）」を作成してから、「システム稼働後の業務フロー（To-Be）」を作れば、システム稼働前・稼働後のフローが明確になります。

機能要件：必要な機能を決める

業務要件で決めた「何をどのように使うのか」ということに対して、「システムがどのような情報を管理したり処理したりすればよいか」を規定するのが機能要件です。
機能要件でありがちな失敗として、「開発者だけで決める方式をとってしまうこと」が挙げられます。
忘れてはいけないのが、発注者の要求こそが開発の大前提であるという点です。
システム課題はもちろん重要ですが、それだけを優先するのではなく、「発注者が実際にどう使うのか」を確認しながら、使いやすさ、必要な機能が備わっているか、を十分検討してください。

非機能要件：システムの裏側を決める

機能要件が「発注者の目に触れる機能」であるのに対し、非機能要件はシステムの品質や性能という「システムの裏側を決めること」です。
どのシステム開発でも、非機能要件で検討すべき内容は同じである場合が多いです。
ここはすでにあるフォーマットを使うことで、資料作成や事項の抽出にかかるコストを削減しましょう。

では、この必須項目のうち「業務要件」「機能要件」「非機能要件」の具体的な洗い出し方法について、さらに詳しく見ていきましょう。

業務要件

業務要件は、要件定義の初期に分析します。
システム化に先立ち、現状の業務がどのように流れているかを分析し問題を抽出した上で、新たに何を実現すべきかを決めていきます。この段階ではシステムはあまり意識せず、あくまで「業務そのもの」に焦点を当てます。
業務要件では、業務に詳しい発注側の関係者に参加してもらい、高いコミュニケーションを図ることが必要です。ここで発注者と開発者間で目的が噛み合わないままスタートしてしまうと、大幅な手戻りが発生して時間とコストの浪費につながるため、丁寧なヒアリングを行うことが肝となります。

業務フローの作成には、弊社がお役立ち資料として無料公開している「業務フローの書き方ガイド」を、ぜひ参考にしてください。

機能要件

システム要件でシステム化の方向性が決まると、システムに必要な機能について検討します。
機能要件とは、システム開発を通して最低限実現すべき機能のことを指し、発注者へのヒアリングを実施することで具体的に固めていきます。
機能要件で洗い出した成果物は、後述の非機能要件と合わせて、次工程の基本設計フェーズでの重要なインプットとなります。
機能要件の主な内容としては以下の5つがあります。（ちなみにこれは、基本設計の際に必要な情報となってきます。）

①画面要件

・画面一覧：開発時の画面を一覧化したもの

出典：IPA機能要件の合意形成ガイド画面編　P17 　

・画面遷移図：画面の流れをあらわしたもの
・画面レイアウト：画面のイメージを共有するためのもの

出典：IPA　工程成果物間の関連　P15

②帳票

・帳票一覧：開発する帳票を一覧化したもの

出典：IPA　工程成果物間の関連　P15 　

・帳票概要：帳票の出力場所や、業務上の用途を記したもの

出典：IPA　工程成果物間の関連P15

・帳票レイアウト：帳票の具体的なイメージを明確にするもの

出典：IPA　工程成果物間の関連　P15 　

③バッチ

・バッチ処理一覧：プロジェクトで開発するバッチ機能を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

④データ

・外部システム関連図：関連システムとのデータ連携を図解したもの
　（システム開発の対象となる部分を色分けし、どのシステムに影響を及ぼす可能性があるのか整理する）

出典：IPA　工程成果物間の関連　P15 　

⑤外部インターフェース要件

・外部インターフェース一覧：関連システムとのデータ連携を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

外部インターフェース定義書：関連システムとのデータのやりとりについて、主要なデータ項目を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

---

非機能要件

機能要件が発注者にとって必須の機能であることに対して、非機能要件は、機能以外に「あればいいな」と考える要件です。一見必要ではないように見えますが、非機能要件を実現していくことで、発注者の満足を上げることができます。システム画面の切り替え速度などは、よくある例です。

非機能要件の決定は、予算や納期を意識しつつ、発注者と合意を図ることが重要となってきます。発注者の要望を文字通りに捉えるのではなく、ヒアリングによって「なぜそれを要求するのか？」までを引き出すことで、潜在的な要求に気づくことができ、より質の高い成果物のアウトプットにつながります。
IPAの非機能要求グレードに示された６つの特性をもとに、運用方法を検討しましょう。

出典：IPA　非機能要求グレードご紹介　P6

要件定義書作成の際のポイント

要件定義書は、項目を網羅するだけでは実務で活用できる資料にはなりません。読み手の立場を意識した構成や表現、要件の具体性、変更を前提とした管理方法までを考慮することで、プロジェクトの共通認識として機能するドキュメントになります。

本章では、既存の成果物項目と重複しない視点から、要件定義書を実務で使い続けるためのポイントを整理します。

読み手に伝わる構成にする

要件定義書は、業務担当者・開発者・意思決定者など、異なる立場の関係者が参照する資料です。そのため、専門用語を減らすことだけが目的ではなく、「どの順番で情報を提示すれば判断しやすいか」という構成設計が重要になります。

例えば、背景や目的を冒頭で整理した上で対象範囲を明示し、その後に要件の詳細を記載することで、読み手は文脈を理解しながら内容を把握できます。また、章立てや見出しの粒度をそろえることで、レビュー時に確認すべきポイントが明確になります。単なる説明資料ではなく、意思決定を支援するドキュメントとして構成を設計する視点が求められます。

機能要件の具体的な書き方

機能要件を記載する際は、「何ができるか」だけでなく、「どの条件で、誰が、どのように利用するのか」を明確にすることが重要です。既存の機能要件項目では内容の種類を整理しますが、記載方法の観点に焦点を当てましょう。

抽象的な表現のまま記載してしまうと、設計段階で解釈が分かれる原因になります。操作主体、入力条件、処理内容、出力結果といった視点で文章を構造化することで、開発担当者が具体的なイメージを持ちやすくなります。

また、例外処理や制約条件をあらかじめ記載しておくことで、後工程での仕様変更を減らす効果も期待できます。

非機能要件を明確にする視点

非機能要件は、性能・可用性・セキュリティなどシステム全体の品質に関わる要素であり、機能要件と比べて抽象的になりやすい領域です。

要件定義書では、単に「高性能」「安全」といった表現にとどめず、評価基準や前提条件を整理しておくことが重要になります。

観点	記載時のポイント	具体化の例
性能	測定条件や想定利用量を明確にする	同時接続数、レスポンス時間
可用性	障害発生時の許容範囲を定義する	稼働率、復旧時間目標
セキュリティ	管理対象やアクセス条件を整理する	認証方式、ログ管理
運用性	運用担当者の作業負荷を考慮する	監視方法、バックアップ方針

非機能要件は後回しにされがちですが、あいまいなまま進めると運用開始後のトラブルにつながることもあるでしょう。関係者と合意できる指標を意識しながら、測定可能な形で整理しておくことが重要です。

変更管理と合意形成の仕組み

要件定義書は一度作成したら固定されるものではなく、プロジェクトの進行に応じて変更が発生することを前提に管理する必要があります。変更履歴や版管理を明確にし、誰がどの判断で更新したのかを追跡できる状態にしておくことで、後から認識の食い違いが起きるリスクを減らせます。 また、変更内容を関係者へ共有する仕組みを整えておくことも重要です。レビューのタイミングや承認フローをあらかじめ決めておくことで、変更が属人的に進むことを防ぎ、プロジェクト全体としての合意形成を維持しやすくなります。

良い要件定義書の必須条件

ここまで、要件定義書に記載すべき項目について具体的に見てきました。
最後に、「良い要件定義書」とはどういうものを指すのか？要件定義を行うにあたって、QualityCubeが考える大事な条件は以下の2つです。
作成した要件定義書が以下の条件に当てはまるかどうか、ぜひ照らし合わせてください。

条件①専門知識がなくても内容が分かる

発注者はIT分野の専門知識に乏しいケースがほとんどです。
そのため、実際にシステムを利用する発注者が理解できる文章で記載されていることは非常に重要です。
書面では、IT分野に関する専門用語や専門知識を極力使わないことを心がけましょう。いくら素晴らしい内容であっても、書面の内容を理解してもらえないことには発注者側で仕上がりがイメージできず、かえって不信感を招いてしまうこともあります。
発注者のみならず、発注者の関係者が読んでも分かりやすい文章になっているか？までを意識するようにしましょう。

条件②課題に対する解決策になっている

要件定義の最終目的は、発注者からの要求をまとめるだけではありません。
発注者が何を求めているかを見定めるのはもちろんのこと、その要求をどのようにして叶えるのかという「答え」＝「課題解決策」にあたる文章を記載し、発注者に理解してもらうことが重要です。
発注者の課題を解決できていない開発は成功とはいえません。
検収時のクレームやムダなコスト増を防ぐため、この「答え」を提案することこそが求められます。

まとめ

本記事では、要件定義をスムーズに進めるための手法や、要件定義書を作成する上でのポイントをご紹介しました。まとめると以下の通りです。

要件定義をスムーズに進めるには？
発注者からヒアリングした内容をもとに、業務フロー・システムフローを把握した上で、必要な機能や非機能をわかりやすくまとめ、発注者・開発者間で認識に齟齬がないかしっかりすり合わせをしましょう。

要件定義書を作成する上でのポイントは？
発注者の要求をもとに「システム開発に至った背景」や「システム開発の目的と目標」を明確化し、そこから業務要件、機能要件、非機能要件を洗い出していきます。
要件定義書を作成する際には、実際にシステムを利用する発注者や発注者の関係者が理解しやすい文章で書くこと、発注者の要求を満たし、課題を解決するための要件定義であることを忘れないようにしましょう。

ご質問・ご要望

要件定義をうまく進め、良い要件定義書を作成するためにおさえておくべき事項は多岐にわたります。
弊社、株式会社QualityCubeでは、要件定義のスペシャリストとして「要件定義代行サービス」を提供しています。

多くの企業様をご支援してきたプロのコンサルタントが、顧客の課題に沿ったヒアリング・調査から要件定義書の作成を代行させていただくことで、QCDバランスを見ながら、プロジェクトの要である要件定義を解決に導きます。ぜひお気軽にお問い合わせください。

より詳細な情報や、貴社の状況に合わせた具体的な提案が必要な場合は、お気軽にご相談ください。例えば、以下のような課題からお問い合わせを頂くケースが多くなってきております。

• 要件定義のできる経験者のリソースが不足している
• 要件定義がうまくいっていないと感じている
• 要件定義の担当者が少ないため、プロジェクト受注を断念するケースがある
• 要件定義工程の外注を検討している