PMOはやめとけって本当？　議事録と進捗表ばかりの現場は、会社を変えれば変わるのか

開発からPMOに回されて、毎日やっているのは定例の議事録、進捗表と課題表の更新、週次報告の資料づくり。遅れが出ると「PMOは何をしていたんだ」と言われるのに、決める権限は無い。ネットで「PMOはやめとけ」「市場価値が付かない」と見て、このまま続けていいのか焦っている人に向けて書きます。

「やめとけ」の理由には、会社や案件を変えれば変わるものと、今と同じ形のPMOを続ける限り変わらないものがあると私は考えます。議事録と表の更新ばかりなのは、今の現場でPMの手伝いを任されているからで、別の会社や案件のPMOでは仕事の中身が違う場合があります。PMOには、テンプレートや研修を用意する型から、プロジェクトを直接管理する型まであります。一方で、開発をしないPMOの仕事を続けている間は、開発の経験は増えません。PMの手伝いとして入るPMOでは最後に決めるのはPMで、そこは会社を変えても同じだと私は考えます。

「PMOの経験は通じない」とまでは言えないと私は考えます。当サイトのPMOの掲載求人（2026年10月13日時点）では、応募要件にPMOの経験が出てくる会社が約3割ありました（必須・歓迎、他の経験との選択を含む）。PMの仕事と技術のどちらへ進むか迷っているなら、まずPMに「回答案を作るところまで」を任せてもらえないか頼んでみてください。やってみると、自分がどちらに惹かれているかが見えてきます。

議事録ばかりの毎日は会社で変わりうる。技術と権限は、今と同じ形のPMOを続ける限り変わらない

よく挙がるきつさごとにまとめると、次のとおりです。

よく挙がるきつさ	どんなきつさか	会社で変わるか、仕事に残るか（私の判定）	当サイトの数字
議事録・進捗表・課題表の更新ばかり	誰でもできる雑用に見え、何が身についたか言えない	会社・案件で変わる。今の現場でPMの手伝いを任されているから	–
技術が増えない	開発から離れて、同期だけが先へ行く気がする	仕事の選び方で変わる。開発をしないPMOの仕事を続ける間は増えない	応募要件に開発・設計・構築の経験を書く会社が約3割
決める権限が無いのに責任が来る	遅れの理由を問われるが、自分では決められない	PMを支える形のPMOでは、最後に決めるのはPM。入り方で発言できる範囲が違うという声もある	–
成果が見えにくい	何をしたと言えばいいか分からない	PMOでいる限り続くが、職務経歴書の書き方で見せられる	–
「PMO」が職種として通じない	職務経歴書に書けない気がする	求人では経験の名前として通じる。ただし公的な職業分類にPMOの区分は無く、中身も現場ごとに違う	応募要件にPMOの経験を書く会社が約3割

当サイトの数字は、当サイトのPMOの掲載求人（2026年10月13日時点、PMとの併記などを除く）を出している会社のうちの割合です。

議事録と表の更新ばかりの毎日が会社で変わりうるのは、PMOという名前の下に、いくつもの違う仕事があるからです。PMI（米国のプロジェクトマネジメント協会）のライブラリに載った論文「PMO evolution」は、PMOを統制の度合いで、テンプレートや研修、教訓を提供する支援型、手法やルールへの準拠を求める管理型、プロジェクトを直接管理する指揮型に分けています。議事録と表の更新が仕事の中心になっているのは、どの型かというより、今の現場でPMの手伝いを任されているからだと私は考えます。

技術の不安は、会社を変えるだけでは消えません。開発をしないPMOの仕事を続けている間は、開発の経験は増えないからです。ただ、PMOの中にも技術を使う仕事があります。当サイトの掲載求人には、開発PMOや、インフラ領域のPMOで設計・構築の経験を必須にしている求人もあります。技術の不安を減らしたいなら、開発に戻るか、技術を使うPMOの仕事を選ぶことになると私は考えます。

PMを支える側に置かれたPMOでいる限り、権限の不満はなくならないと私は考えます。PMOの中にはプロジェクトを直接管理する型もありますが、今のようにPMの手伝いを任されている形では、最後に決めるのはPMだからです。客先常駐の下請けとして入るか、自社のPMOか、コンサルとして入るかで発言できる範囲が違う、という声は複数の書き手から出ています。決める経験を少しずつ増やす頼み方は、後の「続けるか迷う時に、最初に確かめること」に書きました。

PMOの1年で身につくことと、向いている人

厚生労働省の職業情報サイト（job tag）の「プロジェクトマネージャ（IT） - 職業詳細」は、PMの仕事として、進捗の管理や、関係者への進捗・課題の報告、意見の調整を挙げています。job tagはPMOには触れていませんが、これを読むと、PMOの毎日の仕事の多くはPMの仕事の一部と重なっていると私は考えます。課題表で返事が止まっている課題を見つけて、期限まで追いかけた経験は、自分が決める側に回った時にもそのまま使います。

向いているのは、返事の止まった課題を見つけて担当者に声をかけ、片付くまで追いかけるのが苦にならない人だと私は考えます。コードを書くより、段取りを組んで人に動いてもらう方が好きな人です。

PM以外の行き先として、事業会社の企画やDX推進の部署を考える人もいると思います。情報処理推進機構（IPA）の「デジタルスキル標準 ver.2.0」には、業務・組織・システムの分析と要求の整理を担い、関係者の利害調整も行う「ビジネスアナリスト」という役割が定義されています。関係者の間に入って調整してきた経験は、この役割の仕事の一部に重なります。

当サイトのPMOの求人の約3割で、応募要件にPMOの経験が出てくる

当サイトのPMOの掲載求人（2026年10月13日時点）を出している会社のうち、応募要件にPMOの経験が出てくる会社は約3割、開発・設計・構築の経験が出てくる会社も約3割ありました。どちらも必須と歓迎の両方を含み、「ITエンジニアまたはPMOの経験」のような選択肢の1つとして書かれたものも数えています。PMOという言葉は、求人の応募要件の中で経験の名前として使われています。PMOの求人でも、開発の経験を求める会社があります。

ただ、同じPMOでも仕事の中身は現場ごとに違います。職務経歴書に「PMO 1年」とだけ書くと、議事録を書いていたのか、プロジェクト全体の進め方を決めていたのかが伝わりません。盛らずに書くには、自分がしたことと、決めたのは誰かを分けて書きます。たとえば次のような書き方です。

基幹システム更改プロジェクトのPMOとして、課題管理表を週次で集計し、回答期限を過ぎた課題を元請けのPMと客先の担当者に催促。対応方針の判断は元請けのPMと客先。

面接で「それはあなたが決めたんですか」と聞かれたら、次のように答えれば詰まりません。

決めたのはPMです。私は、どの課題が止まっているかを毎週出して、PMが判断できる材料をそろえていました。

PMOの仕事は、決める人が判断できるように材料をそろえることです。決めたのはPMだと言うことは、自分の仕事をそのまま説明していることになります。

開発に戻る場合、クラウドの経験が無いことを気にする人もいると思います。当サイトの掲載求人（2026年10月14日時点）で、応募要件にJavaが出てくる開発の求人を出している会社のうち、クラウド（AWS・Azure・GCPなど）の経験を必須の側に書いている会社は約15%でした。当サイトの掲載求人では、クラウドを必須にしていない開発の求人を出している会社の方が多いということです。

続けるか迷う時に、最初に確かめること

1. PMに「回答案を作るところまで」を頼んでみる。 「決める範囲をください」より、「客先から来る課題の一次切り分けと回答案を私が作るので、PMが確認して直す形でどうでしょう」と頼む方が通りやすいと私は考えます。決めるのはPMのままなので、PMの側が手放すものがありません。案を作ってPMと詰めるのが面白いと感じたなら、PMの仕事に気持ちが向いているのかもしれません。やってみても退屈で、同期のクラウドの話の方が気になるなら、技術の方に心が残っているのだと思います。断られた場合は、その現場では決める経験が増えないことが分かります。

2. 技術の方だと分かったら、社内で開発に戻れないかを、抜ける段取りと一緒に頼む。 人手が足りなくてPMOに回された経緯があると、「戻りたい」だけでは会社の側は「抜けたら誰がやるのか」しか考えられません。「このプロジェクトの区切りが終わったら開発に戻りたいです。それまでに議事録や課題表の回し方を手順にまとめて、引き継げるようにしておきます」のように、時期と引き継ぎを自分から出します。いつまで待つかに根拠のある期間はないので、私なら次の評価面談やプロジェクトの区切りのような出来事で区切り、その時点で時期の話が出なければ、転職の求人を見始めます。技術が一番の不安だと分かった後なら、先に延ばす理由はあまり無いと考えます。

3. 資格より先に職務経歴書を書く。 開発の年数とPMOの年数を書き出して、気になる求人の応募要件と並べると、足りないものが見えます。資格を取るかは、その後に決めても遅くないと私は考えます。

よくある質問

PMOからPMになれますか

続けるだけでなれるとは言えない、と私は考えます。PMの手伝いをするPMOでは、自分で決めた経験が増えにくいからです。IPAの「プロジェクトマネージャ試験 | 試験情報 | IPA 独立行政法人 情報処理推進機構」は、対象者像を、プロジェクトマネジメント業務を「単独で又はチームの一員として担う者」としていて、チームの一員として担う人も含んでいます。私なら、回答案作りのように判断の手前まで受け持つ仕事を頼んで、PMの仕事に近い経験を少しずつ増やしていきます。

開発に戻ったら、PMOの1年は無駄になりますか

無駄にはならないと考えます。job tagの「プロジェクトマネージャ（IT） - 職業詳細」は、PMにはシステムエンジニア等として構築・運用を経験した人が就くことが多いとしていて、開発に戻ってもPMへの道は閉じません。開発チームで進捗や課題を報告する側に回った時、PMが何を見て判断するか、どう書けば課題表で止まらないかを、PMOの1年で知っていることになります。

コンサルのPMOに移れば、技術の不安は解けますか

解けないと私は考えます。コンサルの会社に移っても、PMOとして入る限り、仕事の中心はPMOの仕事になると考えるからです。今の経験は、自分がしたことと決めた人を分ける同じ書き方で応募書類に書けます。技術の不安を減らしたいなら、移り先はコンサルのPMOより、開発か、技術を使うPMOの仕事だと私は考えます。

PMOの年収はどのくらいですか

PMOの年収を示す公的な統計はありません。「令和４年版 厚生労働省編職業分類表」には「ITプロジェクトマネージャ」はあってもPMOの区分はありません。賃金の統計で職種を書き込む時の案内である厚生労働省の「令和 4 年賃金構造基本統計調査業種別主な職種早見表」でも、情報処理プロジェクトマネージャーは「システムコンサルタント・設計者」に入っていて、PMOは挙がっていません。

集計の条件と注意

• 当サイトの数字は、当サイトの掲載求人を数えたもので、市場全体の求人の割合ではありません。割合は会社ごとに該当する求人の割合を出して平均した会社単位の値で、5%単位・1割単位に丸めています
• PMOの求人は、2026年10月13日時点で掲載中の、求人名か職種名にPMOを含む求人から、PMとPMOの併記、PMOの経験者を募る求人名、オープンポジション、アシスタント・事務寄りの求人を除いて数えました。応募要件の欄に出てくる語で拾っているので、必須と歓迎、他の経験との選択肢を区別していません
• Javaの開発求人は、2026年10月14日時点で掲載中の、応募要件にJavaを含み、求人名にエンジニア・SE・開発・プログラマを含む（PMOを含まない）求人です。クラウドの語が「歓迎」の語より前に出てくるか、「歓迎」の語が無い応募要件に出てくるものを必須の側とみなした粗い判定で、約15%は粗い値です。書類が通るかどうかは、この数字からは分かりません
• 表の判定、確かめることの頼み方や区切り方、よくある質問の「私は〜」は書き手の判断で、選考に通ることやPMになれること、年収を請け合うものではありません
• 「PMO evolution」は、PMIのライブラリに載った学会発表の論文で、PMIの公式の基準ではありません
• 入り方で発言できる範囲が違うという話は、複数の記事の書き手の主張で、統計はありません。PMOの経験者がビジネスアナリストなどの役割にどのくらい移れているか、資格が転職でどのくらい効くかを示すデータも見つけていません