システム開発の発注 完全ガイド：失敗しない外注先の選び方・費用相場・内製vs外注を意思決定者の視点で

最初に結論を述べます。システム開発の発注で失敗する最大の原因は、技術力の不足ではありません。「要件定義の曖昧さ」と「見積もりの甘さ」です。 発注者が最初にやるべきは、開発会社を比較することではなく、(1) 本当に作る必要があるかを見極め（SaaSで足りないか）、(2) 費用の構造を理解し、(3) 品質とセキュリティを言語化して要求できる状態になることです。この3つができていれば、発注の成否は8割決まります。

本記事は、私が実際に手がけたプロジェクト——経済産業大臣賞を受賞したB2B SaaS（木材流通業界のDX）、本番稼働中の二重課金0件を維持する決済プラットフォーム、法人向けのエンタープライズAI基盤など——の設計判断を「唯一の真実源」として、発注者（経営者・事業責任者・情報システム担当）が損をしないための意思決定の地図を提供します。各テーマは専用記事に深掘りしているので、必要な箇所から読み進めてください。

数字の前提: 本文中の相場（人月単価・開発費レンジなど）は公開されている一般的な調査・相場情報に基づく目安です。一方、私の実プロジェクトに紐づく定量値（221エンドポイント、本番二重課金0件、4ラウンドの自主セキュリティ監査など）はリポジトリから検証可能な実測値であり、事業ROI（売上・工数削減%）はクライアントの実データが必要なため断定しません。捏造はしない、という方針です。

1. なぜシステム開発の発注は「半分」失敗するのか

日経コンピュータのプロジェクト実態調査（2018年3月1日号）では、1,745件のシステム導入／刷新プロジェクトのうち「成功」は52.8％、「失敗」は47.2％でした。ここでの「成功」は、スケジュール・コスト・満足度の3条件をすべて満たしたものと定義されています。

この「満足度」が入るかどうかが、実は数字を大きく動かします。同じ日経コンピュータの2014年10月16日号の調査では、成功を「当初予定していた品質・予算・納期（QCD）を順守できた」と定義したところ、成功率は75％でした。つまり——

納期と予算は守られたのに、使う人が満足していないプロジェクトが2割前後ある。

これが「発注の失敗」の実像に最も近い姿です。技術的に破綻したのではなく、できあがったものが求めていたものと違った。そしてその原因は、ほとんどが「コードを書く前」に決まっています。

失敗の根本原因を、私の現場経験から3つに絞ります。

この3つはいずれも、発注者側の準備で大きく軽減できます。逆に言えば、開発会社の技術力をいくら比較しても、この準備を飛ばすと失敗するということです。Gartner の調査では、B2B購買者が検討期間中に供給者候補との面談に充てる時間は全体の17％にとどまります。複数社を比較していれば、1社あたりに割かれる時間はさらにその一部です。商談の場で得られる情報だけで判断軸を作るのは、そもそも時間的に無理がある——だからこそ、発注者自身が事前に軸を持っているかどうかが結果を分けます。

2. 発注前の最重要判断：作る前に「作らない選択肢」を潰す

最もコストの高い間違いは、SaaSで足りる業務を、わざわざスクラッチ開発してしまうことです。信頼できる開発パートナーの最初の仕事は、「その要件は既製のSaaSで解くべきか、作るべきか」を正直に助言することだと私は考えています。

判断はシンプルなフローで行えます。

その機能は事業の差別化の核か？
├─ No  → まず SaaS / 既製品を探す（会計・勤怠・CRM・MA などは作らない）
└─ Yes → 既製品で要件を満たせるか？
          ├─ 満たせる → SaaS を採用し、足りない部分だけ連携・拡張する
          └─ 満たせない（業界特有の複雑な商流・独自の業務制約）→ スクラッチ／ハイブリッド

私が手がけた木材流通DXは、後者の典型でした。「林業 → 市場 → 製材所 → プレカット → 工務店 → メーカー」という多段の商流、業種ごとに異なる権限、企業をまたぐ取引とテナント分離——これらは既製のグループウェアやECでは表現できず、スクラッチが正当化されました。一方で、認証はAWS Cognito、決済はStripe Connectという既製の基盤を最大限使い、自前で作るのは『業界固有のロジックだけ』に絞るハイブリッド戦略を取っています。

この「内製 vs 外注」「SaaS vs スクラッチ」の意思決定は、発注の成否を最も大きく左右します。判断フレームワークは別記事で詳説しています。

3. 費用の構造と相場：見積もりは「人月」で決まる

発注者が最も不安を感じるのが費用です。日本のシステム開発費は、ほぼ例外なく人月（にんげつ）で決まります。

開発費 ≒ 人月単価 × 投入人数 × 期間（月）

そして、その原価の約8割は人件費です。つまり「高い／安い」は、本質的には「何人が、何ヶ月、どの単価で関わるか」の問題です。人月単価の目安は、おおよそ次の通りです。

開発規模ごとの総額レンジの目安は次の通りです（あくまで一般的な相場で、要件で大きく変動します）。

見積もりを見抜く鍵は、金額の大小ではなく「内訳」と「非機能要件の有無」です。 安い見積もりは、たいてい以下が抜けています。

• 非機能要件：性能、可用性、セキュリティ、監視・運用、障害復旧（DR）
• 品質保証：テスト、コードレビュー、セキュリティ監査
• 運用・保守：本番リリース後の保守費（一般に開発費の年15%前後が目安）

「最初の見積もりは安かったが、運用で破綻した」という失敗は、ここが抜けていることがほとんどです。見積もりの読み解き方とコスト最適化は専用記事で詳説します。

4. 外注先の選び方：「技術力 × 実績」で見極める

日本のB2B発注者が開発会社を選ぶとき、最重視するのは技術力と実績です。アグリゲーター（発注ナビ、アイミツ等）で会社を並べる前に、まず依頼先の種類ごとに「何がリスクになるか」を押さえ、そのうえで後述のチェックリストで相手を評価してください。

依頼先は5種類ある：それぞれ引き受けるリスクが違う

「どこに頼むか」は優劣の問題ではなく、どのリスクを誰が持つかの選択です。会社が大きいほど安全、個人だから危険、という単純な話ではありません。

私自身はこの表の最後の行（個人）にあたり、クラウドソーシング経由で受けた案件もあります。だからこそ、個人に頼むときのリスクは正直に書いておきます。

個人（フリーランス）に直接頼むときのリスクと、契約・技術での潰し方

「個人に頼むと飛ぶ」「コードを人質に取られる」「結局、経営判断まで丸投げされる」——個人への外注でよく聞く不安は、どれも実際に起きうることです。ただし、多くは契約と名義の設計で構造的に防げます（丸投げは第6章で扱います）。

もう一つ、法律上の義務も押さえておきます。従業員を使用しない個人などに業務を委託する事業者は、委託したら直ちに、給付の内容・報酬の額・支払期日などを書面または電磁的方法で明示しなければなりません（特定受託事業者に係る取引の適正化等に関する法律 第2条・第3条）。受注者を守るための法律ですが、条件を書面に残すこと自体が、発注者を「言った・言わない」から守ります。

発注先評価チェックリスト

• 公開された具体的な実績があるか（プロジェクトの規模・技術スタック・成果が説明できる）
• 作らない提案ができるか（SaaSで足りる部分を正直に言えるか。何でも「作れます」は危険信号）
• 非機能要件を自分から聞いてくるか（性能・セキュリティ・運用・DRを要件定義で詰めるか）
• 品質ゲートを言語化できるか（テスト・型安全・CI/CD・セキュリティ監査の具体）
• 運用・保守まで責任を持つか（作って終わりではないか）
• 見積もりの内訳が透明か（人月の根拠、非機能要件の費用が明示されているか）

「一人 × 生成AI で大丈夫？」という当然の不安に答える

近年、私のような一人（少人数）× 生成AI を活用した開発者への発注が増えています。「速くて安い」一方で、発注者が当然抱くのが「一人で品質は大丈夫か」「属人化しないか」という不安です。これは正しい問いです。

私の答えは、「速い・安い」を可能にするのは生成AIだが、『安全』を担保するのは人間による検証ゲートだ、というものです。生成AIはコードを書く速度を上げますが、その出力をそのまま信用しない仕組み——型安全な境界での検証、自動テスト、静的解析、セキュリティスキャン、そしてペネトレーションテスト——を多層で通すことで、初めて本番品質になります。

これは抽象論ではありません。木材流通DXでは、実在15ロールでのペネトレーションテストを含む4ラウンドの自主セキュリティ監査を経て、全221エンドポイントの認証欠落0件を実証しました。決済基盤（主要開発者3名のチーム開発で、私が信頼性レイヤーを主導）では、冪等性と原子的トランザクションというコードの構造によって、本番稼働中の二重課金を0件に保っています。「AIが書いたから速い」ではなく、「検証で固めているから、速くても安全」——これが発注者に提示すべき品質の根拠です。

ただし、もう一方の不安である属人化（その人がいなくなったら止まる）は、品質とは別の問題で、検証ゲートでは防げません。防ぐのは名義と納品物の設計です。具体的な項目は第7章のチェックリストにまとめました。私が個人として外部の開発責任者を引き受ける場合の名義と納品物の扱いは、CTO代行・外部開発責任者のページにまとめています。

5. 失敗しない要件定義と「段階的導入」

要件定義の曖昧さが最大の失敗要因である以上、ここに最もエネルギーを注ぐべきです。とはいえ、最初から完璧な要件を書ける発注者はいません。重要なのは、「いきなり全面移行しない」ことです。

レガシーな業務（電話・FAX・Excel）をシステム化する場合、私は次の段階的導入を推奨しています。

Phase 1（1〜3ヶ月）: 情報共有・可視化のみ（既存のExcel併用OK）
   ↓  現場が「これは便利だ」と実感する
Phase 2（4〜6ヶ月）: 一部業務（発注など）を移行（Excel併用）
   ↓  併存させ、移行リスクを下げる
Phase 3（7〜12ヶ月）: 全面移行（旧フローを段階的に廃止）

いきなり全面移行すると、現場が混乱して「使われないシステム」になります。併存期間を設けて現場の納得を積み上げる——これが、特にレガシー産業のDXで成否を分けます。木材DXでも、既存のExcelをそのままアップロードしてDB化できる導線を作り、現場が慣れた道具を捨てずに移行できる設計にしました。レガシー業務のDXの始め方（Excel管理が限界に来ているサイン、移行先の選び方、FAX受注の段階的な電子化）はExcel管理の限界と脱エクセルの進め方で詳説しています。

6. 「丸投げ」で失敗しないために：外注しても発注者が手放してはいけないもの

「技術のことは分からないので、全部お任せします」——この一言から始まる発注は、しばしば「思っていたものと違う」に着地します。受注者がどれほど優秀でも、事業の判断だけは代われないからです。判断の材料が渡されないまま作業が進むと、受注者は空白を推測で埋めるしかなく、推測が外れたぶんだけ作り直しが発生します。

技術を任せることと、判断を任せることは別物です。線引きは次のとおりです。

特に検収の合格基準は、発注者が手放した瞬間に「受注者が自分で決めた基準で、自分の成果物を合格にする」構造になります。基準は発注前に言語化し、受注者には「その基準を満たすことを示すテスト」を作ってもらう——この役割分担なら、技術が分からなくても検収の主導権は発注者に残ります。検収の具体的な進め方はシステム開発の検収 実務ガイドで扱っています。

実務では、次の3つを最初に決めておくと丸投げを防げます。

1. 意思決定者を1人に決める——窓口が複数いると、受注者は誰の指示が最終なのか分からなくなります。
2. 決める場を定例にする——週に一度、意思決定者が出る短い定例で、優先順位と保留事項を決めます。技術の細部ではなく「今週、何を決める必要があるか」を受注者に整理してもらうのがコツです。
3. 決めたことを書いて残す——議事メモや課題管理ツールに決定事項を残します。言った・言わないを防ぐだけでなく、担当者が替わっても判断の経緯を引き継げます。

丸投げは発注者側だけでなく、受注者側にも起きます（言われたとおりに作り、業務を理解しようとしない）。双方向の丸投げを含む頓挫のパターンと、それを起こさない相手の見抜き方は失敗しない開発会社の選び方 — 頓挫の典型パターンから逆算するで詳しく扱っています。

7. 契約初日から発注者が持つべきものチェックリスト

どの依頼先を選んでも、次のものが契約初日から発注者の名義・手元にあれば、相手が倒れても、関係が終わっても、事業は止まりません。逆に1つでも相手の名義のままだと、それが交渉の「人質」になりえます。契約書のレビューと一緒に確認してください。

• ソースコードのリポジトリが自社のGitHub組織（Organization）にあり、受注者は外部コラボレーターとして参加している
• クラウドアカウント（AWS・Google Cloud など）が自社名義で、請求も自社に来る。受注者には作業に必要な権限だけを付与している
• ドメインとDNSの登録者・管理アカウントが自社名義になっている
• インフラがIaC（Terraformなど）でコード化され、別のエンジニアが同じ環境を作り直せる
• 運用手順書（Runbook）がある：デプロイ、切り戻し、障害時の一次対応、バックアップからの復旧
• 環境変数の一覧がある：どの設定値が何に使われ、どこに保管されているか（秘密情報そのものではなく、名前・用途・保管場所の一覧）
• 主要な業務フローに自動テストとCIがあり、変更のたびに自動で検証される
• 管理者権限（本番データベース、決済サービス、メール配信、各SaaSの管理画面など）のオーナーが自社で、受注者には個人ごとのアカウントを発行している（共有アカウントにしない）
• 著作権の条項：成果物の著作権を発注者へ譲渡すると明記している。譲渡の条文に著作権法第27条・第28条の権利（翻案権など）を書き込まないと、それらは譲渡した側に残ると推定される（著作権法第61条2項）
• 契約不適合責任の期間（請負の場合）：検収後に見つかった不具合を、いつまで無償で直してもらえるか。民法の原則は「不適合を知った時から1年以内に通知」（第637条）だが、実務では「検収後○ヶ月」と契約で定めることが多い

このうち後から取り戻すのが最も大変なのは、リポジトリ・クラウド・ドメインの名義です。最初に相手の名義で作られると、移管には相手の協力が要ります。最初から自社名義なら、契約の終了は「相手の権限を外す」だけで済みます。契約形態ごとの著作権・契約不適合責任の詳細は請負・準委任・ラボ型 — システム開発の契約形態の選び方で解説しています。

私の進め方: 私が受ける案件では、リポジトリとクラウドアカウントを契約初日から発注者名義で作り、私はコラボレーター権限で作業します。契約が終わるときは、私の権限を外していただくだけです。成果物の著作権は、原則として発注者に帰属します（汎用的なライブラリ・テンプレート部分の扱いは個別契約書で明示します）。README・構成図・環境変数一覧・運用手順書（Runbook）は追加費用なしの標準納品物で、インフラはTerraformなどのIaCで管理し、主要フローの自動テストとCIも標準で納品します。請負の場合は、検収後3ヶ月以内に見つかった不具合を無償で修正します（契約不適合責任。期間などの条件は契約ごとに調整できます）。

8. 品質・セキュリティの見極め：発注者が要求すべき「4つの構造」

「動くもの」と「本番運用に耐え、第三者の攻撃と監査に耐えるシステム」の差は、見た目ではわかりません。発注者は、次の4つを仕組み（構造）として持っているかを要求すべきです。これは私が全プロジェクトで一貫して作り込んでいる差別化要素でもあります。

たとえば決済では、「金額をサーバ側で再計算する」「冪等性キーで二重実行を防ぐ」「Webhookを条件付き書き込みで重複排除する」というコードの構造で正しさを保証します。運用の注意深さに頼ると、いつか必ず事故が起きます。決済・課金システムを発注する際の具体的なチェックリストは専用記事にまとめています。

9. 「一人 × 生成AI」という発注の選択肢

最後に、発注の体制について。従来は「大手SIerに大きく頼む」か「複数人のチームを抱える受託会社に頼む」かでした。そこに第三の選択肢として、一人（少人数）× 生成AI で、要件定義からインフラ・セキュリティ・運用までワンストップで担うスタイルが現実的になっています。

この選択肢が向くのは、次のようなケースです。

• スピードとコストが重要な新規事業・MVP・業務システム
• 意思決定者と直接対話しながら、要件を素早く回したい
• フルスタックで一気通貫に任せ、会社間の調整コストを削りたい

逆に、超大規模・多数の関係者調整が前提のプロジェクトは、大手の体制が向きます。「速い・安い」と「大規模な体制」はトレードオフであり、正直にそれを言える相手こそ信頼できます。

発注者への提案: 私は、要件定義・設計・フロントエンド・バックエンド・インフラ（AWS/GCP/Terraform）・セキュリティ・運用までを一人で一気通貫に担い、その品質を「型安全・テスト・セキュリティ監査・冪等性」という検証ゲートで担保します。経済産業大臣賞を受賞したB2B SaaS（全工程を一人で担当）、本番二重課金0件の決済基盤（チーム開発で信頼性レイヤーを主導）、クラウドワークスの週間契約ランキングで1位を獲得したAI動画基盤（一人で担当）——体制は違っても、すべて同じ「速く作るが、検証で固める」という方針の産物です。

まとめ：発注の成否は「コードを書く前」に8割決まる

システム開発の発注で損をしないために、発注者が押さえるべきは次の7点です。

1. 失敗の真因は技術力ではなく、要件定義の曖昧さと見積もりの甘さ——ここを先に潰す。
2. 作る前に「作らない選択肢（SaaS）」を必ず潰す——スクラッチは差別化の核だけに絞る。
3. 費用は人月で決まり、原価の8割は人件費——金額より「内訳と非機能要件」を見る。
4. 外注先は「技術力 × 実績」で選び、品質ゲートを要求できる相手を選ぶ。依頼先の種類（SIer・開発会社・マッチングサイト経由・クラウドソーシング・個人）は優劣ではなく、引き受けるリスクの違い。
5. 丸投げしない——技術は任せても、優先順位の決定と検収の合格基準は発注者が持ち続ける。
6. リポジトリ・クラウド・ドメインは契約初日から発注者名義に——運用手順書・環境変数一覧・IaC・自動テストまで揃えば、相手が誰でも引き継げる。
7. 一人 × 生成AI は「速い・安い」だけでなく、検証ゲートで「安全」を担保してこそ価値。

なお、発注の最後にもう一つ山があります——検収です。支払い義務と責任追及の期限がここで確定するにもかかわらず、発注者は納品物の中身を読めません。その非対称をどう埋めるかはシステム開発の検収 実務ガイドで扱っています。資金面で補助金の活用を検討している場合は、補助金でシステム開発を外注する完全ガイドもあわせてご覧ください（制度は「交付決定前の着手」が原則NGなので、発注スケジュールの前提が変わります）。

私は、レガシー産業のDX、B2B SaaSの新規開発・立て直し、決済・課金基盤、生成AIの業務導入まで、要件定義からインフラ・セキュリティ・運用まで、この水準でワンストップにお引き受けします。発注をご検討中でしたら、まずは現状の課題と「作るべきか・作らざるべきか」から一緒に整理しましょう。