開発途中で外注先を切り替えたPLが56.7%。中小企業の発注側が契約前に握る4つの線引き

「開発会社に任せれば大丈夫。うちは要件なんて詳しくないから、プロに全部お任せ」——そう言って契約したのに、3ヶ月後には「言った言わない」が始まった。中小企業のIT発注現場では、このパターンが珍しくありません。株式会社STELAQが2025年8月28〜31日に実施した、ソフトウェア開発プロジェクトリーダー300名調査では、プロジェクト途中で外注先を切り替えた経験がある人が56.7%にのぼります。この記事では、数字が示す「発注側が握るべき線引き」を、開発・ディレクションの視点で整理します。

—-

56.7%が外注先を切り替えた。失敗の主因は技術力だけではない

STELAQの調査は、直近2年以内に外注を活用してソフトウェア開発をリードした経験がある300名を対象に実施されました。ハイライトは3点です。

1点目は切り替え率の高さです。2人に1人以上が、当初選んだ外注先との契約を途中で終了、または別ベンダーへ乗り換えた経験を持っています。切り替え理由の最多は技術力不足（76.5%）ですが、それに続いてコミュニケーション不足（40.6%）、プロジェクトの理解不足（31.2%）、チームワークの欠如（25.3%）が並びます。技術力だけを見て選んでも、運用の設計がなければ止まる——これが調査の示す構造です。

2点目は、課題の4分類です。外注活用時に困る点として、品質への不安（52.3%）、属人性（41.7%）、社内人材が育たない（39.0%）、理解の齟齬（34.3%）が上位に挙がりました。いずれも「ベンダーのコードが悪い」というより、発注側と受注側のあいだで起きるマネジメントの問題です。

3点目は、プロジェクト規模による違いです。予算3,000万円未満の小規模案件では、切り替え要因としてプロジェクトの理解不足（40.5%）と人間関係（29.7%）が目立ちます。予算1億円以上の大規模案件では、納期遅れ（32.1%）と体制・設計不備（33.3%）が前面に出ます。中小企業が発注しやすい規模ほど、「何を作るかの共有不足」がそのままトラブルになるわけです。

開発・実装の外注は96.7%で活用されており、実装だけ任せる発想自体は一般的です。一方で、規模が大きくなるほど設計・運用・PMOまで外注範囲が広がる傾向も報告されています。どの工程を自社で持ち、どこから任せるかを決めずにスタートすると、責任範囲と成果物の粒度を巡る争いに発展しやすい——この点は、開発会社への丸投げを防ぐ別記事とも通じる論点です。

—-

小規模PJほど「理解不足」が起きる。発注側とベンダーの差を数値で見る

調査資料では、外注をうまく活用できたケースに「こまめなコミュニケーション」と「定例会の実施」が共通していたとされています。逆に言えば、会議体と情報共有の設計がなければ、品質不安や属人性は表面化しやすくなります。

プロジェクト規模別の切り替え要因を整理すると、次のようになります。

小規模PJ（予算3,000万円未満）：理解不足40.5%、人間関係29.7%が突出。少人数で動くため、担当者同士の認識差がそのままプロジェクトリスクになります。
中規模PJ（3,000万円以上〜1億円未満）：複数要因が分散。工程ごとの成果物定義が曖昧だと、手戻りが連鎖しやすい段階です。
大規模PJ（1億円以上）：納期遅れ32.1%、体制・設計不備33.3%。個人の理解差はチームでカバーできても、進捗管理と体制設計の甘さが遅延として出ます。

さらに選定基準別の落とし穴も示されています。コスト重視で選んだ層は切り替え理由の81.8%が技術力不足。技術力最優先の層でも切り替え率は62.3%で平均より高く、理由はコミュニケーション不足（50.0%）とチームワーク欠如（40.6%）です。「安いから」「技術があるから」だけでは、発注側の運用設計がなければ止まる——両極端に同型の失敗があることがわかります。

AIの影響についても調査されています。外注利用頻度は「増える」「減る」「変わらない」で意見が分かれますが、AIでは代替しにくい領域として、要件定義・上流工程、顧客対応・折衝・調整が多く挙げられました。コードを書く速度は上がっても、「何を作るか・どこまで作るか」を決める負荷はむしろ増える——発注側の要件整理とディレクションの比重は、AI時代に下がるどころか上がる可能性があります。

—-

契約前に握る4つの線引き。外部ディレクターが効くポイント

開発会社に全部任せる前に、発注側が最低限握っておくべき線引きを4つに整理します。いずれも、高額な要件定義書がなくても始められるレベルです。

線引き1：Must／Stop／Outの3分類

やりたいこと（Must）、やめること（Stop）、やらないこと（Out）を先に決めます。「やらないこと」を書かないまま発注すると、機能過多の見積もりと手戻りを招きます。要件定義のコストを後回しにした会社が払う代償は、別記事でも触れていますが、今日は契約前のこの3行が切り替え率56.7%を下げる第一関門だと考えてください。

線引き2：工程ごとの成果物とレビュー方法

96.7%が開発・実装を外注していますが、「実装だけ任せる」と書いても、画面イメージ・データ項目・受け入れ基準が空欄だと理解不足40.5%の側に倒れます。工程ごとに「何をもらい、誰がOKを出すか」を1行ずつでよいので決めます。

線引き3：定例会と連絡経路の契約

成功事例に共通した定例会とこまめなコミュニケーションは、契約書の別紙レベルで固定してよい内容です。週次の進捗、課題管理ツール、エスカレーション先——「技術があるから察してくれる」は、調査上も切り替え理由の半分を占めます。

線引き4：フェーズ分割と切り替え可能な契約

いきなり総額一括ではなく、現状整理・要件合意・開発の段階で区切る契約にします。56.7%が一度は切り替え経験を持つ以上、「最初から完璧な相手を選ぶ」より「早い段階でズレを検知できる契約」の方が、中小企業には現実的です。

ひとり情シスや社長兼任のIT担当が、ベンダーと対等に折衝するのが難しい場合は、外部ディレクターに「発注側の席」を預ける選択肢があります。コードを書くのではなく、要件の言語化、会議設計、受け入れ基準のすり合わせ——調査が示す非技術要因（40.6%＋31.2%＋25.3%）は、まさにここを埋める役割です。

今日やること（3分）：進行中またはこれから発注する案件について、「Must／Stop／Out」を各1行ずつメモし、次回ベンダーとの打ち合わせの冒頭3分で読み上げて合意を取る。

• Must（必ず解決したい課題）を1行で書けている
• Stop（このシステム導入でやめる業務）を1行で書けている
• Out（今回含めない機能・範囲）を1行で書けている
• 定例会の頻度と、進捗・課題の共有方法が決まっている
• 契約がフェーズ分割になっており、要件合意前に開発着手しない

—-

まとめ：外注失敗の半分は「選び方」より「運用の型」

開発途中で外注先を切り替えたPLが56.7%——2人に1人の経験値です。
小規模PJほど理解不足と人間関係が切り替え要因になり、技術力だけ見ても足りません。
Must／Stop／Out、成果物定義、定例会、フェーズ分割——この4線引きは発注側の仕事です。

次の一手：進行中の案件がなくても、次に外注する案件名を1つ決め、Must／Stop／Outだけ今日書き出してください。

—-
参考：株式会社STELAQ「ソフトウェア開発の外注に関する実態調査」プレスリリース、2025年11月27日（調査期間2025年8月28〜31日、対象300名）