アジャイル開発の要件定義とは？進め方の5ステップとウォーターフォールとの違い

アジャイル開発に要件定義は不要、という説明を見かけます。しかしスクラムガイド2020年11月版が定めるプロダクトバックログは、要件そのものの置き場にほかなりません。変わるのは要件を扱うかどうかではなく、要件を確定させる時点。この記事では、ウォーターフォール型との分岐点がどこにあるのか、プロダクトゴールの合意からスプリントプランニングまでの5ステップで何を残すのか、ユーザーストーリーの粒度をINVESTとDEEPでどう判定するのかを整理します。あわせて、後回しにすると費用が膨らむ非機能要件と契約・予算の扱い、そしてアジャイル型の要件定義を見送るべき案件条件まで踏み込みます。

まとめ：アジャイル開発の要件定義で先に固める範囲と後回しにできる範囲

アジャイル型の要件定義とは、要件を捨てる工程ではなく、確定のタイミングを機能単位までずらす工程です。ウォーターフォール型が開発着手前に全機能の仕様を確定させるのに対し、アジャイル型はプロダクトゴールと優先順位だけを先に固め、個々の画面仕様はスプリントプランニングの直前に確定させます。アジャイルソフトウェア開発宣言（2001年）の「計画に従うことよりも変化への対応を」は、計画を作らないという意味ではありません。

先に固めるべきものは3つ。プロダクトゴール、意思決定できる体制、予算枠と期間です。この3つが空欄のまま反復に入ると、スプリントごとに方針が揺れ、実装したインクリメントを捨てる回数が増えます。逆に後回しにしてよいのは、画面遷移の細部、項目のバリデーション条件、優先度が下位のストーリーの受け入れ基準。これらを初期に固めても、2回目のスプリントレビューで作り直しになる確率が高く、確定作業そのものが手戻りコストに変わります。

後回しにできない例外が非機能要件と予算の扱いです。性能・可用性・セキュリティは実装後に差し込むと構造から作り直しになるため、完成の定義に組み込むか、独立したストーリーとしてバックログ上位に置きます。契約面では、IPAが2020年3月31日に公開した「情報システム・モデル取引・契約書（アジャイル開発版）」が準委任型を基本に置いており、成果物の完成ではなく協働作業に対価を払う枠組みが前提。請負契約のままアジャイル型に移すと、変更のたびに契約変更の交渉が発生します。

アジャイル開発で要件定義が不要と誤解される理由と実際に固める対象範囲

「要件定義が不要」という言い方は、工程の名前が消えることと、作業が消えることを混同しています。まず、その混同がどこで生まれるのかを分解します。

要件を一度で確定させる前提が崩れる分岐点とアジャイルでの位置づけ

ウォーターフォール型の要件定義は、開発の前段に1回だけ置かれる独立工程です。ここで確定した要件定義書が、基本設計以降のインプットになります。要件定義の目的・進め方・成果物を体系立てて押さえるなら、この前提を先に理解しておくと差分がつかみやすくなります。

アジャイル型では、この工程が消えるのではなく、スプリントの内側に溶けます。スクラムガイド2020年11月版は、プロダクトバックログを「プロダクトの改善に必要なものの一覧」と定義し、その順序づけと詳細化を継続的な活動として扱っています。つまり要件定義は1回のイベントから、スプリントのたびに回る継続作業へ形を変えました。作業量が減るわけではありません。

誤解が生まれる最大の理由は、成果物が「要件定義書」という単一のドキュメントの形を取らないこと。バックログアイテム、受け入れ基準、完成の定義の3つに分散して記録されるため、外から見ると文書が消えたように見えます。

ウォーターフォールとの違いは文書量ではなく要件を確定させる時点

2つの方式の分岐点は、要件が「変更不可」になる時刻です。下表のとおり、確定の単位と時期が入れ替わります。

3つの手法の使い分け全体はウォーターフォール・アジャイル・スクラムの比較に整理しています。ここで押さえるべきは、変更の吸収先が「審査」から「並べ替え」に移る点。並べ替えで吸収するには、そもそも順序をつけられる粒度までストーリーが割れている必要があり、その割る作業こそがアジャイル型の要件定義です。

アジャイルでも初期に固定する3要素（目的・体制・予算枠）の判断基準

スプリントに入る前に決め切る対象は限られます。第一がプロダクトゴール。スクラムガイド2020年11月版で新しく導入された概念で、プロダクトバックログに対応する長期の目標として位置づけられました。これが無いバックログは、優先順位を決める基準を持ちません。

第二が意思決定の体制です。誰がストーリーの順序を最終決定するのか、その人がどこまでの金額と期間を独断で動かせるのか。ここが曖昧なまま進むと、スプリントレビューのたびに社内稟議が挟まり、反復の周期が2倍に伸びます。第三が予算枠と期間の上限。金額を無限にできる案件は存在しないため、枠は先に置きます。

逆に、初期に決めない方がよいものも明確です。画面数、テーブル定義、帳票レイアウト。これらを着手前に固定すると、変更のたびに固定した文書の改訂作業が発生し、アジャイル型を選んだ利点が相殺されます。アジャイル開発の全体像とスクラムの進め方を先に確認しておくと、どこまでを枠として置くかの感覚がつかめます。

プロダクトバックログとユーザーストーリーで要件を段階的に詳細化する組み立て

アジャイル型の要件定義の実体は、バックログの手入れです。何をどの粒度で書き、いつ詳細化するのかを決める基準を見ていきます。

ユーザーストーリーの記述形式とINVESTで粒度を判定する基準

ユーザーストーリーは「＜役割＞として、＜機能＞がほしい。それは＜価値＞のためだ」という形式で書きます。機能名だけを並べた一覧と違い、誰の何のための機能かが必ず残るため、実装の途中で判断に迷ったときの拠り所になります。

粒度の判定には、Bill Wakeが2003年に提唱したINVESTを使います。Independent（独立している）、Negotiable（交渉の余地がある）、Valuable（価値がある）、Estimable（見積れる）、Small（小さい）、Testable（テストできる）の6条件。実務で最初に効くのはEstimableとSmallの2つです。見積れないストーリーは前提が欠けており、1スプリントに収まらないストーリーは分割されていません。

この2つで弾いてから、残りの4条件を点検すれば足ります。6条件を毎回フルで確認する運用は形骸化しやすく、リファインメントの時間を食い潰します。

ユーザーストーリーマッピングで全体像とリリース単位を切り出す手順

バックログは一次元のリストです。そのため、並べただけでは「ユーザーの体験としてどこが抜けているか」が見えません。Jeff Pattonが『User Story Mapping』（2014年・邦訳2015年）で示したユーザーストーリーマッピングは、この欠点を二次元の地図で補います。

横軸にユーザーの行動を時系列で並べ、縦軸に優先度の高い順にストーリーを積む。横一列を横断的に見ると、ログインはあるのにパスワード再発行が無い、といった体験の穴が可視化されます。そのうえで横方向に線を引き、線の上をリリース1、下をリリース2として切り出す。ここで切った線が、そのままリリース計画になります。

この作業をスプリント開始後に行うと、リリース単位の合意が取れないまま実装が進みます。マッピングは初期に一度、全体像を作るために実施する作業です。

リファインメントの頻度と詳細化の深さを決めるDEEPの4条件と時間配分

バックログの手入れは、プロダクトバックログリファインメントと呼ばれます。判断の基準になるのがRoman Pichlerが提唱したDEEP、すなわちDetailed Appropriately（適切に詳細化されている）、Estimated（見積られている）、Emergent（創発的に変わる）、Prioritized（優先順位がついている）の4条件です。

鍵は最初のD。上位のストーリーだけを細かく、下位は粗いまま置くのが正しい状態で、全アイテムを均等に詳細化する運用は誤りです。目安としては、次の1〜2スプリント分が受け入れ基準まで書けていれば足ります。

時間配分については補足が必要です。2017年版のスクラムガイドには「開発チームのキャパシティの10%以内」という目安が書かれていましたが、2020年11月版ではこの記述が見当たりません。上限をガイドに委ねず、チームが自分たちで配分を決める前提に変わったと読むのが自然でしょう。運用としては、週1回1時間を固定枠で確保する形が回りやすい配分です。

アジャイル開発の要件定義を進める5ステップと各段階で残す成果物

ここまでの要素を、着手から最初のスプリントまでの時系列に並べ直します。各段階で何を残すかまで含めて確認してください。

アジャイル要件定義5ステップの全体像とステップ1・2で合意する範囲

全体の流れは次のとおりです。

1. プロダクトゴールと成功指標の合意（成果物：プロダクトゴールの文章、測定指標）
2. ステークホルダーと意思決定権限の確定（成果物：体制図、決裁範囲の一覧）
3. ユーザーストーリーマッピングとリリース単位の切り出し（成果物：ストーリーマップ、初版バックログ）
4. 相対見積りと優先順位づけ（成果物：見積り付きバックログ、リリース計画）
5. スプリントプランニングでの確定（成果物：スプリントバックログ、受け入れ基準）

ステップ1で決めるのは、プロダクトが到達したい状態と、それを測る指標です。「業務を効率化する」では指標になりません。「月末締め作業の所要時間を3営業日から1営業日に短縮する」まで書けば、後続のストーリーの優先順位が自動的に決まります。ステップ2で確定させるのは、承認を待たずに動かせる金額と期間の範囲。この2つの合意文書は、後続のどの判断でも参照される前提資料になります。

ステップ3のストーリーマッピングとステップ4の相対見積りの進め方

ステップ3では、業務の当事者を必ず同席させます。発注側の情報システム部門だけで作ったマップは、現場の例外処理が抜け落ちる傾向があります。締め日前の駆け込み入力、月次と年次で異なる承認ルート、紙で運用している例外。こうした情報は現場からしか出てきません。

ステップ4の見積りは、人日ではなく相対値で行うのが一般的です。基準となるストーリーを1つ選び、それとの比較で規模を判定する。絶対値で見積ろうとすると、未確定要素の多い下位ストーリーに時間を取られ、見積り作業そのものが数日単位で膨らみます。

優先順位づけの基準は、価値の高さと不確実性の大きさの2軸で置きます。価値が高く不確実性も大きいものを最上位に置くのが定石です。技術的な検証が必要な機能を後回しにすると、終盤で実現不可能が判明し、リリース計画ごと組み直しになります。

ステップ5のスプリントプランニングで確定させる範囲と受け入れ基準

スプリントプランニングは、そのスプリントで扱うストーリーだけを確定させる場です。スクラムガイド2020年11月版はスプリントの長さを1か月以内と定めており、確定させる要件の射程もその期間内に収まる分量に限られます。

ここで書き切るのが受け入れ基準です。「検索できること」ではなく「取引先名の部分一致で検索でき、該当0件の場合は登録画面への導線を表示する」まで書く。この粒度に落ちていれば、実装者が仕様を推測する余地が消え、レビューでの差し戻しが減ります。書式の型そのものを整えたい場合は、要件定義書の記載項目と章立てサンプルが参考になります。

確定の範囲を超えて、次スプリント以降の仕様まで書き込むのは避けてください。書いた分だけ変更時の改訂対象が増え、確定の時点をずらした利点が消えます。スプリントの外は、粗いまま置く。

非機能要件と契約・予算をアジャイル型で扱うときの決め方と落とし穴

反復で吸収できない領域が2つあります。構造に影響する非機能要件と、社外との取り決めです。

非機能要件を完成の定義と個別ストーリーに振り分ける判断の分かれ目

IPA「非機能要求グレード2018」は非機能要求を6大項目に整理しています。可用性、性能拡張性、運用保守性、移行性、セキュリティ、システム環境エコロジー。このうち全ストーリーに一律で効くものは、完成の定義に入れます。入力値の検証、認可チェック、ログ出力の形式。ストーリーごとに満たすべき最低ラインとして扱う対象です。

一方、構造そのものを決める要求は独立したストーリーとしてバックログ上位に置きます。同時接続数の上限、ディザスタリカバリの目標復旧時間、監査ログの保存年数。これらは後から差し込むとデータベース設計やインフラ構成の作り直しにつながるため、リリース1に含めるかどうかを初期に判断します。

分かれ目は「後から足せるか」の一点。足せるものは完成の定義へ、構造を決めるものは上位ストーリーへ。この振り分けを曖昧にしたまま進めると、負荷試験を実施した終盤で性能が出ず、費用が想定を超えます。

IPAアジャイル開発版モデル契約が準委任を前提にする理由と発注側の責任

IPAは2020年3月31日に「情報システム・モデル取引・契約書（アジャイル開発版）」を公開しました。準委任型を基本に置き、ユーザ企業とベンダ企業が協働で作業を行う枠組みと、双方の権利義務を定める内容です。同じ年の2020年12月22日には、第二版の「情報システム・モデル取引・契約書」も公表されています。

準委任が前提になる理由は明快で、完成すべき成果物の範囲を契約時点で確定できないからです。請負契約は仕事の完成に対して対価を払う契約であり、範囲が動くことを前提にした開発とは噛み合いません。範囲が動くたびに契約変更の交渉が挟まり、反復の速度が落ちます。

この形式では、発注側にも責任が生じます。プロダクトオーナーとしての意思決定、優先順位の確定、レビューへの参加。発注側が「発注したので後は任せる」姿勢を取ると、準委任の枠組みそのものが機能しません。契約形式の選択は、発注側の関与量の宣言でもあります。

予算枠を固定してスコープを可変にする合意が成立する条件と失敗例

アジャイル型の予算は、金額と期間を固定し、その中に収めるスコープを可変にする形で合意します。実現できる条件は2つ。優先順位を決める権限が発注側の1人に集約されていること、そして「入らなかった下位ストーリーは作らない」という判断を受け入れられることです。

失敗するのは、予算もスコープも固定するケース。全機能を作ることが決まっているなら、それは要件が確定しているということであり、アジャイル型を選ぶ理由がありません。この状態で反復開発の形式だけを導入すると、スプリントごとの締切が増えるだけで、変更に対応する余地は生まれません。

もうひとつの失敗が、下位ストーリーの切り捨てを終盤まで先送りする運用です。残り2スプリントの時点で未着手が30件あれば、それは全て作らないと決める場面。判断を遅らせるほど、優先度の低い機能に開発時間が流れます。

アジャイル型の要件定義を採用しない方がよい案件条件と現実的な折衷案

ここまで進め方を書いてきましたが、アジャイル型が向かない案件は確実にあります。条件を絞って言い切ります。

法令・制度で要件が外から固定される案件でアジャイルを見送る条件

要件の決定権が発注側にない案件では、アジャイル型を採用しません。法令改正への対応、業界標準の様式に沿った帳票、監督官庁への届出システム。これらは仕様が外部で確定しており、優先順位を並べ替える余地がありません。

この種の案件でアジャイル型を選ぶと、確定済みの要件をわざわざストーリーに割り、リファインメントの時間をかけて再確認する作業が発生します。要件定義書を1回で書き切る方が、工数も期間も短く済む。施行日という動かせない締切がある以上、スコープを可変にする前提も成立しません。

判断の基準は、要件を変える権限が誰にあるか。発注側が変えられないなら、確定型の進め方を選びます。

発注側にプロダクトオーナーを置けない体制で起きる典型的な失敗パターン

アジャイル型は、発注側に週単位で判断する人を必要とします。この役を置けない体制で始めると、3つの形で破綻します。第一に、優先順位が決まらずバックログが並び替えられないまま滞留する。第二に、スプリントレビューで承認が下りず、次スプリントが空転する。第三に、判断が遅れた分を埋めるためベンダ側が仕様を推測し、レビューで作り直しになります。

兼務でも構いませんが、週に半日以上をこの役に割けるかどうかが目安です。割けないなら、アジャイル型は選ばない方が結果的に安く済みます。アジャイル開発が失敗する原因を見ても、体制側の要因は技術的な要因より頻度が高く現れます。

「担当者を決めた」だけでは足りません。決めた人が意思決定の権限と時間の両方を持っているかまで確認してください。

前半をウォーターフォール型にする折衷が現実解になる案件の見分け方

実務でもっとも多いのは、全体をどちらかに寄せない形です。業務要件と非機能要件は確定型で1回書き切り、画面と機能の詳細だけを反復で詰める。基幹システムの刷新など、業務そのものは既に決まっていて、画面の使い勝手に不確実性が集中する案件では、この折衷が現実解になります。

見分ける基準は、不確実性がどこにあるかの一点です。業務フロー自体が固まっていないなら全体をアジャイル型に。業務は固まっていて画面と操作性だけが未確定なら、前半を確定型で処理した方が速い。不確実性の所在と、反復を回す範囲を一致させます。

どちらの形を取るにせよ、発注側だけで進め方を設計するのは負荷が高い作業です。要件の切り分けから反復の設計までを含めて相談したい場合は、業務用・Webアプリ開発の受託で案件の性質に応じた進め方から検討できます。

よくある質問

アジャイル型の要件定義について、発注側から寄せられることの多い質問をまとめました。

アジャイル開発では要件定義書を作らなくてもよいのですか？

単一の要件定義書という形では作らないことが多いものの、記録自体は必ず残します。プロダクトバックログのアイテム、各ストーリーの受け入れ基準、チーム共通の完成の定義。この3つが、ウォーターフォール型の要件定義書に相当する役割を担います。社内の承認や監査で文書が必要な場合は、これらを出力してまとめる形で対応できます。文書をゼロにする方式ではありません。

要件定義にかける期間はどのくらいが目安ですか？

初期に行うステップ1から4までであれば、2週間から1か月程度に収める案件が多く見られます。ここで全機能を詳細化しようとすると数か月かかり、アジャイル型を選んだ意味が失われます。初期に必要なのは、プロダクトゴールとリリース単位の切り出し、そして最初の1〜2スプリント分の受け入れ基準まで。残りはリファインメントで継続的に詰めていく配分です。

ユーザーストーリーと機能要件はどう対応させますか？

ユーザーストーリーは機能要件と1対1では対応しません。1つのストーリーが複数の機能にまたがることも、1つの機能が複数のストーリーに分割されることもあります。対応づけが必要な場合は、ストーリーの受け入れ基準を機能要件の記述として扱う形が実務的です。非機能要件についてはストーリーに紐づかないため、完成の定義または独立したストーリーとして別枠で管理します。

途中で要件が増えたとき、追加費用はどう扱いますか？

予算枠を固定してスコープを可変にする契約であれば、追加費用は発生せず、代わりに下位のストーリーが枠から押し出されます。増えた要件を上位に入れるか、既存の優先順位を維持するかをプロダクトオーナーが判断する形です。枠そのものを広げる場合は契約の変更になります。準委任型のモデル契約はこの前提で作られており、変更のたびに個別の見積り交渉を挟む運用にはなりません。

ウォーターフォールで作った要件定義書をアジャイルに移行できますか？

移行できます。既存の要件定義書の機能一覧を、ユーザーの行動軸で並べ直してストーリーマップを作る手順が一般的です。ただし、そのまま項目をバックログに転記するだけでは順序をつけられません。誰のどの価値のための機能かという情報が要件定義書には残っていないためです。移行時は、機能一覧を分解して価値の観点を補う作業が発生する点を見込んでおいてください。

関連記事

• アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説：アジャイル開発そのものの定義とスクラムの基本を扱っています。
• 要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説：確定型を含む要件定義工程の全体像をまとめています。
• ウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分け：手法そのものの比較と選び分けの基準を整理しています。
• 要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説：文書の記載項目と章立ての型を具体的に示しています。
• アジャイル開発が失敗する5つの原因｜失敗率268%の読み方：体制と運用に起因する失敗の要因を数値とともに扱っています。