GitOps時代の“ハンドオーバー自動化”実践ノート ― 開発会社と内製チームをつなぐ運用設計
はじめに
企業がシステム開発会社へ受託発注した後、プロダクション運用を内製チームへハンドオーバーする――このフェーズで失敗すると、せっかく高い費用を投じて開発したアプリや業務システムが「誰も触れないブラックボックス」になり、追加改修のたびに再び外部ベンダーへ高額見積もりを依頼する悪循環に陥ります。そこで近年注目されているのが GitOps を基盤にしたハンドオーバー自動化 というアプローチです。本稿では、大規模 Web システム運用の現場で培ったノウハウをベースに、要件定義・システム設計・プロジェクト管理の各工程へ GitOps をどう組み込み、費用対効果を最大化するかを解説します。
そもそもハンドオーバー自動化とは
ハンドオーバー（引き継ぎ）の自動化とは、開発会社が構築したコード／インフラ／監視設定を Git リポジトリ 1 か所に集約 し、CI/CD パイプラインでインフラとアプリの状態を再現可能にすることで、受託開発と保守運用の境界を曖昧化する思想です。ポイントは以下の 3 点です。
-
Infrastructure as Code（IaC）：Terraform や AWS CDK でクラウド資源をコード化
-
フロー中心のドキュメント：HowTo ではなく Pull Request の履
ハンドオー
歴そのものを導線化
-
監視ダッシュボードのコード管理：Prometheus ルールや Grafana JSON をバージョン管理
これにより、内製チームが翌月からオンコールに入っても “再現手順にギャップがない” 状態を確保できます。
開発会社選びが運用設計に与えるインパクト
GitOps を本気で回すには、受託側が最初から Git リポジトリを公開し、見積もり段階で IaC スケルトンを提示 できる能力が欠かせません。見積書に「IaC 行数」「CI/CD ステップ数」を明示してくる会社は少数派ですが、長期的にはコスト削減インパクトが大きいです。たとえば Terraform 行数 3,000、GitHub Actions ジョブ 25 本で構成された案件を比較すると、
-
GitOps 対応会社 A：要件変更時の追加費用 15 %
-
従来型会社 B：要件変更時の追加費用 40 %
という差が生まれた事例があります。
選定チェックリストとしては
-
PoC 段階で “README 駆動開発” を実践しているか
-
Pull Request に コスト試算ロジック（例：AWS Cost Explorer API） を自動書き込みしているか
-
運用 Runbook を Markdown でリポジトリ管理 しているか
を確認すると良いでしょう。
GitOps パイプライン設計の 5 レイヤ
GitHub Actions／GitLab CI／ArgoCD などツールは多彩ですが、レイヤ分割は共通です。
1. Lint & Static Analysis
コード品質を自動検査し、修正コストを設計段階で極小化。ESLint／tfsec などを統合。
2. Unit & Contract Test
API 仕様を OpenAPI で定義し、受託チームと内製チームのコミュニケーションロスをゼロ に。
3. Build & Containerize
マルチステージビルドでイメージ容量を 60 % 削減し、デプロイ時間短縮によるレイバーコスト圧縮。
4. Deploy & Promote
Argo Rollouts でカナリアリリース。障害ロールバックを 1 クリック化。
5. Observe & Alert
Prometheus Rule を PR 上でレビューし、SLO 違反をコード差分として議論可能に。
自動化が難しい “非機能要件” とコスト見積もり
可用性 99.95 % を担保するには マルチ AZ＋オートスケール が必須ですが、CloudWatch Logs 推定課金を見逃すと月数十万円の差が出ます。見積もり時点で
-
リクエスト数／秒 × ログ行数 × 保持期間
-
可観測性 SaaS（Datadog 等）の Hot Storage 日数
を積算し、“1 リクエストあたりの運用単価” を提示できる開発会社は信頼度が高いです。
Pull Request テンプレートで「運用タスク実装チェックリスト」を自動付与
内製チームへハンドオーバーする際、PR に以下のチェック欄を自動生成すると、抜け漏れが激減します。
-
Terraform Plan に drift なし
-
New Relic Alert Policy 登録済み
-
Runbook セクション追加済み
-
Cost Impact コメント生成済み
これを GitHub Apps で Bot 化し、マージ不可条件に設定しておくと、開発会社→運用チーム間で責任共有が可視化 されます。
コスト削減シナリオの A/B テスト
GitOps は コスト最適化の実験環境 としても機能します。例：
-
A シナリオ：オンデマンド EC2 × Aurora
-
B シナリオ：Fargate Spot × Aurora Serverless v2
それぞれの Terraform ワークスペースに Cost Anomaly Detection を連携し、30 日間で 18 % 削減 を実証したケースもあります。この結果を意思決定者へ示すことで、追加予算の承認がスムーズになります。
ハンドオーバー後90⽇で計測すべきKPIセット
受託開発から内製運⽤へ切り替えた直後は「障害ゼロ」を追うよりも 改善速度とナレッジ蓄積 を数値化するほうが実態を捉えやすくなります。推奨するKPIは次の5つです。
-
PRリードタイム（コード着⼿〜本番反映）
-
インフラ差分解消時間（Terraform Planで差分検知〜Apply完了）
-
オンコール平均対応時間（PagerDuty ACK〜Close）
-
運⽤Runbook追加件数／週
-
コスト削減Pull Request比率（総PRに占めるコスト関連PR）
これらを Datadog Dashboards と GitHub API で可視化し、毎週レビューすることで「内製チームが改善サイクルを回せているか」を定量把握できます。KPI を Git リポジトリの README バッジに表示すると、経営層もワンクリックで状況を把握できるため意思決定が迅速になります。
内製チーム育成ロードマップ
ハンドオーバーが完了しても、内製メンバーが PR レビューと On-call 当番 を両⽴できなければ意味がありません。以下 3 段階でスキル移譲を進めると、半年以内にフル内製を達成しやすくなります。
ステージ1：シャドー運⽤（0-1か⽉）
受託チームのオンコールに内製エンジニアが同席し、障害ログの読み⽅と即応⼿順を学習します。
ステージ2：ペアレビュー（1-3か⽉）
内製メンバーが作成した PR を受託側リードがレビュー。逆に受託側の PR を内製チームがレビューする クロスレビュー制 で知識を相互補完。
ステージ3：ソロオペレーション（3-6か⽉）
内製チーム単独でローリングデプロイを回し、受託チームは月次アドバイザリだけを提供。SLO 達成率をウォッチし、90⽇連続で基準値を下回らなければ契約を運⽤監査レベルへ縮小します。
ロードマップを事前に見積書へ添付しておくと、費用対効果を経営層へ説明する材料になります。
失敗事例とその回避策
GitOps ハンドオーバー案件で散⾒される失敗パターンは次の3つです。
| よくある失敗 | 原因 | 回避策 |
|---|---|---|
| CI/CD が本番環境にしかつながっておらずステージングで検証できない | 見積もり時に「環境数×パイプライン数」を示していない | マルチアカウント設計 と パイプライン複製コスト を RFP へ明記 |
| 監視ルールを開発会社の New Relic テナントに置いたまま移譲忘れ | 監視設定をコード化せず手動作成 | Grafana JSON や NRQL を Git にコミット、PR レビュー対象へ |
| コストアラートが USD 建てで財務部門が読めない | 為替換算ロジック未実装 | Cost Explorer API + 為替レート取得を Lambda Cron で自動更新 |
いずれも「仕様に書かれていないから後回し」と判断しがちですが、ハンドオーバー遅延が発生すると追加予算を消費 します。PR テンプレートにチェックボックスを用意し、「空欄のままではマージ不可」に設定しておくと早期に問題を炙り出せます。
トラブル対応を“イベントドリブン”で自動化する
GitOps では 障害発生→ブランチ切り→Rollback Merge を 1 クリックで実現できますが、さらに イベントドリブンな ChatOps を組み合わせると運⽤負荷は激減します。具体的には、
-
PagerDuty Webhook 到着→Slack チャンネルへ自動スレッド作成
-
スレッド URL を GitHub Issue に自動転記
-
Issue Close 時に Terraform Destroy Plan を CI へキック（不要リソース自動削除）
こうした仕組みを「非常時の Check-list」として Runbook へ取り込み、DR テスト日を年 4 回設定すると、“運⽤のバス係数” を 5 → 15 に向上 させることも可能です。
長期保守契約を“監査付きサブスク”へ再設計する
従来は「月次稼働 40 時間 × 単価」という保守契約が一般的でした。しかし GitOps では “監査” と “改善提案” が主業務になるため、以下のようなサブスクモデルへ移行すると費用を抑制できます。
| プラン | 月額 | 提供範囲 | KPI |
|---|---|---|---|
| ベース | 20 万円 | SLO 監査／月次レポート | MTTR <= 30 分 |
| アドバンスト | 35 万円 | 上記 + コスト最適化提案 3 件/月 | 予算差異 -10 % 以内 |
| フルマネージド | 60 万円 | 24/7 オンコール + 改修実装 2 PR/月 | 障害回数 <= 1/月 |
監査指摘→改善 PR を 1 サイクルとし、GitHub Projects で可視化することで「開発会社へ支払う運⽤費」が成果に紐づくため、経営陣の納得感が向上します。
まとめ
GitOps を前提に “ハンドオーバー自動化” を設計すれば、開発会社の専門知識と内製チームのドメイン知識をシームレスに統合できます。結果として
-
プロジェクト管理コスト 25 % 削減
-
改修サイクル 60 % 短縮
-
クラウド費用 15 % 削減
といった具体的な数値効果が期待できます。RFP 段階で GitOps 対応ベンダーを選定し、IaC・CI/CD・監視ルールを “コードファースト” で管理することが、長期的な保守費用圧縮と内製化成功のカギを握ります。今後のシステム開発依頼では「ハンドオーバー計画」が見積もり比較の中心軸となるでしょう。
