Contents
自社開発とは：定義と主要メリット・デメリット
ここでは「自社開発」の定義を明確にし、主要な利点とリスクを事業フェーズ別の視点で整理します。用語は初出で定義します。MVPは最小実用製品（MVP）、プロダクト・マーケット・フィットはPMF（PMF）、サービスレベル目標はSLO（SLO）と表記します。
定義
自社開発の範囲と前提を示します。部分的な外注やSaaS併用は許容します。
- 自社開発とは、企画・設計・実装・運用を社内で主導する方式です。
- 部分的外注は、境界を契約で明確化したうえで認めます。
- 成果物の所有権や運用責任を社内で保持する点が特徴です。
主なメリット
自社にとどめる利点を事業価値に紐付けて示します。
- 差別化の実現：コア機能を独自化しやすく、IP化できる可能性があります。
- ナレッジ蓄積：プロダクト知見が社内に蓄積され、長期的な改善速度が上がります。
- 統制とセキュリティ：機密データやコンプライアンス管理がしやすくなります。
- 長期コスト優位：一定規模を超えると外注よりTCOが下がるケースが多いです（後述の数値例参照）。
主なデメリットとリスク
導入前に認識すべき負担を列挙します。
- 初期投資負担：採用・教育・ツール・インフラ費用が先行します。
- 技術負債リスク：経験不足で設計ミスがあると将来の改修コストが増えます。
- 採用難：重要スキルの採用競争が激しい時期は確保が困難です。
- ガバナンス負荷：規模拡大時に内部統制が追いつかないことがあります。
事業フェーズ別の推奨（概略）
フェーズにより採るべき戦略が変わります。目安としてのチーム規模と方針を示します。
- シード期：チーム2〜4名で検証重視。MVPは高速で外部サービス併用が多いです。
- 成長期：チーム4〜12名でコア部分は内製、周辺はSaaS/外注のハイブリッド。
- エンタープライズ：SREやセキュリティ、QAを含む専任組織を整備し、内製比率を高める傾向があります。
意思決定フレーム：評価基準とスコア算出（0–2の具体例）
機能ごとの内製化判断には定量スコアが有効です。ここでは評価軸の定義と実際のスコア算出手順、閾値例を示します。閾値は事業フェーズに応じて調整してください。
評価軸と各スコアの定義
各軸は「0＝内製不要／低」「1＝条件付き」「2＝内製推奨」を意味します。社内で数値基準を共有してください。
- 事業重要度（差別化度）: 0=非差別化, 1=差別要素あり, 2=差別化の核
- 技術的独自性: 0=既存SaaSで代替可, 1=一部独自処理, 2=核心アルゴリズム/ノウハウ
- コンプライアンス/データ要件: 0=標準SaaSで可, 1=注意要, 2=内製必須レベル
- コスト優位性（3年TCO見積）: 0=外注が有利, 1=同等, 2=内製が有利（下に例を示します）
- 内製能力（採用・運用可能性）: 0=不可, 1=条件付き, 2=確保済／可
※ すべての軸を合算して最大10点になります。高得点ほど内製が推奨されます。
TCO（3年）評価の例：参考値（会社フェーズ別）
以下は例示です。自社状況と為替・地代等で調整してください。
- シード期（3年TCO目安）: 0=<500万円、1=500〜1,500万円、2=>1,500万円（ただし「2」は内製で長期的に回収できる見込み）
- 成長期（3年TCO目安）: 0=<2,000万円、1=2,000〜6,000万円、2=>6,000万円
- 企業規模（大企業）: 0=<5,000万円、1=5,000〜1.5億円、2=>1.5億円
注：ここでの「2」は直感に反する場合があるため、必ず「内製で長期的にコスト優位が取れるか」を評価軸に入れてください。
スコア算出手順（実務フロー）
- 各機能について評価軸を埋める。
- 合計点を算出する（最大10点）。
- 閾値マッピングで推奨を決める（例: 8〜10=内製、5〜7=ハイブリッド、0〜4=外注/SaaS）。
- ステークホルダーでレビューし、契約・境界設計へ反映する。
スコアリングのサンプル（決済機能の想定）
| 項目 | スコア（0-2） | 理由（短文） |
|---|---|---|
| 事業重要度 | 2 | 手数料収益に直結、差別化要素あり |
| 技術的独自性 | 1 | カスタムルールを一部採用 |
| コンプライアンス | 2 | PCI/税務ローカライズが必要 |
| コスト優位性 | 1 | 3年で外注と同等見積 |
| 内製能力 | 1 | 採用予定だが未確保 |
合計: 7 → ハイブリッド（コアは内製、決済の一部は外部連携）という判断例です。
実務ロードマップと赤信号（MVP→ローンチ→スケール）
フェーズごとに合否基準を定めることで判断を迅速化します。ここでは各フェーズの主要タスクと定量合格基準、更に「赤信号」の早期検出ルールを示します。
発見／準備フェーズ（Discovery）
探索と前提検証を行う段階です。最小のコストで課題仮説を確認します。
- 主要タスク: ユーザー仮説定義、競合調査、簡易プロト作成。
- 合格基準（例）: 3〜5名の潜在ユーザーインタビューで主要課題が一致すること。KPI候補の定義完了。
MVP設計・構築フェーズ
最小の機能で市場反応を測ります。設計時に計測ポイントを固めます。
- 主要タスク: 最小機能の実装、イベント計測、初期ユーザー招待。
- 合格基準（例）: アクティベーション到達率が事前閾値（7日内20%等）を満たす。重大バグがない。計測が確認できる。
ユーザー検証フェーズ
定量・定性で継続性と価値仮説を検証します。PMF指標の定義も行います。
- 主要タスク: コホート分析、A/Bテスト、NPS調査、継続率確認。
- 合格基準（例）: 7日/30日リテンションがドメイン期待値に到達、NPSが改善傾向。Sean Ellis式のPMFテスト（プロダクトがなくなったら非常に残念と答える割合が40%前後）を参考にする。
ローンチフェーズ
本番運用に耐えうる体制と運用手順を整えます。
- 主要タスク: 負荷試験、SLO設定、運用ランブック、サポート体制整備。
- 合格基準（例）: 負荷試験通過、SLOに基づくアラート運用が稼働、対応ランブックが存在する。
スケールフェーズ
構造化された自動化とコスト管理で成長を支えます。
- 主要タスク: 組織編成、アーキテクチャ最適化、FinOps定着。
- 合格基準（例）: ARR/MAUが継続増加し、クラウドコストが事前の指標内で管理されている。
早期検出の「赤信号」と優先対応
監視すべき指標と閾値の例を挙げます。閾値はプロダクト特性で調整してください。
- リリース頻度が過去4週比で50%以下に低下。即時対応: 機能凍結とレビュープロセス見直し。
- インシデント頻度や重大度が増加（例: 重大インシデント数が月1件→3件）。即時対応: オンコール体制強化、ポストモーテム必須化。
- クラウドコストが予算比30%超過。即時対応: 不要リソース停止、スケーリングポリシー修正。
- 主要ユーザーKPIが継続的に低下。即時対応: ヒアリングとログ解析で根本原因の仮説検証。
- エンジニア離職率や採用難が顕著。即時対応: 外部支援導入と負荷軽減策。
リスク優先度は影響度×発生確率で数値化し、スコアに基づいてアクションの緊急度を決めると運用が安定します。
技術実装の具体手順（IaC、CI/CD、観測性、テスト）
ここでは推奨ツールと導入手順、注意点をフェーズ別に示します。実務で再現できる手順と注意ポイントを中心に解説します。
IaC（インフラをコード化）の導入手順
IaCは環境の再現性と運用コスト低減に直結します。段階的に導入してください。
- ツール候補: Terraform、Pulumi、CloudFormation。
- 導入手順（概要）: 1) リソース設計と命名規約、2) モジュール化（環境単位のstate分離）、3) リモートバックエンド（例: S3＋DynamoDBロック）、4) CIでのplan実行→レビュー→apply。
- ベストプラクティス: シークレットはVaultやKMSで管理。Stateの衝突防止。小さなモジュール単位でのテスト（Terratest等）。
CI/CDとデプロイ戦略
自動化は品質と速度を両立します。段階的導入がおすすめです。
- ツール候補: GitHub Actions、GitLab CI、CircleCI、ArgoCD（GitOps）。
- 標準パイプライン例: PR→Lint/Unit Test→SAST/依存スキャン→Terraform Plan（ステージング）→E2E→手動承認→Prod Apply。
- デプロイ戦略: ブルーグリーン、カナリア、Feature Flags（LaunchDarkly/Unleash）併用を推奨。
- KPI例: デプロイ頻度、MTTR（目標: シード期1日以内、成長期数時間以下へ短縮）。
観測性（メトリクス・ログ・トレース）の導入手順
観測性は問題検出と改善の鍵です。まずSLO設計から始めてください。
- ツール候補: OpenTelemetry、Prometheus、Grafana、Jaeger、Loki、Datadog、Sentry。
- 導入手順: 1) 重要なSLIを定義、2) SLOとエラーバジェットを設定、3) アプリに計測ポイントを埋める、4) ダッシュボードとアラートを作る。
- SLO例: リクエスト成功率 99.9%（30日ウィンドウ）→許容ダウンタイムは約43.2分/月。
- 注意点: アラートはノイズを避けるためにSLOベースで設計する。
テスト自動化とセキュリティスキャン
品質は自動化で担保します。左側（開発初期）に品質対策を置いてください。
- テストピラミッド実践: ユニット→統合→E2Eの順で重み付け。
- 契約テスト（Contract Tests）で外部依存を安定化。
- セキュリティ: SAST（SonarQube等）、依存性スキャン（Dependabot、Snyk）、コンテナスキャン（Trivy）をCIに統合。
- 品質閾値例: 主要機能のE2E成功率99%、ユニットカバレッジの目安70〜80%（ただし品質は数値だけで評価しない）。
移行・段階的リファクタリング（Stranglerパターン）
高速MVPからの移行は計画的に行います。
- 手順: 1) 依存箇所の境界化、2) 新機能を徐々に切り出す（Strangler）、3) 契約テストで整合性を担保、4) 古いコードの段階的廃止。
- 成功基準: ダウンタイムゼロまたは許容内、運用負荷の増加が抑制されること。
セキュリティ・プライバシー・コンプライアンス（APPI/GDPR/規格）
法規制対応は設計段階から組み込む必要があります。ここでは主要法令の要点と実務で使えるチェックリスト、契約項目例を示します。
主要法令の要点と実務対応
APPI（日本）、GDPR（EU）、CCPA（米州）など、対象顧客やデータ所在地により必要対応が変わります。
- 実務対応の流れ: データマッピング→法的根拠の確認→DPA締結→DPIA（高リスク時）→保持ポリシー設定。
- GDPR特記: データ侵害は72時間以内の通知義務。越境移転は標準契約条項（SCC）等の手法が必要。
- APPI特記: 個人情報の第三者提供や共同利用の明示、適切な安全管理措置が求められます。
ベンダー契約とDPA（データ処理契約）項目例
DPAに含めるべき主要項目とチェックポイントです。
| 項目 | 内容 |
|---|---|
| 処理目的と範囲 | 何を、なぜ処理するかを明確に |
| データの種類 | 個人データの分類（詳細に） |
| サブプロセッサー | 再委託先の許可ルール |
| 越境移転 | SCCや認定制度の明記 |
| セキュリティ措置 | 暗号化、アクセス管理の要件 |
| 監査権 | 監査や証跡提出の合意 |
| 事故対応 | 通知期限と協力義務（GDPR:72h等） |
監査・認証と運用体制
顧客や規制要件によってはSOC2やISO27001が必要です。取得目的とコストを比較検討してください。
- SOC2/ISO27001は信用獲得に有効ですが、運用コストがかかります。
- まずは内部統制とログ・監査証跡を整備し、段階的に認証を目指すと効率的です。
ケーススタディ・テンプレート（記入例・CSVコピペ可）
実務で使える匿名化した再現可能な事例とテンプレートを示します。事例内の数値は再現性向上のために想定値を含めます。実際の導入では自社の前提に合わせて調整してください。
ケーススタディ1：国内SaaS（PMFの高速化）【再現性情報付き】
前提・規模: チーム4名（PM1／FS2／インフラ1）、開発期間6ヶ月、総工数約24人月、概算コスト約1,200万円。
実行施策: 小規模クロスファンクショナルチームでオンボーディング再設計。週次顧客ヒアリングとイベント計測実装。
定量目標・定義: 7日アクティベーション率を20%→30%に改善、30日リテンションを15%→25%に改善。
成果（想定）: アクティベーションが6週間で+10ポイント、PMF確度が内部評価で3ヶ月早まったという評価。数値はインタビューと公開資料を基にした想定値です（参考: 事例集や公開ブログ）。
再現性ポイント: エンジニアが顧客接点を持つ、計測を設計して仮説検証を週次で回す。最小工数で定量KPIを早期に定義することが鍵でした。
ケーススタディ2：越境マーケットプレイス（スケール段階）
前提・規模: チーム10名、初期運用コスト月200万円、GMVが主要KPI。
実行施策: マッチングロジックは内製、決済・税務はローカルパートナーと連携。API契約と自動テストで境界を明確化。
成果（想定）: トランザクション成功率向上、サポートコスト削減、GMV増加。再現性のための注: ローカライズ部分は外注で迅速に仕様対応する。
参考: 決済・ローカライズは地域毎の法規制を踏まえた設計が必要です。
ケーススタディ3：MVP→スケールでの段階的リファクタ
前提・規模: MVP期4名、スケール期で20名規模へ拡張。MVP期間3ヶ月。
実行施策: MVPはサーバーレスとフレームワークで高速投入。主要マイルストーン到達時にモジュール化、IaC、CI導入と段階的に技術負債を返済。
成果（想定）: 市場投入速度を維持しつつ、MTTR改善とデプロイ頻度向上を両立。推奨資源: リファクタ時に専任SREを1名置くと効果的。
導入判断シート（テンプレート） — Markdown表とCSV例
導入判断用の最小フォーマット例と、CSVで使える1行サンプルを示します。
| 機能名 | コア/周辺 | 事業重要度(0-2) | 技術独自性(0-2) | コンプラ(0-2) | コスト優位性(0-2) | 内製能力(0-2) | 合計 | 推奨 |
|---|---|---|---|---|---|---|---|---|
| 決済 | コア | 2 | 1 | 2 | 1 | 1 | 7 | ハイブリッド |
CSVコピペ用（一行サンプル）
|
1 2 3 |
機能名,コア/周辺,事業重要度,技術独自性,コンプラ,コスト優位性,内製能力,合計,推奨 決済,コア,2,1,2,1,1,7,ハイブリッド |
MVPリリース判定表（テンプレートと記入例）
| 判定項目 | 必須か | 状態 | 閾値/備考 |
|---|---|---|---|
| 必須機能実装 | 必須 | 完了 | 機能一覧のうち100% |
| 計測ポイント | 必須 | 完了 | イベント定義・送信確認済 |
| 7日アクティベーション | 重要 | 達成 | >=20%（目安） |
| 重大バグ | 必須 | なし | クリティカル回避 |
| セキュリティ基本 | 必須 | 実施 | 依存スキャン実施済 |
リスク優先度表と即時対応マップ（数値化ルール）
- 評価方法: 影響度(1-3) × 発生確率(1-3) = リスクスコア（1〜9）。
- 行動マップ: 7〜9=即時対応（24時間以内）、4〜6=次期スプリント内対応、1〜3=計画的対処。
例:
| リスク | 影響度 | 確率 | スコア | 対応 |
|---|---|---|---|---|
| デプロイ失敗で顧客影響 | 3 | 3 | 9 | 即時ロールバック・インシデント対応 |
SLOテンプレート（記入例）
| サービス | SLI | SLO | 測定ウィンドウ | エラーバジェット（許容） |
|---|---|---|---|---|
| API応答性 | 99.9%成功率 | 99.9% | 30日 | 約43.2分ダウン/月 |
計算メモ: 30日 = 43,200分。許容エラー = (1 - 0.999) × 43,200 = 43.2分。
まとめ
自社開発は差別化とナレッジ蓄積に有効ですが、初期投資と運用負荷を見極める必要があります。評価は明確な軸で数値化し、閾値に基づく意思決定を行ってください。法令対応（APPI/GDPR等）と観測性の整備を早期に組み込み、IaCやCI/CDで再現性を高めることが成功確度を上げます。まずは本稿の導入判断シートとMVP判定表を用いて1件の機能でトライアルを行ってください。