どうも!
太田フランクリンとみこみこです!
今回は
- 『PMOってどんな職業?』
- 『エンジニアから転職を考えている』
- 『どんな人がPMOにむいているの?』
- 『PMOって実際何をしている?』
などの疑問に、
現役のPMOの方に解説していただこうと思います!
太田フランクリンと言います。
もともとSE(システムエンジニア)をずっとやっていましたが、
今はフリーランスでITコンサルタントとして働いています。
プロジェクトでは現在『PMO』として働いています。
現役PMOからリアルなお話を聞ける機会です!
ITコンサルタントとしての知識を身につけて
自分の可能性を最大限に引き上げていきましょう!
PMOとは?
『PMO』とは何なのでしょう?
僕はもともと『SE(システムエンジニア)』をやっていました。
SE目線で、PMOの人が何をやっているのかわからなかったです。
まず案件に入ると、プロジェクトの体制図があります。
PMがいて、メンバーがいて、PMOの役割の人がいます。
PMO(Project Manegement Office)
「プロジェクトマネジメントとしての支援が必要だと判断した場合」に
ITコンサルタントの中でも、
進捗状況・リソース・コスト管理などに特化した能力を発揮するのがPMOです。
【ITコンサルタントとは】
IT戦略の策定支援、システム構想の策定、またDX推進支援などといった、
様々な「ITに関する業務を支援する」役割を持っています。
ITコンサルタントの主な業務として
- 問題の発見・提示
- 課題解決
です。
クライアント企業の問題を見つけて分析・解析を行います。
解決策を導き出すためには
クライアント企業の膨大なデータの把握が必要不可欠となります。
ITコンサルタントは
その膨大なデータの中から的確に問題点や課題などをみつけて、
解決策および筋道を
論理的思考で導き出すといった能力を求められてます。
https://www.itmanage.co.jp/ より画像引用
【PM・PMO:体制図】
https://it-trend.jp/project_management/article/33-0057#d0e9d87eb78fa54e47cd213ca7606442
↑より上記画像引用
「プロジェクトマネジメントを行う組織・役割」のことを
まとめてPMOと呼びます。
文脈によってはPMのことをPMOと言い換えることもあります。
PMの仕事を一部やったり、やらなかったりというのがPMOの日常です。
つまりPMOの仕事を理解するにはまず、
PMの仕事を理解しなければなりません。
それってPMO?
まず、同じPMOでも私の中で
・ちゃんとしてるPMO
・ちゃんとしてないPMO
の2種類に分かれるので説明します。
ちゃんとしてないPMOって?
- 議事録だけ書く
- 会議の調整だけする
大学生インターンやパートさんでも誰でもできる仕事、
雑務をメインで行うことで
PMOとしての単価も下がってしまいます。
PMOだと言ってアサイン(任命)されたのに、
実際は会議調整や議事録など
雑用ばかりしています。
「それは本当にPMOなのか?」
と思うところはあります。
ちなみに議事録そのものは奥が深く、
あくまでもPMOの仕事の一環でとても大事な作業です。
【議事録】
- 会議や打ち合わせの内容
- 経過
- 結論
などの記録をして、
さらに周囲にわかりやすく伝えるために
資料としてまとめた物のことをいいます。
ただ「会議の内容をきれいに書いたもの」ではありません。
https://raku2con.com/minutes/ より画像引用
つまり今回話したい
『PMOについての話』=『PMについての話』
ということになります。
一部をやる、やらない、
色々決めてやるところなので
基本的にPMの話をします。
ちなみにPMがいる時点で補佐は必要なのでしょうか?
【PMOの必要性】
PMOの必要性はプロジェクトの大きさによります。
極端な話
プロジェクトメンバーが二人しかいなかったら、
PM一人とメンバー二人となります。
例えば…
居酒屋のアルバイトで『バイトリーダー』がいて、
その人が管理・指示をするバイトのメンバーは
10人いるとします。
管理しきれますか?。
というように、成り立ちませんよね。
管理できる人数は1人で10人もできないのが現実です。
プロジェクトは作るシステムの規模に応じて
どんどんと巨大化していきます。
数十億円などの規模になると
プロジェクトの人数が
- 100人~
- 200人~
といった世界にもなります。
PM一人では到底回しきれません。
そこでPMOというPMを補佐する人が何人か配置されます。
https://rakumane.net/pmo/ ↑より上記画像引用
さらに細かく説明すると
実際のメンバーとの間に
「PL(プロジェクトリーダー)」
と呼ばれるリーダーも必要となります。
(ベンダーやプロジェクトの文化により呼び名は変わります。)
規模が大きくなってくると
PMOという中間管理職が入ってきます。
管理される人が多ければ多いほど、
管理する人も増やさなきゃいけませんね。
【例:PMが1人、メンバーが10人の場合】
「メンバー×0.1」すると必要なPMOの数がわかります。
メンバーが20人、30人なら
PMOは最低2、3人は必要だと思います。
また、多すぎても指示役が複数人になってしまい、
メンバーは
と混乱してしまいます。
なるべく漏れやだぶりを減らすように考えてチーム分けをします。
ITシステムを例とすると
担当する業務ごとに分けるなどです。
【例①:業務ごとに分ける】
金融を例とします。
- 売り
- 買い
で、それぞれ業務を分けます。また、
- 先頭業務
- 発注業務
- 受注業務
- 金融商品開発
など、業務ごとに機能が作られていきます。
そのチームごとに担当のPMOを配置します。
【例②:管理する領域で分ける】
管理する領域でPMOを分けることもあります。
〈PMの業務〉
- 進捗管理
- 品質管理
- ※ステークホルダーとの調整
など、他にもPMの業務内容はたくさんあります。
https://www.i-think.co.jp/about/project-management/
その中のいくつかのタスクを
それぞれのPMOに渡すことで
PMの仕事を各PMOが担当し、
プロジェクトを回すという構図もできる、ということです。
- 株主
- 経営者
- 従業員
- 顧客
- 取引先
- 金融機関
- 行政機関
- 各種団体
など、企業の様々な利害関係者のこと。
利益、損失など
何かしらの影響を企業に及ぼす存在は『ステークホルダー』となる。
必ずしもその利害は一致しない。
それぞれのPMOがどのように分かれるのかは
PMに決定権があるということですね。
PMOからも『これがやりたい』といえるので、
そこは普通の会社と一緒です。
適材適所に配置をするアサイン権は
基本的にはPMが持ちます。
PMOはPMの補佐として、
担当の役割や領域を任されるので
そこの責任を全うする、といった感じです。
PMOの仕事内容
PMOの仕事内容を確認するためには
まずPMの仕事を理解していきましょう。
PMって何の略かというと
「プロジェクトマネジメント」
プロジェクトはプロジェクト、
マネジメントは『管理』です。
様々なプロジェクトには、必要な管理がたくさんあります。
例えば…
- 進捗管理
- 品質管理
- 課題管理
- タスク管理
- 要員管理
- 予算管理
など、
そのプロジェクトの文化により呼び名は変わりますが、
様々な管理をPMは任されます。
発注主から予算を渡されて、
予算内でプロジェクトを運営するように任される。
その中でいくつか必要な管理項目があり
PMOと分担、協力して進める。
【例①:課題管理】
わかりやすくカップラーメンで説明します。
『カップラーメンを作るというプロジェクト』
タスク1~6
- カップラーメンを買いに行く
- 買いに行って家に戻ってくる
- お湯を沸かす
- 蓋をはがしてお湯を入れる
- 3分待つ
- 食べる
例えばこの中の課題で
といった状況が発生した場合、
プロジェクトが進められません。
このような課題が派生したときにPMが
という方針を打ち出したり、
といったアサインをしたりと指示を出します。
このような場合、
普通のメンバーは予算についての判断はできません。
予算を捻じらないといけないときに出場します。
手が回らないPMの代わりに、PMOの判断で
『予算は1000円で大丈夫です。』
と指示を出すことができます。
課題管理はPM・PMOでないとできないことが多いです。
もちろん小さい課題は各メンバー・SEなど現場に任せます。
・「蓋がはがせません」→誰でもいいのではがしてもらいましょう。
・「お湯の沸かし方わかりません」→あそこにあるT-fal使ってね。など
課題管理はプロジェクト内にたくさんあります。
それを一つ一つ管理して、
誰かに渡したり方針を打ち立てるのがPMOの仕事です。
【例②:進捗管理】
次に進捗管理も重要です。
もともとSEだったみこみこ君はわかると思うけど、
『WBSに沿ってこのタスクをこの期日内に終わらせる』
という指令があったと思います。
そのWBSは誰が作っていたのか覚えていますか?
<WBSとは>
「作業分解構成図」こと。
プロジェクトのスケジュール管理で使用するツールの1つ。
作業工程を細かな作業(Work)に
分解(Breakdown)をして、
構造化(Structure)し、管理する手法です。
PMが作るのだけれど、
プロジェクトの規模が大きくなってくると
一人で作り切れないため
PMOが一部作ることもあります。
PMOが領域ごとに担当しているため、
『ここの領域・機能のWBSはそこを担当しているPMOが作る』
となります。
作れたら管理も必要です。
例えばWBSをチェックして
「カップラーメンが売り切れでした。」
「すぐに入荷すると思いました。」
というように、
タスクの管理、進捗を管理する中で
一人一人のタスクを確認し
何か課題が発生してないかチェックすることもPMの仕事です。
プロジェクトの進行というのは
タスクの積み重なりということです。
新たな課題が発生したら、
一つ一つ解決していかなければなりません。
【例③:要員管理】
「WBSを常にチェックする」といったことから、
『要員管理』に繋がります。
(要員=プロジェクトメンバー)
PMは
『プロジェクトの責任を持つ』と決められているため
プロジェクトメンバーの配置は基本的にPMが全て決めます。
そしてそのアサイン権は一部、
PMOに委譲する場合もあります。
その場合はPMOが実際現場の『要員管理をする』ことになります。
例えば現場から
- 「○○君の態度が悪いです」
- 「○○君が仕事中ずっとスマホをいじってます」
と声が上がれば、
- PMOがパトロールをして確認
- 進捗の確認、指導
- 要員管理の一環としてプロジェクトリリース・配置換え等を行う
別の業務への移動はPM・PMOの判断に任されます。
また、クライアントからの予算と照らし合わせて、
その予算内で人員が収まっているのかという判断も必要です。
【1000万円でシステムを作るという依頼の場合】
「SE/一人当たり人月100万円」だとして10人いれば作れますが、
1000万円の予算→1000万円の人員=利益にならない
こういった場合は
利益を出すための計算・要員管理もPMの仕事です。
5人で作れるシステムを「1000万円」とクライアントに伝え、
「差額500万円」の利益を得ることも手法です。
PMがPMOに要員管理を一任している場合もあります。
・PMO(予算などの計算)→PM(確認)→クライアントに報告
【タスク化しづらい、その他の業務】
代表的な業務のうち管理項目というところを簡単に説明しました。
それ以外のPMOの業務として
- 議事録作成
- 会議の手配
- メンバーへの業務説明・準備
- 掃除
などもあります。
会議調整やクライアントとの日程調整などは
ほとんどが雑用です。
なぜPM・PMOがやるのかというと
SEには時間がないからです。
彼らには決められた納期・決められた成果物があり、
「期間内に作業を終わらせなければならない」というミッションがあります。
グーグルカレンダー全員分を見て、
空いてるかの確認は誰でもできますよね。
クライアントからの要望で行われる
クリーンオフィス・クリーンデスク化や、
新しいメンバーの管理、
パソコンを運んだりするところもあります。
などといった手配も、
雑用はすべてPM・PMOがやります。
「これはめんどくさいからみこみこ君にやらせろ」となったのでしょう。
あくまで仕事の一次請けはPMであり、PMOです。
プロジェクトの管理・運営をする中で必要な仕事を
PM・PMOで協力してやっているのが実態です。
わかりやすい例えでいうと
SEの自分がやっていなかったことを全部やっている
と思ったほうがいいです。
WBSにかかれてないものは全部やっていますね。
PMが「忙しい」と言ったら補佐のPMOがやります。
そういったところに価値を見いだせる人間性でないと
続かないのが現実です。
他のプロジェクトとの違い
プロジェクトには様々な役割があります。
- PM
- SE
- SEの中でもプログラマー、コーダー
などがいるとします。
(SE:手を動かして成果物を作ってくれる人)
ベンダーやプロジェクトによって、
このPMとSEの間にPL(プロジェクトリーダー)
という人を配置することもあります。
自社で全部解決していたのではないかと思いますね。
PMOがいらなかった部署だったかもしれないです。
ここではPL、もしくはPMOという役割がいるとしましょう。
SEとの違いをわかりやすく説明すると、
PMOはタスク管理をされにくいというところです。
『設計書を作る』
『プログラミングソースを作る』
などのように、
成果物がはっきりしていることが多いです。
一方でPLやPMOは、
指示することが仕事です。
『このプロジェクトを運営してください』
と渡されても
何をすればいいのかわからない人も出てきてしまうようです。
フランクリンさんがそうなってしまった時、
どうしたのでしょう?
PMOとして何をしたらいいのか?
1、プロジェクトの中身の文化を探る
『今の工程はここだから、今必要なものはこれで…』
と考えると、PMOとしてやることが見えてきます。
WBSとかがもともとあったり、他のプロジェクトを参考にして作ることができます。
2、プロジェクトに必要なものを見極めて人員を確保
『これを作る人を探さないと』『どのように仕事をアサインしよう』
必要なものがわかれば必要な要因もわかります。
3、わからなければ人に聞けばいい
PM(上司)の下につくのがPMO(部下)です。
それでもわからなかったらお客さん・クライアントに聞くしかありません。
『120%で答える』のが
我々コンサルタントの仕事です。
そのレベルである自分の現在値を把握してもらったうえで、
恥ずかしいかもしれないし
馬鹿にしているように受け取られるかもしれませんが、
クライアントに確認することが間違いありません。
PMOは必要?
自走できればできる組織であればあるほど
管理職は必要ありません。
アメリカのシリコンバレー等の一流エンジニアは管理されません。
=アメリカのエンジニア達の価値はとても高いです。
- 日本の人月単価→100万程
- アメリカの人月単価→日本の数倍
と言われています。
この単価の違いは
アメリカのエンジニアは優秀ということもありますが、
「日本人がサボりがちだからから」ともいわれています。
そういう人たちがいる限り、
PMOや管理職は廃れないのではないでしょうか。
みこみこ君ももともとSEだった時は
いかにサボるかみたいなところにモチベーションがありませんでしたか?
言われたことだけをやるっていう過程ではありました。
『自主的に仕事を探す』というよりも『業務をこなす』といった過程です。
・決められたタスク
・決められた期間
「いかにその期間内に早くタスクを終わらせて残りをサボる」
といったところにモチベーションが沸いてしまうように思います。
SEの頃は
・いかに残業代をもらうか
・いかに内職するか
・いかに副業をするのか
など、くだらないところにモチベーションが沸きがちかもしれません。
「パーキンソンの法則」をご存じですか?
パーキンソンの法則
「期間を与えられたならばその期間を消化するようにできている」
夏休みの宿題、最終日にみんなやりますよね。
夏休みが10日しかなかったら、本当は10日でできます。
40日間あるから40日間フルに使ってやってしまうのでしょうね。
タスクというのも終わりが決まっていて、
終わりに合わせてみんな動いてしまいます。
我々PMOはその終わりを適切な時期に決めないといけません。
そしてその期間内に
順調な進捗を上げているのかをウォッチしないといけないのです。
やっぱり人は管理されないと仕事をしません。
そういう人がいる限りPM・PMOの仕事はなくならないのだと思います。
膨大な人が必要なプロジェクトを走らせるときは
基本、外部に発注することが多いです。
自社でやるとなると、
開発中は外部からたくさんの人を雇用しますが
その開発が終わったときに
となってしまうからです。
日本の会社は終身雇用が前提です。
その結果、外注が主流になるのです。
自社にそうそういるものでもありません。
一回もやったことがないから、プロジェクトで人を呼ぶのです。
プロジェクトというのは
「過去に一回もやったことがない
前例のない取り組みを決められた期間内にやる」です。
例えば日本の中小企業が
となったとします。
予算はあるけどやり方は誰もわからないですよね。
そこで、外部のITコンサルタントなどを雇い
PMやPMOとして入ってもらい
やり方を教えてもらう。
そこから一緒に推進していく。
人を動かす能力を持つというところで、
PMOの価値というのは下がらないですね。
主体的に動いてそこでSEの人にやってもらう、ということですね。
PMOのポジションになるには
一番のおすすめはそういう会社に入るということです。
「いい大学に入る」
「いい会社に入る」
「PM・PMOになる」
これが王道ルートです。
PMOは
外部から発注を受けて、
大きいプロジェクトを回すときに必要になります。
日本では発注を受けるときの受け口になるのが『SIer』と言われる組織です。
SIer企業
など
有名で大きい会社が一次請けになり
その一次請けで受けた会社がグループ会社などで返すこともあれば
外部に委託するということもあります。
PMやPMOの経験を積むことができます。
新卒でも2、3年現場で修行をすれば
「次はPMOの仕事をやろうね」とアサインをされます。
SIerではなく『コンサルティングファーム』なども同じです。
コンサルティングファーム企業
などは、
なるべく高単価でひとを捌きたいので
プロジェクトに人を入れるときは
ITコンサルとしてPM・PMOの枠で入れることが多いです。
最初から
『人を動かしたい』
『人を率先するリーダーシップを発揮したい』
というマインドがあるのでしたら
大きな会社に入るのが間違いないと思います。
一番は
- 学生のうちから勉強を頑張る
- いい大学に入る
- 課外活動も頑張って就活の時に力を発揮する
ということです。
5年~10年くらい働いてようやくPMOの話になると思います。
今説明したのはあくまで王道な感じです。
例えば
いきなりフリーランスになってみて、
とりあえずPMOの案件を片っ端から探してやってみる。
といった邪道な進め方でも全然いいと思いますよ。
PMOのやりがい
やっぱり仕事が大変です、でもそこにやりがいを感じます。
大変さを語る前に私も「元SE」なので
その時の話も織り交ぜながら話したいと思います。
プログラミングもやりましたが、
あの時SEとして一番しんどかった事は『設計書が適当だった』ことでした。
SEの嫌がる設計書
- 人によってやり方が変わる
- フォーマットが無意味
- 脱線している
- 内容を把握している人がいない
- たまに嘘が書いてあることもある
など、自分の中でやるしかないといった感じでした。
自分でプログラムソースなどを読みこんで、
正しい方を判断しないといけないといったSEの大変さがありました。
【PMOのやりがい①】メンバーと同じ目線
PMOはSEとは逆で、
作業を指示する側になるので
また違った大変さがあります。
例えば…
こんな時はPMに相談すると思います。
このような場合にPMは
「○○の理由でこっちが正しいね」
と一緒に考えて判断をします。
SEの人たちに作業をお願いするということは、
その作業の内容を把握しないといけない。
ITプロジェクトのPM・PMOというのは難しいとも思います。
【現場経験なし・知識なしの上司は嫌だ】
コンビニバイト歴5年で、
業務が全部わかる状態だとします。
いきなりコンビニのことを全く知らない
という人が上司になったとき、少し嫌に思いませんか?
となるのが当たり前かなと思います。
コンビニの店長をやるのであれば
コンビニ業務を1~10まで知ってる人でないと納得できない、
というのがバイトの気持ちだと思います。
それと同じ気持ちがSEとPMの間にも絶対にあるので、
なるべく自分の仕事の内どを理解している人に
PM(上司)になってほしいと思うはずです。
つまり、『SIer出身のPM』となると需要はあり続けます。
ITコンサルタントをしている方の中にも
新卒で入ったという人もいますよね?
後付けで勉強したということですか?
キャッチアップがすぐにできるのだと思います。
ある程度有名な都内の有名私大、国立出身など
受験競争に勝ち切った人たちですね。
自分で勉強する習慣がある人達は
周りから少しインプットを与えると自発的に勉強ができます。
『わからないことを人に聞ける』
コミュニケーション能力が高い状態を買われて入っている人達もいるということですね。
【PMOのやりがい②】ライフワークバランス
2つ目にPMOの仕事には終わりがない、ということです。
どこまでもやろうと思ったらやれる仕事内容なのです。
SEなどメンバーの仕事はある程度が終わりがあります。
- 設計書を書きます→できた→終わり
- プログラムソースを書きます→書いた→終わり
PMOの仕事となると
- 「どこまでこの資料をきれいに作ろう」
- 「どこまでお客さんに報告するのか」
- 「どこまで正確な情報を予算管理帳につけようか」
逆に言うと終わりがありません。
一方で、期日を人に言い渡す側になるため、
自分である程度設定できるということになります。
ライフワークバランスも自分で考えられるので、
極端な話でいうと成果主義となります。
家のほうが集中できて、
タスクの終わりを自分で決められるため、
主婦の方や遠方に住んでいる方でも可能な仕事です。
【PMOのやりがい③】年収の高さ
3つ目のやりがいは、まさしく『年収の高さ』です。
PMOの年収については、
ほぼPMに近い年収が期待できます。
- PMOの正社員の平均年収→約600~900万円
といった金額の案件が多数存在します。
「プロジェクトの管理」といった重要なポジションとなるため、
収入は高めに設定されています。
https://ageless.co.jp/media/11265 ↑より画像引用
そして、フリーランスのPMOとなると年収は大幅にアップします。
- フリーランスのPMOの平均年収→1,021万円
- 最高の年間報酬額は『2,520万円程度』とも言われている
https://tng-marketing.com/freelance/knowledge/pmo-consultant/ ↑より画像引用
もちろん案件の単価を上げるためには、経験年数や実績が必要です。
企業でPMOとしての力をつけた後、
将来はフリーランスとして独立することを検討してみる価値は十分にありますよ。
PMOの1日
基本自分の作業が中心で一日が進みます。
一週間後のこの日までに
『この設計書やプログラムを作る』
『テストを終わらせる』
などタスクを引かれています。
タスクはありません。
『どういった方針で今後進めていこうか』
といった会議を入れることが多い。
その会議に向けた資料を自分で準備します。
コンサルタントの人たちは
『powerpoint』『スプレッドシート』『Excel』等に
こだわりがある人が多いです。
あれは会議のための資料を
powerpointやスライドで作ることが日々の仕事だからです。
その他にメンバーへの作業指示や管理、コミュニケーション等を行っています。
他の会社員と同じようなことをして、あとは会議がほとんどです。
やらなければいけない事・やるべき事
好き嫌いというよりも面倒くさいイメージです。
メンバーはもちろん、
特にクライアントとの飲み会は大事にした方がいいです。
「クライアントやメンバーとの信頼を勝ち取る」ために自分の
- 細かいところに気配りできる
- 主体性がある
- コミュニケーション能力が高い
等を伝えるチャンスなとりますよ。
「コンサルタントは芸人である」 前の会社の先輩が教えてくれたとても大切な言葉です。
「プロジェクト完了後、その次のプロジェクトにもう一回呼ばれるか」
「芸人の仕事は多種多様で決まりはない、コンサルタントにも決まりはない。」
といったことを揶揄して『芸人』と言っていました。
「もう一度呼びたい」と思わせることができる人が
コンサルタントにむいている人だと思います。
『やらなければいけない事』と『やるべき事』
昔は違いがわからなかったのですが、
今は飲み会に対して『自分がやるべきこと』だと思っています。
それぞれの事情があるとは思いますが
飲み会に誘ってもいつも来ない人となると
- 「融通が利かない人」
- 「話しにくい人」
と思われてしまうかもしれません。
誘いを断られると人は心理的障壁が少しでも生まれてしまいます。
どんな理由があろうと、
仕事をするうえでその壁はない方がいい、なるべく距離が近い方がいいですね。
話をして楽しくない人と仕事はしたくない、と思います。
コミュニケーション能力の要因として
大事な人たちのマインドをコントロールする力
も大切なことです。
主体的に握るべきであると思います。
自分の価値を出せないとなると本末転倒ですよ。
PMOの方は飲み会に関して業務というよりも、
- 自分の価値を出しに行く機会
- 自分の価値を見出すチャンス
- 違う案件のアサインが決まる可能性
コミュニケーションをとる必要性があると勉強になりました。
PMOの人は、自分の価値提案をするために業務をしているのですね。
PMOはどんな人にむいているのか?
超大事なのでみなさん覚えておいてくださいね。
パターン1:エリートパターン
大手SIerやコンサルティングファームの人です。
新卒の段階、もしくはセカンドキャリアの段階で既に
上に立つべき存在としてPMOのキャリアが築かれています。
そこでコンサルティングファームを積んで
エリート街道まっしぐら」
といったタイプですね。
最初のアサイン、もしくは2回目のアサインでPMOになる人が多いです。
5年未満で
「全然経験ないのにコンサルタントをやってもいいの?」
といった状況になってしまいます。
エリートパターンの場合、
下積みがない状態で急に大きな責任を任されるため
状況を把握することに難しさを感じると思います。
しかし大体は地頭がいい人ばかりなので、
できてしまうのがすごいところです。
コミュ二ケーション能力が高いので
先輩、上司、クライアントから愛されます。
本人も自己肯定感が高い状態で
「頑張ってやっていくぞ」といった組織体になります。
パターン2:成り上がりパターン
エンジニア上がりからの成り上がりパターンです。
「成り上がり」と表現したのは
キャリアを積んで早くて5年目~10年目程でようやくPMOになれる、
という意味です。
エンジニアからの成り上がりパターンは
実力がついている状態でPMOになれるので、現場で重宝されます。
しかし個人的な意見ですが、
エンジニア上がりなだけあって
「融通が利かない瞬間がある」といった印象があります。
クライアントから急な変更や提案を受けた際など、
「できない」
「無理」
と、はっきり言ってしまうタイプの人が多いので注意です。
エンジニア上がりのPMとなると、
クライアント側から無茶ぶりもされます。
そういう時に対する言い回しで返せないということが多いです。
コンサルファーム上がりの人はコミュニケーション能力が高い、
丁寧な対応ができる印象があります。
コンサルタントは夢を語れないといけません。
エンジニアは実現性をもとにひたすら設計を積み重ねてきたので
無茶な提案をしないのです。
「できないことはできない」
といえる事はいいことですが、
果たしてそれで夢を売れるのか?というところですね。
エリートパターンの人は実際全体のPMOの1%程です。
今回この記事を読んでいる方々、
フランクリンさんも含めて
SEからPMOになる人に向けたコンテンツだと思います。
SEからPMOになった人のほうがいいと思いますか?
信頼を得られて長続きすると思います。
私はハイブリットです。
新卒でSEとしてのキャリアを積み、
その後コンサルティングファームの会社に入ったので
どちらも経験しています。
PMOはおすすめの職業?
PMOがおすすめの理由
【SEの職業寿命は短い】
若い時と同じ働き方を
50歳、60歳でできるのかどうか想像してみてください。
例えば
- 会社に出勤する
- パイプ椅子やローテブル
- 姿勢の悪い状態で腰を痛める
- ひたすらモニターを見て作業する
- 視力が落ちてきてもモニターは超小さい
- 新しい言語についていけない・覚えられない
50歳、60歳になっても
今と変わらず同じことをすると考えた時に
しんどいと思いませんか?
俺か!」
現在50歳、60歳のSEの方達は
昔はCOBOLなど化石と呼ばれる言語をやってきている人たちです。
その人たちにいきなり「PHPやRUBYを使って」と言っても
新しいことを覚えられるのか?となります。
「マネジメントスキル」
絶対にこれを覚えた方がいいと思います。
マネジメントスキルは錆びない
マネジメントスキルは錆びません。
そして経験を積めば積むほど
そのスキルの価値が出てくるものだと思っています。
例えば
経営者は経営するステップを踏むごとに
連続起業家は起業するごとに
一流になっていくといいます。
どれだけの企業を作り
どれだけの企業を※バイアウトしたのか
というところで語られるのだと思います。
経営の権利を得るために経営陣が議決権の過半数の株式を買収することで、
企業の経営権を得るといった買収方法のこと。
実績というものは自分で経験するしか身に付きません。
PMOは「マネジメント」をひたすら毎日やり続けているので
スキルが上がり、単価も上がります。
そしてエンジニアで50歳と30歳の能力が同じ人がいるなら、
30歳を採用したいですね。
将来的な資産価値的問題ですね。
50歳の人はあと10年か20年、
30歳の人はあと40年くらいだとするとそうなります。
育成コストも兼ねていると思いますね。
PMOは30歳と50歳だと50歳のほうが魅力的に見えます。
伸びしろ採用はいりませんし、
即戦力になります。
「過去幾度となくプロジェクトを回してきた」
という実績のほうに惹かれます。
PM・PMOははスポットで入ることが多く
基本プロジェクトはやり切り方です。
長いプロジェクトでも5年いてくれればいい、という考えですね。
将来のためにも
SEのままでモヤモヤしている人がいるのでしたら、
PMやPMOとしてののキャリアを歩む
という選択肢を歩んだ方がいいと思います。
PMOになるメリット・デメリット
最後にPMOになった時の『メリットとデメリット』に分けてまとめていきましょう。
PMOのデメリット
- プロジェクトの全体を膨大な資料から理解しなければならない
- タスク化できない雑用が多い
- メンバー全体を注意して管理・観察しなければならない
- 確実に利益を出さなければならない
- クライアントが納得する結果を出さなければならない
- ITの知識を持ち、メンバーを支えなければならない
- たくさんの関係者とのコミュニケーションを怠ってはならない
PMOのメリット
- エンジニアと比較して単価が高い
- プロジェクト全体の指示役でいられる
- 大きなプロジェクトに携わることで経験を積める
- 様々な業界の人達と関わることができる
- 自分でタスクの終わりを決められる
- ライフワークバランスを考えやすい
- エンジニアの経験を活かせる
- 成果主義のためフルリモートでも可能
- コンサルタントのプロフェッショナルとして需要が高い
- 年齢を重ねても長く働くことができる
- 人をまとめる力を発揮することができる
まとめ
- PMOってどんな職業なのか知りたい
- 私もPMOになれるの?
- エンジニアからPMOに転職したい
- PMOはPMの補佐
- PMのことを知ろう
- PMOにむいている人
- ライフワークバランスも自分で考えられる
- コンサルタントは芸人であれ
- エンジニアの経験がPMOにも活かされる
- 成果主義だからフルリモートのPMOもいる
- エンジニアには限界がある
- マネジメントスキルを手にいれてPMOになろう
- 将来を考えるならばPMOになることは超おすすめ!
ということで今回は
「PMOとは」ということを
太田フランクリンさんにご紹介いただきました。
自分のキャリアの中でモヤモヤしているものを解決できたらなと思います。
皆さんまたお会いしましょう!good-by!
↓記事の参考動画です、よろしければどうぞ!↓
【現役ITコンサルタント】コンサルタント業であるPMOとは?ITエンジニア&SE必見!
↓コチラの記事もおすすめ↓
コメント