PM1年でエンジニアに戻りたい人へ｜失ったものと戻り方

※この記事はPR（広告）を含みます。

コードを書かない日が続き、エンジニアとしての感覚が鈍った気がする。PMになって1年たち「戻りたい」と考え始めた人に向けて、失ったものの中身と戻り方、続ける場合の選び方を整理します。

PM1年目のエンジニアが戻りたいと感じる理由と、失ったものの正体

エンジニアからPMになると、1年で仕事の中身がこう変わる

エンジニアの仕事は「作る」ことでしたが、PMの仕事は「作れる状態をつくる」ことに変わります。成果物がコードから、計画・判断・合意に置き換わります。

• 複数案件の進捗と、先の計画を見る
• 予算と収支を管理する
• メンバーの成果物をレビューし、承認する
• 他部署や非エンジニアと要件を調整する
• 仕様書を書き、考慮漏れを潰す

毎日の手応えが「書いたコードが動いた」から「揉めずに決まった」に変わることが、戻りたい気持ちの出発点になっていると考えられます。

PM1年目で一番つらいのは、成果が見えにくく責任だけ増えること

PM1年目は、自分で手を動かせば早い作業を人に任せ、その結果に責任を持つ立場になります。予算の金額の大きさや、他部署からの横やりも同時に押し寄せます。

エンジニアとして得意だった「自分で直す」が、PMでは控えるべき行動に変わる点が、つらさの中心と考えられます。つらさの原因が仕事の型にあるのか、職種そのものにあるのかで、取るべき道は変わります。

PM1年で失ったものは「技術の更新」「手の速さ」「市場での見え方」の3つ

失ったものを3つに分けると、エンジニアに戻るときに何を取り戻せばよいかが具体的になります。一方で、PMの1年で得た調整・見積もり・優先順位づけの力は、どの道を選んでも残ります。

PM1年目のつらさは下げられる：戻りたい気持ちが進捗・予算・調整から来ている場合

複数案件の進捗は、エンジニアが書くチケットの書式を揃えて見る

案件が増えるほど、一人ひとりに聞いて回る進捗確認は回らなくなります。チケットの書式をチームで揃えると、読むだけで状況が分かる状態に近づきます。

• 目的（何のための作業か）
• 完了の条件
• 今の状態と、止まっている理由
• 次に判断が要る人と期日

認識のズレや情報の行き違いは、PMの注意力でなく、Wikiのルールとチケットの書式で防ぐ方が続きます。

予算の怖さとレビューの抱えすぎは、PMが任せる範囲を決めて減らす

元エンジニアのPMほど、コードレビューや承認を全部自分で見たくなります。それが詰まると、チーム全体の速度がPM一人の処理量で決まってしまいます。

• 設計の方針と、外部に影響する変更だけをPMが確認する
• 細かいコードレビューはメンバー同士に任せ、基準をWikiに書く
• 予算は案件ごとに、見積もりと実績の差を定期的に見る

• すべてのプルリクエストをPMが承認する
• 任せた作業を途中で自分が書き直す
• 予算の数字を締めの時期にまとめて初めて見る

任せる範囲を先に言葉にしておくと、レビューも予算も「全部見る」から「差だけ見る」に変わります。予算の金額も、工数と単価に分解して見れば、エンジニア時代の見積もりに近い扱いにできると考えられます。

非エンジニアとの調整と横やりは、PMが企画段階の承認の順番で防ぐ

想定外の部署から後で意見が入り手戻りになるのは、決める前に聞くべき人を飛ばした場合に起きやすいと考えられます。企画段階で、関係者の一覧と承認の順番を決めておきます。

調整の上手さは話術より、聞く順番を設計できるかで決まる部分が大きいと考えられます。

仕様の考慮漏れと「全部自分のせい」は、PM1年目の振り返りの型で減らす

エラー時の動きの書き漏れは、正常な流れだけを書いた仕様書で起きやすくなります。仕様書の雛形に、次の項目を最初から入れておきます。

• 入力が不正なとき
• 外部の仕組みが止まったとき
• 利用者が途中で操作をやめたとき

失敗を一人で抱え込むと、苛立ちが次の判断を鈍らせます。振り返りは「誰が」でなく「仕組みのどこで漏れたか」を書く欄で行うと、自分を責める流れを断ちやすくなります。

エンジニアに戻りたい人が、PM1年で失った技術を取り戻す方法

PMの1年で遅れるのは「書く力」より「今の標準」

1年コードを書かないと、文法を忘れるより先に、ライブラリの版や開発の手順の変化に遅れると考えられます。取り戻す対象は新しい言語を一から学ぶことより、自分の得意分野の1年分の差分です。

• 使っていた言語・フレームワークの主な更新
• テストやデプロイの手順の変化
• AIを使ったコーディング支援など、開発の進め方の変化

エンジニアの手の速さは、PMの業務の隣から戻す

いきなり大きな個人開発を始めるより、業務に近い小さな作業から手を戻す方が続けやすいと考えられます。業務に近いほど、職務経歴書に書ける実績にもなります。

• 進捗の集計や報告書づくりを、自分でスクリプト化する
• チームの軽い修正を引き受け、レビューを受ける側に回る
• 自分が仕様書を書いた機能の、テストコードを読む

レビューを「する側」から「受ける側」に一度戻ると、今の基準と自分のズレが具体的に分かります。

失ったものの学び直しは、会社任せにせずPM自身が時間を取る

IPAの調査では、従業員の学び直しに取り組む企業の割合は、米国企業の8割弱に対し日本企業は19.2%でした。会社が学び直しの場を用意してくれる前提では、PMの1年で失ったものは戻りにくいと考えられます。

一方、非先端IT領域の従事者で、学んだ先端スキルを社内で活かす機会が「ある」とした人は、ここ3年で約26%から約37%に増えました。学んだことを今の職場で使える余地は広がっている、という見方もできます。

エンジニアから相談されないPMにならないための技術の持ち方

PMに要る技術の知識は、自分で実装できる深さより、メンバーの説明と工数の妥当さを判断できる深さと考えられます。技術が分からないと見積もりの根拠を確かめられず、相談されない形だけのPMになりやすくなります。

分からないことを具体的に聞くPMほど、エンジニアから相談が戻ってきやすいと考えられます。

PM1年からエンジニアに戻りたい人は、採用でどう評価されるか

求人票で、PMの1年が効くエンジニア職を見分ける

求人票は、必須要件と歓迎要件を分けて読みます。PMの1年が評価されるかは、歓迎要件と職務内容の書き方で見分けられると考えられます。

• 必須要件：直近の開発経験や使用言語を、今の自分で満たせるか
• 歓迎要件：要件定義・顧客折衝・チームの推進など、PMの1年が当てはまる語があるか
• 職務内容：入社後の役割がコードを書く仕事か、調整が中心か

転職者が今の勤め先を選んだ一番の理由は「自分の技能・能力が活かせるから」が17.7%で最も多く、次いで「仕事の内容・職種に満足がいくから」が16.5%でした。エンジニアに戻る先も、技能が活かせるかと仕事の内容で選ぶ前提で探します。

職務経歴書では、PMの1年をエンジニアの技術判断として書き直す

「管理しました」とだけ書くと、開発から離れた1年に見えます。以下は架空の例文です。

「何を管理したか」でなく「どの技術判断に関わったか」を書くと、エンジニア採用の担当者に伝わりやすくなります。

戻りたい先で再びPMにされないか、労働条件で確かめる

戻りたい理由が「コードを書きたい」なら、変更の範囲の欄は求人票の職種名より重く見ます。

エンジニアとPMの年収の伸び方：戻りたい人が1年目で比べる数字

統計で見るエンジニア（ソフトウェア作成者）と上流職種の水準

賃金構造基本統計調査でPMを比べるなら、上流工程に近い「システムコンサルタント・設計者」が目安になると考えられます。

区分（令和7年賃金構造基本統計調査）	平均年齢	きまって支給する現金給与額（月）	年間賞与その他特別給与額
ソフトウェア作成者 25〜29歳	25〜29歳の層	33万2,100円	86万1,900円
ソフトウェア作成者 30〜34歳	30〜34歳の層	38万4,500円	98万1,200円
ソフトウェア作成者（役職者を除く）	34.7歳	36万1,600円	85万4,900円
ソフトウェア作成者（役職者を含む全体）	記載なし	39万800円	109万5,100円
システムコンサルタント・設計者（10人以上の企業）	38.3歳	54万2,100円	238万5,200円

上流職種の数字が高く見えても、平均年齢や条件が揃っていないので、PMを続ければ同じ額になるとは読めません。ソフトウェア作成者でも役職者を含むと月給・賞与とも高く、管理の役割を持つ道が収入の伸びにつながる面はあると考えられます。

業界全体の年収は、CareerBoost 年収データベースで目安をつかむ

CareerBoost 年収データベースに収録している上場企業826社のうち、情報・通信業は96社で、平均年収の中央値は約791万円、真ん中の半分は約682万〜923万円でした。同じ96社の平均年齢の中央値は38.7歳、平均勤続年数の中央値は9.2年です。

この数字は有価証券報告書の平均年間給与で、エンジニアだけの数字ではありません。営業や管理部門も含む会社全体の平均なので、次のように物差しとして使います。

• 応募先が上場企業なら、有価証券報告書の平均年間給与と平均年齢を見る
• 平均年齢が自分より高い会社は、平均年収も高めに出やすいと割り引いて読む

転職で賃金が上がった人・下がった人の割合

2024年の転職入職者の賃金変動は、25〜29歳で増加46.3%・減少29.2%、30〜34歳で増加46.1%・減少24.2%でした。この数字は、PMからエンジニアへの職種変更に限ったものではありません。

増えた人が多い一方で減った人も一定数いるため、エンジニアに戻る転職は年収だけで決めない前提を置きます。

エンジニアに戻る・PMを続ける・テックリードやEMの3択：PM1年目の判断基準

3つの道の違いを、PMの1年で失ったものの扱いで比べる

比べる点	エンジニアに戻る	PMを続ける	テックリード・EMなど兼ねる役割
日々の仕事	設計と実装	計画・予算・調整	技術判断とチームの運営
1年で失ったもの	取り戻す必要が大きい	戻さなくても仕事は回る	技術の判断力は戻す必要がある
合う「戻りたい」の理由	作ること自体が好き	つらさが仕事の型で減る	技術を手放したくないが調整も苦でない

両方を兼ねる役割は、PMの1年を無駄にせず、技術にも触れ続けたい人の受け皿になると考えられます。ただし、社内にその役割があるかは会社ごとに違います。

「戻りたい」の理由を分けると、エンジニアかPMかの答えが出る

• 戻りたい理由が「コードを書きたい」か「PMのつらさから離れたい」か、言葉にできる
• この記事の前半の、進捗・レビュー・調整の改善を一度試した
• PMの1年で遅れた技術の差分を、項目で書き出せる
• 社内でテックリードなどの役割に移れるか、上司に聞いた

確認リストで「コードを書きたい」がはっきりしたなら、エンジニアに戻る準備を始める段階です。

PM1年からエンジニアに戻りたい人に合う転職支援・合わない人

エンジニアに戻る転職を考えるなら、20〜30代のエンジニア経験者を対象にした転職支援として、明光キャリアパートナーズがあります。明光ネットワークジャパンのグループ会社が運営し、大手からスタートアップまで幅広い会社の紹介実績があります。

このサービスが合う人は次のとおりです。

• 20〜30代で、PMになる前にエンジニアとして開発経験がある人
• 経験・希望・価値観に沿って、戻る先の業種や会社の提案を受けたい人
• PMの1年をどう説明するか、履歴書や面接対策まで支援を受けたい人

合わない人と、その場合の進め方は次のとおりです。

• エンジニアの開発経験がない人：対象外です。まず社内で開発の仕事に携わる道を上司に相談します
• 40代以上の人：対象外です。年齢を限定しない転職サービスや、社内の異動制度を先に当たります

経験と希望を伝えたうえで、戻る先の提案と面接の準備をまとめて受けたい人に向いています。

PM1年目でエンジニアに戻りたい人のよくある質問

迷いやすい点を、PMの1年と失ったものの観点でまとめます。

PM1年目のエンジニアが、戻りたい気持ちを決断に変える次の一歩

失ったものを取り戻す計画を、PMの仕事と並べて書く

計画はPMの業務と同じ書式で書くと、忙しい時期にも止まりにくくなります。

PMの1年を「失った時間」でなく、エンジニアとして持ち帰る経験にする

どの道を選んでも、PMの1年で身についた調整と見積もりの力は消えません。失ったものだけを数えず、取り戻す分と持ち帰る分を分けて書き出すと、戻るかどうかを決める材料がそろいます。

執筆・編集：CareerBoost 編集部（運営：合同会社Radineer）／更新日：2026年10月15日