「開発を外部に任せたいが、どの工程から外注すべきか判断軸がない」。社内のリソースや知見が限られるなかで、開発のどこを内製し、どこを外に出すかは悩ましいテーマです。実際、当社がプロジェクトリーダー300名に行った調査（以下、PL300名調査）でも、外注活用時の課題として「社内の人材が育たない（39.0%）」が上位に挙がりました。本記事では、ソフトウェア開発の標準的な流れ（5工程）を踏まえ、工程ごとに「外注に向くか／向かないか」を判断するための具体的なマトリクスと考え方を整理します。
基本のおさらい
ソフトウェア開発は、一般的に「要件定義 → 設計 → 実装 → テスト → 運用・保守」という工程で進みます。多くの方が「開発＝実装（コーディング）」をイメージしますが、実際にはその前後に、意思決定や品質を左右する工程が連なっています。
本記事では、この5工程のうち「どこを外注し、どこを内製で握るべきか」という発注設計の意思決定にフォーカスします。全部を一括で外注するか／全部内製するかの二択ではなく、工程ごとに最適な分担を考えるのが本記事の立場です。
失敗は「どの工程を外注したか」で決まる
「どこから外注すべきか」を誤ると、外注は失敗します。PL300名調査（株式会社STELAQ調べ）で、外注活用時の主な課題として挙がったのは次の4つでした。
| 外注活用時の主な課題 | 回答率 | 工程の切り分けを誤ると… |
|---|---|---|
| 品質への不安 | 52.3% | 品質基準を決めずにテストまで丸投げし、受け入れ時にトラブル |
| 属人性 | 41.7% | 特定工程をベンダー任せにし、社内が状況を把握できない |
| 社内人材が育たない | 39.0% | 実装を全て外に出し、自社に技術知見が残らない |
| 理解の齟齬 | 34.3% | 要件定義を外部に丸投げし、認識ずれが後工程に波及 |
ここから読み取れる原則はシンプルです。意思決定と品質基準を握る工程（要件定義・受け入れ）は内製で主導し、作業負荷が大きく仕様が定まった工程（実装・一部テスト）は外注の効果が出やすい——。ただし、これは自社の内製スキルとリソースによって変わります。次章で工程別に整理します。
工程別「外注可否チェックリスト」を無料配布
5つの開発工程それぞれについて、外注に向く条件・内製で握るべき条件・発注時の確認項目を整理した資料「システム開発プロジェクトリーダー300名に聞いた外注活用のポイント」を無料でダウンロードいただけます。自社の工程分担を整理する叩き台としてご活用ください。
工程別・外注判断の考え方
工程ごとに「外注の向き不向き」を分ける要因は、(A) 意思決定の重さ、(B) 仕様の確定度、(C) 自社に残すべき知見か、の3つです。これを踏まえ、5工程を順に見ていきます。
- 要件定義：原則「内製主導」、ただし伴走支援は有効。最も意思決定が重く、後工程すべてを左右する工程。丸投げ外注は最も危険です。ノウハウや工数が不足する場合は、ベンダーと共同で進める「伴走型」が有効。主導権は手放さず、技術検証や整理を支援してもらう形が安全です。なお、STELAQはISO 26262・A-SPICE準拠の自動車開発などで、要件定義・設計を含む上流工程から参画してきた実績があります。内製リソースが不足する場合は、上流から一気通貫で伴走することも可能です。
- 設計：基本設計は共同で、詳細設計は分担可。アーキテクチャや方式を決める基本設計は、将来の保守性・拡張性に直結するため共同で。詳細設計は仕様が固まっていれば外注しやすい工程です。
- 実装：外注効果が最も出やすい。仕様が確定していれば、コスト・スピードの両面で外注メリットが大きい工程。チーム派遣で内製チームと協働すれば、ナレッジを社内に残しながらリソースを補えます。
- テスト：品質基準は内製で定義、実行は専門化。何を品質とするか（テスト観点・受け入れ基準）は発注側で定義します。テスト実行や第三者検証は、専門性を持つ外部に任せることで客観性と網羅性が高まります。
- 運用・保守：継続性とナレッジ移管が鍵。属人化を避けるため、ドキュメントとナレッジ移管を前提に。長期の安定運用を見据え、開発時から保守を意識した体制づくりが重要です。
重要なのは「全部外注」でも「全部内製」でもなく、工程ごとに最適な分担を設計することです。
工程別 外注可否マトリクス
ここまでの考え方を一枚に整理します。自社の内製スキルとリソースに応じて読み替えてください。
| 工程 | 外注の向き | 内製で握るべき点 | 推奨スタイル |
|---|---|---|---|
| 要件定義 | △（丸投げ不可） | 意思決定・優先順位づけ | 伴走型（共同） |
| 基本設計 | △ | アーキテクチャ方針 | 伴走型（共同） |
| 詳細設計 | ○ | 仕様レビュー | 請負／伴走 |
| 実装 | ◎ | 受け入れ基準の定義 | チーム派遣／請負 |
| テスト | ◎（専門化） | テスト観点の定義 | 第三者検証 |
| 運用・保守 | ○ | 重要ナレッジの保持 | 準委任／保守契約 |
◎=外注効果が高い ／ ○=条件付きで有効 ／ △=主導権を握りつつ伴走が安全。
※要件定義・基本設計は、一般には発注側が主導する（内製主導）のが原則です。ただしSTELAQは、ISO 26262・A-SPICEなどの規格対応を伴う開発で、要件定義・設計を含む上流工程から開発・検証までを一気通貫で支援した実績があります。「上流は外部に任せられない」とあきらめる前に、体制づくりのご相談から承ります。
当社の導入事例
工程ごとに外部を使い分けた（あるいは上流から一貫して担った）支援事例を2件紹介します。
事例1｜証券会社：テスト工程を第三者検証で外注
- 業界・規模
- 外資系証券会社／証券取引スマートフォンアプリの機能改修
- 課題
- 結合テストで機能的な不具合が多く見つかり、品質への懸念を払拭したい。競争が激しく新商品のリリース頻度も高いため、品質と効率化の両立が求められた。
- 支援内容
- 品質基準・テスト観点は共有したうえで、STELAQが第三者観点での機能試験・多端末試験を担当。社内テストラボで実機検証を行い、試験仕様書の作成から不具合傾向の分析までを実施。
- 成果
- 品質を担保しつつ、担当者が驚くスピード感でテストを支援。使いやすさに配慮したUI/UXの設計にも貢献した。
事例2｜自動車：A-SPICE準拠で、BEVのECU評価体制を立ち上げから構築
- 業界・規模
- 大手自動車メーカー／次世代BEV（電気自動車）のECUソフトウェア開発（組込み・SDV）
- 課題
- SDV化で開発が高度化するなか、ISO 26262・A-SPICE準拠の品質プロセスに則った評価体制を、プロジェクトの立ち上げ期から築く必要があった。
- 支援内容
- STELAQが立ち上げ期（上流）からプロジェクトに参画し、ECUソフトウェアの評価体制をゼロから構築。HILSシミュレーション環境・ECU評価を担当し、ISO 26262／A-SPICE準拠のプロセスに則って評価工程を安定的に推進した。要件定義・設計を含む上流工程から関与できるのがSTELAQの強みです。
- 成果
- 担当する評価領域で、プロジェクト統括者から継続的に高い評価を得ている。
まとめ
- 開発は5工程。外注は「全部か内製か」ではなく、工程ごとに分担を設計する。
- 意思決定が重い要件定義・基本設計、品質基準の定義は内製で主導が原則。仕様が固まった実装・専門性の高いテストは外注効果が高い。
- ただし規格対応を伴う開発などでは、STELAQが要件定義・設計を含む上流から一貫して担うことも可能。自社の内製スキルとリソースに応じ、伴走型・請負・チーム派遣・第三者検証を使い分ける。
自社に最適な「工程の分担」を、一緒に設計しませんか
STELAQは、要件定義から実装・テスト・保守まで全工程を支援できる体制を持ち、工程ごとに最適な関わり方（伴走・チーム派遣・請負・第三者検証）をご提案します。「どこから外注すべきか分からない」段階からのご相談を歓迎します。
出典：システム開発プロジェクトリーダー300名への外注活用に関する実態調査（株式会社STELAQ調べ／2025年）。調査の詳細はこちら
