この記事の結論
- 依頼先の違いは「事業フェーズに合った速さで動けるか」と「引き継げる形で残るか」の2軸で見ると整理できます
- 仮説検証期・調達直後・拡大期で求める開発の性質は変わり、向いている依頼先も変わります
- 契約前にソースコードの帰属・契約形態・内製化への移行方法を質問すれば、大半のミスマッチは防げます
スタートアップがプロダクトの依頼先を探すと、大手のシステム会社からWeb制作会社、フリーランス、弊社のような小規模の開発会社、さらには自社で採用して内製する道まで、選択肢の幅に戸惑う方が多いようです。どれが優れているという話ではなく、事業のフェーズと、社内でどこまで技術の判断ができるかによって向き不向きが変わります。本記事では、タイプごとの違いをスタートアップの視点で整理し、契約前に確認したい質問と内製化への移行の考え方をまとめます。記載している特徴は一般的な傾向です。
依頼先の違いは2つの軸で見る
規模や料金の前に見ておきたい軸が2つあります。
1つ目は、事業フェーズに合った速さで動けるかです。仮説検証の段階では、仕様が途中で変わる前提で短い周期で作っては反応を見る進め方が求められます。営業が窓口で開発は別チームという体制では要望が伝言で伝わり、判断のたびに時間がかかります。窓口と作る人が近ければ、その場で技術的な可否を判断でき、検証の周期を短く保てます。
2つ目は、引き継げる形で残るかです。ソースコード、設計資料、サーバーやドメインの名義が自社に残り、別の会社や将来採用するエンジニアが引き継げる状態か。これは資金調達時のデューデリジェンスや内製化への移行に直接影響し、依頼先の規模とは関係なく契約と作り方で決まります。
事業フェーズごとに求める開発は変わる
スタートアップの開発は、段階によって性質が異なります。一般に、次のような整理ができます。
| フェーズ | 開発に求めること | 起きやすい失敗 |
|---|---|---|
| 仮説検証期(調達前) | 最小の範囲を速く作り、反応から学ぶ | 機能を盛り、資金と時間を使い切る |
| 調達直後 | 検証で残った部分を土台に、拡張できる作りへ整える | 暫定コードをそのまま拡大し、作り直しになる |
| 拡大期 | 安定運用と、社内チームによる継続開発への移行 | 外部依存が固定化し、内製化の道筋が立たない |
依頼先のタイプ別の向き不向き
| タイプ | 向いている状況 | 注意したい点 |
|---|---|---|
| 大手システム会社 | 調達後に大規模な基盤を構築する、厳格な監査対応が必要 | 多層構造で費用と時間がかかりやすく、仮説検証の速度に合わないことがある |
| Web制作会社 | LP、コーポレートサイト、見た目と情報設計が中心の案件 | Webシステムやデータ連携は外注する会社もある。窓口と作る人が別になりやすい |
| フリーランス | 範囲が明確な小規模開発、既存プロダクトの改修 | 一人の稼働に依存する。契約・帰属・保守の取り決めが曖昧になりやすい |
| 小規模開発会社 | 仮説検証から拡大期までの継続的なプロダクト開発、技術責任者不在の補完 | 大規模案件は体制の相談が必要。会社ごとの得意領域の差が大きい |
| 内製(自社採用) | 技術責任者がいて、継続的に開発を続ける前提がある | 採用に時間がかかる。検証結果で必要な技術が変わると人材の再配置が難しい |
大手システム会社
体制が厚く、長期間・大規模な案件に耐える設計と運用ができます。一方で、営業・PM・設計・開発と役割が分かれている分の人件費が費用に乗り、意思決定にも段階が入ります。仮説検証期のように短い周期で作っていく段階では、体制の大きさがそのまま負担になることがあります。
Web制作会社
デザインと情報設計に強みがあり、LPやコーポレートサイトを用意する場面では有力な候補です。ただし、会員機能や決済、データ連携のような「システム」部分は外注に出す会社も多く、窓口と作る人が別になる点は確認しておきたいところです。
フリーランス
費用を抑えやすく、範囲が明確な案件なら速く進みます。注意点は、一人の稼働に依存することと、契約・保守の取り決めが口約束になりやすいことです。成果物の帰属と、対応できなくなった場合の引き継ぎ方法を書面で確認しておきます。
小規模開発会社
少人数で設計から開発、保守までを回す会社です。窓口と作る人が同じか近いため技術的な判断が速く、営業やPMの人件費が乗らない分、費用を抑えられる傾向があります。技術責任者が社内にいないスタートアップにとっては、技術選定や採用の相談相手にもなり得ます。弊社もこのタイプで、Webシステム開発から開発チーム体制構築・内製化支援まで、フェーズに合わせて関わり方を変える前提で進めています。
内製(自社採用)
社内にエンジニアを抱えて開発する方法です。事業の知識が社内に蓄積し、意思決定から実装までの距離が最も短くなります。一方で採用には時間がかかり、仮説検証の結果によって必要な技術が変わることもあります。外部に依頼して検証を進めながら、内製化を前提に引き継げる形で作っておく組み合わせが一般に現実的です。詳しくは内製化ロードマップで解説しています。
エクイティと開発費について
一般に、株式やストックオプションの付与と引き換えに開発を引き受ける相手も存在します。資金が限られる創業期には魅力的に見えますが、株式の希薄化など事業に長く影響する判断です。資本政策全体の中で専門家を交えて検討することをおすすめします。
契約前に聞いておきたい質問
依頼先のタイプにかかわらず、次の質問をすると相性が分かります。
- 窓口の方は、実際の設計や開発にも関わりますか。 関わらない場合、要望はどのように伝わりますか
- ソースコード、設計資料、サーバーやドメインの名義は、自社に残りますか。 別の会社や将来採用するエンジニアに引き継ぐことはできますか
- 契約形態は請負と準委任のどちらが基本ですか。 検証の結果で仕様が変わった場合、どのような扱いになりますか
- 使う技術は一般的で、後から他のエンジニアが引き継げるものですか。
- 将来の内製化や別会社への移行に、どのように協力してもらえますか。
- 自社の事業段階を踏まえて、「今は作らないほうがよい」という提案をすることはありますか。
最後の質問は相手の姿勢を見るのに役立ちます。すべてを開発する提案しか出てこない場合、費用が大きくなる方向にしか話が進まないことがあります。料金や会社の規模だけで決めず、2〜3社に同じ資料で相談すると、提案の違いから自社の要件がはっきりします。契約形態についてはアジャイル開発と契約、技術責任者が不在のときの選択肢は外部CTOで詳しく解説しています。
速さと引き継ぎやすさで依頼先を選ぶ
想定例:シード期の会社が「資金調達までの 3 か月で検証したい」という条件で依頼先を比べると、体制の厚さより、小さく速く出せるかが決め手になります。
依頼先の違いは、「事業フェーズに合った速さで動けるか」と「引き継げる形で残るか」の2軸で整理できます。今のフェーズと次のフェーズを踏まえてタイプの向き不向きを当てはめ、契約前に担当者・成果物の帰属・契約形態・内製化への移行方法を質問すれば、大半のミスマッチは防げます。弊社への相談でも、他の依頼先や内製のほうが向いている場合はそのようにお伝えしています。
依頼先の選定で迷ったら、お問い合わせからご相談ください。他の依頼先が向いている場合はそのようにお伝えします。
本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。
チェックリスト
- 自社の事業フェーズ(仮説検証・調達直後・拡大期)と、それに必要な開発の性質を言葉にしたか
- 窓口の人と実際に作る人が同じか、違うなら情報がどう伝わるかを確認したか
- ソースコード・設計資料・サーバーやドメインの名義が自社に残る契約かを確認したか
- 契約形態と、仮説検証の結果で仕様が変わったときの扱いを確認したか
- 使われる技術が一般的で、後から採用したエンジニアが引き継げるものかを聞いたか
- 将来の内製化や別会社への移行にどう協力してもらえるかを聞いたか
- 「今は作らないほうがよい」という提案をしてくれる相手かを見たか
よくあるご質問
エクイティ(株式)で開発費を払う方法はありますか?
一般に、株式やストックオプションの付与と引き換えに開発を引き受ける会社や個人も存在します。ただし、株式の希薄化、評価額の決め方、関係が終わった後の株式の扱いなど、事業への影響が大きい判断です。弊社では個別の条件を本記事では扱わず、まず資金計画と開発範囲を整理したうえで、専門家を交えて検討することをおすすめしています。
相見積もりは何社くらい取るのがよいですか?
一般に2〜3社が現実的です。それ以上になると各社への説明と比較に時間がかかり、要件の伝え方もぶれやすくなります。同じ資料を渡し、同じ質問をすることで比較しやすくなります。
最初から内製したほうがよいのでしょうか?
創業期に技術責任者がいて採用も進められるなら選択肢になります。一方で、採用には時間がかかり、仮説検証の結果で必要な技術が変わることもあります。外部に依頼して検証を進めつつ、内製化への移行を前提に進める形も一般的です。
関連する記事
- 契約・進め方アジャイル開発と契約 — 準委任で進める場合の合意事項アジャイル開発と請負契約の相性、準委任契約で進める理由、目的とスコープ・体制・検収・変更・知的財産権・中途終了など事前に合意すべき事項と発注側の責務を、発注者の視点で整理します。
- チーム・体制開発の内製化ロードマップ — 外注から自社チームへ移行する手順外注に頼っていた開発を自社チームへ移す手順を、現状の棚卸し、最初に内製化する領域の選定、採用と技術顧問の活用、コードとドキュメントの引き継ぎ、並走期間、移行後の外部パートナーの使い方まで段階的に解説します。
- チーム・体制技術顧問・外部CTOという選択肢 — 何を任せ、何を社内に残すか技術顧問・外部CTOに任せられる役割と、社内に残すべき意思決定やドメイン知識を整理し、契約形態、成果の測り方、内製化との関係、向くケース・向かないケースを解説します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開 / 更新