アジャイル開発でプロジェクトを始めようとするとき、最大の壁になるのが「要件定義とRFP（提案依頼書）をどう書くか」という問題です。従来のウォーターフォールでは、作るものを仕様書で細かく固定し、それを請負契約で発注するのが定石でした。しかしアジャイルは、要件が動くことを前提に進める手法です。仕様を固定するこれまでのやり方をそのまま持ち込むと、アジャイルの柔軟さが殺され、形だけの導入に終わってしまいます。要件定義とRFPの設計こそ、アジャイル成功の分かれ目です。
本記事は、アジャイル開発における要件定義書・RFP・提案依頼書の作り方を、発注側の視点から掘り下げる「要件定義特化」の解説です。仕様ではなくユーザーストーリーで要件を表現する方法、RFPで「作るモノ」ではなく「専門人材の能力と工数」を調達する考え方、要件の変化に対応するための予算の機動的調整枠の設け方、そして準委任契約での発注者の完成リスクをどう抑えるかまで、一次データとあわせて具体的に解説します。なお、アジャイル開発の全体像をまだ把握していない方は、まずアジャイル開発の完全ガイドから読むことをおすすめします。
仕様ではなくユーザーストーリーで要件を定義する
アジャイルの要件定義が従来と決定的に異なるのは、要件の表現方法です。ウォーターフォールでは「画面に項目Aと項目Bを配置し、ボタンを押すと処理Cを実行する」といった具体的な仕様を最初に固めます。これに対しアジャイルでは、「誰が・何のために・何をしたいか」というユーザーストーリーの形で要件を表現します。実装の詳細ではなく、達成したい価値を先に定義するのです。
ユーザーストーリーの書き方と受け入れ条件
ユーザーストーリーは、「ある利用者として、ある目的のために、ある機能がほしい」という構造で書きます。たとえば「経理担当者として、月次処理を早く終わらせるために、請求データを一括で取り込みたい」といった形です。ここで重要なのは、実装方法を指定しないことです。一括取り込みをどう実現するかは開発チームが考える領域であり、要件としては「何を達成したいか」だけを定義します。これにより、よりよい実現方法が見つかれば柔軟に採用できます。
ただし、価値だけを書いて終わりにすると、何をもって完成とするかが曖昧になります。そこで各ストーリーには「受け入れ条件」を添えます。これは「この条件を満たせば、このストーリーは完成とみなす」という合意で、完成の定義（DoD）と並んで品質の歯止めになります。受け入れ条件を明確にしておけば、開発の自由度を保ちながら、成果物が期待からずれることを防げます。アジャイルの要件定義は、価値の定義と受け入れ条件の組み合わせで成り立っています。
優先順位づけを要件定義の中心に置く
アジャイルの要件定義では、すべての要件を網羅的に書き出すことよりも、優先順位をつけることが重要です。限られた期間と予算のなかで、どのストーリーから着手するかを決める判断が、プロジェクトの成果を左右します。優先順位はビジネス価値とリスク、依存関係をもとに決め、リファインメントで継続的に見直します。要件定義書は、固定された全体仕様ではなく、優先順位づけされた生きたリストとして設計するのが基本です。
この優先順位づけの権限を誰が持つかも、要件定義段階で明確にしておく必要があります。アジャイルでは、ビジネス価値の観点から優先順位を決めるプロダクトオーナーの役割が極めて重要です。この役割が曖昧だと、関係者全員の要望が並列に積み上がり、何から作るべきかが決まらなくなります。要件定義の段階で「誰が最終的に優先順位を決めるのか」を定めておくことが、後の混乱を防ぎます。なお、要件をバックログとして管理し優先順位を制御する仕組みは、アジャイルが提供する機能の中核でもあります。詳しくは『アジャイル開発の必要機能・標準機能の一覧について』もあわせてご覧ください。
RFPで「人材の能力と工数」を調達する考え方
アジャイル開発のRFP（提案依頼書）が、従来のRFPと根本的に異なるのは調達の対象です。ウォーターフォールのRFPは「この仕様の完成物をいくらで作れるか」を問います。一方アジャイルのRFPは、「不確実なテーマに対して、優先順位を見極めながら作り続けられる専門人材を、一定期間どれだけの工数で提供できるか」を問います。完成物ではなく、変化に対応できる人材の能力と工数を調達するのです。
能力を評価するRFPの記載項目
人材の能力を調達するRFPでは、記載すべき項目が従来と変わります。完成物の仕様の代わりに、解決したいビジネス課題、プロジェクトの背景と目的、求める人材のスキルセットと経験、想定するチーム構成と期間、評価したい実績などを明記します。提案を受ける側も、「どんな成果物をいくらで作る」ではなく、「どんなチームでどう進めるか、過去にどんな不確実なプロジェクトを成功させたか」を提示することになります。
人材の能力を評価する以上、提示される単価の相場感を持っておくことも重要です。2026年の目安として、スクラムマスターは月60〜90万円、アジャイルコーチは月80〜120万円、スクラム経験のあるPMは月80〜130万円、スクラム経験のあるフルスタックエンジニアは月70〜100万円とされます。RFPでこれらの役割をどう組み合わせるかを示し、提案側の体制と単価を比較できるようにしておくと、調達の判断がしやすくなります。
東京都の準委任調達モデルに学ぶRFP設計
人材の能力と工数を調達するRFPの実例として参考になるのが、東京都の準委任調達モデルです。東京都は2021年ごろから準委任契約でアジャイル調達を進め、稼働を分単位で管理し、実際の工数に応じて単価で清算する仕組みを整えました。これは「完成物を固定価格で買う」のではなく「専門人材の稼働を時間単位で調達する」発想であり、要件が動いても契約をやり直す必要がありません。2022年には複数のプロジェクトを成功させています。
この調達モデルが優れているのは、税金の使途として説明責任を果たせる透明性を保ちながら、アジャイルの柔軟さを実現している点です。稼働を分単位で記録し、単価で清算するルールを明文化することで、「何にいくら使ったか」が明確になります。民間企業がアジャイルのRFPを設計する際も、この「稼働の透明化と清算ルールの明文化」は応用できます。完成物を固定できないアジャイルだからこそ、稼働の見える化と精算の納得感が、発注者の安心につながります。
準委任契約と予算の機動的調整枠の設計
アジャイルの要件定義とRFPは、契約形態と予算の設計とセットで考える必要があります。アジャイルでは、要件が動くことを前提とするため、完成物を固定価格で約束する請負契約はなじみません。代わりに、専門人材の稼働を一定期間調達する準委任契約が選ばれます。ただし準委任には、発注者が完成リスクを負うという特有の不安が伴います。この不安をどう設計で抑えるかが、アジャイル契約の肝です。
基本契約と個別契約を分けるモデル
準委任での完成リスクへの不安を和らげる方法の一つが、基本契約と個別契約を分けるモデルです。まず基本契約で、進め方・体制・単価・成果物の扱いといった全体のルールを取り決めます。そのうえで、一定期間（たとえば数か月や数スプリント）ごとに個別契約を結び、その期間で取り組む優先順位の高いストーリー群と予算を合意します。これにより、長期の完成を約束せずとも、短い区切りで成果を確認しながら次に進めます。
このモデルの利点は、発注者が各区切りで「続けるか、方針を変えるか」を判断できることです。最初の区切りで期待した成果が出なければ、次の個別契約を結ぶ前に体制や進め方を見直せます。完成までを一括で契約する請負と違い、小さく区切ることでリスクを分散できるのです。準委任の完成リスクは、契約を小さく区切り、各区切りで成果を確認する設計によって、実務上は十分に管理可能になります。契約形態の選び方や判断基準については、メリット・デメリットの観点もあわせてご覧ください。
予算の機動的調整枠を要件定義に盛り込む
アジャイルの予算設計で見落とされがちなのが、変化に対応するための機動的な調整枠です。要件が動くことを前提とする以上、当初の想定にない優先順位の高いストーリーが、開発の途中で生まれることは避けられません。これに対応できる予算の余白を、あらかじめ枠として確保しておくのが賢明です。すべての予算を当初計画に固定してしまうと、いざ重要な変更が必要になったときに、契約や稟議のやり直しで身動きが取れなくなります。
この調整枠は、無制限の追加予算という意味ではありません。あらかじめ一定の範囲を「変化対応のための枠」として定義し、その範囲内であれば、プロダクトオーナーの判断で優先順位を入れ替えたり、新たなストーリーを取り込んだりできるようにします。枠を超える場合は改めて承認を得る、というルールにしておけば、統制を保ちながら機動性も確保できます。要件定義の段階で「変化はかならず起きる」と認め、その対応枠を予算に組み込んでおくことが、アジャイルを現実的に運用する鍵になります。
まとめ
アジャイル開発の要件定義とRFPを振り返ると、その本質は「完成物の仕様を固定する」発想から「価値を定義し、人材の能力を調達し、変化に追従する設計をする」発想への転換にあります。要件はユーザーストーリーと受け入れ条件で表現し、RFPでは専門人材の能力と工数を問い、準委任契約を基本・個別に分けて完成リスクを分散し、予算には変化対応の調整枠を持たせます。東京都の準委任調達モデルは、稼働を分単位管理・単価清算する形で、この発想を行政でも実現できることを示しました。
アジャイルの要件定義で最も避けるべきは、ウォーターフォールの仕様固定をそのまま持ち込むことです。要件が動く前提に立ち、契約と予算まで含めて柔軟に設計すれば、変化を脅威ではなく強みに変えられます。スクラムマスターやアジャイルコーチの単価相場を踏まえ、人材の能力を調達するRFPを組み立てることが、その出発点です。riplaはフルスクラッチ受託と準委任の伴走で、アジャイル型の要件定義とRFP設計を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。