PMOは「議事録を書く人」じゃない
「PMOって何をする人ですか?」と聞かれて、多くの人が思い浮かべるのは「会議の議事録を書く人」「進捗表を作る人」「Excelで資料を作る人」といったイメージではないでしょうか。私も30年前にIT業界に入った頃は、そう思っていました。
しかし、プログラマーからSE、そしてPMを経験し、最後の10年以上をPMOとして過ごしてきた今、はっきり言えることがあります。PMOの本当の役割は、そういった事務作業ではないのです。
PMOとは「Project Management Office」の略で、直訳すれば「プロジェクト管理事務局」となります。この日本語訳が、実は大きな誤解を生んでいると私は考えています。「事務局」という言葉が、どうしても「裏方」「サポート役」「資料作成係」というイメージを作ってしまうんですよね。
私が30年のキャリアの中で到達した結論は、こうです。PMOの本当の役割は「プロジェクトを止まらせない人」である、と。
ある日突然、プロジェクトが止まった
私は30年のIT業界キャリアの中で、PMOとして10年以上の経験を積んできました。最初にPMOの役割を任されたとき、私自身も『PMOって何をする人?』と戸惑った記憶があります。先輩から教えられたのは『PMの右腕』『プロジェクトの参謀』という抽象的な言葉でした。実際に複数案件を経験する中で見えてきたPMOの本当の役割は、『プロジェクトを止まらせない人』です。ある200名規模の保険登録システムプロジェクトでは、毎週発生する課題、ベンダー間の認識ズレ、要件変更要求などを即座に整理し、PMが判断できる状態にお膳立てするのが私の仕事でした。資料作成は手段であって目的ではない。PMOの本質は『プロジェクトの推進力を保つこと』だと、現場で身を持って学びました。
この経験から私が学んだのは、プロジェクトが止まる原因の多くは「技術的な問題」ではないということです。むしろ「誰が何を決めるのか分からない」「関係者の認識がバラバラ」「課題が放置されている」といった、人と組織の問題なんですよね。
中小企業でよく見る「PMO不在」の現実
中小企業のIT担当者の方とお話しすると、よくこんな状況を耳にします。
- プロジェクトマネージャー(PM)が技術的な作業と管理業務を兼任している
- 会議で決まったことが実行されないまま次の会議を迎える
- 課題リストは作るが、誰も追いかけていない
- ベンダーとの認識違いが後から発覚して炎上する
- 経営層への報告が遅れ、判断が後手に回る
これらは全て「PMOがいれば防げた」問題です。しかし多くの企業では、PMOという役割そのものが存在しないか、存在していても「議事録係」として認識されているため、本来の機能を果たせていません。
私自身、大手企業のプロジェクトでPMOとして入った際、最初の1週間は「なぜこんなに課題が放置されているのか」と驚きました。課題管理表は存在する。しかし誰も追いかけていない。PMは技術検証や設計レビューで手一杯。結果、小さな課題が積み重なって、後から大きな問題になっていたのです。
なぜPMOが「議事録係」になってしまうのか
30年の経験から見えてきた、PMOが本来の役割を果たせない構造的な原因を整理します。
原因1:PMとPMOの役割分担が曖昧
多くの組織で、PMとPMOの違いが明確に定義されていません。私がこれまで見てきた現場では、こんな曖昧な理解が蔓延していました。
- 「PMが偉くて、PMOはその下で雑用をする人」
- 「PMOは女性が多いから、事務作業担当なんだろう」
- 「PMOは外注先から来てもらう補助要員」
これは完全に間違っています。私の理解では、PMは「何を作るか」を決める人、PMOは「どう進めるか」を回す人です。PMがプロジェクトのゴールと方向性を決め、PMOはそこに到達するための推進力を保つ。両者は上下関係ではなく、役割が違うだけなんですよね。
しかし多くの現場では、この役割分担が曖昧なまま「とりあえず議事録はPMOが書く」「進捗表の更新はPMOがやる」という形で、事務作業がPMOに集中してしまいます。
原因2:「管理」を「監視」だと勘違いしている
PMOの仕事の中心は「プロジェクト管理」です。しかしこの「管理」という言葉が、誤解を生んでいると私は感じています。
多くの人が「管理=監視」だと思っているんですよね。進捗を報告させて、遅れを指摘して、報告書を作る。確かにそれも管理の一部です。しかし本当の管理とは「障害を取り除くこと」だと、私は30年の現場経験から確信しています。
プロジェクトメンバーが作業を進められないとき、そこには必ず理由があります。仕様が決まっていない、承認が下りない、他部署の協力が得られない、ツールの使い方が分からない。こうした「進められない理由」を見つけて、即座に対処する。これがPMOの本当の管理業務です。
私がPMOとして現場に入るとき、まず最初にやるのは「誰が何で困っているか」のヒアリングです。公式な会議では出てこない、現場の本音を聞く。そしてそれを即座に解決する。この積み重ねが、プロジェクトを前に進める推進力になるんですよね。
原因3:成果が見えにくい
PMOの成果は「何かが起きなかったこと」です。炎上しなかった、手戻りが発生しなかった、認識違いが起きなかった。これは非常に見えにくい成果なんですよね。
一方、PMやエンジニアの成果は目に見えます。システムが完成した、機能が動いた、問題が解決した。こうした「見える成果」と比べると、PMOの貢献は評価されにくい。
私が金融系の大規模プロジェクトでPMOを担当していたとき、本番リリースまで重大な障害が一度も発生しませんでした。これは変更管理、課題管理、リスク管理を徹底した結果です。しかしプロジェクト終了後の評価会議では「特に大きな問題もなく順調でしたね」で終わってしまう。「問題が起きなかったのはPMOの功績」とは、なかなか認識されないんですよね。
この「成果の見えにくさ」が、PMOを「いてもいなくても同じ」「コストのかかる事務員」という誤解につながっています。
現代のPMOを支えるツールと使い方
30年前、私がSEとしてプロジェクトに入った頃は、進捗管理も課題管理も全てExcelでした。Excelファイルをメールで送り合い、最新版がどれか分からなくなり、更新漏れが発生する。今思えば、非効率極まりない方法でしたね。
しかし現代は違います。PMOの仕事を劇的に効率化し、本来の役割に集中できるツールが揃っています。私が現場で実際に使い、「これは本当に効く」と感じたツールを紹介します。
Backlog:中小企業に最適な「全部入り」ツール
私が中小企業のPMOにまず勧めるのが、Backlogです。理由は明確で「プロジェクト管理に必要なものが全部入っている」からです。
課題管理、ガントチャート、Wiki、ファイル共有、バージョン管理。これらが一つのツールで完結します。私が30年の経験で学んだのは「ツールが分散すると、情報も分散する」という法則です。課題管理はA、スケジュールはB、ドキュメントはC、では、結局誰も全体を把握できません。
Backlogの良さは、UIが直感的で「ITに詳しくない人でも使える」点です。中小企業では、プロジェクトメンバー全員がIT専門家というわけではありません。経理部門や営業部門も巻き込んでプロジェクトを進める場合、「誰でも使えるツール」が絶対条件なんですよね。
私が実際に使った現場では、課題の起票から完了までの時間が平均30%短縮されました。理由は「誰でも課題を登録できる」「担当者への通知が自動」「進捗状況が一目で分かる」という3点が揃っていたからです。PMOとして、個別に進捗を聞いて回る時間が大幅に減りました。
Microsoft Project:大規模案件の「見える化」に
50人以上が関わるような大規模プロジェクトでは、Microsoft Projectの出番です。私は10年以上このツールを使い続けていますが、やはり「複雑な依存関係の管理」では右に出るものがありません。
Backlogのガントチャートは分かりやすいですが、タスク間の依存関係が複雑になると限界があります。「タスクAが遅れたら、連鎖的にどのタスクが影響を受けるか」を瞬時に把握するには、Microsoft Projectのクリティカルパス分析が必要です。
ただし注意点があります。このツールは「PMOが使いこなすツール」であって、「全員に使わせるツール」ではありません。私の現場では、Microsoft Projectで全体スケジュールを管理し、各チームへの展開はBacklogで行う、という使い分けをしています。適材適所なんですよね。
Slack + 各種Bot:リアルタイムの「止まらせない」仕組み
PMOの本質が「プロジェクトを止まらせないこと」だとすれば、コミュニケーションのスピードは致命的に重要です。課題が発生してから対処するまでの時間を、いかに短くするか。
私が現在担当しているプロジェクトでは、BacklogとSlackを連携させています。課題が登録されたら即座にSlackに通知、重要度が高い課題は特定チャンネルにメンション付きで投稿。これで「課題に気づかなかった」が無くなりました。
メールは見ない人がいても、Slackは見る。この現実を受け入れて、コミュニケーションの主軸をSlackに移行しました。30年前の私なら「チャットツールなんて」と思ったかもしれませんが、今は「リアルタイム性」がプロジェクトの生命線だと実感しています。
ただし、Slack導入時の注意点を一つ。チャンネルを作りすぎないことです。私が失敗した現場では、目的別に20以上のチャンネルを作ってしまい、結局誰もどこを見ればいいか分からなくなりました。最小限のチャンネル構成で、情報を集約する。これがSlackを活かすコツです。
30年現場にいた私が思うこと
PMOとして10年以上、様々なプロジェクトに関わってきました。成功したプロジェクトも、炎上したプロジェクトも、数え切れないほど経験しました。その中で、一つだけ確信していることがあります。
プロジェクトが成功するかどうかは、技術力だけでは決まらない。
優秀なエンジニアが揃っていても、認識がバラバラで、課題が放置され、関係者の調整ができなければ、プロジェクトは失敗します。逆に、技術的には平凡なチームでも、全員が同じ方向を向いて、課題を即座に解決し、推進力を保てれば、プロジェクトは成功するんですよね。
この「プロジェクトを止まらせない力」こそが、PMOの本質です。議事録を書くことでも、進捗表を作ることでも、資料を整えることでもない。プロジェクトが止まりそうになったとき、即座に動いて、障害を取り除く。これがPMOの存在意義だと、私は30年の経験から確信しています。
中小企業こそPMOが必要な理由
「うちは小さな会社だから、PMOなんて必要ない」と思われるかもしれません。しかし私の経験では、むしろ中小企業こそPMOが必要です。
大企業には、プロジェクト管理の仕組みが既に整っています。課題管理のルール、変更管理のプロセス、報告の様式。これらが標準化されているため、PMOがいなくてもある程度は回ります。
一方、中小企業にはそうした仕組みがありません。だからこそ、プロジェクトが属人化し、混乱が起きやすい。PMが技術とマネジメントを兼任し、疲弊する。この状況を打破するには、PMOという「プロジェクトを回す専門家」が不可欠なんですよね。
ただし、最初から完璧なPMOを目指す必要はありません。まずは小さく始めることです。
明日からできる「小さなPMO」の始め方
もしあなたが今、プロジェクトマネジメントに悩んでいるなら、こんな小さな一歩から始めてみてください。
課題が出たら、24時間以内に「誰が」「いつまでに」を決める。
これだけです。課題管理表を作る必要も、複雑なツールを導入する必要もありません。会議で課題が出たら、その場で担当者と期限を決める。そして翌日、進捗を確認する。たったこれだけで、プロジェクトの推進力は劇的に変わります。
私が30年の経験で学んだ最大の教訓は「小さな課題の放置が、大きな炎上を生む」ということです。逆に言えば、小さな課題を確実に潰していけば、大きな問題は起きないんですよね。
PMOとは、特別な資格や肩書きではありません。「プロジェクトを止まらせない」という強い意志を持ち、日々の小さな課題に向き合い続ける。それがPMOの本質だと、私は信じています。
あなたのプロジェクトが、明日も、明後日も、止まらずに前に進むことを願っています。
コメント