プロンプトとコンテキスト
依存関係にあるチームとAPIコントラクトについて意見が対立したときのことを教えてください。相手チームはあなたの提案がメンテナンスコストを増加させると考え、あなたはコントラクトを現状維持すれば信頼性が損なわれると懸念していました。どのように事実を明確にし、決定を下し、デリバリーしましたか？
この質問は、チーム間のコラボレーション、技術的なトレードオフ、および影響力をテストするものです。Atlassianのエンジニアリング面接ガイドでは、問題解決力、学習の俊敏性、コラボレーション、コミュニケーションが明確に求められます。優れた回答では、相手チームを障害として描写するのではなく、実際の制約、検証可能な証拠、合意に基づく決定、そして成果を示します。
面接官が見ているポイント
面接官は、意見の不一致を共通の目標へと転換できるか、事実と好みを切り離せるか、互換性・信頼性・コスト・スケジュールのトレードオフを説明できるか、決定とオーナーシップを記録できるか、そして証拠の変化に応じて方針を変更できるかを知りたがっています。また、依存チームのデリバリーペースを保護しているかどうかも見ています。
状況を明確にするための質問
APIのコンシューマー、バージョン、SLO、データの機密性、リリース期間、および許容できない障害を確認します。対立がフィールドのセマンティクス、エラーコントラクト、互換性維持期間、運用のオーナーシップのどれに関するものかを特定します。両チームが検証できるログ、トラフィック、障害サンプル、移行工数、ロールバック条件を準備します。
30秒での回答
「私はまず、この対立を『リリース期間内で信頼性とメンテナンスの制約を満たす』という共通の目標として再構成しました。既知の事実、仮説、未知の事項を切り分け、依存チームにそれらの検証を依頼しました。互換性、オブザーバビリティ、移行、ロールバックの各コストを比較し、不確実性を減らすために小さなリバーシブル（可逆的）なテストを実施しました。最終的に決定事項、オーナー、期限、ロールバックのシグナルを記録しました。デリバリー後には結果を確認し、その教訓を再利用可能なテンプレートに落とし込みました」
詳細な回答
ステップ1：ユーザーとサービスの目標を一致させる
どのフィールド設計が正しいかという議論から始めてはなりません。ユーザーへの影響、信頼性の目標、リリースタイミング、メンテナンスの境界を文書化し、両チームが同じ成果に向けて最適化できるようにします。目標が衝突する場合は、プロダクトまたはアーキテクチャのトレードオフを誰が担当するかを特定します。
ステップ2：事実、仮説、好みを切り分ける
実際の呼び出し量、障害発生率、互換性のあるクライアント、移行工数、サポート期間をリストアップします。データのない主張は仮説としてラベル付けし、検証可能なチェックをスケジュールします。勤続年数、チームの規模、声の大きさを証拠として使ってはなりません。
ステップ3：コントラクトの選択肢を比較する
現在のコントラクト、最小限の後方互換性変更、長期的な設計を比較します。それぞれについて、フィールドのセマンティクス、エラーコード、バージョニング、オブザーバビリティ、パフォーマンス、メンテナンス、ロールバックを記録します。議論が『変更を押し付けられている』とならないよう、依存チームに自チーム側のコストを記入してもらいます。
ステップ4：リバーシブルな実験を設計する
オプショナルフィールド、デュアルライト、シャドウトラフィック、またはコンシューマーコントラクトテストから開始し、実際の結果を観察します。実験にはタイムボックス、成功基準、停止条件を設定します。互換性レイヤーを永久に残してはなりません。
ステップ5：決定と記録
背景、選択肢、根拠、リスク、オーナー、期限、ロールバックのトリガーをADRまたはプロジェクト記録に記述します。反対意見が残る場合もありますが、その決定がいつ再評価されるかを全員が把握しておく必要があります。
ステップ6：依存チームのデリバリーを保護する
移行例、テストフィクスチャ、互換性期間、共同インテグレーションの時間を提供します。自分の変更によって相手の作業が増える場合は、自分が担当するサポート範囲を明示します。未完了の移行責任をコンシューマーに黙って押し付けてはなりません。
ステップ7：メトリクスを用いてロールアウトのリスクを管理する
リリース前に、エラー率、レイテンシ、未知フィールドの割合、ロールバック時間、コンシューマーの成功率を定義します。段階的にトラフィックを拡大し、責任を押し付け合うのではなく、しきい値を超えたら一時停止またはロールバックします。
ステップ8：学びを得てシステムを変更する
結果が仮説と一致したか確認し、どの証拠によって決定が変化したかを記録します。コントラクトテンプレート、レビューチェックリスト、互換性テスト、または責任分担マトリクスをプロセスに追加し、次回の意見の不一致がより早い段階で表面化するようにします。
モデル回答
注文ステータスAPIの移行時、コンシューマーチームは新しいエラー階層によってクライアント側のメンテナンスが増加することを懸念し、私は曖昧なエラーによって障害発生時にリトライが増幅することを懸念していました。私たちはリリース期間を守りつつ、リトライ可能な状態と不可能な状態を明確に区別することで合意しました。30日分のエラーサンプル、クライアントのバージョン、リトライ量をレビューした結果、2つの状態がリスクの大部分を引き起こしていることがわかりました。まず後方互換性のあるフィールドを追加し、コントラクトテストとシャドウトラフィックを使用しました。私はサンプルのSDK、移行ガイド、ダッシュボードを担当し、相手チームはトラフィック量の多い2つのクライアントを担当しました。ADRにはオーナー、2つの一時停止シグナル、ロールバックを記録しました。段階的にトラフィックを増やし、重複リクエストが減少し、古いクライアントでのパース障害も発生しませんでした。レトロスペクティブで、エラーコントラクトのテンプレートをレビュープロセスに追加しました。この決定は自分の好みを強制したのではなく、共通のメトリクスと可逆的なステップから生まれたものです。
よくある間違い
相手チームの技術力が低いと決めつける
依存チームは通常、コンシューマー側の制約をよく把握しています。それを退けることは移行コストを覆い隠し、信頼関係の構築を示せません。
最終的な設計だけを説明する
面接官は、トレードオフをどのように比較したかを見る必要があります。少なくとも2つの選択肢、その証拠、そして一方が却下された理由を説明してください。
測定可能な結果やオーナーシップを示さない
「全員が合意した」は成果ではありません。メトリクス、期間、自分が行った作業、残存リスクを述べてください。
追加の質問と回答
相手チームがまだ合意しない場合はどうしますか？
新たな事実によって議論が変わったかを確認し、決定プロセスで指名されているアーキテクチャまたはプロダクトのオーナーに判断を仰ぎます。最小限のリバーシブルなステップをデリバリーしつつ、反対意見、リスク、再検討日を記録します。
リリースまであと2日しかない場合はどうしますか？
スコープを縮小し、不可逆的なリスクとクリティカルなコンシューマーを保護し、互換フィールド、機能フラグ、またはシャドウ検証を使用します。何を延期したかを明確にし、ロールバックの代わりに口約束で済ませてはなりません。
設計が過剰エンジニアリング（over-engineered）でないことをどう示しますか？
削ぎ落とした機能を挙げ、実際のトラフィックと障害コストを比較し、互換性レイヤーに期限を設けてその削除計画を立てます。証拠に基づいて複雑さを決定します。
データによって自分の判断が誤りだと証明された場合はどうしますか？
仮説が間違っていたことを認め、ADRとしきい値を更新し、より安全な道を選択して、影響を受けるチームに新たな証拠をどのように共有したかを示します。
同じ対立が再発するのをどう防ぎますか？
コントラクト、バージョン、エラー、互換性期間、オーナーシップの決定をテンプレート化します。コンシューマーコントラクトテストと、短い事前コードレビューを含むリリースチェックリストを追加します。
これはコントロールではなく影響力を発揮したとどう示せますか？
支援作業のオーナーシップを持ちながら、共通の目標、証拠、可逆的な決定を作り出した点を強調します。結果を選択したのはチーム全体であり、相手チームを力でねじ伏せたわけではありません。