MSOL社員ブログ

このたび、PMOのリーディングカンパニー、株式会社マネジメントソリューションズのノウハウを結集したPMO方法論の初版をリリースします。
過去にPMO導入・実行支援を行った際の豊富なノウハウを結集しておりますので、実践に即した内容に仕上がっています。

PMO方法論の効果としましては、PMOとしてプロジェクトに参画した際、「プロジェクト計画書の整備」や「変更管理方法の定義」など、プロジェクトマネジメントに必要な手順を分かりやすく表現しているため、経験したことがないエリア・フェーズでも、一定以上のパフォーマンスを発揮することが期待されます。

また、PMBOK（R）の9つの知識エリア（統合・スコープ・タイム・コスト・人的資源・調達・品質・コミュニケーション・リスク）と、要件定義や基本設計（外部設計）などのフェーズの2つの視点で分類しているため、PMOとして「何をやるべきか（what）」と「どうやるべきか（how）」が明確に分かる構成になっています。

今後は、PMO方法論の拡充・改善を継続し、社内への定着を推進することで、マネジメントソリューションズのサービスと製品の品質の底上げに努めてまいります。

PMOのリーディングカンパニー、株式会社マネジメントソリューションズが監修したiPhone用アプリ「PMO用語集/事例集」が2010年8月リリースされました。

PMO（プロジェクトマネジメントオフィス）とは、プロジェクトマネジメントに関連する業務について実行推進・支援を行い、プロジェクト成功へと導くチームです。プロジェクト全体の進捗や課題を可視化し、プロジェクトマネージャーの意思決定支援を行う組織として、PMOはプロジェクトマネジメントの成熟度を向上させる上で効果を発揮します。

PMO用語集では知っておくべきPMO関連の重要語句が50音別に分類させれているため、知らない単語の意味をすぐに調べることが可能です。またPMO事例集では、マネジメントソリューションズが過去にPMO導入・実行支援を行った際の豊富な事例を、PMBOK(R)の9つの知識エリア（統合・スコープ・タイム・コスト・人的資源・調達・品質・コミュニケーション・リスク）ごとに分類しており、それぞれの事例で、原因、課題、解決策や効果を詳しく説明しています。既存のPMP試験対策にフォーカスしたiPhoneアプリとは異なり、実際にプロジェクトで働く方の使用を想定した実践的な内容のアプリです。
PMOについてこれから学習したい基礎レベルの方から、すでにPMOとして働いている上級レベルの方まで幅広い方々に使用いただけます。興味のある方はぜひご購入ください！

iPhoneアプリ「PMO用語集/事例集」に関してのお問合せは下記URLからお願いします。
https://www.isakuratech.co.jp/iphone_app/pmo_glossary_and_casestudy/contact.
php

株式会社マネジメントソリューションズは、代表取締役、高橋信也の著書『PMO導入フレームワーク』の発売に合わせて、PMOの効果的な活用方法に関してご興味のあるお客様を対象にPMO導入トレーニングを企画いたしました。

 マネジメントソリューションズは、PMOのリーディングカンパニーとして、プロジェクトマネジメントコンサルティング、PMO実行支援、プロジェクトマネジメントトレーニング、プロジェクト管理ツール(ProViz5)のトータルソリューションを提供しております。

「PMOを設置したいけど、実際どうしたらいいの？」「PMOのメンバーにはどのようなスキルが必要なの？」など、様々なお悩みが疑問をお持ちの方に、書籍で論じた「組織」「人」「プロセス」「ツール」の4つの視点からPMOの導入、活用例を丁寧にご説明します。

トレーニングでは、テキストのみの学習に留まらないより具体的なアドバイスをさせていただきます。座学の研修では得られない実践的知識をお伝えしますので、この機会にぜひPMO導入フレームワークトレーニングの受講をご検討ください。

 トレーニングに関してのお問合せはinfo@mgmtsol.co.jpまでお願いします。

 株式会社マネジメントソリューションズ

　現在、グローバル企業の日本国内基幹システム再構築プロジェクトにPMOとして参画しています。体制が少し変わっており、海外関連会社の現地コンサルタントが要件定義段階から参画しており、開発・テストも現地にて実施します。

　PMOチーム体制は、全体PMO・日本側PMOとして弊社が参画しており、海外側にも現地PMOがいます。各種計画書、報告書（プロジェクトマネジメント計画、テスト計画、進捗報告など）を作成する際は協業して実施するのですが、海外から出てくる資料は至ってシンプルで、日本側が期待しているものとはギャップがあります。最近もテスト進捗報告資料の記載内容で議論になりました。

　ここで、思ったのは、日本側の管理がToo much（過剰な、過度の）なのかということです。たしかに、海外が作成した資料はざっくりしていて、詳細は質問しないと分からない部分がありました。ただ、プロジェクトとしてハイライトされるべき点は明確に記載してあったりもします。また、海外側のPL、PMOと話してみると、それなりの意図を持って作成しています。

　一方、過去を振り返って、プロジェクトマネジメント計画を詳細に数十ページ作り、進捗報告項目を細分化し、いざ運用を初めても、現場がついてこなかったりします。ついには会議の中で「結局何が問題なのか分からない。サマリー資料を作ってくれ。」となったりします。
　他にも、テストフェーズで、原因区分を数十個作って、障害分析時に選択するように定義しても、現場が区分内容を理解できておらず、形骸化するケースもあります。原因区分を定義した当のPMOも、現場から区分内容について質問されて、答えられないケースもままある光景です。

　このような状況を防ぐためには、やはり目的・意図をしっかり検討することです。つまり、PMOであれば、定義した管理ルールに自分の思いを込める必要があります（軸やゆずれない部分など）。それを元に現場と議論すれば、よりよいものになるでしょう。

　バランス感覚、プロジェクト状況を考慮した柔軟な対応、現場との対話が必要だと常々思っています。あらためて、以下のようなポイントがToo muchになっていないかチェックしてみてはいかがでしょうか？

・計画書、報告書（内容、分量、グラフ、色など）
・各種プロセス（審議、レビューなど）
・会議体
など

　あと、他者の意見を聞く、海外プロジェクトであれば文化を受け入れるスタンスなどもベースとして必要でしょう。マネジメントに正解はないので、常に心をオープンにして、よいものは取り入れ、自分のマネジメントスタイルを広げることも重要ではないかと感じています。

　最後に余談ですが、海外メンバからお土産をいろいろもらうのですが、体が受けつけないものがありますね。まあ、食わず嫌いは損なので、ひとつは食べてみますが。。このとき、「まずい」ではなく、「これを美味しいっていうんだ」と思いながら、顔を歪めて食べています（笑）

　PMOの役割は多種多様と言われますが、同じように、PMOのパーソナリティ、スタンスも様々だと感じています。たとえば、プロジェクトの内容まで把握しようとするタイプと、そうでないタイプがいると思います。システム開発プロジェクトで言えば、どんなシステムを構築しているか、各チームがどんな内容で苦労しているかなど数値、形式だけでなく、中身まで把握するタイプとしないタイプです。

　この2つについては一概にどちらであるべきという訳ではなく、プロジェクト毎のクライアントのニーズ（契約）であったり、PMO体制・工数に依存します。また、PMOのスキル・経験等による部分もあると感じます。工数がないなかで、中身まで把握することは難しいですし、あまり知らない領域に下手に手を出すと、かえって現場を混乱させてしまいます。

　ただ、ここで気になるのは姿勢です。契約、スキル、工数負荷とは別の次元として、プロジェクトを理解する気持ちがあるかという部分です。PMOは中身を知らなくていいとか、残業が増えているので、自分の持ち場だけきちんとするというような壁を作る行動があれば気になります。たしかに、プロジェクトは役割分担が必要ではあるのですが、とかく大規模プロジェクトではチームも多く、チーム間での壁を取り払う、隙間を埋めることもPMOの役割であるので（PMO自身が埋める必要はなく、リスクとして検知し、進言する場合もある）、PMOは率先して壁を作らず、幅広く見渡す姿勢、拾う姿勢が必要と思っています。また、PMOとして管理プロセスを導入する際も、広い視野を持ち、現場を知らなければ、定着化まで辿り着きません。

　PMOとして、広い視野を持つ、アンテナを高くする方法として、現場と対話する以外に私は以下のことをやっています。（プロジェクト状況・工数の余裕度合・環境によって全てをやるわけではないですが）

• 現場のやりとりメールを把握する（気になるチーム、話題などのメールを追って、深堀する）
  ※現場のメーリングリストに入れてもらう場合もある
• プロジェクトルームで集まって議論していることに聞き耳を立てる、参加する
• プロジェクトで使っている専門技術について、インターネットで調べる
• プロジェクトの企画構想資料から読み込む（途中からプロジェクトへ参画した場合）
• プロジェクト参画時にクライアントに関する本（業界情報含む）を数冊読む
• クライアント先の類似プロジェクトの情報を収集して、文化を掴む
• クライアント情報を新聞、雑誌、インターネット等で収集
  ※RSSフィードやGoogleアラートなどプッシュ型の情報収集を行うと工数をかけずに収集できます
• クライアントの社内ホームページを見る（組織図やニュースなど）
  ※常駐している場合など、イントラネットが公開されているケース

など

　これらのことは、直接的にはPMOタスクには関係ないかもしれませんが（特に後半部分）、たとえば、プロジェクト内のメールにはPM、リーダーの状況、思いなどが表れていたりしますので、PMOタスクを進める上で重要な情報源になります。負荷状況を見極めて、会議体をアレンジしたり、気の利いた振る舞いができると（かゆいところに手が届く）、プロジェクトメンバとの関係性構築、プロジェクト改善に繋がることもあると思います。中身・状況が分かっている人（当事者意識がある人）には相談したくなるという部分もありますので、進捗状況や課題なども収集するのではなく、自然と集まる、集まり易くなる場合もあります。

　PMOなのでプロジェクトマネジメント領域に集中することは前提ですが、広い視点でプロジェクトに興味を持って、時間があるときに上記を試してみるのもよいのではないかと思っています。（あくまで、役割分担、工数負荷などとは違う次元での話です）

　PMOスキルを伸ばす、教育という観点でも、「PMOはシステム・業務の知識が必要か」という問いなどがありますが、あるに越したことはないと思っています。また、PMOをやりながらでも、上記観点で行動することで、徐々に身につけることができると思っています。（システム開発や業務支援など現場を経験している方が多いと思いますので、今までの経験を生かして、自分が深く経験している分野をベースに視野を広げることができると思います。また、詳しい領域を示すと、苦労話も共有できますし、現場との距離が縮まることがあります）

　PMOをやっていて、プロジェクトマネジメント領域を極めようと思い、特化して、マネジメントスキル向上を目指すこともあると思いますが、同じくらいに、現場のプロジェクトに目を向ける姿勢が大切なのかなと感じています。

　PMOとしていくつかのプロジェクトに参画していますが、ここ数年、システム開発方法論構築・活用（各種ツール、標準ドキュメント類等）に力を入れているシステム部門、システム会社が多くなってきたと感じています。実際、弊社は外部PMOとしてプロジェクトに参画しますが、あらかじめ開発方法論であったり、プロジェクト管理ツールや各種指標が用意されていることが多いです。品質向上、効率化、再利用、コスト削減、オフショア開発、マルチベンダー開発などを考えれば、各種方法論であったり標準化の必要性は自ずと導き出されます。また、標準化を推進する部門としてPMOが設置されていることも多いです。

　さて、各社が力を入れいている標準化の効果が出ているかというと、私が見ている限りでは厳しい状況かと思います。原因のひとつとしては、方法論が新規開発（スクラッチ）プロジェクトをモデルとして作成されていたり、自社または国内で設計～開発・テストまで一貫して実施する想定で作成されていることが挙げられます。実際のプロジェクトは、既存システムのエンハンスだったりリプレイスが多かったり、またコスト削減要請から、既存システムをなるべく流用するという方針があり、その中で設計書を流用するケースもあります。既存の設計書を流用するとなると、最新の方法論で定義された成果物とは当てはまらないケースがありますし、QCDや目的を考えると（プロジェクトの優先度がコスト（C）である場合など）、あるべき方法論にあわせることが必ずしも正解とはいえません。また、品質管理指標なども新規開発については充実していますが、既存システム流用などについては用意されていない場合が多いです。あったとしても、既存流用はケースバイケースであるのでなかなかマッチするものはないです。
また、オフショアでの開発やテストを想定していないため、きめ細かなフォローがない状況でもあります。たとえばプロジェクトマネジメント計画書を流用しようとしても、構成管理などオフショアと国内の連携などは定義できていなかったりします（たとえば、オフショアで開発した物件を、日本でどのように管理し、また改修が必要となった場合の受け渡しのやり様など）。また、グローバル企業では、ある拠点で開発したシステムを全世界の拠点へ横展開するなどあります。設計時に考慮するポイントがいくつかありますが、さすがにこの点まで方法論はカバーしていません。

　では、どうすればこのような状況を解決できるかですが、ひとつの考え方としては、方法論のバリエーションを広げるというやり方があるでしょう。ただ、既存システムのエンハンスやリプレイスとなると、置かれている状況も様々ですし、定型化は難しいです。この部分の労力とその効果を考えると現実的ではないといえるでしょう。投資対効果という面では、開発プロセスが新規開発（スクラッチ）とは異なり、導入頻度も高い、パッケージ開発までがバリエーションの対象となるでしょう。

　そこで結局は方法論では全てをカバーできない、限界があるという結論に落ち着くと思います。普通に考えれば当たり前ですが、意外と見えなくなっているのが現状と思っています。というのも、”今後のプロジェクトは全て方法論に則らないと駄目だ”など全社的な号令がかかっているケースがあったりするからです。また、方法論に沿っていれば文句は言われないというプロジェクト側の打算的？な部分もあるかもしれません。あと、プロジェクトを成功に導く方法論というのがあれば、誰もが頼りたくなるのではないでしょうか。

　たしかに、開発プロセス・タスクや成果物の定義は、プロジェクトのQCDに直結しますし、一番難しい部分です。なので、方法論に頼りたくなる部分もありますが（もちろん頼っていいのですが）、目的や意図を考えずに闇雲に従っては、無駄な工数で膨れ上がり、コスト削減を目的としているのに本末転倒となってしまいます。プロジェクトマネジメントにしても、方法論どおりに指標に基づいて、闇雲に集計、報告するのであれば、報告のための報告にしかなりません。

　繰り返しますが、システム開発方法論といっても、完璧ではないということです。この点をきちんとわきまえておく必要があると思っています。つまりは、足りない部分は自ら考えることが大事です。これが忘れがちで、いざ開発を進める中で、不要なタスク・成果物が見つかったり、また方法論にはないが、プロジェクト状況から作成が必要となる成果物が出てきたりします。

　翻って、今、現場のプロジェクトが求めているのは、方法論から必要な部分を抜く、足りない部分を足すというテーラリングのやり方だと思います。ただ、これがなかなかノウハウとしてありません。上述のPMO組織も方法論の作成および展開まではできていても、実プロジェクトでどう使われたか（テーラリングされたか）という一番欲しい生の情報について整理がされていないことが多いです。なので、テーラリングの要諦、勘所といったものが現在、求められれているのではないでしょうか？

　このようなノウハウを収集、蓄積するためには、PMOはできるだけ多くのプロジェクトに関わるのがいいと思います。薄く広くでいいので、各プロジェクトの状況とそれに合わせた方法論のカスタマイズであったり、やり様を確認し、一緒に検討することが大事です。このミッションを持ったPMO担当者は、一度に３つくらいのプロジェクトを掛け持ちで対応するのもいいかもしれません。ひとつのプロジェクトに従事するPMとは異なるPMOの存在意義のひとつかもしれません。できるだけ多くのプロジェクトの生の情報、勘所を持っていれば、PM支援であったり、プロジェクトの成功へ向けての助けが、よりできるようになると思っています。
（弊社も様々なプロジェクトのノウハウがありますので、この点は伸ばしていきたい分野のひとつと個人的には思っています）

　最後に、プロジェクトは変更が付き物ですので、柔軟性を持って取り組む必要があります。方法論に限らず、過度に信じる、頼る姿勢があると、”自分で考えなくなる”、”応用が利かなくなる”というリスク、デメリットが多いにあります。方法論、ベストプラクティス等は必要ですし、一定の効果は出ますが、プロジェクトはひとつとして同じものないという面からすると、”自ら考える”という意識が必要だと思います。現場ではこの意識が足りないという部分もあり、方法論の不備に目が行きがちで、導入・定着化への反発がうまれやすいです。また方法論を展開する側は、テーラリングのやり方だったり、実際に方法論を使った事例、サンプルなど生の情報がフィードバックできていないので、いまいち効果が出ていないのかと感じています。方法論等への向き合い方については、使える部分を使うという意識でいれば、建設的な行動が取れていくと思っています。（もちろん、有効な範囲で定型化、標準化するという意識・目的も併せ持ったうえで）