Key Takeaways
- 新規事業の外注が失敗する主因は委託先の技術力ではなく、仕様が固まる前提で組まれた受託の枠組みに、仕様が固まらない事業を載せていること。
- 受託開発の契約は請負でも準委任でも納品や稼働で完結する設計であり、売上への責任が条文に入ることは通常ない。
- 発注側と受注側では、ゴール・仕様変更・撤退の3地点で意味が反転する。売れることと検収されること、学びの反映と追加コストの違いが典型例。
- 委託前に自社だけで決められるのは、成功の数字・発注の単位と変更の扱い・社内の当事者・撤退条件・成果物と権利の5点。
- 意思決定、顧客との関係、撤退の判断は外注できない。相手に売上への責任を求めるなら、権限と売上データをセットで渡す必要がある。
「開発会社の腕が悪かったわけではない。それなのに、事業は動かなかった」——新規事業の外注でよく聞く感想です。既存システムの刷新なら同じ会社に頼んでうまくいくのに、新規事業の委託だけがこける理由は、相手選びではなく頼み方の型のほうにあります。本記事は「おすすめの開発会社◯選」ではなく、委託先がまだ決まっていない今日の時点で、発注側が自社だけで決められることを書きます。
新規事業の外注は、相手を選ぶ前の段階で結果が決まっている
「見積もりが高い」「認識がずれた」「動くけれど売れない」。語られ方は違っても、行き着く原因は一本にまとまります。受託開発の契約に書かれているのは、納品への責任までです。売上への責任は、通常そこに含まれません。
既存システムの委託と新規事業の委託を分ける違いは、ただ一点です。着手の時点で仕様が確定できるかどうか。既存業務の置き換えなら、現行の業務そのものが仕様の下敷きになります。新規事業には下敷きがありません。何を作るかは、顧客の反応を見ながら決まっていきます。
この一点を踏まえずに通常の発注手続きに乗せると、あとは順番に崩れていきます。
新規事業の外注が失敗する5つのパターン
まず、現場で実際に起きることを並べます。原因の分析は次の節にまとめました。
パターン1｜仕様どおりに納品されたのに、売れない
仕様書を満たすことがゴールになり、売れるかどうかを誰も確かめないまま完成します。開発だけを切り出して発注したため、誰に・どんな価値として・どのルートで届けるかは社内に残ったままです。この宙に浮いた部分は、委託先を変えても埋まりません。届け方の設計についてはGTM戦略の立て方で「作ってから売り方を考える」罠として扱っています。
パターン2｜要件が固まらず、見積もりと承認で前に進まない
方針が変わるたびに、再見積もりと稟議と再契約が挟まります。事業の速度が、手続きの速度に律速される状態です。要件が動くのは、発注側の準備不足ではありません。新規事業では正常な状態であり、動くことを織り込んでいない進め方のほうに無理があります。
パターン3｜担当が替わった瞬間に止まる
社内の推進者が異動しても、委託先の主担当が交代しても、同じことが起きます。なぜその案を捨てたのか。何を試して外れたのか。この判断の経緯が個人の頭にしか残っておらず、再開のたびに説明からやり直しになります。人柄や熱量だけの問題ではありません。当事者と記録を、誰かの善意ではなく設計として置いていないことの問題です。
パターン4｜検証のつもりが「納品して終わり」になる
試作の目的と本番化の条件を決めないまま発注すると、動くものは残るのに次の判断材料が残りません。検証の成果物は動く画面ではなく、進むか止めるかの材料です。この条件を先に置く方法はPoC止まりを卒業する進め方にまとめています。
パターン5｜作ったものを、自社で動かせない
ソースコードの権利。動いている環境と各種アカウント。運用手順と改修の窓口。これらが曖昧なまま納品されると、小さな修正にも発注と待ち時間が必要になります。事業を伸ばす段階に入った瞬間、この一点が最大のボトルネックになります。外注依存から抜ける道筋は内製化のロードマップを参照してください。
5つに共通する原因——受託契約は「納品で終わる」ようにできている
5つは別々の事故に見えて、同じ一点から出ています。開発会社が売上に責任を持たないのは、不誠実だからではありません。契約の類型と受注側の収益構造が、そう設計されているからです。
請負と準委任——受注側が負うのは「完成」か「稼働」か
受託開発の契約は、大きく請負と準委任に分かれます。請負は仕事の完成に責任を負い、準委任は善良な管理者の注意をもって業務を遂行する責任を負います。準委任にも、成果の完成に報酬を結びつける型があります。ただしその成果は納品物であって、売れることではありません。
標準的な受託開発の契約書に、売上への責任を定めた条項が置かれることは通常ありません。実際の扱いは個別の条項と事業の実態によって変わるため、締結前に法務や弁護士へ確認してください。
検収がゴールになる理由——開発会社の売上はいつ立つのか
多くの受託案件で、売上が立つのは検収の後です。一方でエンジニアの人件費は、検収を待たずに毎月出ていきます。だから「いつ検収されるか読めない案件」は、受注側の社内でも承認が通りにくくなります。
発注側が「相手がやたら仕様を固めたがる」と感じる場面の裏側には、この事情があります。要求を絞りたいのではなく、終わりの見える形にしたいだけです。パターン2は、この裏面にあたります。
見積もりは「不確実性の値段」——仕様が動く前提だと積み増される
仕様が確定していない案件を、固定の金額で引き受けるとします。受注側は変更が起きる分をリスクとして見込み、あらかじめ余裕を積むしかありません。発注側はそれを高いと感じ、範囲を削って発注します。
そして削られるのは、たいてい確かめたかった部分です。結果として、何も確かめられないものが納品される。
発注側と受注側で、意味が反転する3地点
同じプロジェクトを見ているのに、意味が逆になる地点が3つあります。どちらかが悪いのではなく、立場が違えば評価される指標も違うという必然のズレです。
ゴール：「売れること」と「検収されること」
発注側の成功は売上です。受注側の成功は検収です。同じプロジェクトを並んで走りながら、評価される指標が最初から違っています。パターン1とパターン4は、ここから出ています。
仕様変更：「学びの反映」と「追加コスト」
新規事業では、顧客の反応を受けて作るものが変わります。それが正常な状態です。しかし受託契約では、変更のたびに再見積もりと工期の再交渉が発生します。学ぶほど発注側の負担が増えるという、目的と逆向きの構造です。パターン2の正体はここにあります。
撤退：「早い損切り」と「予定していた売上の消失」
発注側にとって、早い方向転換は英断です。受注側にとっては、見込んでいた売上と稼働計画が消える事故です。だから当初計画の完遂を勧める力が働きやすくなります。
それでも受託契約が最適になる場面
ここまで読むと受託が悪いように見えるかもしれませんが、そうではありません。作るものが確定している。期限が動かない。社内に要件を書ける人がいる。この条件が揃うなら、受託がいちばん噛み合います。費用も納期も読めます。
噛み合わないのは、何を作るかがまだ決まっていない段階だけです。やること自体が固まっていないなら、委託先を探すより前にアイデアを絞り込む工程が残っています。
委託前に、発注側だけで決められる5つのこと
相手を変えるより先に、頼み方を変えます。5つとも、委託先が決まっていなくても社内だけで決められるものに限りました。
1. 成功を数字で定義する
何がどれだけ動いたら成功なのかを、作る前に一文で書けるか。指標が決まっていなければ、納品されたものが良かったのか悪かったのかを誰も判定できません。「使いやすいものを」ではなく、どの数字がどう動けば次へ進むのかを書きます。決めないと、パターン1が起きます。
2. 発注の単位を「完成」から「区切り」に変える
全機能を一括で発注せず、確かめたい問いごとに区切って発注します。区切りの終わりには継続か中止かの判断点を置き、次の発注はその判断の後に出します。あわせて、変更の手続きと優先順位を入れ替えられる枠を契約に書いておきます。決めないと、パターン2が起きます。
3. 社内に当事者を1人立て、その人の時間を確保する
手を動かす人と、決める人は別に要ります。実装は外に出せますが、意思決定者の時間だけはどの契約形態でも肩代わりできません。兼務のまま名前だけを置くと、判断待ちで全体が止まります。決めないと、パターン3が起きます。
4. 撤退の条件と時期を、始める前に置く
どの数字が、どれだけの期間下回ったら止めるのか。始め方の合意だけで走り出すと、伸びない局面で「ここまで払ったのだから」という感情が判断を鈍らせます。中止したときの精算と引き渡しまで含めて、先に決めておきます。決めないと、パターン4が起きます。
5. 成果物・権利・引き継ぎの形を、契約前に書く
納品物をコードと画面だけにしません。ソースコードと各種アカウントの帰属。動いている環境と運用手順。そして何を試して何が分かったかという記録。ここまでを成果物として定義しておけば、外れた施策も次の判断材料として残ります。決めないと、パターン5が起きます。
どこまで任せるか——外注できない3つの仕事
丸投げしたい気持ちは分かりますが、預けた瞬間に事業が止まる仕事が3つあります。意思決定と、顧客との関係と、撤退の判断です。どの契約形態を選んでも、この3つは社内に残ります。委託先が代わりに腹をくくることも、顧客の信頼を引き受けることもできません。
一方で、頼み方の幅は受託開発だけではありません。要件を固めきれない課題に体制ごと伴走してもらう形もあれば、成果に報酬を連動させる形もあります。「外注イコール受託開発」だと思い込むと、選べたはずの選択肢を最初から捨てることになる。委託先のタイプごとの見分け方と、選定時に投げるべき質問は支援会社4タイプの選び方にまとめてあります。
契約の形は固定報酬だけではない——3つの反転を、どの形が緩めるか
契約の選択肢は、2つの軸だけで整理できます。変更をどう扱うか。事業リスクを誰が負うか。この2軸で見ると、それぞれの形が前の節の3つの反転地点のどれを緩めるのかが分かります。
準委任で体制ごと借りる形は、仕様変更の反転を緩めます。変更が追加コストではなく、稼働の中身の入れ替えになるからです。成果連動の形は、ゴールの反転を緩めます。受注側の報酬が検収ではなく売上に紐づくためです。条項として何を書くかはレベニューシェア型の契約で決める項目を参照してください。撤退の反転だけは、どちらの形でも自動では緩みません。中止の条件と精算・引き渡しを条項に書いて初めて緩みます。
最後に一点だけ。相手に売上への責任を求めるなら、仕様と売り方への権限と売上データをセットで渡す必要があります。責任だけを移そうとする契約は、受注側から断られやすくなります。
新規事業の外注に関するよくある質問
Q. 要件が固まっていない段階でも、新規事業の開発を外注できますか？
できます。ただし、全機能を一括で発注する形とは相性がよくありません。確かめたい問いごとに区切って発注し、区切りの終わりに継続か中止かを判断する進め方に変えてください。
Q. 新規事業の開発委託では、請負契約と準委任契約のどちらが向いていますか？
作るものが確定していれば請負、走りながら決まっていく段階なら準委任が噛み合いやすいとされます。ただし、どちらを選んでも売上への責任が契約に含まれることは通常ありません。個別の契約でどう扱われるかは条項と実態によって変わるため、締結前に法務や弁護士へ確認してください。
Q. 新規事業の外注は、どこまで任せられますか。丸投げはできますか？
実装や設計は任せられますが、意思決定と顧客との関係と撤退の判断は社内に残ります。社内に当事者を1人立て、その人の時間を確保することが最低条件です。
Q. 外注した新規事業が売れなかったとき、責任はどちらにありますか？
通常の受託契約では、受注側の責任は納品や稼働までです。売れなかったことの責任は、原則として発注側に残ります。相手にも売上の責任を負ってほしい場合は、仕様と売り方への権限と売上データを渡したうえで、成果連動の契約を検討することになります。
Q. 外注先を比べるとき、見積もり以外に何を見ればよいですか？
要件が変わったときの手続きと、成果物の定義の2点です。変更の扱いが契約になければ学ぶたびに交渉が起き、成果物がコードと画面だけなら記録も権利も社内に残りません。金額の比較は、この2つを揃えたうえで意味を持ちます。
SAIの視点：外注が止まる場所に、当事者を置く
ここまで一般論として書いてきたことに、株式会社SAIがどう答えているかを書きます。
1つは、要件が固まらない段階から事業に伴走する新規事業開発支援です。エンジニアが商談に同席し、その場でデモを見せて確かめます。変更を追加コストではなく、学びの反映として扱うための体制です。
もう1つは、2026年9月に公開した自責〜JISEKI〜です。新規事業開発をSAIが請け負い、初期開発費用はいただきません（外部サービスの利用料などの実費は別です）。報酬は成果連動のレベニューシェア型です。商談にはSAIが同席しますが、意思決定と顧客との関係そのものは貴社に残ります。だから審査制で、決められる人が当事者として関わる案件だけを受けます。この形が成り立つのは、本文で書いた「権限と情報をセットで渡す」と「撤退条件を先に書く」を前提に置いているからです。
作り切った例としては、広告代理店の制作・運用を自動化した事例と、BCP支援企業でAI活用を定着させた事例があります。
相談は、委託先をどこにするか決める前の段階からで構いません。最初のご相談では、成功を測る数字と撤退の条件という、契約書より先に決めるべき2点を一緒に置きます。お問い合わせください。
関連記事