経験・行動面接

STAR で話します。例えば「月間 50万人の EC サイトで、商品一覧が遅く離脱が増えていました」と状況を短く述べ、「一覧の改善の担当として、LCP を 2.5 秒以内にすることが課題でした」と自分の役割を示します。

行動では、RUM で TTFB が原因だと分け、APM で N+1 を見つけて preload とインデックスで直し、画像の配信も変えた、と判断の順に話します。1つずつリリースして効果を測ったことも入れます。結果は「TTFB 1.2 秒が 300ms、LCP は 2.2 秒に」と数字で示し、N+1 を CI で検出する仕組みを入れたことで締めます。

例えば、キャッシュのキーにユーザー ID を入れ忘れ、ログイン中の別のユーザーの情報が数分間見えてしまった、という経験を話します。気づいたらすぐに報告し、キャッシュを無効にする設定で影響を止め、影響したユーザーを調べて関係者に伝えました。

そのうえで原因を直すだけでなく、ユーザーごとのデータには必ずキーにユーザー ID を含める共通の関数を作り、他人のデータが見えないことを確かめるテストを追加しました。失敗を隠さず報告したこと、影響を止める判断を先にしたこと、仕組みで再発を防いだことを伝えます。

例えば、デザイナーが提案したアニメーションの多い画面が、安いスマホで重くなる懸念がありました。反対するだけではなく、まず目的が「商品の魅力が伝わること」だと確かめ、試作を作って実機で INP を測り、数字を共有しました。

そのうえで、目的を保ちつつ軽くできる代案（transform だけを使う・最初の表示では動かさない）を出し、一緒に決めました。意見の対立は、どちらが正しいかではなく、ユーザーと事業の目的に照らして判断の軸をそろえ、データで決めるようにしています。

負債は「返すべきもの」ではなく、「開発の速さや障害の多さという形で、事業に利息を払っているもの」として説明するようにしています。例えば、テストのない注文の処理を誰も触りたがらず、変更に毎回2日かかっていました。変更の頻度と障害の件数を数字にして PM と共有し、スプリントの2割を改善に使う合意を取りました。

一度に作り直すのではなく、変更のある所からテストを足し、少しずつ処理を分けました。結果として、同じ種類の変更が半日で出せるようになりました。

新しい技術は、まず「何の問題を解決するものか」を調べ、今のチームにその問題があるかを確かめます。例えば Server Components を検討したときは、JS の量と初回表示の遅さが課題だったので、1画面だけで試作し、送る JS の量と LCP を測りました。

採用するときは、チームの学習の手間、運用の変化、やめるときの戻しやすさも含めて比較し、判断と理由を ADR に残します。流行っているからではなく、課題と数字で決めることを大事にしています。