インフラ構築 内製 vs 外注 — 判断の分岐点

インフラ構築を内製にするか外注にするかの判断を「コスト比較」だけで下すと、後から大きな修正コストが発生することがある。変更頻度・社内技術継続性・属人化リスクという3つの判断軸でフェーズごとに境界線を引くことが、構築プロジェクトの設計判断における核心だ。本記事では、その3軸を使った判断フレームとハイブリッドアプローチの設計を体系的に解説する。

「安いから内製」で失敗する理由 — 判断軸を分解する

コスト比較の落とし穴

単純な見積比較で内製を選んだ現場では、後から「想定外の工数」が積み上がるケースが多い。10台規模のオンプレサーバー構築を例に取ると、設計・調達・構築・テスト・ドキュメント化を合計した工数は、経験の浅いメンバーが担当した場合に当初見積の2〜3倍に達することも珍しくない。さらに「次の担当者への引き継ぎ準備」や「構成変更への随時対応」を加算すると、入口の数字だけで比べていた段階では見えていなかった総所有コストが浮かび上がってくる。外注の見積書と並べたときに「安い」と見えた数字が、実際には初期コストに過ぎない点を理解することが判断の出発点だ。

判断軸が「初期費用」の1軸しかないと何が起きるか

内製vs外注の選択で失敗が起きやすい根本的な原因は、判断軸が初期費用しかないことにある。実際には「変更頻度（一度きりか継続的か）」「社内に技術知見を残す必要があるか」「属人化のリスク許容度はどこまでか」という3軸が互いに絡み合い、最終的な設計コストを決定している。この3軸を整理せずに意思決定すると、外注で構築した後に「変更できる担当者がいない」「設計書が手元にない」という状況に陥りやすい。逆に内製を選んだ場合でも、担当者が1名で設計知識を抱え込んだ結果、異動・退職後に環境の全体像を把握できる人間がいなくなるという別のリスクが生まれる。

判断ミスが引き起こす修正コスト

内製・外注の選択を誤ったときに最も問題になるのは、後から方向を変えようとしたときの修正コストだ。外注で構築した環境を後から内製化しようとすると、設計図の再起こしから始めなければならない。あるプロジェクトでは、5環境のネットワーク設計を外注で完成させた後、担当ベンダーが事業縮小したことで内製化を試みた際、設計書の解読と現状把握だけで約2ヶ月を要したという事例がある。IaC（Infrastructure as Code）が整備されていない状態で内製担当者が交代した場合も、現状確認のための調査工数が数週間規模になることがある。こうした修正コストを判断材料に含めることが、3軸フレームの前提になる。

内製が向く構築・外注が向く構築の技術的な違い

内製に向く構築の特性

「頻繁に変更が生じる」「社内の業務ロジックと密結合している」「長期にわたって運用を継続する」という3つの特性が重なる構築は内製に向く。具体的には、CI/CDパイプラインの設計・Kubernetesクラスターのリソース設計・監視アラート設計などが該当する。CI/CDパイプラインはアプリケーションの変化に追随して頻繁に更新されるため、変更のたびにベンダー調整を挟む設計では開発チームのリリースサイクルに対応できなくなる。監視設計も、業務上の「正常状態」を把握している担当者が設計に関与していないと、検知すべき異常を見落とすリスクが高まるため、外部委任の比重を下げる必要がある。

外注に向く構築の特性

「構築後に構成変更が少ない」「汎用的な技術スタックで完結する」「社内に技術知見を積み上げる必要がない」という構築は外注に向く。物理ラックの組み立てとケーブリング・BIOS設定といった一次構築フェーズ、ネットワーク機器のベースラインコンフィグ設定、あるいはオンプレミスからクラウドへの一括移行（リフトアンドシフト）がこれに当たる。設計書さえ整っていれば手順を再現できる作業や、移行完了後に継続利用する見込みがない技術スタックは、外注で処理効率を上げる合理性がある。ただし「汎用的だから外注」という判断は、実装後に変更が生じたときに誤りになることがあるため、変更頻度の見通しを先に確認することが前提だ。

構築タイプ別の内製・外注適性

構築タイプ	内製	外注	主な理由
CI/CDパイプライン設計	◎	△	変更頻度が高く業務ロジックと密結合
物理サーバー一次構築	△	◎	一度きりで汎用手順が確立している
ネットワーク機器初期設定	△	◎	標準設定で完結し反復性が低い
Kubernetesクラスター設計	◎	○	継続的な設計判断が長期に必要
オンプレ→クラウド移行（リフトアンドシフト）	△	◎	移行後に知見を継続利用する機会が少ない
IaC実装（設計済みの範囲）	○	◎	設計内製・実装外注の境界として機能しやすい
監視・アラート設計	◎	△	業務の正常状態の理解が必要で継続更新が前提

判断軸1: 変更頻度と運用継続性

「一度きり」vs「継続的変更」の分け方

「この環境は、構築後どれほど変化するか」という問いが判断の起点になる。物理サーバーの初期設定やネットワーク機器のベースラインコンフィグは、構築後に大きく変わることが少ない典型例だ。これに対してKubernetesのリソース設定・CI/CD環境の設定ファイル・モニタリングルールは、アプリケーションの変化や組織変化に追随して継続的に更新される。変更頻度が月1回以下に収まる構築であれば外注のリードタイムで対応できるケースも多いが、週1回以上の更新が見込まれる環境を外注に委ねると、変更依頼・見積・承認のサイクルがそのままボトルネックになりやすい。

変更頻度が高い環境を外注した場合の失敗パターン

変更頻度の高い環境を外注で管理すると、変更反映のリードタイムが開発チームとの摩擦を生む。あるインフラチームでは、クラスターのノードスケーリング設定の変更をベンダーに依頼したところ、要件確認・見積・承認・実装のサイクルにより平均10営業日を要するようになった。その結果、開発チームが求めるデプロイサイクルとのギャップが広がり、最終的に内製化の判断を下すことになったが、既に外注で構築された環境の設計書を取得し直す作業が別途発生した。こうした失敗を防ぐには、変更頻度の高い環境はIaCで内製管理し、コードレビューとGitフローで変更履歴を管理する設計にすることが現実的な対策だ。

運用継続性の観点から設計を組む

変更頻度に加え、「誰が長期的に運用するか」も判断軸に含める必要がある。構築担当が内製で、その後の運用が別部署や外注先になる場合、設計意図の外在化（ドキュメント化）が構築工程に組み込まれていなければ、運用開始後の問い合わせコストが増大する。内製構築の場合は設計意図が担当者の暗黙知として残るが、外注構築を内部で運用するケースでは設計ロジックの引き継ぎが必須となる。この前提を構築の開始段階から設計要件に含めておくかどうかが、後工程の運用コストに直結する点を見落としやすい。

判断軸2: 社内に残すべき技術知見か、一度きりか

コア技術と周辺技術の整理

構築に使う技術が自社サービスの競争力の基盤になるかどうかを見極めることが、重要な判断軸になる。例えば、自社サービスの大規模データ処理基盤を設計する場合、ストレージ層の選択・データレイテンシの設計・スケールアウト戦略は将来のシステム拡張の基準となり続ける。このような「設計の選択が長期にわたって効き続ける」構築は、社内に設計知見を積み上げる必要がある。一方で、汎用的なOSインストールや既製品ソフトウェアのパラメータ設定は、設計知識が個人に蓄積されてもビジネス上の優位性に直結しにくく、外注に委ねても競争力への影響は限定的だ。

一度きりの構築で外注を活用する設計

「この規模では二度と使わない技術スタック」や「特定の移行プロジェクトのみで使用する技術」は、外注で完結させても社内への残留影響は少ない。オンプレミスからクラウドへの一括移行では、移行ツール固有の操作知識を社内に残す必要性は低く、移行完了後に再利用する機会もほぼない。こうした「出口が見えている構築」では、外注によって移行品質と速度を上げることが合理的な選択になる。ただし、移行後の運用環境（クラウド上の構成管理）については移行後に内製が引き継ぐことになるため、移行プロジェクト中から運用担当者を設計レビューに参加させる体制が必要だ。

外注しながら知見を社内に蓄積する中間設計

外注を活用しながら社内知見を蓄積する中間的なアプローチも選択肢になる。外注ベンダーに実装を委ねつつ、社内担当者を設計レビュー役として参画させ、構築中の判断ロジックを社内に取り込む方法だ。この場合、週次の設計レビューセッションを契約マイルストーンに含め、設計書の所有権を発注側（自社）に帰属させる条件を明記しておく必要がある。これを怠ると、設計書はベンダー管理のドキュメントとして残り、ベンダー変更や内製化の際に取り出せなくなるリスクが生じる。「外注で作る、知見は内製に残す」という設計は、契約の段階から作り込む必要がある。

判断軸3: 属人化リスクと引き継ぎコスト

内製の属人化はどう生まれるか

内製構築における最大のリスクの一つが属人化だ。担当者1名が設計・実装・ドキュメント化のすべてを抱え込んだ場合、その担当者が離職・異動すると環境の全体像を把握できる人間がいなくなる。IaCで管理されていない5〜10台規模のサーバー構築でも、後任が現状確認を行うだけで数週間を要することがある。この問題の厄介な点は、構築完了直後には見えにくく、1〜2年後に担当者の変化が起きたときに初めて表面化することだ。内製を選択する際は、構築工程から「他者がレビューできる状態のコード・ドキュメント」を成果物の一部として定義し、属人化を防ぐ設計を最初から組み込む必要がある。

外注特有の属人化リスク

外注にも別種の属人化リスクがある。特定ベンダーの特定担当者に設計知識が集中した場合、その担当者の交代によって「なぜこの設計を選んだか」という判断ロジックが失われる。ベンダー内での担当者変更は発注側からコントロールできず、プロジェクト途中での交代によって設計意図が消えるケースは実際に多く報告されている。これを防ぐには、設計判断の根拠を「設計ロジック書（なぜこの選択をしたかを記録したドキュメント）」として納品物に含める要件を最初から設けることが有効だ。設計書と設計ロジック書は別物であり、後者がなければ前者だけでは再設計の起点にならない。

引き継ぎコストを設計に織り込む

内製・外注どちらであっても、引き継ぎコストは設計段階から見積もりに含める必要がある。一般的な経験則として、構築工数の15〜20%をドキュメント化と引き継ぎ準備に充てていない構築は、後任担当者が現状を把握するためのコストでその差分が消える。内製の場合はIaCのコードをレビュー可能な状態に保つ工数を、外注の場合は設計書レビューと承認サイクルの工数を見積もりに含めることが求められる。これを「作業コスト」としてではなく「設計要件」として位置づけると、プロジェクトのスコープ定義の段階から引き継ぎを考慮した計画が立てられる。

ハイブリッド（設計は内製・実装は外注）の設計

ハイブリッドが有効なケース

「設計は内製、実装は外注」というハイブリッドアプローチは、技術知見を社内に残しながら実装工数を圧縮したい場合に有効だ。クラウドインフラのアーキテクチャ設計（リージョン選定・ネットワーク設計・IAM設計）を内製で行い、TerraformなどのIaCコードの実装を外注に委ねる構成では、設計意図は社内に残りつつ、コーディング工数を外部リソースで賄える。特に社内エンジニアが3〜5名規模で、設計判断は持ちつつ実装リソースが不足しているチームでは、この分担が現実的な選択になる。外注担当者に任せる範囲を「設計書に記載された実装範囲のみ」に限定することで、設計の主導権は内製側に保てる。

ハイブリッドが失敗するパターン

ハイブリッドが機能しないのは、設計と実装の境界が曖昧なときだ。設計書に記載されていない実装上の判断（ライブラリ選定・エラーハンドリングの方針・サービス間の依存関係の扱い）が外注担当者に委ねられると、後から仕様不整合が発覚する。また、設計担当の社内エンジニアが技術的な深さを持っていない場合、実装上の制約を設計に反映できず、実装着手後に設計の手戻りが発生しやすい。現場では「設計書を渡したが外注担当者が独自の判断で実装を進め、完成後に要件との乖離が判明した」という話をよく聞く。ハイブリッドを選ぶなら、内製担当者が「実装可能な粒度の設計書」を書ける技術力を持つことが前提になる。

ハイブリッドを機能させる契約設計

ハイブリッドアプローチを成立させるには、発注範囲の定義が鍵になる。「設計レビューは発注側が行い、設計変更の最終判断権は発注側にある」という条件を契約に明記することで、実装中に生じた設計上の判断が外注担当者によって単独で決定されることを防げる。週次の設計整合レビューをマイルストーンとして組み込み、発注側の確認なしに実装が先行しない体制を作ることも重要だ。加えて、実装完了後の設計書との整合確認（設計書への実装フィードバック反映）を検収条件に含めることで、「実装が先走った設計」との乖離を防ぐことができる。

分岐点チェックフレーム

以下のチェックフレームを使って、内製・外注・ハイブリッドのどれを選ぶかを構築プロジェクトの開始段階で確認することで、設計判断の抜け漏れを防ぐことができる。各項目に「Yes」が多いカテゴリを優先的に検討する基準として活用してほしい。

内製を選ぶ前に確認する項目

1. 構築後も継続的な変更・更新が月1回以上見込まれるか
2. その技術知見が将来の設計判断（スケール・拡張・改修）に影響し続けるか
3. 担当者が複数名でレビューできる体制があるか
4. IaCなどで設計とコードを一体管理できる体制があるか
5. 担当者の異動・退職時の引き継ぎ計画を設計に含めているか

外注を選ぶ前に確認する項目

1. 設計意図を記録した「設計ロジック書」を納品物に含める要件を設けているか
2. 変更依頼のリードタイムと自社の変更頻度が整合しているか
3. 担当ベンダーの担当者交代リスクに対する契約上の条件があるか
4. 設計書の所有権が自社（発注側）に帰属することを契約に明記しているか
5. 外注完了後に別ベンダーへ移行・内製化した場合のコストを試算しているか

ハイブリッドを選ぶ前に確認する項目

1. 内製担当者が「実装可能な粒度の設計書」を書ける技術力があるか
2. 設計と実装の境界を文書で明確に定義できているか
3. 設計変更の最終判断権が発注側にある条件を契約に含めているか
4. 週次の設計整合レビューを契約マイルストーンとして組み込んでいるか

内製・外注・ハイブリッドのどれを選ぶかよりも、「変更頻度」「知見継続性」「属人化リスク」の3軸を整理したうえで判断を下すことが、構築プロジェクトの後工程コストを左右する。この判断を設計フェーズの最初に行うことで、実装後の方向転換コストを大幅に抑えることができる。手を動かす前に「この構築はどの性質を持つか」を問う習慣が、インフラ設計判断の質を高める起点になる。