PMO（プロジェクトマネジメントオフィス）を生かす

第41回オフショア開発では双方にPMOを置く

オフショア開発では、「ブリッジSE」がオフショア先の進捗管理や課題管理を受け持つことも多いだろう。だが、ここには落とし穴がある。ブリッジ SEはあくまでも「SE」であり、マネジメント上の問題点を見過ごすかもしれないのだ。欧米のプロジェクトでは、発注側とオフショア先の双方にPMOを設置することが一般的になっている。

高橋信也
マネジメントソリューションズ代表取締役

　海外への事業展開を目的としたプロジェクトや日本への進出を目的としたプロジェクトなど、現在さまざまなグローバル・プロジェクトがあちらこちらで展開されています。特に急速に増えているのは、オフショアによるシステム開発プロジェクトでしょう。この6年ほどで、年率150％以上の成長を達成しています。都内のオフィス・ビルでも、中国人やインド人のエンジニアを見かけることが当たり前のようになってきました。

　オフショア開発では、いわゆる「ブリッジSE」と呼ばれる役割の人が日本側の要件を把握し、オフショア先のSEやプログラマに伝えるケースが一般的です。オフショア先のエンジニアが、ドキュメントだけを見て要件を把握できることは稀でしょう。大規模システムの保守案件などは、その部類に入るかもしれません。

　また、ブリッジSEがオフショア先の進捗や課題の状況を把握し、国内へ伝えるプロジェクト管理者としての役割も担うことも多いのですが、ここには大きな落とし穴があります。

　ブリッジSEの役割は、オフショア先に要件を正しく伝え、理解させることにあります。あくまでSEであり、プロジェクト全体を見る視点に欠けている場合が多く、プロジェクト管理も適切に行えない場合がほとんどです。

　筆者が中国へ出張した際、オフショア開発会社を5社訪問しました。日本向け事業の責任者とのミーティングでは、皆が口々に「日本側の要件が決まらないので、しわ寄せが多い」「日本側の頻繁な要件変更に耐えられない」「変更するかどうか分からない要件を、中国側で先走って開発してしまった」という問題を話していました。ブリッジSEでは、このような課題をうまくマネジメントできないのでしょう。

国内とオフショア先、双方にPMOを設置するのが成功の鍵

　PMOは、プロジェクト全体を“鳥の目”で俯瞰し、マネジメント上の問題を解決していくことが不可欠です。前述の課題について述べると、日本側とオフショア先の間で案件管理プロセスや変更管理プロセスが不十分であり、案件や変更要件の承認がうまく行われていないなら、まずその原因を把握すべきです。

　おそらく、ブリッジSEは問題があることを知っていたはずです。ただ、プロジェクト全体のマネジメントを向上させるための“鳥の目”を持っていないため、その原因を把握し、改善のためのアクションにつなげられなかったのだと思います。欧米のプロジェクトでは、発注側とオフショア先の双方にPMOを設置することが一般的になっています。そういう点は見習うべきなのではないでしょうか。

日本人同士とは違うコミュニケーション

　グローバル・プロジェクトにおいて、いくら管理プロセスを徹底し、頻繁な電話会議やメールのやり取りを行ったとしても、やはり対面での打ち合わせは必要です。特にプロジェクト・リスクに対する温度差は十分に埋めておくべきです。危機意識の違いからプロジェクトが予想以上に遅れることもしばしばです。

　日本国内では同じ部屋、同じ会議室で非言語でのコミュニケーションを頻繁に行っているため、危機意識の醸造はしやすいのですが、外国とのやり取りにおいては、一般に言われているように「論理的なコミュニケーション」が必要です。筆者の経験上、プロジェクトのスケジュールや課題、リスクについては、嫌と言うほどの説明資料を持って、うんざりするくらい会議を重ねる必要があると考えます。「一を聞いて十を知る」などという甘い期待は捨てましょう。そのギャップを埋めていくために、PMOは活躍すべきです。

グローバルPMOはカルチャー・ギャップも埋める

　オフショアに限らず、国内で外国人と共同でプロジェクトを行う場合も、宗教や生活習慣の違いを十分に考慮すべきです。特にインド人はベジタリアンが多く、食の好みもずいぶん異なります。PMOはプロジェクトの生産性を高めることに貢献すべきですが、外国人に対する気遣いもモチベーションを上げるために非常に重要なポイントです。外国へ行って仕事をするというのは、日本人が外国に行ってもそうであるように、さまざまな面で大変な思いをします。PMOに限らず、プロジェクト全体でカルチャー・ギャップを埋めていく気遣いが必要であると思います。

第42回プロジェクト制約条件のバランスをとる

PMBOKによると、「プロジェクトマネジメントとは、品質、スコープ、タイム、コストなど、競合する要求のバランスをとること」とある。だが PMBOKには、具体的にどうバランスをとるのかは記されていない。現実には、うまくバランスをとることと、あえてバランスを崩すことを、臨機応変に考えなければならない。

後藤年成
マネジメントソリューションズマネージャー PMP

　PMBOKではプロジェクトの制約条件について、以下のように書いています。

『プロジェクトマネジャは、競合するプロジェクト要求事項をマネジメントする場合に、プロジェクト・スコープ、タイム、コストの「制約3条件」に言及することが多い。プロジェクトの品質は、これらの3つの要因のバランスをとることによって決まる。高品質のプロジェクトは、スコープの範囲内で、納期通りに、予算内で、必要なプロダクト、サービス、または所産を提供する』

　やや硬い文章で分かりづらいかもしれませんが、要するに、「プロジェクト・スコープ、納期、予算、品質（以下、プロジェクト制約条件と呼ぶ）のバランスをとって、プロジェクトを運営すべきだ」ということです。もちろんPMOも、これらのプロジェクト制約条件のバランスをとりながら、プロジェクトを運営する責務を負っています。

　それでは、どのようにして、これらのバランスをとればよいのでしょうか。機能要求の膨張を防ぎ、スケジュール管理、コスト管理、品質管理を厳密に行えば、バランスがとれたプロジェクト運営ができるのでしょうか。みなさんは現実に、下記のようなプロジェクトが可能だと思いますか。

（1）当初定義した機能要件が全く変わらないプロジェクト
（2）すべてのタスクがスケジュール通りに進んでいるプロジェクト
（3）最初に計画した予算通りに費用が発生しているプロジェクト
（4）プロジェクト計画書で規定した通りの品質の成果物ができているプロジェクト

　プロジェクト・スコープ、納期、予算、品質のすべての要素が予定通りに進むプロジェクトなど、ほとんどないと言っても過言ではありません。これらの要素は互いに影響し合っているため、どれか1つの要素に予定外のことが発生したら、その時点でプロジェクト制約条件のバランスは大きく崩れてしまうのです。

リスク管理の下で、バランスを保つための「余裕」を作る

　今まで述べてきたように、プロジェクトにおいてすべてのプロジェクト制約条件を予定通り完璧に保つのは無理です。一般的な対策としては、計画時点でコストやスケジュールに「余裕」を持たせておく方法があります。その余裕が、機能追加や品質悪化によるスケジュール遅延などの変化を吸収して、バランスを保つ役割を果たします。

　しかし、納期短縮やコスト圧縮が重要視される現在において、そのような「余裕」を簡単には認めてもらえません。しっかりした根拠と、適切にマネジメントできることを示す必要があります。

　そこで、リスク管理が重要になってきます。プロジェクトで発生する不確定要素に対して、予算やスケジュール面で「なんとなく」余裕をもたせるのではなく、しっかりとしたリスク管理を計画・実行しなければなりません。リスクを金額化して、「プロジェクト・リスク費用（あるいはスケジュールのバッファ）」としてプロジェクトの全体予算に組み入れるべきなのです。リスク費用の根拠がはっきり示せば、抵抗なく認めてもらえると思います。

　逆にリスク費用が認められないようなプロジェクトがあれば、それはかなり危険なプロジェクトだと判断するべきでしょう。プロジェクト・リスクを金額化する方法は、「リスクが発生したときに発生するコスト×発生確率」で見積もるなど、さまざまな方法があります。詳細はPMBOKなどに記載されていますので、興味のある方は調べてみてください。

制約条件のバランスをあえて崩す

　既知のリスクにはリスク費用やスケジュール・バッファをとることができますが、未知のリスクが発生した場合にはどうしようもありません。そのようなときに必要なのは、「バランスをとることにこだわり過ぎないこと」です。プロジェクトの特性によって、プロジェクト・スコープ、納期、予算、品質について優先順位を付けておき、プロジェクト関係者全員でその優先順位について合意しておくことが重要です。

　例えば、人の命に関わるような物を作っているプロジェクトの場合は、納期やコストが多少オーバーしても中途半端な品質のものは作れないはずです。また、法改正などでどうしても期限までに対応が必要なプロジェクトの場合は、機能を多少削ったりしても納期を優先すべきなのです。

　もちろんPMBOKには、「万が一の時は、プロジェクト制約条件のバランスを崩しましょう」なんてことは書いてありません。PMBOKはあくまで知識体系に過ぎません。PMOは基本を大切にしながらも、時には臨機応変に、優先順位に基づいてプロジェクト制約条件のバランスを崩すことを考えなければなりません。そして、プロジェクトマネジャをはじめとする関係者に、それを提案する能力が求められます。

　そのためにもPMOには、日々現場の様子を観察し、怪しいにおい（未知のリスク）をいち早く察知できる嗅覚が必要なのです。

第43回報告会議で「客観的・コンパクト」をいかに実践するか

マネジメント層が知りたい情報は、プロジェクトの全体感やQCD（品質・コスト・進捗）の予実績をコンパクトにしたものだ。客観的にプロジェクト状況をレポーティングすることが求められる。常にプロジェクトを俯瞰しているPMOの出番である。

川上愛二
マネジメントソリューションズマネージャー

　マネジメント層への報告（マネジメント・レポート）にかけられる時間は限られています。皆さんもご存知の通り、マネジメント層は複数プロジェクトを抱えていますし、社内作業も多数持っているので非常に多忙です。いざ報告会議を始めても、主要メンバーのスケジュールによっては途中で中断される事態も多々あります。せっかく気合いを入れて、たくさんの資料を用意しても、使わずじまいになったりします。

　「マネジメント層への報告は要点を絞れ」とはよく言われますが、今一度整理してみると、以下のようなポイントが挙げられると思います。

（1）結論から報告する。
（2）概要資料と詳細資料を作成する。マネジメント層から突っ込まれたときに、詳細資料で補足できるようにする。
（3）定量情報、シグナル（○、△、×）をうまく使う。
（4）情報を圧縮し、マネジメント層が理解できる言葉に翻訳して、コンパクトに報告する。

　限られた時間の中でマネジメント層に簡潔な状況説明を行い、意思決定してもらう必要があります。だらだらと記述した資料では、目を通してもらえない可能性があります。

　それゆえ、資料の最初に「一番伝えたいこと」を持ってくるべきです。定量的に情報を伝えるとインパクトがあります。マネジメント層の記憶にも残るでしょう。フェーズ完了報告会議、出荷判定会議などでは、シグナルを有効に使うことで興味を引けると思います。

「結論だけの報告」は報告にあらず

　結論をコンパクトに報告することは重要ですが、だからといって結論に至るまでの「検討経緯」を端折ってはいけません。マネジメント層はまず結論を知りたがりますが、それに至るまでの検討経緯にも注目しています。現場を離れたマネジメント層の多くは詳細内容を理解できなくなっていますが、「結論に至るまでの論理に綻びがないか」「リスクがないか」という視点で見ています。そうした要望にこたえられる説明を心掛けるべきです。

　報告の内容面では、以下のポイントを忘れずに記載する必要があります。それぞれの点について、順を追って説明していきましょう。

◆前回報告からの変更点（前回指摘を受けた部分への対応結果など）

　マネジメント層は前回報告した内容をきちんと記憶しています。特に自分が質問した点や宿題としてプロジェクトが持ち帰ったものについては覚えているものです。まずは、前回報告からの変化点や指摘を受けた部分についての対応結果を報告する必要があります。

◆QCD予実績、今後の見通し（要員投入計画など）
◆重大課題、リスクのエスカレーション

　進捗状況についても、キーとなるマイルストーンの遅れについて報告し、QCDへの影響、リカバリ・プランなどを伝える必要があります。課題、リスクについては、マネジメントの判断が必要なものをピックアップし、エスカレーションします。

　ここでも、マネジメント層に決裁してもらうためには、そもそもの課題のゴール、検討経緯（判断に至ったオプション比較案など）を提示する必要があります。プロジェクトメンバーがどこまで全体感を持って、深く検討しているかがチェックされるでしょう（第40回「検討経緯が残っていない」というリスク）。

◆マネジメント層への依頼

　報告に盛り込むべきマネジメント層への依頼事項は、多岐にわたります。具体的には次のような事項が挙げられます。

· トップダウンによるユーザーの巻き込み（プロジェクト説明キャラバン隊編成など）

· ステークホルダーとのトップ会談

· プロジェクトメンバーのモチベーションアップを図るための現場慰問

· ねぎらいのメール

　マネジメント・レポートは、マネジメント層との貴重な接点ですので、うまく利用するとよいでしょう。

◆プロジェクトの経緯

　最後に、マネジメント・レポートには、プロジェクトの現在に至るまでの経緯を常に載せておく必要があります。マネジメント層は多忙なため、報告会議に出席するメンバーがいつも同じとは限りませんし、初めて参加するメンバーがいるかもしれません。過去の経緯をまとめた資料があれば、マネジメント層が報告内容を適切に理解する助けになります。

マネジメント・レポートは第三者的な視点で

　以上、いろいろ述べましたが、端的に言ってマネジメント層は「プロジェクトがうまくいっているか否か」を知りたいのです。仮に今はうまくいっていなくても、「見通しが立っているか否か」を知りたいのです。とかく運用保守フェーズのマネジメント・レポートは、ミスを繕ったり、言い訳に終始しがちですが、内部向けでは、客観的に原因を報告し、アクション・プラン、恒久的な対応、対策を提示することが重要です。

　このように、マネジメント・レポートには客観的な第三者の視点が求められます。その意味で、マネジメント・レポートをファシリテートするのに最も適した立場はPMOです。報告資料を作成する場面でも、PMOが客観的事実、数値データを基に叩き台を作成し、プロジェクトマネジャがレビュー、補足する形も有効です。

　また、PMOの立場なら、マネジメント層へ率直にプロジェクト状況を訴えることができます。プロジェクトがいかに重要な局面か、問題がある場合はそれがいかに深刻かを適切に伝え、サポート体制を依頼することができます（第27回必要なら、プロマネに逆らっても「助けて！」と叫べ）。マネジメント層との連携を密にしておくことが、プロジェクト成功への一歩となります。

第44回プロジェクトの「2歩先」を見ているか？

常に「2歩先のこと」を考える――。プロジェクトマネジメントの現場では、先回りして準備できるかどうかが成否を分ける重要なポイントの1つとなる。だが、プロジェクトマネジャやPMOが目先の仕事に目を奪われているとしたら、そのプロジェクトの先行きは危うい。2歩先を見る担当者を置き、次工程の準備作業を並行して進めなければならない。

後藤年成
マネジメントソリューションズマネージャー PMP

　皆さんのプロジェクトで、プロジェクトマネジャやPMOは目の前にある仕事に忙殺されていないでしょうか。プロジェクトマネジャやPMOが目の前の仕事に忙殺されていると、今はなんとかプロジェクトが運営できていても、次の工程では必ず混乱を来たします。

　鉄道に例えてみましょう。プロジェクトマネジャとPMOは線路（計画）を敷いていきます。プロジェクトマネジャは運転手となり、敷いた線路に沿って列車（プロジェクト）を目的地まで導きます。途中で列車が脱線したり、遅延したりしないようにコントロールするのがPMOです。

　さて、ここで少し考えてみましょう。線路（計画）は最初からすべて詳細に敷かれているのでしょうか。プロジェクト開始当初に敷かれる線路（プロジェクト計画書など）は、あくまでも青写真にすぎません。実際に運行がスムーズにできるような線路を敷くためには、日々変わる状況を加味する必要があります。さまざまな障害物やリスクを考慮して、まずは青写真から実現性のある「路線図（計画のための計画）」を作るべきでしょう。

　路線図があってはじめて、線路を敷くことができるのです。筆者は、この路線図を描くのはPMOの役割だと考えています。PMBOKでは、このようにプロジェクトの進行とともにより具体的に計画を精緻化していくことを「段階的詳細化」と言っています。

　PMOが現在の仕事に忙殺されてしまうと、誰も路線図を描くことができなくなってしまいます。すると、列車は目標への線路自体を失ってしまうことになり、脱線どころでは済まなくなってしまうのです。つまり、「計画のための計画」を立てることがPMOにとって重要な責務の1つなのです。

線路図を描く時の勘所

　それでは、実際のプロジェクトにおいて「計画を立てるための計画」とはどのようなことを指すのでしょうか。さっと思いつくだけでも、具体的には次のような作業が考えられます。

· テスト計画書など、「計画書を作るためのスケジュール」を作成する

· 次の工程の開始基準や終了基準、具体的な成果物を確定する

· テスト仕様書などの「ひな型」を作成する

· 次の工程での管理手順を検討する（進捗のとり方、障害管理、報告書のひな型など）

· 次の工程の体制や会議体を検討する

· 環境やインフラなどを事前に整備する

　上記をご覧になればお分かりと思いますが、要は次工程の詳細計画を立てるために必要な事前準備と捉えることができます。

　実際に、計画工程に入った時は、目次レベルは当然のこと、各種のひな型まですべてできていて、プロジェクトメンバーは中身を埋めるだけ、というのが理想的な状態です。例えば、テストケース表のひな型とテストケース作成基準ができていて、プロジェクトメンバーはテストケースの内容を考えるだけ、といった具合です。

　プロジェクトメンバーが計画書の内容を埋める頃には、PMOはさらに次の工程の「計画の計画」に着手しているべきです。

「計画のための計画」を立てるメリット

　PMOが計画のための計画を立てるメリットは、次の工程計画が円滑に作成できることだけではありません。そのほかのメリットとして、次のような点が挙げられます。

（1）早い段階でリスクを洗い出せるため、リスクに対応する猶予が持てる
（2）考えるべき作業を数人で先行して決めてしまうため、「前の作業が終わらないとそのほか大勢のプロジェクトメンバーが着手ができない」といった状況を避けられる
（3）作業規模や負荷感を事前に把握できる
（4）重要な決定事項を事前に上位層や顧客に連絡することがきる。意思決定の時間を十分に確保できる

　今回は、「PMOは常に2歩先のことを考えてプロジェクトを進めていく」というポイントについて書きましたが、当然PMOは現時点でのルーティン業務もあります。この課題に対応するには、PMOの組織にひと工夫するとよいでしょう。PMOのメンバーの中に、「2歩先のことを考えるメンバー」「プロジェクトマネジャと一緒に計画を立てるメンバー」「計画に沿って現場の進捗や課題を管理するメンバー」というように役割分担するのです。これがPMOの組織力を高めるための重要なポイントになるはずです。

　皆さんのプロジェクトのPMOが目先の仕事だけに追われていないか、今一度チェックしてみてください。

第45回ユーザー企業の組織的PM力を強化せよ（1）

個々のマネジャがプロジェクトマネジメント（PM）の能力を高めることは不可欠だ。しかし、企業がそのような研修の場を提供するだけで安心しているとしたら、根本的な問題が見えていないと言わざるを得ない。個人レベルだけでなく、「組織」としてのプロジェクトマネジメント力も、早急に高めていく必要がある。

高橋信也
マネジメントソリューションズ代表取締役

　改めて言うまでもありませんが、ユーザー企業において、システム開発プロジェクトの数は年々増加しています。また、一つひとつのプロジェクトの複雑さ、大きさも増しています。

　ある金融機関の情報システム部では、プロジェクトの数、規模、予算が3年前の倍になり、その結果、今まで以上にプロジェクトマネジメントを強化しなければならなくなったそうです。また、プロジェクトマネジメントの研修は以前にも増して需要が多く、単にPMP（Project Management Professional）資格を取得するためだけでなく、現場での実践力の向上を主目的としたトレーニングも増えています。

「個人」のスキルアップも重要だが、「組織」としての体質強化を

　ユーザー企業がプロジェクトマネジメントの強化に取り組み出している背景には、下記のような問題があります。

・火を噴いてからでないとプロジェクトの問題が明るみに出ない
・ベンダーやコンサルティング会社の言うがままになっている
・見積もりの妥当性が不明瞭
・開発ベンダーに聞かないとプロジェクトの状況が分からなくなっている
・自社システム部門はユーザー部門とベンダーの調整役になり切れていない

　これらの問題を解決すべく、情報システム部門や情報システム子会社の方々はプロジェクトマネジメントのスキルアップのために日夜努力されていることと思います。しかし、根本的な問題が解決されないまま放置されていないでしょうか。

　それは上記のような問題の根源が、個人レベルのプロジェクトマネジメント力にあるのではなく、「企業組織として、個々のプロジェクトにどこまで口を挟むべきか、首をつこっむべきか」という方針が定まっていないことにある――と考えているからです。このような問題を抱える企業はかなり多く、結果として「組織的なプロジェクトマネジメント力」の低下につながっています。

だいたい失敗に終わっている

　組織的プロジェクトマネジメントの代表例は、本連載のテーマでもあるPMO（プロジェクトマネジメントオフィス）です。ただし、ユーザー企業として各プロジェクトにPMOを組織し、プロジェクトマネジメントを強化すればよいかというと、それはそれで負荷やコストがかかり過ぎます。一般的にユーザー企業は、複数プロジェクトを扱う「“プログラム”マネジメント」や、企業全体のプロジェクトを扱う「“エンタープライズ”プロジェクトマネジメント」を行えばよいでしょう。

　これまで本連載では単体プロジェクトにおけるPMOを対象に話を進めてきましたが、複数プロジェクトにおけるプロジェクトマネジメントやPMO（“プログラム”マネジメントオフィス）では、その性格が多少異なります。それぞれのユーザー企業における定義の仕方にもよりますが、一般的には「予算管理」「標準化推進」「火消し部隊」としての役割を担うことが多いようです。日本のシステム・インテグレータでも、2000年ごろから予算管理や標準化推進を目的としたPMOが次々に導入されました。予算管理を行う上で、「プロジェクトポートフォリオマネジメント（PPM）」を導入しているシステム・インテグレータもあります。

　このような組織は、各プロジェクトの立場から見ると、“お上（おかみ）”のような存在であり、煙たく感じられることが多いようです。実際のところ、ほとんどの企業ではうまく機能していません。

　もちろん、予算管理、標準化推進、火消し部隊といった役割をそれなりに果たしているケースはあります。しかし、個々のプロジェクトとうまく連携を取りつつ、プロジェクトにとっても必要とされる存在として認められている組織は、本当に一握りです。そもそも火消し部隊としての役割は本末転倒で、火が噴かないようにプロジェクトマネジメントを支援することが本来のPMOの役割です。

　では、ユーザー企業として、どのようなPMO組織を構築すればよいのでしょうか。そのポイントは下記のようになります。

（1）プロジェクト管理情報ネットワークを構築する
（2）課題のエスカレーション・プロセスを定着させる
（3）プロジェクト管理の必要性を“腹落ち”させる
（4）PMO側のスタッフのマインドセットを変える
（5）プロジェクトから必要と思われるような「PMOの実績」を上げる

　次回は、上記のポイントについて詳しく述べていきたいと思います。

第46回ユーザー企業の組織的PM力を強化せよ（2）

ユーザー企業内でPMO組織を立ち上げても、単なる“管理屋さん”に陥り、「現場から煙たがられるだけ」というケースが実に多い。それを防ぐには、基本的な部分を正す必要がある。まず「情報を吸い上げる人的ネットワーク」を作り、課題を「スムースにエスカレーションさせる」。当たり前のように思われるだろうが、それができていないから“管理屋さん”に陥るのだ。

高橋信也
マネジメントソリューションズ代表取締役

　前回、ユーザー企業の組織的プロジェクトマネジメント（PM）力を付ける必要性について述べました。ユーザー企業は複数のプロジェクトを複数のベンダーやコンサルティング会社に発注する立場上、プロジェクトマネジメントやプログラムマネジメントは必須のスキルとなります。それを個々のマネジャに任せるだけではなく、PMO（プロジェクトマネジメントオフィス）などにより組織的なプロジェクトマネジメントを実行することが肝要です。

　しかしながら、PMO組織を発足させたとしても、そもそも狙いや役割が不明瞭なままでは企業の中で定着しません。PMO組織の役割を小さく限定してしまうと、単なる“管理屋さん”に陥ってしまう可能性があるので、注意が必要です。

　一方、PMO組織の役割に関して、大風呂敷を広げてしまったら、どうなるでしょうか。PMOという組織には、非常にたくさんの役割を期待されるのが常です。例えば、PMOに関する調査結果から浮かび上がってきたPMOの役割の一部として、下記のようなものが挙げられています。

・上層管理部門にプロジェクトの進捗を報告する
・スタンダードな手法を展開・実施する
・プロジェクトのパフォーマンスを監視しコントロールする
・トレーニングを含めた人材の能力開発をする
・上層経管理部門にアドバイスする
・プロジェクト間の調整をする
・組織内のプロジェクトマネジメントを促進する
・PMOのパフォーマンスを監視しコントロールする
・プロジェクトマネジャを指導する
・プロジェクトのドキュメントを保管・管理する
・プロジェクトを監査する

　役割がこれほど多岐に渡ってしまうと、PMOの要員配置や人数も分からなくなってしまいます。また、PMOを組織化したとしても、必要十分な人数を常時抱えておくことはできません。必要最低限の人数で、どのように効果を発揮していくかが重要な点です。以下、PMOを推進していくに当たって、ぶつかりやすい壁に対する対処策を述べていきたいと思います。

ポイント（1）プロジェクト管理情報ネットワークを構築する

　ユーザー企業にとって必要なPMOの第1条件とは何でしょうか。ほとんどの場合、すべてのプロジェクトの状況を把握することだと思います。プロジェクト状況把握のために、プロジェクト管理標準を導入・定着させ、プロジェクト報告会議の定例化、プロジェクトマネジャのトレーニング、プロジェクト管理ツールの導入・定着化といった、さまざまな取り組みが行われていることでしょう。

　しかしながら、管理帳票はたくさんできているのに、有益な情報が得られていないのが実情です。結果的に、管理プロセスが形骸化する傾向にあります。また、管理を徹底させようと現場に多くの管理負荷を与えてしまうことも、管理プロセスを形骸化させてしまう要因の1つです。

　それを防ぐためには、「人的な管理情報ネットワーク」を構築する必要があります。PMOは、公式・非公式な情報収集のルートを、必ず握っておかなければなりません。また、「報告・連絡・相談」という報連相（ほうれんそう）の習慣を、PMOおよびプロジェクトマネジャ自身がしっかりと身に付けるべきです。これが情報を吸い上げる組織構造の基礎になります。

ポイント（2）課題のエスカレーション・プロセスを定着させる

　情報を吸い上げる組織構造ができたとしても、ただ漫然とプロジェクトの問題を話し合っているだけでは何の解決にもなりません。社内PMOという立場上、プロジェクトの情報はいくらでも入ってくるため、単なる“評論家集団”に陥りがちです。プロジェクトの現場から見ると、「うるさい外野」のように映り、プロジェクトマネジメントの改善につながりません。

　PMOはステークホルダーマネジメントに貢献すべきです。プロジェクトマネジャがプロジェクト内で解決できない課題に対して、社内のどこにどのようにエスカレーションすべきか、PMOはアドバイスだけでなく、一緒に動いて課題をエスカレーションするための努力が必要です。

　さて、次回は引き続き、以下の3つのポイントについて述べたいと思います。
（3）プロジェクト管理の必要性を“腹落ち”させる
（4）PMO側スタッフのマインドセットを変える
（5）プロジェクトから必要と思われるような「PMOの実績」を上げる

第47回ユーザー企業の組織的PM力を強化せよ（3）

ユーザー企業内でPMO組織を立ち上げるには、いくつかの困難や弊害を伴う。だが裏返せば、それらに正しく対処することが成功のポイントでもある。 PMOが単なる“管理屋さん”に陥らないようにするには、PMO自身が高い意識を持ち、さらにプロジェクトの関係者にも伝播・定着させていく取り組みが重要だ。

高橋信也
マネジメントソリューションズ代表取締役

　前回は、プロジェクト管理情報ネットワークを構築し、課題のエスカレーション・プロセスを定着させる点について述べました。これらのポイントをクリアすることができれば、社内PMO（プロジェクトマネジメントオフィス）と各プロジェクトのプロジェクトマネジャの間で、人的関係が密になるでしょう。そして、「プロジェクトマネジャが頼りにするPMO」としての存在価値が生まれます。

ポイント（3）プロジェクト管理の必要性を“腹落ち”させる

　そんな「頼りになるPMO」が活躍すべき場は、もちろん報連相（ほうれんそう）の場面だけではありません。プロジェクト内の「意識合わせ」や「カルチャー作り」という場面でのサポートも、社内PMOの役割の1つです。

　例えば、プロジェクト内の管理が徹底されていないと、そもそもプロジェクトマネジャ自身が情報収集に手間取ることになり、多くの時間を割かなくてはならなくなります。そこに「プロジェクトマネジャを組織的に支援する」というPMOの存在理由があります。社内PMOは標準的な管理プロセスを持っているでしょう。それをプロジェクトの現場まで落とし込んでいくためのサポートをすべきです。

　その際、ただ「必要だからやってくれ」「そういう決まりだから」という理由で説明しても現場は動きません。ただでさえ現場にとって「管理は面倒なもの」なのですから、プロジェクト管理の必要性をきちんと“腹落ち”させなければなりません。その一押しが重要なのです。

　現場で管理をしっかりやることで、「いかにプロジェクトが可視化」され、「いかにプロジェクト内外のステークホルダーとの調整がうまくいくようになるのか」ということを社内PMO、プロジェクトマネジャの両者が十分に説明すべきでしょう。加えて、PMOが日々の管理業務を通じて現場に確かな理解を促す必要があります。

ポイント（4）PMO側スタッフのマインドセットを変える

　ユーザー企業の社内PMOが機能不全に陥る原因の1つに、社内PMOの「マネジメント意識」の問題があります。社内PMOの組織的位置付けなどとも関係した、やや複雑な問題です。しかし、PMO側スタッフが本来の基本的な役割さえ理解できれば、彼らの行動は見違えるほど変わります。

　社内PMOの機能を担う組織は「品質管理部」「プロジェクト管理部」などの名称で呼ばれることが多いでしょう。組織図上は「社内管理部門」という位置づけになっています。所属するスタッフも、必ずしも現場での経験が豊富というわけではなく、プロジェクト側から見るとスキル面で見劣りしてしまうことが多々あります。そういう場面でPMOスタッフが萎縮したり、“管理屋さん”としての仕事に閉じこもってしまう可能性があります。

　しかしながら、PMOスタッフはプロジェクト要員の代替ではありません。PMOスタッフには固有の任務があることを、肝に銘じておくべきでしょう。

　組織的プロジェクトマネジメントを実行していくために、たとえPMOスタッフのスキル・経験が乏しくても、やれることはたくさんあります。PMOという立ち位置でプロジェクトを観察した場合、プロジェクトの「リスク」や「ステークホルダーとの関係」などは、プロジェクトの専任メンバーよりもずっとよく見通せるものなのです。

　このコラムでも以前述べたように、PMOは管理責任を負うのではなく、説明責任を負うべきです。したがって、PMOスタッフとして「プロジェクトを見る目」を養う必要があります。そのために必要なことは、プロジェクトマネジメントの理論を学ぶことではありません。「マネジメント」という立場に必要なマインドを持つことです。

ポイント（5）プロジェクトから必要と思われるような「PMOの実績」を上げる

　社内PMOが「プロジェクトから必要と思われる存在」として評価される手っ取り早い方法は、「PMOとしての実績」を上げることです。PMOが参画したことで、プロジェクトマネジャやメンバーが「すごく円滑に運営できるなった」と感じているようなら大成功です。

　もちろん、プロジェクトの状況を可視化しただけでは「実績」と呼べません。PMOとして最も手柄が立てやすい分野は、リスク・マネジメントとステークホルダー・マネジメントです。まずは、このあたりを重点的に改善するとよいでしょう。リスク・マネジメントは過去のプロジェクトからの事例をベースにリスク基準を作ると効果的です。また、ステークホルダー・マネジメントは、調整会議の開催や、特にライン組織との調整役として実績を積みやすいと思います。

　ただし、PMOとしての実績を上げることばかりに気をとられると、長い間には弊害も出てきます。陥りやすいのは、PMO組織の肥大化です。

　社内PMOは、大企業だと比較的大きな組織になることがあります。組織的プロジェクトマネジメントを実行していくために、ある程度大きな組織が必要なのは当然です。しかし、逆にプロジェクト側から頼られすぎて、PMOが「肥大化するリスク」も出てきます。

　PMOに「火消し役」としての実績や「プロジェクト予算管理」の役割が求められ始めると、大きな権限も持つようになります。その良し悪しを論じるつもりはありませんが、このコラムで述べているPMOの役割（説明責任はあるが管理責任はない）を超えた組織になりますし、概して現場に煙たがられる存在になりがちです。一方、権限はなくとも、社内PMOとして長く在籍している社員は、権威を持つようになってくるかもしれません。それは、プロジェクトに良い影響ばかりを与えるものではありません。

　一度作り上げた社内PMOは、常に改善していくべきです。本田宗一郎さんとともに“HONDA”を作り上げた、藤沢武夫さんの著書に『経営に終わりはない』という本があります。プロジェクトマネジメントやPMOにも終わりはなく、常に変化・改善していくべきものです。

第48回「なぜなぜ5回」がプロジェクトの雰囲気を悪くすることも

プロジェクトを進めるにつれ、なかなか解決しない課題が山ほど出てくる。「この課題が解決しない原因は？」「なぜ？なぜ？なぜ？」を問い詰めていくと、プロジェクトの雰囲気を悪くしてしまうことがある。改善活動に必須の「なぜなぜ5回」も、プロジェクトでは問題に合わせた使い方をしなければならない。

松永幸大
マネジメントソリューションズマネージャー　中小企業診断士

　問題を解決しようと「なぜ？なぜ？なぜ？」と問題を原因分析していくことは、いわゆるトヨタ式の「カイゼン」、QC（品質管理）サークル活動といった形で多くの企業・プロジェクトが実践しています。問題を解決する活動以外にも、企画書を上司に出す際に、「ここはなぜ？それはなぜ？どうして？」と繰り返し聞かれた経験がある方も多いと思います。「なぜ？なぜ？」を繰り返すことは、理屈が通っていなければならないビジネスの世界では「当たり前」に行われている習慣です。

　プロジェクトの現場でも「なぜ？なぜ？」が重要なのは同じです。例えば、進捗会議の場で多くの方が、下記のような場面に遭遇していると思います。

PMO（プロジェクトマネジメントオフィス）：「画面設計の進捗が計画通りに進んでいないようです」

プロジェクトマネジャ：「それはまずいな。原因は何？」

チームリーダー：「当初想定していたよりも画面の難易度が高いために、思うように作業が進んでいません」

PMO：「当初想定していたよりも画面の難易度が高かった画面は、何画面あるのですか。それらは具体的に、どのように難易度が高かったのですか？」

チームリーダー：「数はすぐには分からないので、会議終了後に確認して、ご報告します…」

プロジェクトマネジャ：「ついでに、当初の画面難易度の見積もりとズレが生じている理由は何かな。現時点で作業に取りかかっていない画面でも、同じようなズレが発生するかもしれないよね？」

チームリーダー：「それについても、会議終了後に確認して、ご報告します…」

　この問題を深堀りしていく「当たり前」の行為は、それを解決しようと強く思うほど、徹底的に問題の原因を追求しようとします。「なぜ？を5回繰り返せ！」なんて号令をかけられている現場なら、とにかく「なぜ？」を5回繰り返してみるものです。多くの場合、こうした習慣が良い結果をもたらすことに異論はないでしょう。

原因追求型の「なぜ？」は人・組織からの反発を受けやすい

　しかし、問題にもいろいろな種類があります。物の製造に関する問題の改善やシステムの問題は、緻密に分析していくことで原因を潰すことができ、結果として問題が解決されることが多いでしょう。

　その一方で、プロジェクトでは物の製造やシステムの問題よりも、「人」「人のつながり」「組織」に関係する問題のほうが大きく横たわっています。そして、人・組織の問題は、「なぜ？」を繰り返すことで問題を突き止めれば解決できるほど単純ではありません。人や組織は、自分が悪いとされただけで反発心が生まれ、「自分が悪いのではなくて、××が悪い」と自己防衛してしまうケースが多々見られます。

　例えば、あなたのプロジェクトで「○○部の協力がうまく得られていない」といった問題が起こったとしましょう。原因追求型（問題志向）の「なぜ？」を連発すると、次のような状況に陥ることもあるのではないでしょうか。

PMO：「なぜ○○部の協力がうまく得られていないのですか？」

業務チームリーダー：「○○部のAさんの時間が取れないのです」

PMO：「なるほど。○○部のAさんの時間が取れないのはなぜですか？」

業務チームリーダー：「○○部の部長に支援の取り付けをしていますが、それが甘いからだと思います…」

PMO：「なぜ部長の支援の取り付けが甘いのですか？」

業務チームリーダー：「うちのチームのBさんの働きかけが足りないからだと思います……」

PMO：「それならBさんの働きかけを改善してもらえば解決しそうですね」

業務チームリーダー：「そうかもしれませんが、Bさんの担当でない領域のタスクも支援しなくてはならなくなったので、工数が取れていないんです。むしろ、悪いのはBさんではなくて『人が足りない』というプロジェクトの状態が原因だと思います。何とかしてください」

PMO：「そんなことを言っても、予算とスケジュールってものが…」

　上記の例の場合、予算やスケジュールの配分をマネジメントできれば解決できますが、会話の最後でプロジェクト全体の「人不足」の話にすり替えられてしまいました。こうなると堂々巡りで、「じゃあ、継続検討ってことで…」となりやすいものです。問題が解決しないばかりか、話がこじれ、いつまで経っても解決しない、という事態になる危険性もあります。

　さらにやっかいなのは、人間関係も悪化して、プロジェクトの雰囲気を悪化させてしまうことです。故障して止まった機械は黙って修理を待ちますが、人は「悪いのは、あなた」と言われてしまうと、「反発感情→人間関係の悪化→プロジェクトの雰囲気悪化」というように、悪感情がじわじわとプロジェクト全体に伝播しやすいものです。人間関係の悪化とプロジェクトの雰囲気悪化が起こると、生産性の低下はもとより、プロジェクト崩壊の一因になると言っても過言ではありません。

　こういった組織問題の原因を「なぜ？なぜ？」と分析していくと、その最小単位である「人」の問題に必然的に辿り着きます。それが軋轢（あつれき）を生む原因にもなります。

人を追及しないための「発想の転換」

　では、「人」の問題にどう対処すればよいのでしょうか。結論を先に言うと、原因追求型の「なぜ？」ではなく、解決志向の「どうやって？」を使うのです。

　近年注目されているコーチングやソリューション・フォーカスといったポジティブ・アプローチもそうですが、問題の原因追及よりも「手に入れたい状態」を「どのように実現するか」を考えるのが『解決志向』です。

「Whyではなく、Howを考える」

　こんなフレーズを耳にしたことがある方は多いのではないでしょうか。

　解決志向で問題に当たる場合、「原因」となっている人・組織を追求することなく、どうすれば一緒に実現できるかを検討していけるようになります。先ほどの例のようにプロジェクトで「○○部の協力がうまく得られていない」という問題が起こったときは、次のような感じで「どうやって？」を使ってみましょう。

PMO：「○○部の協力が得られている状態って、どんな感じかな」

業務チームリーダー：「そうですね…。積極的に、前向きに協力してくれている感じですよね」

PMO：「たしかにそうだよね。前向きな感じって、どうすれば作れると思う？」

業務チームリーダー：「まず、仲良くなることじゃないですかね。あとは、プロジェクトに対して理解してもらっている感じですよね」

PMO：「なるほど。どうやったら、もっと仲良くなれるかな？」

業務チームリーダー：「いろいろあると思いますけど、とりあえず、今晩にでも○○部の部長さんと飲みに行って、終電まで語り合いましょうか」

PMO：「そりゃいいね。じゃ、私も行くので、早速やってみましょう」

　上記の例を見ると、原因はコミュニケーション不足で、対応策は非公式なコミュニケーションの実施、という見方をすることも可能かもしれません。ただ、実際に原因追求型で検討した場合には、この解にたどり着かず、誰かのせいで終わってしまうかもしれません。

　PMOの役割は、「プロジェクトの成功を目指し、円滑にプロジェクトを進めるためのサポートをする」です。犯人探しをして、プロジェクトの雰囲気を悪化させることではありませんし、もちろん誰もそんなことを望んでいません。「問題志向」が悪いアプローチだと言いたいわけではありません。問題志向アプローチを採る場合は多角的に分析する、それと共に解決志向も利用する、という広い視野を持つことがPMOには求められていると考えればよいでしょう。

　プロジェクトの雰囲気を明るくし、プロジェクトを成功させるために、問題志向だけではなく「解決志向」の考え方も取り入れてみてはどうでしょうか。プロジェクト全体のコミュニケーションの潤滑油として、PMOがちょっと発想を変えるだけでプロジェクトの雰囲気は明るくなります。それはプロジェクト・メンバーのモチベーションを良好に保ち、結果としてプロジェクトの推進につながっていくことでしょう。

第49回プロジェクトを成功させる「魔法の言葉」

プロジェクトを円滑に進める魔法のような言葉があると言ったら、読者の皆さんは信じるだろうか。会話の最初にその枕詞（まくらことば）を付けるだけで、プロジェクトがゴールに向かって自然に歩み出す魔法みたいな言葉だ。プロジェクトメンバーがその言葉を使い始めると、現場の雰囲気がとても前向きになる。

後藤年成
マネジメントソリューションズマネージャー PMP

　PMO（プロジェクトマネジメントオフィス）としての重要な活動の1つは、プロジェクト関係者（ステークホルダー）と調整してプロジェクト上の問題を解決していくことです。「調整」と一言で言っても、協力的でないメンバーや、なにかと文句をつけてくる担当者、常に威圧的な上司などと調整してプロジェクトを推進するのは、実に骨の折れる仕事です。そんなときに極めて有効な言葉が「プロジェクトの成功のために」という枕詞です。

　使い方の例を紹介しましょう。普通なら「品質が悪いので、スケジュールを延期しなければなりません」と言うところを、「プロジェクトの成功のためには品質を確保しなければなりません。そのためにはスケジュールの延期が必要です」と言うのです。

　ここで読者の中には「ちょっと待てよ。ただ単に枕詞を付けるだけでよいなら『プロジェクトの成功のために、品質が悪いので、スケジュールを延期しなければなりません』になるのでは？」と考える方もいらっしゃるかと思います。しかし、両者を比較するとニュアンスの違いを感じるはずです。「プロジェクトの成功のためには品質を確保しなければなりません。そのためにはスケジュールの延期が必要です」と言う方が、ずっと前向きなニュアンスを感じ取れるのではないでしょうか。ここがこの言葉のすごいところなのです。

普段の言葉使いがメンバーの意識をも変える

　この「プロジェクトの成功のために」という枕詞のポイントは、枕詞の最後が【ために】で終わっていることです。つまり、「～のために」の後に言葉を続けるためには「～する」や「～が必要」など何らかの自分の意思表示が文末に必要になってくるのです。

　しかも「プロジェクトの成功のために」と自分で言っている以上、文末に後ろ向きなことは言えません。その結果、自分でも知らずしらずのうちに前向きな言葉を発するようになります。話の聞き手側から見ても、「プロジェクトの成功のために」と言われれば非協力的な態度は取りにくくなります。

　もう1つ、この言葉には不思議な作用があります。「プロジェクトの成功のために」とは、プロジェクトマネジャがいつも考えていることです。この枕詞を日常的に使うようになると、その人はプロジェクトマネジャと同じ視点で物事を考えたり、判断したりする癖が付きます。

　さらに、この枕詞を流行語のようにプロジェクト内に広めたら、どうなるでしょうか。プロジェクトメンバーと関係者全員がプロジェクトマネジャと同じ視点で考えるようになり、皆が「プロジェクトの成功という同じゴールに向かっている」という最高の状態を作ることが可能なのです。その結果、各ステークホルダーや各チームにあるセクショナリズムを排除でき、プロジェクトの風通しや雰囲気も良くなります。

隠れた枕詞をあぶりだせ

　ここまで、「プロジェクトの成功のために」という枕詞を意識的に使いましょうと述べてきました。しかし、今まで皆さんがプロジェクトの中で発してきた言葉にも、何らかの“隠れた枕詞”があったと思います。例えば、冒頭の例で言うならば、次のような枕詞が隠れていた可能性があります。

◆『私の責任じゃないけど』品質が悪いので、スケジュールを延期しなければなりません。
◆『無理なスケジュールを押し付けられて』品質が悪いので、スケジュールを延期しなければなりません。

　一読して分かるように、ネガティブな枕詞が多いと思います。ほかにもよく見られる隠れた枕詞として、次のようなものがあります。

◆『余計な仕事はしたくないから』
◆『私の業務範囲とは関係ないけど』

　このようなネガティブな枕詞を「プロジェクトの成功のために」へ置き換えるだけでも、計り知れない効果が得られます。

　ただし、注意すべき点もあります。それは、この枕詞を都合よく使ってパートナーを犠牲にしないことです。極端な例ですが『プロジェクトの成功のために』パートナーの報酬を削ってもいいということにはなりませんし、パートナーに無制限の残業をしろと強要できるわけでもありません。あくまでも、パートナーとのWin-Winの関係を保ちつつ、プロジェクト全体のベクトルを「プロジェクトの成功」というゴールに合わせるために、この魔法の言葉を使ってもらいたいと願っています。

第50回「見える化」では見えない予兆をつかむ

　プロジェクトでは「見える化」が重要である。一般に、現場の状況を定量的に見るアプローチがとられているが、それだけでは危ない予兆（＝リスク）を見落としやすい。PMOは「見える化」で見えないものにも敏感になり、プロジェクトマネジャの意思決定を支援する必要がある。

渡部孝一
マネジメントソリューションズマネージャー

　プロジェクトの「見える化」が重要であることは一般に認識されており、皆さんも取り組んでいることと思います。進捗を成果物完了数で計測したり、課題未解決数を原因分類ごとに可視化したりするなど、確かに定量的な指標に基づく「見える化」が定着すると、プロジェクトの状況を把握しやすくなります。

　しかし、「見える化」した定量的な情報ばかりに注目していると、プロジェクトに潜む危険な「予兆」に気づかないことがあります。数字に頼りすぎてはいけません。

「見える化」の裏側

　定量的な情報に頼りすぎると、なぜいけないのでしょうか。例えば以下の4項目はプロジェクトマネジメントにとって重要な情報ですが、定量的に把握できるわけではありません。

■クライアントの満足度

＜クライアントが満足している場合＞
　クライアントから冗談を言われたり、会議中も笑いがあったりします。
　
＜クライアントが満足していない場合＞
　こちらの発言に対して、微妙に顔をしかめたり、目を合わせてもらえなかったりします。

■チーム間の関係

＜チーム間の関係が良好な場合＞
　会議が始まるまでの時間に雑談をしたり、昼前の会議後に誘いあって一緒に食事に行ったりします。

＜チーム間の関係が悪い場合＞
　チーム横断会議に遅刻が多かったり、会議中もお互いの口数が少なかったりします。

■プロジェクトルームの雰囲気

＜プロジェクトルームの雰囲気が良好な場合＞
　「おはようございます」「お疲れさまでした」「○○に行ってきます」などの挨拶や会話が当たり前のようにあったり、仕事中、適度な雑談があったりします。

＜プロジェクトルームの雰囲気が悪い場合＞
　挨拶や会話がなく、誰が今どこで何をしているか把握できない状態であったり、仕事中も無言で仕事していたりします。

■メンバーのモチベーション

＜モチベーションが高い場合＞
　出勤時刻が早かったり、会議でもポジティブな発言が多かったりします。

＜モチベーションが低い場合＞
　遅刻や休みが多かったり、会議でもネガティブな発言が多かったりします。

　これらは、定量化による「見える化」では決して見えてきません。いくらプロジェクトが円滑に進んでいるように見えても、これらの項目で危険な予兆を見逃すと、後々問題を引き起こしかねません。

　プロジェクトが小規模な場合やプロジェクトの初期フェーズにおいては、プロジェクトマネジャにも余裕があるでしょう。そういう場面では、プロジェクトマネジャがクライアントやメンバーと積極的にコミュニケーションをとって、予兆をつかむ機会がたくさんあります。

　危ないのは、プロジェクトが大規模な場合や、プロジェクトが遅れ始めた状況のときです。プロジェクトマネジャに余裕がなくなってくると、上記のような点に気づかなくなります。

「定量化できないもの」に注目する

　プロジェクトマネジャを支援する立場にあるPMOは、プロジェクトマネジャの目となって、プロジェクト内に起こるあらゆる「変化」を追い続ける必要があります。具体的には、日常の会議や行動の中から、次の例にあるような点に注目すべきです。

■クライアントの満足度

　＜着目点＞クライアントの顔色や相談内容

（1）クライアントから相談される回数や相談内容の変化をとらえる。
（2）こちらから提案や依頼をした際、渋い顔やしかめっ面をしていないか、微妙な表情の変化を観察する。

■チーム間の関係

　＜着目点＞会議中の「笑い」や会話の様子

（1）会議中に起こった笑いの回数や、盛り上がり具合の変化をとらえる。
（2）会議中にチーム間で目を合わせながら会話をしているかを見る。

■プロジェクトルームの雰囲気

　＜着目点＞活気とメンバー間の協力関係

（1）メールの連絡だけではなく、お互いに声掛けができているか耳を澄ます。
（2）他メンバーが不在の際、「どこに行っているのか」を知っているかどうか、尋ねてみる。

■メンバーのモチベーション

　＜着目点＞メンバーの発言内容や勤務状況

（1）メンバーのポジティブ発言とネガティブ発言の回数や内容の変化をとらえる。
（2）メンバーの遅刻の回数や、休暇の回数の変化をとらえる。

　変化をとらえるためには、上記のように、笑いの回数や相談の回数など、普段の会話や表情、行動に着目する必要があります。PMOは、自身の「目」「耳」「口」を総動員して、変化を感じとれるようにしなければなりません。

　ただし、大規模なプロジェクトなどでは、PMOとプロジェクトマネジャが協力しても、あらゆる変化をとらえることが困難な場合があります。そういうときは、「こういう行動や表情の変化をとらえよう」という内容の「見えないものチェックリスト」を作成して、チームリーダーと共有することをお薦めします。意外なことに、若手（チームリーダーなど）が抱く「なんかおかしいぞ」「なんとなく危なそうだな」といった直感が、結構、的を射ているケースがあります。

　上記のような点を踏まえ、PMOはプロジェクトに起こりうるさまざまな出来事に気を配り、プロジェクトマネジャの正しい意思決定を支援する必要があります。「見える化」で取得できる定量的な情報は既に発生した事象の結果でしかありません。正しい意思決定を行うためには、プロジェクトの成否にかかわる予兆（＝リスク）を加味すべきです。

定量的な情報の「裏」に潜むもの

　危ない予兆は「見える化」で見えてこないものがほとんどです。だからこそ、それらを事前にとらえることができれば、定量的な情報に加えて強力な意思決定の材料になるのです。

　クライアントの満足度、チーム間の関係、プロジェクトルームの雰囲気、メンバーのモチベーションなどは、重要な情報でありながら、定量的な数字では見えてきません。チーム間の関係悪化やメンバーのモチベーションが低下すると、結果的に進捗報告の遅延や課題未解決数の増加となって数字に表れますが、「何が原因か」を数字から判断するのは困難です。

　定量的な情報の「裏」にある情報に気を配る――。そういう視点がPMOには求められます。

　特にプロジェクトがひっ迫してくると、悩みや疲れ、焦りを抱えているメンバーも多くなります。期限が迫ればチームの雰囲気も悪くなります。これらはプロジェクト運営がうまくいかなくなる予兆です。

　状況の変化をいち早く察知するためには、現場にまめに足を運んで、顔を見ながらのコミュニケーションを心がける必要があります。会議でのメンバーやクライアントの発言内容に注目するなど、プロジェクト内に起こる、あらゆる変化をとらえ、問題が起こる前に適切な処置を行うことが肝要です。