はじめに
こんにちは。
本来はエンジニアとしてジョブチェンジをしたはずが、社内事情という名の荒波に揉まれ、気づけば PMO（Project Management Office） の席に座っていた私です。
元々大阪に住んでいたのですが、かねてよりの私の希望でエンジニアが所属する開発部に異動することになり、「ワークライフバランス無視で働いてやるぞ🔥」と息巻いていましたが、何故か半年経った今ではPMOをやっています。なんで？？
配属されて早2ヶ月。
「PMOってプロジェクト管理のサポート役だよね？」と教科書通りの認識で飛び込んだものの、そこで待っていたのは 「慢性的な人手不足」 と 「PM不在の実質PM代行」 という、なかなかスリリングな現場でした。
まあうちはベンチャーだし仕方ないですが。
そもそもPMOの定義を適切に理解できている人っていない気がするので、仕方ないと思っています。
同じように「気づけば何でも屋になっている」方々の共感や、これからPMOに関わる方の参考になれば幸いです。
前提：なぜPMOになったのか
- 入社経緯: エンジニアとしてQA→エンジニアにジョブチェンジ
- 現状: 社内リソースの都合により、PMOチームへアサイン
- 現場の状況: エンジニア・マネジメント層ともに慢性的な人手不足
「コードを書くぞ！」と意気込んでいた手前、最初は戸惑いしかありませんでしたが、「プロダクト全体を見渡せるチャンス」とポジティブに捉えてスタートしました。「もうエンジニアは稼げないよ🤓」みたいな嫌なこと言う人もいっぱいいますしね。
（まあ、金を稼ぎたいというか、ただ開発が好きでずっと趣味で個人で開発していて、それを仕事にしたいと思って弊社に入った私からしたら、上記のような言説って「黙れ」としか思いませんが。まあ、これはただの愚痴です、、、）
「PMO」の皮を被った「QA兼BA」
一般的にPMOといえば、プロジェクトマネジメントの標準化や、進捗・課題の可視化が主な役割です。
しかし、人手が足りない弊社において、PMOの守備範囲は**「落ちているボールは全て拾う」**ことでした。
この2ヶ月で私が実施した業務は、PMOの枠を大きく超えていました。
| 役割 | 本来の担当 | 私の実績 |
|---|---|---|
| PMO | 進捗管理・課題管理 | もちろん実施 |
| BA (Business Analyst) | 要件定義・顧客折衝 | 仕様が曖昧な部分をヒアリングし、ドキュメント化 |
| QA (Quality Assurance) | テスト計画・実施 | リソース不足のため、テストケース作成から実施まで担当 |
もはや「プロジェクト管理室」ではなく**「プロジェクトなんとかする室」**です。
QAやBAの動きまで求められるため、脳の切り替えだけで一日のエネルギーの大半を消費していました。
最大の壁：見積もりと進捗管理の難しさ
エンジニアバックグラウンドがあるとはいえ、実務で触っていないコードベースやシステム構成のすべてを把握しているわけではありません。
ここで一番苦労したのが 「見積もり」 と 「進捗管理」 です。
1. エンジニアに聞くしかない無力感
自分で実装するわけではないため、タスクの規模感や技術的な不確実性を肌感覚で掴むことができません。結局、見積もりは現場のエンジニアに依存します。
- 「これ、どれくらいで終わりますか？」
- 「やってみないとわかりません（正論）」
- 「ですよね……でもスケジュール引かないといけないんです……」
このラリーを繰り返す中で、エンジニアの作業時間を奪ってしまう申し訳なさと、それでも数字を出さなければならない板挟みに苦しみました。
現場の状況的に開発者が少ないが営業、CSは足りているという状況で、そうなると開発の要望とか、顧客からの問い合わせとかいっぱい来るんですよね。そういうのが全部私に来るんですが、そのままエンジニアに横流しするだけで、無力感に襲われましたね、、、
2. 見えない依存関係
BA的な動きもしているため仕様は把握していますが、裏側の「技術的な負債」や「複雑な依存関係」までは見えません。「この機能追加なら3日でいけるだろう」と思っても、レガシーコードの森に阻まれて2週間かかる、なんてことがザラにあります。
構造的な問題：「PM不在」のプロジェクト
そして、何より一番しんどかったのが 「PM（Project Manager）が実質不在」 という状況です。
本来、PMOはPMを支援する組織です。
$$PMO \xrightarrow{Support} PM \xrightarrow{Manage} Project$$
しかし、弊社では多くのプロジェクトでPMが実質不在（または兼務過多で機能していない）でした。
$$PMO \xrightarrow{???} Project$$
実際はPMの役職に人はいるのですが、複数プロジェクト見ていたり、PO/PMの線引きが曖昧で、現場にはほとんど関わらず意思決定は実質PMOに任せる人など、状況はさまざまです。
方針なきプロジェクトの辛さ
PMが不在だと何が起きるか。それは 「プロダクトの方針（Direction）の欠如」 です。
- 「この機能、本当に今やるべき？」
- 「仕様変更が発生したけど、納期と品質どっちを優先する？」
- 「A案とB案、ビジネスインパクトが大きいのはどっち？」
こういった意思決定をする人がいないのです。
PMOとして「状況」は整理できますが、「決断」をする権限も責任も曖昧なまま。
結果として、PMOである私が方針案を出し、なんとなく合意形成をして進める……という「隠れPM」のような動きを強いられました。
エンジニアたちが迷子にならないよう旗を振るべきPMがいないと、現場は疲弊し、PMOは調整だけで一日を終えることになります。
2ヶ月を終えてのKPT
怒涛の2ヶ月でしたが、得られたものもゼロではありません。
Keep（良かったこと）
- ドメイン知識の爆速習得: QAやBAまでやったおかげで、仕様の隅々まで理解できた。
- エンジニアへのリスペクト: 見積もりの難しさを痛感し、エンジニアとの対話を誰よりも重視するようになった。
- 調整力の向上: 誰も決めない中で「じゃあこうしましょう」と推進する胆力はついた。
Problem（課題）
- ロールの境界が曖昧: 何でも拾いすぎて「PMOの仕事」が定義できなくなっている。
- 意思決定のボトルネック: PM不在により、重要な決定が遅れがち。
Try（今後やりたいこと）
- 「決める人」を定義する: プロジェクト開始時に、誰が意思決定者かを明確にするよう働きかける。
- PMO業務の線引き: QAやBA業務はあくまで「暫定対応」とし、専門ロールへの移譲を提案し続ける。
まとめ
エンジニアとして入社したはずが、PMOとしてQAからBAまでこなすことになった2ヶ月。
正直、「話が違う！」と思う瞬間がなかったと言えば嘘になります。
しかし、「コードを書く以外でプロジェクトを前に進める力」 が、エンジニアとしての基礎体力（特に上流工程の理解）を鍛えてくれているとも感じます。
ただ、これだけは言わせてください。
「PMの皆さん、プロダクトの方針だけは！ バシッと決めてください！」
それさえあれば、あとの雑務は我々PMO（兼何でも屋）がなんとかしますから。