プロンプトとスコープ
ある企業が12か月後にv1 APIを廃止し、v2をローンチする予定です。v1には3,000社の顧客がおり、リクエストの約40%が依然としてレガシーフィールドを使用しており、200社は高収益なエンタープライズ顧客です。新機能、互換性、開発者体験、収益リスク、廃止のバランスを取りながら移行を計画してください。
これは、プロダクトマネージャーが技術的な移行を顧客向けの境界付けられたプロダクトへ転換できるかをテストするものです。影響を受ける対象、移行が重要な理由、壊してはならない動作を特定し、その上で互換性、ツール、コミュニケーション、段階的ロールアウト、終了基準を設計します。GitHubのAPIバージョンガイダンスでは、破壊的変更、Deprecation/Sunsetヘッダー、サポート期間、移行テストをバージョンガバナンスの制約として扱っています。
面接官がテストしているポイント
第一に、単一の期日を発表するだけでなく、顧客をセグメント化してリスクを順位付けできるかです。高収益、規制対象、低アクティビティ、セルフサービスの顧客では、移行に対する抵抗が異なります。
第二に、互換性、移行、廃止を区別できるかです。旧バージョンの維持、アダプターの追加、バッチ変換の提供はリスクを軽減しますが、顧客の確認や終了基準の代わりにはなりません。
第三に、観測可能なシグナルに基づいて意思決定を進められるかです。リクエスト数の減少だけでは移行の証明にはなりません。アクティブなアプリケーション、エラー、フィールドの使用状況、完了した移行、サポート負荷も追跡する必要があります。
回答前に明確にすべき質問
- v2のコアバリューは何か？ セキュリティ、パフォーマンス、コンプライアンス、コスト、あるいは新しいリソースモデルか？
- どのv1の動作が壊れるか？ 削除されたフィールド、型の変更、認証の変更、エラーセマンティクスをリストアップします。
- 顧客は自分たちが何を使用しているか確認できるか？ トークン、アプリケーション、組織単位で使用状況を確認できるか？
- 12か月は厳格な期限か、それとも目標か？ どのような証拠があれば延長や段階的な閉鎖がトリガーされるか？
- 両方のバージョンまたはアダプターを並行稼働できるか？ コスト、レイテンシ、一貫性の制限はどのようになっているか？
- 廃止後のサポートの約束はどうなっているか？ 410レスポンス、ドキュメント、異議申し立て、セキュリティ例外はどのように機能するか？
30秒の回答フレームワーク
「v1の使用基準値と顧客セグメントを確立し、すべての破壊的変更とv2のメリットをリストアップします。高価値の顧客や社内統合から始めて、互換性ガイダンス、差分一覧、検証ツール、アプリケーションレベルの使用状況ダッシュボードを公開します。移行期間中は、ドキュメント、コンソール通知、メール、直接のアウトリーチに加え、Deprecation/Sunsetヘッダーと段階的なエラードリルを活用します。各ステージには導入率、エラー、アクティブアプリケーションの移行、サポートチケットのしきい値を設定し、終了基準が満たされた後にのみ、セキュリティ例外と短いロールバックウィンドウを設けてv1を廃止します。」
ステップごとの詳細解説
ステップ 1: ゴールと壊してはならない動作を定義する
ゴールを顧客価値とプラットフォームの制約に分割します。たとえば、移行期間中v1の主要な読み取りおよび書き込みセマンティクスを安定させつつ、v2でより詳細な権限を提供します。削除または名前変更されたフィールド、新しい必須パラメータ、型やenumの変更、認証要件をリストアップします。200レスポンスが返るだけでは互換性の証明にはなりません。
ステップ 2: 使用基準値とリスク階層を確立する
組織、アプリケーション、トークン、バージョン、エンドポイント、フィールド、リクエスト数、収益、コンプライアンス、技術担当者ごとにセグメント化します。各アプリケーションの90日間のアクティビティ、影響を受けるフィールドの割合、移行の複雑さ、顧客価値を算出します。高収益で低ボリュームの顧客であっても明示的な確認が必要です。所有者のいないアプリケーションは早期にリスクキューに入れます。
ステップ 3: 移行パスと互換性の境界を設計する
追加的な移行を優先します（オプショナルフィールド、並行レスポンス、またはv1からv2へのアダプターなど）。互換性のないフィールドについては、同等のマッピング、リクエスト例、セマンティクスの違いを提供します。アダプターには期限、コスト、観測可能性を設定し、顧客側の不完全な移行を恒久的に隠蔽してはなりません。
ステップ 4: ツールとドキュメントをプロダクト化する
差分リスト、アプリケーション使用状況レポート、静的チェックまたはSDK移行ヒント、サンドボックス検証、サンプルコード、ロールバック手順を提供します。すべての破壊的変更を代替構文とテスト手順にリンクさせます。長いアナウンスから顧客が推測する必要がないよう、ツールの出力は再現可能であるべきです。
inventory -> classify risk -> test v2 -> dual-run -> migrate -> verify -> retire v1ステップ 5: ロールアウトとコミュニケーションを段階化する
社内およびデザインパートナーから開始し、次にセルフサービス移行、続いて高価値または複雑な顧客へと進めます。各ステージで変更履歴、開発者ドキュメント、コンソールバナー、メール、アカウントマネージャーのアウトリーチを活用します。チャネル間で矛盾した約束がなされないよう、日付、影響、アクション、サポート窓口、例外条件を単一の移行契約にまとめます。
ステップ 6: 単一の導入率ではなくシグナルでゲートを設ける
v1リクエスト数、アクティブなv1アプリケーション、影響を受けるフィールドの呼び出し、v2の成功率、移行後のロールバック率、非推奨ヘッダーのカバレッジ、サポートチケット、高価値顧客の確認状況を毎週レビューします。アプリケーションが切り替わり、クリティカルなシナリオに合格し、エラーが正常範囲に収まり、所有者が確認した場合にのみ移行完了とみなします。
ステップ 7: 廃止、延長、例外ルールを定義する
廃止前に、テスト環境で410または同等のエラーをシミュレートし、顧客がアクション可能なガイドを確認できるかを検証します。延長には、未完了のセキュリティ修正、移行中の重要な規制対象顧客、確認されたv2のリグレッションなどの証拠が必要です。セキュリティリスクによって早期閉鎖が正当化される場合もありますが、影響、代替案、サポートを文書化します。すべての例外には有効期限を設けます。
ステップ 8: 移行を振り返り、バージョンガバナンスを制度化する
廃止後、エラーのピーク、リテンション、サポートコスト、インフラのコスト削減、予期せぬ使用状況を調査します。v1/v2の差分、コミュニケーション、決定ログ、インシデントのタイムラインを保存します。サポート期間、破壊的変更のレビュー、非推奨ヘッダー、移行テスト、顧客通知を次期リリーステンプレートに追加します。
トレードオフと境界
トレードオフ 1: アダプターか高速な切り替えか
アダプターは短期的なリスクを低減しますが、メンテナンス、レイテンシ、セマンティクスの曖昧さを増大させます。移行価値が明確で、境界が観測可能であり、終了日が決まっている場合にのみ維持します。それ以外の場合は、v1を無期限に延長するのではなく、明確なv2の移行期間を提供します。
トレードオフ 2: 単一の期日か顧客ウェーブか
単一の期日は運用が容易です。ウェーブはリスクを制御し、複雑な顧客に時間を与えます。高収益の顧客が最終週に問題を顕在化させないよう、リスクに基づいたマイルストーンとチェックポイントを設定しつつ、公開用の最終期日を維持します。
トレードオフ 3: リクエストの減少か実際のアプリケーション移行か
リクエストは、ビジネスの衰退、キャッシング、または無効化によって減少する可能性があります。総トラフィックだけでなく、アクティブなアプリケーション、成功した重要エンドポイント、完了したフィールドの置き換え、所有者の確認をもって移行を判断します。
障害訓練と進化計画
訓練 1: 破壊的フィールドの漏れ
サンプリングした実際のリクエストをv2に対してリプレイし、ステータスコード、エラーオブジェクト、ページネーション、タイムゾーン、金額のセマンティクスを比較します。差異を深刻度ごとに分類し、説明のつかない重要なフィールドについてはトラフィックの拡大をブロックします。
訓練 2: 高価値顧客が依然としてv1を利用している
90日前に顧客リストを生成し、アカウントマネジメント、サポート、プロダクトに担当者がいることを確認します。最終日に閉鎖するのではなく、技術的診断と期限付きの例外を1回提供します。
訓練 3: 廃止後のエラースパイク
少人数のコホートまたはサンドボックスで移行リンク付きの410を返します。SDK、モニタリング、ドキュメントが修復をガイドしていることを確認します。明確なトリガーを持つ短い復旧ウィンドウを設定し、すべての有効化を記録します。
よくある間違いとフォローアップ
間違い 1: 非推奨メールを1通送信するだけ
通知は、使用状況インベントリ、コード例、テスト環境、サポート窓口の代わりにはなりません。移行は顧客のワークフロー内で実行可能でなければなりません。
間違い 2: バージョン番号がすべての互換性を表すと扱う
フィールド、エラー、認証はバージョン内でも変化する可能性があります。項目別の差分とコントラクトテストを維持してください。
間違い 3: 旧バージョンを永久に維持する
終了日のないアダプターはドキュメントを分裂させ、インフラに負担をかけ、セキュリティ攻撃面を拡大させます。すべての例外に担当者と期限を設けてください。
間違い 4: 総リクエスト数だけで顧客を順位付けする
低ボリュームのアプリケーションでも、重要な会計やコンプライアンスのフローを実行している場合があります。価値、影響、技術的複雑さによってセグメント化してください。
間違い 5: バージョン指定のない呼び出しを無視する
デフォルトバージョンに依存している顧客は、廃止後に動作の変更に直面する可能性があります。バージョンヘッダーのないリクエストを特定し、移行期間中に警告を発してください。
間違い 6: ロールバックや延長をテストしない
成功のみを想定したリハーサルでは、リスクが制御されていることは証明できません。エラーガイダンス、例外承認、復旧ウィンドウ、延長基準を事前にテストしてください。