アジャイル開発の要件定義は不要？仕様書との違い・進め方5ステップ【Scrum Guide 2020準拠】

結論から言うと、アジャイル開発でも要件定義は必須です。 「不要」と語られるのは、初期に全要件を凍結するウォーターフォール型の網羅的な要件定義のことであり、 何を作るか・なぜ作るかの合意形成自体は省略できません 。本記事ではScrum Guide 2020準拠で、ユーザーストーリー・プロダクトバックログ・完了の定義（DoD）を使ってアジャイル開発の要件定義をどう運用するかを、現場で再現可能な5ステップに分解します。あわせて「アジャイルに仕様書は必要か」という疑問にも答えます。

本記事を読むと次の3点が分かります。

• 「アジャイル開発 要件定義 不要」と言われる本当の意味と、その誤解の解き方
• ユーザーストーリー（INVEST原則）と軽量な設計書で要件・仕様書を扱う具体的な書き方
• DoDにドキュメント更新を組み込み、変更に強い要件管理を維持する運用ルール

アジャイル開発の要件定義は不要？「不要論」の正体を整理する

「アジャイル開発 要件定義 不要」というクエリで検索する人が最も知りたいのは、 本当に何も決めずに開発を始めてよいのか という一点です。結論は ノー で、決めるタイミングと粒度を変えるだけです。

アジャイルソフトウェア開発宣言の正しい読み方

アジャイルソフトウェア開発宣言には「包括的なドキュメントよりも動くソフトウェアを」と書かれていますが、続きに「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」と明記されています。 ドキュメントの価値そのものは否定されていません 。

アジャイル開発で不要とされているのは、次の3つの「重い要件定義」のスタイルです。

• 開発開始前にすべての画面・機能・データ項目を凍結する数百ページの要件定義書
• 変更を抑制するためのウォーターフォール型の承認プロセス
• ユーザーが触る前に確定する、検証されていない仕様

逆に、次の3点は アジャイル開発でも必須 です。

• プロダクトのビジョン・ターゲットユーザー・解決する課題の合意
• 非機能要件（性能・セキュリティ・可用性・コンプライアンス）の早期定義
• スプリント単位で開発対象となる要件（ユーザーストーリー）の継続的な詳細化

ウォーターフォールとの粒度・タイミング差

両者の違いは「やるかやらないか」ではなく「いつ・どこまで詳細化するか」です。

観点	ウォーターフォール	アジャイル開発
初期に決める範囲	全機能の詳細仕様	プロダクトビジョン + 非機能要件 + 大きめのテーマ
詳細化のタイミング	開発開始前に一括	スプリント直前に少しずつ（プロダクトバックログリファインメント）
変更管理	変更要求書 + 影響分析 + 再承認	プロダクトオーナーが優先順位を入れ替える
主要成果物	機能要件定義書・基本設計書	プロダクトバックログ・ユーザーストーリー・軽量設計書
契約形態	請負契約が中心	準委任契約が中心（IPAアジャイル開発版モデル契約）

IPAのアジャイル開発版モデル契約書（2020年3月公開）では、成果物の完成ではなく ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約 が前提とされています。外部委託でアジャイル開発を採用する場合、契約形態と要件定義の進め方はセットで設計する必要があります。

要件定義そのものの基本構造を改めて押さえたい場合は要件定義とは？意味・進め方・具体例を、ウォーターフォール手法との詳細比較はアジャイル開発・ウォーターフォール開発の違いを参照してください。

「アジャイル開発に仕様書は必要か？」への答え

「アジャイル 仕様書」というクエリで検索する人が知りたいのも、結局は同じ問いです。答えは 「ウォーターフォール型の機能仕様書は作らないが、ユーザーストーリー + 軽量設計書という形で仕様情報は必ず残す」 となります。

従来の仕様書	アジャイル開発での代替
機能仕様書（画面遷移・項目定義の網羅）	ユーザーストーリー + 受け入れ基準 + UIモック
詳細設計書（クラス図・処理フロー）	コード自体 + ADR（設計判断の記録）
API仕様書（手動更新）	OpenAPI（コードから自動生成）
テスト仕様書（事前作成）	受け入れ基準 + 自動テストコード

つまり「仕様書を書かない」のではなく、 仕様情報を分散させて、それぞれを変更に強い形で管理する のがアジャイル開発の実態です。ステップ4で扱う「軽量設計書」がこの代替の中心になります。

アジャイル開発の要件定義でドキュメント不足が招く3つのリスク

「動くソフトウェア優先」を「ドキュメント不要」と誤読すると、次の3つの形で必ず破綻します。

1. オンボーディングコスト爆発

新メンバーが過去のコミットログとSlackログを読むだけで仕様を再構築するのは現実的ではありません。 6ヶ月以上稼働しているプロダクトに新メンバーが加わると、ドキュメントがない場合のキャッチアップは平均で2〜4週間遅延する と現場では言われます。プロダクトオーナーが交代した瞬間に「なぜこの仕様にしたか」が失われ、過去の判断を再現できないまま方向修正できなくなります。

2. 影響範囲の把握不能による技術的負債

ER図・API仕様・状態遷移を残さないと、3スプリント後に「この修正で何が壊れるか分からない」状態になります。リファクタリング時に設計意図が不明となり、単純な機能変更にも数週間を要する事例は珍しくありません。これは「重い要件定義をやめた結果」ではなく「 軽い要件管理すらやめた結果 」です。

3. 受け入れ基準の曖昧化によるリリース判定不能

ユーザーストーリーに受け入れ基準（Acceptance Criteria）がないと、プロダクトオーナーは「動くソフトウェア」が要件を満たしているか判定できません。スプリントレビューが毎回「これで完了でいいですか？」の確認会になり、リリース判定が属人化します。

これらのリスクを回避する鍵は、 変化への柔軟な対応 と 最低限の証跡保持 のバランスです。どのタイミングで、どの粒度でドキュメント化するかは、後述のステップ1〜3でチーム内に合意ルールとして埋め込みます。失敗パターンを先に俯瞰したい場合はアジャイル開発のメリット・デメリット完全比較（成功率39% vs 11% のCHAOS Reportデータ付き）、開発プロセス全体はSaaSシステム開発を成功させる7つのポイントも参考になります。

アジャイル開発の要件定義 進め方5ステップ

ここからが本題です。アジャイル開発の要件定義を、現場で再現可能な5ステップに分解します。「 そのドキュメントがないことで将来のチームが困るか 」を判断基準にしてください。

ステップ1: プロダクトビジョンと非機能要件を最初に固定する

開発を始める前に固める「凍らせてよい部分」を明確にします。スプリントごとに変えるとプロダクトの軸がぶれるためです。

固定すべき項目は次の4つです。

• プロダクトビジョン: 誰のどの課題を、何によって解決するか（エレベーターピッチ形式）
• ターゲットユーザーとペルソナ: 主要1〜2セグメント
• 非機能要件: 想定同時接続数・レスポンス目標・稼働率・データ保持期間・認証強度・準拠すべき法令
• 制約条件: 予算・期限・既存システムとの連携・利用が必須の技術スタック

非機能要件はリリース後に変更すると影響が大きいため、SLAの考え方を含めて最初に決めます。詳細はSLAとは？SaaS契約で発注側が確認すべきポイントが参考になります。

ステップ2: 大きなテーマをユーザーストーリーに分解する（INVEST原則）

機能を箇条書きで並べるのではなく、 ユーザーストーリー で「誰が・何をしたくて・なぜか」を1枚のカードに収めます。

書式は次の通りです。

<役割> として、 <実現したいこと> したい。なぜなら <得たい価値> だからだ。

実際のサンプルは次のようになります。

「 営業担当者 として、顧客の 過去の商談履歴を1画面で一覧表示 したい。なぜなら、商談前の準備時間を 30分から5分に短縮 して提案の質を上げたいからだ。」

書いたユーザーストーリーは INVEST原則 で品質を確認します。INVESTは2003年にBill Wake氏が論文「INVEST in Good Stories, and SMART Tasks」で提唱した、良いユーザーストーリーの6条件です。

文字	意味	チェック観点
Independent	独立	他ストーリーと依存せず単独でリリースできるか
Negotiable	交渉可能	プロダクトオーナーと開発者で詳細を調整できる余地があるか
Valuable	価値がある	ユーザーまたはビジネスに具体的な価値があるか
Estimable	見積もり可能	開発工数を相対サイズで見積もれるか
Small	小さい	1スプリント内に収まる粒度か
Testable	テスト可能	受け入れ基準で達成判定できるか

各ストーリーには 受け入れ基準（Acceptance Criteria） を3〜5項目添えます。例えば「商談履歴は新しい順に表示される」「1画面に20件まで表示される」「ステータスフィルタが効く」のように具体的に書くと、開発者・QA・プロダクトオーナーの認識が揃います。

ユーザーに最初に届ける最小単位の見極めにはMVP開発による成功手順も合わせて検討してください。

ステップ3: プロダクトバックログと優先順位付けの仕組みを作る

ユーザーストーリーを集約する場所が プロダクトバックログ です。Scrum Guide 2020では「 プロダクトを改善するために必要なものの、創発的で順序付けされたリスト 」と定義され、Scrum Team の作業の 唯一の発生源（the single source of work） と位置づけられています。管理責任はプロダクトオーナーが負います。

優先順位付けには MoSCoW分析 が現場で使われます。

• Must have: このスプリント・このリリースに必須
• Should have: 重要だが必須ではない
• Could have: あれば良い
• Won't have (this time): 今回はやらない（次回検討）

MoSCoWの使い方を詳しく知りたい場合は要件定義の進め方5ステップで具体例まで踏み込んで解説しています。

優先順位は プロダクトバックログリファインメント （Scrum Guide 2020で「継続的な活動」と明示）で、プロダクトオーナーと開発者が一緒に更新します。Scrum.org のガイダンスでは、リファインメントに 開発チームのキャパシティの10%程度 を割り当てることが一般的な目安として紹介されています。

ステップ4: 「安定した概念」だけを軽量な設計書に残す

ユーザーストーリーで日々の要件を扱う一方で、変わりにくく・かつ参照頻度の高い情報は 動的な設計書 として残します。テキスト中心の重いドキュメントを書くのではなく、 コードや実装と同期する形式 を選ぶのが鉄則です。

残すべき設計書と推奨ツールは次の通りです。

設計書	役割	推奨ツール・形式
API仕様書	エンドポイント・リクエスト・レスポンスの定義	OpenAPI(Swagger)でコードから自動生成
データモデル（ER図）	テーブル構造とリレーションの可視化	dbdocs / Mermaid / SchemaSpy
UI設計・コンポーネント	デザインの一元管理	Figmaのコンポーネントライブラリ
実装済みUIカタログ	フロントエンド再利用の促進	Storybook
アーキテクチャ図	システム全体構成の把握	C4モデル + Mermaid / Lucid / draw\.io
ADR（アーキテクチャ決定記録）	なぜその技術を選んだかの根拠	Markdownでリポジトリに同梱

「コードを書く前に書く」のではなく「コードと同時に最新化する」 運用が要点です。これにより、ドキュメントとコードのドリフト（乖離）を最小化できます。技術選定の前提から整えたい場合はSaaS開発を成功に導く言語・環境の選び方も併せて確認してください。

要件定義の成果物全体を体系的に整理したい場合は要件定義の成果物一覧と基本設計との違い、要件定義書フォーマットそのもののサンプルが必要なら要件定義書の書き方サンプル完全ガイドも参考になります。

ステップ5: 完了の定義（DoD）にドキュメント更新を組み込む

要件定義の形骸化を防ぐ最後の関門が、 完了の定義（Definition of Done、DoD） です。Scrum Guide 2020 では DoD を インクリメントに対するコミットメント として位置づけており、開発者が品質を担保するための共通基準とされています。

DoDに ドキュメント更新タスクを明示的に含める ことで、ドキュメントが古いまま放置される事態を構造的に防げます。具体例を示します。

DoDサンプル（SaaS開発の場合）

• 受け入れ基準をすべて満たしている
• コードレビューを通過している
• ユニットテストカバレッジが80%以上
• OpenAPI仕様書がコードと一致している（CIで自動チェック）
• ER図・状態遷移図に変更がある場合は更新済み
• 主要なアーキテクチャ判断があればADRに記録済み
• ステージング環境でプロダクトオーナーが動作確認済み
• 監視・ログ設定が本番運用に耐える状態である

このリストはチームの成熟度に応じて拡張していきます。 全項目を満たしてから「Done」 とし、満たさないストーリーは次スプリントへ持ち越します。

スプリント運用の実務的な進め方はアジャイル スプリントとは？期間の決め方と進め方、スクラム特有のロール・イベントはアジャイル開発とスクラムの違いも合わせて確認してください。

アジャイル開発の要件定義でやってはいけない3つのアンチパターン

実際のプロジェクトで発生しやすい失敗を3つにまとめます。リリース前のチェックリストとして活用してください。

アンチパターン1: ユーザーストーリーを「タスク」として書く

「ログイン画面を作る」「商談一覧APIを実装する」のように 実装作業の単位 で書いてしまうケースです。これでは「誰のどの価値のために作るか」が消え、優先順位の根拠も曖昧になります。常に 役割・目的・価値 の3点を含めてください。

アンチパターン2: 受け入れ基準を後付けで書く

スプリント開始直前に受け入れ基準を書くと、開発中に「これは含まれない」「これも必要だった」と認識ズレが頻発します。プロダクトバックログリファインメントの段階で プロダクトオーナーと開発者が一緒に受け入れ基準を確定 してからスプリントに投入してください。

アンチパターン3: 非機能要件をスプリント単位で扱う

性能・セキュリティ・可用性をスプリントごとに小出しにすると、アーキテクチャ全体の整合が取れなくなります。 非機能要件はステップ1で固定 し、スプリントごとに扱うのは機能要件と受け入れ基準だけにします。

よくある質問（FAQ）

Q1. アジャイル開発で要件定義書は本当に書かなくていいですか？

「重厚な要件定義書」は不要ですが、 プロダクトビジョン・非機能要件・主要なユーザーストーリーリスト は必ず文書化してください。これらは契約・チーム間連携・新メンバー受け入れの基盤になります。

Q2. アジャイル開発に仕様書は必要ですか？

ウォーターフォール型の「機能仕様書」は作りません。代わりに ユーザーストーリー + 受け入れ基準（機能仕様の代替） 、 OpenAPI（API仕様の代替） 、 Figma + Storybook（UI仕様の代替） 、 ADR（設計判断の記録） を組み合わせます。「仕様書を1冊にまとめる」発想を捨て、「仕様情報を変更に強い形式に分散させる」発想に切り替えるのがポイントです。

Q3. ウォーターフォール経験者が陥りやすい誤解は何ですか？

「決めてから作る」を捨てきれず、ユーザーストーリーを詳細化しすぎる傾向です。INVESTの N（交渉可能） を意識し、 開発中も詳細を更新してよい と割り切ることが鍵です。

Q4. プロダクトオーナーがいない場合はどうしますか？

IPAアジャイル開発版モデル契約でも、プロダクトオーナーはユーザー企業側が立てることが原則とされています。立てられない場合は、要件凍結を前提としたウォーターフォール型の方が破綻リスクが低いケースもあります。

Q5. 設計書はどこまで詳しく書くべきですか？

「 そのドキュメントがないと将来困るかどうか 」が判断基準です。コードを読めば分かることは書かず、 コードを読んでも分からない判断の背景・データ構造・外部接続仕様 だけを書くのが鉄則です。

Q6. ドキュメントが必ず古くなる問題はどう防ぎますか？

ステップ5のDoDに「ドキュメント更新済みであること」を入れ、 Pull Requestのチェックリストでも確認 してください。さらにAPI仕様書はOpenAPI、UIはStorybookのように コードから自動生成 できる仕組みに移行すると、ドリフトを構造的に減らせます。

まとめ

アジャイル開発でも要件定義は必須で、 不要なのは「初期に全要件を凍結する重い要件定義」だけ です。次の5ステップで運用すれば、アジャイルの柔軟性と要件管理の堅牢さを両立できます。

1. プロダクトビジョンと非機能要件 を最初に固定する
2. 機能要件は ユーザーストーリー（INVEST） で扱い、受け入れ基準を必ず添える
3. プロダクトバックログ で優先順位を一元管理し、MoSCoWでスコープを判断する
4. 変わりにくい部分だけ 軽量な動的設計書（OpenAPI・Figma・Storybook・ADR） として残す
5. DoDにドキュメント更新を組み込み 、形骸化を構造的に防ぐ

これらを徹底すれば「アジャイル開発 要件定義 不要」「アジャイル 仕様書 不要」という誤解からチームを守り、Scrum Guide 2020準拠の現代的な開発体制を構築できます。次に手を動かすなら、要件定義の進め方5ステップや要件定義書の書き方サンプルで具体的なフォーマットに落とし込んでみてください。