退職エントリ：HR業界を離れるにあたって
Published on 2026年3月27日
キャリアはじめに
2026年2月末をもって、HR業界を退職します。2023年1月に入社してweb制作から入り、自社のペット事業プロダクト、HRテック領域のSaaSプロダクト開発に携わってきました。
この退職エントリは、自分がやってきたことの棚卸しと、なぜ次に進むのかの言語化、そして転職活動を通じて気づいたことの記録として書いています。読んでくださる方が、エンジニアとしてのキャリア設計や転職活動のヒントを得られれば幸いです。
やってきたこと
国家公務員からエンジニアへ
エンジニアとしてのキャリアは少し異色かもしれません。前職は国家公務員で、統計調査の集計システム開発や統計の調査部隊として約4年8ヶ月従事していました。VB.NETを使った全国集計システムの開発・保守、Excelマクロによる業務効率化ツールの作成が主な業務でした。
やりがいはあったものの、自分の仕事がユーザーの生活をどう変えているのか、実感が持てなかった。 数百万件規模のデータを処理する集計システムを扱いながら、そのデータを活用する「ユーザーの顔」が見えない。エンドユーザーへのインパクトが実感できない環境に、徐々に限界を感じていきました。
「ユーザーの課題解決に一番近い場所で働きたい」——その一心で、独学でPHPを使い業務管理システムをフルスクラッチで作成しました。アーキテクチャ設計はオライリー本でOOPを体系的に学び直し、「動くコードを書く」から「設計できるエンジニアになる」への意識転換を果たして、2023年1月に現職へ飛び込みました。
現職での3年間
未経験Webエンジニアとしてコーダーからスタートし、採用支援SaaSのプロダクト開発チームに所属。フロントエンドを主軸としたフルスタックエンジニアとして働きました。
入社当初からプロダクトチームは存在していましたが、社内の組織再編でエンジニアが他部署へ異動・退職し、チームはほぼゼロリセットの状態に。PO・スクラムマスター・UIUXデザイナー・エンジニア2名という小所帯で再始動することになりました。
人数が少ない分、一人ひとりの影響範囲は広い。「技術」と「組織」の両面で基盤を作ることに没頭した日々でした。
チーム文化 ── 技術を超えた貢献
個人的に最も誇りに思っているのは、チーム文化です。
毎週のLT会： 火曜日の夕方、4〜5人で各10〜15分のライトニングトークです。その週に学んだこと、気づいたことを共有する場としてマネージャーを中心に立ち上がりました。最初は「発表のネタがない」という声もありましたが、「完成した知識でなくていい、学習途中でいい」など完璧なものを求めず、今行なっていることを常にアウトプットすることが当たり前な状態となりました。私が退職する最後のKTは7７回目を迎えます。この継続的なアウトっぷとの習慣が、チームの知識共有の土台になっていると感じています。
実装方針の明文化： 「なぜこの設計にしたのか」「どういう背景でこの実装になっているか」を言語化し、ドキュメントとSlackに残す習慣を作りました。属人化を防ぐだけでなく、新メンバーが「なぜ」を理解した上でコードを触れるようになることが目的でした。
議論におけるチームのスタンス： 「誰が悪いか」ではなく「どこに構造的な課題があるか」を問うこと。HRT（Humility, Respect, Trust）を前提に、個人の糾弾ではなくチームとしての改善にフォーカスする。このスタンスをチームで共通認識として持つことで、プロダクトに対する議論の場では誰もが率直に意見を言える状態を作れました。
新メンバーの伴走 ── 暗黙知を言語化する
チームのエンジニアが2名から6名に拡大する中で、新メンバーのオンボーディングに力を入れました。
あるスプリントで、新しくジョインしたジュニアメンバーがバックエンドの実装方針を決められず停滞していました。原因を掘り下げると、既存のドメインロジックや過去の設計経緯を把握しておらず、「どこまで既存仕様を踏襲すべきか」の判断基準がなかったことが分かりました。
すぐにペアプロを実施。単にコードを一緒に書くだけでなく、「この設計にした背景」「過去にこういう議論があってこう決まった」という判断基準を言語化して伝えました。 その後、彼は同様の判断を自分で下せるようになり、チームとしての開発速度も維持できました。
判断基準を言語化し、チームに再現可能な形で残す——これがスクラム体制で45スプリント連続で成果物を落とさず達成できた要因だと考えています。コードを書く速さより、判断の仕組みを整えることが、チームのスループットを最大化すると確信した経験でした。
副業での挑戦 ── 複数の環境で自分を検証する
本業と並行して、副業にも積極的に取り組みました。
クラウドファンディングサービスの0→1立ち上げ： ヒアリングから要件定義、実装、保守運用まで一貫して対応。プロダクトチームとしての動き方ではなく、一人でビジネスサイドと直接向き合いながら「何を作るか」から考える経験は、本業との大きな違いを実感させてくれました。
AIエージェント開発： MCP（Model Context Protocol）を用いたチャットベースのマーケティング支援ツール開発に参画。最新のAIスタックを実務レベルで動かし、「AI活用」を概念ではなく実装として理解できたことは、転職活動でも評価されたポイントでした。
副業を通じて確認したかったのは、**「自分は特定の環境でしか機能しないのか、それとも異なる環境やフェーズでも価値を発揮できるのか」**ということ。0→1の立ち上げ、既存サービスへの参画、AI領域の新規開発——異なるコンテキストで自走できたことは、「自分の強みは環境依存ではない」という確信につながりました。
なぜ辞めるのか
プロダクト部署の凍結になりました。
プロダクトで成果を出し切る前に、この判断が入ったことに悔しさがあります。 フルリプレイスで基盤を整え、チーム文化を醸成し、これからが本番だという矢先でした。スプリント45回分の積み上げ、75回のLT会——それらが続く先にあったはずの「プロダクトとしての成果」を出せなかったことは、今でも残念に思っています。
ただ、この経験があったからこそ、次に何を求めるのかが明確になりました。
「プロダクト開発に向き合える環境で、ユーザーの課題解決に貢献したい」——公務員時代から一貫しているこの軸に加えて、「リードとして責任を負い、プロダクトで成果を出し切る」という次のステップが見えています。
転職活動の記録
利用したサービス・チャネル
- Findy / 転職ドラフト：スカウト経由でのアプローチ。GitHubの草やポートフォリオを見てのスカウトが多く、技術的な文脈での会話からスタートできる点が良かった
- 直接スカウト：SNSや技術コミュニティ経由でのCTO・役員からの直接コンタクト。面接というより「壁打ち」に近い対話で、自分の市場価値を客観視する機会になった
転職活動の軸
一貫して掲げたのは、**「愚直に積み上げた。次はリードとして責任を負う。」**という決意です。
この軸を証明するファクトとして、技術書15冊以上の読破、フルリプレイスの設計主導、チーム文化の醸成、新メンバーの伴走、そして副業での複数環境（0→1、AI領域）の経験を、各社のフェーズ・コンテキストに合わせて翻訳して提示しました。
転職活動を貫いた一つの考え方：構造化
振り返ると、この転職活動を通じて自分が一貫してやっていたことは、**「構造化」**という一言に集約されます。
エンジニアとしての仕事でも、面談の場でも、自己理解の過程でも——どの局面でも、混沌とした情報に境界線を引き、関係性を整理し、再現可能な形に落とすという行為を繰り返していました。
構造化には3つの層がありました。
① 技術・設計の構造化：コードやシステムに責務の境界線を引くこと。変更コストを最小化し、将来の拡張に耐えられる設計にすること。この思想はプロダクト開発での判断の基軸になっていました。
② 自分が話す内容の構造化：自分の経験を「点（事実）」ではなく「線（再現性）」として整理すること。エピソードを結論・背景・学びの30秒構造に落とし込み、「どの企業のどのフェーズに刺さるか」をマトリクスで管理する。準備が構造化されるほど、場の空気を読む余裕が生まれました。
③ 採用面接というフィールドの構造化：面談を感覚で乗り越えようとするのではなく、「各タイプの面談で企業が何を問うているか」「相手がどの階層（経営・設計・実装）の話をしたいのか」を事前に定義すること。フィールドの構造を把握することで、その場でどう振る舞うべきかの判断が速くなりました。
この3つの層は、実は同じ思考回路から生まれています。普段の設計で「このコンポーネントはどの責務を持つべきか」と問うように、面談でも「今この場で相手は何を問うているか」を定義してから動く。構造化の習慣が、技術以外のフィールドにも自然に転用されていました。
面談に臨む前に：採用選考フィールドの構造化
準備を進める中で気づいたのは、エピソードの磨き込みより先にやるべきことがあるということでした。採用選考というフィールド自体を構造化し、「そもそも何が起きている場なのか」を定義することです。
採用選考の本質を一言で定義すると、**「企業に『この人が必要だ』と思わせるプロセス」**です。そして「必要」の基準は、常に事業成長につながるかどうかです。
この定義から導かれる行動原則はシンプルでした。「自分が何をしたか」ではなく、「企業にとってどう価値があるか」を語ること。同じ経験でも、相手のコンテキストに接続して翻訳する。「私は〇〇をしました」ではなく、「御社の△△に対して、私の〇〇が活かせます」という構造で話す。フィールドを構造化するとは、ルールを把握した上でプレイすることです。
面談タイプの構造化：各場で何が問われているかを定義する
面談には種類があり、それぞれ企業側が問うていることが異なります。これを混同して話すと、良い経験を持っていても「刺さらない」状態になります。各タイプを定義し、それに合わせた回答の粒度と戦略を事前に設計しました。
カジュアル面談は「足切り」ではなく「相互理解」の場です。企業側の問いは「この人と選考に進みたいか？」です。よほどのミスマッチがない限り次には進める一方で、「この人と話したい」と思わせないと優先度が下がります。ここでやるべきことは全部話すことではなく、フックを作ることです。概要を伝えて「詳しくお話ししましょうか？」と引き出す余白を作る。相手の関心がどこにあるかを読む場でもあります。
1次面接では「この人は戦力になるか？」が問われます。技術力、再現性、思考プロセス、自走力が見られる。ここでは「私が」を主語にして、過去の実績を自社でも再現できるという確信を与える必要があります。回答の粒度は「結論→具体的な事実→なぜそうしたか」の順です。
2次面接になると問いが変わります。「この人を仲間にしたいか？」です。カルチャーフィット、覚悟、ビジョン、成長可能性が焦点になる。「なぜここで、何を成し遂げたいか」を自分の言葉で、覚悟を持って語る場です。「この会社でなければならない理由」を示せるかどうかが、ここでの勝負になります。
話す内容の構造化：経験を再現性のある能力に変える
面談の失敗を「落ちた」ではなく、**「インターフェースの不整合」**として捉え直す。録音を聞き返し、どこで相手の期待と自分の出力がずれていたかをデバッグするように分析しました。
最初の1次面談不通過の本質は、自分のデータを全件返却していたことでした。相手のAPI仕様（求めている情報の粒度や抽象度）を確認せず、持ちネタを全部話してしまっていた。これはエンジニアリングでいえば、インターフェースの定義なしにデータを渡し続けている状態です。
この気づきから、話す内容の構造化を3つの軸で設計しました。
① 30秒プロトコルの導入：出力情報の過不足を「結論（10s）→背景（10s）→学び（10s）」の構造で制御する。コンポーネントの責務を明確にするように、回答の責務を明確にする。
② 企業フェーズ別の翻訳：同じ経験も、0→1フェーズと1→10フェーズでは伝えるべき側面が異なる。「どのフェーズのどの文脈に刺さるか」をマトリクスとして持ち、接続先を変えて出力する。
③ パケット交換の習慣：最初の1分で軽い質問を投げ、相手が「経営・設計・実装」のどの階層の話をしたいのかを確認してから本題に入る。インターフェースを先に握ってからデータを渡す。
各エピソードの「学び」の部分には、**「次の現場でも使える判断基準」**を明示的に入れることを徹底しました。面接官が知りたいのは過去の事実ではなく、その人が同じ状況に置かれたとき再現できるかどうかです。経験を「点」ではなく「線」として整理することが、構造化の核心でした。
場に応じたインターフェースの最適化
相手の求める情報の粒度を察し、伝える情報を動的に最適化する。これはエンジニアリングにおけるインターフェース設計そのものだと気づきました。
- カジュアル面談：30秒〜1分で「フック」を作る。概要を伝え、詳細は相手の関心に応じて引き出す。「全部話そう」とすると相手の興味を読めなくなる
- 技術面談（STAR法の徹底）：冗長さを排除し、**結論（10s）→ 背景（10s）→ 成果/学び（10s）**の30秒構造で最短距離で本質を伝える。準備しすぎたエピソードを「全部話す」より、相手が知りたい部分に集中して深堀りできるほうが印象が良い
具体的には、各エピソードをSTAR形式で事前に整理しておき、「どの会社のどのフェーズに刺さるか」のマトリクスを作っていました。準備が多いほど、場の空気を読む余裕が生まれます。
エピソードを「再現性のある能力」に変える
準備の過程で、自分の経験を「点（事実）」ではなく「線（再現性）」として整理し直しました。各エピソードをSTAR形式でストックしておき、「どの会社のどのフェーズに刺さるか」をマトリクスとして持っておく。準備の量が増えるほど、場の空気を読む余裕が生まれます。
特に意識したのは、各エピソードの「学び」の部分に**「次の現場でも使える判断基準」**を明示的に入れることでした。面接官が知りたいのは過去の事実ではなく、その人が同じ状況に置かれたとき再現できるかどうかです。
抽象と具体の使い分け：相手に応じた出力の動的最適化
構造化のもう一つの応用が、抽象と具体の動的な切り替えです。
抽象を理解できる人は具体も理解できますが、具体しか見ない人に抽象から入ると伝わりません。そのため、まず具体から入り、相手の反応を見て調整するという流れを徹底しました。相手の求める情報の粒度を察し、出力を動的に最適化する——これはエンジニアリングにおけるレスポンス設計そのものです。
設計の話に相手が前のめりになれば抽象度を上げる。反応が薄ければ具体に留める。この調整ができるようになってから、面談の手応えが変わりました。逆に言えば、設計の話が全く刺さらない場合は「自分の強みが活きない環境かもしれない」という見極めの指標にもなります。
逆質問も同じ原則で設計しました。質問だけするのではなく、「認識の提示→必要な要素の提案→質問」という構造で、自分の考えを持った上で議論できる人間であることを示すことを意識しました。
コミュニケーションの原則として持ち続けたこと
戦略を整理する中で、全ての面談に共通する原則として4つを言語化しました。
具体から入ること、結論ファーストで話すこと、相手の反応を見て一方的に話し続けないこと、そして軸を一貫させること。特に軸のブレは不信感に直結するため、「なぜ転職するのか」「何を大切にしているのか」のコアは面談を重ねるほど磨き込みました。
面談を通じて学んだこと：評価基準のフレームワークを構築する
今回の転職活動は、順風満帆なスタートではありませんでした。しかし、初期の失敗を徹底的に分析したことが、結果としてエンジニアとしての視座を大きく変えてくれました。
最初に受けた1次面談で落ちました。録音を聞き返して気づいたのは、**「企業が求めている像と、自分の回答の抽象度にズレがあった」**ことです。私は設計の重要性や長期的なアーキテクチャ判断を語っていましたが、当時の現場が求めていたのは「具体的な実装スピード」と「明日使えるスキルセット」でした。
「良いエンジニア」の正解は企業のフェーズによって変わる——この当たり前のことを、身をもって痛感しました。これを機に、相手がどの階層の課題を解決したいのかを察知し、自分の強みをそのコンテキストに合わせて翻訳して伝える訓練を繰り返しました。
客観的に捉えた「市場価値」と「伸び代」
多くのCEOやCTOとの対話（壁打ち）を経て、自分の現在地を再定義できました。
高く評価された点：
- 経験年数以上の視座：実装の裏にある事業成長を語れる点。エンジニア以外の経験が思考に幅を与えているという評価もあった
- 事業視点での質問力：収益構造やプロダクトビジョンから技術のあり方を逆算する姿勢
- AI活用の実践知：最新技術を実務レベルで議論できる点。「知っている」と「動かせる」の差は、対話の深さで明らかになる
明確になった課題：
- 定量的成果の言語化：定性的な改善を定量化して語る力。次の環境で意識的に身につけていきたい
- リーダーシップの責任：チームを動かすリード的な動きはしてきたが、正式な職責としての責任を背負った経験はなかった
「失敗経験」の昇華
転職活動を通じて気づいたのは、失敗経験をどう語るかで評価が大きく変わるということです。大切なのは「何を失敗したか」ではなく、「その後どう動いたか」と「再発防止をどう仕組み化したか」です。ミスをしない人間を演じるより、ミスを仕組みで防げる人間であることを示すほうが、リード候補としての信頼につながりました。
市場価値の再定義：異色な経歴の翻訳
エンジニア以外のキャリアをどう説明するか、最初は悩みました。しかし整理していくと、過去の経験が現在の設計思想に直結していることに気づきました。異色に見える経歴も、「なぜ今の自分がこの判断をするのか」という根拠になる。そう捉え直してから、面談での自己紹介の説得力が変わりました。
最終的な気づき
多くのCTO・CEOとの対話を経て、最後に残った課題は技術でも設計でもありませんでした。
「足りないのはスキルではない。意思決定の結果に責任を持つ『重さ』の経験だ」
このメタ認知を言語化できたことが、リードエンジニアとして挑戦する強い動機となりました。そして、その認識を面談の場で正直に話せたことが、次のステージへの扉を開いてくれたと思っています。
思えば、この転職活動そのものが「構造化」の実践でした。自分の経験を構造化し、面談というフィールドを構造化し、相手の文脈に合わせて出力を最適化する。普段のエンジニアリングでやっていることを、採用という別のフィールドで再現した——そう振り返ると、活動を通じて得た学びは、次の現場でも同じように使えると確信しています。
次について
次の環境では、プロダクト開発者として、ビジネスサイドと交流しながら意思決定に関わることを目指します。
現職では、プロダクトチーム内での技術的な意思決定には関わっていましたが、ビジネス側の意思決定に関わる機会は限られていました。「この機能を作ることで、どのKPIに貢献するのか」「今の開発コストは事業的に正当化されるか」——こうした問いを日常的に立てられる環境で経験を積みたいと考えています。
技術的に正しいだけでなく、事業として正しい判断ができるエンジニアになりたい。
短期的（1〜2年） には、リーダーとして意思決定の責任を正式に負える立場を目指します。現職でもチームの判断基準を作り、新メンバーの自走を支援する動きはしてきましたが、正式な責任を持つ立場ではなかった。責任の重さが変わることで、自分の意思決定の解像度も上がると考えています。
中長期的（3〜5年） には、エンジニアリングマネージャーを目指しています。技術を極める方向よりも、チーム全体の成果を最大化する仕組みを作ることに関心があります。判断基準の明文化、オンボーディングの整備、心理的安全性の確保——メンバーが成果を出しやすい環境を構築したい。自分の強みである「チームを自走させる力」を、より大きなスケールで発揮したいと考えています。
エンジニアリングマネージャーを志すのは、「管理職になりたい」からではありません。現職の3年間で実感したのは、個人の技術力よりも「チームの仕組み」の方が、プロダクトの成果に対する影響が大きいということです。75回のLT会、45スプリントの継続、新メンバーの自走——これらはすべて「仕組み」の力でした。この力をもっと大きなスケールで発揮したい。
おわりに
未経験からの3年間は、エンジニアとしての土台を築いた期間でした。
未経験からWeb業界に飛び込み、設計を学び、チーム文化を作り、新メンバーを育て、副業で自分を検証し、AIの波にも乗る—— **「愚直に積み上げた」**という言葉に嘘はありません。
マネージャーには特に感謝しています。退職時に贈ってくれた言葉が印象に残っています。
「許可を求めるな、謝罪せよ」を大事にしてください。皆さんはこれからより高みを目指していきます。それはきっとスキル面において私よりも先にいくことになります。その時に意思決定者が理解できていない、わからない時に許可を求めるとどうなるか。多くの場合はわからないから怖いから拒絶をします。でもそれをやる価値を知っているのは最前線でフルコミットしている皆さんだけです。やってうまくいけばいいし、やってだめだったら何事もない状態にリカバリーすればいい。
見るべきは社内の人間の顔ではない。HRTをもとに、ユーザーの顔を見て仕事をしろ。
プロダクトには人格があります。その人格を形成しているのは我々です。この一面では寄り添ってくれるが、この一面では自己中で邪悪な人と仕事をしたいですか。ユーザーは気づきます。黙って離れて愛想を尽かされます。ユーザーは賢いです。ただプロダクトを作るだけではなく、ユーザーに向き合いたいですね。プロダクトの人格も作り、常に誰かに必要とされているプロダクトでありたいです。そして継続的にプロダクトを通して誰かを幸せにしているチームでありたいですね。
この言葉が示してくれたからこそ、自分もその志を強く受け継ぐことができました。チームメンバー全員が、プロダクトに対して熱を持って向き合っていた。あの環境で働けたことは、自分のキャリアの中で大きな財産です。
プロダクトで成果を出し切れなかった悔しさは残っています。だからこそ、次の環境では必ずやり切る。
「愚直に積み上げた。次はリードとして責任を負う。」
この軸はブレません。
ここまで読んでいただき、ありがとうございました。