ITプロジェクトを内製化すべき？判断のポイントと準備

エリート水準のソフトウェア組織は、1日未満のリードタイムと0〜15%の変更失敗率を達成するとDORAの年次報告は示しています¹。デプロイ頻度や回復時間の差は、そのまま体験品質と収益機会の差に直結します³。一方で、外部委託への依存が大きいほど、要求変更のリードタイムは延びやすく、意思決定が契約稟議に吸い込まれる現場は珍しくありません。公開調査や現場の報告を照らし合わせると、内製は魔法の杖ではないものの、変化が激しい領域では学習速度と差別化の源泉になりやすいという傾向が見えてきます。

ただし、流行語としての「内製化」は危うい。焦点は発注形態ではなく、プロダクト価値が生まれるボトルネックをどこで解消するかです。本稿では、CTOやエンジニアリングマネージャーが意思決定に使えるように、判断のフレームワーク、TCOとROIの試算方法、DORA指標を用いた準備度評価、そして90日パイロットの進め方を、実務に根ざした形で立体的に解説します。

内製化か外注か：判断のフレームワーク

最初に問うべきは「作るべきか、買うべきか」ではありません。そこが顧客価値と学習ループの中核かどうかです。顧客接点でA/Bテストを高頻度に回したい、手の内のデータを機動的に活用したい、競争優位のアルゴリズムを磨き込みたい。こうした領域は内製と相性が良い。一方で、会計や汎用人事のような非差別化領域は、信頼できるSaaSと堅実な統合のほうが投資対効果を得やすい現実があります。

次に、変更頻度と不確実性を見ます。仕様が固く、規制で変更が稀な部分は外部委託でも十分にスケールします。反対に、仮説検証のサイクルを週単位で回す必要がある領域は、契約の壁が都度の意思決定を鈍らせるため、内製のほうがフィットしやすい。ここではDORAの4指標（デプロイ頻度、変更リードタイム、サービス復旧時間、変更失敗率）が羅針盤になります²。これらが短いほど、プロダクトの学習は速く、内製チームへの投資価値が高まります³。

ベンダーロックインとコンプライアンスも冷静に評価すべき観点です。海外クラウドのデータ越境要件、監査証跡の厳格さ、個人情報の移転制限。これらは契約やプラットフォーム選定で解けることもあれば、ドメイン知識を持つ社内チームの設計判断が不可欠な場合もあります。規制産業では、外部委託時の第三者リスクやコンプライアンス管理が重要論点であることが、監督当局のガイダンス等でも指摘されています⁴。セキュリティ審査を外に払い続けるほど、社内のレビュー能力が痩せていくという組織学習のコストも忘れてはいけません。

最後に総コストを金額で比較します。内製は固定費化しやすく、外注は変動費化しやすい⁶。短期のP/Lを軽くしたければ外注が有利に見えますが、長期の変更回数が多いほど内製の便益は逓増します。意思決定の眼差しを、初期費+運用費だけでなく、待ち時間が生む機会損失や、学習速度の差まで広げて比較することが肝要です。

ケース：ECでのレコメンド内製化

EC領域では、レコメンドを外部ASPから自前に切り替える取り組みが見られます。データ活用の自由度を優先し、フィード生成からモデル更新、配信までを自社設計に寄せると、A/Bテストの反復速度が日次レベルまで上がりやすく、CVRが数十ベーシスポイント（0.1〜1.0ポイント程度）改善する報告もあります。クラウド費はスケーリング戦略の見直しで1〜3割圧縮されるケースが一般的に観測され、初期開発は数人月、運用は1〜2人月規模で回る想定が現実的です。ベンダー費の置き換えだけでなく、学習速度の向上が利益の主要因になりやすい点が示唆されます。

経済性を可視化する：TCOとROIの現実的な試算

判断を感覚に委ねないために、**TCO（Total Cost of Ownership：総保有コスト）**のモデル化が欠かせません。内製シナリオでは、人件費、クラウドとSaaS、開発ツール、採用・オンボーディング、教育、セキュリティ監査、オンコール体制を含めます。外注シナリオでは、初期構築費、月額保守、機能追加単価、変更リードタイムに伴う機会損失、契約管理コストを積み上げます。モデルはシンプルで構いませんが、時間の関数として表現することがポイントです。

例えば（すべて仮定）、年間の内製コストは「FTE×年単価＋クラウド/ツール＋オンコール＋教育費」と置けます。5人チーム、年単価900万円、クラウドとツールで年間2,400万円、オンコール手当と教育に400万円とすると、合計は約7,900万円/年。対して外注は、初期3,000万円、保守月300万円、追加開発が四半期ごとに1,000万円発生するなら、1年目は約7,600万円、2年目以降は約5,200万円/年となる想定です。これだけを見れば外注が有利に見えますが、四半期ごとに重要な改善を4本入れる必要があり、その遅延が取扱高に影響するなら、機会損失を計上すべきです。

仮に主要機能の市場投入が1四半期遅れると、月間売上5億円のうち該当機能が影響する割合を5%と見積もると、1カ月2,500万円の潜在価値が先送りされます。四半期遅延で7,500万円。この分を外注シナリオに加えれば、内製チームが迅速に出せるなら、2年目で損益分岐が見えてきます。重要なのは、金額の前提と感度を経営と共有し、シナリオ分析を回すことです。

ROIは単純に「増分利益−増分コスト」を期間で割れば算出できますが、内製の価値は多くがオプション価値として現れます。例えば、規制や市場の変化に合わせたピボット能力、価格や在庫の即応的な最適化、データ保護要件のエスカレーション対応などです。これらは起きる確率は低くても、起きたときの影響が大きいので、実務では柔軟性の価値として別枠で説明できるようにしておくと意思決定が通りやすくなります。

ベンダー費の見えない固定化を疑う

外注費は変動費の顔をしていますが、契約と運用が定常化すると事実上の固定費になります⁶。仕様変更のたびに見積と受発注が必要で、待ち時間がボトルネックになっているなら、その待ち時間自体がコストです。SLAの見直し、成果物のソースコードとCI/CDの引き渡し、ナレッジトランスファーの条項など、交渉次第で学習速度を上げる余地もあります。

準備度を測る：チーム、プロセス、プラットフォーム

内製の成否は、技術力そのものよりも、反復可能な仕組みの有無に左右されます。準備度評価では、プロダクトマネジメント、アーキテクチャ、プラットフォーム、品質・セキュリティの四つを確認します。まずプロダクトマネジメントでは、顧客価値仮説がチケットに翻訳され、実装から計測、学習までが一筆書きで回るかを見ます。ここで北極星指標と補助指標が定義されていると、内製チームは自律的に優先度を決められます。

アーキテクチャでは、境界づけられたコンテキストの設計と、変更の局所性が確保されているかが鍵です。モノリスでもよいのですが、機能境界が曖昧で結合が強いと、変更は常に全体作業になり、内製の利点が摩耗します。API契約、スキーマの進化、ロギングとトレーシングの標準化が、開発速度と障害対応の両方を支えます。

プラットフォームでは、テンプレート化された環境が用意されているかが効きます。認証・監査・ネットワーク制御・シークレット管理がパッケージ化され、プロジェクトがその上に乗るだけで組織標準を満たせるなら、内製の安全係数が上がります。加えて、開発者セルフサービスのポータルやゴールデンパスがあると、立ち上げと異動の摩擦が一段と減ります。

品質とセキュリティでは、変更審査が早くて安いことが条件です。SAST/DAST（静的/動的アプリ脆弱性検査）、依存関係スキャン、IaCポリシー（Infrastructure as Codeの規約化）、リリースゲートがパイプラインに自動化されていると、レビューの心理的安全性が高まり、例外の議論に集中できます。ここでDORA指標を四半期で継続計測し、デプロイ頻度、変更リードタイム、復旧時間、変更失敗率がどの程度の水準かを公開します¹³。目安としては、内製に踏み切る前段階でも、主要サービスで週1以上のデプロイ、主要機能のリードタイム1週間以内を一つの通過点に置くと、移行初期の混乱を抑えられます。

人材戦略：採用か育成か、そして委譲

内製は人の戦略です。採用市場の逼迫を前提に、育成と委譲の計画を同時に引く必要があります。アーキテクトやSREのようなスパースな職種は外部の知見を借りながら、日々の開発・運用を担うロールは社内のキャリアパスと紐づける。ベンダーに常駐してもらいナレッジトランスファーを行う移行期間を作り、その期間にドキュメント、設計意思決定記録（ADR：Architecture Decision Record）、ランブック、SLO（Service Level Objective）の定義を揃えます。

進め方：90日パイロットと双発エンジンでの移行

大規模な鞍替えは失敗の母です。おすすめは、90日で完了するパイロットを設定し、価値の小さな島から自前のやり方で結果を出すことです。スコープは顧客に見える部分がよい。目標は、3つほどのKPIで明瞭に測れる形にし、例えば「モバイルの購入フローの離脱率を0.8ポイント下げる」「検索レスポンスをP95（95パーセンタイル）で300ms短縮する」「障害時の平均復旧時間を30%改善する」など、顧客体験と運用の両輪に効くものを据えます。

パイロットの開始時に、計測と可観測性の基盤を整えます。ログ、メトリクス、トレース、合成モニタリングを組み合わせ、ダッシュボードにKPIとSLOを並べる。デプロイは段階的リリースと自動ロールバックを必須にし、失敗率を低く保ちながら反復を加速します。ここで得られたリードタイムの短縮や不具合率の低下を事実として積み上げ、内製の次の島を広げる意思決定材料にします。

移行期は、双発エンジンで飛ぶイメージが肝心です。既存の外注ラインは安定運航を維持しながら、新設の内製ラインで新規や変更頻度の高い領域を扱います。両者の間には明確なインターフェースを設け、API契約とデータ契約で責務を切り分けます。契約上も、ベンダー側のリポジトリやCI/CDへのアクセス権、開発環境の再現方法、障害対応の連携フローを明文化しておくと、知識のサイロ化を防げます。

金融のような規制産業では、勘定系のような重厚長大なコアは専業ベンダーと長期契約を保ちつつ、顧客チャネルのアプリやオンボーディング体験、本人確認、カスタマーケアの自動化といった周辺を内製する構えが現実的です。チャネル側は毎週リリースが一般化し、口座開設の完了率が約1ポイント前後向上し、平均処理時間が2〜4割短縮したとする公開事例もあります。コアの変更を最小化しつつ、顧客価値の反復領域に内製の強みを集中する戦略は、多くの規制産業でも適用可能です。

リスク管理：ガバナンスは軽く、実効的に

内製はガバナンスを無視して突っ走ることではありません。むしろ、軽量で自動化されたガバナンスを整えることが成功条件です。アーキテクチャ審査はドキュメントとADRの提出で非同期に進め、プラットフォームにポリシーアズコード（規約をコード化して自動適用）を埋め込み、例外は期限付きで承認する。予算はプロダクト単位の小さなプールで運用し、四半期のレビューで成果と次の賭けを見直します。会議よりもメトリクスとログが語る世界を組織に根づかせてください。

社外の学びも取り込みましょう。開発生産性の計測はDORAメトリクスの実践が良い出発点ですし¹、チーム土台の構築はプラットフォームエンジニアリングの要諦にヒントが多い。また、コスト最適化を継続する仕組みはFinOpsの基本と親和性が高く、内製の固定費化リスクを和らげます⁵。

まとめ：内製化は目的ではなく、学習速度の手段

内製はバッジではありません。競争環境の変化が速く、顧客体験を磨き続ける必要があるなら、学習速度を最大化する手段として選ぶ価値があります。判断は、プロダクトの中核度と変更頻度、規制とロックイン、そしてTCOと機会損失を同じ土俵で比較するところから始まります。準備は、DORA指標を定点観測し、テンプレート化されたプラットフォームと軽量ガバナンスを整えること。進め方は、小さな島で90日パイロットを走らせ、事実で次の島を増やすことです。

あなたの組織にとって、学習のボトルネックはどこにあるでしょうか。今日からできる一歩として、ひとつのプロダクトでリードタイムと失敗率を測り、次の四半期に短縮できる打ち手を3つ記述してみてください。その小さな可視化が、「内製化」という選択を単なるスローガンから、再現可能な成果へと変えていきます。