金融機関SEからPMへの転身 — 「作る人」から「作らせる仕組みを設計する人」へ

「自分はコードを書く方が得意で、マネジメントには向いていないと思うんですが」。金融機関のシステムエンジニアの方から、こう相談されることがよくあります。率直に言うと、この悩みは非常によく分かります。しかし、PMというのはマネジメント適性を新たに獲得する仕事ではなく、これまで培ってきた技術理解を土台に、役割を一段階拡張する仕事だと僕は捉えています。

0. 前提 — PMは「技術を手放す仕事」ではない

誤解がないように申し上げると、PMへの転身は技術力を手放すことを意味しません。むしろ金融機関のプロジェクトでは、技術的な妥当性を判断できるPMの方が、ベンダーとの折衝や仕様調整において圧倒的に強い立場に立てます。技術を「自分で書く」から「正しく判断する」に役割を変える、というのが実態に近い表現です。

1. SEの経験がPM実務にそのまま活きる3つの場面

1-1. 要件定義。エンジニアとして要件の実現可能性を見極めてきた経験は、PMとしてスコープを適切に管理する力に直結します。

1-2. 進捗管理。開発の工程を理解しているからこそ、現実的なスケジュールを引き、遅延の予兆を早期に察知できます。

1-3. 関係者調整。ベンダーや他部門とのやり取りを重ねてきた経験は、規模が大きくなっても本質的には同じスキルの延長線上にあります。

2. 転身の壁は技術力ではなく「意思決定の引き受け方」

僕が多くのSE出身者と面談してきて感じるのは、転身の本当の壁は技術力ではなく、意思決定と説明責任を引き受けることへの心理的なハードルだということです。エンジニアとして正しい実装を追求する姿勢と、PMとして「今ある情報で最善の判断を下し、結果に責任を持つ」姿勢は、求められる思考の型が異なります。

2-1. 完璧な情報が揃うまで判断を保留する癖がある方は、PMに転じた直後にこの壁にぶつかりやすい傾向があります。

2-2. 一方で、限られた情報の中でも「今はこう判断する」と決めて前に進める経験を積んできた方は、比較的スムーズに移行できています。

3. 転身のための3ステップ

3-1. 小さな範囲からPM的な役割を経験する。チーム内のサブリーダー、機能単位の進行管理など、公式な肩書がなくても実質的にPMの動きをする機会を作ります。

3-2. 数字で語れる実績を作る。担当した機能のリリース遅延をどう防いだか、テスト工程をどう効率化したかなど、定量的に語れる経験を意識的に積みます。

3-3. 職務経歴書を「実装した機能」ではなく「動かしたプロジェクト」の観点で書き直します。

4. コラム — 勘定系エンジニアから、刷新プロジェクトのPMへ

僕が面談した30代後半の男性は、証券会社のシステム子会社で8年、勘定系システムの開発エンジニアとして働いてきた方でした。ある大型リプレースプロジェクトで、彼はチーム内のサブリーダーとして進捗管理を任されたことをきっかけに、「自分は開発よりも、全体を見て調整する仕事の方が向いているかもしれない」と感じ始めたそうです。

転職活動では、当初「開発経験しかないので」と不安を口にしていましたが、実際にはサブリーダーとしてベンダーとの仕様調整や、テスト工程の遅延対応を主導していた実績があり、これを職務経歴書で「プロジェクト推進実績」として整理し直したところ、複数の金融機関のシステム子会社から勘定系刷新PMのポジションでオファーを受けることができました。

彼が語っていた言葉が印象的でした。「コードを書かなくなったわけじゃなくて、書く人をどう動かすかを考えるようになっただけなんです」。この視点の転換こそが、SEからPMへの転身の本質だと僕は考えています。

5. 面接で伝えるべき「技術理解」の価値

SE出身者がPM面接で語るべきなのは、単に「開発経験があります」ということではありません。技術的な妥当性を理解しているからこそ、ベンダーの見積もりや提案の是非を適切に判断できる、という具体的な価値です。ここを丁寧に伝えられると、「技術がわかるPM」としての希少性が評価されやすくなります。

5-1. マネジメント未経験でも応募できる求人の見分け方

求人票を見る際、「マネジメント経験◯年以上必須」という条件が明記されている場合でも、実質的にはサブリーダー的な経験があれば応募可能なケースが少なくありません。特に、勘定系刷新のような大型プロジェクトでは、経験豊富なPMそのものが不足しているため、「技術がわかり、全体を見る意欲がある人」を育成前提で採用する求人も存在します。応募前に、求人票の文言だけで諦めず、エージェント等を通じて実質的な採用基準を確認することをお勧めします。

6. PMへの転身後、最初の半年で意識すべきこと

6-1. 自分でコードを書きたくなる衝動を抑え、チームメンバーに任せる練習をする。

6-2. 「分からないことは分からない」と正直に言い、周囲の知見を借りる姿勢を持つ。

6-3. 進捗の報告を「順調です」で終わらせず、リスクの兆候を具体的に共有する習慣をつける。

6-1. 転身後にぶつかりやすい「評価軸の変化」への戸惑い

SEからPMに転身した直後、多くの方が戸惑うのが評価軸の変化です。エンジニアとして評価されていたのは、コードの品質やバグの少なさといった「作ったものの正しさ」でした。PMとして評価されるのは、プロジェクト全体が期限内に、想定した品質で完了したかという「動かした結果の正しさ」です。この評価軸の違いに慣れるまで、最初の数ヶ月は自分の仕事の価値を実感しにくいと感じる方が少なくありません。

僕がアドバイスしているのは、最初の半年は「自分が何を作ったか」ではなく「チームが何を完了できたか」を、自分の実績として捉え直す練習をすることです。この視点の切り替えができると、PMという仕事の面白さが見えてくるという声を、転身した方々から多く聞きます。

（結論）PMへの転身は、技術理解を土台にした役割の拡張である

まとめます。①SEからPMへの転身は技術力の放棄ではなく、技術理解を土台にした役割の拡張である。②転身の壁は技術力ではなく、意思決定と説明責任を引き受けることへの心理的なハードルにある。③小さな範囲からPM的な役割を経験し、実績を数字で語れる形に整理することが転身の近道になる。

率直に言うと、多くのSEの方が「マネジメントは自分には向いていない」と早々に判断してしまいがちです。しかし実際に転身した方々を見てきた限り、向き不向きの判断は転身してみる前より、実際に小さな役割を経験してみた後の方がずっと正確につきます。まずは15問の適性診断で、自分がどの金融PMタイプに近いかを確かめてみてください。皆さんいかがでしたでしょうか。では今日もがんばりましょう。