スクラム開発のRFPには、作るモノの仕様ではなく、専門人材の能力と工数を調達する条件を書きます。要件定義書には、ユーザーストーリーと受け入れ基準で要件を書きます。
従来の作法どおり仕様を固定して発注すると、スクラムの柔軟性が失われます。この領域は解説が手薄ですが、スクラム発注を成功させるうえで最も重要な勘所です。全体像を把握していない方は、まずスクラム開発の完全ガイドから読むことをおすすめします。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ユーザーストーリーによる要件定義
スクラムの要件定義で最初に切り替えるのは、機能をすべて仕様書に書き切るという発想です。スクラムでは、要件をユーザーストーリーという形式で書きます。
ユーザーストーリーは、「（誰）として、（何のために）、（何をしたい）」という利用者視点の短い文で価値を表す方法です。機能の詳細仕様より先に、達成したいことを起点に置くのが特徴です。
仕様を固定せずに価値を定義するこの方法は、変化に追従できるスクラムの要件定義の土台になります。
ユーザーストーリーと受け入れ基準の書き方
ユーザーストーリーは、利用者、目的、行いたいことの三要素を一文にまとめて記述します。たとえば「経理担当者として、月末の締め作業を早く終えるために、請求データを一括出力したい」のような形です。
ここで重要なのは、実装方法を指定しないことです。どう作るかは開発チームに任せ、発注者は、なぜそれが必要で、どんな価値を生むのかを明確にすることに集中します。これにより、開発の途中でより良い実現方法が見つかれば、柔軟に取り入れられます。
ただし、ユーザーストーリーだけでは、どこまでできたら完成かが曖昧になります。そこで、各ストーリーに受け入れ基準（Acceptance Criteria）を添えます。
受け入れ基準は、「この条件を満たせば、このストーリーは完成とみなす」という合意です。たとえば「指定した期間の請求データがCSV形式で出力できること」のように、検証できる条件を列挙します。
ストーリーで価値を示し、受け入れ基準で完成の条件を定めます。この二段構えによって、仕様を固定しなくても、品質と認識のズレを防げます。
プロダクトバックログの役割については、『スクラム開発の必要機能や標準機能の一覧について』もあわせてご覧ください。
- 利用者と目的：誰のための、何のための要求かが一文で読めるか
- 完成の条件：検証できる形で列挙された受け入れ基準
プロダクトバックログによる優先順位付け
個々のユーザーストーリーは、優先順位の順に並べてプロダクトバックログとしてまとめます。スクラムの要件定義は、この優先順位まで含めて定義する点が従来と異なります。
すべての要件を平等に扱うのではなく、上位から順に作っていきます。優先順位順に並べた項目ごとに、プロダクトを確認しながら進めます。これにより、予算や期間が限られていても、最も価値の高い部分を確実に手に入れられます。
要件定義の段階で完璧なバックログを作る必要はありません。上位の項目は実装できる粒度まで詳しく書き、下位の項目はざっくりとした粒度で記述します。
開発の進行に合わせて随時詳細化していくこの継続的な活動は、バックログリファインメントと呼ばれます。最初にすべてを固めて時間を浪費するのではなく、進めながら詳しくしていく考え方です。
優先度の高いものだけを今わかる範囲で詳しくするという割り切りが、スクラムの要件定義のスピードと柔軟性を生みます。発注前に全要件を確定させる必要がない点は、発注者にとって大きな利点です。
- ビジネス価値：事業や利用者にとっての価値が大きい項目
- 不確実性と依存関係：中身がまだ読めない項目や、ほかの前提になる項目
能力と工数を調達するRFP
スクラムのRFPで最も大きく変わるのは、調達するものを成果物から、専門人材の能力と稼働へ移すことです。
ウォーターフォールのRFPは「この仕様のシステムをいくらで作れますか」を問います。一方でスクラムのRFPは、「スクラムを回せる専門人材を、どのような体制で、どれだけの期間提供できますか」を問います。
作るモノを固定しない以上、調達するのは完成品ではなく、価値を生み出し続ける能力そのものになります。
RFPに記載すべき人材要件と体制の評価軸
能力を調達するRFPでは、求める人材の役割と経験を具体的に記載します。スクラムマスター、アジャイル経験のあるプロジェクトマネージャー、フルスタックエンジニアといった役割ごとに、必要な経験年数やスクラムでの実績を問います。
市場の単価相場を踏まえると、2026年時点ではスクラムマスターが月60〜90万円、アジャイルコーチが月80〜120万円、スクラム経験のあるPMが月80〜130万円です。また、スクラム経験のあるフルスタックエンジニアは、月70〜100万円が一つの目安になります。この相場を知っておくと、提案の妥当性を判断できます。
評価軸として重視したいのは、個々のスキルだけでなく、チームとして自己完結できるかどうかです。スクラムの開発チームは、外部に頼らずスプリント内で機能を完成させられる、クロスファンクショナルな体制が理想です。
設計・実装・テストを提案側の体制で完結できる構成か、スクラムマスターが専任で配置されるかといった体制面を評価することが、提案の質を見極める鍵になります。安い単価だけで選ぶと、肝心のスクラム運営力が伴わず失敗につながるため、能力と体制の両面を慎重に評価してください。
- 役割ごとの経験：スクラムマスターやPMなど、役割ごとの経験年数と実績
- 単価と体制の釣り合い：相場と照らして、単価が体制の中身に見合うか
準委任契約を前提としたRFPの組み立て方
能力を調達するRFPは、契約形態として準委任契約を前提に組み立てます。準委任契約は、特定の成果物の完成ではなく、専門的な業務の遂行そのものを対価の対象とする契約です。
要件が動くスクラムでは成果物を事前に確定できないため、完成責任を負う請負契約はなじみません。RFPの段階で準委任を前提と明示しておけば、提案者も適切な体制と見積もりを組めます。
実際に東京都は、2021年から準委任契約によるアジャイル・スクラムの調達を進め、2022年には複数のプロジェクトで成果を上げました。公共調達という最も保守的な領域でも、準委任を前提にすればスクラムが成り立つことを示した好例です。
RFPには契約形態に加えて進め方のルールも明記しておくと、認識のズレを防げます。
契約形態が請負か準委任かの判断は、メリット・デメリットの観点からも重要です。『スクラム開発のメリット・デメリット・効果と判断基準について』もあわせてご覧ください。
- 契約形態：準委任契約であることを、RFPの段階で明示する
- 進め方のルール：スプリントの長さ、レビューやデモの頻度、発注者側のプロダクトオーナーの関与方法
機動的に調整できる予算枠の設計
スクラムの要件定義とRFPで、もう一つ重要なのが予算の考え方です。
要件を固定しない以上、総額を一円単位で固定する従来型の予算管理はスクラムと相性が悪いため、機動的に調整できる枠として予算を設計する必要があります。
機動的な予算とは、上限を定めつつ、その範囲内で優先順位に応じて柔軟に配分するという発想です。「青天井で使う」という意味ではありません。
上限を定めつつ優先順位で配分する予算枠
機動的な予算枠の基本は、上限を先に決め、その中で動くという考え方です。たとえば「この体制で6か月」という枠を置くと、期間が上限になるため、総額を制御できます。
何を作るかは、スプリントごとに調整できるため、市場の変化や新たな発見にも柔軟に対応できます。
この方式の利点は、価値の高いものから作るため、予算枠を使い切っても最も重要な機能は手元に残ることです。
ウォーターフォールでは、全機能の完成を前提に予算を組むため、途中で予算が尽きると使えないものが残るリスクがあります。これに対してスクラムの予算枠は、常に動くものが積み上がっているため、どの時点で打ち切っても投資が無駄になりにくい構造です。
この特性をRFPと社内の予算稟議の両方で説明できれば、機動的な予算枠への理解を得られます。
- 上限の設定：投入する人材と期間で決まる、総額の上限
- 配分の順序：上限の中で、プロダクトバックログの上位から順に消化する
ハイブリッド型による予算統制と柔軟性の両立
組織の予算制度が完全な機動的予算枠を認めないケースは多く、その場合はハイブリッド型が現実的です。上流の要件定義や全体構想は固めて進め、その後の実装をスクラムで回します。
最初に大枠の方向性とおおよその予算規模を固め、その範囲内でスクラムの柔軟性を生かします。この折衷案であれば、既存の予算稟議の流れとも折り合いをつけやすくなります。
ハイブリッド型で注意したいのは、固定部分と柔軟部分の境界です。どこまでを事前に固め、どこからをスクラムで動かすのかが曖昧だと、すべてを固定しようとする力が働き、スクラムの利点が失われます。
そのため、RFPと要件定義の段階で「ここから先は優先順位で動かす」という線引きを示し、関係者の合意を得ておくことが、ハイブリッド型を機能させる鍵です。組織の予算制度の実情に合わせて、固定と柔軟のバランスを設計してください。
- 境界の線引き：固定する部分と柔軟に動かす部分を、どこで分けるか
- 関係者の合意：予算稟議を通す社内の関係者と、線引きの内容をそろえること
準委任での発注者の完成リスク不安の解消
準委任契約を前提にスクラムを発注しようとすると、必ず社内から出てくるのが「完成責任がないのに発注して大丈夫なのか」という不安です。
請負契約に慣れた組織にとって、成果物の完成を保証されない準委任は心理的なハードルが高いものです。この不安にどう向き合うかが、スクラム発注を社内で通すうえでの最大の関門になります。
稼働の把握と分単位管理による透明性の確保
準委任の不安を解消するいちばん効果的な方法は、稼働とアウトプットの透明性を高めることです。東京都は、準委任で調達したスクラム開発において、稼働を分単位で管理し、単価で清算する仕組みを取り入れました。
投じた時間と、その対価として何が生まれたかが分かるようにすると、「完成責任がない＝成果が見えない」という懸念を払拭できます。透明性は、準委任の不安に対する最も実務的な手立てです。
RFPの段階で、稼働の把握や定期的な成果報告の仕組みを契約に組み込むよう求めておくと、発注後の運用がスムーズになります。
準委任であっても、発注者は投資が適切に使われているかを継続的に検証できます。完成を保証してもらう代わりに、プロセスの透明性で安心を担保できます。これがスクラム発注の要諦です。
- スプリントレビュー：毎回、動くものを確認できる機会
- 進捗と稼働の報告：バーンダウンチャートなどで見える進捗と、稼働実績の報告
要件に含める発注者側のプロダクトオーナー関与
準委任の不安の根底には、「丸投げできない」という誤解もあります。スクラムは、発注者がプロダクトオーナーとして優先順位を判断し、レビューでフィードバックを返すことを前提とした手法です。
この関与を「負担」と見るか「コントロール手段」と見るかで、準委任への見方は変わります。発注者が主体的に関われるからこそ、作るものを途中で軌道修正でき、完成責任の有無とは別の形でプロジェクトを統制できます。
発注者側のプロダクトオーナーの役割と関与の度合いは、RFPと要件定義の段階で明確に定めておくことが重要です。この準備ができていれば、準委任でも発注者が手綱を握れます。
東京都がキックオフでアジャイルの模擬体験ワークショップを行ったのも、発注者側がこの役割を担う覚悟と理解を持つためでした。準委任の不安は、発注者自身が関与の主体になることで、本質的に解消されます。
- 担当者とレビュー参加：プロダクトオーナーを誰が担い、どの頻度でレビューに加わるか
- 意思決定の範囲：発注側が持つ決定権の上限
まとめ
スクラム開発の要件定義とRFPの核心は、作るモノを固定する発想から、価値を生み出す能力を調達する発想へ転換することです。
要件は機能仕様ではなく、ユーザーストーリーと受け入れ基準で記述します。そのうえで、優先順位を含めたプロダクトバックログとして管理します。
RFPでは専門人材の能力と稼働を調達し、準委任契約を前提に進め方のルールを明記します。予算は期間と体制で上限を定める機動的な枠とし、組織の制約が強い場合はハイブリッド型で折り合いをつけます。
そして準委任の完成リスクへの不安は、東京都の分単位管理のように稼働を見えるようにし、発注者が主体的に関与することで解消できます。
スクラムの発注は、従来のウォーターフォール型のRFP作法をそのまま持ち込むと、柔軟性が契約と要件定義の入口で失われます。価値で定義し、能力を調達し、透明性で安心を担保する。この三つを押さえれば、要件の変化を恐れずスクラムの強みを引き出せます。
ripla は、フルスクラッチ受託と準委任での伴走を通じて、能力調達型のRFPや要件定義の設計を支援しています。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。