ごきげんよう、二深すうちです。
私はIT開発現場でPMO（※一部PM）をしています。
PMO歴は約1年。
そろそろ「PMOって結局何してるの？」という問いに、感覚ではなく構造で答えられるように整理しました。
PMOという職種、だいたいどこの説明でもふわっとしています。
私もあまり良く理解しないまま参画しました。
（参画当時、知人に「なんの仕事しているの？」と聞かれても、守秘義務の都合で具体的な社名や案件内容はもちろん伏せますが、それ以前に自分の業務をうまく言語化できていませんでした。
「会議の議事録を取ったり」「問題を一元管理したり」と、結局、自分自身もふわっとした説明をしていた記憶があります。）
本記事では、PMOの仕事・本質・PMとの違いを体系的にまとめています。
特に「在り方」と「メンタル設計」は、現場でハラハラしながら学んだ実践論です。
教科書的なきれいごとではなく、“壊れずにやるための話”も含めています。
そもそも、プロジェクトマネジメントとは？
大前提として、PMOはプロジェクトがなければ始まりません。
その名の通り、プロジェクトをマネジメントする“オフィス”です。
（個人的には“裏方組織”だと思っています。）
ということで、簡単に、でも本質的にプロジェクトマネジメントを整理してみます。
今回のプロジェクトは、スパイスカレー作りです。
（なお、炎上案件ではありません。）
定義
- 一時的
- 目的達成
- 制約あり（QCD）
※QCD（品質：Quality／コスト：Cost／納期：Delivery）
例：カレーをスパイスから作ろう
期間限定で、材料費というコストがあり、完成時間という納期があり、そして味という品質がある。
プロジェクトとは、期間限定で、制約の中で目的を達成する取り組みのこと。
それを管理するのがプロジェクトマネジメント。
QCD（品質・コスト・納期）はすべてを100点にはできない。
だからこそ、何を優先し、何を諦めるかを決めるのがマネジメントである。
マネジメントはなぜ必要？
- 自然にやると崩壊
- 不確実性
- 人・時間・お金の制約
例：カレーをスパイスから作ろう
スパイスからカレーを作ろうと、思いつきで始めるとどうなるか。
スパイスの調達が間に合わない。
配合が決まらない。
気づいたら「なんか違うカレー」が完成する。
日常でも私たちは何かしらを管理している（料理、年末の大掃除、旅行の計画など）
規模が小さいうちは“なんとなく”で回る。
しかし規模が大きくなると、“なんとなく”は事故の原因となる。
マネジメントは、気合いや善意の代わりではなく、仕組みで前に進めるための技術である。
やってること
- 計画
- 実行
- 監視・コントロール
- 終結
例：カレーをスパイスから作ろう
カレーをいつまでに完成させるか、いつまでに何のスパイスを調達するのかなどを決める
実際にカレー作りを実行していく
カレー作りが計画通りに進んでいるかを確認し、ズレがあれば放置せずに手を打つ
いただきます。
ただし、食べて終わりではない。
成果を確認し、振り返り、次に活かせる形にして初めて“完了”となる。
管理対象
- ステークホルダー（利害関係者）
- スコープ
- スケジュール
- コスト
- 品質
- リスク
例：カレーをスパイスから作ろう
誰が食べるのか決めること
- 誰が影響を受ける？
- 誰が決める？
- 誰が反対する可能性がある？
- 誰に説明が必要？
子ども？辛いの好きな友達？ここを間違えると、品質以前に炎上する。
プロジェクトは作ることだけでなく、合意をつくることでもある。
どんなカレーを作るのか決めること
- チキン？キーマ？野菜？
- 甘口？スパイス強め？
- 付け合わせはある？
途中で
「やっぱりナンも焼こう」「デザートも作ろう」と増えると大変。
どこまでやるかを決める
いつ完成させるかを決めること
- スパイスの買い出しは今日？
- 仕込みは何時から？
- 煮込みはどれくらい？
間に合わないと困ってしまう。
いつまでに何をやるかを決める
材料や道具にどれくらいお金をかけるか
- 高級スパイスを使う？
- 近所のスーパーで済ませる？
- 人を呼ぶなら量も増える？
予算オーバーすると困る。
使えるお金の中で考える
出来上がったカレーが期待通りか
- 味は大丈夫？
- 火は通ってる？
- 思ってたカレーになってる？
間に合ってもおいしくなかったら意味がない。
期待どおりにできているかを見る
起きるかもしれないトラブルを考えておく
- スパイス売り切れ
- 肉が傷んでた
- 煮込みすぎて焦げる
- 体調不良
事前に考えておくと焦らなくて済む。
困りそうなことを先に想像しておく
どれか一つでも崩れれば、プロジェクトは歪む。
全体を見続けること。それがマネジメント。
本質
成功確率を上げる技術（うまく進めるための工夫）
世間一般のPMOの説明への再定義
一般的にPMOは、下記のような説明をされることが多い。
・PMの補佐
・プロセス標準化
・進捗／課題管理
・組織横断の調整
どれも確かにその通りだが、ふわっとした説明でしかない。
PMOの本質は“やる人”ではなく、“整える人”
- 判断材料を作る（「気づいたら遅い」を防ぐ）
- 事故を防ぐ（安心して進められるようにする）
プロジェクトが「なんとなく」ではなく「意図して」進むようにする役割である。
PMとPMO
PMOを語るには、PMとの違いをはっきりさせておく必要がある。
役割
- 意思決定（まとめ役）
- 最終責任（決める人）
- 運転する人
- 意思決定できる状態を作る人
- 可視化（見えるようにする人）
- 仕組み化（整える人）
- 統制（バラバラにしない人）
- ナビ・メーター
やること
- 方向を決める
- 優先順位をつける
- トレードオフ判断（困ったときに判断）
- 進捗（今どうなっているか）見える化
- 数値化（感覚ではなく根拠で見える化）
- リスク整理（問題に気付けるようにする）
- ルール作る（進め方を整える）
PMOの仕事
情報をそろえる仕事
- 議事録作成・共有
- 進捗の取りまとめ
- ステータスレポート作成
- 会議体の設計
みんなが同じ状況を見られるようにする
進み具合を見える化する仕事
- WBS作成・更新
- 進捗率の集計
- 工数管理
- 予実管理
「なんとなく順調」をなくす
問題を早く見つける仕事
- 課題管理表の運用
- リスク一覧の整理
- 変更管理
「気づいたら遅い」を防ぐ
進め方を整える仕事
- テンプレート整備
- ルール設計
- KPI設計
- 報告フォーマット統一
「人によってバラバラ」をなくす
PMOの仕事の本質
- 情報を集める
- 整える
- 数値にする
- 共有する
- 気づかせる
意思決定を支援する
PMOとしての在り方（Position）
- 決める人ではない（決めるのはPM。しかし、決められる状態をつくるのがPMO）
- 成功の主役ではない（プロジェクトの中心に立つのはPMや現場）
- でも失敗を減らす人（失敗していないことがPMOとして最大の成功）
- 全責任を背負う人ではない（全体が見えることと、全責任を負うことは違う）
- でも見て見ぬふりはしない人（「このままだと危ない」を言語化するのがPMO）
PMOのメンタル設計（Survival）
- 温度差に飲まれない/ハラハラを抱えすぎない線引き
PMOは全体が良く見えるからこそ、心配症になりがち。しかし人はさまざま。
時には楽観的な対応をされることもあるかもしれない。
しかしPMOの仕事は心配を感じることではなく、心配を言語化すること。
“自分自身の心が心配を抱える必要はない”。 - 「言った」を記録に変える技術
情報は伝えたい相手に伝えないと伝えたことにならない。
そして残念なことに、伝えたとしても人は時には悪意なく忘れてしまう生き物。
口頭で伝えたものは念のために記録に残しておくと、相手が忘れてしまった時の相手へのカンペにもできる。
記録は相手を責めるためではなく認識を揃えるためのものとなり、結果的にそれが自分を守ることにもつながる。 - コントロールできることに集中する
他人の温度や意思決定のスピードもコントロールできない。
しかし情報整理、数値化、期限提示はできる。
PMOは“感情”ではなく“構造”で戦う。
PMOに必要な力（Skill）
技術スキル
- WBS設計力
- 数値化能力
- 予実管理
- 会議設計
- ロジカル整理力
- ドキュメント設計力
- 仕組み化力（再現性を作る力）
内面スキル
- ファシリテーション
- 伝達力
- 温度差調整力
- 感情に巻き込まれない力
- 俯瞰視点
- 構造化力（抽象化力）
PMOは一枚岩ではない
ぶっちゃけ、組織によってPMOの役割は大きく異なり、
教科書的には、PMOは大きく3種類に分類される。
- 支援型PMO
- 管理型PMO
- 指揮型PMO
権限や責任の度合いもそれぞれ違い、場合によってはPM並みの責任を担うこともある。
つまり「PMOとはこういう仕事です」と一言で言い切れるものではない。
だからこそ重要なのは、
与えられた立場の中で“何を自分が担うのか”を自覚すること。
私は、最終的には自責思考が大事だと感じています。
PMOを雑用とみるか参謀とみるか
今回PMOをすごく簡単にまとめてみましたが、人によっては「それって雑用では？」と思われるかもしれません。
しかし、PMOは全体を見まわたせるからこそ、その質がプロジェクトの成功と失敗を左右します。
確かにPMOはコードを書くわけでも、インフラを構築するわけでもありません。
ですが、だからといって技術を理解しなくていい理由にはなりません。
理解しようとすることはできるし、それはPMOの価値を確実に底上げします。
PMOは職種というより、プロジェクト全体を見渡せるポジションだと思っています。
マネジメントは、プロジェクトがある限り必ず必要なものです。
だからこそPMOは、業界や技術に縛られず、自分の努力次第でフィールドを広げていけます。
今は想像もしていない業界、例えばロケット開発のような分野に関わる可能性もあるかもしれません。
立っている場所が“全体”だからこそ、どこへでも伸ばしていける。
そこまでできるPMOは、雑用ではなく参謀だと思っています。
雑用は、言われたことをこなす仕事。
参謀は、うまく進めるための構造をつくる仕事。
私は参謀になりたい。
私は参謀になるべくはじめの一歩として、数字で根拠を出せるよう統計学・データ分析の勉強をしています。
それは自分自身のスキルになるだけでなく、プロジェクトを成功に近づける武器になると信じています。
コメント