プロンプト
初めて本番環境への変更を行うチームメイトを指導した経験について教えてください。学習目標の特定、リスクの分解、レビューの段取り、段階的な権限移譲、そしてデリバリーと能力向上の両方をどのように測定したかを説明してください。
シナリオと境界条件
実際のサービス、変更のスコープ、不足していた経験、リリース期間を用いてください。正式なメンター、レビュアー、あるいは一時的なパートナーであった場合もありますが、その人の代わりに作業を終わらせることはメンターとしての成果ではありません。
この質問で見られるポイント
この質問では、単に答えを与える支援から、相手の能力を構築する支援へと転換できているかが試されます。Google のコードレビューガイドラインでは教えることを重要なレビュー機能として位置づけており、GitLab のメンターシップではペアワーク、目標設定、継続的なフィードバックを重視しています。優れた回答は、本番環境を保護しつつ、学習者の意思決定スペースを確保します。
模範回答の構成
STAR-L を使用します。Situation（状況）では変更と学習の背景を説明し、Task（課題）ではサービス面での成果とメンターとしての境界を定め、Action（行動）では共同でのリスク分解、ロールバック準備、小さな単位でのレビュー、観察、段階的なオーナーシップの移譲を扱い、Result（結果）ではリリース、インシデント、デリバリー期間、能力向上に関する根拠を示し、Learning（学び）では自身のコーチングがどのように変化したかを説明します。
重要な詳細情報
事前環境でのチェック、2 人による承認、カナリアリリースの規模、モニタリング、ロールバックのリハーサルなどのガードレールを挙げてください。チームメイト自身がどの決定を下したかを明確に述べてください。単に関係性が良くなったと述べるだけでなく、自立して行った変更、レビューの往復回数の減少、オンコールへの自信、その後のメンター業務などを指標として測定してください。
よくある落とし穴
チームメイトの代わりにコードを書いてしまうこと、相手の弱点にのみ焦点を当てること、プレッシャーに押されてガードレールを省略すること、成功を自分の手柄にすること、フィードバックによって行動がどう変わったかを省くこと、メンターシップを一方的な指示として描くことなどがあります。
評価基準
優れた回答には、学習目標、段階的な権限移譲、安全のためのガードレール、検証可能な成果が含まれます。また、いつ介入し、いつ一歩引いたのか、そして知識がどのようにドキュメントやチームのプラクティスに組み込まれたかが説明されます。不十分な回答は、能力の向上が見られない単発のペアプログラミングセッションの説明にとどまります。
追加の質問
チームメイトがリスクが高いと思われる設計にこだわった場合はどうしますか？
前提条件、リスク、検証方法を一緒に書き出し、元に戻すことが可能な最小限の実験を実施します。権限やリスクバジェットを超える場合は、独断で設計を差し替えるのではなく、チームのレビュープロセスを活用します。
一歩引くべきタイミングはどのように判断しますか？
チームメイトが設計を説明し、メトリクスを選択し、ロールバックを実行し、異常に対応できるかどうかを観察します。リスクの低いステップをいくつか主導させ、その上で承認や指示の頻度を減らしていきます。
そのメンターシップはチームにどのような影響を与えましたか？
繰り返された質問をランブック、チェックリスト、またはレビューテンプレートに落とし込み、チームメイトにもその改善に参加してもらい、その後の変更がより迅速かつ安全になり、同じ質問への対応が減ったかどうかを追跡します。