スクラッチ開発の外注判断基準｜費用・工期・拡張性で決める

社内のシステム刷新を任され、開発会社への相談やRFP（提案依頼書）の作成に進む前に、「自社はスクラッチ開発で進めるべきか、それともパッケージやSaaSで対応できるのか」という方向性の決定で手が止まっている。そんな状況にいる発注担当者は少なくありません。

この方向性の判断は、要件定義よりもさらに手前にあるにもかかわらず、最も影響範囲が大きい意思決定です。一度方向性を固めて設計・開発フェーズに入ってしまうと、後から「やはり別の方法が適していた」と気づいても、軌道修正には数百万円から数千万円規模の手戻りが発生します。だからこそ「次は失敗できない」という緊張感を持って情報を集めている方が多いのです。

ところが、いざ調べてみると「スクラッチとパッケージの違い」を説明する記事は多いものの、「自社の条件を当てはめれば方向性が決まる」という判断軸を示してくれる情報はなかなか見つかりません。開発会社に相談しても、その会社が得意とする手法に話が寄っていく感覚があり、中立な立場で判断できる材料が手元にない、という不安もよく聞かれます。

本記事では、スクラッチ開発を外注すべきか、パッケージやSaaSで対応すべきかを、費用・工期・拡張性の3軸と、順に答えるだけで方向性が出る5つの問いで整理します。技術的な内部構造の話には立ち入らず、発注者が自分の責任範囲で根拠を持って意思決定し、要件定義やRFPの準備に自信を持って進める状態を目指します。

スクラッチ開発の外注で「方向性の判断ミス」が致命傷になる理由

システム開発における手戻りのコストは、フェーズが進むほど指数関数的に膨らみます。要件定義の段階で気づいた認識のズレは打ち合わせ数回で修正できますが、設計・開発が進んでから「そもそもパッケージで足りた」「逆にパッケージでは業務に合わず作り込みが必要だった」と判明すると、それまでの工数の多くが無駄になります。

特に方向性（スクラッチ／パッケージ／SaaS）の選択ミスは、機能単位の仕様変更とは性質が異なります。たとえばパッケージ導入を前提に進めた後で「自社業務の独自性が高く、カスタマイズだけでは対応できない」と分かれば、スクラッチへの作り直しに近い判断を迫られます。これは部分的な修正ではなく、プロジェクトの土台そのものを組み替える話です。

にもかかわらず、この方向性は要件定義より前に決めなければなりません。判断材料が十分にそろっていない段階で決断を迫られるため、発注担当者にとっては最も不安の大きいポイントになります。しかも開発会社に相談すれば中立な助言が得られるとは限りません。スクラッチを主力とする会社はスクラッチを、パッケージを扱う会社はパッケージを勧めがちで、発注者自身が判断軸を持っていなければ、提案の妥当性を評価できないからです。

つまり、方向性の決定で誤らないためには、開発会社に相談する前に、発注者自身が「費用・工期・拡張性」という共通の物差しを持っておくことが欠かせません。次の章から、その物差しを一つずつ整えていきます。

スクラッチ開発・パッケージ・SaaSの違い（発注判断に必要な範囲だけ）

方向性を判断するために、まず3つの選択肢を発注者の意思決定に必要な範囲だけ押さえます。ここでは技術的な作りの違いではなく、「誰がどこまでカスタマイズできるか」「費用がどのように発生するか」「運用の責任が誰にあるか」という発注実務に直結する観点で整理します。各手法のメリット・デメリットをより詳しく比較したい場合は、パッケージ開発とはもあわせてご覧ください。

スクラッチ開発とは

スクラッチ開発は、ゼロから自社専用のシステムを設計・構築する方法です。業務フローに完全に合わせて作り込めるため自由度が最大である一方、設計から開発まですべてを行うため費用と期間も最大になります。出来上がったシステムは自社の資産となり、仕様も自社が握れますが、保守・改修も含めて長期にわたって付き合う前提になります。

パッケージ開発とは

パッケージ開発は、特定の業務向けに作られた既製のソフトウェアをベースに、自社の業務に合わせて一部をカスタマイズして導入する方法です。基本機能がすでに用意されているためスクラッチより費用・期間を抑えられますが、カスタマイズの範囲が広がるほどコストは膨らみ、製品の作りによっては対応できない要望も出てきます。自由度とコストのバランスを取る中庸の選択肢です。

SaaSとは

SaaS（サース）は、クラウド上で提供されるソフトウェアを月額などの利用料を払って使う方法です。自社でシステムを保有せず、ベンダーが運用・保守・アップデートまで担うため、導入が最も速く初期費用も最小に抑えられます。一方でカスタマイズは原則できず、サービス内容・料金・存続はベンダーの方針に左右されます。標準機能が自社の業務に合致するかどうかが導入可否の分かれ目です。

3手法の比較表

3つの選択肢を、発注判断に関わる5つの観点で並べると次のようになります。

この表が、以降の費用・工期・拡張性の議論と判断フローの土台になります。

費用・工期の目安｜どのくらいの規模で何が変わるか

3軸のうち、まず判断材料として最も具体的に押さえておきたいのが費用と工期です。自社案件がどのくらいの規模感に当たるのかを掴むために、現実的なレンジを見ていきます。

初期費用の目安

3手法の初期費用は、規模が違うというより桁が違うと考えたほうが実態に近いです。

スクラッチ開発の費用は人件費が大半を占め、「エンジニアの月単価 × 人数 × 開発期間」で概算されます。エンジニアの月単価はおおむね80万〜120万円が目安です。同じ「業務システム」でも、扱うデータの種類や連携先の数、画面数によって費用は大きく変動するため、上記レンジはあくまで出発点として捉えてください。

開発期間の目安

期間も初期費用と同様に、手法によって大きく異なります。

納期に厳しい制約がある場合、スクラッチ開発はその時点で選択肢から外れることもあります。期間は費用と並ぶ重要な制約条件です。

見落としがちなランニングコストと「トータルコストで比較する」原則

費用を比較するとき、初期費用だけを見ると判断を誤ります。重要なのは、運用が続く限り発生し続けるランニングコストまで含めた総額（トータルコスト）で比べることです。

• スクラッチ開発：保守・改修費用が継続的に発生します。一般に年間保守費は初期開発費の10〜15%程度が目安とされ、長く使うほど累積します。
• パッケージ開発：ライセンスの更新費用やバージョンアップ費用がかかります。カスタマイズした部分は、製品本体のバージョンアップ時に追加の改修費がかかることもあります。
• SaaS：月額利用料が使い続ける限り発生します。1ユーザーあたり月数千円〜1万円前後が一般的で、利用人数が増えるほど月額も増えます。

たとえば「初期費用が安いSaaS」を選んでも、利用人数が多く長期間使うなら、数年単位ではスクラッチの初期費用に近づくケースもあります。逆に「初期費用は高いがランニングが軽いスクラッチ」が長期的に有利になることもあります。5年程度のスパンでトータルコストを試算してから比較するのが、後悔しないための原則です。

費用を実際に試算してみたいときは、システム開発の費用構造を体系的に整理したお役立ち資料も用意しています。費用の内訳や見積もりの読み方を理解しておくと、開発会社の提案を冷静に評価しやすくなります。費用相場のより詳しい解説はシステム開発の費用相場もご参照ください。

拡張性で考える｜「将来の変化に耐えるか」の見極め方

3軸の最後は拡張性です。ここは営業トークに最も流されやすいポイントなので、自己判断の軸を丁寧に作っておきます。

「将来の拡張性を考えるとスクラッチがよい」という説明は一見もっともらしく聞こえますが、拡張性が必要だからといって即スクラッチ、という結論は早すぎます。拡張性は「必要か／不要か」の二択ではなく、変化の頻度・範囲・連携要件の3つに分解して考えると、過剰投資を避けられます。

• 変化の頻度：業務ルールや機能要件がどのくらいの頻度で変わるか。法改正対応や事業モデルの変更が頻繁に見込まれるなら、自社の判断で柔軟に改修できるスクラッチの価値が高まります。逆に、業務が安定していて数年間ほぼ変わらないなら、パッケージやSaaSの標準機能で十分なことが多いです。
• 変化の範囲：変更が画面の文言や設定変更レベルで収まるのか、業務フローそのものを作り替えるレベルなのか。前者ならパッケージやSaaSの設定変更で対応できますが、後者が頻繁に起こるならスクラッチが向きます。
• 連携要件：既存の基幹システムや外部サービスとどこまで連携する必要があるか。複雑で独自性の高い連携が多いほどスクラッチが有利になり、標準的な連携で済むならパッケージやSaaSのAPI連携機能で対応できる場合があります。

ポイントは、「将来こういう拡張があるかもしれない」という曖昧な不安だけでスクラッチを選ばないことです。具体的に「いつ・どの業務が・どの範囲で変わる見込みか」を言語化できないなら、その拡張性への投資は過剰になりがちです。まず確実に見えている範囲で最小限の方法を選び、変化が現実になった段階で拡張を検討する、という考え方も有力な選択肢です。

スクラッチ外注かパッケージ活用か｜5つの問いで決める判断フロー

ここまでの費用・工期・拡張性の3軸を踏まえ、自社の方向性を実際に決めるための判断フローを示します。次の5つの問いに順に答えていくことで、自社案件がどの手法に向いているかが言語化できます。

判断フローチャート（5つの問い）

このフローは「①でYESなら即スクラッチ」という単純なものではなく、各問いの傾きを積み重ねて全体の方向性を見るものです。スクラッチ候補が多く積み上がればスクラッチ寄り、SaaS・パッケージ候補が多ければそちら寄りと判断します。

問いごとの考え方と判断のコツ

• ①業務の独自性と競争優位：その業務のやり方そのものが自社の強みになっているなら、既製品に業務を合わせると強みを失います。逆に、経理・勤怠・人事のように業界標準のやり方で十分な業務は、独自に作り込む必要は薄く、SaaSやパッケージが適します。
• ②予算・納期の制約：費用と工期の章で見たとおり、スクラッチは費用・期間ともに最大です。半年以内に動かしたい、予算が数百万円以内、といった制約が強い場合、スクラッチは現実的でないことが多くなります。
• ③将来の変化：拡張性の章で分解した「頻度・範囲」を当てはめます。頻繁かつ広範囲な変更が見込まれるならスクラッチの柔軟性が活き、安定した業務なら標準機能で十分です。
• ④連携要件：基幹システムとはで扱うような中核業務と複雑に連携する必要があるなら、自由に設計できるスクラッチやカスタマイズ可能なパッケージが向きます。
• ⑤撤退・乗り換えのしやすさ：事業の見通しが不確実で、合わなければやめたい・乗り換えたいという可能性を重視するなら、契約を止めれば終えられるSaaSが有利です。スクラッチは投資が大きいぶん、撤退コストも大きくなります。

迷ったときの基本指針

5つの問いに答えてもなお判断が割れる場合は、スモールスタートを基本指針とするのが安全です。まずSaaSやパッケージで小さく始めて実際の業務での適合度を検証し、標準機能では業務に合わないと明確に分かった段階で、はじめてスクラッチへの移行を検討します。

最初から大きくスクラッチに投資するより、検証を経てから本格投資に進むほうが、方向性を誤ったときの手戻りを最小化できます。「不確実なときほど、可逆性の高い選択肢から試す」という考え方は、方向性決定における失敗を防ぐうえで非常に有効です。

判断を誤らないために｜よくある失敗パターンと回避策

判断フローで方向性が見えても、実行段階で典型的な落とし穴にはまると、結局は手戻りにつながります。発注者がよくやりがちな失敗を4つ挙げ、それぞれの回避策を整理します。

• パッケージのカスタマイズ過多でスクラッチ並みのコストになる：パッケージを選んだものの、自社業務に合わせる作り込みが膨らみ、費用も保守の難しさもスクラッチに迫ってしまうパターンです。回避策は、導入前に「カスタマイズせず標準機能のまま使える割合」を見積もること。標準機能で7〜8割をカバーできないなら、そのパッケージは自社に合っていない可能性が高く、スクラッチを再検討する判断材料になります。

• SaaSのベンダーロックイン・サービス終了・値上げ：SaaSは便利な反面、ベンダー都合でのサービス終了、一方的な値上げ、仕様変更のリスクがあります。回避策は、契約前にデータのエクスポート可否（自社データを引き出せるか）と、解約条件を確認しておくこと。乗り換えできる状態を保っておけば、ベンダー依存のリスクを抑えられます。

• 不要なスクラッチによる過剰投資と長期化：「将来のため」「他社と差をつけるため」と曖昧な理由でスクラッチを選び、費用と期間が膨らむパターンです。回避策は、拡張性の章で述べたとおり、拡張の必要性を「いつ・どの業務が・どの範囲で」具体的に言語化できるかで判断すること。言語化できないなら、その投資は過剰の可能性が高いです。

• 開発会社の得意手法に誘導される：相談先の開発会社が得意とする手法に話が寄り、中立な比較ができないまま方向性が決まってしまうパターンです。回避策は、本記事で整理した費用・工期・拡張性の3軸と5つの問いで、発注者自身が事前に仮の方向性を持っておくこと。そのうえで複数社に相談し、なぜその手法を勧めるのかの根拠を説明してもらえば、提案の妥当性を自分で評価できます。

これらの失敗はいずれも、方向性決定の段階で少し立ち止まって確認すれば防げるものです。実行に移る前のチェックリストとして活用してください。

方向性が決まったら｜手戻りを防ぐ要件定義・RFPの進め方

方向性が固まったら、次は要件定義とRFPの準備に進みます。ここを丁寧に進めることが、最終的に手戻りを防ぐ決め手になります。

手戻りの真因は「曖昧な要件」にある

開発プロジェクトで手戻りが起こる原因の多くは、技術的な失敗ではなく「要件が曖昧なまま開発に進んでしまったこと」にあります。発注者が伝えたつもりの要件と、開発会社が受け取った理解にズレがあると、出来上がったものが期待と違い、作り直しが発生します。方向性を正しく決めても、要件が曖昧なら手戻りのリスクは残ります。

発注者が準備すべき4要素

要件のズレを防ぐために、発注者があらかじめ整理しておきたい情報は次の4つです。

1. 現状の業務フロー：今どのような手順で業務を回しているかを書き出します。
2. 課題の定量化：「業務が大変」ではなく数字で示します。たとえば「受注データを3つのExcelに手作業で転記しており、月30時間かかり、誤入力が月平均15件発生している」といった具合です。定量化された課題は、開発会社が解決策を具体的に提案しやすくします。
3. 機能の優先度（必須／任意の切り分け）：欲しい機能をすべて並べるのではなく、「これがないと業務が回らない必須機能」と「あれば嬉しい任意機能」を分けます。これにより予算と工期に応じた現実的な範囲設定ができます。
4. 非機能要件：処理速度、同時利用人数、セキュリティ要件、稼働率など、機能以外の品質要件です。後から判明すると大きな手戻りになりやすいため、早い段階で整理しておきます。

RFPで開発会社に判断を委ねすぎないコツ

RFP（提案依頼書）は開発会社に提案を求める文書ですが、何をどう作るかをすべて開発会社任せにすると、各社の提案がバラバラになり比較できなくなります。発注者側で「解決したい課題」「必須要件」「予算・納期の制約」を明確に示したうえで、実現方法の提案を求めるのがコツです。要件定義書とRFPの役割分担や具体的な書き方はシステム開発RFPの書き方で詳しく解説しています。

ここまで準備できていれば、開発会社からの提案を3軸で評価でき、方向性決定から実装まで一貫した判断軸で進められます。

まとめ｜費用・工期・拡張性の3軸で、発注前に方向性を固める

スクラッチ開発を外注すべきか、パッケージやSaaSで対応すべきかは、要件定義より手前で決めなければならない、最も影響範囲の大きい意思決定です。判断を誤ると数百万〜数千万円規模の手戻りにつながるため、開発会社に相談する前に、発注者自身が判断軸を持っておくことが欠かせません。

本記事で整理した要点は次のとおりです。

• 費用・工期：スクラッチは500万〜2,000万円・半年〜数年、パッケージはライセンス＋カスタマイズで数週間〜数か月、SaaSは月額制で即日〜数週間。初期費用だけでなく、5年スパンのトータルコストで比較する。
• 拡張性：「拡張性が必要＝即スクラッチ」ではなく、変化の頻度・範囲・連携要件に分解して見極める。曖昧な不安での過剰投資を避ける。
• 判断フロー：業務の独自性・予算と納期の制約・将来の変化・連携要件・撤退のしやすさという5つの問いで方向性を言語化する。迷ったらスモールスタートが安全。
• 失敗回避と要件定義：カスタマイズ過多・ベンダーロックイン・過剰投資・営業誘導という典型的な失敗を事前チェックで避け、方向性が決まったら定量化した課題と機能の優先度を整理して要件定義・RFPに臨む。

方向性は、開発会社に相談する前に、発注者自身が費用・工期・拡張性の物差しを持って固めるものです。その軸さえ持っていれば、提案の妥当性を冷静に評価でき、前回のような手戻りを繰り返すことなく、自信を持って次のステップに進めます。