アジャイル開発の見積｜スコープ固定できない案件の考え方

アジャイル開発の見積が「読み取りづらい」のは構造の違いから来ている

「アジャイルで開発しましょう」と提案されたものの、いざ見積を受け取ってみると「スプリント単価」「ベロシティ」「バックログ」といった見慣れない言葉が並び、総額がいくらになるのか読み取りづらい——そんな戸惑いを持つ発注担当者は少なくありません。ウォーターフォール型のように「機能一覧に対して確定金額」を出すのではなく、期間と体制に対して費用が積み上がる構造だからです。

この記事では、事業会社の発注担当者向けに、アジャイル開発の見積がどのような仕組みで成り立っているか、発注側は何を合意し、どこまでを「変動を受け入れる」領域として置いておくべきかを整理します。契約形態の選択肢や、破綻しがちな NG パターンまで踏み込んで解説するので、はじめてアジャイル案件を発注する方の判断材料として活用してください。

FIXIT

アジャイルで見積出してもらったら、スプリント単価しか書いてなくて総額が読めない。

Hayate

アジャイルは「機能 × 単価」ではなく「体制 × 期間」で組むので、そもそも総額が出しにくいんです。

FIXIT

じゃあ社内に「いくらで何ができる」って言えないの？

Hayate

「この予算枠で Must と可能な範囲の Should を作る」の伝え方のほうが実務的です。

FIXIT

それだと稟議を通せる気がしないんだけど。

Hayate

使い分けの目安は、上限予算・Must・削除可能スコープを事前に握ることです。ここが揃えば稟議は通ります。

1. なぜアジャイル開発ではウォーターフォールと同じ見積が成り立たないのか

ウォーターフォール型の見積は、要件定義書に列挙された機能を工数に換算し、その合計に単価と管理費を乗せるかたちで組み立てます。これが成り立つのは「開発開始前にスコープが固定できる」ことが前提だからです。

一方、アジャイル開発は次のような案件で選ばれます。

• 事業仮説が固まりきっておらず、ユーザー反応を見て仕様を調整したい
• 競合環境や規制が変わりやすく、半年先の仕様を確定できない
• 初期リリースは小さく、その後に段階的に機能を積み上げる方針

いずれも「先にスコープを固定できない・固定すべきでない」ケースです。ここに機能一覧ベースの確定見積を無理に当てはめると、開発途中で必ず起きる仕様変更が「追加見積」の応酬になり、発注側にも受注側にも消耗が生じます。アジャイル案件の見積は、スコープが動くことを前提に「動く範囲・動かせない範囲」を分けて設計します。

関連して、概算見積と本見積の違い も押さえておくと、精度と使い分けの理解が深まります。

2. タイムボックス見積とベロシティの基本

アジャイル案件でよく使われるのが、期間ベースの「タイムボックス見積」です。

総額 = スプリント単価 × スプリント本数 + 立上げ費用 + 予備費

スプリントとは、通常 1〜4 週間の開発サイクルを指します。1 スプリントで消化できる作業量は、チームの人数と経験で決まるため、金額は「体制 × 期間」に近いかたちになります。

スプリント単価の構成

スプリント単価は、参加メンバー (PM / エンジニア / デザイナー / QA) の人月単価を、スプリント長で按分して合算した金額です。例えば 2 週間スプリントで、次の体制なら次のとおりです。

ロール	人月単価	2 週間換算
PM 0.5 人	130 万円	32.5 万円
エンジニア 2 人	各 100 万円	100 万円
デザイナー 0.5 人	100 万円	25 万円
QA 0.3 人	90 万円	13.5 万円

このケースでは 1 スプリントあたり約 170 万円、6 スプリント (3 か月) で 1,020 万円が体制費として積み上がります。ここに立上げ費用や環境費、予備費が加算されます。

ベロシティの概念

ベロシティは「1 スプリントでチームが消化できる作業量」を指す指標です。ストーリーポイントなど独自単位で表現され、序盤の数スプリントで実測してから、以後のリリース予測に使います。発注段階では確定させられないため、「初期見積では想定ベロシティを置き、3 スプリント後に見直す」といった扱いをします。

3. MVP 見積の考え方——優先度と削除可能スコープ

タイムボックス見積は「期間分の費用」を示せますが、それだけでは発注側は「その期間で本当に必要な機能が完成するのか」を判断できません。そこで併用されるのが、MVP と優先度をベースにしたスコープ見積です。

全機能ではなく Must から並べる

要望を全部並べて工数を積むのではなく、次のような優先度別のバックログを作ります。

• Must: ローンチ時に必ず必要な機能
• Should: あると事業価値が上がるが後回し可能な機能
• Could: 余力があれば入れたい機能
• Won't: 今回はやらないと明示的に合意する機能

見積提示時には、「Must を入れると◯スプリント、Should まで含めると◯スプリント」というかたちで幅を持たせて提示するのが実態に合った出し方です。

削除可能スコープを最初から設計する

アジャイル案件では、開発中に「思ったより時間がかかる」「新たな要望が優先度を持ち上げてくる」という事態が必ず起きます。このとき「先に決めた機能はすべて完成させる」を守ろうとすると、必ず期間か品質が崩れます。

そこで、あらかじめ「削除可能スコープ」を合意しておきます。締切と Must は守り、それ以外は状況に応じて外せる、という約束です。この考え方の詳細は MVP 開発の見積 でも扱っています。

4. 発注側が「合意すべきこと」と「合意できないこと」

アジャイル案件で発注担当者がまず整理すべきなのは、「何は最初に決められて、何は決められないか」を明示することです。

合意すべきこと (動かない領域)

• 総予算の上限 (例: 初期 3 か月で 1,000 万円を上限)
• チーム体制 (人数・ロール構成)
• スプリント長と定例のリズム
• ゴールとなる事業指標 (例: MVP で検証したい KPI)
• Must に位置付ける最低限の機能
• 受け入れ判定を行う担当者と権限範囲

合意できないこと (動く領域)

• Should 以下の機能が最終的にどれだけ入るか
• 個別機能の細かい仕様 (開発中にユーザー検証で決まる)
• ローンチ後のフェーズ 2 で何を作るか

この線引きを見積提示時に文書化しておくと、後工程で発生する仕様調整が「合意違反」ではなく「想定内の変動」として扱えます。

5. 契約形態の選択肢——準委任・成果基準の請負・ハイブリッド

アジャイル案件を契約書に落とし込むとき、選択肢は大きく 3 つあります。それぞれの詳細は 請負契約と準委任契約 で解説していますが、ここでは見積との関係で概観します。

準委任契約

期間・体制に対して費用が発生する契約です。スコープの変動を前提とするアジャイルとの相性がもっとも良く、実務でも多く選ばれます。発注側にとっては「期間を延ばせば費用が増える」ため、期間管理と優先度判断の責任を持つ必要があります。

成果基準の請負契約

「MVP の最低機能セットを確定金額で作る」かたちで、初期リリースだけを請負契約にする方法です。仕様変動リスクを受注側が持つため、その分バッファが積まれ単価は割高になります。事業側の要件がある程度固まっている場合には有効です。

ハイブリッド

初期リリース (要件がある程度読める部分) を請負、追加開発・改善フェーズを準委任にする組み合わせです。「まずは請負で世に出し、その後はチーム貸しで改善を回す」という設計と親和性が高く、ラボ型開発の見積構造 につなげるパターンでよく採用されます。

6. アジャイル案件で見積が破綻する NG パターン

実務で見積・費用管理が崩れる典型例を挙げておきます。同じ落とし穴を避けるためのチェックリストとして使ってください。

NG1: 機能一覧すべてに Must を付ける

優先度がついていないバックログは、実質的にウォーターフォールと同じで、期間内に収まりません。Should と Could を必ず一定割合置き、削除可能スコープを可視化しておく必要があります。

NG2: 総額の上限を握らずに走り出す

「アジャイルなので状況次第」で開始すると、稟議側で費用が説明できなくなります。期間の上限総額 (体制 × 期間) を先に確定させ、その中で機能の実現範囲を調整するのが基本です。

NG3: 発注側の意思決定担当者が固まっていない

スプリントごとの受け入れ判断が滞ると、それだけで実質的な費用が積み上がります。担当者と権限範囲を最初に明文化し、レビュー会に必ず出られる体制を敷いておくのが安全です。

NG4: Should をすべて足した見積を「最低ライン」と誤解する

上限提示と最低ラインが混在すると、社内予算に反映しづらくなります。「Must まで」「Should まで」の 2 段階提示にし、どちらが上限でどちらが目標かを明示して扱うのが実務的です。

NG5: 仕様変更ごとに個別見積を積み増す

アジャイルの理念に反するうえ、実質的にウォーターフォール的な追加見積になります。詳しくは 仕様変更・追加の見積 を参照してください。

まとめ

アジャイル開発の見積は「機能 × 単価」ではなく「体制 × 期間」で組み立てる構造です。タイムボックス見積で総額の上限を、MVP と優先度でスコープを制御し、発注側は「動かない領域」と「動く領域」を最初に線引きして合意する——この骨格を持っておけば、はじめてのアジャイル案件でも稟議側に説明が通る見積を扱えます。契約形態は準委任が第一候補、要件次第でハイブリッドや成果基準の請負を組み合わせ、破綻パターン (優先度不在・上限不在・意思決定不在) を初期合意で潰しておくのが実務のコツです。

AI 駆動開発のクリエイティブスタジオである FIXIT では、事業仮説段階の案件を、上限予算と Must スコープを握ったうえで小さく走らせるかたちで伴走しています。「アジャイルで進めたいが、社内でどう見積を通せばよいか」を相談したい方は 無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。