Article

内製開発 vs SES活用:プロジェクトに応じた最適な体制とは

高田晃太郎
内製開発 vs SES活用:プロジェクトに応じた最適な体制とは

国内の調査では、IT人材の不足感を抱える企業は7割超、2030年の不足規模は最大約79万人規模に達するとの推計があります[1][2]。研究データでは、熟練エンジニアの採用から本番投入までにかかる期間は平均で数カ月単位となり、チームの生産性立ち上がりにはさらに時間が必要と示されています[3]。複数の公開レポートを総合すると、内製(自社での開発体制の構築)は中長期の競争力に寄与する一方、短期の納期・需要変動・専門スキルの確保については外部人材の活用がリードタイム短縮に繋がるケースが一定数あることが見えてきます[4]。つまり、内製かSES(System Engineering Service:外部のエンジニアを時間単位で活用する形態)かを二者択一で決めるのではなく、プロジェクトの不確実性・期間・知的財産の重要度・品質要求を軸に最適解を動的に選ぶことが、いまのCTO・エンジニアリングリーダーに求められている判断です。

意思決定の土台:4つの軸で比較する

感覚や前例で体制を決めると、短期の最適化が長期の負債に化けます。ここでは、コスト、スピード、品質、リスクという4軸に分解し、それぞれに内製とSESの傾向をマッピングします。まずコストは、見かけの人件費やレートだけでなく、採用・オンボーディング・離職・知識定着の費用まで含めたTCO(総保有コスト:Total Cost of Ownership)で評価することが前提です。内製は初期固定費が増える代わりに、稼働が安定すれば一人月あたりコストは逓減します。対してSESは可変費として柔軟ですが、長期固定化でレートの累積がTCOを押し上げます。

スピードは、チームの立ち上がり速度と変更耐性で見ます。内製は採用と育成のリードタイムがネックになりがちですが、プロダクトコンテキストの学習が進むほど変更に強い継続的デリバリーを実現しやすくなります。SESは調達がスムーズなら即戦力を短期投入できますが、コンテキスト不足や契約境界での待ち時間が積もると、変更コストが跳ね上がることが少なくありません。

品質は、DORAの四指標(デプロイ頻度、変更のリードタイム、変更失敗率、サービス復旧時間)で客観評価します[5]。DORAはDevOpsのパフォーマンスを測る実務的な物差しで、手元の運用データから継続的改善の効果を見える化できます。内製はリリース権限やツール選定を自律的に最適化できるため、改善の累積が効きます。SESでも高い品質は狙えますが、組織をまたぐとリリースゲーティングや責任分界の調整が増え、ループが長くなる傾向が出ます。

リスクは、IP(知的財産)の流出、属人化、供給途絶、コンプライアンス違反の観点で比較します。IPやアルゴリズムのコアは内製の支配権と知識蓄積が長期の安全弁になりやすい一方、短期トラフィックの山谷や専門スキルの稀少性についてはSESでの可変調達が全体の供給リスクを下げます。知識不足や既存システムとの関係性に起因する課題は公的白書でも上位に挙げられており、ナレッジの保持と移転設計は体制選択と不可分です[6]。結論として、プロジェクトの不確実性が高いほど内製比率を上げ、需要変動や特殊スキルの比重が高いほどSESを弾力的に組み込む発想が実務的です。

ケースで捉える:新規0→1とレガシー刷新

新規プロダクトの0→1(ゼロイチ:新規立ち上げ)では、仮説検証の速度と仕様変更の頻度が支配的です。ここでは、プロダクトマネジメントと設計・コア開発を内製の小さな精鋭に寄せ、短期的に足りない専門実装や検証をSESで補うと、ピボット時の摩擦を抑えながら学習速度を維持できます[4]。逆にレガシー刷新の大規模案件では、要件が比較的明確で反復的な作業が多くなりがちなため、テスト自動化や移行の実務をSESでスケールさせ、品質基準と運用を内製側がガードレールとして握る設計が効果的です。

コストとROI:TCOで語るための算定フレーム

CFOと対話できる言葉で体制を説明するには、TCOとROI(投資利益率)を明示することが不可欠です。TCOは、固定費(基本給、福利厚生、設備、ツール)、変動費(採用、教育、離職補填、外注)、機会費用(出荷遅延、品質事故による売上・評判損失)を合算して期間で割り戻し、比較対象が同一のアウトプット単位になるよう調整します。ROIは、増分売上やコスト削減(例:自動化による工数削減と障害コスト低減)からTCOを差し引き、投下資本に対して年率換算します。ここで重要なのは、SESのレート比較に終始しないことです。たとえば、年間で一定の恒常需要(例:3人月規模)があるのに常時SESを当て続けると、意思決定は簡単でも、翌年以降の継続コストが自動的にロールし、内製化の学習効果とスケールメリットを取り逃がします。

一方で、内製の採用と育成には見えにくい先行投資が埋もれがちです。採用費やオンボーディングの工数、暗黙知の文書化、設計原則の合意形成、レビュー体制の確立など、最初の数カ月は帳尻が合わないように見えます。だからこそ、ブレークイーブン(投資回収点)の時点を数値で仮置きすることが現実的です。たとえば、月間の安定需要が一定以上、変更頻度が高い、IPのコア性が強い、SaaSの差別化に直結する、といった条件が揃うと、12〜18カ月で内製が総コスト面でも逆転するシナリオは珍しくありません。逆に、季節波動が大きい、スキル希少性が高く短期需要、依存する外部APIの寿命が短い、といった条件が強いほど、SESの可変費メリットが生きます。

契約の形態もTCOに直結します。準委任(時間精算)は柔軟ですが、成果水準のコミットが弱くなる傾向があります。請負は達成責任が明確な一方で、変更管理のコストが顕在化しやすい。アジャイル契約を採用し、スプリント単位での受け入れ基準と価値指標を合意できれば、SESでも成果志向に寄せられます。

サンプル計算:内製3名 vs SES3名の12カ月

仮に、内製エンジニア3名の年額総コストが各900万円(給与・福利厚生・ツール等込み)だとすると、年間2,700万円です。採用・育成の初期費用を300万円、プロダクト知識の立ち上がりで最初の3カ月の生産性を70%と見積もると、初年度実効生産性は0.925人年×3相当になります。SES3名を月180万円のブレンデッドレートで12カ月継続すると、年間6,480万円です。SESは初期立ち上がりが速いとしても、ドメイン知識の学習コストや交代時の引き継ぎロス、ベンダー管理の間接コストが積み上がります。もちろん、この単純比較はプロダクトの収益寄与や市場投入の前倒し効果を含めて再評価する必要がありますが、一定の恒常需要がある限り、内製の学習曲線がTCOを押し下げるという傾向は見落とせません。

スピードと品質:メトリクスで両立させる

スピードと品質はトレードオフに見えますが、デリバリーのシステムを設計すれば両立できます。鍵は、チーム境界を跨いだフロー効率を高め、待ちをなくし、バッチを小さくすることです。内製主体の場合は、デプロイ自動化、テストカバレッジの戦略、リリース権限の分散といった基盤整備に投資し、DORAメトリクスを四半期でレビューします。SES主体またはハイブリッドの場合は、受け入れ基準をコードレベルで共有し、レビューとテストを共通パイプラインに載せることで、組織境界によるループの長さを制御します。たとえば、CI(継続的インテグレーション)のログと欠陥の帰属を曖昧にしない運用により、変更失敗率と復旧時間の責任所在を明確化できます。

学習速度の担保も重要です。ドメイン知識の移転は、口頭説明やチケットの添付資料だけでは足りません。アーキテクチャ決定記録(ADR)と運用手順、SLI/SLO(サービスの指標と目標)、設計原則の例外ルールまで含めたナレッジの再利用単位を定義し、作成・更新を契約条件や評価指標に組み込みます。これにより、SESの交代時の摩擦を下げ、内製チームが負債を引き取る際の移行コストも抑制できます。

リスク制御:契約と運用の二層で握る

IP、セキュリティ、供給途絶のリスクは、契約の条項と日々の運用に分けてコントロールします。契約では、成果物の権利帰属、サードパーティライセンスの取り扱い、生成AI利用のポリシー、代替人員の事前承認、離任時の引継ぎ成果物、コンプライアンス(個人情報、金融、医療等)への準拠条件を具体化します。運用では、アクセス権限の最小化、秘密情報の分類とマスキング、シャドーイング期間の確保、週次の価値レビューとリスクレビューをパルスとして固定化します。こうした二層の仕組みができていれば、体制の構成比はプロジェクトの変動に応じて柔軟に動かしても安全域を保てます。

ハイブリッド体制の設計:動かせる中核と弾力の周縁

実務では、内製の**中核(Core)とSESの周縁(Periphery)**を意識した設計が有効です。Coreは、プロダクト戦略、アーキテクチャ、コアドメイン、SRE、セキュリティ、データガバナンスの責任を担い、ロードマップと品質基準を握ります。Peripheryは、実装のスループット拡張、専門スキルの点的投入、検証・移行・運用補助など、需要波動に合わせた容量調整を担います。この分割は単なる役割分担ではなく、境界の横断コストを最小化するための設計課題です。たとえば、API契約の整備、スキーマのバージョニング規約、障害対応のRACI(責任分担の明確化)、仕様変更時の影響分析のフォーマットなど、協調に必要なプロトコルを先に決めておくことが、後工程の摩擦を劇的に減らします。

人と時間のダイナミクスも設計に含めます。新規開発の前半は内製比率を高めて意思決定を速くし、検証や移行の山場ではSESの比率を一時的に上げ、安定運用フェーズでは内製運用に回収しつつ、継続改善のために限定的に専門家を呼び戻す、といったフェーズごとの比率調整が有効です。評価と報酬の設計も連動させ、内製には継続的改善と知識共有の成果を、SESにはデリバリーの予見可能性とナレッジ移転の量・質を指標として提示します。こうした全体設計は、開発組織設計の原則と相性が良いアプローチです。

ベンダーマネジメント:関係をコストではなく価値で測る

SESパートナーを単なる稼働の穴埋めとして扱うと、すぐにレートと稼働消化のゲームに陥ります。代わりに、価値で測る関係に変えます。具体的には、オンボーディングから価値創出までの時間、スプリントごとのスループット安定性、変更失敗率、ナレッジ移転の成果、離任時の可逆性を、四半期の評価指標に組み込み、改善計画を共同で作る運用にします。契約更新は、これらの指標に基づくボーナス・ペナルティの仕掛けと組み合わせることで、短期の単価交渉を超えた長期のパフォーマンス最適化に繋がります。

コンプライアンスと生成AI:新しい現実への適応

生成AIのコード支援が一般化したいま、内製・SESを問わず、第三者の権利やセキュリティ要件への配慮は必須です。AI支援の利用範囲、プロンプトと出力の取り扱い、ライセンス監査、機密データの持ち出し防止について、方針とツールをチーム横断で統一します。SES契約にも、AI利用の可否とガイドライン、監査への協力義務、検知されたコンプライアンス違反時の是正フローを明記し、運用面ではリポジトリのスキャン、依存関係のライセンス検査、SBOM(Software Bill of Materials:ソフトウェア部品表)の管理を標準化します。これにより、スピードと安全性を両立する新しい標準作業がチームの境界を超えて機能します。

まとめ:意思決定を再現可能にする

最終的に、内製かSESかの議論はプロジェクトの文脈に依存します。重要なのは、同じチームが同じ状況であれば同じ結論に至る、再現可能な判断基準を持つことです。コストはTCOで、スピードと品質はDORAを中心に、リスクは契約と運用の二層で、そして体制はフェーズに応じて比率を可変に——この一連の枠組みが土台になります。次の四半期計画を見直すいま、あなたのプロダクトでコアに据える領域はどこか、需要の山谷はどこにあるか、そしてハイブリッド体制をどう設計すれば学習速度と安全域を最大化できるかを、チームで対話してみてください。今日の一歩は小さくても、再現可能な意思決定は確実に明日の競争力に転化します。

参考文献

  1. PRTimes. 企業のIT人材不足に関する調査(調査の結果、75%…)https://prtimes.jp/main/html/rd/p/000001851.000005089.html
  2. 日刊工業新聞. 経産省が日本のIT人材不足の推計を発表(2030年に約79万人)https://www.nikkan.co.jp/articles/view/00388679
  3. Coté, M. 60 to 100 days to onboard a developer. https://newsletter.cote.io/p/60-to-100-days-to-onboard-a-developer
  4. Impress DXross コラム. 「DX白書2023」にみる外部リソース活用とアジャイルの潮流。https://dcross.impress.co.jp/docs/column/column20230317/003381.html
  5. Google Cloud Blog. Using the Four Keys to measure your DevOps performance. https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
  6. 総務省 情報通信白書(令和3年版)デジタル化の阻害要因(「的な知識不足」「既存システムとの関係性」等)。https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r03/html/nd112490.html