# 開発スコープの決め方｜要件定義前の整理手順

- 公開日: 2026-10-17
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/public/column/development-scope-definition-guide

開発スコープ（＝今回のプロジェクトで実施する範囲）は、機能だけでなく、対象業務、利用者、データ移行、外部連携、運用準備まで「やる・やらない・後でやる」に分けて決めます。発注前に境界と優先順位、変更手続きを明文化すれば、見積もり差や追加費用を抑え、納期と予算に合う提案を比較しやすくなります。

## 開発スコープとは何を決めるものか

開発スコープで最も重要なのは、開発対象と対象外の境界を第三者が判断できる状態にすることです。「顧客管理システムを作る」「予約機能を追加する」といった説明だけでは、見積もりに必要な範囲が定まりません。

システム開発の発注では、機能の数だけでなく、対象となる利用者、データ、外部サービス、テスト、導入支援なども工数を左右します。画面には現れない作業を含めて整理する必要があります。

### 機能一覧だけではスコープにならない

たとえば「CSV出力」という機能が一覧に記載されていても、次の条件によって費用は変わります。

- 誰が出力できるのか
- 出力する項目を利用者が選べるのか
- 数十件と数百万件のどちらを想定するのか
- 個人情報を含む場合、操作履歴を残すのか
- 出力処理中に他の操作を継続できるのか
- ファイルの保存期間や削除方法をどうするのか

つまり、機能名だけでなく、利用条件と業務上の境界まで決めることが必要です。要件定義（＝作るものを具体的に決める工程）へ進む前に、少なくとも次の観点で範囲を整理しましょう。

| スコープの観点 | 決める内容の例 | 見落とした場合の影響 |
|---|---|---|
| 目的・成果 | 解決する課題、達成したい状態、評価指標 | 不要な機能が増え、投資判断が曖昧になる |
| 対象業務 | 受付、承認、請求、集計などの対象工程 | 前後工程との間に手作業が残る |
| 利用者 | 顧客、一般社員、管理者、取引先など | 権限や画面の追加が後から発生する |
| 機能 | 登録、検索、通知、出力、管理機能など | 見積もりの前提が会社ごとに変わる |
| データ | 新規データ、既存データ、保存期間 | 移行やデータ整備の費用が漏れる |
| 外部連携 | 会計、決済、認証、メールなど | 接続調査や外部サービス費用が追加される |
| 利用環境 | PC、スマートフォン、ブラウザ、拠点 | 対応端末やテスト範囲が膨らむ |
| 品質・性能 | 同時利用者数、応答速度、可用性 | 公開直前に構成変更が必要になる |
| 導入・運用 | 研修、マニュアル、問い合わせ、監視 | 完成しても現場で利用できない |
| 成果物 | 設計書、ソースコード、テスト結果など | 納品時の認識違いや引き継ぎ問題が起きる |

発注者が誤解しやすいのは、「開発会社なら一般的に必要なものをすべて含めてくれる」という点です。一般的な対応範囲は会社や契約によって異なります。データ移行、操作研修、ストア申請、インフラ費用、公開後の保守などは、別見積もりになることも少なくありません。

## 開発スコープを決める7つの手順

開発スコープは、最初から細かな機能を並べるのではなく、目的から対象業務へ掘り下げ、最後に優先順位と除外範囲を確定すると整理しやすくなります。以下の順番で進めると、経営判断と現場要件が分断されにくくなります。

### 1. 目的と成功条件を決める

最初に「なぜ開発するのか」を一文で表します。目的は「システムを導入すること」ではなく、業務や顧客体験をどう変えるかで設定します。

例として、次のように具体化します。

- 受注情報の二重入力をなくす
- 申請から承認までの平均時間を短縮する
- 顧客が営業時間外でも予約できるようにする
- 月次集計に必要な手作業を削減する

成功条件には、KPI（＝成果を測る指標）を設定します。ただし、発注前に精密な数値を決められない場合は、「処理時間」「入力回数」「利用率」など測定する項目だけでも構いません。目的が明確であれば、予算超過時に何を残すべきか判断しやすくなります。

### 2. 対象となる利用者と業務を特定する

次に、誰が、どの場面で、何をするシステムかを整理します。部署名だけでなく、役割ごとに分けることがポイントです。同じ営業部でも、担当者、承認者、部門管理者では必要な機能と権限が異なります。

確認する項目は次のとおりです。

- 利用者の種類と人数
- 社内利用か社外利用か
- 利用する場所、端末、時間帯
- 現在の業務開始から終了までの流れ
- システム化する工程と手作業で残す工程
- 例外処理を担当する人
- 最終的な承認者と問い合わせ窓口

業務の流れとシステム画面の関係を明確にしたい場合は、[画面遷移図の作り方｜開発依頼前の準備](https://www.geek-bridge.com/column/screen-flow-diagram-guide)も参考になります。

### 3. スコープを10の観点で洗い出す

対象業務が決まったら、機能、データ、外部連携、利用環境、セキュリティ、性能、テスト、移行、教育、運用の観点で必要事項を洗い出します。この段階では、採用するかどうかをすぐに決めず、候補を漏れなく出すことを優先します。

特に忘れやすい項目は次のとおりです。

- 管理者向けの登録・修正・停止機能
- 既存システムからのデータ移行
- 初期データの登録と重複データの整理
- メール、SMS、プッシュ通知の送信費用
- 外部サービスの契約と利用料
- 操作ログや監査記録の保存
- パスワード再発行などの利用者支援
- 操作マニュアルと社内研修
- 本番公開時の切り替え作業
- 公開後の監視、問い合わせ、障害対応

相談を受ける開発会社の立場では、管理画面、例外処理、データ移行の情報が不足している案件ほど、初期見積もりに幅を持たせざるを得ません。通常処理だけでなく、「入力を間違えた」「連携が失敗した」「退職者の権限を停止する」といった場面も確認してください。

### 4. 「今回・次回・対象外・未決」に分類する

洗い出した項目は、次の4つに分類します。「必要か不要か」の二択にしないことが重要です。

| 分類 | 意味 | 記載例 |
|---|---|---|
| 今回実施 | 今回の公開に不可欠 | 顧客登録、予約受付、管理者による予約変更 |
| 次回候補 | 初回公開後に効果を見て追加 | レコメンド、詳細分析、複雑な自動化 |
| 対象外 | 今回は実施しない | 多言語対応、海外決済、旧端末対応 |
| 未決 | 調査や社内判断が必要 | 会計システムとの自動連携方式 |

「次回候補」は、今回の契約に含まれないことを明記します。「未決」は放置せず、決定期限、判断者、調査担当を設定してください。未決事項が残ったまま固定価格の見積もりを依頼すると、開発会社ごとに異なる前提で金額が提示されます。

### 5. 優先順位を付ける

今回実施する項目にも優先順位を付けます。代表的な方法がMoSCoW法（＝必須、重要、できれば、今回は実施しない、の4段階で分ける方法）です。

- Must：目的達成や法令、業務継続のために必須
- Should：重要だが、代替手段があれば初回公開後でもよい
- Could：予算と納期に余裕があれば実施
- Won't：今回は実施せず、将来候補として残す

すべてをMustにすると、優先順位を付けた意味がありません。Mustには、「なければ公開できない理由」を添えます。手作業で一時的に代替できるものは、ShouldやCouldにできる可能性があります。

優先順位は機能単位だけでなく、利用者や対象拠点でも設定できます。たとえば、初回は本社と主要拠点だけで利用し、運用を確認してから全拠点へ展開する方法です。

### 6. スコープ表に条件と対象外を記載する

開発会社へ渡すスコープ表には、最低限、次の項目を記載します。

| 記載項目 | 内容 |
|---|---|
| 対象項目 | 機能、業務、データ移行、研修など |
| 概要 | 実現したいことを1～3文で説明 |
| 対象利用者 | 操作する役割と権限 |
| 優先度 | Must、Should、Could、Won't |
| 今回の区分 | 今回、次回、対象外、未決 |
| 前提条件 | 利用人数、データ量、対応端末など |
| 完了条件 | 何をもって完了とするか |
| 担当 | 発注者、開発会社、外部事業者 |
| 備考・未決事項 | 決定期限と判断者を含める |

完了条件は、納品物の有無だけでなく、利用可能な状態を具体化します。たとえばデータ移行なら、「移行ツールを納品する」のか、「本番データを移行して件数と主要項目を照合する」のかで範囲が異なります。

### 7. 関係者の合意と変更手続きを決める

最後に、現場責任者、事業責任者、情報システム部門、セキュリティ担当などがスコープを確認します。ただし、全員の希望を無条件に追加する場ではありません。目的、予算、納期に照らして採否を決める場です。

合意後のスコープはベースライン（＝変更判断の基準となる承認済みの内容）として版を固定します。誰が最終決定するか、追加要望が出た場合に誰が影響を確認し、誰が承認するかも決めておきましょう。発注者側の役割分担については、[システム開発の発注者体制｜役割・工数・作り方](https://www.geek-bridge.com/column/system-development-client-team)で詳しく解説しています。

## スコープ整理の費用・期間と変更管理

スコープ整理に必要な期間と費用は、関係部署、既存システム、外部連携、資料の整備状況によって変わります。一般的な目安は次のとおりです。これは開発費ではなく、調査やスコープ整理を外部へ依頼する場合の目安です。

| 案件の規模・状態 | 期間の目安 | 外部支援費用の目安 | 想定する内容 |
|---|---:|---:|---|
| 小規模・単一業務 | 1～3週間 | 30万～100万円程度 | 数回のヒアリング、対象整理、概算見積もり用資料 |
| 中規模・複数部署 | 3～8週間 | 100万～300万円程度 | 業務調査、機能整理、移行・連携確認、優先順位付け |
| 大規模・複数システム | 2～4か月以上 | 300万～1,000万円以上になる場合もある | 現行調査、多部門調整、複数連携、段階導入計画 |

既存資料があり、意思決定者が打ち合わせに参加できれば、期間を短縮しやすくなります。一方で、現行システムの仕様が不明、データの状態を確認できない、部署ごとに業務が異なる場合は、調査期間を別に設ける必要があります。

### 未確定部分を無理に固定価格へ入れない

不確定要素が大きいまま開発全体を固定価格にすると、開発会社はリスクを見込んで価格を上げるか、厳しい除外条件を設定します。発注者にとって価格が安く見えても、前提外の作業が追加費用になれば、最終的な総額は比較できません。

不確定な案件では、次のように段階を分ける方法があります。

1. 現行調査と課題整理
2. スコープ策定と要件定義
3. 試作または技術検証
4. 本開発の再見積もり
5. 開発、受入テスト、公開

調査結果によって開発しない判断もあり得るため、最初から本開発まで一括発注することが常に正解とは限りません。

### 変更は「追加するか」だけで判断しない

開発途中に新しい要望が出ること自体は珍しくありません。問題は、影響を確認せずに口頭で追加することです。変更要求が出たら、次の手順で管理します。

1. 変更内容と理由を記録する
2. 費用、納期、設計、テストへの影響を開発会社が確認する
3. 既存要件との入れ替えが可能か検討する
4. 今回追加、次期開発へ延期、却下のいずれかを決める
5. 承認されたスコープ、見積もり、スケジュールを更新する

予算に余裕がない場合は、追加要件と同程度の工数を持つ既存要件を外す方法もあります。発注時には、未確定事項や変更に備えた予備費を確保しておくと判断しやすくなります。予備費の割合は不確実性によって異なりますが、初期予算の10～20％程度を一つの検討目安とし、案件ごとに根拠を確認してください。

## 見積もり比較とよくある失敗の回避策

複数社の見積もりを比較する際は、総額ではなく「どのスコープを、どの前提で含めた金額か」を確認します。金額差の多くは、単価だけでなく、含まれる工程、品質基準、成果物、保守範囲の違いから生じます。

### 見積書で確認するチェックリスト

- 対象機能と対象外機能が明記されているか
- 要件定義、設計、テスト、公開作業が含まれているか
- 管理画面や権限管理が含まれているか
- データ移行の件数、回数、照合方法が明記されているか
- 外部連携先と接続試験の範囲が明記されているか
- インフラ、外部サービス、ライセンスの利用料が分離されているか
- 操作マニュアル、研修、問い合わせ対応が含まれているか
- 対応端末、OS、ブラウザの範囲が明記されているか
- 納品物と検収条件が明記されているか
- 仕様変更時の見積もり・承認方法が決まっているか
- 公開後の保証と有償保守の境界が明記されているか

各社へ同じスコープ表を渡したうえで、見積もりに含まれない項目と独自の前提条件を回答してもらいます。単に「一式」と記載された見積もりは、内訳や除外条件を確認してください。

### 開発会社を見極めるポイント

スコープ策定を相談する会社には、言われた機能をそのまま見積もるだけでなく、目的に照らして範囲を整理する力が必要です。

確認したいポイントは次のとおりです。

- 目的や業務上の課題から質問しているか
- 通常処理だけでなく例外処理を確認しているか
- データ移行、外部連携、運用まで確認しているか
- 不明点を勝手に補わず、前提条件として明記しているか
- 必須範囲と将来範囲を分けて提案できるか
- 予算に応じた代替案を提示できるか
- 変更時の影響と手続きを説明できるか
- 調査が必要な項目を早い段階で指摘できるか

発注のご相談を受ける立場では、「必要なものを全部入れてください」という依頼よりも、「この目的と公開日に不可欠な範囲を提案してください」という依頼のほうが、代替案を提示しやすくなります。スコープ整理から支援が必要な場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談いただけます。

### よくある失敗と対策

| よくある失敗 | 起きる問題 | 回避策 |
|---|---|---|
| 画面と機能だけを決める | 移行、研修、運用が別費用になる | 導入から公開後までを時系列で確認する |
| 「一般的な機能」と記載する | 各社が異なる仕様を想定する | 利用者、操作、条件、完了基準を書く |
| すべてを必須にする | 予算超過時に削る基準がない | 目的に直結するMustを限定する |
| 対象外を記載しない | 含まれると思っていた作業が漏れる | 今回実施しない項目も明文化する |
| 現場だけで決める | 経営・セキュリティ要件が後から追加される | 関係者と確認時期を最初に決める |
| 経営者だけで決める | 実際の例外業務が漏れる | 現場担当者へのヒアリングを行う |
| 未決事項を放置する | 開発中に仕様変更が集中する | 判断者と期限、仮の前提を設定する |
| 変更を口頭で依頼する | 費用と納期の合意が崩れる | 変更要求を記録し、影響確認後に承認する |

スコープは一度決めたら絶対に変えてはいけないものではありません。変化を認めつつ、事業上の必要性と影響を可視化して判断するための基準です。変更をゼロにすることより、無秩序な変更を防ぐことを目指してください。

## まとめ

- 開発スコープは、機能だけでなく、対象業務、利用者、データ、外部連携、移行、運用、成果物まで含めて決めます
- 各項目を「今回実施・次回候補・対象外・未決」に分類すると、見積もりの前提が明確になります
- 優先順位は、目的達成に不可欠なMustを限定し、予算超過時に調整できる状態にします
- 対象外、前提条件、完了条件までスコープ表に記載することが重要です
- 外部へスコープ整理を依頼する費用は、小規模で30万～100万円程度、中規模で100万～300万円程度が一般的な目安です
- 不確定要素が大きい場合は、調査・要件定義と本開発を分けて契約する方法があります
- 見積もりは総額だけでなく、含まれる範囲、除外項目、前提条件、変更手続きを比較します
- 開発途中の追加要望は、費用と納期への影響を確認し、追加・入れ替え・延期を判断します

## よくある質問

### 開発スコープは発注者と開発会社のどちらが決めますか？

事業目的、対象業務、優先順位は発注者が決め、技術的な実現方法や工数への影響は開発会社が整理するのが基本です。一方に任せ切るのではなく、発注者が判断基準を示し、開発会社の提案を受けながら共同で具体化します。

### 相談前にどこまで詳しく決める必要がありますか？

すべての画面や細かな操作を確定する必要はありません。少なくとも、目的、利用者、対象業務、必要な機能、希望時期、予算上限、対象外にしたい範囲を整理してください。不明点は不明と明記したほうが、開発会社から適切な調査や要件定義を提案してもらえます。

### 開発途中で要件を追加することはできますか？

追加は可能ですが、費用、納期、品質への影響を確認してから判断する必要があります。変更内容と理由を記録し、影響見積もりを受けたうえで、追加する、既存要件と入れ替える、次期開発へ送る、のいずれかを選びます。

### 新規サービスで必要機能が固まっていない場合はどうしますか？

最初から全機能を確定せず、仮説検証に必要な最小範囲と、将来追加する範囲を分けます。判断に必要な情報が不足している場合は、調査、試作、要件定義を先行契約し、その結果を踏まえて本開発のスコープと予算を決める方法が適しています。