いきなりのお知らせですが, 私shinyorkeは年内で現職（某大手外資系ITコンサル企業*1）を退職します（本日12/13が最終出社でした）&来年から再びプロダクトを取り扱うベンチャー企業*2でエンジニアとして働くことになりました（まだ予定ですが）&その転職活動から爆誕したコンテンツがこの記事です.
現職の皆様, 本当にお世話になりました&次の働き先はもうすぐ決まる見込みです*3.
退職と転職の話は後日別のブログで語ることにしますが,
約3年ぶりの転職活動（40代になってから二回目）は本当に苦労しました.
エンジニアの転職プロセスは色々ありますが,
- 通常の面接・選考(過去経歴, いくつかの質問の中で能力・カルチャーがフィットするか)
- 技術選考（プログラミングテスト, 応用的な技術課題の作成・提出, レビュー形式の技術面談など）
大雑把にこの2つに分かれるかと思います*4が,
???「技術選考って時間かかるし何から準備したら?」
ってなるんじゃないかなと思います, 少なくとも私はそうでした.
そんな苦労した選考に関するノウハウややったことを,
- 参考書籍
- 選考対策, 特に技術選考での対策
をまとめたのがこの記事となります.
おそらくですが再現性はあります*5（再現性を持ってるような事だけ書いています）,
今まさに転職活動中の方も, 将来の転職活動を見据えている方も, そして企業の採用担当の方の参考になれば幸いです.
また, この記事は毎年恒例「おすすめの技術書籍紹介（去年はこれ）」コーナーを兼ねている事を予め宣言しておきます.
TL;DR
技術選考はディスカバリー（発見）風プレゼンとその準備が大事&自身のキャリアストーリーを語れるようにするのはマジで大事.
対象読者
この記事は,
給料・報酬をもらってエンジニアリングをしているエンジニア全般および, そのようなエンジニアを採用したい企業担当者
を対象としております.
特に,
- 既にエンジニアリング・マネージャー（EM）である, もしくはEM相当で転職活動をしている（経験有無は問わない）.
- 「技術者教育について」というブログ（ぜひ読んで欲しい）において, 「一人前」以上の経験と実力があること*6.
- 現職で後輩や部下をリードしているエンジニア
上記に当てはまる方にとって参考になる情報になるかと思います&若い方, ジュニアな方や採用担当者は「強いエンジニアから見るとそう見えるのね」って思いながら読むと良いのかなと思います.
おしながき
転職活動前に読んで欲しい書籍
今回の転職活動（自宅を購入し, 落ち着いた後の夏場から開始しました）では, （今後想定されるであろう）技術選考および, 自分が所望していたSREおよびプロマネ（プロジェクト/プロダクト両方）に備えて, 以下の書籍3冊をしっかり読みました.
また, （私が苦手な）プログラミングテストについてもこの辺の書籍を読みつつ練習して対応しました.
なお, 「敢えて一冊に絞って欲しい」という話だと「システム設計の面接試験」になります.
こちらが本当に参考になりました.
システム設計の面接試験
書籍のタイトル通り, 「面接受けるなら絶対読んでおけ, 必読やぞ！」レベルの良著です.
仕事の提案や, 事業会社のエンジニア部門における「システムをどういう構成で作るか？」といった問は日常茶飯事的にあると思います. これらのお題目に合わせたBlueprintを書くのに最適な一冊という感じで面白かったです&実際に面接でも使えると思います.
- ユーザー数が突然100万以上になったときのスケーラビリティ
- 通知システムのアーキテクチャ
- あなたはYouTubeをどうやって作りますか?
という問に答えるのに良い一冊でした.
という感想を書きましたが, さらに付け加えると,
- サーバー, データベース, ネットワークetc...といったシステムコンポーネントごとの観点・ノウハウ
- 問題理解や設計の提案および必要な深堀りの考え方, やり方
- スケーラビリティやアルゴリズムなどの要件を踏まえたアーキ設計
などなど, 「システム開発や保守で困ることあるある」をいい感じに書いてくれています.
なお, 面接や技術選考をしない人も普通に手元に一冊あると便利かなと思っています*7.
後述する「SREをはじめよう」と合わせて読むと良いかもしれません.
SREをはじめよう
SRE（Site Reliability Engineering*8）の導入書として最高なだけでなく, システム運用・開発で考慮すべきことを網羅的に触れている良質な一冊です.
「私, SREじゃないし」みたいな方も読んで損はないと思います. 「SRE = インフラの人」とは限らないので.
SREという文脈で別途感想を書きたい書籍ですが, 今回はこちらの内容を紹介します.
7章「SREとして採用されるためのヒント」
そのままの章タイトルですね.
ここでは本当にいいことが書いてあります.
SREの面接に備えるという項目にて,
- NALSD（非抽象的な大規模なシステム設計）*9
- 監視/オブザーバビリティ
- 実践的なコンピューティングの基礎
- トラブルシュート/デバッグ
以上の項目が「職種の特殊性に関わらず, 普遍的なトピックですよ」と紹介されています.
実際問題「NALSD」「監視」「コンピューティングの基礎」「デバッグ」はどの領域のエンジニアでも抑えるべき内容*10です.
詳しい解説や前後の文脈はぜひ「SREをはじめよう」を手にとってお読み頂ければと思いますが, SRE本の決定版ぐらいに素晴らしいので是非.
プロジェクトマネジメントの基本が全部わかる本
プロジェクトマネジメントで抑えるべきことをいい感じにまとめている書籍です.
特にエンジニアリング・マネージャーな人（もしくはこれからなる人）にとって必読レベルでいい本だと思います.
とくに
- 新規事業やDXに携わるマネージャー
- 受託プロジェクトのマネージャー
- PMの基本を学び直したいビジネスパーソン
- プロダクト開発に挑戦するスタートアップの経営者、エンジニア、デザイナー
にとっては必読の一冊でしょう。
と, Amazonの解説にありますが個人的には特にPMの基本を学び直したいビジネスパーソンという意味で抑えるべき書籍かなと思っています*11.
なお, プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営までというお仲間的な本もあります&私はまだ読んでいません（これから読みます）が, エンジニアの転職対策的には「プロジェクトマネジメントの基本が全部わかる本」で賄えたのでひとまず最初の一冊はこれで十分かと思います.
プログラミングテスト対策
本屋さんなどでチェックして, 良さげな本を買って写経すべきかなと考えています.
これは置かれている状況や好みの言語, どこまで実装力を求められるかで濃淡あるので個々人で合う本が良いかなと.
私はいくつか読んで, 以下の書籍を買いました.
- プログラミングテストはPythonと決めていた*12のでPythonの本
- 自分的に写経しやすい
- 応用も効きやすい
的な理由でこちらの書籍を選択しました.
エンジニア転職で必要な対策
ここまで書籍の紹介をしましたが,
???「転職活動において実際やっておくべき対策って何よ🤔」
という話をします.
- 技術選考対策
- 机上の知識より手触りが大事
- ディスカバリーをやる
- 質疑応答を打ち返す練習
- 通常の面接対策
- ポートフォリオで流れを作る
- 君のキャリアを語れ
という話をしますが大事な事を先にいいます.
転職活動をするなら, 「職務経歴書」などの準備*13を含め, それなりに時間と労力が必要です.
準備の重要さは去年このスライドで語っています.
技術選考対策
手を動かし, 成果物の説明をディスカバリーとして実施.
あとはひたすら質疑応答を打ち返す練習（と体力）を付けましょう.
机上の知識より手触りが大事
手を動かしてシステムを扱う経験こそ正義. 書籍や選考対策「だけ」の人は話が浅くてすぐ看破されますよ！
「選考対策」はこのブログの内容も含みます, これを読んでそれっぽく振る舞うだけではだめだと思うので.
手を動かす（コードを書く, ドキュメントを書く, トラブル対応をする）経験は本当に尊いです, これがあるからこそ選考の話や説明に現実味が増します.
これは業務的な経験で積む方法もありますが, 個人開発でも全然良いと思います.
少なくとも「本で読んだ」「学習サイトでチュートリアルをやった」だけの人とは「手触り感」が全然違います*14.
私の場合は後ほど紹介するポートフォリオの中で手を動かした実績を交えてプレゼンするなども実施しました.
ディスカバリーをやる
選考課題の成果物を説明する際は, 「説明的なプレゼンテーション」ではなく, 「ディスカバリー（発見）風のプレゼンテーション」をやる.
これは結構難しいテクニック・概念ですができるとプレゼンがバシッと決まるのでオススメです.
「ディスカバリー」というのは, SaaSやクラウドサービスのソリューションアーキテクトやその手の人が,
- 顧客が解決したい事・得たいこと
- 現状の状態（言い換えるとAs-Isの事. システム構成, デプロイ回数, 開発・保守の状況, etc...を元にすることが多い）
- あるべき姿（言い換えるとTo-Be. 狼アラート減らしたい, デプロイ回数増やしたいetc...）
をインプットとして, 「解決すべき課題」と「課題を解決する手法・アイデア」を提示することを指します（私の理解では）.
どんな形であれ技術選考は,
- どういった技術スタックで実現するか
- チーム構成・コストはどれぐらいかかるのか
- 起こり得る問題に対してどうやって対処するか
これをストーリー立てて説明することになるのですが,
技術選考で求められるようなアウトプットを「読み上げるような説明でやっちゃうとつまらない感じになってもったいない」事になります.
という事が私には何となく見えていた*15ので,
- 選考課題のインセプションデッキもしくはDesign Docを書く（雰囲気に合う方で良い*16）
- 書き上げた後, 推敲して「特に話題になりそうな課題」「解決方法・アイデア」に着目する
- 話す順番を整理して「ディスカバリーっぽい」話にまとめる
という作業と準備をした結果, いい感じになりました.
なお, 「ディスカバリー」「インセプションデッキ」の準備とレビュー, 壁打ちには生成AIがめっちゃ使えます&かなり捗ります.
質疑応答を打ち返す練習
30分〜1時間の質疑応答に対する準備を怠らない（場馴れする&前日しっかり休む）.
この辺はぶっちゃけ「気合」です.
ITコンサルやSIの人は対面レビューの経験豊富かなと思いますがその経験が活きてきます.
「普段GitHub ISSUEやチャットでのレビューやりとり多いな」って方は, 社内外でLTや発表してその質疑応答などで鍛えてください.
あと, 「体力を温存するためのコンディション調整」もめっちゃ重要です.
私は技術選考の面接前のルーティーンとして,
- 前日はお酒を飲まない
- 前日はたっぷり寝ておく
- 可能な限り当日は仕事をしない（半休もしくは全休して備える）
ようにしていました.
いくら場馴れしていても, 体調などの調子が悪いとパフォーマンスに影響するので.
通常の面接対策
ちょこっとだけ通常の面接対策を紹介します.
一言で言うと, ポートフォリオを準備するとめちゃくちゃ捗る！
ポートフォリオで流れを作る
職務経歴書に加えてポートフォリオを準備したら最高に捗りました.
論より証拠で, こんな感じで準備しました.
実際使ったポートフォリオはもっと詳細に書いています（公開用に少し端折っています）.
これは私が職歴ベースでの自己紹介で何度かしくじったこともあり,
- 普段のプレゼンと同様スライド合ったほうがいい
- プレゼンの強弱をコントロールしたい
- そうだ, ポートフォリオじゃん！！！
となり, Googleスライドの公式フォーマットにちょうどいいポートフォリオがあったのでこれをベースに作成しました.
結果的にこれは大成功で,
- テキスト形式の職歴よりプレゼンしやすい. 特に画面を投影しながらやるときは雲泥の差.
- 字が大きいのと必要な箇所に特定できるので見やすい.
- 選考フェーズやポジションに合わせてアレンジしやすい*17.
ベースのポートフォリオ作成には2日ほどかかって大変でしたが, 時間を投資しただけの効果はありました.
キャリアを語れ
自分のキャリアを未来・過去・今のストーリーとして語る.
私の場合は特に転職活動が多いので,
- 各タイミングの転職理由
- キャリアの節目で得たもの（失ったもの）
- これからやりたいこと
を語る準備をして挑みました.
この際にもポートフォリオは役立ちました.
（ある意味当たり前の事ですが）過去のキャリアややりたいことは当然問われるので準備はしたほうがいいです.
結び
長々と書きましたが,
- 技術選考の準備
- 普通の選考の準備
- 読んでおくべき書籍
を紹介しました.
「ええ, これ全部やるの難しいじゃん」って思った方は真似できる所からやる, もしくはとりあえず本をポチって週末に読むでもいいかなと思います.
なお, 「転職に役立つ」と書いたものの, 別に転職しなくても役立つと思います.
この書籍紹介と転職準備のノウハウが誰かの役に立つことを願っております.
最後までお読み頂きありがとうございました&おまけもお楽しみください（興味ある人は）.
【おまけ】関連して参考になる記事
手前味噌ですが, この辺は参考になります.
【おまけ】2024年に読んで良かった書籍
毎年恒例のやつです.
ついに来ましたデータマネジメント第二版！
斜め読みしか出来ていないですが, じっくり読みたい.
野暮用でAzureが必要になったので読みましたが良かったです.
個人的にパブリッククラウド（AWS, Google Cloudなどそういうやつ）は,
- 課金体系およびプロジェクト体系を知る
- VPCやSubnet, VPNといったネットワーク製品と特性を知る
- 上記を交えたベスプラを知る
事で理解が進むと思っているのですが*18, そういう読み方するのに丁度いい感じでした.
おかげさまで, 「書籍を読んでちょこっとアプリ書いてterraformで操る」事で理解できました👍️
興味本位で読みましたが面白かったです.
ディスカバリーやストーリーテリングを上手くやる意味でも読むといいかも.
読みました&自分で作りたくて買ったのですがまだ手を動かせていないので.
長いお休みの中でやれたらと思います.
*1:社名を書いていないのは大人の事情です, 察してください.
*2:こちらは時期が来たら次の社名とやることを公開可能な範囲で語ります.
*3:2024/12/13現在, 複数のオファーから選択する段階となっており, 決定はしていません.
*4:書類選考, さらにその前のカジュアル面談もありますがこの記事では「それらは既に済んでいたとして」という仮定で書きます.
*5:「shinyorkeだから出来るんでしょ」「そりゃ中川さんコンサルだし」とか言われそうですが, 本を読んで真似するのはまあまあ出来るのではと.
*6:ジュニアな人が読んでも参考になるとは思いますが, ちょっと難しい内容なので「シニアなエンジニアの転職ってこんなかんじなのか」ぐらいに捉えて読むと良いかもしれません.
*7:本のコンセプトもそこにあるような気がします.
*8:たまに違う訳もあったりしますがオリジナルは「Site Reliability Engineering」です.
*9:Googleさんのブログより.例えばこういう話なのですが, この辺のノウハウなどはSRE本だけでなく, 「システム設計の面接試験」でもしっかり学ぶことができます.
*10:システム(Site)全体の安定化やガバナンスを効かせて仕組みづくりはSREロールのエンジニアのミッションだと思いますが, 具体の対策や実装, 運用そのものはフロントエンド, バックエンド, アプリなどの他のエンジニアとコラボして進めるのがあるべきだと私は考えています.
*11:「プロジェクトマネジメントよりプロダクトマネジメント！」なんて声も聞こえそうですが, 結論から言うとどっちも必要でこの2者は似て非なる者です.
*12:今どきのプログラミングテスト環境だとどの言語でもいける（はず）なので, 受験予定の言語を決め打ちして選ぶのがベストだと思います.
*13:履歴書, 職歴に加えてエージェントや転職サイトにて書くor渡すべき物が結構あります. また, 面接やプレゼン経験が低い（苦手）な人は練習も必要でしょう.
*14:私は面接を受けるだけでなく, 面接官もやるのでわかりますが「机上の知識」「本を読んだだけの生兵法」は割とわかっちゃいます. どんなにトークが上手い人でも.
*15:これは実務経験上もそうで, 単に資料を読み上げるプレゼン以上に「ストーリーに基づいた課題と目的, やることの確認」にならないとメッセージは伝わらないです. いわゆる「ストーリーテリング」をする必要があります.
*16:現実的には「課題に合う方」でいいかなと思います. プロダクトマネジメントが求められる課題ならインセプションデッキ, システム開発やアーキに関する話ならDesign Docかなと. ちなみに私は両方必要なシチュエーションがあったので両方書いて選考に臨んだこともあります.
*17:例えば「SREリードの選考」の場合, SREとしての実績を強調, 他の経験は別紙扱いにするなど, コピーを作って有機的に対応することができます. これを職歴でやるのは辛いので大きな発見でした.
*18:これは今の仕事の中で覚えました&ヒントになるような強強エンジニア上司に恵まれたお陰だと思っています
