バックエンド／SREから外注すべき領域の切り方

「開発は全部外に出す」「いやコアは全部内製」——議論が両極端になりがちだ。実際に効くのは、感情的な線引きではなく、変更頻度と障害影響で領域を切ることだ。

バックエンドとSREは、画面のように切り出しやすい部分と、事業の生死に直結する部分が混在する。ここを雑に切ると、インターフェース地獄か、丸投げ依存のどちらかになる。

残す／出す／一緒にやる、の3分類を先に1枚にする。

結論：切り方の表

分類	目安	例
残す（内製）	変更が多く、ドメイン知識が競争力	中核のドメインロジック、課金ルール
出す（外注）	変更が比較的安定、専門性が高い	特定の基盤構築、移行プロジェクト
一緒にやる	障害影響が大きい、または境界が動く	認証、観測、デプロイパイプライン

「得意なので全部できます」は切り方ではない。境界と責任分界を先に書く。

事例1：フロントごと出して遅延したケース

匿名化した一例。少人数の内製チームが、フロント＋API＋インフラを一式外注。要件変更のたびに「画面もAPIもインフラも」待ちが発生し、リードタイムが内製時代より悪化した。

分岐点は発注範囲だ。中核APIは内製に残し、管理画面とバッチ基盤だけ外に出していたら、変更の待ち行列は短く済んだ可能性が高い。

事例2：基盤だけ出して加速したケース

別の一例。プロダクトAPIは内製、Kubernetes移行と観測基盤だけを期間限定で外注。インターフェース（リポジトリ、環境、オンコールの一次）を文書化し、8週間で内製チームが運用を受け取った。速くなったのは「全部任せた」からではなく、境界が明確だったからだ。

論点：インターフェース・オンコール・コスト

• インターフェース: API契約、イベント、環境変数、権限。ここが曖昧だと結合で必ず止まる
• オンコール: 夜に起こすのは誰か。外注期間中と終了後で分ける
• コスト: 人月単価比較だけでなく、待ち時間と切り替えコストを見る

判断軸：外に出す／内に残す

出す	残す
期間限定の専門作業で、完了条件が書ける	毎週仕様が変わり、事業判断と密結合
社内に一時的にスキルがないが、受け取り計画がある	障害時の判断を外に出せない規制・契約上の制約
「一緒にやる」で境界を固定できる	境界自体がまだ揺れている（まず境界設計）

次に確認すること

1. 変更頻度×障害影響のマトリクスを1枚作ったか
2. 出す領域の完了条件と受け取り担当はいるか
3. オンコールの一次／エスカレーションは書いたか
4. インターフェースのオーナーは社内か
5. 「なんでも外注」になっていないか

まとめ

バックエンド／SREの外注は、得意分野の丸投げではない。変更頻度と障害影響で残す・出す・一緒にやるを切り、インターフェースとオンコールを先に決める。 切れるなら外注は加速装置になる。切れないなら、先に境界設計だ。

---

バックエンド・SRE領域の切り出し相談は、お問い合わせフォーム からどうぞ。