要件定義とは？意味・進め方7ステップと具体例・成果物【IPA／JUAS 一次ソース準拠｜2026年版】

要件定義とは、システム開発で「何を・なぜ作るか」を関係者全員で合意し、要件定義書という成果物に落とし込む上流工程です。 機能要件・非機能要件・スコープ・変更管理ルールをここで決め切れないと、開発フェーズ以降の手戻りで費用とスケジュールが膨らみます。実際にJUAS（日本情報システム・ユーザー協会）のソフトウェア・メトリクス調査2025では、納期遵守率が87.5%、20%以上の大幅遅延が7.4%報告されており、その多くは要件定義段階の合意不足が起点と分析されています。

本記事は 要件定義クラスタの主記事 として、意味・進め方7ステップ・要求定義との違い・基本設計との違い・成果物一覧・IPA非機能要求グレードまでを、SaaS開発や社内システム刷新で「すぐ現場に持ち込める形」で整理しました。

• 要件定義の意味と、要求定義／基本設計との違い
• 現場で使える7ステップの進め方と具体的な要件定義の例
• 機能要件・非機能要件の切り分けとIPA非機能要求グレード6大項目
• 要件定義書に含めるべき成果物と変更管理シートのサンプル

クラスタ内の他記事との棲み分け ：本記事は「要件定義の定義・進め方・成果物の全体像」が起点です。要件定義書のフォーマット・記入例は要件定義書サンプル完全ガイド、AIを活用した効率化は要件定義にAIを活用する方法、アジャイル開発での扱いはアジャイル開発の要件定義は不要？仕様書との違い・進め方5ステップを併読してください。

要件定義とは？意味と上流工程での位置づけ

要件定義とは、システムで実現したいビジネス上の目的と、それを満たすために必要な機能・性能・制約を 関係者間で合意し、要件定義書という形式で文書化する工程 です。経済産業省の共通フレーム2013やIPA「ITプロジェクトの『見える化』上流工程編」でも、上流工程の品質がプロジェクト全体の成否を決定づけると整理されています。

要求と要件の正確な切り分け

「要求」と「要件」を混同するとスコープが肥大化し、コスト超過の起点になります。両者の関係は次の通りです。

用語	主な担い手	内容	例
要求（Requirement）	経営層・業務部門・顧客	やりたいこと・解決したい課題（Why／What寄り）	「日々の売上推移を瞬時に把握したい」
要件（Specification）	PM／PMO／開発側	要求を実現する具体的な実装条件（What／How手前）	「既存BIツールとデータ連携し、ダッシュボードへのリンクを設置する」

要求をそのまま要件として鵜呑みにすると、「グラフ機能の新規開発」のように過剰実装になりがちです。要求の背後にある目的を深掘りし、最小コストで満たせる要件へ翻訳するのが要件定義の核心です。

要件定義と基本設計の違い

要件定義（Why／What）と基本設計（How）は責任範囲が異なります。

工程	主目的	主な成果物	主な意思決定者
要件定義	何を・なぜ作るかを合意する	要件定義書、業務フロー、機能一覧、非機能要件一覧	経営層／業務部門／PM
基本設計	要件をどう実現するかを決める	システム構成図、画面設計書、データベース論理設計、外部設計書	アーキテクト／PM
詳細設計	内部構造を細部まで具体化する	プログラム設計書、内部設計書、テーブル定義	開発リーダー

要件定義は「What／Why」、基本設計は「How」までを扱う、というのが現場での目安です。「Whyが決まっていないままHowに進む」状態をなくすことが、要件定義の最大の役割です。

要件定義の進め方7ステップ｜SaaS開発と社内システム刷新の現場で使える形

ここからは、SaaS開発や社内システム刷新のプロジェクトでそのまま使える「要件定義の進め方7ステップ」を解説します。共通フレーム2013やBIPROGYの要件定義解説など主要プレイヤーが共通して挙げる工程を、現場担当者の視点で再構成しています。

ステップ	主なアウトプット	主な担当
1. 目的とスコープの明確化	プロジェクト憲章、Must／Want一覧	経営層・PM
2. 要求と要件の切り分け	要求一覧、要件一覧	PM・業務部門
3. 業務フローの可視化と実装範囲の判断	As-Is／To-Be業務フロー、スコープ表	PM・業務部門
4. 機能要件と非機能要件の定義	機能一覧、非機能要件一覧（IPAグレード）	PM・アーキテクト
5. 仕様変更への対応と管理ルール	変更管理シート、承認フロー	PM・PMO
6. チームの認識を揃えるコラボレーション	要件定義書、画面モック、議事録	全員
7. 運用保守を見据えたルール策定	SLA、運用フロー、教育計画	PM・運用責任者

ステップ1：目的とスコープの明確化

最初のステップは、プロジェクトの「目的とスコープ（範囲）の明確化」です。SaaSの新規立ち上げや社内システム刷新で、初期段階の精度がプロジェクト全体の成否を大きく左右します。

そもそも要件定義とは、「何を実現するのか」を明確にし、関係者全員で合意形成を図る工程です。目的が曖昧なまま進むと、仕様変更が頻発し、コスト増とスケジュール遅延を招きます。

判断の基準として、ビジネス課題の解決に「必須の機能（Must）」と「後回しにできる機能（Want）」を厳密に切り分けます。特にSaaS開発では、初期リリースで最小限の価値を提供するMVP（Minimum Viable Product）の発想が不可欠で、スコープを最小限に絞り込む決断が求められます。

現場で運用する際の注意点

要件定義をスムーズに進めるうえで最も注意すべきは、ステークホルダー間の「認識のズレ」です。開発担当者、経営層、現場のビジネス部門ではシステムに対する期待値が異なります。

例えばSaaSの機能要件をヒアリングする際、新規顧客の獲得を優先する営業部門と、既存顧客の定着を担うカスタマーサクセス部門で求める要件が対立することは珍しくありません。ビジネス部門ごとのミッションの違いを把握し、優先順位を擦り合わせることが不可欠です。各部門の役割整理はカスタマーサクセスと営業の違いとは？役割や目標設定など8つのポイントで完全解説も参考にしてください。

要点を整理すると次の3点に集約されます。

• 目的の言語化 ：システムを通じて解決したい課題を明確にする
• スコープの確定 ：実装する機能の優先順位をつけ、開発範囲を限定する
• 合意形成 ：開発側とビジネス側のステークホルダー全員で認識を統一する

ステップ2：要求と要件の正確な切り分け

事業部門からの「要求」と、システムとして実装する「要件」を明確に切り分けます。すべての要求を実装しようとすると、開発費用が膨張し、スケジュールが遅延します。

要件として採用するかどうかの判断ポイントは、その機能がビジネス課題の根本解決に直結しているかどうかです。要求（Want）を要件（Must）に変換する際の具体的な要件定義の例を挙げます。

• 要求の例 ：「管理画面に多機能なグラフを表示したい」
  • 背景にある真の目的 ：「日々の売上推移を瞬時に把握したい」
  • 要件定義の例 ：「既存のBIツールとデータ連携し、ダッシュボードへのリンクを設置する」

本当に必要なのは「グラフ機能の新規開発」そのものではないケースが多くあります。要求の背景にある真の目的を深掘りし、システム化の範囲を適切に絞り込むことが要件定義の核心です。

企画段階から精度を高める

要件定義の精度をさらに高めるためには、前段の事業企画の段階で、解決すべき課題やターゲットが論理的に整理されていることが不可欠です。企画段階での要求整理に課題がある場合は、【実例あり】新規事業の企画書の作り方とプレゼン資料例｜決裁を通す立ち上げプロセス7ステップを参考に、事業の目的とシステム化の方向性を事前に擦り合わせておくと、要件定義フェーズでの手戻りを最小限に防げます。

ステップ3：業務フローの可視化と実装範囲の判断

3つ目のステップは、業務フローの可視化と実装範囲（スコープ）の明確化です。現場の要望をすべて詰め込もうとすると、開発期間の長期化や費用の増大を招きます。

As-IsとTo-Beの業務フロー可視化

まず、現在の業務フロー（As-Is）と、システム導入後の理想の業務フロー（To-Be）を整理することが基本です。

• As-Is（現状）の例 ：営業担当者がスプレッドシートに顧客情報を入力し、月末に経理担当者が手作業で請求書を発行している
• To-Be（理想）の例 ：SaaS上で顧客データが一元管理され、月末に設定された条件で請求書が自動発行される

この過程で、属人化している工程や、不要な二度手間などのボトルネックが浮き彫りになります。

実装範囲（スコープ）の判断基準

判断の基準は費用対効果と業務の頻度です。月に1回しか発生しない例外的な処理のために複雑な機能を開発するよりも、その部分は手作業（運用）でカバーする方が、全体の開発コストを大幅に抑えられます。

現場担当者は「今の業務のやり方を変えたくない」という心理が働きやすく、既存の非効率な手順をそのままシステム化するよう求めてくるケースが少なくありません。「なぜその機能が必要なのか」を深掘りし、根本的な目的を共有することが求められます。

要点は「やらないことを決める勇気」です。限られた予算と期間で最大の価値を提供するためには、必要最小限の機能に絞り込み、優先順位の高いものから段階的にリリースするアプローチが有効です。

ステップ4：機能要件と非機能要件の定義

4つ目のステップは、システムに求める要件を「機能要件」と「非機能要件」に明確に分類し、判断基準を具体化することです。分類が曖昧なままプロジェクトを進行すると、開発の終盤で「想定していた処理速度が出ない」「セキュリティ要件を満たしていない」といった致命的な手戻りが発生します。

機能要件・非機能要件の違いと要件定義の例

要件は大きく2つに分類できます。SaaSにおける要件定義の例を以下の表に整理しました。

分類	定義	SaaSにおける要件定義の例
機能要件	ユーザーが目的を達成するためにシステムが直接実行する機能	・メールアドレスとパスワードによるログイン機能 ・CSV形式でのデータエクスポート機能 ・権限別の管理画面表示
非機能要件	性能、可用性、セキュリティなど、システムの品質や裏側の仕組みに関する要件	・画面の遷移を2秒以内に完了させる ・月間稼働率99.9%（計画停止は月1回まで） ・通信データをすべてTLS1.3で暗号化

機能要件は画面イメージや操作フローとして可視化しやすく、ビジネス側と合意を取りやすい一方、非機能要件は目に見えにくく暗黙の了解になりがちです。

IPA非機能要求グレード6大項目を活用する

非機能要件の抜け漏れを防ぐため、独立行政法人情報処理推進機構（IPA）が公開する非機能要求グレードを活用するのが定石です。IPA非機能要求グレードは、118個の要件検討項目と238個（重複除き230個）の指標で非機能要件を網羅的に整理したフレームワークで、要件定義・RFPの実務で広く参照されています。

非機能要求グレードは次の6大項目から構成されます。

1. 可用性 ：システムが継続して稼働する能力（稼働率や計画停止時間）
2. 性能・拡張性 ：処理スピードや将来のアクセス増加への対応
3. 運用・保守性 ：バックアップや障害時の監視体制
4. 移行性 ：既存システムから新しいシステムへのデータ移行
5. セキュリティ ：不正アクセス防止やデータ暗号化の基準
6. システム環境・エコロジー ：サーバーの物理環境や耐震性など（クラウド移行により省略されるケースも多い）

実務では「社会的影響が殆ど無いシステム」「社会的影響が限定されるシステム」「社会的影響が極めて大きいシステム」の3モデルからプロジェクトに近いものを選び、テーラリング（プロジェクトで検討すべき項目の絞り込み）を行うのが標準的な流れです。

ステップ5：仕様変更への対応と管理ルール

5つ目のステップは、「仕様変更への対応と管理ルールの策定」です。初期段階で開発対象の境界線を引くことが、後の手戻りやコスト超過を防ぐ要となります。

スコープと変更管理の基本事項

スコープ管理とは、実装する機能（インスコープ）と実装しない機能（アウトスコープ）を明確に定義することです。「何を作らないか」をステークホルダー間で合意しておくことで、開発フェーズに入ってからの認識のズレを防ぎます。

例えば「決済機能は外部の決済代行サービスへのリンクで代用し（インスコープ）、自社独自の決済システムの構築は見送る（アウトスコープ）」のように、明確に境界線を引きます。

変更管理シートのサンプル

進行中に新たな機能追加の要望が寄せられた際は、感覚で判断せず、客観的な「変更管理シート」で評価します。変更管理シートに必須の項目は次の通りです。

• 変更要求日・起票者 ：誰がいつ変更を求めたか
• 変更内容と目的 ：何を、なぜ追加・変更したいのか
• ビジネス上のインパクト ：追加することで得られる効果（売上増加、工数削減など）
• 影響範囲（工数・スケジュール・費用） ：エンジニアが算出した追加コスト
• 代替案の有無 ：既存機能や手動運用でカバーできないか
• 承認状況 ：プロジェクト責任者による最終判断

口頭依頼の積み重ねを防ぐ運用

最も注意すべきは「口頭での曖昧な仕様変更」です。「ついでにこのボタンも追加してほしい」といった軽い依頼が積み重なると、最終的なスケジュールが破綻します。変更要求は必ず変更管理シートのプロセスを通し、影響範囲を調査してから承認を得るフローを厳格に守ることが、現場を混乱させないための鍵です。

ステップ6：チームの認識を揃えるコラボレーション

6つ目のステップは、関わるメンバーの多様なスキルを結集し、強固なチーム連携を構築することです。業務フローに精通した事業担当者と、実現可能性を判断するエンジニア間の密な連携が不可欠です。

要件定義のプロセスで使われる代表的なコラボレーションツールには次のようなものがあります。

• Miro／Lucidchart（オンラインホワイトボード） ：As-Is／To-Beの業務フロー図を複数人で同時に書き込みながら可視化
• Notion／Confluence（ドキュメント管理） ：議事録や要件定義書を一元管理し、常に最新の情報をチーム全員が参照
• Figma（デザイン・プロトタイピング） ：ワイヤーフレームや画面モックアップを作成し、完成イメージの認識を視覚的に統一

専門用語の違いやコミュニケーションの齟齬による認識ズレを防ぐためには、単に要件を文字で羅列するのではなく、ツールを用いて図やプロトタイプで共有することが重要です。「誰が、いつ、どのような決定を下すのか」という意思決定のプロセスもツール上で記録し、可視化しておきます。

ステップ7：運用保守を見据えたルール策定

7つ目のステップは、リリース後の運用保守を見据えたルールの策定です。稼働後のパフォーマンス・セキュリティ・可用性といった非機能要件を、要件定義の段階で具体的な数値に落とし込みます。

SLA（サービスレベル合意）の具体例

許容できる障害の範囲やシステムの復旧目標時間を、具体的な数値で取り決めます。すべてのリスクに完璧な対策を講じようとすると、インフラコストと開発期間が大幅に膨らみます。

SaaS事業の運用では、以下のようなSLAの数値を具体的に設定します。

• 稼働率の目標 ：月間稼働率99.9%（月のダウンタイムを約43分以内に抑える）
• 障害時の対応時間（RTO） ：重大な障害発生時は、検知から4時間以内に復旧
• データのバックアップ ：毎日午前3時に日次バックアップを取得し、過去30日間保存

ビジネスへの影響度と投資可能な予算のバランスを客観的に見極めて要件を決定します。SLAの設定の詳細はSLAとは？SaaS契約で発注側が確認すべき7つのポイントも参考にしてください。

形骸化を防ぐドキュメント更新フロー

要件定義書や仕様書の形骸化を防ぐ仕組みも重要です。開発フェーズや運用開始後に仕様変更が発生した際、ドキュメントが適切に更新されないと、システムの属人化を招き、将来的な機能拡張の妨げになります。初期段階から仕様変更の承認フローやドキュメントの更新プロセスを関係者間で合意しておくことが、長期的に安定したサービス提供の基盤となります。

要件定義の成果物一覧｜要件定義書に含めるべきドキュメント

要件定義フェーズの成果物（Deliverables）は、要件定義書を中心とした関連ドキュメント群です。代表的な成果物は次の通りです。

成果物	目的	主な記載内容
要件定義書	プロジェクトの合意事項を一元化	目的、スコープ、機能要件、非機能要件、用語集
業務フロー図（As-Is／To-Be）	現状と理想の業務プロセスを可視化	各部門の担当作業、データの受け渡し
機能一覧表	実装する機能を網羅・優先度付け	機能名、概要、優先度（Must／Want）、画面ID
非機能要件一覧	性能・可用性・セキュリティ等の数値要件	IPA非機能要求グレード6大項目に沿った数値
画面遷移図／画面モック	UI／UXのイメージを統一	画面構成、入力項目、遷移条件
変更管理シート	仕様変更の承認プロセスを可視化	変更内容、影響範囲、承認者
用語集（Glossary）	関係者間の言葉のズレを排除	業務用語、システム用語の定義

要件定義書の具体的なフォーマットや12項目の記入例は要件定義書サンプル完全ガイドで扱っているため、本記事と併読すると現場での粒度感がつかみやすくなります。

ウォーターフォール／アジャイル開発における要件定義の扱い

要件定義はウォーターフォール開発前提で語られることが多いですが、アジャイル開発でも「要件定義は不要ではない」というのが現場の実感です。

開発手法	要件定義のタイミング	代表的なアウトプット
ウォーターフォール	上流工程で一度に確定	要件定義書、業務フロー、機能一覧
アジャイル（Scrum）	プロダクトバックログとして継続的に詳細化	プロダクトゴール、ユーザーストーリー、Definition of Done

Scrum Guide 2020では、プロダクトオーナーがプロダクトバックログを継続的に管理し、各スプリント開始時にスプリントバックログを精緻化することが定められています。アジャイルでの実務上の進め方はアジャイル開発の要件定義は不要？仕様書との違い・進め方5ステップに整理しました。

なお、生成AIを使った要件定義の効率化（ヒアリング議事録のサマリ作成、要件定義書ドラフトの自動生成など）は要件定義にAIを活用する方法で詳しく扱っています。

要件定義に関するよくある質問

Q. 要件定義と要求定義の違いは何ですか？

A. 要求定義は「やりたいこと（要求）」を整理する工程、要件定義は「やりたいことを満たすために何を実装するか」を決める工程です。共通フレーム2013では要求定義の成果物として「要求仕様書」、要件定義の成果物として「要件定義書」が位置づけられています。

Q. 要件定義と基本設計の違いは何ですか？

A. 要件定義は「Why／What（何を・なぜ作るか）」、基本設計は「How（どう実現するか）」を扱う工程です。要件定義の成果物が要件定義書、基本設計の成果物がシステム構成図や画面設計書になります。

Q. 要件定義の主な成果物は何ですか？

A. 要件定義書を中心に、業務フロー図（As-Is／To-Be）、機能一覧表、非機能要件一覧、画面遷移図／モック、変更管理シート、用語集の7点が代表的な成果物です。

Q. 非機能要件はどう抜け漏れを防げばよいですか？

A. IPA非機能要求グレードの6大項目（可用性／性能・拡張性／運用・保守性／移行性／セキュリティ／システム環境・エコロジー）を起点にテーラリングするのが標準的です。クラウド前提なら「システム環境・エコロジー」を簡略化するなど、プロジェクトに応じた取捨選択を行います。

Q. 要件定義で失敗するプロジェクトに共通する原因は何ですか？

A. JUASのソフトウェア・メトリクス調査でも、要件定義段階の合意不足が手戻りの主要因として継続的に指摘されています。具体的には「要求と要件の混同」「Must／Wantの線引きの曖昧さ」「変更管理ルールの不在」の3点が多く、本記事の7ステップはこれらに正面から対応する構成です。

まとめ｜要件定義の本質は「やらないこと」を決め切ること

要件定義は、SaaS開発や社内システム刷新の成否を左右する最も重要なフェーズです。本記事で解説した「目的とスコープの明確化」「要求と要件の切り分け」「機能要件と非機能要件の定義」「変更管理ルールの策定」を中心とする7ステップを押さえることで、手戻りを最小限に抑え、計画通りのスケジュールと予算で価値あるプロダクトをリリースできます。

さらに細部に踏み込みたい場合は、要件定義書のフォーマットを扱う要件定義書サンプル完全ガイド、AI活用による効率化を扱う要件定義にAIを活用する方法、アジャイル開発での運用を扱うアジャイル開発の要件定義は不要？仕様書との違い・進め方5ステップを併せて読むと、要件定義クラスタ全体が体系的に理解できます。