スクラッチ開発の発注/外注/依頼/委託方法について

スクラッチ開発を外注するには、発注前の準備、発注先の選定、契約から納品までを順に進めます。

• スクラッチ開発を外注するメリット・デメリット
• スクラッチ開発の発注前準備
• 発注先の選び方と比較ポイント
• 発注から納品までの流れ
• 失敗しないための注意点

# 記事No.914「スクラッチ開発の発注/外注/依頼/委託方法について」

スクラッチ開発は、既存のパッケージソフトやフレームワークを流用せず、ゼロから独自のシステムを構築する開発手法です。自社の業務に合わせやすい一方、パッケージ導入より開発期間と費用が大きくなる傾向があります。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

スクラッチ開発を外注するメリット・デメリット

外注のメリット

スクラッチ開発を外注する最大のメリットは、自社の業務フローに完全にフィットしたシステムを構築できる点です。パッケージソフトでは「9割は要件を満たすが、残り1割がどうしても合わない」という場面がよくあります。一方、スクラッチ開発であれば、業務の細部にわたる要件を設計に反映できます。

たとえば、製造業の複雑な受発注処理や、医療機関特有の記録フォーマットなど、業界固有の業務ロジックをそのままシステム化することも可能です。また、外注することで社内リソースを圧迫せずに、高品質なシステムを入手できます。自社でエンジニアを雇用するには採用コストや教育コストがかかりますが、開発会社に委託すれば即戦力のエンジニアチームを活用できます。

さらに、優れた開発会社を選べば、最新技術の活用やプロジェクト管理のノウハウといった恩恵を受けられます。拡張性の面でも、最初から将来の機能追加を考慮した設計を依頼できるため、事業の成長に合わせてシステムを進化させやすい点が大きな強みです。

外注のデメリットとリスク

スクラッチ開発の外注には、パッケージ導入と比べてコストと期間が大きくなるというデメリットがあります。小規模なシステムでも200万円〜500万円程度の費用が必要になり、基幹システム級の大規模開発では2,000万円〜数億円に達するケースもあります。開発期間も数カ月から数年かかるため、スピード感が求められる場面では、パッケージやSaaSの活用を検討すべきでしょう。

外注特有のリスクとして、コミュニケーションギャップがあります。発注者と開発会社の間で認識がずれたまま開発が進むと、完成したシステムが要件と大きく食い違うという事態が起きます。加えて、外注先への技術的依存度が高まるため、保守・運用で継続的なコストが発生しやすい点にも注意が必要です。

また、著作権の帰属にも注意が必要です。著作権法上、システムの著作権は開発会社側に帰属します。そのため、契約書に「著作権の移転に関する条文」を明記しておかないと、自社が発注・費用負担したシステムであっても、自由に改変・利用できないリスクがあります。

スクラッチ開発の発注前準備

要件定義と仕様書の作り方

発注前準備の中で最も重要な作業は要件定義で、「何を作りたいか」を言語化し、開発会社と認識を共有するための土台になります。特に、要件定義が不十分なまま発注すると、開発途中で仕様変更が頻発し、追加費用や納期遅延が生じる原因になります。そこで、まず「現状の業務フローで何が困っているか」を整理するところから始めます。

現場の担当者にヒアリングして、日々の業務手順や使用中のExcel・帳票・紙の書類を洗い出します。次に、求める機能を「必須機能」と「あれば望ましい機能」に分類すると、後の見積もり交渉や開発スコープの調整にも役立ちます。たとえば受発注システムでは、受注登録・在庫確認・請求書発行を必須機能、売上分析ダッシュボードをあれば望ましい機能として分類します。

仕様書としては、RFP（Request for Proposal＝提案依頼書）の形式でまとめると、複数の開発会社に同一条件で見積もりを依頼できるため、非常に便利です。RFPには、システムの目的、対象ユーザー、主要機能、想定データ量を記載します。さらに、連携する既存システム、セキュリティ要件、スケジュール、予算感なども盛り込みます。

予算・スケジュールの設定方法

予算は、相場感を把握したうえで現実的な金額を設定することが大切です。スクラッチ開発の費用は、主にエンジニアの人件費（工数×単価）で決まります。一般的な目安として、小規模システム（社内向けの管理ツール程度）は200万円〜500万円、中規模システム（ECサイトや業務基幹システム）は500万円〜2,000万円とされています。

さらに、大規模システム（複数拠点・多機能の基幹システムなど）は2,000万円以上が相場とされています。予算が少ないからといって無理に削ると、機能の妥協や品質低下につながるため、必要な投資はしっかり確保しておきます。

スケジュールは、要件定義から保守までの各フェーズに必要な期間を逆算して設定します。特に要件定義と設計に十分な時間を割くことが、後工程をスムーズにするコツですが、「とにかく早く動くものを見たい」という気持ちで設計を急ぐと、後から手戻りが発生しやすくなります。全体には10〜20%程度のバッファを設けることを強くお勧めし、承認フローや関係部署のレビュー期間も考慮すると、想定外の遅延を防げます。

発注先の選び方と比較ポイント

開発会社の種類と特徴

スクラッチ開発の外注先は、大手SIer、中堅システム開発会社、Web系開発会社、フリーランスの4種類に分けられます。大手SIerは、NTTデータや富士通、NEC系などの大規模案件に強く、信頼性や体制の安定性が高い反面、費用が高めで小回りが利きにくい傾向があります。そのため、中規模以上の基幹システムや金融・公共系のシステムを発注する際に適した選択肢です。

中堅システム開発会社は、数十人規模のエンジニアを擁し、特定業界や技術分野に強みを持つ企業です。費用対効果のバランスが取りやすく、中規模のスクラッチ開発案件に向いています。特に、自社の業界と親和性の高い実績を持つ会社を選ぶと、業務理解が深まりスムーズな開発が期待できます。

Web系開発会社は、Webサービスやスマホアプリの開発を得意とするアジャイル型の会社で、スピード感があり、スタートアップや新規事業開発に適しています。フリーランスはコストを抑えられる一方で、体制面のリスクがあります。そのため、小規模かつ短期の開発に限定して活用するのが賢明です。

選定時に確認すべきチェックリスト

開発会社を選ぶ際は、まず同業界・同規模の開発実績があるかを確認します。ポートフォリオや事例ページで、自社の課題に近い案件を経験しているかどうかは、重要な判断基準です。次に確認したいのは、コミュニケーション能力と対応スピードです。

問い合わせへのレスポンスが遅い会社は、開発フェーズでもコミュニケーションに問題が生じやすい傾向があります。初回の打ち合わせでは、技術的な質問への回答のわかりやすさや、提案内容の独自性を見極めます。また、リリース後も障害対応・機能改修・セキュリティアップデートが継続的に発生するため、保守・運用体制と納品後のサポート、保守契約の条件を事前に確認します。

複数社から見積もりを取ることは必須で、同じRFPを3社以上に提示して金額・工数・技術提案内容を比べれば、市場相場の把握と最適なパートナー選びが可能になります。ただし、見積もり金額が極端に安い会社は、要件の理解が不足していたり、後から追加費用を請求するケースがあるため、注意が必要です。

発注から納品までの流れ

契約・発注フェーズ

開発会社の選定が完了したら契約フェーズに入り、スクラッチ開発の契約形態には「請負契約」と「準委任契約」の2種類があります。請負契約は、成果物（完成したシステム）に対して報酬を支払う契約で、完成責任が開発会社にある点が特徴です。一方、準委任契約は、作業そのものに対して報酬を支払う契約で、アジャイル開発や要件が変動しやすいプロジェクトで採用されることが多いです。

どちらの形態が自社プロジェクトに適しているかは、開発会社と相談しながら決めます。そのうえで、契約書には開発範囲・費用・支払条件・納期を必ず明記します。さらに、瑕疵担保責任・著作権の帰属・秘密保持・途中解約の条件も必ず明記します。

特に著作権の帰属については、契約書に「発注者に帰属する」と明記しておかないと、後からシステムを他社に保守委託したい場合や機能追加を依頼したい場合に問題が生じます。また、機密情報の扱いについては、秘密保持契約（NDA）を締結するのが一般的です。契約書の内容は、弁護士やITに詳しい法務担当者にレビューしてもらうことを強くお勧めします。

開発・検収フェーズ

契約締結後は開発フェーズが始まり、まず基本設計（要件をシステム構成に落とし込む作業）と詳細設計（画面設計・データベース設計・API設計など）が行われます。発注者は、その内容をレビューして承認します。設計段階で認識のずれを直しておくことは、後の手戻り防止に直結します。

そのため、設計書の確認には十分な時間を割き、設計が固まってからコーディング（実装）フェーズに入ります。開発中は、定期的な進捗報告の場を設け、発注者側も積極的に関与することが大切です。週次または隔週の定例ミーティングを設定し、進捗状況・課題・変更依頼などを共有します。

開発が一段落したらテストフェーズに移り、開発会社がユニットテスト・結合テスト・システムテストを実施した後、発注者側がユーザー受入テスト（UAT）を行います。UATでは、実際の業務担当者が操作して仕様通りに動作するかを確認します。検収基準を事前に書面で定めておくことで、「これは仕様内か仕様外か」という争いを防げます。

保守・運用フェーズ

保守・運用フェーズは、リリースして終わりではなく継続的に続きます。保守費用の一般的な目安はシステム開発費の約5〜15%程度で、たとえば500万円のシステムを開発した場合、年間25万円〜75万円程度の保守費用が発生する計算になります。保守契約の内容としては、障害対応（バグ修正）・セキュリティパッチ適用・OSやミドルウェアのバージョンアップ対応・軽微な機能改修などが一般的です。

保守を外注先に依頼する場合は、対応時間（平日のみか24時間か）・インシデントの優先度定義・SLA（サービスレベルアグリーメント）の取り決めを、保守契約書に明記しておきます。また、システムのソースコードやドキュメント一式は、発注者側でも保管しておくことが重要です。

万が一、保守会社との契約を解除する場合でも、資産を自社で保有していれば他社への引き継ぎがスムーズに行えます。そのほか、エスクロー契約（第三者機関にソースコードを預ける契約）を活用する方法もあります。

失敗しないための注意点

よくある失敗パターン

外注で最も典型的な失敗パターンは、要件定義の曖昧さに起因するトラブルです。「なんとなく」の漠然とした依頼では、開発会社が独自の解釈でシステムを構築してしまい、完成品を見て「思っていたものと違う」と気づいたときには、多大な費用と時間が消費されています。業務の「暗黙のルール」（取引先への特別割引、月末5日前の受注停止など）は要件定義書に落とし忘れやすく、後から「機能が足りない」という問題に発展します。

もう一つは「仕様の途中変更」で、追加要求が積み重なると、工数が大幅に増え、費用と納期が当初の見積もりを大きく超えてしまいます。たとえば、旭川医科大学と通信会社の病院情報管理システム開発では、仕様変更が止まらず開発が大幅に遅延し、最終的に契約解除と訴訟に至りました。仕様を一度確定させたら「仕様凍結」として変更管理を厳格に行うことが、このリスクを防ぐ鍵です。

また、価格だけで外注先を選んでしまうことも危険な失敗パターンです。相場より大幅に安い見積もりを提示する会社は、要件理解が不十分だったり、後から「追加工数商法」で追加費用を請求したりするケースがあります。そのため、複数社の見積もりを取り、金額だけでなく技術提案の質・コミュニケーションの丁寧さ・実績の具体性を総合的に評価して選びます。

トラブル防止策

トラブルを防ぐには、全工程で「書面での合意」を徹底することが最も効果的です。口頭では「そんな話はしていない」という争いになりがちなため、打ち合わせの内容は議事録に残し、双方が確認・承認します。また、変更依頼が出た際は必ず変更管理票を作成し、変更内容・影響範囲・追加費用・スケジュール変更を明記したうえで、承認を得てから対応を依頼します。

発注者側の窓口は一本化すべきで、部門担当者がバラバラに要望を伝えると、指示が矛盾して開発会社が優先順位を判断できなくなります。そこで、プロジェクトマネージャー（PM）またはシステム担当者を1名決め、その人が一元的に管理する体制を整えます。社内にIT知識のある人材がいない場合は、ITコンサルタントやPMOを別途活用する選択肢もあります。

「全部完成したら一気に確認する」という進め方では、最終段階で大きな問題が発覚するリスクがあるため、マイルストーンごとに部分的な成果物を確認する「段階的な検収」を取り入れます。設計完了や画面モックアップ完成、主要機能の実装完了などの節目ごとにレビューと承認を行い、問題を早い段階で修正することは、全体コストと品質管理に大きく貢献します。

まとめ

発注前の準備では、業務フローの洗い出しと要件定義、RFPの作成、現実的な予算・スケジュールの設定が必要です。次に、発注先の選定では、同業界の実績・コミュニケーション能力・保守体制を複数社で比べます。

さらに、契約フェーズでは請負か準委任かを判断し、著作権の帰属・瑕疵担保責任・著作物の扱いを契約書に明記することが不可欠です。開発中は定期的な進捗確認と段階的な成果物レビューを行い、仕様変更は変更管理を通じて厳格に管理します。

スクラッチ開発は大きな投資ですが、適切に進めれば、自社の競争力を高める手段になります。「自社専用のシステムを作りたい」という考えを実現するため、本記事で紹介した準備・発注・管理のポイントを参考にしてください。

発注先選びに迷ったら、まず複数社に相談して提案内容を比べてみてください。適切なパートナーと適切な進め方があれば、スクラッチ開発は事業の成長を支える力になります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介