ＰＭＯってなによ？。うちのマネジメント部署のキャリアパスとかそんなん。

※注。ろくろを回す系のおしごとではありません。

弊社には、開発側の部隊とは別に、ＩＴ関連のマネジメント・ＩＴコンサルティングを主業務とした部署がありまして。なんだかんだ2017の年末くらいからやってるんですが、なにしろこの事業部のひとらは【マネジメント】と言う汎用性の高い専門分野をお持ちなもんですから、他の社内向けの推進業務がいろいろあったりしまして。なかなか採用向けのフィードも書いてくれません。

だからって、オレが書くのか？

記事の質が微妙なのはご容赦な！
（PMOって難しいよね。）

まず、この事業部は『ＩＴコンサル事業部』と銘打っております。
正直、コンサル？な部分もあるんですがね。キャリアパスの到達点としている職種が、かなりITコンサルちっくな要素を要求されるお仕事でして。まあいいかと。

あとね、PMOとか言ってもね。だいたい

《伝わらない。》

求職者はもちろん、発注者にもワリと伝わらない。(※１)

しかし、ニーズは強いとか言う、よくわからない市場なのであります。
※まず、ほとんど待機しない。仕事選ぶと普通にスキルアップもできる。また、採用面ではエンジニアよりもだんぜん採用が難しい。

なので、わかりやすく『ＩＴコンサル事業部』と、しております。
実際には、（ガチな）PMOや、PM、ITディレクターと言った職種が所属している《マネジメント成分がほとんど》な部署です。まあ、エンドやベンダーに対してコンサルティングするような要素もあるか。

とりあえず、鬼マネジメントする人たちの専門部署です。

1.目的って、なによ？

ITコンサル事業部の目的は、顧客のニーズの解消とシステム開発の目的の不一致に起因するシステム開発の失敗を解消すること。なんですが。

要は、クライアントってふつうＩＴの会社じゃないんだからＩＴには詳しくないし、プロのＰＭがたくさんいる訳でもない。（解雇制限があるからほいほい雇用もできない）そこを専門家集団で支援してやって、ちゃんとクライアントのビジネスに資する形に、安全に、外部への発注もスムーズに。　やれるようにしましょうって話です。

外部への発注がスムーズになると言う事は、弊社のシステム開発側の部隊も安全に受託開発やアジャイルチームによる常駐支援ができるようになるワケでして。と言うか、ここまでやらんとふつうに儲かる請負とかないなと思っているので、システム開発事業部側にとっても、コンサル事業部との連携と言うのが将来のビジネス展開に置いて大前提になってくる訳です。

また、当のＩＴ業界（ベンダー界隈）側も、『システムエンジニア』がやりたくてこの業界に入ってきた人たちが大半。それがいきなりマネジメントをやらされる系の話が多い訳でして、この界隈でも専門職のマネジメント部隊の支援のニーズが激高だったりします。

こんな市場なので、この需給のギャップを生む構造を利用して専門的な人材を育成。他事業部・業務提携先などとの連携時にビジネスを推進できるメンバーの確保できる。と言う副産物も考え、ビジネス育成実行中なのです。

2.どういう職種があるん？【キャリアパス】

※あくまでうちの内部での住み分けね。

・PMO

チームを組んで、プロジェクトを円滑に進められるよう、プロジェクトマネージャーの支援を行う人たちです。弊社内では下記のようにランクを分けています。高度になるほど、プロジェクトに関わる管理だけではなく推進していくことが求められます。また、関わるプロジェクトの本数や規模も大きくなって行きます。プロジェクト運営上、必要な情報を引き出して伝えたり、咀嚼して伝わる言葉に直したり。膨大な情報のやり取りを支えるHUBのような立ち位置でもあります。待っているだけの人だと、そのPMOは不要と言う事になります。

1.見習い
2.アドミニストレータ
3.エキスパート
4.マネージャー

この中の《アドミニストレータ》が、業界でよく飛び交うＰＭＯ事務、PMO補佐、SEサポート的な職。
あまりPMO向きではない『管理しか出来ないおじさん』が、何処に分類されるかはいまいちわからないが、アドミニストレータとエキスパートの中間くらいではなかろうかと思われる。

一般に、エキスパートのクラスはＰＭができるレベルの人材でなくてはいけないと言われる。
マネージャーはさらにPMOチームのマネジメントの他、人材育成なども可能と言う人。

・ＰＭ

本来は外部の人間がやる仕事ではないんですがね・・・。とは言え本来、非ＩＴの会社であるクライアントの内部に本職のＰＭがごろごろいる訳もなく。（ほか、日本の場合は解雇制限もあり、高額な人材の雇用は難しい）クライアントのPMの代行を行う事もあります。　

また、自社・関連会社・子会社等のシステム開発であれば、普通にPMとしてアサインされる事があります。

当事業部で言うところのＰＭはＰＭＯよりも技術者的な経験も相応に要求されるポジションとして位置付けられています。

・ＩＴディレクター

ＰＭＯよりもさらに聞きなれない職種。一部の事情（※２）でＰＭＯのイメージが悪いベンダーや顧客が増えてきたが故の造語かと思われる。うちの育成上のゴールにとても近いので、そのまま頂いた。

ユーザーニーズの発掘・把握から、それの実現方法の提案、そして、実現する為の方法の選択と、実施、ベンダーコントロールまでを行うポジション。エンド側のＰＭＯに加えてＩＴコンサル的な要素がかなり加わっている。　ＩＴのプロが、最初から最後までフォローするよと言う話。

弊社のビジネス戦略上で必須になる職種でもあり、いかにこのレベルの人材を開発するかが重要になる。

・資質として求められるモノ

各職種共通で、下記の様な要素。

・PDCAサイクルを回せる。
・円滑に作業する為に権限を得たい。その為に責任を負う事もいとわない。
・論理的思考能力をもっている。
・問題が発生しても、思考停止しない。
・各関係者間のコミュニケーション上のHUBになれるだけの報告・連絡・相談スキル

このように、よくあるエンジニア像とはかけ離れたキャラクターが採用イメージ時の募集イメージとなってきます。

ほか、実業務の中でドキュメント作成能力は高くなります。集計・分析の為にVBAは使えると便利。プロジェクト推進の上で使用する技術用語などもわかる必要がでてきます。マルチタスク処理能力も要求されるようになるでしょう。当然、プロジェクトマネジメントの考え方も学んでいかなくてはいけません。

このあたりは実務と訓練でなんとかなるんじゃあるまいか。

３．立ち位置による業務の違い（難易度の違い）

育成の上では、参画する商流も重要な要素になってきます。とのこと。

多くの場合、セカンダリーベンダーのチームは、システム全体ではなく、サブシステムをいくつか担当しますよくらいの立ち位置でプロジェクトに参加してくる。このセカンダリーベンダーのプロジェクトを支援する場合、ＰＭＯは複数のサブシステムを横断して担当する事になる。各ＰＬ／ＰＭからの情報の吸い上げを行う事になる。逆に、認識齟齬なく指揮命令を各ＰＬ／ＰＭに情報と伝達手段を提供するのもお仕事。

それに対し、プライマリーベンダーはシステム全体を横断した関わり方をする（当然だが）為、ＰＭＯは全システムを横断し、各ベンダーからの情報の吸い上げを行う事に。対クライアントのエスカレーションも発生する事になる。

クライアント側での支援となると、システム開発全体に加え、顧客内の複数部署を（ＩＴ部署と、システムを利用する事業部側）などとなり、さらに関連する範囲が広がり難易度は上昇。クライアントと言うまったく異業種の違うビジネス構造の相手と話をし、背景を理解していけなくては、勝負にならない。

４．一部の事情（※1、※2）

一部のクライアントやベンダーがＰＭＯと聞いてやな顔する理由。

『本職も適性もＳＥなのだが、なんかの理由でＰＭＯにされた』人だったり、『ＩＴ事務員で会社に入社したら、ＰＭＯで派遣された』的な、適性以前にPMOと言う職種でやっていく気もない人たちが投入されてくる為です。

各関係者間の情報を流通させ、調整を行う人たちであるにもかかわらず。摩擦を避ける為に情報を自分のところで堰きとめたり、責任を回避する為に権限を最小化する事に拘って板ばさみになってみたり。状況を見て自分で考えて判断しているとは思えないような消極性や、事なかれ、他責スタイルの方々が、かなりの比率で存在する。（たぶん、SEより比率高い。）

そんなわけでPMOと聞いても、