# 内製 vs 外注・SaaS vs スクラッチ：中小・スタートアップのための意思決定フレームワーク > システムを内製すべきか外注すべきか、SaaSで足りるのかスクラッチで作るべきか。中小企業・スタートアップの意思決定者が、感覚ではなく軸で判断するためのフレームワークを解説。差別化の核・変更頻度・専門性・TCOの4軸と、ハイブリッド戦略、一人×生成AIという第三の選択肢まで、実プロジェクトの知見から体系化します。 - 公開日: 2026-06-25 - 著者: 友田 陽大 - タグ: 受託開発, システム開発, 発注, アーキテクチャ設計, B2B SaaS, 技術選定 - URL: https://tomodahinata.com/blog/build-vs-buy-saas-vs-scratch-inhouse-vs-outsource-guide ## 要点 - 最初の問いは『内製か外注か』ではなく『そもそも作るべきか（SaaSで足りないか）』。ここを飛ばすと最も高くつく - スクラッチが正当化されるのは『事業の差別化の核』かつ『既製品で表現できない業務制約』がある時だけ - 内製 vs 外注は、差別化の核・変更頻度・専門性・TCOの4軸で判断する。核で高頻度に変わるものは内製寄り - 現実解はハイブリッド——認証・決済などは既製基盤を使い、自前で作るのは業界固有のロジックだけに絞る - 一人×生成AIは『外注の柔軟性』と『内製に近い密な対話』を両立する第三の選択肢になりうる --- 結論を先に述べます。**「内製か外注か」を考える前に、必ず「そもそも作るべきか（SaaSで足りないか）」を先に潰してください。** 最もコストの高い間違いは、既製のSaaSで解ける業務を、わざわざゼロから開発してしまうことです。そのうえで、内製と外注の判断は、感覚ではなく**「差別化の核・変更頻度・専門性・TCO」の4軸**で行います。本記事は、中小企業・スタートアップの意思決定者が、この一連の判断を自分の頭で下せるようになるためのフレームワークです。 > この記事は[システム開発の発注 完全ガイド](/blog/system-development-outsourcing-guide-vendor-selection-cost)の意思決定編です。費用の詳細は[費用相場と見積もりの記事](/blog/system-development-cost-estimate-market-rate-guide)を参照してください。 --- ## 1. 第一の分岐：作るべきか、買うべきか（SaaS vs スクラッチ） 意思決定の最初のゲートは、ここです。順番を間違えないでください。 ```text その機能は、事業の差別化の核か？ ├─ No → まず SaaS / 既製品で解く │ （会計・勤怠・CRM・MA・チャット・予約などは作らない） └─ Yes → 既製品で要件を満たせるか？ ├─ 満たせる → SaaS を採用し、足りない部分だけ拡張・連携する └─ 満たせない → スクラッチ（または下記のハイブリッド） ※業界特有の複雑な商流・独自の業務制約がある場合 ``` **スクラッチ開発が正当化されるのは、次の2条件をどちらも満たすときだけ**です。 1. **事業の差別化の核**である（競合との差を生む、あなたの事業そのものの部分） 2. **既製品では表現できない**業務制約がある（複雑な商流、業界固有のロジック、独自のデータモデル） 私が手がけた木材流通のB2B SaaSは、この典型でした。「林業 → 市場 → 製材所 → プレカット → 工務店 → メーカー」という多段の商流、業種ごとに異なる権限、企業をまたぐ取引とテナント分離——これらは既製のグループウェアやECでは表現できず、スクラッチが正当でした。一方で、会計や勤怠のような「どの会社も同じ」業務をスクラッチで作るのは、ほぼ常に間違いです。 > **信頼できるパートナーの見分け方**: 何を聞いても「作れます」と答える相手は危険です。優れた開発者は、「その要件は既製のSaaSで足ります。作るべきはこの部分だけです」と**作らない提案ができる**人です。これは発注額を自ら減らす提案であり、長期的な信頼の証でもあります。 --- ## 2. 現実解は「ハイブリッド」——全部作る／全部買う、ではない 「SaaS vs スクラッチ」は二者択一ではありません。本番品質のシステムの多くは、**ハイブリッド**です。すなわち、 - **既製の基盤は最大限使う**——認証（Cognito / Auth0 / Clerk）、決済（Stripe）、メール、ストレージ、監視。これらを自前で作るのは車輪の再発明であり、セキュリティリスクでもあります。 - **自前で作るのは、業界固有のロジックだけに絞る**——差別化の核となる、あなたの事業そのものの部分。 金融リテラシー教育のサブスク学習プラットフォームを構築したときが、まさにこれでした。カード決済は**Stripeに寄せる**一方、Stripeに乗らない**銀行振込の継続課金**（入金期限・猶予期間・督促・自動失効）は、業務要件に合わせて自前の状態機械として実装しました。さらに、直販・代理店・NFT優待・外部移行という**6系統の料金体系を決定的に解決する純粋関数**は、既製品では絶対に表現できない差別化の核なので、ここに開発リソースを集中させています。 「全部作る」でも「全部買う」でもなく、**作る価値のある部分だけを作る**。これがコストと品質を両立させる現実解です。 --- ## 3. 第二の分岐：内製 vs 外注を決める4軸 「作る」と決めた後、それを**社内で内製するか、外部に外注するか**。これを4つの軸で判断します。 | 評価軸 | 内製が有利 | 外注が有利 | |---|---|---| | **差別化の核か** | 事業の中核で、ノウハウを社内に蓄積したい | 周辺機能・一時的な構築 | | **変更頻度** | 頻繁に変わり続ける（育て続ける） | 作ったらしばらく安定 | | **専門性** | 社内に該当スキルがある／育てたい | 高度な専門性が一時的に必要 | | **TCO（総保有コスト）** | 長期に使い、採用・維持できる | 立ち上げを速く・安く、固定費を持ちたくない | ざっくり言えば、**「事業の核で、頻繁に変わり、長く育てるもの」は内製寄り**。**「専門性が一時的に必要で、速く立ち上げたいもの」は外注寄り**です。 ただし、中小企業・スタートアップには重大な現実があります——**そもそもエンジニアを採用・維持できない**。内製には「採用コスト・人件費・退職による属人化リスク・マネジメント工数」がかかります。一人のエンジニアを正社員で雇えば、年間で数百万〜1,000万円超の固定費です。これを払い続けられないなら、内製は選択肢になりません。 > **意思決定の現実**: 多くの中小企業にとって、最初の正解は「まずSaaSで足りないかを確認し、足りない差別化部分だけを外注（または一人×生成AIで一気通貫）し、事業が育ってコア機能が固まったら段階的に内製へ移す」という**段階的な内製化**です。最初から全部内製は、ほぼ常に早すぎます。 --- ## 4. 「速く・安く・固定費なし」で作りたい場合の第三の選択肢 従来、外注の選択肢は「大手SIerに大きく頼む」か「複数人の受託会社に頼む」かでした。そこに、**一人（少人数）× 生成AI で、要件定義からインフラ・運用までワンストップ**という第三の選択肢が加わっています。 これは、内製と外注の「いいとこ取り」を狙えるポジションです。 | 観点 | 大手SIer外注 | 一人 × 生成AI | 内製 | |---|---|---|---| | 立ち上げ速度 | 遅い（調整が多い） | 速い | 採用次第（遅い） | | コスト | 高い（マージン） | 低い | 固定費が重い | | 意思決定者との距離 | 遠い（多層） | 近い（直接対話） | 近い | | 柔軟性（仕様変更） | 低い（契約に縛られる） | 高い | 高い | | 大規模・多人数調整 | 強い | 不向き | スケール次第 | 一人×生成AIが向くのは、**スピードとコストが重要な新規事業・MVP・業務システム**で、**意思決定者と直接対話しながら素早く要件を回したい**ケースです。逆に、超大規模で多数の関係者調整が前提なら、大手の体制が向きます。**「速い・安い・柔軟」と「大規模な体制」はトレードオフ**であり、それを正直に言える相手こそ信頼できます。 --- ## 5. よくある判断ミスと、その回避 実際の現場で繰り返し見る判断ミスを挙げます。 | ありがちなミス | なぜ間違いか | 正しい判断 | |---|---|---| | 何でもスクラッチで作る | 既製品で足りる業務まで作り、コストと保守負担が膨らむ | 差別化の核だけを作る | | 何でもSaaSで済ませる | 差別化の核まで既製品に合わせ、競合と同質化する | 核はハイブリッドで作り込む | | 早すぎる内製化 | 採用・維持コストと属人化リスクを抱え込む | 段階的内製化（まず外注/一人×AI） | | 安さだけで外注先を選ぶ | 非機能要件・品質が抜け、運用で破綻 | 技術力×実績と品質ゲートで選ぶ | | ベンダーロックインの軽視 | 特定SaaS/言語に縛られ、移行コストが跳ね上がる | 標準技術・抽象化境界で逃げ道を残す | 特に最後の**ベンダーロックイン**は見落とされがちです。私は実装でも、たとえばAIの推論エンジンや音声合成プロバイダを「インターフェース→プロバイダ→ファクトリ」の抽象境界の背後に置き、**環境変数だけで差し替え可能**にしておくことで、特定ベンダーへの依存を局所化しています。これは「将来の選択肢を残す」という、ETC（Easy To Change）の設計判断です。 --- ## よくある質問（FAQ） ### Q. 内製と外注、どちらを選ぶべきですか？ 事業の差別化の核で、頻繁に変わり続け、長く育てる機能なら内製寄り。専門性が一時的に必要で、速く・安く立ち上げたいなら外注寄りです。ただし中小企業・スタートアップでは、エンジニアの採用・維持コストが重いため、まず外注（または一人×生成AI）で立ち上げ、コア機能が固まってから段階的に内製化するのが現実的です。 ### Q. SaaSで足りるか、スクラッチで作るべきか、どう見分けますか？ 「事業の差別化の核か」「既製品で業務要件を表現できるか」の2点で判断します。会計・勤怠・CRMのような汎用業務はSaaS、業界特有の複雑な商流や独自ロジックはスクラッチ。多くの場合、答えはハイブリッド——既製基盤（認証・決済など）を使い、差別化の核だけを自前で作るのが最適です。 ### Q. 全部スクラッチで作れば、自由度が高くて良いのでは？ 自由度は上がりますが、コストと保守負担が膨らみます。認証や決済を自前実装するのは車輪の再発明であり、セキュリティリスクも増えます。既製の基盤で解ける部分は既製品を使い、開発リソースを差別化の核に集中させる方が、結果的に良いものが速く安く作れます。 ### Q. 一人の開発者に外注するのは、内製・大手外注と比べてどうですか？ 立ち上げ速度・コスト・意思決定者との距離・仕様変更の柔軟性では有利です。一方、超大規模で多数の関係者調整が必要なプロジェクトには不向きです。スピードとコストが重要な新規事業・MVP・業務システムで、直接対話しながら素早く進めたい場合に最適な選択肢です。 --- ## まとめ：判断の順番を間違えない 内製・外注・SaaS・スクラッチの意思決定は、次の順番で行います。 1. **まず「作るべきか（SaaSで足りないか）」を潰す**——最もコストの高い間違いを避ける。 2. **スクラッチは「差別化の核」かつ「既製品で表現できない」時だけ**——それ以外は既製品。 3. **現実解はハイブリッド**——既製基盤を使い、自前で作るのは業界固有のロジックだけ。 4. **内製 vs 外注は4軸（核・変更頻度・専門性・TCO）で判断**——早すぎる内製化を避ける。 5. **一人×生成AIは「外注の柔軟性」と「内製に近い対話」を両立する第三の選択肢**。 「うちの場合はどう判断すべきか」を一緒に整理したい——そうしたご相談を歓迎します。作るべきもの・作らざるべきものの線引きから、最適な体制まで、発注者の側に立って設計します。