概要
廃止判断はデータで行う
「役目を終えた」は主観。ピーク比3%とはいえ月240件・3者が今も依存している実測値から出発しないと、廃止計画そのものが説得力を持たない。
依存関係マップは契約条件まで含める
呼び出し元の列挙だけでは不十分。外部委託先の「仕様変更は14営業日前書面通知必須」のような契約条項を見落とすと、契約違反・信頼喪失に直結する。
Notice→Support→Freeze→Sunsetの段階性
一気に停止せず、通知・移行支援・凍結（読み取り専用）・削除の4段階に分解する。Freezeという中間状態が、いきなり全停止して障害を起こすリスクを下げる安全弁になる。
ROIは放置コストとの比較で語る
維持コスト年12万円は小さく見えるが、Cloud Functions gen1のsunset予告を放置すると90万円の緊急対応コストを負う。この差を示すことが経営層への説得材料になる。
問題
ECサイト MOps チームは3年前に構築した 「バナー画像リサイズAPI（レガシー版）」（アップロードされた元画像をPC/SP/アプリ等5サイズに自動リサイズするCloud Functions gen1製API）を保守し続けている。半年前に新パイプライン「banner-studio」（Cloud Run + Next.js）へ大部分の利用が移行済みだが、レガシーAPIは今も一部チームから呼び出されている。
あなたはMOpsチームのシニアエンジニアとして、後輩PdM見習いが作成した以下の Bad 廃止（デプリケーション）計画ドラフトをレビューし、実際に安全へ実行できるレベルへ再設計することになった。以下のドラフトには 7つの問題点が潜んでいる。問題点を全て洗い出し、Good 廃止計画へ再設計してください。
制約・前提条件
- 利用状況（実測データ）: レガシーAPI呼び出し数は現在 月間240件。ピーク時（3年前）は月間8,000件あったため、現在の利用率はピーク比 3% まで減少している
- 呼び出し元（3者）: 在庫管理チームの季節タグ画像生成バッチ（月80件、内部・移行難易度低）、CRMチームのメルマガ用バナー画像生成（月100件、内部・FE改修を伴う）、外部委託の制作会社の入稿ツール（月60件、月額固定の業務委託契約あり。「API仕様変更は14営業日前までの書面通知が必要」という契約条項が存在）
- 技術的な廃止動機: レガシーAPIが稼働する Cloud Functions gen1 は GCPロードマップ上、2027年Q2（約半年後）にサポート終了（sunset）が予告済み。放置すると強制的に緊急移行を迫られる
- 維持コスト試算: Cloud Functions gen1稼働費・Cloud Loggingコストで月額約2,000円（年間2.4万円）、加えて障害対応・問い合わせ対応で保守エンジニア工数が月0.2人日（年間2.4人日）発生
- エンジニア単価: 80万円/月（160時間）とし、1人日=4万円で計算すること
- 計画的移行 vs 強制的緊急移行の想定工数差: 計画的に段階移行すれば想定5人日（20万円）。放置してgen1が強制終了された場合、3チーム同時対応が必要になり想定15人日（60万円）、加えてバナー生成停止による販促機会損失を1日あたり10万円、最大3日停止と仮定（30万円）
- 現行ドラフトは「来月末で停止」という一方向・一度きりの通知のみで進行し、外部委託先の契約条項の充足確認、依存先ごとの移行支援、段階的な切り戻し余地は一切検討されていない
期待する回答形式: 問題点の列挙（番号付き） + 利用状況分析・依存関係マップ（契約条件含む表） + 段階的廃止ロードマップ（フェーズ図・各フェーズのトリガー条件） + コミュニケーション計画（時間軸付きタイムライン表） + ロールバック・セーフティネット設計 + ROI試算（維持コスト vs 計画的移行コスト vs 放置した場合の緊急移行コスト）
悪い廃止計画ドラフト (Before)
このドラフトには 7つの問題 が隠れています。見つけてみてください。
Bad ドラフト — データなし・契約無視・一気に停止
件名: レガシー画像リサイズAPI 廃止のお知らせ
背景: 新しいbanner-studioに移行が進んでいるため、レガシーAPIは役目を終えました。
← 問題①: 「役目を終えた」は主観。月240件・3者の実利用実績を未確認
進め方:
- 来月末でAPIを停止します
← 問題④⑤⑥: 通知は一度きりでリードタイム不足、段階性なし、
トリガー条件が「来月末」という日付固定
- 停止前に利用チームにSlackで一度アナウンスします
← 問題②: 外部委託先の契約条項(14営業日前書面通知)を未確認
- 移行先はbanner-studioです。詳細は各自ドキュメントを見てください
← 問題③: チーム別の移行難易度を考慮しない一律の丸投げ
- 何か問題があれば都度対応します
← 問題⑦: 維持コスト・移行コスト・放置リスクが未数値化
以上、ご協力よろしくお願いします。問題点サマリー（7点）
1「役目を終えた」は主観のみ — 月240件・3者の実測データから出発する
2契約条件を見落とし — 外部委託先の14営業日前通知義務を依存関係マップに含める
3移行支援が丸投げ — チーム別の移行難易度に応じた相談会・進捗トラッキング
4通知が一度きり — T-60/T-30/T-14/T-7の複数回タイムライン
5段階性がない — Notice→Migration Support→Freeze→Sunsetの4フェーズ
6トリガーが日付固定 — 移行完了率100%＋呼び出し0件の測定可能な条件
7コストが未数値化 — 維持/計画的移行/放置時緊急移行のROI比較
ヒント（段階的開示）
ヒント1 — 方向性
Bad計画の罠は3系統。(1) 利用状況把握の欠如 — 「役目を終えた」は完全に主観的な判断であり、実際には月240件・3者が今も依存しているという実測データを一切確認せずに書かれている。(2) 依存関係の見落とし（契約条件を含む） — 誰が・どんな契約条件で使っているかの洗い出しが不十分で、特に外部委託先には「14営業日前の書面通知」という契約上の義務があるにもかかわらず、それを満たせるかの検討が抜けている。(3) 段階性・ロールバック余地の欠如 — 「来月末で停止」という一気の切り替えで、通知も一度きり。移行が間に合わなかった場合の切り戻し手順や、廃止を安全に実行してよいかを判定するトリガー条件が存在しない。
ヒント2 — アプローチ
- 問題①: 「役目を終えた」という主観のみで廃止を判断 → 呼び出し数推移・利用率（ピーク比3%等）のデータで現状を定量的に把握する
- 問題②: 依存先の洗い出しが呼び出し元列挙止まりで契約条件を未確認 → 依存関係マップに契約上の通知義務（14営業日前）まで含めて記載する
- 問題③: 移行支援が「各自ドキュメントを見てください」のみ → チームごとの移行難易度に応じた支援（相談会・進捗トラッキング）を設計する
- 問題④: 通知が一度きりでリードタイムが実質1ヶ月未満 → T-60/T-30/T-14/T-7の複数回・時間軸付き通知計画にする
- 問題⑤: 一気に停止でロールバックの余地が無い → Notice→Migration Support→Freeze（読み取り専用）→Sunset（削除）の段階的フェーズにする
- 問題⑥: 廃止実行の判定基準が「来月末」という日付固定 → 「移行完了率100%かつ直近7日間の呼び出し0件」という測定可能なトリガー条件にする
- 問題⑦: 維持コスト・廃止コストが数値化されていない → 維持コスト・計画的移行コスト・放置した場合の緊急移行コストをROIとして比較する
ヒント3 — 誘導
【依存関係マップの骨格】
呼び出し元 | 月間件数 | 移行難易度 | 契約条件
在庫管理チーム | 80件 | 低 | なし（内部チーム）
CRMチーム | 100件 | 中（FE改修） | なし（内部チーム）
外部委託 制作会社 | 60件 | 中〜高 | 仕様変更は14営業日前書面通知必須
【段階的廃止ロードマップ（フェーズ）】
Phase 0: 利用状況分析・依存関係マップ作成（前提）
Phase 1: Notice (T-60〜T-30日): 全利用者へ正式通知、移行ガイド配布
Phase 2: Migration Support (T-30〜T-7日): 移行相談会、進捗ダッシュボード
Phase 3: Freeze (T-7〜T-0日): 新規リクエスト遮断、既存呼び出し元のみ読み取り専用許可
Phase 4: Sunset (T-0以降): トリガー条件（移行完了率100%かつ直近7日呼び出し0件）を
満たした場合のみ削除実行。未達なら個別ヒアリングしFreeze延長。
【ROI計算の骨格】
維持コスト(年間) = Cloud Functions稼働費 + 保守工数×人日単価
計画的移行コスト = 5人日 × 4万円 = 20万円
放置時の緊急移行コスト = 15人日×4万円 + 機会損失(10万円×最大3日) = 60万円+30万円 = 90万円
回避効果 = 90万円 - 20万円 = 70万円（投資対効果 3.5倍）問題点分析（7点）
| # | 問題点 | 分類 | 改善方法 |
|---|---|---|---|
| 1 | 「役目を終えた」という主観のみで廃止判断 | データ根拠の欠如 | 呼び出し数推移・利用率で定量把握 |
| 2 | 外部委託先の契約条項(14営業日前通知)を未確認 | 契約リスク | 依存関係マップに契約条件を含める |
| 3 | 移行支援が「各自ドキュメントを見てください」のみ | 移行支援設計 | チーム別難易度に応じた相談会・トラッキング |
| 4 | 通知が一度きりでリードタイム実質1ヶ月未満 | 時間軸の欠如 | T-60/T-30/T-14/T-7の段階的通知 |
| 5 | 一気に停止でロールバック余地なし | 段階性の欠如 | Notice→Support→Freeze→Sunsetの4フェーズ |
| 6 | 廃止トリガーが「来月末」の日付固定 | 判定基準 | 移行完了率+呼び出し実績のトリガー条件 |
| 7 | 維持コスト・廃止コストが未数値化 | ROI不在 | 維持/計画的移行/放置時緊急移行の比較 |
廃止プロセス比較 — Bad vs Good
模範解答
修正①②: 利用状況分析・依存関係マップ
利用状況の推移
| 時期 | 月間呼び出し数 | ピーク比 |
|---|---|---|
| 3年前（ピーク） | 8,000件 | 100% |
| 現在 | 240件 | 3% |
依存関係マップ（契約条件含む）
| 呼び出し元 | 月間件数 | 用途 | 移行難易度 | 契約条件 |
|---|---|---|---|---|
| 在庫管理チーム | 80件 | 季節タグ画像生成バッチ | 低 | なし（内部チーム） |
| CRMチーム | 100件 | メルマガ用バナー画像生成 | 中（FE改修） | なし（内部チーム） |
| 外部委託 制作会社 | 60件 | 入稿ツールからの呼び出し | 中〜高 | 仕様変更は14営業日前書面通知必須 |
Bad版は「利用チーム」という粒度でしか把握しておらず、最もリスクの高い制約（外部委託先への契約上の通知義務）を見落としていた。Good版は依存先ごとに移行難易度と契約条件を並べることで、通知タイムライン設計の根拠にする。
修正⑤⑥: 段階的廃止ロードマップ（フェーズ・トリガー条件）
| フェーズ | 期間目安 | 内容 | 次フェーズへのトリガー条件 |
|---|---|---|---|
| Phase 0: 分析 | 事前 | 利用状況分析・依存関係マップ作成 | 完了済み |
| Phase 1: Notice | T-60〜T-30日 | 全利用者へ正式通知、外部委託先には契約書に基づく書面通知、移行ガイド配布 | 全利用者への通知完了 |
| Phase 2: Migration Support | T-30〜T-7日 | 移行相談会、移行進捗ダッシュボードで3者の完了率を可視化 | 進捗チェックイン2回実施済み |
| Phase 3: Freeze | T-7〜T-0日 | 新規リクエスト遮断、既存呼び出し元のみ読み取り専用で許可、廃止警告ヘッダー付与 | 異常（エラー率悪化・問い合わせ急増）が無い |
| Phase 4: Sunset | T-0以降 | 移行完了率100%かつ直近7日間の呼び出し数0件の場合のみAPI削除を実行 | 未達なら未移行チームへ個別ヒアリングしFreeze延長 |
Bad版の「来月末で一気に停止」を、通知→移行支援→凍結（読み取り専用）→削除という4段階に分解し、各フェーズ間に「戻れる余地」を残す。特にPhase 3のFreezeは、実際に削除する前の安全弁として機能する。
修正④: コミュニケーション計画（時間軸付きタイムライン）
| タイミング | アクション | 対象 |
|---|---|---|
| T-60日 | 正式廃止通知（Slack＋メール）、外部委託先には契約に基づく書面通知を送付 | 在庫管理・CRM・外部委託先 |
| T-45日 | 移行ガイド・FAQ公開、移行相談会の予約受付開始 | 全利用者 |
| T-30日 | 移行進捗チェックイン（1回目）、進捗ダッシュボード公開 | 全利用者 |
| T-14日 | 移行進捗チェックイン（2回目）、未移行チームへのエスカレーション | 未移行チーム |
| T-7日 | Freezeモードへ切替、最終リマインド送付 | 全利用者 |
| T-0 | 移行完了率100%を確認できた場合のみSunset実行。未達なら延期を判断し通知 | 全利用者 |
外部委託先の契約条項「14営業日前までの書面通知」に対し、T-60日通知は約60営業日相当の猶予を確保しており、契約違反リスクを構造的に排除している。
ロールバック・セーフティネット設計
- Freeze期間中の切り戻し: レガシーAPIの新規リクエスト遮断はフィーチャーフラグで制御し、重大な問題が発生した場合は即座にフラグを無効化してFreeze以前の状態に戻す
- モニタリング指標: (1) レガシーAPIのエラー率、(2) 移行チームからの問い合わせ件数、(3) 外部委託先からのSLA違反報告の有無、を日次で監視し、閾値超過時はSunset延期の判断材料とする
- Sunset延期条件: 「移行完了率100%かつ直近7日呼び出し0件」を満たさない場合は自動削除を実行せず、未移行チームへのヒアリングとFreeze延長を先に行う。日付ではなく実績で判断することで、間に合わなかった1社を切り捨てて障害を起こす事態を防ぐ
修正⑦: ROI試算（維持 vs 計画的移行 vs 放置時緊急移行）
| 項目 | 金額 | 内訳 |
|---|---|---|
| 現状の維持コスト（年間） | 約12万円 | Cloud Functions稼働費・Loggingコスト 年2.4万円 ＋ 保守工数 年2.4人日×4万円=9.6万円 |
| 計画的移行コスト（一括） | 20万円 | 5人日 × 4万円/人日 |
| 放置時の緊急移行コスト（gen1 sunset想定） | 90万円 | 緊急対応15人日×4万円=60万円 ＋ 機会損失10万円×最大3日=30万円 |
| 回避効果 | 70万円 | 90万円 − 20万円（投資対効果 3.5倍） |
維持コスト自体は年間12万円と小さく見えるため「急いで廃止する理由が無い」と誤読されやすいが、真の判断材料はCloud Functions gen1のsunset予告という技術的な期限である。計画的に今移行すれば20万円、放置すれば90万円という比較を提示することで「なぜ今やるべきか」を数値で説明できる。
ポイント解説
1「役目を終えた」は主観であり、廃止判断は必ずデータ（呼び出し数推移・依存関係）に基づいて行う — ピーク比3%であっても、月240件・3者が実際に依存している以上、感覚ではなく実測値で現状を語る必要がある。
2依存関係マップは呼び出し元の列挙だけでなく、契約条件まで含めて洗い出す — 外部委託先のような契約関係にある依存先は、通知義務を見落とすと契約違反や信頼喪失に直結する、最もリスクの高いステークホルダーになりうる。
3廃止は一気に行わず、Notice→Migration Support→Freeze→Sunsetという段階的フェーズで進め、各フェーズに「戻れる余地」を残す — 特にFreeze（新規遮断・既存維持）という中間状態を挟むことで、いきなり全停止して障害を起こすリスクを大幅に下げられる。
4廃止実行のトリガー条件は「日付」ではなく「移行完了率＋実際の呼び出し実績」という測定可能な条件にする — 日付固定だと、移行が間に合わなかった1社を切り捨てて障害を起こすか、逆にずるずると先延ばしになるかの二択に陥りやすい。
5ROIは「維持コストの小ささ」だけで語らず、放置した場合の強制対応コスト（技術ロードマップ上の期限）との比較で語る — 小さな維持コストに隠れた「先送りのリスクコスト」を定量化することが、経営層を動かす説得材料になる。
実務への応用
MOpsチームは今後も、旧クーポン発行API・旧レコメンドエンジンなど多くのレガシー機能を廃止していく局面に直面する。本問題の型（利用状況のデータ分析 → 契約条件を含む依存関係マップ → 段階的フェーズ設計 → 測定可能な廃止トリガー → ロールバック・セーフティネット設計 → ROI試算）は、汎用的な「デプリケーションプレイブック」として繰り返し再利用できる。
証券会社経験との接続: 商品終了（償還）プロセスにも「告知→移行案内→凍結→終了」という似た段階性があり、顧客への周知期間や契約上の通知義務を軽視すると苦情や規制対応に発展する事例をよく見た。エンジニアリングにおける機能廃止も、技術的な都合だけでなく「契約・SLA」という業務側の観点を組み込んで設計できるかどうかが、シニアエンジニアからPM/CTOへのキャリアで問われる力になる。
今日のまとめ
レガシー機能の廃止は「役目を終えたので停止する」という主観的な終了宣言では成立しない。データに基づく利用状況分析・契約条件まで含めた依存関係マップ・Notice→Migration Support→Freeze→Sunsetの段階的フェーズ・移行完了率と呼び出し実績という測定可能な廃止トリガー・ロールバック設計・放置した場合の緊急対応コストとの比較によるROI試算という一連の設計が揃って初めて、安全かつ説得力を持って実行できる恒久的な廃止計画になる。
次のステップ
- 発展問題: Freeze期間中に外部委託先から「移行が間に合わないため、Freezeを解除して従来通り使わせてほしい」という交渉が来たとする。このとき、（1）個別に期限延長を認める基準をどう設計するか、（2）延長を認めすぎることで廃止プロジェクト全体が形骸化するリスクをどう防ぐか、の2点を踏まえた運用ルールを設計せよ。
- 参考: デプリケーションプレイブック / フィーチャーフラグによる段階的ロールアウト・ロールバック / Freeze・Sunsetパターン / 契約上の通知義務（SLA）とコミュニケーション設計