← phihash
キャリア
戦略を練る
狙い先（どんな会社・環境を目指すか）
- よく分からんベンチャーで「PMでこんな成績上げました」と職務経歴書に書かれても、よく分からんベンチャーだからよく分からん（社格・知名度が実績の解釈可能性を左右する）社格あれば独立・副業で困らない
- 転職なら基本は親会社に入った方がいい。子会社は福利厚生は同じでも給与が親会社の7〜8割で、同じ課長でももらえる額が数百万違う
- ベンチャーに転職するなら、年収もSO（ストックオプション）もどっちも出してくれるかを確認
- スタートアップのプロダクト開発は安全にdefectなくリリースする経験が身につきにくいことが多いので、少し堅めで、しっかり予算を使って開発してる所の方が色々経験できる
- 上を目指すなら背伸びしてでもレベルの高いところに入る（成長は環境が8割）
- 技術的に強くなりたいなら、質の高いエンジニアリング文化＋大量ユーザーのサービスを持つtoC自社開発企業
- キャリア意識の高い組織にいると情報が勝手に集まる
- SWE採用の国内テック企業（応募先候補の参考）：
- Google（検索・Chrome等コア開発）／ Indeed（日本に大きな開発拠点）／ Amazon（ポイント・マンガ・一部AWS）／ Microsoft（Industry Solutions Engineering）／ Apple（SRE・DevOps・内部ツール）／ Adobe・Salesforce（ローカリゼーション）／ X（プロダクト開発）／ Wolt（元DoorDash）／ Niantic ／ NVIDIA ／ Unity ／ Elastic ／ Shopify ／ Databricks ／ Palantir（Forward Deployed SWE）／ Stripe ／ Block（旧Square）／ ByteDance（R&D）／ Splunk（SRE）／ Oracle（SRE・LLM系）／ Palo Alto Networks（SRE）／ SmartNews（日本発では年収トップ級）／ Treasure Data（日本人創業）／ 一休 ／ メルカリ ／ Woven by Toyota（トヨタ子会社、ポジション多）
- メガベン一覧（国内）：
- LINEヤフー ／ メルカリ ／ PayPay・PayPayカード ／ リクルート ／ サイバーエージェント ／ Sansan ／ GMO ／ DeNA ／ mixi ／ はてな ／ 楽天 ／ LegalOn Technologies ／ DMM ／ LayerX ／ エムスリー ／ クックパッド ／ ZOZO ／ マネーフォワード ／ freee ／ サイボウズ ／ クラシル ／ ユーザベース ／ ビズリーチ（Visional）／ LIFULL ／ エウレカ ／ CADDi
自分の動き（何を作る・勉強する・どう応募する）
- 高度資格・3年勤続などは要は「外から見える実績を作る」ための手段。外から見える実績が最終的にキャリアの自由度をくれる。「今の自分が何をしたら外から優秀だと見てもらえるか」を深く考える
- 職務経歴書に3つは書ける実績を作る。経験年数1年未満・実績薄では転職は無理——大したバックグラウンドがないなら、せめてこれを作ってから動く
- 経験は勝手に金にならない（どこで積むか次第）
- 横滑り転職はしない
- よく分からん企業を転々とするのはキャリア最大のバッドプラクティス。本当にやめた方がいい
- ブラック企業に入らない確実な方法は、ブラック企業に応募しないこと。「早く転職したい」「不合格通知を見たくない」の焦りに負けて格下に応募すると、すぐまた転職したくなる上に履歴書が汚れて次の難易度が上がる＝遠回り
- 在籍3年未満での転職は「遅効性の毒」：した直後は一見問題ない。やらかしに気づくのは次以降の転職で——経験的に行けるはずの企業なのに、なぜか書類選考が通らない。じわじわキャリアを蝕むのでやめておく
- 3年耐えた後、転職するなら「今の勤務先の完全上位互換」のみに応募。焦った格下転職や小刻みなステップアップは転職回数が増える分むしろ市場価値が下がる。ダラダラ新規求人を監視しながらジャンプアップを狙う。転職は長期戦
- メガベン経験がないならレジュメに経験を刻む選択も悪くない。ネームバリューのないスタートアップでも、キャリアになるドメイン領域の経験なら良い選択
- どこにでも適用できる絶対的なエンジニアの評価などない。自分がどこで評価されたいのかよく考えること
- 優れたエンジニア ≠ 会社で評価されるエンジニア。マインドと働き方を変えるだけでも評価は変わる（技術力そのものより、その場での立ち回り方の問題）
- 中途はノーダメージでチャレンジできる：新卒就活と違い、手が届かないような良い所を受けて落ちても現職に残ればいいだけ。何回もチャレンジすればいつか面接慣れして受かる。この点で中途はめちゃくちゃ有利。上手くいけば年収800万は簡単に超えるし、ダメでも「今回はダメだったね」で終わり＋活動で得た知見が現職に活きる。やらない理由を探すより行動する方がお得
- 優秀なエンジニアが集まる企業（有名SU・メガベン等）に入る前提で逆算する：穴があくほどそこの求人を読み込み、発表資料・ブログを見て、今の自分とのギャップを把握し、それを埋めることに集中する。こうすれば"一次ソース"で判断でき、Xのパーソナライズされてないキャリア論に振り回されずに済む
- 会社と一緒に沈んではいけない。他の企業で今やってることがどう活かせるかを考慮する
- 年収をそこそこ上げたいだけなら、事業内容に関係なく経歴にキーワードを増やすゲーム。ただし企業の将来性や条件も考えるなら、特定技術の経験値だけでなく「如何に上手く使いこなしてきたか」を案件ベースでセットで語れる必要がある
- 開発者以外の技術職の見立て（共通：製品に興味あるか／世の中で人気か をモチベ・ポストキャリア両面で重視）：
- サポートエンジニア：入り口としてはアリだが長続きする仕事とは思わない。技術職で給与最低に設定されがち、ケース消化がKPIでCreativityがなく飽きる。抜けるならソリューションアーキテクト（ポストセールス寄り）を狙う。関連学位の制限が少ないので面接さえ通れば今でも入りやすい（同系で Technical Account Manager も調べる価値あり）
- コンサル：SIerに少し近い。案件ベースだが納品義務はなく実装は大体パートナー企業。一人で複数案件でクッソ忙しい（人を増やさず売上だけ求められる構図）
- ソリューションアーキテクト：ふわっとしたロールだがやってみたい。会社によってやること違う。好きなプロダクトでないと続かない
- プリセールス：年収は高くなるのでオススメだが、エンジニアと呼べるか微妙。営業ほど責任はないがディール成立に大きな役割、結果を出せないと居づらい
- DevRel：開発者以外なら一番やってみたい。ただし人気プロダクトであることが大前提（開発者の前でドヤってチヤホヤされたい）
- 新規開発は「動かすこと」「仕様を満たすこと」が最優先で、設計の自由度も高く負債もなくユーザーも少ない＝「動けば合格」で評価が完結しがち。信頼性・性能を高めるエンジニアリングは後回しにされやすい。既存を止めず品質を落とさずリアーキするのはゼロから作るより遥かに難しく、その力は動き続けているシステムと向き合わない限り身につかない。とはいえ新規開発が無意味という話ではなく、両方をバランスよく——新規で得るスピード感と、運用で鍛える信頼性・性能への感覚。
- 応募は積極的に。日本語必須の日本の外資ITポジションにも臆せず応募する（平気で応募してくるインド人を見習う）
- 「見せれる経歴」より 「話せる経歴」 を作る。ハッカソンや受賞歴でなく、個人開発・プロダクト志向を見られる流れ（例：ゆめみ）
- 休日の勉強は、小手先のツールの扱いより コーディングインタビュー・システム設計の対策。外資ITのSWE職に近づく
- CS学歴っぽいものの手っ取り早い代替：AtCoderの茶〜緑を取ってレジュメに書く。最低限の役割は果たせる
- 挑戦を「実力ないのに」と馬鹿にする奴こそ恥
- PF（ポートフォリオ）の内定への影響度は 面接(選考)対策 >>> README > UI/UX > 機能数（Web転職を終えた人の実感）。採用担当は思ってるほどあなたのPFに興味がない（あなた自身には興味がある）。機能数を必要以上に増やすのは徒労になりがち。
- README はほぼどこも見る＝ここを全力でアピール：デモ動画・機能一覧・使用技術一覧・インフラ構成
- 次にトップページまでは見る企業が多い＝デザインで今どき感を出すと好印象。レスポンシブ対応はほぼマスト
- キャリアは運だけじゃなく戦略：運要素は確かに強いが、今も条件よく働けてる人は「自分でキャリア戦略をきちんと考えてた」人。プロジェクトに入れられて数年動かず、完全に会社任せで緩やかに経歴が終わっていく人は、継続した努力＋リスクを取りに行ってる人には勝てない
選考の仕組み（動きの裏づけ）
- テック転職で「資格」はあまり意味を成さない。アウトプットとして弱いどころか、場合によっては逆効果。資格だけ多く実績薄いのは「勉強してます」止まり、アピールの仕方を考える
- 社歴は選考にバチバチ関係する。それだけで受かりはしないが、書類選考でまず目に留まるのは社歴。その後に中身でマッチ確認
- 所属企業のブランドが書類通過率をガッツリ左右する（3回転職した人の実体験）：中小企業→SUBARU在籍で通過率が明らかに変わり、短期在籍でもPwCからの転職ではさらに上がった。＝無名企業でスキルを必死に磨くより、環境そのものを変える方がキャリアアップにつながりやすい
- 面接はコストなので、ポジションが少数なら何人も呼べない（大量採用ならガバる）。だから書類段階で条件（社歴・経歴）が揃っている人は落ちにくい。輝いてる職務経歴書は案の定だいたい通る
経験者の教訓（やってよかった / しくじった）
- やってよかった：業務改善の経験。小さくても「上司に提案する形で業務改善した」経験は選考で聞かれることが多い＝作っておくと効く
- やってよかった：カジュアル面談を最重要視。選考後半ほど「ポジション理解×カルチャーマッチ」を見られる。それを探る最初で最後のチャンス。「御社で活躍している人の特徴・共通点を（個人の感覚で）教えてください」を必ず聞き、選考ではその人物像に寄せて回答した
- しくじり：複数言語に手を出した。業務＋個人学習で4言語ほど扱い、各言語が広く浅くに。選考では（多くの現場でも）複数言語の浅い知識より、1言語の深い知識のほうが評価される
- しくじり：早めに心折れておくべきだった。レジュメ推敲に時間をかけても、実際に面接を受けて落ちない限りPDCAが回らず転職活動の解像度が上がらない。心折れが怖くて慎重になりすぎ、時間を無駄にした
- 自社開発（メガベン等）は"やらされた"経験より"自分の意志でやった"経験を重視する
- 長期的なキャリアの成長を支えるのは、個別の技術の使い方でなく普遍的な基礎技術の土台
会社選び・地雷
目の前の会社に応募するか／内定を受けるか、見極めるとき。
見極め
- 直属の上司となるであろう人と面接するような会社がいい
地雷の見分け
- 燈：調達・評価額ばかりで売上非公開、実態はSaaS＋受託で革新的でない
- データサイエンス系SESは地獄
- ベンチャー求人四天王（裏の意味）
- 「裁量があります」→ 雑用も全部やる
- 「フラットな組織です」→ 誰も決めない
- 「家族のような会社です」→ 距離感が気持ち悪い
- 「成長できる環境です」→ 人手不足の言い換え
- 「仲間」を勘違いしてお友達ごっこを始める会社もあるので気をつける
- 炎上案件の特徴（フリーランス時代の実体験）：
- クラウド/インフラ担当が1-2名体制／開発チームの9割が外注の寄せ集め
- 基盤構築が1-2ヶ月で完了前提の無謀なスケジュール（雰囲気で引いてある）
- 「クラウドだから設計は不要」「IaCならコピペで環境構築できる」という認識
- 請負なのにテスト中の要件変更に柔軟対応させられる（請負と準委任の違いを理解してない）
- 根本原因：粗利最大化で安い外注で頭数を揃える／社内に有識者ゼロでクラウド採用／基盤は簡単にすぐ作れる扱い／「コード化したい」目的でのIaC採用／優秀な人はみんな辞めていく
- 「この案件炎上するな〜」の予兆ランキング：①仕様が決まってないのに開発が始まる ②関係者が多すぎる ③進捗報告が毎回「ほとんど大丈夫です」 ④進捗会議が増え始める ⑤ドキュメントが存在しない
- 数字目標がなくほぼ定性評価の会社は、上司に嫌われた瞬間終わる（上司ガチャリスク）
- 雑な採用は地雷サイン：社内SEなのにタイトルが「営業」、面接確約と言いながら書類選考しますと言う、求人票に誤字——採用初心者の可能性
- OpenWorkのスコアが著しく低い企業は避ける。3.3〜3.8くらいが良い。4以上は弄ってる（サクラ・操作）可能性が高い
- 新卒で初任給30万超えのベンチャーは、だいたいみなし残業80時間がついてる傾向。高い初任給の裏を疑う
- 採用の非対称性：応募者には「転職回数が多いですね」と聞くのに、「この会社では過去5年で何人辞めましたか？」とは聞かれない。労働者の離職歴だけをリスク扱いするなら、会社の"辞められた履歴"も同じように見えていい。→ 面接は会社を審査する場でもある。離職率・定着率を臆せず聞く
やばい自社開発の見分け方
書類を出す前
職務経歴書・レジュメ・ポートフォリオを書く・仕上げるとき。☑は潰す、それ以外は読む。
やること
書き方の指針
- 「何を作ったか」より 課題→解決→設計思想→運用フィードバック→UXの理由 を流暢に語れるPF/ES
- 実装機能の説明は最小、"どう考え課題に取り組んだか"を語る
- 業務内容は140文字くらいで「どんな立場で・何をして・どういうことを解決したか」を書く。作業の列挙じゃなく課題解決までのストーリー
- 型：「どのような課題があって、このようなアプローチをした結果、このようなポジティブなインパクトを顧客もしくはチームに与えた」という書き方をしないと駄目
- 「何をやったか」だけでは足りない。「何を考えて仕事していたのか」を伝える。特に自社開発企業では開発労働力を提供したら売上になるわけではない——その違いの理解から
- レジュメはGoogle Docsが第一。余裕があれば書ききれなかった内容を補助資料としてGitHubやNotionに用意
- スキルシートをまず見て良し悪しを判定するのは「分かってない人」が多い→その指標として「経歴〇年」の分かりやすい形が効く。一方その後に読まれる個別案件の詳細は「分かってる人」が見るので、そこは好き勝手に（濃く）書いてOK
- GitHubはリンクされたら一応見る（Emptyで閉じる、外向けに作ってあれば見る）／forkしまくりの大層なリポジトリは無言で不採用／草は定期的だと開発好きが伝わる
- 転職を終えた人の体感、内定への影響度が高い順：面接(選考)対策 >>> PFのREADME > PFのUI/UX > PFの機能数。採用担当者はPF自体に興味がない。逆にREADMEは大体どこも見てくれてそうなので、ここでアピールする
- 面接に呼ばれないと始まらない＝まず書類を通すこと
- 日本人の職務経歴書は長すぎがち。特に外資企業への応募にそのまま出すのは非推奨（外資は簡潔なレジュメ文化）
- 職務経歴書は"伝え方"で通過率が激変する：一見メガベン厳しそうな経歴でも、書き方を一緒に改善したら某メガベンの最終面接まで到達した例あり。中身より伝え方
レジュメチェックポイント
面接前
面接の直前に、上から目を通す。☑は準備で潰す、それ以外は頭に入れる。
心得（直前に思い出す）
- 退職理由と志望理由の一貫性が大事。「貴社にどうしても入社したいから今の会社を辞める」と繋がるように語る
- 「すぐ辞められます、1週間もあれば」的なことは言わない。すぐ辞められる＝その程度の仕事しかしてない／引継ぎ・責任感がなさそう、円満退職に見えない、という印象を与える
- 希望給与を手取りで言わない
- 面接では積極的に画面共有する。「見てもらえない」じゃなくて見せるのが大事（自信満々に見せる以上"一見の価値あり"と思われるモノが要る）。このガツガツさは特に経営層にウケる
- 現職の否定はしない。前職の悪口はなるべく抑える（相手はこちらの事情を把握してないので、会社が悪いのか自分が悪いのか判断できない）
- 「やりたいこと」より「会社に貢献できること」。自分のやりたい事アピールしすぎはよくない
- 中途（特にゲーム会社）では「うちに入ったら何ができますか＝何を貢献できるか」を必ず聞かれる。ここで自分の強み・夢・目標を明確に説明できないと落ちる
- 30代後半で志望理由が「キャリアアップしたいので転職します！」は「今まで何してたんだ」となる。良い例：「会社は運用保守に力を入れていきたい考えで、一定の理解はできるが、自分のキャリアの方向性と一致しないので転職活動を再開した」＝会社への理解を示しつつ方向性の不一致で語る
- 中途選考の考え方（前提：①会社が求める役割像が明確＝人気企業ほど要求が高い、②応募者に裏付け実績がある）：
- ①↔②の適合度を効果的に伝える＝基準点、その上で+αを印象づける＝加算点
- 一見実績不足でも、それを補う適合性（組織風土など）やノビシロをアピールできれば基準点の足切りは防げるかも（＝期待ベース評価）
- 採用は企業の要求クリアと同時に他応募者との競争。人気企業ほど基準点クリアは当たり前で、加算点の重要性が増す
- 日本で加算点になるのは（1）人柄と（2）キャリア
- （1）人柄＝コミュニケーション能力＋素直さ。コミュ力は組織労働の大前提（意思疎通できないと仕事にならない／ユーモアや非言語=笑顔・仕草・身嗜みも大事）。素直さ＝従順さ、上司・先輩の言うことにきちんと従えるか。コミュ力が「歯車が噛み合うか」、素直さが「歯車がよく回るか」
- （2）キャリア＝リテンション要因。採用・育成は莫大なコストで数年で辞められると大損。見通しを共有できれば安心して採用・育成できる。差をつけるには、事実を元にポイントを繋いで美しい物語に仕上げる能力が問われる
- 面接という場を忘れて会話を楽しむのがいい。準備しまくって臨んだ面接は大抵失敗する
- 一方的な「なぜ」だけの質問攻めは、される側の答える気を削ぐ（会ったことも話したこともない相手ならなおさら）。＝自分が聞く側のときも、詰問でなく会話にする
- TPOに合わせて服装含め準備できない人はお呼びでない。結局そこ
- 「この人仕事できないんだろうな」と思われる瞬間第1位：ベルトの色と革靴の色が違う（身だしなみの基本）
見られてる力
- 語るエピソードは「課題／効率化したい業務／改善したい体験」起点。相手は"どう考え取り組んだか"を聞いて自社で再現できるか見極めてる。必ず技術的な深掘りが入るので、自分の意思決定・設計・AI活用を答えられるよう準備
- 伸び代を見ている。働き方の型
- 曖昧な状況でも、自分で考えて前に進めるか
- 整理されたタスクを正確にこなす力と、曖昧な要件を整理しながら前に進める力——小さなチームでは後者がないと誰かが常にタスクを分解・判断・指示する必要が出る
- 指示された範囲の外に、自分から出たことがあるか
- 詰まったとき、いつ・どう人に頼るか
- 分からないことがあっても、考え、必要なところで人を頼りながら前に進めるか
- 「今どれだけできるか」より、「どれだけ自分で前に進めるか」
- 一緒に働いて気持ちいい若手：詰められてもあんま喰らわない／常に自分の意見も持ってくる／雑な指示も咀嚼しようと頑張る
- 会社の行動指針を守ることが何より大事。ボールを自分で拾ってプロジェクトを進められる人が評価される
- 運用保守を担当してた人が転職できないわけじゃない。何やってましたかと聞かれて「運用保守です」としか答えない人が転職できないだけ（そこで何を考え、どう信頼性/性能を上げたかを語れるか）
- よくある不採用理由：技術知識が浅い／トレードオフを踏まえた議論ができない／技術的な意思決定の妥当な根拠を説明できない
- ＝「知識があるか」より「現場でちゃんと戦えるか」「判断の理由を説明できるか」を見られてる。「何を作ったか」より「なぜそうしたか」を説明できるかが大事
- 深掘りされるポイント：
- 過去経験の深掘り：何をやったか→なぜそれをやったか→どう進めたか→結果どうなったか
- 難しかった課題と乗り越え方：詰まったときにどう切り分け、どう助けを求め、どう前に進めたか。再現性を見られてる
- 設計の判断理由（トレードオフ）：「これが良い」じゃなく「他の選択肢もある中で、今回は何を捨てて何を取ったか」を言語化できるか
- 本番運用を想定した視点：今の実装で足りないのは？（テスト、監視、ログ、リトライ、タイムアウト、CI/CD、認証…）
- パフォーマンス/障害対応の切り分け：遅い/落ちたときにどこから見て、どう原因を絞るか（ネットワーク、DB、外部API、ログ、メトリクス…）
- セキュリティ/認証認可：危ない実装を避けられるか、何がリスクか分かってるか
- API/DBの基礎：N+1、index、API設計、GraphQL/RESTのメリデメ。暗記じゃなく、なぜそうなるかを自分の言葉で
- LLMが書いたコードを理解して評価できるレベルは求められる。誰でもアウトプットできてしまう時代だからこそ中身をしっかり語れることが大切
- 採用面接は結局「一緒に働くイメージが湧くか」に着地する
- 経験値は年数じゃなく「どれだけ地獄（障害）をくぐったか」。「直近で一番しんどかった障害は？」で語れる人と急にトーンが落ちる人に分かれる
定番質問（＝ここを見られてる）：
「直近のプロジェクトを1つ教えてください。どの段階から入りましたか？ タスクはすでに整理されていましたか？ それとも曖昧な要件から自分で進めましたか？」
仕込む質問への準備（非技術）
見られてるポイント：どうしてうちじゃないと／ヴィジョン共感（カルチャーマッチ）／モチベ／ワークスタイル／求人と経験のマッチ／はきはき話せるか／キャリアプランの一致／会話にブレがないか／候補者の考えや強み
行動面接（behavioral）の攻略：質問1個ごとにエピソードを考えるのは非効率。メインストーリーは2〜3個で十分、その中から「技術的に困難だったこと／他人と対立したこと／失敗したこと／自分がリードしたこと」を書き出しておき、各質問はそこから引き出す。
仕込む質問への準備（技術）
経歴ベースの技術面接で技術的課題に話題が移ったら、以下まで一気に語れると強い（＝普段何を意識して仕事しているかを示せる）：
- どんな技術的課題があったか
- なぜそれを解決すべきだったか
- どんな方法を思いついたか
- なぜその方法を選んだか
- どうやって実装したか
- 結果どうだったか
実際に面接を受けた実感：「なぜその技術なのか」「どうやったのか」「苦労したところは」と深掘りされた。＝上記に加えて苦労したポイントも準備しておく。
データ構造とアルゴリズム：
- ハッシュテーブルの実装方法は？
- マージソートのアルゴリズム／安定ソートな理由は？
- 動的配列と連結リストの違いは？
- LRU Cacheの実装方法は？
技術選定の理由（自分のPF/実装について論理的に答える）：
- 「MySQLを採用したのはなぜ？」——他の選択肢と比べてなぜこの結論になったか
- 「認証にJWTを使っているとのことだが、JWTを採用する利点と、気をつけるべきポイントは？」
- ＝使った技術は必ず「なぜ選んだか／トレードオフ／注意点」をセットで言語化しておく
非機能要件まわり：
- N+1問題をどう説明し、どう解消するか
- DBのインデックスをどのカラムに貼るか、判断理由とトレードオフ
- 「ページが遅い」と言われたとき、バックエンド側でどう切り分けるか
- GraphQLはRESTと比べて何が良くて、逆にどこが辛いか
- Pub/Subってそもそも何？どういう場面で適用する？（Amazon SNSを見て。基礎力大切）
- シングルトンとは？マルチスレッド環境で起こる問題は？（レースで複数生成／命令並べ替え→対策：eager初期化・synchronized・volatile付きDCL・Holderイディオム・enum）
基礎知識の定番質問（カテゴリ別・答えられるように）：
- 参照渡しと値渡しの違いは？（Programming）
- JavaScriptの const / var / let の違いは？（JS）
- ブラウザでURLを開いてから画面表示までに何が起きているか（Network）
- ページを高速に表示するためにできることをいくつか（Browser/HTML/JS/CSS）
- CSSの詳細度（Specificity）：ID / CLASS / TYPE セレクタのどの優先度で適用されるか（CSS）
- SQLとNoSQLの一般的な違いは？（DB）
- プロセスとスレッドの違いは？（OS）
- VMとコンテナの違いは？（Virtualization）
- Reactの仮想DOMとは？（React）
- useMemoはどんな時に使う？（React）
こっちから聞くチェックリスト
前提：面接は「見抜く場」ではなく「証拠を集める場」。印象を聞く質問（「開発文化はどうですか」等）には100%良い答えが返るのでノイズ。聞くべきは直近の事実と数字。
その他の確認軸：
- 負債と障害：機能開発以外の工数／直近障害とポストモーテム（「障害起きてない」は検知できてない疑い）
- 外でやる：個人発信（GitHub/Zenn/登壇）を見る／カジュアル面談2-3人に同じ質問。答えが揃うかがその組織の情報流通の質
背景知識
業界の空気感・トレンド。どの場面にも紐づかない、眺めるだけの棚（＝「へー」で終わる雑学も含む）。
- ベンチャー転職後は職住近接が生存条件：大企業→ベンチャーで入社1ヶ月で会社の近くに引っ越した人も。労働時間と睡眠時間の確保が成果に直結するので、通勤を削る＝そうしないと生き残れないという実感
- 結局「早くやる」が最強のスキル。スピードは正義
- 育ててもらった恩は会社には返さなくていい：育ったなら会社がちゃんとした給料で雇えばいいだけ。安く使っておいて義理はない。ただし育ててくれた"人"には絶対感謝する（会社と人を分けて考える）
- BIできるエンジニアは今後需要が高まる
- 就職四季報の平均年収は当てにならない（実際はもっと高い）：大手IT/SIerで働く人には周知の事実らしい
- GMOはかつてアダルト系ダイヤルQ2の会社だった
- 40-50代が市場に流入、ジュニア＋AIで金食い虫のシニアを切る流れが一部で
- ずっと派遣→30歳超で正社員採用は厳しい（派遣持ち上げ記事に注意）
- 新卒エンジニアの採用単価がかなり上がってる
- 優秀な学生エンジニアを取りたい需要は続き、むしろ強まっている
- 新卒領域は毎年リセットされるから、エージェントの新規参入もしやすい
- GAFAMオフィシャルにPIPはアマゾンだけ
- Big Tech新卒には"やり方"がある、米国大以外だとWaterlooが強い
- SIerはbiz↔devの橋渡し、ITを他業界に活かす軸＝「自分の手でプロダクトを作りたい」タイプとは方向性が違う
- そこそこ優秀だった上司が異動先で冷遇されてるのを見て——人事評価なんて時と場所で変わる
- デジタル庁（大組織）の推察：末端エンジニアは最新の働き方を取り入れてるが、ビジネス側は古い慣習で疲弊。変えたくてもステークホルダー・しがらみが多くてどうしようもない。新規プロジェクトは既存を考えなくていいので比較的回る。意気揚々と入っても自分の力では何も変えられず絶望、というパターン
- 「20代は激務、30代から高給JTCゆるふわ部署へ」というキャリア戦略は現実には難しい。高給JTCゆるふわ部署は退職者がほぼいない＝中途にほとんど開かれてない。若いうちに激務スタートすると、結局ずっと戦い続けることになる
- 年収は「所属企業」×「職位」の2要素で決まる。「市場価値」という言葉は当てにならない——受ける企業によって事情が全く異なるから。年収をスキルや人材価値に紐づけて語る人（特に人材業界に多い）は、世の中に一本の「市場価値」の物差しがあって全員をそれで測れるかのように語るからおかしくなる
- 会社員での自己実現の限界：用意された食材でどう料理するかの裁量は与えられるが、好きな食材を買ってきて自分の好きな料理を作るのは難しい。＝手段の裁量はあっても、作るもの自体を選ぶ自由は薄い（自己実現したいなら独立・個人開発の側）
エージェント・応募
どのプラットフォーム・応募経路を使うか。
- 転職媒体：YOUTRUST / LAPRAS / Findy / Forkwell / レバテック等。登録した媒体以外のエージェントから連絡が来ないプラットフォームを選ぶと良い（質の悪いエージェントから大量メッセージが来るのを防げる）
- 単独フォーム（誰でも応募できる）だと、倍率が高い求人は受かりにくい。レベル未達の応募が大量に来るので、企業はリファラル・エージェント推薦を優先的にチェックして選考を進める。＝エージェントも多少は足切りとして機能している（「直応募は採用コストが浮くから有利」とは限らない）
- 転職者がエージェントを使うときの条件：自分の名目上のステータス（資格・経験）を上げて、いかに"美味しそうな売上"に見えるか
- 「対策」と言いつつ経歴の誤魔化しを指導してくるエージェントもいる。これは論外なので乗らない（成約優先で応募者を焼くタイプ）
- エージェントは当たり外れがデカく、外れがほとんど前提で使う（過去3回の転職・大手/ベンチャー10社以上と話した実感）。見分け方：
- 使えない：エージェントの都合で、希望に関係なく手持ち求人を投げてくるだけ
- 使える：希望に沿った提案／面接対策情報の提供／年収交渉／内定時期の交渉をやってくれる
- 多くは"入れそうな企業"を紹介するだけで転職者のキャリアは考えていない。キャリアアップしたいなら企業研究は自分でやる。当たりに当たるまで見切る前提で
🧩
コーディングテスト
LeetCode を解いた記録