開発者からPM・PMOへ役割を移す進め方｜今の案件でできることと最初の案件の選び方

開発者からPM・PMOへ役割を移すには、今の案件の中で、進捗・課題・調整の仕事を少しずつ引き受け、その実績を説明できる形で残すのが近道です。業務委託の案件は役割ごとに募集されるため、マネジメントの経験がまったくないまま、PMやPMOの案件に移るのは難しいのが実情です。

この記事では、PMとPMOのどちらを目指すかの考え方、開発の立場から役割を広げる段階、最初の案件の選び方と注意点を整理します。PMやPMOとして独立する手順そのものは、PMがフリーランスになる方法とPMOがフリーランスになる方法で扱っています。

開発の仕事と、PM・PMOの仕事の違い

開発者として評価されてきたのは、自分の手で動くものを作る力です。PMやPMOでは、評価の軸が変わります。

いちばん大きな違いは、自分で直せない問題を、人に動いてもらって解くことです。開発者として優秀な人ほど、問題を自分で直したくなりますが、PM・PMOの立場でそれを続けると、全体を見る仕事が手薄になります。役割を移すときには、この切り替えに慣れることが最初の壁になります。

PMとPMOのどちらを目指すか

PMとPMOは、似ていても求められる経験が違います。

• PM：プロジェクトの計画を立て、遅れや問題が起きたときに判断し、結果に責任を持つ役割。判断した経験が問われる
• PMO：PMや責任者を支え、進捗・課題・リスク・会議体などを管理する役割。管理の仕組みを回した経験が問われる

開発者からの移り方としては、次の2つの道があります。

1. 開発のリーダーからPMへ：開発チームのリーダーとして計画や見積もりを担い、そこから小さなプロジェクト全体へ広げる
2. 技術に強いPMOへ：開発の知識を生かして、開発チームの進捗や品質を管理するPMOとして入る

どちらが向いているかは、判断と責任を負う仕事に関心があるか、管理の仕組みを整える仕事に関心があるかで考えます。最初から一つに決めなくても、両方に共通する経験（進捗の管理、課題の管理、会議の運営）から積み始めれば、後で選べます。専門と幅の考え方はスペシャリストとジェネラリストの記事で扱っています。

今の案件で役割を広げる段階

開発者として参画している案件の中でも、マネジメントの経験は積めます。いきなり大きな役割を求めるより、次のような段階で少しずつ広げると、取引先も任せやすくなります。

段階1：自分の担当の見積もりと進捗を数字で出す

まずは、自分が担当する作業について、見積もり・予定・実績を数字で出し、遅れそうなときに早めに知らせることから始めます。週報や進捗報告で、予定と実績の差、遅れの理由、対応案を書くようにすると、それ自体が進捗管理の練習になります。書き方は週報の記事で扱っています。

段階2：チームの課題やリスクの一覧を担う

開発チームの課題や不具合の一覧を整理し、誰がいつまでに対応するかを決めて追いかける役を引き受けます。会議の議事録を取り、決まったことと宿題を残す役も同じです。目立たない仕事ですが、PMOの中心的な仕事とほぼ同じ中身です。

段階3：小さな単位のリーダーを担う

数人の開発チームや、一つの機能のまとまりについて、計画・見積もり・メンバーへの作業の割り振り・進捗の報告を担います。ここで、自分で手を動かす時間と、全体を見る時間の配分を経験します。

段階4：発注側や他チームとの調整に入る

仕様の確認、ほかのチームとのつなぎ込みの日程、リリースの判断など、チームの外との調整に加わります。ここまで来ると、PMやPMOの案件で求められる経験の多くを、具体例として話せるようになります。

最初のPM・PMO案件の選び方

役割を移す最初の案件は、これまでの開発の経験が生きる案件を選ぶと、立ち上がりが楽になります。

• 技術領域が近い案件：使ってきた技術や、携わってきた業務のシステムに近いプロジェクト。開発チームの話がすぐ分かるため、管理の仕事に集中できる
• 開発リーダーとPMOを兼ねる案件：開発の知見を求められつつ、進捗や課題の管理も担う形。移行の途中の段階として入りやすい
• 体制の中で上にPMがいる案件：最初からすべての判断を一人で負うのではなく、PMの下で管理の仕事を担う形

反対に、最初の案件で避けたいのは、役割があいまいな案件です。「PM補佐」「PMO」と書かれていても、実際は開発の人手不足を埋める役割を期待されている場合があります。面談では、週の時間のうち管理の仕事と開発の作業がどのくらいの割合になりそうか、誰に報告し、何を決める権限があるかを確かめておきます。

報酬は、役割を移した直後に上がるとは限りません。開発での実績が長い人ほど、マネジメントの経験が浅い段階では、開発の案件と比べて条件が見劣りすることもあります。報酬の考え方は案件によって大きく変わるため、PM案件の報酬の記事やPMO案件の報酬の記事も参考にしてください。

スキルシートの書き直し方

役割を移すときは、スキルシートの見せ方も変えます。開発のスキルシートは技術の一覧が中心ですが、PM・PMOの案件では、管理した範囲と判断の場面が見られます。

• 冒頭の要約：「開発の経験をもとに、進捗・課題管理とチームの調整を担ってきた」のように、目指す役割に向けた一文を置く
• プロジェクト欄：開発の作業と並べて、担った管理の仕事（見積もり、進捗の報告、課題の一覧の運用、会議の運営、調整の相手）を書く
• 規模の情報：チームの人数、関わったチームの数、プロジェクトの期間など、管理した範囲が分かる数字を添える

マネジメントの経験年数は、肩書きではなく、実際に管理を担った期間で数えます。数え方は経験年数の数え方の記事で整理しています。PM・PMO向けの書き方はPMのスキルシートの記事とPMOのスキルシートの記事をご覧ください。

資格は知識の裏付けとして

資格は、経験の代わりにはなりませんが、マネジメントの知識を体系的に学んだことの裏付けになります。なお、IPA（情報処理推進機構）は、2027年度から情報処理技術者試験を新しい制度に移す予定で、応用情報技術者試験と高度試験を大括りにして「プロフェッショナルデジタルスキル試験」に再編し、「マネジメント領域」「データ・AI領域」「システム領域」の3つの区分を設ける案を2026年3月に示しています（名称は仮称で、内容は検討中のため今後変わる場合があります。2026年10月時点）。受験を考えている場合は、IPAの試験制度の見直しのページで最新の情報を確かめてください。

よくある質問

開発の仕事を完全にやめないと、PM・PMOとは見てもらえませんか？

開発とマネジメントを兼ねる案件も多くあります。移行の途中では、開発の経験を生かしながら管理の仕事の比重を増やしていく形が現実的です。スキルシートでは、管理の仕事を開発の作業と分けて書くと、両方の経験が伝わります。

リーダーの肩書きがなかった経験も、マネジメントの経験として書けますか？

肩書きがなくても、進捗や課題を自分で管理し、メンバーや他チームと調整していたなら、その中身を書けます。ただし、誇張は避け、「チームの課題一覧の運用を担当」のように、担った範囲をそのまま書きます。

PMOから入って、後でPMを目指すことはできますか？

PMOの仕事の中で、課題の解決策を提案したり、判断の材料をまとめたりしてきた経験は、PMに移るときの足がかりになります。一方で、PMの案件では最終的に判断した経験が問われるため、小さな範囲でも自分で決めて責任を持った場面を積んでいくことが大切です。