開発会社の提案書や打ち合わせで「スクラムで進めましょう」と言われ、意味がはっきりしないまま話が進んでいませんか。しかも見積は固定金額ではなく「工数ベースの概算」と書かれていて、社内で説明できず困っている方も多いはずです。
この記事では、まず「スクラムとは何か」を短く押さえます。そのうえで、スクラムで発注すると見積・契約・保守の判断がどう変わるのかを、発注者の立場で整理します。読み終えるころには、提案書を自社の言葉で評価し、稟議に必要な確認項目を持てる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
スクラムとは？スクラム開発を3行で理解する
スクラム（スクラム開発）とは、アジャイル開発の代表的な進め方（フレームワーク）です。 1〜4週間程度の短い期間（スプリント）で「計画→開発→確認→振り返り」を繰り返し、動くものを少しずつ作りながら優先順位を見直します。
- アジャイル開発は「変化に柔軟に対応する」という考え方、スクラムはそれを実現する具体的な型です
- 提案書にある「アジャイル開発（スクラム）」「スクラムアジャイル開発」は、ほぼ同じ意味で使われています
- 名前の由来はラグビーのスクラムで、チーム全員で一体となってボールを前に進めるイメージです
用語の基礎（スプリント、バックログ、PO など会議で出てくる言葉）だけを先に整理したい方は、スクラムとは？発注者が会議でつまずく用語をやさしく整理をご覧ください。本記事は、用語を知ったうえで「発注の判断にどうつなげるか」に絞って解説します。アジャイル開発そのものの考え方はアジャイル開発とはで詳しく紹介しています。
スクラムで発注すると何が変わる？見積・契約・保守の3つの判断
スクラムを選ぶと、ウォーターフォール型の発注で慣れた判断軸が3つ変わります。最初に全体像を押さえておきましょう。
判断項目 | ウォーターフォール型の発注 | スクラム型の発注 |
|---|---|---|
見積 | 完成形を決めて総額を固定する | 期間・チーム体制で見積もり、範囲は優先順位で調整する |
契約 | 請負契約が中心 | 準委任契約（期間・工数ベース）が相性がよい |
保守 | 納品後に別途保守契約を結ぶ | リリースを重ねながら、開発中から運用体制を作る |
発注者の関与 | 要件定義と受け入れ検収が中心 | 毎スプリントの確認・優先順位の判断が必要 |
つまりスクラムは「進め方」だけでなく、お金と責任の取り決め方まで変わる選択です。ウォーターフォールとの違いを詳しく知りたい場合は、システム開発のウォーターフォールとアジャイルの違いも参考にしてください。
【見積】スクラム開発の見積は「総額固定」ではなく「範囲を調整する」考え方
スクラムの見積で最も戸惑うのが、総額が最初に確定しない点です。ここで押さえたいのは、「金額が決まらない」のではなく「金額を固定して、範囲を調整する」という発想に変わることです。
見積の基本パターン
- 期間・体制ベース: 「エンジニア○名で1スプリント○週間、月額○円」のように、チームの稼働に対して費用が決まります
- 範囲は優先順位で調整: やりたいことを優先度順に並べ、予算と期間に収まる範囲から作ります。収まらない機能は後回しか削減します
- 途中で見直せる: 各スプリントの結果を見て、続ける・止める・範囲を変えるを判断できます
提案書の見積で確認したい質問
- 見積の前提となるチーム人数と、1スプリントあたりの費用はいくらか
- 想定する総期間と、予算上限に達したときの扱い（範囲の削減か、追加予算の相談か）
- 追加の仕様変更が出たとき、見積はどう扱われるのか（スコープ調整で吸収か、追加費用か）
- 見積の根拠となった「やること一覧（バックログ）」を見せてもらえるか
見積の見方で注意したいのは、金額の大小だけで比較しないことです。スクラム型の見積は前提（人数・期間・範囲の扱い）が会社ごとに異なるため、同じ条件にそろえて比べる必要があります。
【契約】スクラム開発は準委任？請負？契約形態の選び方
スクラム開発では、契約形態の選び方が発注者の負担とリスクを大きく左右します。
項目 | 準委任契約 | 請負契約 |
|---|---|---|
約束する内容 | 作業（チームの稼働）を提供する | 成果物の完成を約束する |
向いている進め方 | スクラムなど、途中で範囲が変わる開発 | 仕様が固まっている開発 |
費用の決まり方 | 期間・工数ベース | 総額固定 |
発注者のメリット | 変更に柔軟、優先順位を自分で決められる | 完成までの総額が読みやすい |
発注者の注意点 | 成果物の完成そのものは保証されない | 変更のたびに追加費用や再見積が発生しやすい |
スクラムは途中で範囲が変わることを前提にするため、一般には準委任契約と相性がよいとされています。ただし、準委任は「完成を約束する契約ではない」ため、発注者側に次の工夫が求められます。
- スプリントごとに成果物（動くもの）を確認し、期待とのずれを早めに伝える
- 契約書に、成果物の権利の帰属・検収の方法・中途解約の条件を明記してもらう
- 1ヶ月単位などで体制の見直しや終了ができる契約期間かを確認する
契約形態の全体像は受託開発の進め方と契約形態で解説しています。なお、スクラムだからといって請負契約が絶対にできないわけではありません。開発会社によっては「準委任でスクラム開発、確定した範囲だけ請負」といったハイブリッドの提案もあります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
【保守】スクラムはリリース後の保守・運用もつながっている
スクラムは「作って終わり」ではなく、リリースしながら改善を続ける進め方です。そのため保守の考え方も、納品後に別契約で始める従来型とは少し異なります。
確認したいポイント
- 開発中の担当者がそのまま保守に入るか: 仕様を知っているチームが続けるほうが、引き継ぎコストが抑えられます
- リリース後の修正・改善をどう依頼するか: 開発契約を延長して対応するのか、別の保守契約に切り替えるのか
- 保守費用の考え方: 月額固定の保守か、改善の工数に応じた費用か
- 体制を縮小・拡大できるか: 運用期に入ったら人数を減らし、新機能を追加するときに増やすといった調整が可能か
たとえば弊社の受託開発サービス（TechBand）は、月額制の準委任型契約で、1ヶ月単位で体制の縮小・拡大ができる設計にしています。こうした契約の柔軟性は、保守期への移行を考えるうえで重要な比較ポイントです。
スクラム開発の3つの役割と発注者が知っておくこと
スクラムのチームには3つの役割があります。ここでは、発注の判断に関わる部分に絞って整理します。
プロダクトオーナー（PO）
「何を作るか」「何を優先するか」を決める責任者です。発注者にとって最も関わりの深い役割で、ここを誰が担うかが見積や契約の前提にもなります。
スクラムマスター（SM）
チームがスクラムのルールに沿って進められるよう支援する役割です。開発会社側が担当するのが一般的です。
開発チーム
設計・実装・テストを行う専門家の集まりです。3〜9人程度で構成されます。
受託開発でのPO体制パターン
パターン | 内容 | 発注者の負担 |
|---|---|---|
発注者がPOを担う | 優先順位を自社で決める | 大きいが、意思決定は速い |
開発会社がPOを兼任する | 開発会社が整理・提案し、発注者が承認する | 小さいが、判断が外部任せになりやすい |
ハイブリッド型 | 発注者が方針を決め、開発会社が補佐する | 中程度でバランスがよい |
目安として、発注者がPOを担う場合は週2〜3時間ほど確保できるかが判断基準になります。確保が難しい場合は、ハイブリッド型を選べるかを開発会社に相談してみてください。
スクラム開発の流れ（スプリント）と発注者が関わる場面
スクラムは、1〜4週間（2週間が一般的）のスプリントを繰り返します。弊社では週次（1スプリント＝5営業日）で「ヒアリング→設計→実装→デモ・リリース」を回す進め方を採っています。
- スプリント計画: 今回のスプリントで作る範囲を決めます。発注者は優先順位を伝えます
- 開発とデイリースクラム: 毎日15分程度、チームが進捗を共有します。発注者の参加は通常不要です
- スプリントレビュー: 動くものをデモで確認します。発注者が最も参加すべき場面です
- レトロスペクティブ: 進め方の振り返りです。必要に応じて発注者も意見を出します
発注者の関与で重要なのは、スプリントレビューでの「確認」と、バックログの優先順位の「判断」です。ここが滞ると、見積で想定した期間に収まらなくなります。
スクラム開発のメリット・デメリット（発注判断の視点で）
メリット
- 要件変更に対応しやすく、市場や社内の状況変化を反映できる
- 動くものを早く確認でき、認識のずれやリスクを早期に発見できる
- 最小限の機能から早期にリリースできる
- 進捗と課題が見えやすく、判断の根拠を持ちやすい
デメリット
- 総額が最初に確定しないため、稟議・予算確保で説明が必要になる
- 発注者が確認や優先順位決めに時間を割く必要がある
- 完成形が最初は見えにくく、期待値の調整が必要になる
スクラムが向いているプロジェクト・向いていないプロジェクト
向いている | 向いていない | |
|---|---|---|
要件 | 途中で変わる可能性が高い（新規事業、新サービス） | 最初から仕様が固まっている |
発注者の関与 | 定期的にレビューに参加できる | 完全にお任せしたい |
予算 | 範囲を調整しながら進められる | 総額・納期を厳密に固定する必要がある |
例 | SaaSのMVP、業務アプリの段階的な改善 | 法令対応など仕様が決まった改修 |
判断のポイントは「要件が変わる可能性」と「発注者がレビューに参加できるか」の2点です。
提案書を受け取ったら確認したい5つのポイント
最後に、スクラム開発の提案を評価するときの確認項目をまとめます。
- スプリント期間: 1週間・2週間など、自社の確認ペースに合っているか
- レビューへの参加頻度と形式: オンラインか対面か、発注者は誰が出るのか
- PO体制: 発注者・開発会社・ハイブリッドのどれか。役割分担が明確か
- 進捗の見える化: バックログや進捗をどのツールで共有するか
- 契約形態と見積の前提: 準委任か請負か。見積の前提（人数・期間・範囲の扱い）と、リリース後の保守の取り決めはどうなっているか
これらを開発会社に質問し、回答を稟議書の根拠としてまとめておくと、社内説明がスムーズになります。
まとめ
スクラム開発とは、アジャイル開発の代表的なフレームワークで、短いスプリントを繰り返しながら進める方法です。発注者にとって大切なのは、用語を知ることに加えて、スクラムを選ぶと見積は「範囲を調整する」考え方に、契約は準委任中心に、保守は開発と連続したものに変わると理解しておくことです。
自社の状況に合うかを判断するには、提案書の見積前提・契約形態・保守の取り決め・PO体制を確認することが近道です。詳しい確認項目は、発注前チェックリストにまとめています。受託開発の進め方全体はこちらの記事も参考にしてください。
秋霜堂株式会社について
秋霜堂は、Web開発・AI活用・業務システム開発を手がけるシステム開発会社です。要件定義から設計・開発・運用まで一貫してご支援しています。
システム開発のご相談や、自社課題に合った技術的アプローチについてお悩みの方は、お気軽にお問い合わせください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- スクラムとウォーターフォールで迷った場合、何を基準に選べばよいですか？
開発の途中で要件や優先順位が変わりやすいプロジェクトか、そして発注者自身がスプリントレビューなど定期的な確認の場に時間を割ける体制かどうかが主な判断材料になります。両方に当てはまるならスクラムが向いており、要件がほぼ固まっていて関与の時間を確保しにくい場合はウォーターフォールのほうが適しています。
- 発注者側にプロダクトオーナー（PO）を担える人がいない場合はどうすればよいですか？
開発会社側がPOを兼任する体制や、発注者がビジネス要件を伝え開発会社がPOとして整理するハイブリッド型を検討してください。どちらの場合も発注者の関与度は下がりますが、優先順位の判断だけは発注者側に残しておくと、完成後のイメージのズレを防ぎやすくなります。契約前に体制と役割分担を開発会社とすり合わせておきましょう。
- 発注者はスプリントレビューにどのくらいの頻度・時間を確保すればよいですか？
スプリント期間（多くは2週間）ごとに1回、動くプロダクトのデモ確認とフィードバックを行う場に参加します。所要時間はプロジェクト規模によって数十分から1時間程度が目安です。参加形式（対面・オンライン）や具体的な時間は開発会社ごとに異なるため、契約前に確認し、社内の担当者が継続して確保できるかを見極めておくと安心です。
- スクラム開発の契約は準委任と請負のどちらを選ぶべきですか？
変化への対応や優先度の見直しを重視するなら、実工数に対して支払う準委任契約（タイムアンドマテリアル型）が相性が良いです。総コストの見通しを優先したい場合は請負契約も選択肢になりますが、仕様変更のたびに追加費用が発生しやすい点に注意してください。
- スクラム開発が未経験でも、いきなり本格導入して問題ありませんか？
不安がある場合は、いきなり全体を委ねるのではなく、まず1回分の開発期間だけ試験的に依頼する進め方を提案してもらうのが有効です。実際のレビュー参加や意思決定にかかる負担を体感したうえで、本格的な導入に進むかどうかを判断できます。開発会社によっては短期の試験導入に対応していない場合もあるため、事前に相談してみてください。
