内製 vs 外注・SaaS vs スクラッチ：CTOがいない中小・スタートアップの開発体制の決め方

結論から言います。システムの体制は、次の4つの順番で決めてください。

1. そもそも作るか——SaaS（月額で使える既製のクラウドサービス）で足りないか。
2. 作るなら、どこまで既製品を使うか——認証や決済などは既製の基盤に任せ、自前で作る範囲を絞る（ハイブリッド）。
3. 誰が作るか——社内で作る（内製）か、外部に頼む（外注）か。差別化の核・変更頻度・社内の専門性・総保有コストの4軸で決める。
4. 技術の判断に誰が責任を持つか——社内にCTO（技術の最高責任者）がいないなら、外部の開発責任者に任せる選択肢がある。ただし、手放してはいけないものがある。

順番を飛ばすと、後で高くつきがちです。特に高くつきやすい間違いは2つあります。1つは、SaaSで解ける業務をゼロから開発してしまうこと。もう1つは、リポジトリ（ソースコードの保管場所）やクラウドのアカウントを外注先の名義のままにして、後から自社で動かせなくなることです。

この記事は、個人事業主、中小企業の経営者・役員、そしてCTOのいない会社で開発の担当を任された方に向けて書いています。コードを読めなくても判断できるようにし、エンジニア向けの具体的な設定は、見出しに「エンジニア向け」と付けた節に分けました。

この記事はシステム開発の発注 完全ガイドの意思決定編です。費用の考え方は費用相場と見積もりの記事を参照してください。

1. 第一の分岐：作るか、買うか（SaaS vs スクラッチ）

最初のゲートはここです。スクラッチ（既製品を使わずにゼロから作る開発）を検討する前に、まず既製品で解けないかを確かめます。

その機能は、事業の差別化の核か？
├─ No  → まず SaaS / 既製品で解く
│         （会計・勤怠・CRM・MA（マーケティング自動化）・チャット・予約などは作らない）
└─ Yes → 既製品で要件を満たせるか？
          ├─ 満たせる    → SaaS を採用し、足りない部分だけ拡張・連携する
          └─ 満たせない  → 自前で作る（次の節のハイブリッドで）

スクラッチが正当化されるのは、次の2条件をどちらも満たすときだけです。

1. 事業の差別化の核である——競合との差を生む、事業そのものの部分。
2. 既製品では表現できない業務の制約がある——複雑な商流、業界固有のルール、独自のデータの持ち方。

経済産業大臣賞を受賞した木材流通のB2B SaaS（私が要件定義から運用まで単独で担当）は、この典型でした。「林業 → 市場 → 製材所 → プレカット → 工務店 → メーカー」と業種が多段につながる商流、業種ごとに異なる操作や閲覧の範囲、企業をまたぐ取引とデータの分離。どれも既製のグループウェアやECで表現するのは難しい種類の要件で、この部分は自前で作りました。一方で、会計や勤怠のような「どの会社でもほぼ同じ」業務をスクラッチで作るのは、ほぼ常に間違いです。

「買う」を選ぶ場合も、契約の条件は確かめて選びます。たとえば、解約するときに自社のデータを取り出せるか（7節のベンダーロックイン）は、申し込む前に確かめておきたい点です。独立行政法人情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書」には、受託開発向けとは別に、パッケージやクラウドサービス（SaaSなど）を活用する場合の版（第二版追補版）も用意されています。

信頼できる相手の見分け方：何を聞いても「作れます」と答える相手には注意してください。信頼できる開発者は、「その要件は既製のSaaSで足ります。作るべきはこの部分だけです」と、作らない提案ができます。自分の受注額を減らす提案なので、長く付き合える相手かどうかを見分ける材料になります。

2. 現実解は「ハイブリッド」——全部作る／全部買う、ではない

現実的な答えは、多くの場合ハイブリッドだと私は考えています。

• 既製の基盤は最大限使う——認証（Cognito / Auth0 / Clerk）、決済（Stripe）、メール、ストレージ、監視。これらを自前で作るのは車輪の再発明で、セキュリティ上のリスクも増えます。
• 自前で作るのは、業界固有のロジックだけに絞る——差別化の核になる、事業そのものの部分。

私が中核エンジニアとしてチーム開発に参加した、金融リテラシー教育のサブスク学習プラットフォームがこの形でした。カード決済はStripeに任せ、Stripeの外で処理する銀行振込の継続課金（入金期限・猶予期間・督促・自動失効）は、業務に合わせてチームで自前の仕組みを作りました。直販・代理店・NFTホルダー優待・外部サービスからの移行が混在する料金は、6系統の判定材料から一つの関数で決める仕組みにしています。どちらも、この事業に固有の課金ルールです。

「全部作る」でも「全部買う」でもなく、作る価値のある部分だけを作る。費用と品質を両立させる現実解です。

3. 第二の分岐：内製か外注か——4つの軸で決める

「作る」と決めたら、次は誰が作るかです。

TCO（総保有コスト）とは、作る費用だけでなく、保守・インフラ・外部サービスの利用料・社内の手間・将来の移行費用まで含めた、使い続ける間の費用の総額のことです。

判定表：よくある状況ごとの答え

中小企業・スタートアップの現実

内製には、採用費・人件費・社会保険・教育・マネジメントの手間が、固定費としてかかり続けます。辞めた人しか分からない部分が残る「属人化」のリスクもあります。払い続けられる見込みがないなら、最初から全部を内製するのは早すぎます。

多くの中小企業にとって、最初の正解は段階的な内製化です。まずSaaSで足りないかを確かめ、足りない差別化の部分だけを外注で作り、事業が育ってコアの機能が固まったら、少しずつ社内に移します。

ただし、外注でも属人化は起こります。外注先にしかコードの場所や設定が分からない状態になれば、社員が辞めたときと同じことが起きます。そこで必要になるのが、4つ目の問い「技術の判断に誰が責任を持つか」です。

4. CTOがいない会社は、何を外部の開発責任者に任せられて、何を手放してはいけないか

社内にCTOや開発責任者がいない会社が外注すると、「見積もりが妥当か分からない」「技術の選び方を説明されても判断できない」「作った人がいなくなったら誰も触れない」という問題が起きがちです。これを補うのが外部の開発責任者です。呼び方は技術顧問・CTO代行などさまざまですが、社外の立場から技術の判断を引き受ける役割を指します。月額の技術顧問は判断と助言を担います。この記事でいうCTO代行は、それに加えて、設計・実装・クラウド構築といった開発の実作業まで引き受ける関わり方です。

外部の開発責任者には、任せてよいことと、社内に残すべきことがあります。

なぜ「決めること」は社内に残すのか

IPAの「情報システム・モデル取引・契約書（アジャイル開発版）」は、プロダクトの方向性と内容に責任を持つ役割をプロダクトオーナー（PO）と呼び、ユーザ企業がPOを選任して、開発チームが必要とする情報や意思決定を適時に提供する形を定めています。開発側（ベンダ）は専門家として、バックログ（これから作るものの一覧）への助言や、技術的なリスクの説明を行う、という役割分担です。

外部の開発責任者に技術の判断を任せても、この構図は変わりません。選択肢と理由を出すのは外部の責任者、何を優先し、いくら払い、何をもって完成とするかを決めるのは会社です。ここまで任せきりにすると、何を作るべきかを外部の人が推測で決めることになり、「思っていたものと違う」の原因になります。

なぜ「名義」は社内に残すのか

アカウントの名義は、最も見落とされやすく、後から取り返すのが最も面倒な項目です。

• リポジトリ：GitHubの公式ドキュメントは、組織（Organization）のオーナーは組織に対する完全な管理権限を持つと説明し、オーナーは限られた人数にしつつ、2人を下回らないよう勧めています。外部の人は「外部コラボレーター」として、必要なリポジトリにだけ参加させられます。
• クラウド：AWSのアカウントを作ると、アカウント内のすべてのリソースに完全にアクセスできる「ルートユーザー」ができます。AWSは、ルートユーザーのメールアドレスに、会社が管理し複数の人に転送されるアドレスを使うよう勧めています。担当者が休暇中・病気・退職していても、AWSからの連絡への対応が遅れにくくなるためです。
• 著作権：著作権法では、著作者は「著作物を創作する者」です。会社の発意に基づいて社員が職務で作ったプログラムは、契約や就業規則に別段の定めがなければ会社が著作者になります（第15条第2項）。一方、外部の開発会社やフリーランスが作ったものはこの規定の対象にならないことが多く、会社のものにするには契約で著作権の譲渡を定めます（第61条第1項）。さらに、譲渡の契約で第27条（翻訳権、翻案権等）と第28条（二次的著作物の利用に関する原著作者の権利）の権利が明記されていないと、これらは譲渡した側に残ると推定されます（第61条第2項）。改修を続けていくソフトウェアでは見落とせない点です。契約書の文言は、必要に応じて弁護士などの専門家に確認してください。

外部の開発責任者に求めるべき4つのこと

誰に頼む場合でも、次の4つは契約の前に確認してください。

1. リポジトリとクラウドは、初日から自社名義で作る——外部の人は、権限をもらって作業する立場にとどめる。契約が終わるときは、権限を外し、相手が触れた鍵（APIキー・パスワードなど）を作り直せば済む。
2. 引き継ぎ資料を納品物に入れる——README・構成図・環境変数一覧・運用手順書（Runbook）。
3. インフラをコードで管理する（IaC）——Terraformなどで定義しておけば、別のエンジニアが同じ環境を作り直せる。
4. 主要な業務フローに自動テストとCIを用意する——CI（変更のたびにテストを自動で回す仕組み）があれば、別のエンジニアも安全に改修できる。

私は、この4つを標準のやり方にしています。リポジトリとクラウドは初日から発注者の名義で作り、私はコラボレーター権限で作業します。引き継ぎ資料は追加費用なしの標準の納品物です。NDA（秘密保持契約）は商談前から締結でき、成果物の著作権は原則として発注者に帰属します。ただ、ここで伝えたいのは「私に頼めば安心」ということではありません。誰に頼む場合でも、この4つを条件にしておけば、その人がいなくなっても事業が止まりにくくなるということです。

エンジニア向け：名義と権限の具体的な設定

社内に少しでも技術の分かる方がいれば、次の設定を確認してもらってください。

• GitHub：会社のOrganizationを作り、Ownerは社内の2人以上にする。外部の開発責任者や開発会社には、外部コラボレーター（またはメンバー）として、必要なリポジトリにだけ権限を付ける。
• リポジトリが外注先の個人アカウントにある場合：リポジトリの移管（Transfer）で、会社のOrganizationに移せる。移管する人には、そのリポジトリの管理者権限に加えて、移管先のOrganizationでリポジトリを作成できる権限が必要。外注先を外部コラボレーター（Organizationのメンバーではない立場）にしている場合は、移管の前にこの権限があるかを確かめ、なければ移管の間だけメンバーにしてリポジトリの作成を許可するなど、準備しておく（メンバーにリポジトリの作成を許すかは、Organizationの設定で選べる）。Issue・Pull Request・Wikiなども一緒に移り、旧URLへのリンクは新しい場所へ自動でリダイレクトされる。ただし、元の場所に新しいリポジトリやフォークを作ると、このリダイレクトは完全に削除される。
• AWS：ルートユーザーのメールは会社管理のグループアドレスにし、MFA（多要素認証）を設定する。ルートユーザーは日常の作業に使わず、管理用のユーザーを別に作る。外部の人を含む利用者には、単一のアカウントならIAMロール、AWS Organizationsで複数のアカウントを管理しているならIAM Identity Centerを使い、一時的な認証情報で必要な権限だけを渡す。
• ドメイン・外部サービス：ドメインの登録者や、決済・メール配信・監視などの外部サービスの契約も、会社の名義・会社のメールアドレスで持つ。

5. 一人の外部開発責任者が向く会社・向かない会社

外部の頼み先は、大手SIer（システムの企画から構築・運用までを請け負う大手の開発会社）、複数人の開発会社、一人の外部開発責任者に大きく分かれます。私が提供しているのは最後の形で、AIで速く作り、本番の品質には人間が責任を持つやり方です。生成AIでコードを書く速さを使いつつ、自動テスト・Lint（コードの書き方の検査）・脆弱性スキャンをCIで回し、レビューして本番に出す判断は人間が持ちます。窓口は一人で、成果物は別のエンジニアが引き継げる形で発注者に残します。

「社員の人件費」は、人を雇うことで毎月かかる固定費です。外部に頼む場合も、月額の技術顧問のように続く契約を結べば、その契約費は毎月かかります。

向いている会社

• 社内にエンジニアがいない、または少なく、MVP（最小限の機能で出す最初の製品）・SaaS・業務システムを立ち上げたい
• 社長や事業責任者が直接話して、優先順位をその場で決められる
• 何を作り、何を作らないかから一緒に整理したい

向いていない会社・案件

• 多数の部署や関係会社をまたぐ大規模なプログラムで、調整そのものが仕事の大半を占める
• 夜間・休日も含めて交代で待機する運用体制（オンコール）が必要なシステム。私の月額技術顧問にも、障害時の待機は含まれません
• 複数の開発ラインを同時に並行して進める必要があり、人数そのものが要る規模
• 社内に、優先順位や検収の基準を決める人（PO役）を置けない。任せきりでは、誰に頼んでもうまくいきません

一人に頼むときに多い不安は、「その人が対応できなくなったら」です。これへの答えは、誰かが代わりに来る約束ではなく、4節の4条件で別のエンジニアが引き継げる状態で進めることです。初日から自社名義にするのはリポジトリとクラウドで、引き継ぎ資料・IaC・自動テストとCIは納品の条件にします。

6. 小さく始める：まずは判断の助言から

外部の開発責任者に、いきなり大きな契約で頼む必要はありません。作る人がいない場合も、PoC（本格開発の前に、実現できるかを小さく確かめる試作）のような小さな単位から始められます。料金は料金ページと同じです（税別）。

助言だけで足りるか、開発まで頼むべきかの目安は、社内（または契約中の開発会社）に作る人がいるかどうかです。作る人がいるなら、判断役としての技術顧問で足ります。作る人がいないなら、PoCやMVP、あるいはプロジェクトのように、成果物の単位で頼む方が、費用と完成の基準がはっきりします。請負の契約では、検収後3ヶ月以内に見つかった不具合を無償で修正します（契約不適合責任）。

技術顧問とCTO代行の違い、相談から引き渡しまでの進め方は、CTO代行・外部開発責任者のページにまとめています。

既存システムの引き継ぎや作り直しには、決まった料金がありません。 費用がコードの状態で大きく変わるためです。何が見積もりを動かすか、見積もりを早く正確にするために何を用意すればよいかは、引き継ぎの準備の記事にまとめています。

まずはスポット相談でコードと環境を見て、コードの状態によっては先に技術負債診断（3〜5営業日）を行ったうえで、部分的な改修と作り直しのどちらが適切かを、費用とリスクを比べて決めるのが順当です。

7. よくある判断ミスと、その回避

AIで作った試作品は、正当な出発点

生成AIを使えば、社長や担当者が自分で動く試作品を作れるようになりました。試作品は、作りたいものを言葉よりも正確に伝えられる、正当な出発点です。ただし、動くことと本番で壊れないことは別物で、そのまま公開するのは危険です。多くの場合は作り直さずに壊れやすい箇所を補強（硬化）できますが、直して使うか、一部作り直すか、作り直すかは、確かめられるサインで決めます。その判断表はAI生成コードの本番化の記事にまとめています。

初期費用ではなく、総コストで比べる

外注先や体制を比べるときは、初期費用だけでなく、保守・インフラ・外部サービスの利用料・社内の手間・将来の移行費用まで含めて比べてください。見積書に出てこない費用の整理と計算の仕方は、システム開発の総コスト（TCO）の記事にあります。

チェックリスト：発注の前に確認すること

• その機能は、SaaSや既製品で足りないかを確かめた
• 自前で作る範囲を、差別化の核に絞った
• 内製か外注かを、4軸（差別化の核・変更頻度・専門性・TCO）で判断した
• 優先順位・予算・検収の基準を決める人を、社内に決めた
• リポジトリ・クラウド・ドメインは自社名義で、オーナーが社内に2人以上いる
• 引き継ぎ資料・IaC・自動テストとCIを、納品の条件に入れた
• 外部の人が抜けるときに外す権限と、作り直す鍵の一覧がある
• 著作権の帰属（第27条・第28条の権利を含む）と秘密保持を、契約書に書いた
• 初期費用ではなく、総コストで比べた

まとめ：判断の順番を間違えない

1. まず、作るべきか（SaaSで足りないか）を確かめる——特に高くつきやすい間違いを避ける。
2. スクラッチは「差別化の核」かつ「既製品で表現できない」部分だけ——現実解はハイブリッド。
3. 内製か外注かは4軸で判断する——早すぎる内製化を避ける。
4. CTOがいないなら、技術の判断は外部の開発責任者に任せられる——ただし、事業の優先順位・予算・最終決定と、アカウントの名義・アクセス権は手放さない。
5. 小さく始める——判断の助言ならスポット相談か月額顧問から、作る人がいないならPoCやMVPから。