プロンプトとコンテキスト
中核となる収益メトリクスの返金処理に関する修正が必要ですが、数百ものダッシュボード、アラート、データプロダクトが依然として古い定義を使用しています。変更内容の説明が可能で、移行可能であり、かつロールバック可能なメトリクスのバージョニングと非推奨化コントラクトを設計してください。
特定のカタログやセマンティックレイヤーベンダーに依存した回答にはしないでください。定義、依存関係、互換性ウィンドウ、リリースゲート、コンシューマーへの通知、および廃止のエビデンスに焦点を当ててください。
面接官が評価するポイント
セマンティック境界
SQLを暗黙的に変更するのではなく、メトリクス名を計算式、フィルター、時間セマンティクス、粒度、単位、タイムゾーン、バージョン、およびオーナーを含むコントラクトに変換できるか。
影響分析
直接的な依存関係と間接的な依存関係を区別しながら、ダッシュボード、アラート、エクスポート、モデル、APIを網羅的に列挙できるか。
移行ガバナンス
予期せぬ一括停止（ビッグバン破壊）を引き起こすことなく、期限、承認者、移行ステータスを設定して新旧バージョンを並行稼働できるか。
検証可能な廃止
利用実績、照合、アラートの再生、古い呼び出しが完全に消滅したことのエビデンスによって、廃止を証明できるか。
尋ねるべき明確化のための質問
- この変更はバグ修正、ビジネス定義の変更、またはソース移行のどれですか？
- 財務、監査、過去データの再計算、または法的なデータ保持において古いメトリクスが必要とされますか？
- コンシューマーは SQL、BI、API、エクスポート、機械学習機能のどれを使用していますか？
- チーム横断、または外部顧客向けの SLA は存在しますか？
- 両バージョンをどれくらいの期間並行稼働させることができ、誰がその期間を延長できますか？
- 数値が乖離した場合、定義、データ、またはプレゼンテーション層のどこをロールバックしますか？
30秒で答えるフレームワーク
「私はメトリクス定義を、計算式、フィルター、粒度、時間セマンティクス、およびオーナーを含むバージョン管理されたコントラクトとして扱います。まず、依存関係グラフと利用状況のスナップショットを作成し、古いバージョンを保持したまま新しいバージョンを公開します。すべてのレスポンスにはバージョンと有効時間が明示されます。移行ではリスクの高いコンシューマーを優先し、固定サンプル、過去データの再生、および照合を使用します。非推奨期間中はオーナーへ通知し、新規利用をブロックします。古い呼び出しがゼロになり、重要なコンシューマーからの承認が得られ、監査記録が完備された後にのみ廃止を実施し、同時に復元可能な定義と結果スナップショットを保持します。」
ステップバイステップの詳細解説
ステップ 1: 現在のコントラクトを凍結する
旧バージョンの名称、計算式、フィルター、粒度、単位、タイムゾーン、ソース、鮮度、オーナー、機密度、および有効時間を記録します。変更ごとに不変（immutable）なバージョンを生成し、決して暗黙的に上書きしません。
ステップ 2: 依存関係とリスクグラフを構築する
セマンティックレイヤー、クエリログ、BIメタデータ、スケジュールされたジョブ、アラート定義、およびAPI呼び出しから依存関係を収集します。財務関連、顧客向け、ニアリアルタイム、機械学習のコンシューマーを特定・マークし、影響度と利用頻度に基づいて移行の優先順位を付けます。
ステップ 3: 互換性を定義する
エイリアスや表示のみの変更には互換性エイリアスを使用できます。計算式、粒度、または時間セマンティクスの変更には新しいバージョンを付与します。レスポンス、エクスポートメタデータ、ドキュメントにバージョン、単位、定義参照を返すことで、コンシューマーに推測させないようにします。
ステップ 4: 新リリースのゲートを設定する
サンドボックス環境および小規模なコンシューマーコホートで新バージョンを実行します。ゲートでは式のパース、サンプル値、過去データの再生、null値、単位、権限、レイテンシ、コストをチェックします。対象を拡大する前に、オーナーおよび影響を受けるコンシューマーが承認します。
ステップ 5: 移行と通知
すべての依存関係にオーナー、期限、ステータスを割り当てます。カタログステータス、CIチェック、クエリヒント、定期レポートを利用して旧バージョンのユーザーに通知します。新しいダッシュボードが旧バージョンを参照することをブロックし、例外には有効期限を設けます。
ステップ 6: 検収、ロールバック、および廃止
固定サンプル、過去期間ウィンドウ、重要なダッシュボード上で新旧バージョンを比較し、返金、遅延データ、またはタイムゾーンによって生じた差異を説明します。旧定義と結果スナップショットを保持し、異常が発生した場合は廃止を一時停止するか元のバージョンに戻します。旧呼び出しがゼロになり、監査、コンシューマーの確認、ロールバック資料がすべて揃った後にのみ廃止します。
優れた回答例
「私は現在の収益定義を v1 として凍結し、認識時点、返金処理、通貨、タイムゾーン、粒度、およびオーナーを明示的に文書化します。クエリログとカタログメタデータから依存関係グラフを生成し、財務レポート、顧客向け請求書、アラートを高リスクとしてマークします。
返金の修正によって計算式が変わる場合は、v1 を上書きするのではなく v2 を公開します。両バージョンを並行稼働させ、出力値にはバージョン、単位、鮮度情報を含めます。CI で新しい v1 参照をブロックし、移行リストでオーナーと期限を管理します。既知の注文や特定の月データで照合を行い、アラート、エクスポート、API を再生します。すべての差異について説明が必要です。
高リスクのコンシューマーが確認を完了し、v1 の利用が継続してゼロになり、ドキュメントと監査記録が完備された後、v1 を読み取り専用として凍結し、最終シャットダウン日を設定します。過去のレポートの追跡性を維持し、異常時に復元できるよう、その定義と結果スナップショットを保持します。」
よくある間違い
- 同名の SQL を直接編集し、過去のレポートの意味が暗黙のうちに変わってしまう。
- カタログの参照のみを確認し、クエリログ、アラート、エクスポート、API を見落とす。
- 新旧バージョンで同一のキャッシュキーや結果テーブルを再利用する。
- 単位、タイムゾーン、粒度、バージョンのフィールドを省略し、コンシューマーに推測を強いる。
- オーナー、期限、強制力のないアナウンスを送信する。
- 平均差異を用いて、重要な月や高リスク顧客における数値の乖離を隠蔽する。
- 過去の説明やロールバックが可能になる前に旧定義を削除する。
- 一時的な利用数の低下を廃止完了の証明と見なし、バッチジョブや頻度の低い監査クエリを見落とす。
フォローアップ質問と回答
フォローアップ 1: 何が破壊的変更（Breaking Change）とみなされますか？
計算式、フィルター、粒度、単位、タイムゾーン、ソースの信頼性、または権限セマンティクスの変更は破壊的変更です。エイリアスや説明文の変更は、結果のコントラクトが変わらない場合に限り互換性があるとみなされます。
フォローアップ 2: 新しいダッシュボードが古いバージョンを採用するのをどう防ぎますか？
旧バージョンを非推奨（deprecated）としてマークし、CI およびセマンティックレイヤーで新しい参照を拒否させます。クエリヒントで代替バージョンを示し、例外にはオーナー、理由、有効期限を必須とします。
フォローアップ 3: 数値の差異がバグではないことをどのように証明しますか？
固定サンプル、過去期間ウィンドウ、境界値の注文、および照合合計を再生します。返金、遅延、通貨、タイムゾーンごとに差異を分解し、ビジネスオーナーからの正式な承認を取得します。
フォローアップ 4: 低頻度のコンシューマーが移行しない場合はどうしますか？
リスクに応じた厳格な期限を設定し、移行レポートと代替クエリを提供します。コンプライアンスや請求関連のコンシューマーに対しては、理由、承認者、新しい期日を記録した上で、管理された期間延長を許可します。
フォローアップ 5: 廃止後に過去のデータに関する質問へ回答できますか？
不変の定義、バージョン、入力スナップショット、または再生可能な資料を保持し、各過去レポートで使用されたバージョンを記録します。アクティブなエンドポイントを削除しても、監査エビデンスは削除しません。