・開発能力が人よりちょっと低いな
・自分のタスクより他人のタスクの進捗が気になってしまう
そんなあなたに朗報です！
あなたはPMOに向いている可能性があります。
私自身は自分で開発をしてみたくてプログラミングスクールに通い、システム会社に入社しました。ただ結果だけを見るに私は開発能力は人より低く、入社して1年で見切りを付けられ、PMOとしての道を歩む事になりました。
結果、私の人生は好転しました。
肩身が狭かった会議も切り込めるようになりました。
今日はそんな開発が苦手なあなたに役立つ情報を記載していきます。
この記事を読まなかったがために向いていない開発の仕事を続けて才能を浪費しないようにしましょう！
PMOに向いている人、向いていない人
向いている人
・開発の流れを理解したい人
・せっかちやな人
・複数タスクを一緒に視るのが得意な人
・ゼネラリスト指向
向いていない人
・一つの課題に深く向き合いたい人
・期日ぎりぎりのタイプ
・開発に集中したい人
・スペシャリスト指向
といったところでしょうか。
薄く浅く理解して全体像を置いたい人にPMOは向いています。
自分で言うのもアレですが私は前者でした。
開発をしていても全体としてどのタスクがボトルネックになっているか気になってしまうのです。
今思えば集中力が分散しやすかったのかもしれません。
PMOは未経験でなれる？
②PMOに向いている人、向いていない人
結論、全くの未経験でPMOになるのは困難です。
少なくとも開発経験が1-2年あると良いです。
実務を知らないと、例えば「文言修正にどれだけ時間がかかるのか？」といった感覚がつかめません。
・ホームページの文言を直すにはどのくらい時間かかるのか？
・入力項目を必須にするにはどのくらい時間がかかるのか？
私は開発はできる方ではないですが、上記2個であれば1-2日で何とかなるかな、というのは体感的にわかります。
（開発体制によるが少なくとも重い開発タスクでない事はわかります）
実際にユーザー側のPMO・コンサルに入るとシステムに触った事がない人が多いので上記の知識は非常に重宝されます。
PMOの基本3スキル+大事な1スキル
ここではPMOに求められる3個のスキルについて述べます。
1. タスク依存関係の理解
タスクが他の作業にどのように影響しているかを把握し、ブロッカーを一旦見つけたら早急に対応する能力が重要です。
広く浅く物事を眺める必要があります。
特に最初のスタートダッシュが大事なので、参画当初はシステムの資料を舐め回すように読んで、不明点はバンバン質問するようにしましょう。
最初は質問できるボーナス期間でもあります。
2. 工数・スケジュールの整理
WBSを作成して継続的に更新する、経算定めや契約フローの機素も考慮に入れる、そういった細かな解像度が求められます。
そして日々そのWBSを眺めてタスクが予定より前倒しで進んでいるのか、遅れているのかをチェックする必要があります。
また遅れているよりは前倒しの方が良いのですが、その遅れがプロジェクト全体から見てどの程度致命的なのかを察知できるようにしましょう。
3. 会議で切り込む心臓
会議でバンバン発言するようにしましょう。
最初はわからないことだらけのシステムですが、質問を繰り返す事で理解度がガンガン深まっていきます。
人間の理解力は線路みたいなもんなので、不明点をそのままにすると、知識が途切れ途切れになって全体像を理解することができません。
特にテキストでのコミュニケーションは有効ですが、会話に比べると非常にコミュニケーションコストがかかります。
会議でバンバン質問して存在感を出すとともに、プロジェクトの理解を深めるようにしましょう。
最も大事な能力
そしてかなり大事な能力としては即レス（しなくても良いけど早く反応すること）する能力です。
というのも人間の記憶力には限りがあるので、どんどん忘れていくからです。自分も、プロジェクトのメンバー、外部の会社もです。
即レスすれば相手も記憶が新鮮なので、精度高く、素早く返信してくれてプロジェクトがガンガン進みます。
反対にレスポンスが遅いと相手も記憶が薄くなるので、「そもそも何の問題だっけ？」なんてことになりかねません。場合によっては「思い出すための会議」が設定されることがあります。
物事の重み付けは大事ですが、そもそも何が大事なのかは担当者によっても異なるため、どんな問題も早めに片付けて置くことが大事です。
未経験PMOへの3STEP
Step1: 小規模プロジェクトの開発者に
フロントエンドやバックエンドの基礎的な経験を持つことで、後のPMOの現場理解力が執押的に上がります。
私は正直バックエンドしかわかりませんが、フロントエンドは検索すればかろうじて概要を把握することができます。
また小規模だと全体の動きを把握することができ、関係者も少なくなるので、コミュニケーションコストが非常に小さいです。
そしてプロジェクトによっては顧客と直接コミュニケーションを取る事ができるため、開発～顧客コミュニケーションまで一気通貫で行う事ができます。
感覚値で最低1-2年やっておくと良いでしょう。
1-2年やれば開発に必要な基礎知識の70%くらいはカバーできると思います。
（何を持って基礎知識というかは定義次第ですが顧客対応も含めて70%はカバーできると思います）
開発は底なし沼なので、いつまでやっても極める事はできません。
向き/不向き、会社の都合もありますが、1-2年でPM/PMOに上がれるようにしましょう。
Step2: 開発していたプロジェクトのPM/PMOに
可能であれば、そのままそのプロジェクトのPM/PMOになります。
そもそも開発していたので、プロジェクト特有の単語にも慣れていますし、関係者もすでに把握済です。
そしてPM/PMOも1-2年はやるようにしましょう。
1-2年あれば開発メンバーの入れ替え、使っていたシステムのサポート期間の終了など様々なイベントを経験することができます。
顧客からのクレームにも良くも悪くも慣れます。
Step3: 大規模プロジェクトのPM/PMOに
小規模・大規模プロジェクトで中身がだいぶ異なります。
小規模であれば1人でもシステムのほぼすべてを理解することができますし、不明点も自分自身で調査して解決が可能です。
なので、顧客から調査依頼が来れば、すぐに二つ返事でOKできます。
反対に大規模プロジェクトは大きすぎて、どのシステムが他のシステムのどのように影響しているかわかりませんし、自分自身で調査不可能だったりするケースも多く、中には誰が調査してもらえるのかもわからないことがあります。
そのため、調査依頼が来ても目的や背景などを理解しないと社内調査するのも大きな工数がかかったりします。
大規模プロジェクトも1年くらいやっておくと良いでしょう。
それ以上の年月をやるとあとは社内政治に詳しくなるくらいのメリットしかなくなるので、技術を深化させるという意味だと別のプロジェクトに映るのが良いかもしれません。
まとめ: あなたの苦労した開発経験は生きる
冒頭で述べた通り、私は開発能力が低かったです。
なにせ100人以上いる開発会社でPMOをやっているのは私含めて1,2人しかいませんでした。会社の総合的な判断によるものです。
しかし、プロジェクトはとても大きなもので、様々な役割が求められます。
開発ができるに越した事はありませんが、できなくても他の役割があります。
更にAIによってコーディングが以前より重視されなくなりました。
そういった意味では時代を先取りしていたのかもしれません（そんな想定はしてなかったのですが）
ただ苦労はしましたが、数年システムに触れた事は今後の大きな財産になりました。
私のシステムに関する能力は普通の会社では平均以下でしかありませんが、ユーザー側から見たらオーバースペックになるからです。
そういった意味で1個の能力で人より優秀でなくても落ち込む必要はありません。
軸足を変えれば活躍できる場はいくらでもあるからです。
特にAIがそうでしたが、「優秀さの定義」自体が変わります。
そういった意味では軸足を変えると行った「時代の波に乗る力」が一番大事なのかもしれません。
それでは、また！
皆様のご相談に乗るチケットを出してます。気軽にご相談ください。
満足いただけれなければ返金します！
それではまた！
招待リンクはこちら：
➡ https：//coconala.com/invite/JGB98B
（コピーしてブラウザに貼ってください）
招待コード「JGB98B」で申し込みいただくと1,000円OFFになります
実質1000円未満でご相談が可能です！
※URLを全てコピーしてください。このリンクからでないと1,000円OFFの対象にならない場合があります。
