現在ご覧のページは当社の旧webサイトになります。トップページはこちら

PMOの体制を5つの視点から考える

マネージャー 和泉 靖史
『情報未来』No.35より

はじめに

多くのシステムを同時に構築・改修するような大規模プロジェクト(特にマルチベンダー体制の場合)では、プロジェクトリーダーの補佐としてプロジェクトマネジメントオフィス(以下、PMO)を設置することが一般的になっている。一方で、PMOはその必要性は認識されているものの、アウトプットが明確に定められるものではないため、何をやればいいのか、どこまでやればいいのか、どういう体制を敷けばいいのかといったことで頭を悩まされる方も多いのではないか。本稿では、PMOの体制の考え方について焦点を当て、5つの視点にもとづいて提案してみたい。

1.プロジェクト管理のさまざまな側面をどこまでカバーするか

プロジェクトの目的は、一言で言ってしまえばQCD(=Q:Quality(品質)、C:Cost(価格)、D:Delivery(納期))を満たすことであるが、PMBOK(=Project Management Body of Knowledge)の9つの知識エリアに代表されるように、プロジェクト管理にはさまざまな側面がある。これらを総花的に行うと、PMO・開発側双方において必要以上の負荷がかかることも想定されるため、プロジェクトの進行に則して、力を入れるべきところをフォーカスし、メリハリをつけて取り組んでいくのがいいだろう。例えば、テストフェーズでは「予定通り進捗している」と言っても「だから何?」ということになり、どれだけ品質基準を満たしているかが重要となる。また、プロジェクト後半の最終局面においては、いつまでも品質を作りこむ猶予は無いため、リスク管理(顧客影響等が発生するリスクを想定した対策の検討)が重要となる。

図表1:PMOの体制イメージ
(プロジェクト開始当初)
出所:NTT データ経営研究所にて作成

なお、その妥当性を測定するのは容易ではないが、プロジェクト管理の側面としては、ユーザー企業および協力会社双方における体制(スキル・要員数)が十分に敷かれているかを確認することはとても重要なことである。これが本質的な原因となり、恒常的にプロジェクトの進捗・品質に支障をきたすことが多々見受けられるため、体制面に関しては全フェーズを通して検証し続けることが必要であろう(図表1)。

2.個々のシステムをどのようにカバーしていくか

PMOといえども、管理下のシステムについて何も分かっていなければ、表面的な管理に留まってしまう。このため、PMO内に個々のシステムの窓口となる担当者を配置し、同担当者が継続的に管理・モニタリングしていくことで、システムの特性や脆弱性等を次第に理解していくことや、システム側の担当者との関係を構築していくことが期待できる。管理対象となるシステムが多岐にわたる場合には、重点管理するシステムとそうでないシステムに分けて、リソースを配分してもいいだろう。また、システム開発では、得てしてプロジェクトの進行により明暗が分かれていく(順調に進行するシステムとそうでないシステム)ものであるため、状況に応じて手厚さを変えていく等の柔軟性も必要であろう。

3.プロジェクトの推進にどこまで入り込んでいくか


図表2:PMOの体制イメージ
(プロジェクト中盤)
出所:NTT データ経営研究所にて作成

PMOを設置するような大規模プロジェクトでは、複数システムに跨る計画策定や課題解決が幾度となく必要となる。PMOとしてどこまで入り込んでいくか、その立ち位置を決める必要があるが、

(1)システム間での調整に委ね、あくまでも状況の管理に徹する、

(2)主要システムに検討を促しながら全体をファシリテートする、

(3)自らがアイデア(たたき台)等を出しながら全体を推進する

等、いろんな選択肢が考えられるため、必要性はもとより、PMOのリソース(能力を含む)を考慮しながら、予め、PMOと各システムの間で考え方を共有しておくことが必要であろう(図表2)。

4.フェーズに応じてどのように体制を組み換えていくか


図表3:PMOの体制イメージ
(プロジェクト最終局面)
出所:NTT データ経営研究所にて作成

個々のシステムの中でも、プロジェクトの進行に則して体制を変えていくことが一般的であるが、PMOも同様に、プロジェクトの進行に則して体制を変えていくことが必要であろう。例えば、

(1)プロジェクト開始当初は、個々のシステムに担当者をはりつけ、状況をモニタリングし、その状況をプロジェクト全体として管理することから始め、

(2)開発フェーズに入ったあたりから、その先に控えているプロジェクト全体でのテストや移行(データ移行、システム切り替え等)に備え、システム横断的な検討体制を立ち上げて計画を立案し、その運営を行う、

(3)プロジェクトの最終局面に入ると、本番稼働後を念頭に置いたプロジェクト全体でのリリース体制(本番検証、障害対応等)が必要となる。

これらに共通して言えることは、プロジェクトの進行に則して、タイムリーかつダイナミックに体制を組み換えることである。開発現場はとっくに体制が入れ替わっているのに、PMO側がこれまでの体制をひきずっていたり、体制の立ち上げにもたついていると、PMOがボトルネックになりかねない。その場合、各システムはそれぞれで勝手に検討を始め、個別最適な考え方に走ってしまう恐れがある(図表3)。

5.社員と協力会社でどのように役割分担するか

これまで、PMOの体制を検討する上でいくつかの視点にもとづいて述べてきたが、ここでは、PMOを社員と協力会社でどのように役割分担するかということに触れてみたい。PMOを設置するような大規模プロジェクト(システム統合プロジェクト、次期システム構築プロジェクト、大幅な法改正対応プロジェクト等)は、それほど頻繁に行われるものではないため、社員側にそのスキルが十分に備わっていない場合には、外部の協力会社を活用することもあろう。また、単に社員のリソースが不足しているということもあるかもしれない。このような時に、協力会社を活用するのはいいが、社員と協力会社の間でどのように役割分担するのがよいか考えどころである。これに関しては、なかなか明確な答えは出しづらいと思われるが、一つ言えるとすれば、PMOはプロジェクトリーダー直轄の重要な組織であり、あくまでも社員がプロジェクト運営の前面に立ってさまざまな意思決定を行うものであるため、そのための当事者意識を社員はきちんと持つ一方で、協力会社は各種意思決定ができるようお膳立てし、必要に応じて示唆を与えることが求められるのではないかと思う。

おわりに

少し精神論になるかもしれないが、私がこれまでPMOに携わってきた中で、周囲の人間から受けた印象的なアドバイスについて共有させていただきたい。「PMOとはブレーキではなく(システム開発の現場を阻害するものではなく)、アクセルでなければならない」、「PMOとはプロジェクトリーダーに成り代わって、手足となり(実態を的確に把握し)、頭となり(プロジェクトリーダーの視点で物事を考え)、ハートを共有する(必ず成功させるという志をもつ)ものだ」

Page Top