プロンプトとコンテキスト
あなたのB2B SaaSでは、現在も3つのAPIバージョンが使用されています。エンジニアリング部門は最新バージョンのみを無料で保守することを望んでいますが、営業部門は大口顧客に対して長期的な互換性を約束してしまいました。どのバージョンを利用可能のまま維持するか、非推奨をどのように周知するか、誰が移行ツールの開発費用を負担するか、そして長期サポートを有料機能とすべきかを決定する必要があります。
RFC 8594は、将来的にリソースが応答しなくなる可能性があることを示すSunsetレスポンスヘッダーを定義しています。RFC 9745は、リソースが非推奨であることを示すDeprecationレスポンスヘッダーを定義しています。これらは機械可読なシグナルを提供しますが、サポート期間、顧客ティア、または移行責任を決定するものではありません。
このケースは、APIライフサイクルのプロダクトガバナンスと商業的な境界線に関するものです。APIのシャットダウンの実装や、一般的なAPI導入戦略の作成とは異なります。
面接官が評価するポイント
- 互換性の約束を顧客価値、契約更新、エンジニアリングコストと結びつけているか。
- バージョン、サポートレベル、非推奨通知、測定可能な移行成功基準を定義しているか。
- 基本的なセキュリティ義務と、有償の長期保守を明確に分離しているか。
- 営業による個別例外、契約上の約束、エコシステムの公平性、セルフサービスでの移行を適切に処理しているか。
- 無制限の約束をするのではなく、メトリクス、パイロット運用、提供終了基準を活用しているか。
質問すべき確認事項
- 各旧バージョンのリクエスト数、アクティブ顧客数、売上高、顧客の集中度、および障害モードはどのようなものか？
- セキュリティ修正、バグ修正、機能強化、破壊的変更（breaking changes）のそれぞれの内訳はどうなっているか？
- 既存の契約でサポート期間、通知期間、サービスレベル、または救済措置がすでに規定されているか？
- 顧客はビジネスロジックを変更することなく切り替えが可能か。また、SDK、移行レポート、テスト環境は存在するか？
- 営業の約束は単なる例外なのか、それともエンタープライズ顧客全体に共通する市場の期待値なのか？
30秒の回答フレームワーク
利用状況、売上高、リスク、移行の難易度ごとにバージョンをセグメント化し、セキュリティ修正と非推奨通知をベースラインのコミットメントとします。最新バージョンおよび旧バージョンの限定的な期間は無料で保守します。その期間を超えたサポートについては、対象バージョン、対応レベル、移行ツール、終了期日を明示した上でのみ有料で提供します。本格展開の前に、互換性メトリクス、移行完了率、サポートコストを用いてパイロット運用を行います。
ステップごとの詳細解説
1. この問題が収益化に値するかどうかを検証する
リクエスト数、アクティブ顧客数、売上高、エラー率、機密データリスク、SDKのカバー率、推定移行工数を記載したバージョンマップを作成します。顧客をセルフサービス、移行支援対象、および契約上の長期互換性対象グループにセグメント化します。
開発者、調達部門、セキュリティ部門、カスタマーサクセスにヒアリングを行い、顧客が旧バージョンそのものに価値を見出しているのか、それとも移行リスク、ダウンタイムリスク、社内承認コストを低減しようとしているのかを把握します。もし大半の顧客が単に移行ドキュメントの不足に困っているだけなら、長期サポートの有料化は、プロダクトの改善で解決できる問題に対してペナルティを課すことになってしまいます。
2. 段階的なライフサイクルステータスを定義する
現行（Current）、保守（Maintenance）、非推奨（Deprecated）の3つのステータスを使用します。現行バージョンは新機能と通常の修正を受け取ります。保守バージョンはセキュリティおよび影響度の高いバグ修正のみを受け取ります。非推奨バージョンは、予告された終了期日まで、明確な移行ガイダンスと機械可読な通知を返し続けます。
各バージョンについて、リリース日、非推奨日、シャットダウン日、サポート範囲、代替手段の期日を公開します。非推奨ステータスを表すにはDeprecationを使用し、応答しなくなる予定日時を表すにはSunsetを使用します。ドキュメント、管理コンソール、SDKの警告、顧客対応窓口で共通のタイムラインを共有する必要があります。
3. 無料と有料の境界線を設定する
無料ティアには、セキュリティ修正、公開移行ドキュメント、変更履歴（チェンジログ）、安定した非推奨通知、および合理的な移行期間を含める必要があります。有料の長期サポートには、延長された保守期間、専用のレスポンス対応、移行アセスメント、一括互換性テスト、カスタムコネクタなどが含まれます。製品自体のセキュリティ欠陥の修正を有料化してはなりません。
バージョン数、サポート期間、リクエスト数、またはサービスレベルに基づいて価格を設定します。口頭での営業上の約束が無制限の法的責任とならないよう、契約書にはエンドポイント、修正カテゴリ、対応時間、顧客側の義務、例外承認、最終シャットダウン日を明記しなければなりません。
4. 移行ツールとエビデンスを構築する
差分（diff）レポート、非推奨エンドポイント一覧、リクエスト例、推奨SDK、サンドボックス、リプレイテストから着手します。静的に検出可能なパラメータ変更にはコードモッド（codemods）やリントルールを提供し、セマンティックな変更にはレビューチェックリストやシャドウトラフィックを使用します。
移行完了率、失敗理由、ロールバック回数、テストカバレッジ、通知から本番切り替えまでの日数を測定します。移行ガイドを閲覧しただけの顧客は、移行完了とはみなされません。完了には、新バージョンでの実際のリクエストと、重要なビジネス成果の達成が必要です。
5. 営業の例外を公平にガバナンスする
顧客名、約束の責任者、契約条項、対象バージョン、有効期限、コスト、代替案を含む例外登録台帳を作成します。短期的な例外であっても価格と終了期日が必要であり、エンジニアリング部門が見えないプライベートブランチを保守するような事態は避けるべきです。
すべての顧客に同じベースラインのタイムラインを公開します。有料顧客には追加のサービスキャパシティと長期の猶予期間が提供される場合がありますが、非推奨通知の隠蔽やセキュリティ修正のバイパスといった特権は与えられません。過去の契約と矛盾がある場合、プロダクト部門が一貫した公式通知を公開する前に、法務部門と営業部門が義務内容を確認する必要があります。
6. コスト、リスク、成果を測定する
コストには、互換性マトリクス、テスト環境、オンコール対応、ドキュメント、SDK、古い依存関係に対するセキュリティ修正が含まれます。リスクには、脆弱性、移行に伴うダウンタイム、ベンダーロックインの認識、エコシステムの断片化などがあります。
旧バージョンのリクエストシェア、通知の到達率、移行の完了および失敗、サポート工数、長期サポートの売上総利益率、重大な修正の対応レイテンシ、契約更新への影響を追跡します。トラフィックの少ない少数の大口顧客によって、多数の中小顧客が負っている負担が見えなくならないよう、顧客ごとにセグメント化します。
7. ロードマップと提供終了基準
フェーズ1では、バージョンマップ、契約上の約束、通知メカニズムを整理し、2社の顧客と移行ツールのパイロット運用を実施します。フェーズ2では、コンソールでのリマインダー、差分レポート、サンドボックス、有料長期サポート契約を追加します。フェーズ3では、トラフィックの減少、移行の成功状況、利益率を評価し、旧バージョンのシャットダウンを行うか、さらなる自動化を進めるかを決定します。
セキュリティ修正が約束を果たせなくなった場合、例外が増え続ける場合、移行の失敗が重大なリスクを生む場合、価値の低下に伴い顧客が支払いを拒否した場合、または保守コストが維持収益を上回った場合に提供を終了します。旧バージョンへの新規顧客の受け入れを凍結し、早期に告知した上で、最終シャットダウン計画を実行します。
優れた回答例
私ならまず、バージョンの使用状況、売上高、契約内容、移行の難易度をマッピングし、その上でセキュリティ修正と非推奨通知を全顧客に対するベースラインの義務とします。現行バージョンには新機能を提供し、保守バージョンにはセキュリティおよび影響度の高い修正を提供します。非推奨バージョンは公開された期間内に限り利用可能とし、Deprecation、Sunset、コンソール、ドキュメント通知を通じて一貫した案内を行います。
長期サポートは有料化できますが、その有料の価値は期間の延長、専用の対応、移行アセスメント、互換性テストであるべきであり、製品のセキュリティ欠陥の修正であってはなりません。差分レポート、サンドボックス、リプレイテストを2社の顧客とパイロット運用し、トラフィックの減少、完了率、失敗、サポート時間、契約更新への影響を測定した上で、終了基準が満たされた段階で有料サポートを拡大するか旧バージョンをシャットダウンします。
よくある間違い
- 売上、契約、移行リスクを確認せずに、エンジニアリングの都合だけで旧バージョンをシャットダウンする。
- セキュリティ修正を有料ティアに限定し、ベースラインの信頼関係を損なう。
- 機械可読な日付、コンソールリマインダー、到達率追跡を伴わずに、ブログ記事だけで告知を済ませる。
- 対象エンドポイント、対応レベル、終了期日を決めずに長期的な互換性を約束する。
- 新バージョンでの実際のリクエストを検証せず、移行ガイドの閲覧をもって移行成功と見なす。
- 1社の大口顧客のためにプライベートブランチを保守し、監査可能なバージョンマトリクスを失う。
- 旧バージョンへの新規顧客の受け入れ凍結や、最終シャットダウンの終了条件を設定し忘れる。
追加の質問と回答
なぜ全バージョンを無料で保守し続けないのですか？
有限のベースライン期間を設定することでエコシステムのリスクを制限できます。無制限の期間はテストやセキュリティのコストを際限なく増加させます。有料の長期サポートは、公平なベースラインのセキュリティ約束を維持しつつ、追加の時間と責任を明確化します。
顧客が「契約で永続的な互換性が約束されている」と主張した場合はどうしますか？
契約上の証拠を保全し、法務および営業部門に義務内容を確認させます。例外の範囲と有効期限を登録し、移行計画を提供した上で、義務が解決されるまでは一方的なサービス停止を行いません。
RFCヘッダーだけで非推奨の周知は解決できますか？
いいえ。DeprecationおよびSunsetは機械可読なシグナルを提供しますが、ドキュメント、コンソール、SDK、顧客連絡窓口、サポートワークフロー全体で同じタイムラインを実行する必要があります。
有料サポートによるロックインの発生をどのように防ぎますか？
バージョニングのルール、エクスポート可能な移行ツール、終了期日を公開します。顧客がベンダーの支援なしで基本的な移行を完了できるよう、対応、アセスメント、テストサービスに対して課金します。
コードモッドを構築する価値があるのはどのような場合ですか？
パラメータ変更が静的に検出可能で、顧客ベースが大きく、障害モードが安定している場合です。セマンティックやデータの変更には依然としてサンドボックス、リプレイ、人的レビューが必要です。完全自動で安全な変換を安易に約束してはなりません。
旧バージョンをシャットダウンするかどうかはどのメトリクスで判断しますか？
リクエストシェア、重要顧客のカバー率、移行完了率、障害リスク、サポートコスト、契約上の義務を総合して判断します。単一のトラフィックの閾値だけでは、リスクの高い少数の顧客への影響を見落とすことになります。