業務システムを刷新するとき、最初に決めなければならないのが「既製品を使うか、自社用に作るか」という開発手法の選択です。この判断を誤ると、費用が想定を大きく超えたり、完成したシステムが業務に合わなかったりと、後から取り返しのつかない問題につながります。

自社用にゼロから作る手法がスクラッチ開発です。この記事では、スクラッチ開発の意味とパッケージなど他の手法との違い、メリットとデメリット、採用すべき案件の見分け方、発注時に失敗しないためのポイントを解説します。

この記事を読むと理解できること

• スクラッチ開発の意味と、フルスクラッチ・ハーフスクラッチの違い

• パッケージ、SaaS、ローコード開発とスクラッチ開発の比較

• スクラッチ開発のメリットとデメリット

• スクラッチ開発を選ぶべき案件と見送るべき案件の判断基準

• 要件定義から運用までの流れと、工程ごとの発注者の役割

• 発注時に起きやすい失敗と、契約や納品物で先回りする方法

スクラッチ開発とは何か、パッケージやハーフスクラッチとどう違うのか

スクラッチ開発とは、既製のソフトウェア製品を土台にせず、自社の業務や要件に合わせてシステムを一から設計・開発する手法です。パッケージが「完成済みの標準機能を買う」選択だとすれば、スクラッチ開発は「自社専用のシステムを作るための設計と開発の稼働を買う」選択だと言えます。

何も使わずに作るわけではない

スクラッチ開発という言葉から、プログラムをすべて手書きするイメージを持つ人もいます。しかし実務では、Webアプリケーションのフレームワークやクラウドの各種サービス、オープンソースのライブラリなど、既存の部品を活用しながら開発するのが一般的です。

ここでいう「ゼロから」とは、業務ロジックや画面、データ構造を自社の要件に合わせて設計するという意味です。発注の際は、ベンダーがどこまでを既存部品で賄い、どこからを個別に作るのかを確認しておくと、見積もりの比較がしやすくなります。

フルスクラッチとハーフスクラッチ

スクラッチ開発は、既製品をどれだけ使うかで大きく2つに分けて語られます。すべてを個別に設計・開発するのがフルスクラッチ、既製品やパッケージを土台にして足りない部分だけを個別開発するのがハーフスクラッチです。

ただし、フルスクラッチという言葉の範囲は会社によって異なります。単にスクラッチ開発と同じ意味で使う会社もあれば、既存部品を極力使わない開発を指す会社もあるため、発注前に定義をすり合わせておくことが大切です。

パッケージ、SaaS、ローコードとの比較

業務システムを用意する手段は、スクラッチ開発だけではありません。代表的な4つの選択肢を、発注者が判断しやすい軸で比べると次のようになります。

スクラッチ開発は自由度が最も高い分、費用と期間、そして要件を決める発注者側の負荷も最も大きくなります。ローコード開発との違いはローコード開発の解説記事で詳しく整理しています。

スクラッチ開発のメリットとデメリットは何か

スクラッチ開発の最大のメリットは、業務への適合度と改修の自由度です。一方で、費用と期間がかかり、品質がベンダーの力量と発注者の要件定義に大きく左右されるというデメリットがあります。

メリット1 業務にぴったり合わせられる

パッケージでは、標準機能に合わない業務を運用でカバーしたり、業務そのものを製品に合わせて変えたりする必要があります。スクラッチ開発なら、自社独自の業務の流れや判断の手順を、そのままシステムの設計に反映できます。

特に、受注の条件判断や見積もりのロジックなど、他社との違いを生んでいる業務ほどスクラッチ開発の価値は大きくなります。標準化された製品に合わせると、強みそのものが失われるおそれがあるためです。

メリット2 画面と操作性を作り込める

見落とされがちですが、スクラッチ開発では画面の構成や操作の流れも自由に設計できます。現場の担当者が1日に何百回も繰り返す操作を数クリック減らせれば、それだけで業務全体の生産性は大きく変わります。

パッケージの画面は多くの企業に共通する作りになっているため、特定の業務に最適化するには限界があります。現場で使われ続けるシステムにするうえで、画面設計の自由度はスクラッチ開発の重要な強みです。

メリット3 製品の都合に左右されにくい

パッケージやSaaSは、提供元のバージョンアップや価格改定、サポート終了の影響を受けます。スクラッチ開発のシステムは自社の資産になるため、改修や延命のタイミングを自社の判断で決められます。

また、ユーザー数に応じたライセンス費が継続的に発生しない点も、長く使う前提のシステムでは利点になります。ただし、保守・運用の費用は別途必要になる点に注意が必要です。

デメリット1 費用と期間がかかる

すべてを設計・開発するため、パッケージの導入に比べて初期費用は大きく、稼働までの期間も長くなります。スクラッチ開発の見積もりは、基本的に必要な作業量と技術者の単価の掛け算で積み上がるため、要件が増えるほど費用も比例して増えます。

そのため、見積もりを比べるときは総額だけでなく、どの機能にどれだけの作業量が見込まれているかという内訳まで確認することが大切です。

デメリット2 品質が発注者とベンダーの力量に左右される

完成品がない状態から作るため、システムの品質は要件定義の精度と、ベンダーの設計・開発力に直接左右されます。発注者が要件をベンダーに丸投げすると、業務の実態とずれたシステムができあがり、手戻りで費用と期間がさらに膨らみます。

デメリット3 ブラックボックス化しやすい

設計書や仕様書が十分に残されないまま開発会社が離れると、システムを誰も改修できなくなります。特定の会社にしか保守できない状態は、価格交渉力の低下や、撤退時の業務停止リスクにつながります。この問題はベンダーロックインの解説でも取り上げています。

スクラッチ開発を選ぶべき案件と見送るべき案件の見分け方は

スクラッチ開発を選ぶかどうかは、「その業務が競争力の源泉か」「既製品で要件を満たせないか」「長く使い、改修し続ける前提か」の3つで判断するのが基本です。3つすべてに当てはまる場合、スクラッチ開発は有力な選択肢になります。

選ぶべき条件1 業務そのものが競争力になっている

他社にない業務の進め方や判断の基準が売上や顧客満足を生んでいるなら、その業務を支えるシステムは自社で設計する価値があります。逆に、どの会社でも同じように行う業務であれば、既製品に業務を合わせたほうが合理的です。

選ぶべき条件2 既製品では要件を満たせない

パッケージやSaaSを検討したうえで、どうしても満たせない要件があるかを確認します。ここで重要なのは、「満たせない」と判断した理由を具体的に書き出すことです。単に「使い慣れた画面と違う」という理由なら、業務の見直しで解決できることも少なくありません。

選ぶべき条件3 長期の利用と改修を前提にしている

スクラッチ開発は初期投資が大きいため、長く使い、事業の変化に合わせて改修し続けることで投資を回収する性格があります。数年で使い捨てる予定のシステムや、要件が固まらない実験的な取り組みには向きません。

見送るべき場面

会計、勤怠、経費精算のような標準化された業務は、スクラッチ開発で作る合理性が低い代表例です。また、納期が極端に短い案件や、予算が限られている案件、「将来使うかもしれない」機能を先回りして作ろうとしている案件も、スクラッチ開発を見送るべきサインです。

中核だけをスクラッチ開発で作る選択肢

実務では、全部をスクラッチ開発で作るか、全部を既製品にするかの二択で考える必要はありません。標準業務はSaaSやパッケージに任せ、競争力の中核となる業務だけをスクラッチ開発で作り、両者をAPIでつなぐ構成が現実的な落としどころになることが多くあります。

スクラッチ開発はどんな流れで進むのか

スクラッチ開発は、要件定義、設計、開発、テスト、リリースと運用・保守という流れで進むのが一般的です。発注者にとって大切なのは、工程ごとに自社が何を決め、何を確認すべきかを把握しておくことです。

要件定義で業務とシステムの範囲を決める

要件定義は、スクラッチ開発で最も重要な工程です。どの業務をシステム化し、どんな機能や画面が必要で、性能やセキュリティにどんな条件があるかを決めます。

この段階では、必須の要件と、あれば望ましい要件を分けて整理しておくと、予算や期間の調整がしやすくなります。現状の業務と目指す姿を整理する手法はAs-Is To-Beの解説も参考になります。

設計からテストまでの工程

設計では、要件をもとにシステムの構成や画面、データの持ち方を具体化します。その後、設計に沿って開発し、機能ごとの動作確認から業務の流れを通した確認へと段階的にテストを進めます。

発注者が最も関わるべきなのは、画面設計の確認と、業務の流れを通した受け入れテストです。ここで現場の担当者に実際に操作してもらうと、仕様書だけでは見えない使いにくさを稼働前に見つけられます。

リリース後の運用・保守まで見据える

スクラッチ開発のシステムは、稼働してからが本番です。障害対応や問い合わせ対応、法改正や業務変更に伴う改修を誰がどう担うかを、リリース前に決めておく必要があります。

運用・保守を外部に委託する場合は、対応範囲や対応時間、費用の考え方を契約で明確にしておきましょう。将来の内製化を視野に入れるなら、開発の段階から社内の担当者が設計やコードの内容を理解できる体制をつくっておくことが重要です。

スクラッチ開発を発注するとき失敗しないためのポイントは

スクラッチ開発の失敗の多くは、技術ではなく発注の進め方から生まれます。要件定義の分担、契約形態、納品物、画面設計の進め方の4点を押さえておくと、典型的な失敗の多くは事前に防げます。

要件定義をベンダーに丸投げしない

ベンダーは開発の専門家ですが、自社の業務の専門家ではありません。業務の実態や優先順位を発注者が示さないまま要件定義を任せると、ベンダーは一般的な業務を想定して設計するしかなくなります。

要件定義には、情報システム部門だけでなく、実際にシステムを使う業務部門の担当者にも参加してもらいましょう。決定権を持つ人が要所で判断することも、手戻りを減らすうえで欠かせません。

工程に合わせて契約形態を分ける

要件が固まっていない上流工程と、仕様が固まった後の開発工程では、適した契約形態が異なります。上流の要件定義は作業の遂行に対して対価を払う準委任契約、仕様が固まった設計・開発は成果物の完成に責任を持ってもらう請負契約、と分けて考えるのが一般的です。

納品物と権利の扱いを事前に決める

ソースコード、設計書、運用手順書など、何を納品物とするかを契約時に明確にしておきます。あわせて、成果物の著作権がどちらに帰属するかも確認しておきましょう。

これらが曖昧なままだと、将来ほかの会社に保守を移したいときや、社内で改修したいときに大きな障害になります。

画面は作る前に見せて合意する

スクラッチ開発の失敗でよくあるのが、完成してから「思っていたのと違う」と気づくパターンです。仕様書の文章や機能一覧だけでは、実際の画面でどう操作するかを関係者が同じように思い描くことは難しいためです。

FAKEが業務システムの開発を支援する際も、デザインドリブン®のアプローチで画面のプロトタイプを先に作り、現場に触ってもらって合意してから実装に進めます。スクラッチ開発の自由度を、現場が使い続けられるシステムに確実に結びつけるための進め方です。

スクラッチ開発に強く、上流から伴走できる依頼先を探している場合は、業務システム・DXに強い開発会社の選び方もあわせて確認してみてください。

まとめ

スクラッチ開発は、既製品を土台にせず、自社の業務や要件に合わせてシステムを一から設計・開発する手法です。業務への適合度、画面や操作性の作り込み、改修の自由度が大きな強みである一方、費用と期間がかかり、品質が要件定義とベンダーの力量に左右されるという弱みがあります。

採用の判断は、業務が競争力の源泉か、既製品で要件を満たせないか、長く使い改修し続ける前提か、の3点で考えるのが基本です。標準業務は既製品に任せ、中核の業務だけをスクラッチ開発で作る組み合わせも有力な選択肢です。

発注時には、要件定義を丸投げしないこと、工程に応じて契約形態を分けること、納品物と権利を明確にすること、画面を作る前に見せて合意することを押さえておきましょう。

スクラッチ開発に関するよくある質問

スクラッチ開発は時代遅れなのでしょうか

時代遅れではありません。会計や勤怠のような標準業務をゼロから作る合理性は下がっていますが、既製品では実現できない独自業務や、競争力の源泉になる業務では、今も有効な手法です。判断のポイントは、その業務に合う既製品が存在するかどうかです。

スクラッチ開発とフルスクラッチは同じ意味ですか

実務ではほぼ同じ意味で使われることが多いですが、会社によっては既存の部品をできる限り使わない開発を特にフルスクラッチと呼ぶ場合があります。見積もりや提案の前提がずれないよう、発注前に用語の定義を確認しておくと安心です。

スクラッチ開発の費用はどのように決まりますか

スクラッチ開発の費用は、主に必要な作業量と技術者の単価の掛け算で決まります。そのため、機能や画面の数、外部システムとの連携の多さ、性能やセキュリティの要件によって大きく変わります。相見積もりを取るときは、総額だけでなく作業量と単価の内訳を比べると、提案内容の違いが見えやすくなります。

スクラッチ開発とローコード開発は組み合わせられますか

組み合わせられます。たとえば、部門内で完結する定型的な業務アプリはローコード開発で素早く作り、複雑なロジックや大量のデータ処理が必要な中核部分はスクラッチ開発で作る、といった使い分けです。両者をつなぐデータ連携の設計を最初に決めておくことが、組み合わせを成功させる鍵になります。