外注コストを抑えるスコープ分割・フェーズ分け発注の設計と進め方

「業務システムを外注したいので開発会社に見積もりを依頼したら、一括で数百万円、案件によっては数千万円の金額が提示された」——こうした見積もりを前にして、その金額にそのままコミットしてよいものか、判断がつかずに手が止まっている方は少なくありません。

不安の正体は単に「高い」ことではありません。要件がまだ完全には固まっていないのに全額を一度に約束しなければならず、もし途中で「やっぱり方向性が違った」となっても引き返せない、という構造への不安です。失敗したら投じた費用がまるごと無駄になるかもしれない。その怖さがあるからこそ、社内でも「もっと安く、段階的に進められないか」という声が上がります。

実は、外注コストが想定より膨らんでしまう大きな原因は、開発会社の単価そのものよりも「最初から全部をまとめて発注している」という発注の仕方にあります。逆に言えば、発注の範囲を意図的に区切り、段階的に発注していく設計（スコープ分割・フェーズ分け発注）を取り入れるだけで、無駄な開発費や後からの追加費用を大きく抑えられる余地があります。

ただし「分割すれば安くなる」というほど単純な話でもありません。どこで区切るかの基準を間違えると、かえって管理コストが増えて割高になることもあります。重要なのは「分け方の設計基準」です。

本記事では、外注コストが一括発注で膨らむ仕組みを整理したうえで、発注範囲を「どこで区切るか」を判断する3つの軸、フェーズと契約形態（準委任・請負）の組み合わせ方、そして分割しすぎの落とし穴と回避策まで、発注者目線で具体的に解説します。読み終えたとき、自社のプロジェクトをどこで区切ればコストとリスクを抑えられるか、ご自身で判断できる状態を目指します。

外注コストが膨らむ原因は「一括発注」にある

外注の見積もりが高く感じられるとき、つい「もっと安い会社を探そう」「値引き交渉しよう」と考えがちです。しかし、コストが膨らむ本当の原因は発注先の単価ではなく、「最初から全工程・全機能を一括で発注している」という発注構造そのものにあることが多いのです。まずはこの構造を分解してみましょう。

一括発注で外注コストが膨らむ3つの構造的な原因

一括発注には、コストを押し上げる3つの構造的な原因があります。

1. 要件が固まりきっていない段階で見積もるため、金額が高めになる

開発会社は、提示された要件をもとに見積もりを作成します。しかし発注側の要件がまだ曖昧な段階で全体を見積もると、開発会社は「後から仕様が増えても対応できるように」余裕を持った金額を提示せざるを得ません。不確実性が大きいほど、見積もりには「読めない部分への保険」が上乗せされ、結果として総額が膨らみます。

2. 全額をコミット済みのため、途中で引き返せない

一括で発注して契約を結んだ後に「やはり方向性が違った」「この機能は不要だった」と気づいても、すでに全額が契約に含まれているため、簡単には取りやめられません。本来なら早めに軌道修正すれば抑えられたはずのコストが、止められないまま消化されていきます。

3. 使われない機能まで作り込んでしまう

最初にすべての要件を詰め込もうとすると、「あったら便利かもしれない」という機能まで仕様に入りがちです。ところが実際にリリースしてみると、利用されない機能が多数含まれていた、というのはよくある話です。一括発注では、この「念のため」の機能まで開発費・テスト費がかかってしまいます。

これら3つはいずれも「一度に全部を決めて発注する」ことから生まれる構造的な無駄です。だからこそ、発注の範囲を区切るという発想が効いてきます。

スコープ分割・フェーズ分け発注とは何か

本記事で提案する考え方を整理しておきます。

スコープとは、その発注で「どこまで作るか」という範囲のことです。スコープ分割は、この範囲を一度に全部発注するのではなく、意味のある単位で区切ることを指します。たとえば「要件定義までをまず発注する」「コア機能だけを先に発注する」といった切り出し方です。

フェーズ分け発注は、分割したスコープを時間軸に沿って段階的に発注していく進め方です。第1フェーズの結果を見てから第2フェーズを発注する、というように、前のフェーズの成果を踏まえて次の発注内容や金額を確定させていきます。

両者はほぼ一体で使われる考え方で、要するに「全部まとめて一度に発注するのをやめ、範囲を区切って段階的に発注していく」という発注設計です。実はこの考え方は特殊なものではなく、経済産業省が公開している「情報システム・モデル取引・契約書」でも、要件定義・設計・開発といった工程ごとに契約を分ける「多段階契約」が標準的な方式として示されています（経済産業省 情報システム・モデル取引・契約書）。

分割すると本当にコストは下がるのか

ここで率直な疑問が浮かびます。「フェーズを分けたら、その分だけ手間が増えて、むしろ高くつくのでは？」というものです。

結論から言えば、分割それ自体が直接的に「単価を下げる」わけではありません。フェーズを分けても、開発する総量が同じなら開発費の総額は大きくは変わりません。

スコープ分割が効くのは、「作らなくてよいもの」「作り直しになるもの」を早い段階で見極められる点です。

• 要件定義を先に切り出せば、その成果を見たうえで本当に必要な開発範囲だけを次に発注でき、過剰な作り込みを防げます
• コア機能だけを先に作って試せば、実際の反応を見てから付加機能の要否を判断でき、使われない機能への投資を避けられます
• 不確実性の高い部分を小さく試してから本発注すれば、大きな手戻り（作り直し）のリスクを抑えられます

つまり、分割によって下がるのは「単価」ではなく「無駄な総量」と「手戻りのリスク」です。次の章では、このメリットを引き出すための「どこで区切るか」の具体的な判断軸を見ていきます。

スコープ分割発注の設計｜「どこで区切るか」3つの判断軸

ここからが本記事の核心です。「分割するとよい」とわかっても、実際にどこで区切ればよいのかが分からなければ動けません。発注範囲を区切る判断軸は、大きく分けて次の3つです。

1. 工程で区切る（要件定義／設計／開発／テスト）
2. 機能優先度で区切る（コア機能／付加機能）
3. 不確実性で区切る（読める部分／読めない部分）

それぞれが「どのコストを抑えるのか」を意識しながら見ていきましょう。実際の発注では、この3つを組み合わせて使います。

判断軸①工程で区切る

最もオーソドックスな分割が、開発の工程（プロセス）の境界で区切る方法です。システム開発は大まかに「要件定義 → 設計 → 開発・実装 → テスト → 運用」という工程を経て進みます。これを一括で発注するのではなく、まずは上流の工程だけを切り出して発注します。

特に効果が大きいのが、要件定義を最初に独立したフェーズとして切り出すことです。

要件定義とは「何を、どこまで作るか」を具体的に固める工程です。前章で見たとおり、外注コストが膨らむ最大の原因は「要件が曖昧なまま全体を見積もる」ことにありました。であれば、まず要件定義だけを発注し、作るものを明確にしてから開発の見積もりを取れば、開発会社は不確実性への保険を上乗せする必要がなくなり、開発の見積もり精度が上がります。

要件定義の成果物（要件をまとめた仕様書など）が手元に残るのも利点です。仮に要件定義の結果「想定より大規模で予算に合わない」と分かれば、その時点で立ち止まれます。要件定義の費用は発生しますが、固まっていない要件のまま開発を丸ごと発注して作り直すコストに比べれば、はるかに小さい投資です。

工程で区切ることで抑えられるのは、見積もりの過剰な上振れと、要件のズレに起因する大きな手戻りです。

判断軸②機能優先度で区切る

2つ目の軸は、作る「機能」の優先度で区切る方法です。システムに盛り込みたい機能を洗い出し、「これがないと成立しないコア機能」と「あると便利な付加機能」に分けます。そして、まずはコア機能だけを発注します。

これは「MVP（Minimum Viable Product＝実用最小限の製品）」と呼ばれる考え方に近いものです。必要最小限の機能だけをまず作って動かし、実際に使ってみてから、付加機能を追加するかどうかを判断します。

この分割が効くのは、前章で触れた「使われない機能まで作り込んでしまう」という無駄を防げる点です。最初に全機能を詰め込むと、実際には利用されない機能の開発費・テスト費まで支払うことになります。コア機能から発注すれば、まず本当に必要なものだけにコストを集中でき、付加機能は「実際に必要だと分かってから」発注できます。

機能優先度で区切るときのコツは、「あったら便利」を一旦すべて後回しにする勇気を持つことです。発注者としては全部入りで作りたくなりますが、まずコア機能で価値を確かめ、付加機能は反応を見てから判断する——この順番が、ムダな作り込みへの最大の歯止めになります。

機能優先度で区切ることで抑えられるのは、使われない機能への開発投資です。

判断軸③不確実性で区切る

3つ目の軸は、見通しの立ちにくさ（不確実性）で区切る方法です。プロジェクトの中には、「やってみないと分からない」要素が含まれることがあります。たとえば、新しい技術が自社の環境で動くか、外部サービスとの連携がうまくいくか、想定した使い方をユーザーが受け入れるか、といった部分です。

こうした不確実性の高い部分を、いきなり本格的な開発として大きく発注するのは危険です。読めない部分が後で行き詰まると、それまで作ったものごと作り直しになりかねません。そこで、不確実性の高い部分は小さく試す（検証する）フェーズとして先に切り出すのが有効です。

具体的には、技術検証（PoC＝概念実証）や試作（プロトタイプ）を小さな発注として先に行い、「この方式で問題なく作れる」という見通しを得てから、本格的な開発を発注します。検証フェーズの費用は本開発に比べれば小さく、ここで「この方式では難しい」と分かれば、大きな投資をする前に方針を変えられます。

不確実性で区切ることで抑えられるのは、読めない部分が原因の大きな手戻りと、見通しの甘い本発注によるコスト暴走です。

これら3つの軸は、どれか1つだけを使うものではありません。たとえば「要件定義を先に切り出し（工程）、その中でコア機能を特定し（優先度）、技術的に不安な部分は試作で検証する（不確実性）」というように、組み合わせて発注全体を設計します。

フェーズ分け発注と契約形態の組み合わせ方

スコープをどこで区切るかが見えてきたら、次は「各フェーズをどの契約形態で発注するか」です。ここで登場するのが、聞いたことはあっても自社の発注にどう使えばよいか分かりにくい「準委任契約」と「請負契約」です。この2つを、コストの観点に絞って整理します。

準委任契約と請負契約の違いをコスト視点で整理する

両者の最も大きな違いは「何に対してお金を払うか」です。

• 請負契約は、「成果物の完成」に対して報酬を払う契約です。あらかじめ決めた成果物を完成させる責任を開発会社が負い、報酬の総額は契約時に確定します
• 準委任契約は、「業務の遂行」に対して報酬を払う契約です。決められた期間・体制で作業を進めること自体が報酬の対象で、特定の成果物の完成を約束するものではありません

コスト設計の観点で重要なのは、仕様変更が起きたときの追加費用の発生のしかたです。

請負契約では、成果物の範囲が契約で固定されています。そのため、契約後に「やはりこの機能も追加したい」という仕様変更が出ると、原則として追加契約・追加費用が必要になります（Workship ENTERPRISE｜準委任と請負の違い）。逆に言えば、仕様がきっちり固まっているなら、請負は「総額が動かない」という安心感があります。

準委任契約では、もともと成果物を固定していないため、進めながらの仕様調整に柔軟に対応してもらいやすいのが特徴です。ただし「業務の遂行」に対して払うため、作業期間が延びればその分の費用は増えます。柔軟な一方で、総額は事前に固定されにくいという性質があります。

簡単にまとめると、次のような対比になります。

上流は準委任・下流は請負——典型的なフェーズ×契約の組み合わせ

この2つの性質を踏まえると、フェーズと契約形態の組み合わせには、コストとリスクを抑えやすい定番のパターンがあります。それが「上流は準委任・下流は請負」です。

要件定義や設計といった上流のフェーズは、まだ「何を作るか」を固めている段階で、成果物を契約時にきっちり定義しきれません。この段階を無理に請負にすると、固まっていない要件をもとに成果物を約束させることになり、開発会社は保険として高めの金額を出すか、後の仕様変更ごとに追加費用が発生します。そこで上流は、柔軟に詰めていける準委任契約が向いています。

一方、要件・仕様が固まった後の開発・実装フェーズは、「何を作るか」が明確です。ここは成果物を定義できるため、総額を確定できる請負契約にすることで、コストの見通しが立てやすくなります。

この組み合わせは、思いつきではなく公的にも推奨されている方式です。経済産業省や業界団体のモデル契約でも、要件が固まりきらない上流工程は準委任、成果物を特定できる開発工程は請負、という多段階の使い分けが標準的な考え方として示されています（経済産業省 情報システム・モデル取引・契約書）。

発注者の立場で言えば、「要件が曖昧なうちは総額を固定しない（準委任）」「固まったら総額を固定する（請負）」と覚えておくと、各フェーズでどちらを選ぶか判断しやすくなります。

多段階契約にする際の注意点

フェーズごとに契約を分ける（多段階契約にする）ときには、いくつか注意点があります。

フェーズ間の引き継ぎを明確にする

前のフェーズの成果物が、次のフェーズの発注の前提になります。要件定義フェーズで作った仕様書が曖昧だと、開発フェーズの請負見積もりがまた高くなったり、認識のズレが残ったりします。各フェーズの成果物が「次の発注の土台」として機能する品質になっているかを確認することが大切です。

各フェーズの成果物を契約で定義しておく

特に上流を準委任にする場合、「成果物の完成」を約束しない契約であるため、何が手元に残るのかが曖昧になりがちです。準委任であっても「このフェーズではどのドキュメント・どの検証結果を納めてもらうか」を契約段階で具体的に決めておくと、次のフェーズへスムーズにつなげられます。

フェーズの切れ目で「続けるか・止めるか」を判断できるようにする

多段階契約の最大の利点は、フェーズの区切りごとに立ち止まって判断できることです。各フェーズの終わりに「次のフェーズに進むか、見直すか、止めるか」を判断する場をあらかじめ設けておくと、分割発注のメリットを最大限に活かせます。

分割発注の落とし穴｜やりすぎると逆にコストが増える

ここまでスコープ分割・フェーズ分け発注のメリットを見てきましたが、「分割すればするほど安全で安くなる」というわけではありません。むしろ、分割のしかたを誤ると、かえってコストが増えることもあります。意思決定の前に、トレードオフも正直に押さえておきましょう。

分割しすぎによる管理コスト増という逆効果

フェーズを分けるたびに、それぞれのフェーズで見積もりの取得・契約の締結・キックオフ・進捗管理・成果物の確認といった「立ち上げと締めの作業」が発生します。フェーズが2つなら2回、5つなら5回、この手間が繰り返されます。

分割の粒度を細かくしすぎると、こうした管理工数（発注者側・開発会社側の双方にかかる手間）が積み上がり、本来抑えたかったコストを上回ってしまうことがあります。1回ごとの発注が小さくなる分、開発会社にとっては「立ち上げの割に小さな仕事」になり、単価が割高に設定されることもあります。

目安としては、「意味のある判断ポイントがあるか」で区切るのが適切です。フェーズの切れ目ごとに「続けるか・見直すか」という意思決定の意味があるなら、その分割には価値があります。逆に、特に判断する必要のないところまで細かく刻むと、管理コストだけが増えてしまいます。

フェーズごとのベンダー乗り換えがもたらす手戻りリスク

「フェーズごとに別の会社に頼めば、各フェーズで一番安いところを選べて得なのでは」と考える方もいます。確かに個別最適では安く見えますが、ここには大きな落とし穴があります。

フェーズごとにベンダーを変えると、前のフェーズの背景や意図を理解している人がいなくなり、引き継ぎのたびに認識のズレや確認の手間が生じます。要件定義をA社、開発をB社に頼んだ場合、B社はA社が作った仕様書を一から読み解く必要があり、その理解にコストがかかるうえ、解釈の食い違いから手戻りが発生しやすくなります。結果として、各フェーズで節約したつもりの金額を、引き継ぎロスと手戻りで失うことが珍しくありません。

特に上流から下流まで一貫した理解が必要なプロジェクトでは、フェーズをまたいで同じ開発会社（または同じ担当者）に継続してもらうほうが、トータルでは安く・確実になることが多いのです。

適切な分割粒度を見極める目安

では、どのくらいの粒度で分割するのが適切なのでしょうか。万能の正解はありませんが、次の目安が役立ちます。

• 「判断のために区切る」を基準にする：そのフェーズの終わりに「続行・見直し・中止」を判断する意味があるなら分ける価値があります。判断ポイントのない細分化は避けます
• 不確実性の高い部分は小さく、固まった部分はまとめて：読めない部分は小さく試し、すでに仕様が固まっている部分は無理に刻まず1つのフェーズにまとめると、管理コストを抑えられます
• 全体の方針は最初に固定する：個々のフェーズ最適に陥らないよう、「最終的に何を実現したいか」という全体方針はプロジェクト開始時に固め、各フェーズはその方針の中で設計します。これがないと、フェーズごとに判断がブレて全体設計が崩れます

分割は「目的（コストとリスクを抑える）のための手段」です。分割そのものが目的化して刻みすぎないよう、常に「この区切りに判断の意味があるか」を問い直すことが、適切な粒度を保つコツです。

外注コストを抑える発注設計の進め方

最後に、ここまでの内容を実際に動かすための手順に落とし込みます。難しく考える必要はありません。次のステップに沿って、自社のプロジェクトを設計してみましょう。

ステップ1〜3：機能の分解とフェーズ設計

ステップ1：作りたいものを機能リストに分解し、優先度をつける

まず、作りたいシステムに必要な機能をできるだけ具体的に書き出します。次に、それぞれを「これがないと成立しないコア機能」と「あると便利な付加機能」に仕分けします。この段階で「全部必要」と思える機能の中にも、よく見ると後回しにできるものが含まれているはずです。

ステップ2：不確実性の高い部分を特定する

書き出した要素の中で、「やってみないと分からない」「技術的にうまくいくか不安」という部分に印をつけます。外部サービスとの連携、新しい技術の採用、想定が立てづらいユーザー体験などが該当します。ここが、小さく試すべき検証フェーズの候補になります。

ステップ3：工程・優先度・不確実性の3軸でフェーズを設計する

ステップ1〜2の結果をもとに、本記事で紹介した3つの軸を組み合わせてフェーズを設計します。典型的には「要件定義フェーズ（工程）→ 不安な部分の検証フェーズ（不確実性）→ コア機能の開発フェーズ（優先度）→ 付加機能の開発フェーズ」といった流れになります。前章の注意点のとおり、判断の意味がある切れ目で区切り、刻みすぎないようにします。

ステップ4〜5：契約形態の決定と小さく始める第1フェーズ

ステップ4：各フェーズの契約形態を決める

設計したフェーズごとに、準委任契約と請負契約のどちらが適切かを決めます。原則は「要件がまだ流動的な上流（要件定義・検証）は準委任、仕様が固まった開発は請負」です。これにより、曖昧な段階で総額を固定して高くつくことを避けつつ、固まった部分は総額を確定させて見通しを立てられます。

ステップ5：第1フェーズを小さく発注して開発会社との相性を見る

いきなり全フェーズを1社に確約するのではなく、まず第1フェーズ（多くの場合は要件定義や小さな検証）を発注します。この第1フェーズには、コストを抑える以外にもう1つ大きな意味があります。それは、開発会社との相性や進め方を、小さなリスクで見極められることです。

要件定義フェーズでのコミュニケーションの質、レスポンスの速さ、提案の的確さは、その後の開発フェーズを任せてよいかを判断する貴重な材料になります。第1フェーズで「この会社とは進めやすい」と確認できてから、本格的な開発フェーズを発注すれば、相性の悪い相手に全額をコミットしてしまうリスクを避けられます。

フリーランス・業務委託を段階発注に組み込む選択肢

段階発注の「小さく始める第1フェーズ」を考えるとき、発注先は開発会社（法人）だけとは限りません。要件定義の壁打ちや小規模な検証、特定機能の試作といった限定的なフェーズでは、フリーランスや業務委託のエンジニアを活用するという選択肢もあります。

たとえば、要件をどう整理すればよいか相談しながら詰めたい上流フェーズでは、経験豊富なエンジニアに準委任で関わってもらい、要件と技術的な見通しを一緒に固めていく、という進め方が考えられます。検証フェーズも、必要な期間・必要なスキルに絞って人材を確保できれば、固定的な大型発注より柔軟にコストをコントロールしやすくなります。

外部人材を段階発注に組み込む場合のポイントは、本記事で見てきた設計の原則がそのまま当てはまることです。すなわち、上流の流動的なフェーズは準委任で柔軟に、固まった開発は請負（あるいは成果を明確にした形）で総額を見通す。そして、フェーズをまたいで一貫した理解を保てるよう、同じ人材に継続して関わってもらえる体制を意識する——この組み立てが、外部人材を活用する場合でも手戻りと無駄を抑える鍵になります。

自社の状況に合ったスキルを持つ人材を、必要なフェーズに必要な分だけ確保できる環境を整えておくと、段階発注という設計はぐっと実行しやすくなります。

よくある質問（外注コスト削減・分割発注のFAQ）

Q. 分割発注は一括発注より本当に安くなるのですか？

分割それ自体が単価を下げるわけではありません。安くなるのは、「使われない機能を作らずに済む」「要件のズレによる大きな手戻りを防げる」「不確実な部分を小さく試してから本発注できる」ことで、無駄な総量と手戻りリスクが減るためです。逆に、判断の意味のないところまで細かく刻むと管理コストが増え、かえって割高になることもあります。「無駄を減らすための分割」という目的を意識することが大切です。

Q. フェーズを分けると納期は延びませんか？

フェーズの立ち上げ・引き継ぎの手間が増える分、単純比較では多少時間がかかる場合もあります。ただし、要件が曖昧なまま一括で進めて途中で大きな手戻りが発生すると、結果的にはそちらのほうが大幅に遅れることが少なくありません。要件を先に固めることで、開発フェーズ自体は手戻りなく進みやすくなり、トータルでは安定したスケジュールになりやすいといえます。

Q. フェーズごとに別の会社に頼んでもよいですか？

可能ではありますが、慎重な判断が必要です。フェーズごとにベンダーを変えると、引き継ぎのたびに前提の理解コストがかかり、解釈のズレから手戻りが起きやすくなります。各フェーズで節約したつもりの金額を、引き継ぎロスで失うこともあります。上流から下流まで一貫した理解が必要なプロジェクトでは、同じ会社・同じ担当者に継続してもらうほうがトータルでは安く確実になることが多いです。

Q. 要件が固まっていなくても発注してよいのですか？

むしろ、要件が固まっていないからこそ、まず「要件定義フェーズ」を準委任契約で発注するのが有効です。固まっていない要件のまま開発全体を請負で発注すると、保険を含んだ高い見積もりになったり、後から仕様変更のたびに追加費用が発生したりします。先に要件を固めるフェーズを切り出すことで、その後の開発の見積もり精度が上がり、結果的にコストを抑えられます。

Q. 小さく試す第1フェーズは、どのくらいの規模・費用が目安ですか？

一律の正解はありませんが、第1フェーズは「全額をコミットする前に、続けるか止めるかを判断できる最小限の範囲」が目安です。要件定義や小さな技術検証であれば、全体予算の一部にとどまることが多く、ここで方向性や開発会社との相性を見極めてから本格的な開発を発注します。重要なのは金額の大小よりも、「この第1フェーズの結果を見て次の判断ができるか」という点です。

スコープ分割やフェーズ分けの設計をいざ自社の発注に落とし込もうとすると、「発注前にどこまで要件を固めておくべきか」「発注中の各フェーズで何を確認すれば手戻りを防げるか」「完了後に何をチェックすれば次の発注に活かせるか」といった、フェーズごとの具体的な確認事項でつまずきがちです。発注前・発注中・完了後の3フェーズで押さえるべきポイントを一覧で確認したい方は、お役立ち資料「システム開発 完全チェックリスト」が参考になります。本記事で解説した分割発注の設計と併せて使うと、各フェーズの抜け漏れを防ぎながら発注を進められます。