# システム開発の発注 完全ガイド：失敗しない外注先の選び方・費用相場・内製vs外注を意思決定者の視点で > システム開発・受託開発の発注で失敗しないための意思決定ガイド。費用相場と見積もりの見抜き方、内製と外注の判断軸、外注先の選び方、要件定義の進め方、品質・セキュリティの見極め方を、経済産業大臣賞を受賞したB2B SaaSや本番二重課金0件の決済基盤など実プロジェクトの知見から、発注者の視点で体系化します。 - 公開日: 2026-06-25 - 著者: 友田 陽大 - タグ: 受託開発, システム開発, 発注, DX, B2B SaaS, 技術選定, コスト最適化 - URL: https://tomodahinata.com/blog/system-development-outsourcing-guide-vendor-selection-cost ## 要点 - 発注の失敗の大半は技術力不足ではなく『要件定義の曖昧さ』と『見積もりの甘さ』に起因する——ここを先に潰す - 費用は人月（人月単価×人数×期間）で決まり、原価の約8割は人件費。相場はツール導入~10万円・カスタマイズ50~300万円・スクラッチ300万円~数千万円が目安 - 作る前に『作らない選択肢（SaaS）』を必ず潰す。スクラッチが正当化されるのは差別化の核と複雑な業務制約がある時だけ - 外注先は『技術力 × 実績』で選ぶ。冪等性・セキュリティ監査・テスト・型安全という品質ゲートを要求し、回答できる相手を選ぶ - 一人 × 生成AI は『速い・安い』だけでなく、人間による検証ゲートで『安全』を担保してこそ価値になる --- 最初に結論を述べます。**システム開発の発注で失敗する最大の原因は、技術力の不足ではありません。「要件定義の曖昧さ」と「見積もりの甘さ」です。** 発注者が最初にやるべきは、開発会社を比較することではなく、(1) 本当に作る必要があるかを見極め（SaaSで足りないか）、(2) 費用の構造を理解し、(3) 品質とセキュリティを言語化して要求できる状態になることです。この3つができていれば、発注の成否は8割決まります。 本記事は、私が実際に手がけたプロジェクト——**経済産業大臣賞を受賞したB2B SaaS**（木材流通業界のDX）、**本番稼働中の二重課金0件を維持する決済プラットフォーム**、国内大手放送局向けのエンタープライズAI基盤など——の設計判断を「唯一の真実源」として、発注者（経営者・事業責任者・情報システム担当）が損をしないための意思決定の地図を提供します。各テーマは専用記事に深掘りしているので、必要な箇所から読み進めてください。 > **数字の前提**: 本文中の相場（人月単価・開発費レンジなど）は公開されている一般的な調査・相場情報に基づく目安です。一方、私の実プロジェクトに紐づく定量値（221エンドポイント、本番二重課金0件、4ラウンドのセキュリティ監査など）はリポジトリから検証可能な実測値であり、事業ROI（売上・工数削減%）はクライアントの実データが必要なため断定しません。捏造はしない、という方針です。 --- ## 1. なぜシステム開発の発注は「半分」失敗するのか 業界では、システム開発プロジェクトの失敗率はおよそ半数とも言われます。日経BPコンサルティングなどの調査でも、当初のQCD（品質・コスト・納期）を満たせたプロジェクトは半分程度という結果が繰り返し報告されてきました。重要なのは、**その失敗のほとんどが「コードを書く前」に決まっている**という事実です。 失敗の根本原因を、私の現場経験から3つに絞ります。 | 失敗パターン | 典型的な症状 | 真因 | |---|---|---| | **要件定義の曖昧さ** | 「思っていたものと違う」「あとから仕様が膨らむ」 | 業務フローと『誰が・何を・なぜ』が言語化されないまま着手 | | **見積もりの甘さ** | 予算超過、追加費用、納期遅延 | 不確実性を含む工数を固定価格で握る／非機能要件（性能・セキュリティ・運用）が抜ける | | **丸投げと放置** | できあがったが使われない、運用で破綻 | 発注者が意思決定から降りてしまい、現場の業務と乖離する | この3つはいずれも、発注者側の準備で大きく軽減できます。逆に言えば、**開発会社の技術力をいくら比較しても、この準備を飛ばすと失敗する**ということです。Gartnerの調査によれば、B2Bの購買者は購買プロセスの約8割を営業担当と接触する前の自己学習に費やします。発注においても、発注者自身が判断軸を持っているかどうかが結果を分けます。 --- ## 2. 発注前の最重要判断：作る前に「作らない選択肢」を潰す 最もコストの高い間違いは、**SaaSで足りる業務を、わざわざスクラッチ開発してしまう**ことです。信頼できる開発パートナーの最初の仕事は、「その要件は既製のSaaSで解くべきか、作るべきか」を正直に助言することだと私は考えています。 判断はシンプルなフローで行えます。 ```text その機能は事業の差別化の核か？ ├─ No → まず SaaS / 既製品を探す（会計・勤怠・CRM・MA などは作らない） └─ Yes → 既製品で要件を満たせるか？ ├─ 満たせる → SaaS を採用し、足りない部分だけ連携・拡張する └─ 満たせない（業界特有の複雑な商流・独自の業務制約）→ スクラッチ／ハイブリッド ``` 私が手がけた木材流通DXは、後者の典型でした。「林業 → 市場 → 製材所 → プレカット → 工務店 → メーカー」という多段の商流、業種ごとに異なる権限、企業をまたぐ取引とテナント分離——これらは既製のグループウェアやECでは表現できず、スクラッチが正当化されました。一方で、認証はAWS Cognito、決済はStripe Connectという**既製の基盤を最大限使い、自前で作るのは『業界固有のロジックだけ』に絞る**ハイブリッド戦略を取っています。 この「内製 vs 外注」「SaaS vs スクラッチ」の意思決定は、発注の成否を最も大きく左右します。判断フレームワークは別記事で詳説しています。 --- ## 3. 費用の構造と相場：見積もりは「人月」で決まる 発注者が最も不安を感じるのが費用です。日本のシステム開発費は、ほぼ例外なく**人月（にんげつ）**で決まります。 ```text 開発費 ≒ 人月単価 × 投入人数 × 期間（月） ``` そして、その**原価の約8割は人件費**です。つまり「高い／安い」は、本質的には「何人が、何ヶ月、どの単価で関わるか」の問題です。人月単価の目安は、おおよそ次の通りです。 | 役割・水準 | 人月単価の目安 | |---|---| | 初級〜中堅エンジニア（一般的な受託） | 60〜100万円 | | 上級・テックリード級 | 100〜160万円 | | 大手SIer・コンサル | 150万円以上 | 開発規模ごとの総額レンジの目安は次の通りです（あくまで一般的な相場で、要件で大きく変動します）。 | 開発タイプ | 費用レンジの目安 | 例 | |---|---|---| | SaaS導入・設定 | 〜10万円程度 | 既製ツールの導入・初期設定 | | カスタマイズ・小規模 | 50〜300万円 | 既製品の拡張、小規模な業務アプリ | | スクラッチ・中〜大規模 | 300万円〜数千万円 | 業務システム新規開発、B2B SaaS | **見積もりを見抜く鍵は、金額の大小ではなく「内訳」と「非機能要件の有無」です。** 安い見積もりは、たいてい以下が抜けています。 - **非機能要件**：性能、可用性、セキュリティ、監視・運用、障害復旧（DR） - **品質保証**：テスト、コードレビュー、セキュリティ監査 - **運用・保守**：本番リリース後の保守費（一般に開発費の年15%前後が目安） 「最初の見積もりは安かったが、運用で破綻した」という失敗は、ここが抜けていることがほとんどです。見積もりの読み解き方とコスト最適化は専用記事で詳説します。 --- ## 4. 外注先の選び方：「技術力 × 実績」で見極める 日本のB2B発注者が開発会社を選ぶとき、最重視するのは**技術力と実績**です。アグリゲーター（発注ナビ、アイミツ等）で会社を並べる前に、次のチェックリストで相手を評価してください。 ### 発注先評価チェックリスト - [ ] **公開された具体的な実績がある**か（プロジェクトの規模・技術スタック・成果が説明できる） - [ ] **作らない提案ができる**か（SaaSで足りる部分を正直に言えるか。何でも「作れます」は危険信号） - [ ] **非機能要件を自分から聞いてくる**か（性能・セキュリティ・運用・DRを要件定義で詰めるか） - [ ] **品質ゲートを言語化できる**か（テスト・型安全・CI/CD・セキュリティ監査の具体） - [ ] **運用・保守まで責任を持つ**か（作って終わりではないか） - [ ] **見積もりの内訳が透明**か（人月の根拠、非機能要件の費用が明示されているか） ### 「一人 × 生成AI で大丈夫？」という当然の不安に答える 近年、私のような**一人（少人数）× 生成AI を活用した開発者**への発注が増えています。「速くて安い」一方で、発注者が当然抱くのが「一人で品質は大丈夫か」「属人化しないか」という不安です。これは正しい問いです。 私の答えは、**「速い・安い」を可能にするのは生成AIだが、『安全』を担保するのは人間による検証ゲートだ**、というものです。生成AIはコードを書く速度を上げますが、その出力を**そのまま信用しない仕組み**——型安全な境界での検証、自動テスト、静的解析、セキュリティスキャン、そして第三者によるペネトレーションテスト——を多層で通すことで、初めて本番品質になります。 これは抽象論ではありません。木材流通DXでは、**実在15ロールでの第三者ペネトレーションテストを含む4ラウンドのセキュリティ監査**を経て、全221エンドポイントの認証欠落0件を実証しました。決済基盤では、冪等性と原子的トランザクションという**コードの構造**によって、本番稼働中の二重課金を0件に保っています。「AIが書いたから速い」ではなく、「**検証で固めているから、速くても安全**」——これが発注者に提示すべき品質の根拠です。 --- ## 5. 失敗しない要件定義と「段階的導入」 要件定義の曖昧さが最大の失敗要因である以上、ここに最もエネルギーを注ぐべきです。とはいえ、最初から完璧な要件を書ける発注者はいません。重要なのは、**「いきなり全面移行しない」**ことです。 レガシーな業務（電話・FAX・Excel）をシステム化する場合、私は次の段階的導入を推奨しています。 ```text Phase 1（1〜3ヶ月）: 情報共有・可視化のみ（既存のExcel併用OK） ↓ 現場が「これは便利だ」と実感する Phase 2（4〜6ヶ月）: 一部業務（発注など）を移行（Excel併用） ↓ 併存させ、移行リスクを下げる Phase 3（7〜12ヶ月）: 全面移行（旧フローを段階的に廃止） ``` いきなり全面移行すると、現場が混乱して「使われないシステム」になります。**併存期間を設けて現場の納得を積み上げる**——これが、特にレガシー産業のDXで成否を分けます。木材DXでも、既存のExcelをそのままアップロードしてDB化できる導線を作り、現場が慣れた道具を捨てずに移行できる設計にしました。レガシー業務のDXの始め方は専用記事で詳説します。 --- ## 6. 品質・セキュリティの見極め：発注者が要求すべき「4つの構造」 「動くもの」と「本番運用に耐え、第三者の攻撃と監査に耐えるシステム」の差は、見た目ではわかりません。発注者は、次の4つを**仕組み（構造）として持っているか**を要求すべきです。これは私が全プロジェクトで一貫して作り込んでいる差別化要素でもあります。 | 要求すべき構造 | なぜ重要か | 具体例 | |---|---|---| | **冪等性（べきとうせい）** | ネットワーク断やリトライで処理が二重に走っても、結果が1回に収束する | 決済の二重課金防止、Webhookの重複排除 | | **型安全・境界検証** | 不正なデータを「表現不能」にして、バグを構造的に減らす | TypeScript/Zodで外部入力を検証、`any`禁止 | | **テストとCI/CD** | 人手のレビューに頼らず品質を機械的に維持する | 自動テスト、型チェック、セキュリティスキャンをCIで強制 | | **セキュリティ監査** | 攻撃者・監査人の視点で穴を塞いだ証跡がある | ペネトレーションテスト、受容リスクの台帳化 | たとえば決済では、「金額をサーバ側で再計算する」「冪等性キーで二重実行を防ぐ」「Webhookを条件付き書き込みで重複排除する」という**コードの構造**で正しさを保証します。運用の注意深さに頼ると、いつか必ず事故が起きます。決済・課金システムを発注する際の具体的なチェックリストは専用記事にまとめています。 --- ## 7. 「一人 × 生成AI」という発注の選択肢 最後に、発注の体制について。従来は「大手SIerに大きく頼む」か「複数人のチームを抱える受託会社に頼む」かでした。そこに第三の選択肢として、**一人（少人数）× 生成AI で、要件定義からインフラ・セキュリティ・運用までワンストップで担う**スタイルが現実的になっています。 この選択肢が向くのは、次のようなケースです。 - **スピードとコストが重要**な新規事業・MVP・業務システム - **意思決定者と直接対話**しながら、要件を素早く回したい - **フルスタックで一気通貫**に任せ、会社間の調整コストを削りたい 逆に、超大規模・多数の関係者調整が前提のプロジェクトは、大手の体制が向きます。**「速い・安い」と「大規模な体制」はトレードオフ**であり、正直にそれを言える相手こそ信頼できます。 > **発注者への提案**: 私は、要件定義・設計・フロントエンド・バックエンド・インフラ（AWS/GCP/Terraform）・セキュリティ・運用までを一人で一気通貫に担い、その品質を「型安全・テスト・セキュリティ監査・冪等性」という検証ゲートで担保します。経済産業大臣賞を受賞したB2B SaaS、本番二重課金0件の決済基盤、クラウドワークス契約ランキング1位のAI動画基盤——これらは、すべて同じ「速く作るが、検証で固める」という方針の産物です。 --- ## よくある質問（FAQ） ### Q. システム開発の費用はどれくらいが相場ですか？ 費用は「人月単価 × 人数 × 期間」で決まり、原価の約8割が人件費です。目安として、SaaS導入は〜10万円程度、既製品のカスタマイズや小規模アプリは50〜300万円、業務システムやB2B SaaSのスクラッチ開発は300万円〜数千万円です。ただし、性能・セキュリティ・運用などの非機能要件で大きく変動します。安すぎる見積もりは、これらが抜けている可能性を疑ってください。 ### Q. 内製と外注、どちらが良いですか？ 事業の差別化の核となる機能で、長期に育て続ける必要があるなら内製寄り。専門性が高く一時的・スポット的な構築なら外注が有利です。ただし多くの中小企業では、まず既製のSaaSで足りないかを確認し、足りない部分だけを外注（または一人×AIで一気通貫）するのが最もコスト効率に優れます。 ### Q. 一人の開発者に発注して、品質や属人化は大丈夫ですか？ 「速い・安い」を可能にするのは生成AIですが、「安全」を担保するのは人間による検証ゲートです。自動テスト、型安全な境界検証、CI/CD、セキュリティ監査（ペネトレーションテストを含む）を多層で通すことで、少人数でも本番品質を実現できます。発注時は「どんな品質ゲートを通すか」を具体的に説明できるかを確認してください。 ### Q. 発注で失敗しないために、発注者は何を準備すべきですか？ (1) 本当に作る必要があるか（SaaSで足りないか）を見極める、(2) 費用の構造（人月・非機能要件）を理解する、(3) 要求する品質・セキュリティを言語化する——この3つです。これができていれば、発注の成否は8割決まります。いきなり全面移行せず、段階的に導入することも重要です。 ### Q. レガシーな業務（電話・FAX・Excel）もシステム化できますか？ できます。鍵は「いきなり全面移行しない」こと。情報共有・可視化から始め、現場が便利さを実感したうえで、発注などの業務を段階的に移行します。既存のExcelをそのまま取り込める導線を用意するなど、現場が慣れた道具を捨てずに移行できる設計が成功の条件です。 --- ## まとめ：発注の成否は「コードを書く前」に8割決まる システム開発の発注で損をしないために、発注者が押さえるべきは次の5点です。 1. **失敗の真因は技術力ではなく、要件定義の曖昧さと見積もりの甘さ**——ここを先に潰す。 2. **作る前に「作らない選択肢（SaaS）」を必ず潰す**——スクラッチは差別化の核だけに絞る。 3. **費用は人月で決まり、原価の8割は人件費**——金額より「内訳と非機能要件」を見る。 4. **外注先は「技術力 × 実績」で選び、品質ゲートを要求できる相手を選ぶ**。 5. **一人 × 生成AI は「速い・安い」だけでなく、検証ゲートで「安全」を担保してこそ価値**。 私は、レガシー産業のDX、B2B SaaSの新規開発・立て直し、決済・課金基盤、生成AIの業務導入まで、要件定義からインフラ・セキュリティ・運用まで、この水準でワンストップにお引き受けします。発注をご検討中でしたら、まずは現状の課題と「作るべきか・作らざるべきか」から一緒に整理しましょう。