はじめに
こんにちは。ぷーじ（@yug1224）です。
最近、Dress Code株式会社に転職し、5年ぶりにEMからICへ戻ったので、その決断の背景と現在の状況を共有します！
ちなみに転職活動の話はこちらのPodcastでもしているので、良かったら聞いてみてください！
https://creators.spotify.com/pod/profile/chijonohoshi/episodes/17-500AI-e356fif/a-ac1m01o
なぜEMからICへ戻ろうと思ったのか？
これまで経験してきた会社は規模の大きい会社も多く、もともといつかはアーリーのスタートアップに挑戦したいと思っていました。しかし、実際に自分で手を動かす開発の現場からはしばらく遠ざかっていたため、その夢は諦めかけていました。
そんな中、AIの登場とVibe Codingの流行があり、AIの伴走があればブランクがある自分でもまたICに戻れるのではと考えたのがきっかけです。AIの登場によって、EMからICへの復帰のハードルが大幅に下がったと実感しています。
マネージャー時代に得たもの・失ったもの
得たもの：抽象的な問題解決力
マネージャーとして数十人のメンバーをマネジメントし、抽象的な問題の分析、課題設定、解決策の計画立案と実行推進を行いました。中長期的な視点で理想から逆算し、今何をすべきかを考える力を養いました。
また、技術戦略の策定や開発文化の醸成を通じて、プロダクト思考やビジネス理解、組織開発の経験も得ることができました。
失ったもの：エンジニアとしての腕力
一方で、個人開発は続けていたものの、業務で最新技術を扱う機会がなくなったため、エンジニアとしての腕力が衰えている不安は常にありました。
マネージャー業務に時間を取られ、コーディング時間が激減したことで、最新技術への深い理解が不足していると感じていました。
大規模プロジェクト管理から小規模チームでの実践へ
プロジェクトマネージャー時代の大規模プロジェクト経験
プロジェクトマネージャー時代には、複数のサービスを統合する大規模プロジェクトを担当しました。フロントエンドチームだけで最大700人月規模のプロジェクトで、チームリーダーとして品質管理と実行推進を担いました。
最大25名に増えたフロントエンドチームには、大規模開発の経験が浅いメンバーも多かったです。スキル差の大きいチームを安定して率いるため、方式設計書を事前に作成し、勉強会を開き、メンバーのスキルに合わせてタスクを分割しました。
抽象度の高い問題は粒度を細かくしながら進め、タスクが切り替わる際には必ず計画を見直しました。その結果、遅延も不具合もほぼなく完遂できました。
現在の小規模チームでの活かし方
現職は社員数約20名、開発メンバー8名の小規模チームです。要件定義から運用保守まで、すべての開発工程を担当する必要があります。
私も入社1か月で、不具合対応から本番環境での作業、ドメインモデリング、バックエンド・フロントエンド開発まで幅広く担当しました。
また、チームにはマネージャーが存在しないため、各自がセルフマネジメントを求められる環境です。大規模プロジェクトで培った計画立案と実行推進のスキルは、個人レベルでのタスク管理や品質保証にも活かせると考えています。
技術広報・採用活動の経験を活かす
エンジニアリングマネージャー時代の技術広報・採用活動
エンジニアリングマネージャー時代には、認知拡大・業界貢献・人材育成・採用強化の4軸を目的とした技術広報活動を推進していました。
技術広報では、勉強会やLT会を企画運営し、テックブログの執筆を支援しました。エンジニアのアウトプットを促し、個人の成長を最優先に考え、それが会社の認知度向上や業界貢献、そして最終的な採用に繋がるように活動していました。
エンジニア採用では、カジュアル面談・面接・オファー面談等を担当し、2024年度は年間300件以上の面談・面接を実施しました。CTOや人事とともに、採用戦略の立案から実際の面接まで、一貫した採用活動を経験しました。
技術広報・採用活動での経験活用
SRE NEXT 2025のブース運営の様子
技術広報や採用活動も全員でやっており、自分も入社直後からカンファレンスのブース運営にも参加しました！
イベントの企画・運営や、技術記事の執筆支援、採用活動の戦略立案など、マネージャー時代に培ったスキルは今後も活かせると感じています！
開発現場に戻って実感したこと
開発現場への復帰
開発現場に戻ると、想定以上に時間がかかり、エンジニアとしての腕が鈍っていることを痛感しました。全盛期の3分の1程度の速度しか出せない悔しさを感じつつも、AIの力でなんとか食らいついています。
開発現場に復帰してみて、マネージャーとICで脳の使い方が異なることに気付きました。
マネージャー時代は、日々発生する問題をひたすら捌き続けていたので、低トルク・高回転数のエンジンのような使い方でした。ICに戻ってみると、さまざまな工程のタスクを順序良くじっくり積み上げていくので、高トルク・低回転数のエンジンのような使い方です。
どちらもゴールから逆算して計画する点は同じですが、それ以外の思考プロセスが異なるため、ICとしての感覚を取り戻すのに苦労しています。
現在はまだ低トルク・低回転の状態なので、一刻も早く高トルクに上げて馬力を取り戻したいです。
AIを活用した開発現場への復帰
キャッチアップの効率化
既存の設計や実装を理解する際は、Notion AIやCursorに問いかけることで簡潔なまとめを得られます。そのため、チームメンバーに常に付き添ってもらう必要がなく、効率的にキャッチアップを進められています。
AIの助けがあれば、以前は数ヶ月かかっていたキャッチアップが数日で完了することもあるでしょう。 AIやVibe Codingの登場が、開発現場への復帰のハードルを劇的に下げたと実感しています。
マネジメントスキルを活かしたAI活用
開発タスクについても、マネージャーがメンバーにタスクを指示するようにAIに指示を出せば、AIが変更内容を報告しながらタスクを進めてくれます。最新のフレームワークについての理解が深くなくても、担当の開発タスクを進めることができています。
いきなり抽象的な指示をするのではなく、まずはプランニングから指示したり、タスクを細かく指示し、進捗を確認しながら進めています。これはマネジメントとほぼ同じなので、苦もなく対応できました。
ブランクがあるとはいえ土台となる知識や経験はある程度あったため、最新のフレームワークや言語の記法、このプロジェクトでのお作法を教えてもらうことに集中できました。ゼロから一人でキャッチアップするよりは格段にスムーズでした。
設計から実装まで一貫したAI活用
設計から実装まで一貫したAI活用のワークフローを実現できました。ドメインモデリングではPlantUMLをAIと対話しながら作成し、そこからPrismaのスキーマを生成してもらいました。APIの実装は要件と参考実装を伝えて進め、UIの実装にはFigma MCPを活用しました。APIの繋ぎこみはOpenAPIのスキーマ定義をもとに実装し、Playwright MCPで動作確認と修正を行っています。
Figma MCPを利用した具体的な開発事例については、チームメンバーがまとめているので、下記記事もぜひご覧ください！
https://zenn.dev/dress_code/articles/0d3e40682ab015
これからのキャリアについて
AI時代のキャリア戦略
今後はさらにAIを利用した開発が当たり前になっていくと考えると、実際に自分も業務経験を積むことができて良かったです。
AIを活用して開発するエンジニアは、同様の経験を持つマネージャーからの指導を望むようになると思うので、この経験は、将来マネージャー職に復帰する際にも活かせると考えています。
EMからICへ戻ることを考えている人へ
Vibe Codingが登場する前は、ICに戻るのは難しいと諦めていましたが、今なら戻ることができます！ もしICに戻るか悩んでいる方がいれば、ぜひ挑戦してほしいです！
本記事が、同じような経験をされている方や、これから挑戦しようとしている方の参考になれば嬉しいです。ごきげんにいきましょう！
おまけ：このブログもVibe Codingで書いた
CursorでVibe Codingしながら記事を書いている様子
この記事の執筆プロセス自体も、Vibe Codingの実践例でした。
良いアウトプットには事前準備と計画が不可欠です。そこで、職歴などをマークダウンにまとめ、先立ってアウトラインを決めました。
しかし、職歴だけでは情報が少なく、何もないところから文章を書きだすとハルシネーションが発生するため、AIにインタビューしてもらう形式で情報を補完し、文章に落とし込んでいます。
具体的には、「EMからICに戻った理由を詳しく教えてください」「マネージャー時代の経験で、ICとして活かせていることは何ですか？」「Vibe Codingで助けられた具体的な場面はありますか？」といった質問をAIから投げかけてもらい、その回答をもとに文章を構成してもらいました。
