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

本記事では、スクラッチ開発の発注・外注・依頼・委託方法について、要点を整理して解説します。結論として、スクラッチ開発を外注・委託するにあたって重要なポイントを振り返りましょう。まず発注前の準備として、業務フローの洗い出しと要件定義、RFPの作成、現実的な予算・スケジュールの設定が必要です。

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

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

スクラッチ開発とは、既存のパッケージソフトやフレームワークを流用せず、ゼロから独自にシステムを構築する開発手法です。自社の業務フローにぴったり合わせたシステムを作れる反面、開発期間・費用ともにパッケージ導入より大きくなる傾向があります。「自社専用のシステムが欲しいけれど、どう発注すればよいかわからない」「外注先を探しているが選定基準が曖昧で困っている」というご担当者は多く、発注フェーズの準備不足が原因でプロジェクトが迷走するケースも後を絶ちません。本記事では、スクラッチ開発を外注・委託・依頼する際の具体的な手順と、失敗しないための実践的なポイントを詳しく解説します。

スクラッチ開発の発注で最も重要なのは「発注者側の準備」です。開発会社がどれだけ優れていても、発注者が何を作りたいかを明確に言語化できていなければ、最終的な成果物は期待と大きくかけ離れたものになります。要件定義・予算・スケジュール・契約内容・検収基準まで、各フェーズで発注者がどう動くべきかを理解しておくことが、プロジェクト成功への最短ルートです。以降のセクションでは、外注のメリット・デメリットから発注後の保守・運用まで、ひとつひとつ丁寧に説明していきます。

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

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

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

スクラッチ開発を外注する最大のメリットは、自社の業務フローに完全にフィットしたシステムを構築できる点です。パッケージソフトでは「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の作成、現実的な予算・スケジュールの設定が必要です。発注先の選定では、同業界の実績・コミュニケーション能力・保守体制を複数社で比較検討します。契約フェーズでは請負か準委任かを判断し、著作権帰属・瑕疵担保責任・著作物の扱いを契約書に明記することが不可欠です。開発中は定期的な進捗確認と段階的な成果物レビューを行い、仕様変更は変更管理を通じて厳格に管理します。

スクラッチ開発は大きな投資ですが、適切に進めることで自社の競争優位性を高める強力な武器になります。「自社専用のシステムを作りたい」というビジョンを実現するために、本記事で紹介した準備・発注・管理のポイントをぜひ参考にしてください。発注先選びに迷った場合は、複数社に相談して提案内容を比較することから始めましょう。適切なパートナーと適切なプロセスで進めれば、スクラッチ開発はビジネスの大きな成長ドライバーとなります。

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