PMOを目指すには｜開発・営業・事務など他の職種からのキャリアチェンジ

他の職種からPMOを目指すなら、今の職場で進捗や課題の管理、会議の運営を担う場面を自分から取りに行き、その経験を「誰を支え、何を管理し、何を変えたか」で言葉にすることが近道です。PMOは肩書きより実務で判断される職種なので、正式にPMOになる前から経験を積み始められます。

ただし、フリーランスの案件は即戦力を求めるため、PMOの経験がまったくない状態でいきなり業務委託で入るのは難しいのが実情です。この記事では、前職ごとに生かせる経験と足りない部分、その埋め方を整理します。PMOとして独立するまでの手順はPMOがフリーランスになるにはで解説しています。

PMOへの主なルート

PMOを目指す人の前職はさまざまです。代表的なルートと、生かせる経験、足りなくなりやすい部分をまとめます。

どのルートでも、生かせる経験はPMOの仕事の一部に当たります。足りない部分を、今の職場で埋められるかが鍵になります。

ルート別の進め方

開発エンジニア・リーダーから

開発の現場を知っていることは、PMOとして大きな強みです。遅れの兆しを、作業の中身から読み取れるからです。開発リーダーとして、チームの進捗をまとめて報告していた経験は、そのままPMOの経験の土台になります。

足りなくなりやすいのは、自分のチームの外を見る経験です。他のチームや他の会社との境目にある課題を引き取ってまとめる、全体の定例の資料づくりを手伝うなど、チームの外の管理に関わる場面を増やすと、PMOの経験として語れるようになります。プロジェクトリーダーとして独立する道と比べたい場合はPLがフリーランスになるにはもご覧ください。

PMから

PMの経験がある方は、PMOの仕事の多くをすでに知っています。気をつけたいのは、立場の切り替えです。PMOは決める人ではなく、決める人の材料を作る人です。PMの癖で関係者に指示を出したり、優先順位を決めたりすると、参画先のPMとぶつかります。

面談では、PMとしての経験のうち、計画の管理、課題の整理、報告の仕組みづくりの部分を前に出し、PMOとしての立場の違いを理解していることを伝えます。PMとして目指す道はPMを目指すにはで扱っています。

営業・プリセールス・情報システム部門から

顧客や社内の関係者と調整してきた経験は、PMOの調整の仕事に通じます。情報システム部門の方は、発注側の立場でベンダーを管理した経験が、発注側のPMOの案件で生きます。

足りなくなりやすいのは、開発の工程と、台帳で数字を管理する経験です。プロジェクトの計画書や進捗報告を読み込み、どの数字から何が分かるかを説明できるようにしておきます。社内のシステム導入のプロジェクトがあれば、事務局として手を挙げるのが一番の近道です。

経営企画・事務・アシスタントから

会議の運営、資料の取りまとめ、数字の集計は、PMOの事務局の仕事と重なります。この経験から入る場合は、事務局型の役割を入口にし、ITプロジェクトの流れと用語を学びながら、管理推進の役割へ広げていくのが現実的です。

最初から管理推進やPM補佐の役割を目指すより、議事録や台帳の更新を正確にこなし、その中で気づいた点をまとめて報告する経験を重ねると、任される範囲が広がります。

コンサルタント・テスト・品質管理から

コンサルタントの方は、論点の整理や経営層向けの資料づくりに慣れており、PMOの判断の支援の仕事と重なります。足りなくなりやすいのは、課題の一件一件を期限まで追いかけ、台帳を毎週更新し続ける地道な管理です。提言で終わらず、決まったことが現場で実行されるまでを追った経験を整理しておきます。

テストや品質管理の方は、不具合の発生と解消の推移を読み、品質の判断の材料を作ってきた経験が生きます。テストの段階のPMOや、品質の判定会議を回す役割から入ると、強みを出しやすくなります。そのうえで、費用、要員、変更の管理など、品質以外の領域に関わる場面を増やしていきます。

足りない部分の埋め方

1. 今の職場でPMO的な仕事を取りに行く

最も効果があるのは、今の職場で実際にPMOの仕事に関わることです。次のような場面は、どの職種にいても手を挙げやすいものです。

• 社内のシステム導入や業務改善のプロジェクトで、事務局を引き受ける
• チームの定例会議で、議題の準備と議事録、宿題の追いかけを担う
• 複数の部署が関わる取り組みで、進捗の一覧を作って共有する
• 遅れている取り組みで、課題を整理して上司に選択肢を出す

小さな取り組みでも、自分で管理の仕組みを作り、回した経験は、PMOの経験として説明できます。

2. プロジェクトマネジメントの体系を学ぶ

実務の経験に加えて、プロジェクトマネジメントの考え方を体系的に学んでおくと、自分がやってきたことを共通の言葉で説明できるようになります。範囲、スケジュール、費用、品質、リスク、関係者との意思疎通といった管理の領域を一通り押さえておくと、どの領域の経験が足りないかも見えてきます。資格の位置づけはPMOに資格は必要かの記事で扱っています。

3. 道具に慣れる

PMOの案件では、表計算ソフトでの集計、報告資料の作成、チケット管理ツールでの課題管理などの経験がよく確かめられます。今の職場で使っていない道具は、個人で触れられる範囲で一通り操作に慣れておきます。道具の名前より、それで何を管理したかを話せることが大切です。

4. 正社員のPMOで経験を積んでから独立する

PMOの経験がほとんどない場合は、まず正社員としてPMOの役割に就き、経験を積んでから独立する順番が現実的です。社内の異動でPMOの部署に移る方法や、PMOの経験を積める会社へ転職する方法があります。正社員とフリーランスの違いはPMOは正社員とフリーランスのどちらがよいかで整理しています。

経験をPMOの言葉で書き直す

他の職種の経験をPMOの経験として伝えるには、スキルシートの書き方も変えます。

1. 支援の相手を書く：誰の取り組みを支えたのか（上司、プロジェクトの責任者、複数の部署など）
2. 管理の対象を書く：進捗、課題、リスク、変更、費用など、何を管理していたか
3. 作った仕組みを書く：一覧表、会議の進め方、報告の様式など、自分で作ったもの
4. 気づいて動いた場面を書く：何から問題に気づき、どうまとめ、何が決まったか

前職の肩書きのままでは、PMOの案件と結び付きません。PMOの言葉で書き直すと、案件側が判断しやすくなります。書き方はPMOのスキルシートの記事、PMOに求められるスキルの全体はPMOのスキルの記事で解説しています。

よくある質問

IT業界の経験がなくてもPMOを目指せますか？

目指せますが、ITプロジェクトの流れと用語を学ぶ時間が必要です。会議の運営や資料の取りまとめ、数字の集計の経験があれば、事務局型の役割の土台になります。まずは社内のシステム導入のプロジェクトに関わるなど、ITプロジェクトの現場を経験する機会を探すと近道です。

PMからPMOに移るのは、キャリアとして後退になりますか？

後退とは限りません。PMOは、複数のプロジェクトを横断して見る役割や、全社の管理の仕組みを作る役割へ広がっていく職種で、PMとは別の専門性があります。PMとして判断してきた経験は、判断する人が何を必要とするかを知っている強みになります。

PMOを目指すのに、資格は先に取ったほうがよいですか？

資格がなくても、PMOの仕事に就くことはできます。案件で重視されるのは実務の経験です。学ぶことで自分の経験を共通の言葉で説明しやすくなる効果はあるため、実務の経験を積みながら並行して学ぶ形をおすすめします。