PMOを目指すあなたへ:私のキャリアは計画通りではなかった
PMOになるには何をすればいいのか。どんなスキルが必要なのか。そもそも自分はPMOに向いているのか。こうした疑問を抱えてこの記事にたどり着いた方も多いと思います。
私は現在、PMOとして10年以上のキャリアを積んでいますが、最初からPMOを目指していたわけではありません。1994年にプログラマーとしてキャリアをスタートし、SE、そしてPMOへと移行してきました。振り返ってみれば30年以上のIT人生ですが、正直に言えば、そのほとんどは「その時々の現場で必要とされることに応えていたら、いつの間にかここにいた」という感覚です。
PMOという職種は、プロジェクトマネジメントを支援する専門職として認知されるようになってきましたが、明確なキャリアパスが確立されているわけではありません。資格を取れば自動的になれるものでもなく、ある日突然「あなたはPMOです」と任命されるものでもない。では、どうやって私はPMOになったのか。
この記事では、私自身のキャリアを時系列で振り返りながら、各フェーズで何を学び、どんな経験が次のステップにつながったのかを具体的に語ります。これは「正解ルート」の提示ではありません。一人のIT実務家が30年間、現場で何を経験し、どう考えてきたかという実例です。あなた自身のキャリアを考えるヒントになれば幸いです。
私のITキャリアは1994年4月、新卒でプログラマーとして始まりました。最初の3年7ヶ月は上下水道プラント監視システムでCOBOLを書く日々。物理機器との連携や24時間監視の責任感に鍛えられました。1998年からSEに移行し、Visual Basic 6.0やPowerBuilderで業務システムを開発。要件定義から運用保守までを経験する中で、『システムは作って終わりではない』ことを学びました。2014年頃からPMOに本格的に関わり始め、複数の大規模プロジェクト(200名規模を2回)でPMOの本質を学びました。そして2023年にPJM-A(プロジェクトマネジメント・アソシエイト)を取得し、自分の中で『PMOとしての軸』が完成しました。PG 8年 → SE 17年 → PMO 10年以上。このキャリアは『正解』ではなく『一つの実例』として、これからキャリアを考える若手の参考になれば嬉しいです。
キャリアの節目で「次はこれをやりたい」と明確に決めていたわけではありません。むしろ、目の前の仕事に全力で取り組んでいるうちに、自然と次のステージに引き上げられていった感覚が強いです。ただし、振り返ってみると、各フェーズで得た経験やスキルが確実に次の役割につながっていたことも事実です。
PMOを目指す方にとって重要なのは、直線的なキャリアパスを描くことではなく、自分の現在地と次の一歩を見定めることだと私は思います。では、私がどのように30年間を歩んできたのか、具体的に見ていきましょう。
1994年、プログラマーとしてのスタート
私がIT業界に入ったのは1994年、バブル崩壊後の就職氷河期でした。配属されたのは金融系のシステム開発部門で、使用言語はCOBOL。当時はまだ汎用機(メインフレーム)が主流の時代で、端末はグリーンの文字が光る5250端末でした。
最初の3年間は、ひたすらコーディングとテストの日々です。先輩が書いた設計書を見ながらプログラムを書き、単体テストを繰り返す。バグが出れば修正し、また動かす。地道な作業でしたが、この時期に「動くものを作る」という感覚を身体に染み込ませることができました。
COBOLは今では古い言語と言われますが、データ構造の設計やファイル処理の基本、エラーハンドリングの考え方など、プログラミングの本質的な部分を学ぶには良い環境でした。何より、金融系という特性上、「1円も間違えてはいけない」という厳格な品質管理の文化が徹底されていました。
この時期、私は自分がプログラマーとしてどこまでいけるのか、正直わかりませんでした。周囲には私よりずっと優秀なプログラマーが大勢いましたし、自分の適性に確信が持てない日々もありました。ただ、目の前のコードを書くこと、バグを潰すこと、期日に間に合わせることに集中していました。
クライアントサーバ時代の到来とスキル拡張
1997年頃から、システム開発の潮流が大きく変わり始めます。汎用機からクライアントサーバシステムへの移行が進み、Visual Basic 6.0やJavaといった新しい開発環境が現場に入ってきました。
私もVB6を使った業務アプリケーション開発に携わるようになり、COBOLとは全く異なる世界に触れることになります。GUIの設計、イベント駆動型のプログラミング、データベースとの連携(ADO、DAO)など、新しい概念を次々と学びました。
この時期の経験で大きかったのは、「言語やツールは変わっても、システム開発の本質は変わらない」と実感できたことです。データの流れを正確に把握し、ユーザーの要求を形にし、品質を担保する。使う道具が変わっただけで、やるべきことの核心は同じでした。
プログラマーとして8年目を迎える頃、私は自然とチームの中で後輩を指導する立場になっていました。コードレビューを担当し、若手の相談に乗り、設計の意図を説明する。知らず知らずのうちに、「作る人」から「作る人を支える人」へと役割がシフトし始めていたのです。
SEとしての17年:設計と顧客折衝の現場で学んだこと
2002年頃、私は正式にSE(システムエンジニア)の役割を担うようになりました。プログラマー時代の主戦場が「設計書からコードへ」だったとすれば、SEとしての主戦場は「顧客要求から設計書へ」です。この移行は、想像以上に大きな変化でした。
要件定義という名の交渉術
SEになって最初に戸惑ったのは、顧客とのコミュニケーションでした。プログラマー時代は「仕様書に書いてあること」を実装すればよかったのですが、SEは「何を仕様書に書くか」を決めなければなりません。
顧客は自分が欲しいものを正確に言語化できるわけではありません。「もっと使いやすく」「前のシステムと同じように」「でも新しい機能も」といった曖昧な要求をどう具体化するか。ここが腕の見せ所であり、苦労のしどころでもありました。
要件定義では、顧客の言葉をそのまま受け取るのではなく、その背後にある業務課題を理解することが重要です。「この帳票を追加してほしい」という要求の裏には、「月次の集計作業に3日かかって困っている」という本質的な課題があるかもしれません。表面的な要求だけを聞いていては、本当に価値のあるシステムは作れません。
私はSE時代の前半、この「課題の本質を掴む」という部分で何度も失敗しました。顧客の言う通りに作ったのに「使いにくい」と言われたり、後から「これもできると思っていた」と追加要求が来たり。そのたびに設計をやり直し、スケジュールが遅延し、チームに迷惑をかけました。
設計書という名のコミュニケーションツール
SEとしてのもう一つの重要な仕事は、設計書を書くことです。ただし、設計書は単なる技術文書ではありません。顧客、プログラマー、テスター、運用担当者など、様々な立場の人が読むコミュニケーションツールです。
顧客向けには業務の流れが分かる外部設計書、プログラマー向けには実装の詳細を記した内部設計書、テスター向けにはテスト観点を明確にした機能一覧。同じシステムでも、読み手によって必要な情報は異なります。
私が設計書を書く上で意識していたのは、「この文書を読んだ人が次のアクションを起こせるか」という点です。顧客が承認判断できるか、プログラマーが実装に入れるか、テスターがテストケースを作れるか。そのために必要な情報が過不足なく書かれているかを常にチェックしていました。
SE時代の中盤、私は複数のプロジェクトで設計リーダーを任されるようになりました。自分が設計するだけでなく、他のSEが書いた設計書をレビューし、品質を担保する役割です。ここで学んだのは、「良い設計書」の条件は一律ではないということでした。
運用保守で見えた「作って終わり」の危うさ
SEとして10年を過ぎた頃、私は運用保守フェーズも担当するようになりました。自分が設計・開発したシステムが本番稼働し、実際のユーザーに使われる。そこで初めて見えてくる問題がありました。
開発時には「これで完璧」と思っていた設計が、実運用では使いにくかった。想定していなかった業務フローがあった。性能は十分なはずが、特定の時間帯だけ遅くなった。こうした「作って終わり」では見えない問題に直面することで、システム開発の視野が広がりました。
運用保守では、障害対応も重要な仕事です。深夜に本番障害の連絡が入り、急いで原因を調査し、暫定対応と恒久対策を立てる。この経験を通じて、システムの「継続性」を支える仕組みの重要性を身をもって学びました。
また、運用チームや保守チームとの連携も、この時期に深まりました。開発側の論理だけでシステムを作っても、運用できなければ意味がありません。運用担当者が監視しやすいログ設計、保守担当者が対応しやすいエラーメッセージ、ユーザーが自己解決できるマニュアル。こうした「作った後」を意識した設計ができるようになったのは、運用保守の経験があったからです。
SE時代に培った「全体を見る目」
SE時代の17年間で、私は様々な業種・規模のプロジェクトに関わりました。小規模な追加開発から、数十人規模の刷新プロジェクトまで。その中で気づいたのは、プロジェクトの成否を分けるのは技術力だけではないということです。
顧客との信頼関係、チーム内のコミュニケーション、スケジュールとリソースの調整、リスクの早期発見と対応。こうした「技術以外の要素」がプロジェクトを左右します。優れた設計書を書いても、チームがバラバラでは良いシステムは作れません。逆に、技術的には平凡でも、チームがうまく機能すれば、顧客満足度の高いシステムができます。
SE時代の後半、私はプロジェクト全体を俯瞰する視点を持つようになっていました。自分の担当範囲だけでなく、プロジェクト全体のスケジュール、品質、コスト、リスクを意識する。これが、後にPMOとして働く上での土台になりました。
PMOへの転身:マネジメントを支える専門職として
2014年頃、私はPMO(プロジェクトマネジメントオフィス)としてのキャリアをスタートさせました。SE時代の終盤、大規模プロジェクトでプロジェクト支援の役割を任されたことがきっかけです。
PMOとは何をする人なのか
PMOという職種は、日本ではまだ定義が曖昧です。企業やプロジェクトによって役割が異なり、「PMの補佐」「進捗管理の専門家」「事務局」など、様々な捉え方があります。
私が担当しているPMOの役割は、主に以下の4つです。
- 進捗・工数管理: プロジェクト全体の進捗状況を可視化し、遅延リスクを早期に検出する
- 障害管理: 本番障害やプロジェクト課題を一元管理し、対応状況を追跡する
- 顧客折衝: プロジェクトマネージャーと顧客の間に立ち、情報伝達と調整を行う
- ベンダーコントロール: 複数のベンダーが関わるプロジェクトで、調整と品質管理を担う
PMOはプロジェクトマネージャーではありません。意思決定の権限はPMが持ちます。しかし、PMが適切な意思決定をするために必要な情報を整理し、選択肢を提示し、実行を支援するのがPMOの仕事です。
PMOに求められるスキルは「現場経験」だった
PMOになって最初に感じたのは、「これまでの経験がすべて活きる」ということでした。プログラマー時代に培った技術的な理解、SE時代に学んだ顧客折衝と設計の視点、運用保守で得た「作った後」の意識。これらがすべて、PMOとしての仕事に直結していました。
例えば、進捗管理では、開発者が「80%完成」と報告してきても、その実態を見抜く目が必要です。本当に80%なのか、それとも「見た目は動いているが内部は未実装」なのか。プログラマー経験がなければ、この違いは分かりません。
顧客折衝でも、SE時代の経験が活きます。顧客の要求をそのまま開発チームに伝えるのではなく、背後にある課題を理解し、実現可能な選択肢を提示する。これはSE時代に何度も繰り返してきたプロセスです。
PMOの仕事には、マネジメントの知識も必要です。私はPMBOK(プロジェクトマネジメントの知識体系)やPMP資格の内容も学びましたが、正直に言えば、資格の知識だけでは現場では通用しません。理論と実務の間には大きなギャップがあり、そのギャップを埋めるのは現場経験しかありません。
PMOとして最も重要な能力は「調整力」
PMOとして10年以上働いてきて、最も重要だと感じるのは「調整力」です。これは単なる交渉術ではなく、異なる立場の人たちの利害を理解し、全体最適の解を見つける能力です。
プロジェクトには様々な立場の人が関わります。開発を急ぎたい顧客、品質を担保したい開発チーム、コストを抑えたい経営層、納期を守りたいPM。それぞれの主張は正しく、しかし同時に満たすことは不可能です。
PMOの役割は、この複雑な利害関係の中で、「今、最も重要なことは何か」を見定め、関係者が納得できる落としどころを見つけることです。これは正解のない問いであり、プロジェクトごと、状況ごとに答えが変わります。
私がPMOとして意識しているのは、「誰かを悪者にしない」ということです。顧客が無理を言っているわけでも、開発チームが怠けているわけでもありません。それぞれが自分の立場で最善を尽くしている。その前提に立った上で、全体を俯瞰し、調整する。これがPMOの仕事です。
現在も現役:PMOとしての日常
現在、私は複数のプロジェクトでPMOを担当しています。日々の業務は多岐にわたりますが、基本的には「プロジェクトを円滑に進めるためのあらゆる支援」です。
月曜日はプロジェクト定例会議で進捗報告、火曜日は顧客との調整会議、水曜日は障害対応の状況確認、木曜日はベンダーとの品質レビュー、金曜日は翌週の計画調整。合間に突発の障害対応や、PMからの相談対応が入ります。
地味な仕事が多いですが、この「地味な積み重ね」がプロジェクトの安定稼働を支えています。PMOがいなくてもプロジェクトは回るかもしれませんが、PMOがいることで、PMはより戦略的な判断に集中でき、開発チームは開発に専念できます。
PMOは表舞台に立つ仕事ではありません。プロジェクトが成功すれば、称賛はPMや開発チームに向かいます。それでいいと私は思っています。縁の下の力持ちとして、プロジェクトを支える。それがPMOの役割であり、私が30年のキャリアの末に選んだ立ち位置です。
なぜ私はPG→SE→PMOというキャリアを歩んだのか
ここまで、私のキャリアを時系列で語ってきました。では、なぜこのようなキャリアパスになったのか。構造的に振り返ってみたいと思います。
IT業界特有の「現場経験の積み上げ」構造
IT業界のキャリアは、多くの場合「現場経験の積み上げ」で形成されます。新卒で入社すればまずはプログラマー、経験を積めばSE、さらに進めばPMやPMO。これは業界の構造的な特徴です。
なぜこのような構造になるのか。それは、IT業界が「経験知」に大きく依存する業界だからです。プログラミングも、設計も、プロジェクト管理も、教科書通りにはいきません。実際にコードを書き、バグに苦しみ、顧客と交渉し、納期に追われる。そうした経験の中でしか学べないことが山ほどあります。
私のキャリアも、この「経験の積み上げ」の典型例です。プログラマーとして8年間、コードと格闘したからこそ、SEとして設計する時に「実装可能性」を判断できました。SEとして17年間、顧客と開発チームの間で調整してきたからこそ、PMOとして全体を俯瞰する視点を持てました。
「技術」から「人」へのシフト
私のキャリアを振り返ると、関心の中心が「技術」から「人」へとシフトしていったことが分かります。
プログラマー時代は、コードの美しさや効率性に関心がありました。いかに短いコードで機能を実現するか、いかに高速なアルゴリズムを実装するか。技術そのものが面白かったのです。
SE時代は、顧客の課題をいかに解決するかに関心が移りました。技術はあくまで手段であり、重要なのは「顧客が何に困っているか」「どうすれば業務が楽になるか」です。技術より人の方が難しく、そして面白いと感じ始めました。
PMO時代は、プロジェクトに関わる人々全体をいかに円滑に機能させるかが関心の中心です。顧客、PM、開発チーム、運用チーム、ベンダー。それぞれが異なる目標と制約を持つ中で、どうすればプロジェクト全体が前に進むか。人と人の間に立ち、調整することに、私は今、最もやりがいを感じています。
このシフトは意図的だったわけではありません。ただ、目の前の仕事に取り組んでいるうちに、自然と関心が移っていきました。そして振り返ってみれば、それは「技術」から「人」への成長プロセスだったのだと理解できます。
「専門性」の再定義
PMOは専門職ですが、その専門性は単一のスキルではありません。技術理解、マネジメント知識、コミュニケーション能力、調整力、そして現場経験。これらすべてが組み合わさって、初めてPMOとしての専門性が成り立ちます。
プログラマーの専門性は「コードを書く能力」、SEの専門性は「システムを設計する能力」と、比較的明確です。しかしPMOの専門性は、「プロジェクトを支援する総合力」としか言いようがありません。
この「総合力」は、一朝一夕には身につきません。私の場合、プログラマー8年、SE17年という積み重ねがあって、ようやくPMOとしての仕事ができるようになりました。逆に言えば、これまでの経験すべてが、今の専門性を形作っているのです。
IT業界でキャリアを積むということは、単一のスキルを深めるだけでなく、複数の視点を統合していくプロセスでもあります。私のキャリアは、その一つの実例に過ぎません。
現代のITキャリア構築:あなたならどう歩むか
私が歩んできたキャリアパスは、あくまで1994年から2024年までの30年間という時代背景の中でのものです。今、ITキャリアを考える方にとって、同じ道が最適解とは限りません。時代は変わり、技術も変わり、働き方も変わっています。
変わったこと、変わらないこと
私がプログラマーを始めた1994年と現在では、IT業界は劇的に変化しました。開発言語はCOBOLからPython、クラウド、AI/MLへ。開発手法はウォーターフォールからアジャイルへ。働き方もオフィス勤務からリモートワークへ。
しかし、変わらないこともあります。システム開発の本質、顧客の課題を解決するという目的、チームで働くことの重要性、現場経験でしか学べないことがあるという事実。これらは30年前も今も変わりません。
現代のITキャリアを考える上で重要なのは、「変わったこと」に適応しつつ、「変わらないこと」を大切にすることだと私は思います。新しい技術を学び続けることは必要ですが、それ以上に、現場での経験を通じて「技術以外のこと」を学ぶことが、長期的なキャリアを支えます。
キャリア構築を支える現代のツールとコミュニティ
私の時代と大きく異なるのは、キャリア構築を支援するツールやコミュニティが充実していることです。
LinkedInやWantedlyなどのキャリアプラットフォームでは、他の人のキャリアパスを参照できます。PMOとして働いている人がどんな経歴を持っているか、どんなスキルを身につけてきたか。こうした情報は、私の時代にはありませんでした。他人のキャリアを参考にしながら、自分の方向性を考えることができます。
オンライン学習プラットフォーム(Udemy、Courseraなど)では、プロジェクトマネジメントやアジャイル開発など、現場で必要なスキルを体系的に学べます。私はOJT(オン・ザ・ジョブ・トレーニング)で学ぶしかありませんでしたが、今は事前に基礎知識を得てから現場に入ることができます。
エンジニアコミュニティ(勉強会、技術カンファレンス)も豊富です。同じ職種、同じ技術領域の人たちと交流することで、自分の立ち位置や次のステップが見えてきます。私も最近はオンラインの勉強会に参加し、若手エンジニアの視点から刺激を受けています。
ただし、これらのツールやコミュニティは、あくまで「参考情報」です。最終的には、自分自身の現場経験が最大の教材になります。オンラインで学んだ知識を、どう現場に適用するか。他人のキャリアパスを見て、自分はどう歩むか。主体的に考え、選択することが重要です。
資格は必要か:PMOに求められる証明とは
PMOを目指す方からよく聞かれるのが、「資格は必要ですか」という質問です。PMP(プロジェクトマネジメント・プロフェッショナル)、PMO-CP(PMOスペシャリスト認定)、ITコーディネータなど、関連資格はいくつかあります。
私自身は、これらの資格を持っていません。それでもPMOとして仕事ができているのは、現場経験が評価されているからです。ただし、資格が無意味だとは思いません。資格取得のプロセスで体系的な知識を得られますし、特に転職市場では資格が有利に働くことも事実です。
私が考える資格の位置づけは、「あれば有利、なくても致命的ではない」です。資格よりも重要なのは、「この人はプロジェクトを支援できる」という信頼を現場で得ることです。その信頼は、日々の仕事の中で、小さな成功を積み重ねることでしか得られません。
もしあなたが今、PMOを目指しているなら、資格取得と並行して、現在の職場で「PMO的な仕事」を少しずつ引き受けることをお勧めします。進捗管理の補助、会議の議事録作成、課題管理の整理。どれも地味な仕事ですが、これらを丁寧にこなすことで、PMOとしての基礎が身につきます。
30年現場にいた私が思うこと:キャリアは「線」ではなく「点の連続」
30年のキャリアを振り返ると、私は明確なキャリアプランを持っていたわけではありませんでした。「5年後にはSEになる」「10年後にはPMOになる」といった計画は一度も立てたことがありません。ただ、目の前の仕事に全力で取り組んでいたら、いつの間にかここにいた。それが正直なところです。
計画通りにいかないからこそ面白い
キャリアというのは、計画通りにはいきません。予期せぬプロジェクトへの異動、会社の方針転換、技術トレンドの変化、個人的な事情。様々な要因が絡み合って、キャリアは予測不可能な方向に進みます。
私も、COBOLプログラマーとしてスタートした時、まさか30年後にPMOになっているとは想像もしていませんでした。SE時代には「一生SEでいい」と思っていましたし、PMOという職種が存在することすら知りませんでした。
しかし、振り返ってみれば、その時々の選択が自然と次の道につながっていました。プログラマー時代に真面目にコードを書いたから、SEとして設計できた。SE時代に顧客と真摯に向き合ったから、PMOとして調整できる。点と点が線でつながる瞬間を、後になって何度も経験しました。
スティーブ・ジョブズの有名なスピーチに「点と点をつなぐ」という話があります。まさにその通りで、キャリアは後から振り返って初めて「ああ、あの経験が今につながっているんだ」と分かるものです。
「現場」にい続けることの価値
私のキャリアで一貫しているのは、「現場」にい続けたということです。管理職になる選択肢もありましたが、私は現場のプレイヤーであり続けることを選びました。
現場にいることの価値は、リアルな課題に直面し続けることです。理論や知識は本でも学べますが、「この顧客はなぜこう言うのか」「このベンダーはなぜこう動くのか」といった生々しい現実は、現場でしか分かりません。
PMOという職種も、現場の仕事です。毎日、具体的な進捗を確認し、具体的な課題に対応し、具体的な人と調整する。この「具体性」が、私の仕事の面白さであり、価値の源泉です。
もしあなたが今、キャリアの岐路に立っているなら、「現場に残るか、管理職になるか」という選択に直面するかもしれません。どちらが正しいということはありませんが、私の経験から言えるのは、「現場にい続ける」という選択肢も十分に価値があるということです。
次の10年をどう歩むか
私は現在50代半ばで、定年まであと10年ほどです。この10年をどう過ごすか、最近考えることが増えました。
技術は日進月歩で進化し続けています。AI/ML、クラウドネイティブ、DevOps。私が学んできた技術の多くは、もはや古いものになりました。新しい技術を学び続ける必要はありますが、正直に言えば、若手には追いつけない部分もあります。
しかし、30年の現場経験で培った「人を見る目」「プロジェクトを見る目」は、若手には簡単には身につかないものです。この経験知を、どう次の世代に伝えていくか。それが、私の次の10年のテーマになると思っています。
PMOとして現役で働き続けながら、若手の育成にも関わっていく。オンラインでの情報発信も増やしていく。自分の経験が、誰かのキャリアのヒントになれば、それは嬉しいことです。このブログもその一環です。
あなたへのメッセージ:明日からできる小さな一歩
長々と自分のキャリアを語ってきましたが、最後に、PMOを目指すあなた、またはITキャリアに悩むあなたに、明日から取り組める小さなアクションを提案したいと思います。
今の職場で「全体を見る習慣」を始めてください。
あなたが今、プログラマーならば、自分の担当モジュールだけでなく、システム全体の構造を理解しようとしてください。あなたが今、SEならば、自分の担当機能だけでなく、プロジェクト全体のスケジュールやリスクに関心を持ってください。
PMOに必要なのは、「全体を俯瞰する視点」です。この視点は、特別な訓練で身につくものではありません。日々の仕事の中で、少しだけ視野を広げる。それを続けることで、自然と「全体を見る目」が養われます。
具体的には、こんな小さなことから始められます。
- プロジェクトの定例会議で、自分の担当以外の報告にも注意を向ける
- 他のチームメンバーの進捗状況を気にかけ、困っていそうなら声をかける
- 顧客との会議に同席する機会があれば、積極的に参加する
- 障害が発生した時、自分の担当外でも原因と対策に関心を持つ
どれも地味な行動ですが、こうした「少しだけ視野を広げる習慣」の積み重ねが、やがてPMOとしての基礎を作ります。
キャリアは長い道のりです。焦る必要はありません。今日、目の前の仕事に誠実に向き合い、少しだけ視野を広げる。それを続けていれば、5年後、10年後、あなたは自分でも予想しなかった場所に立っているかもしれません。
私がそうだったように。
あなたのキャリアが、充実したものになることを願っています。もし迷った時、この記事を思い出してもらえれば嬉しいです。現場にいる一人の先輩として、あなたを応援しています。
コメント