要件定義の成果物一覧【サンプル付き】基本設計との違いと手戻りを防ぐ7つのポイント

「要件定義の成果物として、何をどこまで書けばよいのか分からない」――SaaS開発プロジェクトに初めて携わるPMや事業担当者から、最もよく聞かれる悩みのひとつです。成果物の範囲が曖昧なまま開発に進むと、後工程で「想定と違う」という手戻りが多発し、スケジュールとコストの両方に大きなダメージを与えます。

本記事では、要件定義フェーズで作成すべき 成果物の種類と各サンプル を一覧形式で整理します。さらに、後続工程である「基本設計」との役割の違い（What vs How）を明確にし、 手戻りを防ぐ7つの実践ポイント を具体例とともに解説します。すでに「要件定義の進め方」は理解している方で、「成果物の具体的な中身と品質基準」を知りたい方に特に役立つ内容です。

なお、本記事で扱う成果物の定義・工程区分は、IPA（情報処理推進機構）が公開する「共通フレーム2013（SLCP-JCF2013）」の用語体系に準拠しています。プロジェクト管理の観点はPMI公式のPMBOKガイド第7版を参照しています。

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

要件定義を成功させるためには、後続工程である「基本設計」との境界線を明確にすることが第一歩です。この役割の違いを理解せずにドキュメントを作成すると、システム的な制約に縛られて本来のビジネス目的を見失ったり、逆にエンジニアに意図が伝わらず間違ったシステムが作られたりするリスクがあります。

何を決めるか（What）と、どう作るか（How）

要件定義と基本設計の最大の違いは、定義する対象の視点にあります。

• 要件定義（What）: 「ユーザーのどんな課題を、どの機能で解決するか」を定義します。対象読者は事業責任者やステークホルダーであり、非エンジニアでも理解できるビジネス用語・業務視点で記述します。
• 基本設計（How）: 要件定義で決まった機能を「システム的にどう実現するか」を定義します。画面レイアウト、データベースのテーブル構造、API仕様など、開発者（エンジニア）向けの専門的なドキュメントとなります。

この視点の切り替わりを意識し、要件定義の段階でシステムの内部構造（How）に踏み込みすぎないことが重要です。

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

「要件定義 基本設計 違い」を一目で押さえたい方のために、6つの観点で対比した比較表を用意しました。

観点	要件定義（What）	基本設計（How）
目的	ビジネス課題と解決手段の合意	機能をシステムとして実装可能な単位に翻訳
主な読者	事業責任者・ユーザー部門・経営層	開発エンジニア・QA・運用担当
記述粒度	業務用語・ユーザー視点	画面・API・データモデル単位
主な成果物	業務要件定義書／システム要件定義書／機能要件一覧／非機能要件定義書	画面設計書／ER図／API仕様書／バッチ設計書
承認者	事業責任者・プロダクトオーナー	開発リーダー・アーキテクト
変更コスト	低（合意のし直しが中心）	高（既存設計・コードの影響を伴う）

なお、ウォーターフォール型ではこの2工程を明確に分離しますが、アジャイル型ではユーザーストーリー単位で What と How を短いサイクルで往復します。手法選択による要件定義のあり方の違いはアジャイル開発の要件定義は不要？仕様書との違い・進め方5ステップ【Scrum Guide 2020準拠】で詳しく整理しています。

要件定義で作成する主な成果物一覧とサンプル

要件定義フェーズで作成する成果物は、プロジェクトの規模によって異なりますが、一般的に以下のドキュメントが中心となります。これらが基本設計へ引き継ぐための重要なインプットになります。

成果物名	目的・役割	主な承認者	具体的な記載項目のサンプル
業務要件定義書	ユーザー部門の業務がどう変わるかを明確にし合意を取る	事業責任者・業務部門長	・現状の業務フロー（As-Is） ・システム導入後の業務フロー（To-Be） ・解決すべき課題と期待効果
システム要件定義書	何をシステム化し、何を対象外にするか（スコープ）を定義する	プロダクトオーナー	・システム化の対象範囲（インスコープ） ・対象外範囲（アウトスコープ） ・前提となる利用環境（ブラウザ、OS）
機能要件一覧	ユーザーの要求を実現するために、システムが提供すべき具体的な機能を洗い出す	プロダクトオーナー・開発リーダー	・画面ごとの必要機能（例: CSV一括登録） ・データ入出力要件 ・ユーザー権限管理（管理者・一般）
非機能要件定義書	目に見えないシステムの品質、性能、運用要件などの制約事項を定める	開発リーダー・運用責任者	・目標応答速度（例: 検索結果表示は3秒以内） ・セキュリティ基準（IP制限など） ・稼働時間、バックアップ方針

非機能要件の項目体系については、IPAが公開する「非機能要求グレード」を参照すると、可用性・性能・拡張性・運用保守・移行・セキュリティ・システム環境の7カテゴリで網羅的に整理できます。自社で1から項目を洗い出すよりも、まずグレード表をベースに自プロジェクトに必要な行だけ抽出するほうが漏れを防ぎやすくなります。

要件定義書のサンプル・テンプレートはどこで入手できるか

「要件定義書 サンプル」で検索すると無数のテンプレートがヒットしますが、品質を担保したい場合は 公的機関が公開している一次資料 をベースにするのが最短ルートです。商用テンプレート集を購入する前に、以下の無料公開資料を確認してください。

• IPA 共通フレーム2013 関連資料 ：要件定義工程で作成すべきドキュメントの章立て・記載項目・受け入れ基準が体系的に整理されています。SLCP-JCF2013に準拠した汎用テンプレートとして、官公庁・金融などコンプライアンス要求が厳しい案件でも引用根拠として通用します。
• IPA 非機能要求グレード ：非機能要件定義書のサンプル相当として、項目ごとの「レベル0〜5」のメトリクス例まで掲載されています。Excel形式で配布されているため、そのままプロジェクト固有値を入れる土台として使えます。
• 経済産業省「DX推進指標」自己診断シート ：業務要件定義書のAs-Is/To-Be整理に流用できる項目群が含まれており、経営層レビュー資料との接続に便利です。

これらをベースに、自社の業務用語・固有要件・固有制約だけを書き足していくのが、自前テンプレートを1から作るよりも圧倒的に早く、かつレビュー指摘が減る進め方です。Webサイト構築やノーコード活用が前提の場合は記載粒度を調整する必要があるため、テンプレートを丸呑みせず、次章の7つのポイントと照らし合わせて取捨選択してください。

手戻りを防ぐ！要件定義の成果物作成7つのポイント

質の高い要件定義の成果物を作成し、プロジェクトを成功に導くための7つの実践ポイントを具体例とともに解説します。

1. 目的とスコープ（対象範囲）の明文化

要件定義において最初に押さえるべきは、プロジェクトの目的とスコープの可視化です。「誰の、どのような課題を、システムでどう解決するのか」が第三者にも伝わる内容になっているかを確認します。 特に「やらないこと（アウトスコープ）」を明記することが、後々の仕様追加によるスケジュール遅延（スコープクリープ）を防ぐ防波堤になります。PMBOKガイド第7版でも、スコープ・ステートメントに「除外事項（Exclusions）」を明示することがプロジェクト成功の前提条件として挙げられています。

2. 業務フロー（As-Is/To-Be）の可視化

システム要件を決める前に、必ず業務フローを図解して関係者で認識を合わせます。 「現状の業務（As-Is）」から「システム導入後の理想の業務（To-Be）」へどう変化するのか、ユーザーの視点でプロセスを記述します。BPMN（Business Process Model and Notation）など標準記法を使うと、業務部門と開発チームの両方が同じ図を読めるようになり、レビュー会の認識ズレを減らせます。

3. 機能要件は「誰が・何を・どうする」レベルで書く

機能要件一覧を作る際は、「ユーザー管理機能」といった曖昧な記述を避け、具体性を持たせます。

• 悪い例：「ユーザー情報をエクスポートできる機能」
• 良い例：「管理者権限を持つユーザーが、検索条件で絞り込んだユーザー一覧をCSV形式でダウンロードできる機能」

このように「誰が（アクター）」「何を（対象）」「どうする（アクション）」の粒度で書くことで、エンジニアが基本設計に落とし込みやすくなります。アジャイル開発で用いるユーザーストーリー（「[役割]として、[目的]のために、[機能]がほしい」）と同じ構造になるため、開発手法を切り替える際にも資産として流用できます。

4. 非機能要件（セキュリティ・性能）の数値化

非機能要件は、開発後半になってから「動作が遅い」「アクセス制限ができない」といったトラブルの火種になりやすい部分です。 「サクサク動くこと」「安全であること」といった定性的な表現ではなく、必ず数値化して定義します。

• 性能要件：「同時アクセス1,000件時でも、ダッシュボードの表示が2秒以内に完了すること」
• 稼働要件：「計画停止を除き、月間稼働率99.9%を保証すること」

稼働率の目標を決めるときは、SaaS契約におけるサービスレベル合意（SLA）と整合させる必要があります。SLA・SLO・SLIの考え方はSLOとは？SLA・SLIとの違いとエラーバジェット運用7つのポイントで詳しく解説しています。

5. ワイヤーフレームで画面イメージの認識を揃える

機能一覧のテキストだけでは、発注者と開発者の間でイメージのズレが生じます。要件定義の段階で簡易的な画面構成図（ワイヤーフレーム）を作成し、どの画面にどの情報やボタンが配置されるかを可視化しましょう。 ただし、ここでは詳細なデザイン（色やマージンなど）は決めず、あくまで「どんな情報要素が必要か」の確認に留め、詳細なUI設計は基本設計や詳細設計に委ねます。

6. 例外処理とエラー時の挙動を定義する

正常に処理が進んだ場合（正常系）の要件だけでなく、エラーが発生した場合（異常系・例外処理）の要件も網羅的に定義します。

• 「必須項目が未入力の場合、どの箇所にどのようなエラーメッセージを赤字で出すか」
• 「外部APIとの連携がタイムアウトした場合、リトライするのかエラー画面に遷移するのか」 これらが定義されていることで、テスト工程での「抜け漏れ」を劇的に減らすことができます。共通フレーム2013でも、要件定義工程の終了基準として「異常系の振る舞いが定義されていること」が含まれています。

7. 変更管理ルールと承認プロセスを策定する

SaaS開発においては、市場のフィードバックを受けながら仕様を変更するケースが頻繁に発生します。そのため、要件定義の成果物は「一度作って終わり」ではなく、常に最新状態にアップデートする（変更管理）ルールが必要です。 仕様変更が発生した際の承認フロー（誰が決裁するのか）、変更履歴の記録方法、関係者への周知プロセスをプロジェクト初期段階で定めておきましょう。

よくある質問（FAQ）

Q1. 要件定義と基本設計の違いを一言で説明すると？

要件定義は「 何を作るか（What） 」をビジネス言葉で合意する工程、基本設計は「 どう作るか（How） 」を技術的に決める工程です。要件定義が事業責任者向けのドキュメントなのに対し、基本設計は開発エンジニア向けのドキュメントである点が最大の違いです。

Q2. 要件定義の成果物は最低限どれを作ればよいですか？

プロジェクト規模が小さくても、最低限 「業務要件定義書（As-Is/To-Beの業務フロー）」「機能要件一覧」「非機能要件定義書」 の3点は作成してください。これらが揃っていないと、後工程で「合意していない仕様」「数値化されていない品質要件」を起点とした手戻りが発生します。

Q3. アジャイル開発でも要件定義の成果物は必要ですか？

必要です。ただし作り方が異なります。アジャイル開発では分厚い要件定義書の代わりに、プロダクトバックログとユーザーストーリー（受け入れ基準付き）が成果物の中心になります。詳細はアジャイル開発の要件定義は不要？仕様書との違い・進め方5ステップ【Scrum Guide 2020準拠】を参照してください。

Q4. 非機能要件の項目はどこまで網羅すべきですか？

IPAの「非機能要求グレード」が定める 7カテゴリ（可用性・性能/拡張性・運用保守・移行・セキュリティ・システム環境/エコロジー） を起点に、自プロジェクトに該当する項目を抽出するのが効率的です。SaaSの場合は特に「可用性（稼働率）」「性能（応答時間）」「セキュリティ（認証・データ保護）」を最初に数値化しましょう。

Q5. 要件定義書のテンプレート・サンプルは公開されていますか？

公的機関の無料資料として、IPAの「共通フレーム2013」関連資料（章立て・受け入れ基準）、「非機能要求グレード」（Excel形式の項目表）、経済産業省「DX推進指標」自己診断シート（As-Is/To-Be整理用）の3点を推奨します。社内テンプレートを1から作るのではなく、これらをベースに自社の業務用語へ書き換えるのが最短ルートです。市販のExcel/PDFテンプレート集を導入する場合も、上記の一次資料との整合性を必ず確認してください。

Q6. 要件定義書と仕様書・要求定義の違いは？

要求定義 はユーザー側の「やりたいこと」を整理する上流工程、 要件定義 はそれをシステム化前提で「合意可能な要件」に翻訳する工程、 仕様書（基本設計／詳細設計） は要件をシステム実装単位に分解した成果物、という関係です。要求定義が「事業視点」、要件定義が「業務×システム視点」、仕様書が「実装視点」と覚えると整理しやすくなります。

まとめ

本記事では、手戻りを防ぎ開発を成功に導くための「要件定義の成果物作成7つのポイント」と、「要件定義と基本設計の違い」について解説しました。

要件定義（What）と基本設計（How）の役割を正しく切り分け、ステークホルダー間で「やること・やらないこと」の合意を形成することが、プロジェクト成功の絶対条件です。業務要件、システム要件、非機能要件といった成果物を具体的に記述し、常に最新の状態に保つことで、開発チームとビジネス部門が一体となったスムーズなシステム開発が実現します。IPAの共通フレーム2013や非機能要求グレード、PMBOKガイド第7版といった一次ソースを土台に、自社プロジェクトに合わせてカスタマイズして活用してください。