スクラッチ開発の進め方/やり方/流れや方法/手法/工程/手順

スクラッチ開発は、要件定義・企画から始まり、設計・開発、テスト・リリースという工程を経て、システムが本番稼働を迎えます。

自社の業務に合わせたシステムを作れる一方、進め方を誤ると開発費が当初の2〜3倍に膨らんだり、完成後も使われないシステムができあがったりするリスクがあります。

開発の全体像から見積もりまで、確認したい項目を順に挙げます。

  • スクラッチ開発の全体像
  • スクラッチ開発の進め方・フロー
  • 費用相場とコストの内訳
  • 見積もりを取る際のポイント

スクラッチ開発とは、既製品のパッケージソフトウェアを使わず、ゼロから完全にオーダーメイドでシステムを構築する開発手法です。

自社の業務フローや要件に100%合わせたシステムを作れます。その反面、開発期間が長く、費用も高額になりやすいという特性があります。

経済産業省の調査によると、国内のシステム開発予算のうち相当な割合がスクラッチ開発に充てられています。特に独自の業務プロセスを持つ製造業や金融業では、今も主要な選択肢であり続けています。

これからスクラッチ開発を検討する担当者の方が、失敗なくプロジェクトを進められるよう、現場で役立つ情報をまとめました。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・スクラッチ開発の完全ガイド

スクラッチ開発の全体像

スクラッチ開発の特徴と種類

スクラッチ開発の最大の特徴は、自社のビジネス要件に完全に合ったシステムを一から作れる点です。「スクラッチ」はもともと「ゼロの状態」を意味し、スポーツではハンディキャップのない状態を指します。システム開発でも、既存のコードや仕組みに頼らず白紙の状態から始める手法として定着しています。

スクラッチ開発には大きく分けて、「フルスクラッチ開発」と「セミスクラッチ開発」の2種類があります。フルスクラッチ開発は、何もない状態から全機能を開発する方式で、自由度は最も高い反面、開発コストと期間も最大になります。一方、セミスクラッチ開発は、既存のフレームワークやオープンソースのコンポーネントを活用しつつ、コアとなるビジネスロジックをゼロから開発する方式です。

近年はセミスクラッチ開発が主流となっており、開発期間を30〜50%短縮できるケースも報告されています。また、開発手法はウォーターフォール型とアジャイル型の2種類があり、要件が明確なプロジェクトにはウォーターフォール型が、要件が流動的で段階的に機能を追加するプロジェクトにはアジャイル型が向いています。

パッケージ開発との違い

スクラッチ開発とよく比較されるのが、パッケージ開発です。パッケージ開発とは、ERPやCRMなどの既製のソフトウェアパッケージを導入し、設定変更や軽微なカスタマイズで自社の業務に合わせる手法です。SAP社やOracle社の大規模ERPパッケージが代表例で、中小企業向けにはkintoneやSalesforceなどのSaaSも広く利用されています。

両者の最大の違いは、カスタマイズ性とコストのトレードオフにあります。パッケージ開発は初期費用を大幅に抑えられ、中規模の業務システムなら数十万円から数百万円の範囲で導入できるケースも少なくありません。一方で、パッケージが提供する機能の範囲内でしか構成できず、自社固有のビジネスルールや業務フローを反映しきれないことがあります。

業務をシステムに合わせて変えることを受け入れられる企業には、パッケージ開発が適しています。業界特有の複雑なルールや競合他社との差別化が重要な業務では、スクラッチ開発のほうが長期的な競争優位につながります。さらに、パッケージ開発ではベンダーのサポート終了リスクを常に考慮する必要がありますが、スクラッチ開発で構築したシステムは自社資産として保有・管理でき、ベンダーロックインを回避できます。

ポイント

業務に完全に合わせたいか、既存の部品を使いたいかで、フルスクラッチ、セミスクラッチ、パッケージ開発のどれが合うかを比べます。要件が流動的なら、アジャイル型が向いています。

スクラッチ開発の進め方・フロー

要件定義・企画から設計・開発、テスト・リリース、運用へ進むスクラッチ開発の工程図
各工程の成果を次の段階へつなぎ、リリース後も運用を続けます。

要件定義・企画フェーズ

スクラッチ開発の第一歩は、何を作るかを定める「要件定義・企画フェーズ」です。このフェーズの品質が成否を左右すると言っても過言ではなく、経験豊富なプロジェクトマネージャーは「要件定義に投資した1時間は、後工程での10時間の手戻りを防ぐ」とよく表現します。まずは、「売上管理の手作業を自動化したい」「顧客との接点情報を一元管理したい」といった目的から、システムが解決すべきビジネス課題を整理します。

次に、発注側と開発会社で現在の業務フローを一覧にし、どの部分にシステムが関わるかを洗い出します。この際は、現場担当者へのヒアリングを丁寧に行うことが欠かせません。担当者が日常的に感じている課題や改善要望は、システムの価値を左右する貴重な情報源になります。

続いて要件定義では、機能要件(システムが実現すべき機能の一覧)と非機能要件(処理速度、セキュリティレベル、可用性など)を文書化します。この要件定義書は後の設計・開発フェーズでの合意文書にもなるため、発注側と開発側の双方が内容を十分に理解し、承認する場を設けることが不可欠です。要件定義にかかる期間は規模にもよりますが、中規模のシステムで1〜3ヶ月程度を見込むのが一般的です。

設計・開発フェーズ

要件定義が完了すると設計・開発フェーズに入り、設計は「基本設計(外部設計)」と「詳細設計(内部設計)」の2段階に分かれます。基本設計では、サーバー構成、データベース設計、画面のUI/UX、外部システムとの連携方式などを含めて、システム全体のアーキテクチャ(構成)を決めます。特にデータベース設計は後から変更するコストが非常に高いため、将来の拡張性を考えた設計が求められます。

詳細設計では、個々のプログラムがどのような処理を行うかを、クラス図やシーケンス図などで仕様書に文書化します。開発フェーズでは、エンジニアが詳細設計書に基づいてプログラムコードを書きます。近年はアジャイル手法を採るケースも増えており、2週間〜1ヶ月単位の「スプリント」と呼ばれる短い開発サイクルを繰り返して、機能を積み上げていきます。

この方法では、途中の要件変更に柔軟に対応でき、動くソフトウェアを早い段階で見せることで、認識のずれも早期に発見できます。一方、ウォーターフォール型は全機能を一度に開発し切るため、設計フェーズでの完成度が特に重要になります。中規模のシステムでは、設計から開発までに3〜8ヶ月程度かかることが多く、大規模システムでは1〜3年に及ぶプロジェクトも珍しくありません。

テスト・リリースフェーズ

開発が完了したシステムは、次の4段階のテストを経てリリースされます。

  • 単体テスト:エンジニアが個々のプログラムの動作を確かめる段階です。開発と並行して行われることも多いです。
  • 結合テスト:複数のモジュールを組み合わせたときの動作を見ます。
  • システムテスト(総合テスト):本番環境に近い条件で、全体の動作・性能・セキュリティを検証します。
  • 受入テスト(UAT):発注側の担当者が実際にシステムを操作し、要件定義で定めた内容が満たされているかを確認する段階です。

受入テストで不備が見つかれば修正対応が発生します。そのため、発注側も積極的に参加することが求められます。テストが完了すると、本番環境へのリリース(デプロイメント)に進みます。

大規模なシステムでは、一度に全機能を切り替える「一斉移行」のリスクを避けるため、段階的に機能をリリースする「段階移行」や、新旧システムを一定期間並行稼働させる「並行稼働」といった移行戦略が採られます。リリース後は、初動の安定稼働を確認する「移行後サポート期間」を設けるのが一般的で、この期間は開発チームが常駐して問題に即応できる体制を整えます。

運用フェーズに移った後も、定期的なバグ修正やセキュリティアップデート、機能追加対応が継続して必要になります。

ポイント

迷ったときは、要件定義書に書かれているかを基準にすると、設計や開発での手戻りを抑えられます。受入テストでは発注側も積極的に加わる必要があります。

費用相場とコストの内訳

サーバー・インフラ、保守・運用、ライセンスの費用を総所有コストに含めて考える図
継続費用をまとめて捉えると、初期費用だけでは見えない負担も整理できます。

人件費と工数

開発費用は、機能数と開発期間で決まる規模によって大きく変わります。

  • 小規模:機能数10〜20程度、開発期間3〜4ヶ月以内で、100万〜300万円程度です。
  • 中規模:機能数50〜100程度、開発期間半年〜1年で、500万〜1,000万円程度です。
  • 大規模:機能数が数百に及び、開発期間1年以上の場合は1,000万円以上です。場合によっては数億円規模になることもあります。

企業の基幹システムを一新するような大規模プロジェクトでは、2,000万〜3,000万円以上のケースも珍しくありません。

コストの大半は人件費で、業界では「人月(にんげつ)」を単位に工数とコストを計算します。1人月とは、1人のエンジニアが1ヶ月フルタイムで働いた作業量のことです。人月単価は、担当者のスキルや役割、地域によって差があります。

  • 開発会社の人月単価:スキルレベルや地域によって異なりますが、一般的には1人月あたり50万〜120万円程度が相場とされています。
  • 上流工程の担当者:シニアエンジニアやプロジェクトマネージャーは、1人月100万〜150万円を超えることもあります。

たとえば10人月の開発プロジェクトを想定すると、人件費だけで500万〜1,000万円規模になります。近年はオフショア開発(ベトナムやフィリピンなどの海外拠点での開発)で、国内開発の3分の1〜2分の1程度のコストに抑えられるケースも増えており、有力なコスト削減策として注目されています。ただし、コミュニケーションコストやリスク管理の手間も増えるため、単純にコストだけで判断するのは禁物です。

初期費用以外のランニングコスト

スクラッチ開発では、初期の開発費用に加えて、リリース後に継続的に発生するランニングコストも予算計画に組み込む必要があります。ランニングコストの主な内訳は、サーバー・インフラ費用、保守・運用費用、ライセンス費用の3つです。サーバー・インフラ費用は、AWSやGoogle Cloud、Azureなどのクラウドサービスが主流となった現在、使用量に応じた従量課金制で月額数万円〜数十万円が相場です。

小規模なシステムなら月額1万〜5万円程度で運用できることもありますが、トラフィックの多いWebサービスや処理負荷の高いシステムでは、月額数十万円に及ぶケースもあります。保守・運用費用は、年間の保守費用として開発費の15〜25%程度を目安にするのが業界の通例です。たとえば1,000万円で開発したシステムなら、年間150万〜250万円程度の保守費用を見込む計算になります。

この保守費用には、不具合対応(バグ修正)やセキュリティパッチの適用のほか、定期的な動作確認(ヘルスチェック)と問い合わせ対応が含まれます。さらに、機能追加や仕様変更が発生した場合は、その都度、追加費用がかかります。中長期的に見ると、「総所有コスト(TCO)」は初期費用の2〜3倍以上になるケースも多いため、初期費用だけで比べず、5年〜10年単位のランニングコストも含めて総合的に試算します。

ポイント

費用は、初期の開発費用に加えて、保守費やサーバー・インフラ費用などのランニングコストも含めて試算します。判断は5〜10年単位の総額で行うと、比べ方を誤りにくくなります。

見積もりを取る際のポイント

機能要件一覧、業務フロー図、競合他社・類似システムの例、性能要件を並べた見積もり準備チェックリスト
同じ資料を各社へ示すことで、提案や金額を同じ条件で見比べやすくなります。

要件明確化と仕様書の準備

正確な見積もりを得るには、発注前にできる限り要件を明確化しておくことが不可欠です。「何となくこういうものを作りたい」という程度の情報しか提供できないと、見積もりの精度が大幅に下がり、後から「思っていたものと違う」「追加費用が発生した」といったトラブルの原因になります。見積もりの精度を上げるため、発注前に用意しておきたい項目は4つあります。

  • 機能要件一覧:システムに持たせたい機能をリストアップした文書で、優先度(必須・あれば望ましい・将来対応)も整理しておくと、開発会社との協議が円滑になります。
  • 業務フロー図:現状の業務の流れや、導入後に変わるフローを図示したものです。開発会社が業務の全体像を把握しやすくなります。
  • 競合他社・類似システムの例:参考にしたいサービスを示すことが、開発会社の理解を助けるうえで有効です。
  • 性能要件:ユーザー数やデータ量、アクセス数のピーク値などを事前に整理すると、インフラ規模の見積もり精度が向上します。

これらは「要件概要書」や「RFP(提案依頼書)」にまとめて開発会社に提示します。そうすると、複数社の見積もりを同じ条件で比べられます。

複数社比較と発注先の選び方

発注先選びは、プロジェクトの成否に直結する重要な判断です。複数の開発会社に同じ要件を示して見積もりを取り、金額と提案内容を比べることが基本になります。スクラッチ開発の品質は、担当エンジニアの技術力と、発注側の要件をどれだけ正確に理解できるかで決まるため、価格の安さだけで選ぶのは禁物です。

発注先を選ぶ際は、まず「同業界・同規模の開発実績」を確認します。自社と近い業界や規模のシステムを手がけた会社は業務への理解が深く、要件定義を円滑に進められる可能性が高いです。次に「提案の具体性と質」も大事な評価軸で、ヒアリングの段階から自社の課題を深く理解しようとし、技術提案が具体的かつ現実的な会社は、開発でも信頼できるパートナーとなりやすいです。

また、見積書の明細が、フェーズごと・機能ごとに工数と金額に細分化されていれば、透明性が高く、後から追加費用を請求されるリスクが低い傾向があります。逆に「一式〇〇円」という形の見積もりは内訳が不明確で、後のトラブルにつながりやすいため、注意が必要です。理想的には3〜5社から見積もりを取り、金額と技術力を中心に、コミュニケーション能力・実績・保守体制も含めて総合的に評価することをおすすめします。

注意すべきリスクと対策

スクラッチ開発には特有のリスクがあり、事前に把握して対策を講じておくことが成功の鍵です。開発の途中で表面化しやすいのは、要件や仕様をめぐる問題と、保守や安全性にかかわる問題です。

  • 要件の変化による手戻り:最も多いトラブルの一つで、開発期間が半年〜1年以上に及ぶと、業務環境や経営方針の変化で当初の要件定義と現実がずれることがあります。
  • スコープクリープ(仕様の肥大化):開発が進むにつれて「あの機能も追加したい」などの要望が積み重なり、当初の想定を超えた規模になることがあります。
  • 属人化:担当者の転職や変更で保守が困難になることを想定し、ソースコードの管理方式やドキュメント整備の義務を契約に盛り込むことが大切です。
  • セキュリティ:自社独自のシステムであるため、設計・実装の段階から対策が求められます。

手戻りを防ぐには、アジャイル手法で定期的に成果物を確認するか、ウォーターフォール型でも中間レビューの機会を複数設けることが有効です。スコープクリープについては、追加要件のルール(変更管理プロセス)を事前に契約で定め、追加費用の発生条件と算定方法を明確にしておくことが重要です。

また、「エンジニアの属人化」も長期的なリスクです。システムを開発したエンジニアが転職や担当変更によってプロジェクトを離れると、システムのメンテナンスが困難になることがあります。

さらに、セキュリティリスクについても考慮が必要です。そのため、開発会社にはセキュリティ診断(脆弱性診断)の実施を必須条件とし、本番リリース後も定期的に受けることを検討してください。セキュリティ診断の費用は規模にもよりますが、年間数十万〜数百万円程度が目安です。

ポイント

RFPを用意して複数社に同じ要件を示し、金額だけでなく明細の詳細度や実績で比べます。契約には追加要件のルールとセキュリティ診断を定めておくと、リスクを抑えられます。

まとめ

期待どおりのシステムを得るには、各フェーズで発注側が積極的に関わり、開発会社と密にコミュニケーションを取ることが最も大切です。

費用は、小規模で100万〜300万円、中規模で500万〜1,000万円、大規模で1,000万円以上を相場として念頭に置きます。そのうえで、初期費用だけでなく、年間保守費(開発費の15〜25%程度)やサーバー・インフラ費用も含め、5〜10年スパンで試算します。

見積もりを取るときは、RFPや要件概要書を用意して複数社に提示します。比べる際は、金額に加えて技術力・実績・保守体制も含め、総合的に評価することをおすすめします。

リスクへの対策も事前に講じておけば、スクラッチ開発の成功確率を大幅に高められます。要件の変化やスコープの拡大への備えを中心に、属人化を防ぐドキュメント整備やセキュリティ対策も、早い段階で決めておくことが欠かせません。

本記事で紹介したポイントを参考に、自社に合ったシステム開発を進めてください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。