スクラム開発を発注しようとするとき、多くの担当者が最初に直面する難問が「要件を固定しないスクラムで、いったい何をRFP（提案依頼書）に書き、何を要件定義書にまとめればよいのか」という疑問です。従来のウォーターフォール開発では、作るモノの仕様を細部まで固めてから発注するのが常識でした。しかしスクラムは、要件が動くことを前提とし、優先度の高いものから作りながら適応していく手法です。仕様を固定して発注するという従来の作法をそのまま持ち込むと、スクラムの柔軟性は契約と要件定義の段階で殺されてしまいます。
本記事は、スクラム開発における要件定義とRFPの作り方を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。仕様書ではなくユーザーストーリーで要件を定義する方法、RFPで「作るモノ」ではなく「専門人材の能力と工数」を調達する考え方、予算を機動的に調整できる枠を契約に盛り込む工夫、そして準委任契約での発注者の不安をどう解消するかまで、一次データとあわせて掘り下げます。この領域は競合記事が手薄で、スクラム発注を成功させるうえで最も重要な勘所です。なお、スクラム開発の全体像をまだ把握していない方は、まずスクラム開発の完全ガイドから読むことをおすすめします。
仕様書でなくユーザーストーリーで要件を定義する
スクラムの要件定義で最初に切り替えるべきは、「機能を漏れなく仕様書に書き切る」という発想です。スクラムでは、要件をユーザーストーリーという形式で記述します。これは「（誰）として、（何のために）、（何をしたい）」という利用者視点の短い文で価値を表現する方法で、機能の詳細仕様ではなく「達成したいこと」を起点に置きます。仕様を固定せず価値を定義するこの方法こそ、変化に追従できるスクラムの要件定義の土台です。
ユーザーストーリーと受け入れ基準の書き方
ユーザーストーリーは、たとえば「経理担当者として、月末の締め作業を早く終えるために、請求データを一括出力したい」というように、利用者・目的・行いたいことの三要素で記述します。ここで重要なのは、実装方法を指定しないことです。どう作るかは開発チームに委ね、発注者は「なぜそれが必要で、どんな価値を生むのか」を明確にすることに集中します。これにより、開発が進む中でより良い実現方法が見つかれば、柔軟に取り入れられます。
ただし、ユーザーストーリーだけでは「どこまでできたら完成か」が曖昧になります。そこで各ストーリーには受け入れ基準（Acceptance Criteria）を添えます。受け入れ基準は「この条件を満たせば、このストーリーは完成とみなす」という合意であり、たとえば「指定した期間の請求データがCSV形式で出力できること」といった検証可能な条件を列挙します。ストーリーで価値を、受け入れ基準で完成条件を定義する。この二段構えが、仕様を固定せずとも品質と認識のズレを防ぐ仕組みになります。スクラムの作成物としてのプロダクトバックログの役割は『スクラム開発の必要機能や標準機能の一覧について』もあわせてご覧ください。
プロダクトバックログとして優先順位を定義する
個々のユーザーストーリーは、優先順位順に並べてプロダクトバックログとしてまとめます。スクラムの要件定義は、この「優先順位を含めて定義する」点が従来と大きく異なります。すべての要件を平等に扱うのではなく、ビジネス価値の高いもの、不確実性の高いもの、依存関係の前提になるものを上位に置き、上から順に作っていきます。これにより、予算や期間が限られても、最も価値の高い部分を確実に手に入れられます。
要件定義の段階で完璧なバックログを作る必要はありません。上位の項目は実装できる粒度まで詳細に、下位の項目はざっくりとした粒度で記述し、開発の進行に合わせて随時詳細化していきます。これはバックログリファインメントと呼ばれる継続的な活動です。最初にすべてを固めようとして時間を浪費するのではなく、「優先度の高いものだけを今わかる範囲で詳しくする」という割り切りが、スクラムの要件定義のスピードと柔軟性を生みます。発注前に全要件を確定させる必要がない点は、発注者にとって大きな利点です。
RFPで「作るモノ」でなく「能力と工数」を調達する
スクラムのRFPで最も重要な発想の転換が、調達対象を「成果物」から「専門人材の能力と稼働」へ移すことです。ウォーターフォールのRFPは「この仕様のシステムをいくらで作れますか」を問いますが、スクラムのRFPは「スクラムを回せる専門人材を、どのような体制で、どれだけの期間提供できますか」を問います。作るモノを固定しない以上、調達するのは完成品ではなく、価値を生み出し続ける能力そのものになります。
RFPに記載すべき人材要件と体制の評価軸
能力を調達するRFPでは、求める人材の役割と経験を具体的に記載します。スクラムマスター、アジャイル経験のあるプロジェクトマネージャー、フルスタックエンジニアといった役割ごとに、必要な経験年数やスクラムでの実績を問います。市場の単価相場を踏まえると、2026年時点でスクラムマスターは月60〜90万円、アジャイルコーチは月80〜120万円、スクラム経験のあるPMは月80〜130万円、スクラム経験のあるフルスタックエンジニアは月70〜100万円が一つの目安です。この相場を理解しておくと、提案の妥当性を判断できます。
評価軸としては、個々のスキルだけでなく「チームとして自己完結できるか」を重視します。スクラムの開発チームは、外部に依頼せずスプリント内で機能を完成させられるクロスファンクショナルな体制が理想です。設計・実装・テストを内製できる構成になっているか、スクラムマスターが専任で配置されるか、といった体制面を評価することが、提案の質を見極める鍵になります。安い単価だけで選ぶと、肝心のスクラム運営力が伴わず失敗するため、能力と体制の両面を慎重に評価してください。
準委任契約を前提としたRFPの組み立て方
能力を調達するRFPは、契約形態として準委任契約を前提に組み立てます。準委任契約は、特定の成果物の完成ではなく、専門的な業務の遂行そのものを対価の対象とする契約です。要件が動くスクラムでは、成果物を事前に確定できないため、完成責任を負う請負契約は本質的になじみません。RFPの段階で準委任を前提と明示しておくことで、提案者も適切な体制と見積もりを組めます。
実際、東京都は2021年から準委任契約によるアジャイル・スクラムの調達を進め、2022年に複数のプロジェクトで成果を上げました。公共調達という最も保守的な領域でも、準委任を前提とすればスクラムが成立することを示した好例です。RFPでは、契約形態に加えて、スプリントの長さ、レビューやデモの頻度、発注者側のプロダクトオーナーの関与方法といった「進め方のルール」も明記しておくと、認識のズレを防げます。なお、契約形態が請負か準委任かという判断は、メリット・デメリットの観点でも重要なため『スクラム開発のメリット・デメリット・効果と判断基準について』もあわせてご覧ください。
予算を機動的に調整できる枠を設計する
スクラムの要件定義とRFPでもう一つ重要なのが、予算の考え方です。要件を固定しない以上、総額を一円単位で固定する従来型の予算管理はスクラムと相性が悪く、機動的に調整できる枠として予算を設計する必要があります。これは「青天井で使う」という意味ではなく、上限を定めつつ、その範囲内で優先順位に応じて柔軟に配分する、という発想です。
上限を定めつつ優先順位で配分する予算枠
機動的な予算枠の基本は、「投入する人材と期間で上限を定め、その中で何を作るかは優先順位に応じて決める」という考え方です。たとえば「この体制で6か月」という枠を設定し、その期間内でプロダクトバックログの上位から順に消化していきます。期間という上限が予算の上限になるため、総額は制御できます。一方で、何を作るかはスプリントごとに調整できるため、市場の変化や新たな発見に柔軟に対応できます。
この方式の利点は、価値の高いものから作るため、たとえ予算枠を使い切っても、最も重要な機能は手元に残ることです。ウォーターフォールでは、全機能の完成を前提に予算を組むため、途中で予算が尽きると何も使えないものが残るリスクがあります。スクラムの予算枠は、常に「動くもの」が積み上がっているため、どの時点で打ち切っても投資が無駄になりにくい構造です。この特性をRFPと社内の予算稟議の両方で説明できると、機動的な予算枠への理解が得やすくなります。
ハイブリッド型で予算統制と柔軟性を両立する
とはいえ、組織の予算制度が完全な機動的予算枠を許容しないケースは多々あります。その場合は、上流の要件定義や全体構想は固定的に進め、その後の実装をスクラムで回すというハイブリッド型が現実的です。最初に大枠の方向性とおおよその予算規模を固め、その範囲内でスクラムの柔軟性を活かす。この折衷案であれば、既存の予算稟議のプロセスとも折り合いをつけやすくなります。
ハイブリッド型を採る際の注意点は、固定部分と柔軟部分の境界を明確にすることです。どこまでを事前に固め、どこからをスクラムで動かすのかが曖昧だと、結局すべてを固定しようとする力が働き、スクラムの利点が失われます。RFPと要件定義の段階で「ここから先は優先順位で動かす」という線引きを明示し、関係者の合意を得ておくことが、ハイブリッド型を機能させる鍵です。組織の予算制度の実情に合わせて、固定と柔軟のバランスを設計してください。
準委任での発注者の完成リスク不安を解消する
準委任契約を前提にスクラムを発注しようとすると、必ず社内から出るのが「完成責任がないのに発注して大丈夫なのか」という不安です。請負契約に慣れた組織にとって、成果物の完成を保証されない準委任は心理的なハードルが高いものです。この不安にどう向き合い、どう解消するかが、スクラム発注を社内で通すうえでの最大の関門になります。
稼働の可視化と分単位管理で透明性を担保する
準委任の不安を解消する最も効果的な方法は、稼働とアウトプットの透明性を高めることです。東京都は、準委任で調達したスクラム開発において、稼働を分単位で管理し単価で清算する仕組みを取り入れました。投じた時間と、その対価として何が生まれたかを可視化することで、「完成責任がない＝成果が見えない」という懸念を払拭したのです。透明性は、準委任の不安に対する最も実務的な処方箋です。
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を創業。