転職活動で一番「準備した気になれる」のが、面接の対策だと思う。
でも実際にやってみると、「どこまでやればいいんだろう」という感覚がずっとあった。今回は、私が転職活動中に実際にやった面接準備の中身を、なるべく具体的に書いてみる。
まず「想定問答集」を作ることにした
面接対策で最初にやったのは、想定質問と回答をセットで整理したドキュメントを作ることだ。
エージェントから「こういうことを聞かれますよ」とリストをもらったり、AIに「このポジションの面接でよく聞かれることを挙げて」と出してもらったりして、それに対する答えを書き込んでいった。
ポイントとして意識したのは、回答を「30秒版」と「60秒版」の2種類用意することだった。
面接では、最初に短く答えてから深掘りされることが多い。「転職理由を教えてください」と聞かれて、いきなり3分話すのはリズムが悪い。まず結論だけ短く出して、「もう少し詳しく聞かせてください」と言われてから詳細を添える、という流れのほうが会話として自然になる。
転職理由の場合で言うと、こんな感じで整理した。
- 30秒版：「5年後を見据えて、高速な価値提供サイクルをプロダクト全体で回せる環境に移りたいと考えたためです」
- 60秒版：現職での構造的な課題（分業・意思決定の距離）と、社内で解決を試みたが難しかったことを加える
ただ、問答集は丸暗記してそのまま喋るためのものじゃないと実感した。全部覚えようとすると、気持ちが乗らなくなる。それよりも、「なぜ自分は転職するのか」という軸を固めておいて、その方向性に沿って話せるようにしておく方が、本番で自然に出てきやすかった。
STAR法で「1番頑張ったプロジェクト」を整理した
技術面接で必ず聞かれるのが、具体的なプロジェクトの話だ。
私の場合は「CI/CD環境の構築」を主軸に据えた。
- Situation（状況）：従来のプロジェクトでは、CI/CDの導入が実装完了後になることが多く、エラーが長期間残りやすかった
- Task（課題）：新規プロジェクトの実装フェーズ中に、開発プロセスを根本から改善する
- Action（行動）：まず自分でプロトタイプを実装し、PDCAを回しながら関係メンバーと改善
- Result（成果）：5分以内にエラー検知、10分以内に自動デプロイできる環境を実現
数字があると具体的になる。「改善しました」だけだと伝わりにくくて、「5分でエラー検知、10分でデプロイ」のような数字を添えることで話に重さが出る。
STARフォーマットを使うのは、話が散らからないようにするためだと実感した。自分の話なのに、いざ言語化しようとすると順番がバラバラになりがちなんですよね、これ汗。
ネガティブFBや弱みも「事前に準備」した
「弱みを教えてください」と直接聞かれることはなかったが、「もっと改善するとすれば？」「できていなかった部分はどこですか？」という形での質問は来た。
現場でとっさに答えようとすると、言葉がうまく出てこない。なので事前に「実際に受けたフィードバックを1シーンに落とす」という形で準備した。
私の場合は、上司から「設計や実装はきちんとできているが、自分のタスク完了で止まってしまい、周囲の意思決定や全体の流れを前に進めきれていない」というフィードバックを受けたことがあった。これをそのまま面接で話せる形にした。
大事なのは、FBを「ただの反省話」で終わらせないこと。どんな場面でそれが出たか、そこからどう改善したか（育成を担当してスキルマップを作った、など）まで用意しておくと、「課題認識できていて、前に進める人」という印象になる。
エージェントとの模擬面接がかなり効いた
模擬面接でお世話になったのは、izulとキッカケエージェントの2社。それぞれ役割が違った。
izulにお願いしたのは最初の段階で、「面接に慣れる」が目的だった。応募前のかなり早い段階から「やってみましょうか」と声をかけてくれて、職務経歴書ベースで一度やってみることができた。
一人で問答集を作っていると「これで大丈夫かな」という感覚がずっとあるが、実際に人に向かって話してみると、まったく違う気づきがある。
- 話の順番が頭の中と違う
- 「なぜそう思ったんですか？」と深掘りされると止まる
- 言葉を選びすぎて逆に伝わらない
フィードバックも具体的で、「回答は整理できているけど、プロセスや思考の深みがもう一段ほしい」といった指摘をもらった。この段階では「感覚を掴む」という目的にはちょうど良かった。
その後の対策を手厚くサポートしてくれたのがキッカケエージェントだった。
担当のキャリアアドバイザーが内定先についてよく知っていて、「どのあたりの技術観点を深く聞かれやすいか」「内定先が何を大切にしているか」といった情報を事前に共有してくれた。面接があるたびにほぼ毎週定例で話して、フィードバックをもらいながら次の準備を進めることができた。
内定先が面接の観点をある程度オープンに公開していたのも大きかった。「こういう観点で見ますよ」と示してくれている企業なら、それに沿って準備するのは当然の話。これを使わない手はなかった。
内定先の選考自体も、想像より丁寧な印象だった。副社長クラスが面接に参加するなど、「ちゃんと人を見てもらっている」感があって、準備してきたことを出しきれたと思う。
また、エージェントとの模擬面接だけでなく、AIを相手に練習するのもかなり有効だった。質問をテキストで出してもらって、マイクで答えてフィードバックをもらう。回数を積む意味では、人ではなくてもこれがかなり使えた。
一般的に、転職エージェントには模擬面接を依頼できることが多いので、使わない手はないと思います！
「当日の面接でどうなったか」も書いておく
実際に内定先の一次面接に臨んでみると、準備していた内容とだいたい同じ流れだった。
面接の4割くらいは、1番頑張ったプロジェクトの技術的な深掘りだった。
- 技術スタック（Rails / Nginx / Aurora）の説明
- パフォーマンス改善の数値成果（8req/sec → 25req/sec）
- E2Eテストやスロークエリの対応
- CI/CDの判断（いまの規模ではコストに見合わないと判断した理由）
「スロークエリの監視はしていなかった」ということも正直に答えた。完璧に答えようとして嘘をつくより、「できていないことはできていないと言って、改善の判断に繋げる」ほうがずっと自然だし、あとから聞いた話では、そういう回答の方が評価されやすいらしい。
面接の途中で猫（凜ちゃん）が乱入してきた。一瞬「まずいかな」と思ったが、キッカケエージェントの担当者に事前に相談したとき「猫が横切ったことが理由で落とすのって、論理的じゃないですよね」と言ってくれていたので、本番もあまり気にせず話せた。Web面接あるあるですね笑。
後半はチーム開発やスクラムの話になった。スクラムの課題も含めて正直に話したが、面接直前に受けた研修で学んだ考え方を実際に使えたのは素直に嬉しかったですね。
振り返って感じること
面接準備でやってよかったことを3つまとめると、
- 「30秒版」「60秒版」の2段階で答えを用意した（ただし丸暗記より「軸を固めておく」ことの方が本番では効いた）
- エージェントやAIとの模擬面接を何度もやった（問題点は話してみないとわからない）
- 弱みやFBも事前に整理した（現場でとっさに答えようとすると失敗する）
面接は「試験」じゃなくて「会話」だとよく言われるが、それでも準備量は裏切らないと実感した。
準備しすぎて困ることはなかったので、できる範囲でやり込んでおくのがいいと思います！
転職活動に役立つエージェントや求人サービスは、以下から探せます。