はじめましての方もそうでない方も本記事をチェックいただきありがとうございます
意外と早くも2回目の投稿ですが、1人でも多くの人に読んでもらえたら幸いです
今回のテーマは、元開発エンジニアが解くPMOの武器のそろえ方です
前回の記事で自己紹介しましたが、
私自身がPMO目指してキャリア積んだわけでなく、
7.8年前くらい前に組織内の部署異動をきっかけにPMO職を知りました。
当時はPMOという言葉が飛び交っていない時代（個人の感触）で、ここ数年でPMOが流行った気がします。（あくまでも個人の感触です）
3年半開発部署のニンゲンが準備なく2週間後に社内異動でプロジェクト管理（以下、プロ管）へ配属されたのですが、実は特に大きな困りゴトなくのらりくらりと今日まで生き抜いたなーと、ふと思いました。（PMBOKすら読んでなかったですし、恥ずかしながら、ここ2・3年前に常駐先にあった書籍をチラ見したくらいです。....今は手元にあります、、、笑）
そんなズボラ人間（？）でも生き抜けた経験値を元に、コレやっといてよかったんだーをまとめてみようかなー？と思います
contents
1.元開発エンジニアが解くPMOの武器のそろえ方
2.“結果論“、PMOを努める前に◯◯をやっておいてよかったこと〜BEST3
3.最後に
1.元開発エンジニアが解くPMOの武器のそろえ方
前回の記事で、ＰＭＯは社内外調整作業がメインで、自分に非がなくとも（関係者の）代わりに謝ることができる人なんてお伝えした背景なのですが、
PMO業務するようになってから.....
- 現場が変わるたびに"（これから戦う武器をそろえることになるので）「あー情報収集（キャッチアップ）しないと戦えない！」
- （情報ないから）調整もうまくいかんし、代わりに謝ることもできない！
ということに気づきました。
PMOは情報こそが武器ですが、現場の方も他のチームメンバーやベンダーさんなどと会話をする機会は多いと思いますので、新しい現場（社内異動含む）になった初日以降に必ず以下の３つを意識してます。
ドキュメントサーフィン🏄♀️
-
前回お伝えしたように、プロジェクトには多くの人がかかわります。なので、みんなで認識を合わせたり、調整をするために資料を作ることが多くあります。
- 例えば、、、、、以下の３点はどのPJ、現場で必ず見かける資料かと思います。
プロジェクト計画書
"このプロジェクトのゴールはどこなのか。","誰がやっているのか。","いつまでにやるのか。"をまとめた資料。
開発プロセスのドキュメント
どういう方法で進めようとしているのかを記載した資料
会議のアジェンダ、議事録
”プロジェクトの経緯”がわかる資料
これらの情報はプロジェクトで判断を迫られた際、判断を行う基本的な情報になります。
なので、こういった情報をよく知っているプロジェクトに長くかかわっている人や情報の集まる高いポジションにいる人は戦闘力が自然と高くなります。
ただし、そういった条件がそろっていない状態でも優秀な人は上手く質問をすることで結論までたどりつけたりします。- また、現在のチームがどのように動いているかを把握するために、チャットツール（例えば、現場がteamsを使っていれば）このteams運用ルールだったり、何のチャネルがあったり、このチャネルでは何のドキュメントが格納されていたり、主に誰メインで使われているのか？などの情報をあるだけ、斜め読みをしたりします。
- 例えば、、、、、以下の３点はどのPJ、現場で必ず見かける資料かと思います。
↑サーフィン🏄♀️のときに、用語集のようなドキュメントがあるかどうか
- 同じ業界、業種でも企業理念や文化が違えば、たとえ広辞苑に載っている単語だとしても、意味がまったく異なることがよくあります。
（同じ会社内の異動だとしても少しばかり違ったりするので、
例えるなら東京駅の丸の内南口側の景色と八重洲北口側の景色くらい違うと思いますー）
↑サーフィン🏄♀️のときに、直近の組織図（体制図）を眺める
- 主に確認しておきたポイントは以下の通りです。
- 今の直近のメンバー
- お隣のチームメンバー
- 同じ部内のメンバー
- 今後関わるであろう部外のメンバー（ユーザ部門）
- その他（直感で）キーマンとなるメンバー
全員は覚えるのは無理なのでローカルに持っておきながら、業務のガス抜きしたい時間に眺めたり、関係者の確認時に眺めたりしてます。
なので、自力で過去の背景などをキャッチアップしないと戦えないため、
どの異動先の初日って大変なんですよねー
2.“結果論“、PMOを努める前に◯◯をやっておいてよかったこと〜BEST3
🥇第1位…なんらかのシステム開発の"開発"を携わっていたこと
🥈第2位…なんらかのシステム開発の"窓口"を携わっていたこと
🥉第3位…なんらかのシステム開発の"雑用"を携わっていたこと
ベスト3にする意味、、、wwかもですが、
PMOとして武器を揃える気づきのインプットが開発経験でした。
これがあったからこそ、この界隈で生き延びれましたと思ってます！
🥇第1位…なんらかのシステム開発の"開発"を携わっていたこと
どんな小さい開発案件、大規模案件関わらず１周（要件定義～リリース→保守/運用まで）しないと、
各工程のプロセスや大変さがわからないから。に尽きます。
できたら、要件定義前のPJ立ち上げから経験があるほうがよいですが、
なかなか初期メンバーとしてアサインされる機会に恵まれないと・・・の前提があるので、要件定義工程から経験があるといいかと思います。
各工程で出てくる登場人物、キーマンもそれぞれ変わってくるので、自然と視野を広げることができます
🥈第2位…なんらかのシステム開発の"窓口"を携わっていたこと
ここでの”窓口”は開発案件の事務局、保守チームのPMOや共通管理といった、
開発チームにいながら、開発メインで行わないポジションのことをさします。
🥇第1位の開発経験をもとに窓口業務を行うと、別視点の視野が得られる気がします。
開発チーム以外からの作業依頼などのフィルター役をすることで、
その人にあわせた会話ができるようになったな。と思いました。
ホント人によって、その人基準の単語で会話されるので、それに気づかないとなかなか認識齟齬に気づけないです。。。。
🥉第3位…なんらかのシステム開発の"雑用"を携わっていたこと
”雑用”のニュアンスは失礼な表現になりますが、いわゆる会議体の議事メモです。
（私が新人のときは「議事録は雑用がするもんだ」と教えられたから、になりますが。。。今思えばとんでもない上司ですね。。。。(笑)）
議事メモはその場で聞いた単語だけ並べて書けばいいというわけでもなく、
結局ストーリーがわからないとまとめることができないので、
プロジェクト（現場）参画直後はどんな年次になってもホント苦労します。
議事メモをとれるようになると当時の背景やナレッジ（文章、ドキュメントスキルなど）もたまるので、
実は議事メモまとめられる人こそ有識者だと思ってます。
だって当時の話がわかる訳ですから。
BEST3をまとめてみましたが、どんなに有識者から学びがあったとしても、
結局は自分で経験を積んじゃったほうが近道なんですよね。うん。って痛感しました。
3.最後に
今回も癖のある長文を最後まで、お付き合いいただきありがとうございましたm(__)m
前回も今回も私独自の目線での解釈をしておりますので、
本記事でも１つでも何かの参考にしていただけることがありましたら、幸いです。
色々書いてますが、PMOって難しそう・・・という方の偏見が取っ払えてたらうれしい限りです。
何かリクエスト・アドバイスなどありましたら、コメントいただけると励みになります🙇🏻♀️