面接の全体像と答え方

例えば、次のように答えます。前のチームで、古い決済の仕組みを新しい基盤に移すか、当面は今のまま機能を足し続けるかを判断したことがあります。状況は、事業側から新しい決済方法を3か月で出したいと言われていた一方、古い仕組みは変更のたびに障害が起き、担当できる人も1人だけでした。

選択肢は、全部を作り直す、今のまま足す、新しい決済方法だけを新しい基盤に作り段階的に移す、の3つでした。判断基準は、事業の期限に間に合うか、障害のリスク、特定の人への依存を減らせるか、の3つに置き、PdM・テックリードと ADR にまとめて比べました。結果、3つ目を選びました。

結果として、新しい決済方法は予定より2週間遅れましたが、障害なく出せ、担当できる人も3人に増えました。学びは、遅れの見込みを早めに事業側に伝えたことで信頼を保てたことと、判断の基準を最初に関係者とそろえておくと、途中で迷ったときに立ち返れることです。

まず、同じ目標を見ているかを確かめます。多くの場合、意見の違いは目標ではなく、何を重く見るか（売上、信頼性、開発の速さ）の違いです。そのうえで、お互いの案について、事業への効果とコスト、やらない場合のリスクを数字でそろえます。

例えば、PdM は新機能を先に出したい、私は障害の多い部分の改善を先にしたい、という場合なら、「この部分の障害が月に何回起き、1回でどれだけ売上や問い合わせに響いているか」「改善しないと新機能の開発もどれだけ遅くなるか」を示します。全部か無しかではなく、新機能を出しつつスプリントの一部を改善に充てる、といった間の案も出します。

何を作るかの最終判断は PdM が持つことが多いので、決まったら全力で支えます。ただ、信頼性のように事前に合意したルール（エラーバジェットポリシーなど）があれば、それに沿って判断します。

例えば、次のように答えます。私のチームが新機能のために基盤チームの API の変更を必要としていましたが、基盤チームは他のチームの依頼も抱えていて、2か月たっても着手されませんでした。お互いに「相手が協力的でない」と感じ始めていました。

私は基盤チームの EM と話し、まず相手の優先順位と事情を聞きました。そのうえで、依頼をチケットにして事業への影響を書き、両チームの四半期の計画を一緒に見て、上位の責任者を交えて優先順位を決め直しました。さらに、基盤チームの負担を減らすため、私のチームのメンバーが期間を決めて一緒に実装する形にしました。

結果、1か月で変更を出せました。学びは、依頼を口頭やチャットで済ませず影響と一緒に見える形にすること、そして依存が分かった時点で早く計画をすり合わせることです。今は、依存するチームとは四半期の計画を最初から一緒に見るようにしています。