複数のプロジェクトを束ね、強靭な組織を支える「部門PMO」


はじめに

本連載では、企業における4種類のPMO(プロジェクトマネジメントオフィス)について解説しています。これまでPMOの全体像、そしてベンダー会社、事業会社それぞれのプロジェクト内PMOについて深掘りしてきました。

今回取り上げるのは「部門PMO(下図における②)」です。特定の事業部門に配置され、部門の管理業務、部門内の各プロジェクトの横断的な支援、他部門との連携などを通して、成長戦略を支えるポジションです。

本記事では、部門PMOが組織に生まれる背景、役割、目指すべき姿まで解説していきたいと思います。

【出典】甲州潤　著『DX時代の最強PMOになる方法』

「部門PMO」誕生の背景とは？

企業の事業部内では、日々さまざまなプロジェクトが走っています。例えば、ベンダー会社であればクライアントによって「A社のアプリ開発」「B社のアプリ開発」などがあるでしょう。

そうした状況下で起こりうるのが、「A社プロジェクトでも、B社プロジェクトでも同じような不具合やミスが発生している」という事態です。そもそもその事態に誰も気づいていないケースもありますし、都度各々のプロジェクト内で対処すれば問題は解決することができます。

しかし、こうした事態は「プロジェクト同士の連携が取れていればもっとスムーズに解決できた」あるいは、「問題自体発生しなかった」かもしれないのです。

例えば、「A社プロジェクトでは、こういう原因で不具合が生じてこのように対処した」という情報が事前に部門内で共有されていた場合、B社プロジェクトは不具合を未然に防いだり、すぐ対処できたりしたはずですよね。

その連携が取れていないばかりに、各プロジェクトでは何か起こるたびに、誰かの経験則や適当な見積もりなどで解決しようと余計な手間と時間を使ってしまい、プロジェクト遅延を招いたり、事業部に求められる売上や品質といった成果を出せなかったりする可能性もあるわけです。

こうした課題に組織として気づき、改善に乗り出す際に設立されるのが、各プロジェクトを横断的に管理する「部門PMO」部隊なのです。プロジェクト経験の豊富なPMやチームリーダーを配置するケースが多く見られます。

“御用聞き”で終わらず、
2段階で進化してこそ本物の「部門PMO」に！

しかし、いざ「部門PMOとして、部門全体を管理するぞ！」と思っても、多くの場合、最初に待ち構えているのは「各プロジェクトからの個々の相談解決」です。

「部門長への提出が必要な事務処理が複雑なんです。簡略化できないですかね？」 「この時期、人が足りなくて……他プロジェクトから誰か借りることはできませんか？」

このような相談に対し、部門PMOは「ではいったん作業を預かり、仕組み化を検討します」「他プロジェクトから一時的に派遣できるメンバーがいないか調査します」と、依頼されたことを淡々とこなす、いわゆる“御用聞き”になってしまいがちなのです。

ただ、それが悪いわけではありません。私も、部門PMO始動時にはこうした「プロジェクトお悩み相談窓口」的役割でいいと思っています。なぜなら、部門全体を管理するためには、まず部門内に顕在する問題を把握することが不可欠だからです。

しかし、投げられたボールをただ打ち返し続けているわけにもいきません。部門PMOの本来の役割は、「個々の作業の巻き取り」ではないのです。そのため、ある程度の相談解決実績が積み上がったタイミングで、この状態から抜け出すことが重要です。

では、どうすればいいのか。

蓄積された相談から、「この内容は、毎回同じタイミングで上がってくるな」「これは、多くのプロジェクトで共通する困りごとだ」ということを抜き出し、部門内全体を視野に入れた解決策を検討してみるのです。

例えば、報告書の記載内容や提出方法に関する問い合わせが多ければ、部内一律のフォーマットやコミュニケーションツール、使用マニュアルを用意し、さらにFAQを作れば、「あなたがこちらへ投げようとしているボールの解決策はこれです」と提示できるため、そもそも部門PMOへの相談自体もなくなっていくでしょう。

人員配置に関しても、プロジェクトごとに調整するのではなく、例えば年度始めに全てのPMやプロジェクト内PMOと部門PMOが連携し、各プロジェクトのスケジュールやメンバーのタスク割合、繁忙期などの共有を行います。

その上で、もしどこかのプロジェクトで人員が必要になったとき、全体を把握する部門PMOが「今、この方なら一時的に手が空いています」と派遣可能なメンバーを配置できれば、どのプロジェクトも柔軟でスムーズな進行ができるでしょう。

こうした部門PMOによる複数プロジェクトを横断した「標準化」によって、プロジェクトメンバーやPMはもちろん、人員配置の最終的な意思決定をする部門長も本来業務に集中できるようになるわけです。

「お問い合わせ窓口」状態といういわゆる“火消し”の段階を経て、問い合わせが減り、各プロジェクトの連携も円滑になってきた。

そうなれば部門PMOは、「他の起こりうる問題の事前対策をしておこう」という“防災”や「部門のKPIを達成するには、さらにどんな標準化や仕組みが必要だろうか？」といった、「次段階」の思考を持てるようになります。

また、基本的な問題はすべて解決可能な環境が整備されているため、各プロジェクトから寄せられる相談の“質”も上がります。

具体的には、「この業務はどう進めればいいのでしょうか？」といった相談から、「もっと自社の利益増大につなげるには、何から着手すべきでしょうか？」といった戦略的な相談へと変化していきます。

そのフェーズに入れば、部門PMO部隊も「では、過去プロジェクトのデータを分析してみようか」「これから新たにPMに着任する人が迷わないよう、実績のあるPMの行動パターンをもとに当部門のスターターキットを制作しよう」など、より視座の高い行動ができるようになるのです。

私はこうした部門全体、ときに全社的な成果まで目を向けた動きができるPMOこそ、真の「部門PMO」だと考えています。そのためには、お伝えしてきたように「御用聞き」からいわば「部門全体の管制塔」へと、「2段階の進化」が必要だと感じています。

【事例】プロジェクトの定量化により、
問題の早期発見・解決が可能に

「部門PMO」の具体的な業務を理解いただくために、実際に私がある企業の開発部において部門PMOを担った事例をご紹介します。

開発部の主な業務は、各業務部門からの要望を受け、システム要件定義を作成してベンダーに開発依頼をする、あるいは自社内でシステムを開発するといったことでした。

その中で、品質向上と現場運営の効率化を目指すべく、私にPMOの依頼がきたのです。参画後、現場のヒアリングなどを通して発生している問題を洗い出すと、以下のようなことが見えてきました。

• 開発と保守が同一のチームに属しており、チーム内部でタスク配分を行っている。
• 不具合は発生箇所のみ修正し原因の深掘りがされず、類似の不具合を繰り返してしまう。
• プロジェクト運営は、現場リーダーの肌感覚による報告を重視する文化が根付いている。

複数のプロジェクトが走っているにもかかわらず、横断的な基準が統一されていないために、さまざまな問題が起きていたのです。

これらに対し、私は主に「開発プロセスの体系化」「プロジェクトの定量化」「リソース管理」の3本柱で解決に臨みました。具体的には、以下の通りです。

• プロジェクトの管理手法やフォーマットを統一
• システム障害の原因を深掘り、分析する手法を構築し、不具合対策を立案するなど、再発防止対策サイクルを確立

• 計画立案、定量情報をもとにした実績値の測定、プロジェクト完了後の評価、定量情報の指標値の見直しを行うサイクルを確立
• プロジェクトにおける開発規模、開発期間、開発工数などの定量基準を作成し、社内の過去案件などと比較したベンチマークデータを構築
• テスト方法の確立と定着化に向けた指導を実施

• 工数が影響する案件を一元管理し、稼働メンバーの工数を把握
• 各プロジェクトの現状の稼働情報の収集し、メンバー別の生産性を算出し評価

約1年の任期の中でこれらを実行し、不具合の再発リスクは大幅に低減したほか、現場のPM が統一基準に沿って効率的にプロジェクトを進められるようになりました。

また、経験に頼った計画や「肌感」のような定性的な判断ではなく、数値という定量的な情報をもとにした綿密な計画により、確かな意思決定ができるようになったのです。

おわりに

今回は、部門PMOに焦点を当てて解説しました。

プロジェクト内PMOと比べると、部門PMOは非常に守備範囲の広いPMOです。段階を経て最終的なフェーズまで到達すれば、全社的なコーポレートPMOの領域にかかってくる場合もあります。

「責任が重そう」「大変そう」と思うかもしれませんが、お伝えしてきたように段階を経ていくごとに視野や思考力が広がり、自身も成長していけるのが「部門PMO」の大きなやりがいだと感じています。

また、部内のさまざまなプロジェクトを束ね、各々の進行を円滑にし、組織全体の力を強固にするという、企業成長を左右するキーパーソンと言っても過言ではないと思います。ぜひ今回の記事で、部門PMOの重要性もご理解いただけたらうれしいです。

次回は、経営層直下に配属される「コーポレートPMO」にクローズアップしたいと思います。どうぞ、お楽しみに！