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

第91回 プロジェクト管理ツールをもっと使い倒す（後編）

　前回はプロジェクト管理ツールをうまく利用するための勘所として、5つのポイントのうち、2つを見てきた。今回は残りの3つのポイントを見ていこう。

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

　プロジェクト管理ツールには、「現場の見える化」のほかに、下記の5つの導入メリットがあると前回述べました。

（1）ツールはコミュニケーションの取引コストを下げる
（2）ツールはプロジェクト内の隙間を埋める
（3）ツールはプロジェクトの課題処理速度（意思決定）を高める
（4）ツールは運用ルールを定着化させる
（5）ツールはプロジェクトマネジメントの教育を肩代わりする

　前回に引き続き（3）～（5）について個別に見ていきましょう。

課題処理速度を高めるためのポイント

　皆さんの心の中には、「意思決定はトップが行うもの」という感覚があるかもしれません。しかし、プロジェクトにおける意思決定について言えば、何もプロジェクトマネジャー（PM）だけが行うものではありません。

　各チームのリーダーや担当者も、日々業務の中でプロジェクトを進めるための意思決定をしています。これを「現場レベルの意思決定」とします。また、PM やPMOは1歩先、2歩先を見据えて、プロジェクト全体の方向性を決めるための意思決定をしています。これを「戦略レベルの意思決定」とします。

　プロジェクトをうまく回すためには、必要な課題が、必要なレベルで速やかに意思決定されていく必要があります。PMやPMOが本来の役割でない「現場レ ベルの意思決定」に忙殺されていたり、現場では何ともしがたい「戦略レベルの意思決定」をチームリーダーが抱えていたりすると、プロジェクトはいとも簡単に止まってしまいます。

　こうした事態を避けるには、ある課題が、しかるべきレイヤーで適切に処理されていることが重要になります。そこでは、プロジェクト管理ツールを利用して、「エスカレーション（またはその逆）の仕組み」と「円滑な意思決定の仕組み」を作り込むことが重要になるのです。

運用ルールを仕組みとして作り込む

　プロジェクト管理ツールの利点の1つとして、プロジェクトの運用ルールを仕組みとしてツールに組み込める点があります。いわゆるワークフローのような運用もあれば、重要項目については必ず入力しないと先へ進めない、といった入力規則のようなものもあります。

　プロジェクトマネジメントにおいては、運用ルールを人の善意に頼ると必ず失敗します。運用ルールは、性悪説で考えるのが基本です。「これをやらないと先 へ進めない」といった制約や仕組みは、プロジェクトにとって好ましくない振る舞いをするメンバーに、ルールを守らせる力を持ちます。プロジェクト管理ツールは、そのような制約を仕組みとして組み込むのに、最も適しているといえるでしょう。

プロジェクト管理ツールによるマネジメント教育

　プロジェクト管理ツールの最後の利点としては、プロジェクト管理に必要な項目や運用プロセスを、ツールを使うことで学習できる点が挙げられます。

　システム開発のプロジェクトにおいては、プロジェクトマネジメントを今まで経験したことのないユーザー側の担当者や、新卒で初めてプロジェクトにアサイ ンされた人など、様々な人が集まってきます。そうした人々にプロジェクト管理ツールという「標準」を利用してもらうことで、日々の作業の中で自然にプロジェクトマネジメントを学んでもらうことができます。

　例えば課題管理において、「期限の項目を入力必須にする」「エスカレーションレベルを項目として設ける」といった仕組みが当たり前のようにツールに組み 込まれていると思います。こうしたツールを使っていれば、課題管理が初めての人にも「必要項目、重要な項目は何か」「項目の意味は何か」を知ってもらうことができます。また、プロジェクト管理ツールを使い続けることにより、課題管理のプロセスも身をもって経験できます。このような意味において、優れたプロ ジェクト管理ツールは「優れたプロジェクトマネジメントの学習ツール」であるとも言えるのです。

　前回と今回のコラムでは、プロジェクト管理ツールを有効に使いこなすためには、どのような観点が必要かを述べてきました。プロジェクト管理ツールは「現 場の見える化」を目的として導入するのが最優先ですが、前回と今回で述べた5つのメリットを十分に享受できるよう、考慮してみてはいかがでしょうか。

第92回 プロジェクトでの正しい“騒ぎ方”

『第27回 必要なら、プロマネに逆らっても「助けて！」と叫べ』 のコラムにて、PMOはプロジェクトマネジャーの状況を見て、必要であれば上位組織に危険をエスカレーションする必要があると書いた。しかし、現実問題として上位組織の方々は、エスカレーションしたとしても、そうやすやすとは動いてくれない。今回は、どうしたら上位組織が動いてくれるのか、について考えて みたい。

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

 

　PMOの主要な役割の一つに、プロジェクト状況の「見える化」があります。見える化した結果、問題が見つかればプロジェクトマネジャーにエスカレーションします。通常は、見える化された状況を基に対応策を考え、プロジェクトマネジャーはそれを実施するための「意思決定」をします。

　ここで問題となってくるのは、プロジェクトマネジャーでは意思決定できない問題が発生した場合です。筆者の判断基準としては、プロジェクトの「前提条 件」（プロジェクト関係者の中で確実に存在する、または、実施、順守されると仮定したこと）が崩れた時を目安としています。

　なぜならば、プロジェクトはその前提に従って計画や予算が立てられ、その前提が崩れることを想定していないからです。想定外の出来事に対応するための十 分なリソースやコストが確保されていない可能性があり、その場合、プロジェクトマネジャーだけでは意思決定できなくなってしまいます。もちろん、プロジェクトリスク費用としてコストを確保している場合もありますが、前提条件が変更になるような事態は、確保した以上のコストが発生すると考えた方がいいでしょ う。

様々なルートを使って上位組織に危険を伝える

　このような場合に必要になってくるのが、PMOとしての「騒ぎ方」です。当然、最初はプロジェクトマネジャーが自分の力で何とか問題を解決しようと試みるでしょう。しかし、それに費やす時間がプロジェクトにとって命取りになる場合も出てきます。

　そこでPMOは、「プロジェクトマネジャー以外の誰がこの問題に対処できるのか？」を考えて、スピード感をもって「プロジェクト内で対処できない問題が発生したこと」を適切な上位組織の担当者にエスカレーションしなければなりません。

　その際、PMOとしては、多少大げさでも「危機感を持ってもらえる」ように騒ぐ方がよいと筆者は考えています。ポイントとしては、その上位組織の意思決定者に様々な所から「この問題は危険だ」という情報が伝わるように仕向けていくことです。そのために様々なルートや手段を使ってPMOが騒いでいく必要があります。裏を返せば、そこで「騒ぐことができない」PMOは、自らの職務を半分放棄しているといっても過言でありません。

日頃から上位組織との信頼を築く

　一つ注意する点は、PMOがいくら「危険だ」と騒いでも、上位組織の方々との信頼関係がなければ単なる「オオカミ少年」になりがちなことです。重要なのは、PMOとして上位組織と信頼関係を構築していくことです。筆者が見てきた現場で、この上位組織との信頼関係がうまくいっている所では、図1に示すような良いサイクルを回すことができます。

図1●PMOがプロジェクトの上位組織から信頼を獲得していくサイクル

[画像のクリックで拡大表示]

　ポイントは、PMOがプロジェクト内のコミュニケーションのハブとなることです。上位組織と現場のつなぎ役となることにより、現場の状況を知るために「上位組織の担当者がPMOに状況を聞きに来る」という状態を作るのです。また、上位組織の方針や考えを現場にフィードバックし、「さらに現場から新しい情報を入手して上位組織に伝える」という役割を担うのです。そうすると、上位組織にとってPMOは、情報収集源として欠かせない存在になってきます。

　このような場合においては、プロジェクトマネジャーを巻き込むのか、あえてプロジェクトマネジャーを通さずに情報を流していくのかは、慎重に選ぶべきで す。プロジェクトマネジャーの置かれた立場や状況、その組織の文化によって選ぶべき方法は異なります。もし、プロジェクトマネジャーが「自分が知らないところで話が進むのは面白くない」と感じたり、自分の保身に走ったりすれば、重要な情報がねじ曲げられ、現場を一層混乱させる可能性も出てきます。そのよう な意味において、「騒ぎ過ぎ」は控えた方がいい場合もあるでしょう。

第93回 PMOの存在価値の数値化

PMOの永遠的な命題として、「PMOの存在価値を数値化できるのか」という命題がある。よくお客様から問われる質問でもある。今回は、PMOの存在価値としての数値化の取組みについて考えてみたいと思います。

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

 

　このコラムを通して一貫して述べているPMOの仕事の一つは、「プロジェクト関係者が気持ちよく働ける環境を作ること」です。さて、ここで「気持ちよく働ける環境」とは、一体どんな環境でしょうか。それは、自分が本来やるべき（自分しかできない）作業に専念できることです。

　ただし、プロジェクトにおいては、それぞの役割を決めてチーム分けを行います。当然、各チームは割り当てられた役割を全うするために全力で作業を行うの ですが、役割を決めて分業をしている以上、それらをまとめて統括していく必要があります。また、プロジェクトのステークホルダーであるマネジメント層やユーザー側の責任者、または品質管理部門などとも協力しながらプロジェクトを進める必要があります。

　その取りまとめ役がプロジェクトマネジャー（PM）やプロジェクトリーダー（PL）なのですが、その仕事についてよく不平不満が生じています。なぜな ら、PM/PLにとって、「取りまとめ」は本来自分にしかできない仕事ではないし、取りまとめるための情報収集や報告資料の作成などに多くの時間を奪われているからです。とてもPM/PLが「気持ちよく働ける環境」とは言えません。

プロジェクトマネジャーの作業の可視化

　ではPM/PLは、本来やるべき作業にどのくらいの時間を使えているのでしょうか。そして、それらはPMOが肩代わりできるものでしょうか。

　図1を見てください。この図は、PM/PLが「本来自分がやるべき作業（自分しかできない作業）」にどれだけ集中できているかを可視化するチェックシートです。皆さんもこの表を使って、1カ月にどんな作業をどのくらいの割合でしているか、可視化してみてください。

図1●1カ月の作業の割合を可視化してみよう

PM/PLの忙しさの原因は何か？

　図2は、あるプロジェクトにおけるPMの1カ月の作業内容を示した例です。上の2つの項目（プロジェクトの推進に必要な意思決定活動、 PM/PLにしかできない根回し）は本来PM/PLが実施すべき作業です。その他の項目は、PMOのようなスタッフ組織が代替可能な作業です（図の区分け は業種や企業文化、プロジェクトによって異なってくると思いますので、現状に合わせて見直して頂くとよいでしょう）。

図2●可視化した結果から見えること

[画像のクリックで拡大表示]

　このように可視化することで、プロジェクトマネジメントの現状が見えてきます。案外、自分が本来やらなければならない作業に十分な時間をかけられていないことに驚くのではないでしょうか。

　プロジェクトを進めるための意思決定について、PMが情報を集めるところからやっていると、決定すべき項目が多過ぎて意思決定が追いつかなくなります。結果的にプロジェクトの活動が停滞してしまう可能性が高くなります。

実は多い「PMOが肩代わりできる作業」

　そこでPMOが、PM/PLの仕事の一部を代行してみたらどうなるでしょうか。意思決定のためのインプットを整理し、報告資料を作成し、PM/PLに代 わって関係者間の認識合わせや根回しをしていくことにより、PM/PLが本来の自分しかできない作業に集中できる環境を作っていけます。

　もっと言えば、図に書いていある「プロジェクトの推進に必要な意思決定活動」とは、本来はプロジェクトの「先の先」を考えて未来の計画書を詳細化し、リ スクを先回りして潰していくのが理想の姿です。決して、今の問題に対応できていることだけが「プロジェクトの推進に必要な意思決定活動」ではありません。 PM/PLがそのような理想に少しでも近づくために、PMOという組織をうまく活用していく必要があるのです。

PMOの価値の数値化

　また、このような図を使うことによって、PMOの価値を数値化してみることも可能となります。図2の各業務の割合に、1カ月のプロジェクトに費やした時間を掛けてみると図3のようになります。ここから何が読み取れるでしょうか。

図3●PMOが入ることにより、PM/PLの作業効率を向上させる

[画像のクリックで拡大表示]

　プロジェクトに費やした1カ月の総時間を160時間としてみましょう。すると、本来PM/PLがやるべきであった作業に、わずか48時間しか取り組めな かったことになります。残りの112時間が、とても長く効率の悪いものに見えると思います。PMとしての作業効率は30％程度ということです。

　ここでPMOが入って、PM/PLの「本来の仕事ではない部分」を肩代わりすれば、PMとしての作業効率を100％（160時間）に近づけることができるようになります。その差分がPMOの価値と見なすことができるでしょう。

　今回、PMOの価値を「PM/PLの作業を代行する」という観点で数値化してみましたが、PMOの仕事はそれだけではありません。PM/PLやチームメンバーの相談相手であったり、プロジェクトのすき間に落ちている問題に対処したり（関連記事）と、様々な作業を実施します。これらの点も踏まえれば、プロジェクトにPMOを入れる意味がよく分かるのではないでしょうか。

第94回 「標準化」の「標準化」

『第76回 標準化が定着しない理由』 にて、プロジェクトにおける標準化のメリットやデメリットについて考えた。しかし、「標準化」と簡単に言うものの、「標準化」自体をどのような観点で「標準化」していくかについては、それほど深く気にしていないのではないか。今回は、プロジェクトマネジメントの「標準化」について、少し深く考えてみたい。

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

 

　『第76回 標準化が定着しない理由』では、標準化のデメリットとして以下の5つの点を挙げました。

• 標準が絶対的なバイブルとなり、柔軟性がなくなる
• 「標準に従っていればよい」という心理を生み、改善意欲が失われる
• 標準どおりに実施した結果、現場の生産性が下がる
• 利用も何もしない無駄な指標を計測し続ける
• プロジェクト固有の習慣や文化、言葉などを標準に合わせるための“翻訳作業”が発生する

　誤解を恐れずに上記の5つを要約すると、「不確実な例外処理（リスク）が発生した場合において、標準化したがゆえに柔軟な対応ができない」ということが一番のデメリットになると思います。

　では、リスクに弱いという「標準化」のデメリットに、うまく対処する方法はないのでしょうか。一般的に、システム開発における「標準化」とは、下記の3つの要素に分解することができます。

（1）作業をするためのインプット（チーム間インタフェース）の標準化
（2）作業自体のプロセス（手順）の標準化
（3）作業結果のアウトプット（成果物）の標準化

　システム開発の標準化としては、上記の（1）（2）（3）のすべてを標準化しようと試みます。そのため、「インプット→プロセス→アウトプット」という 一連の流れのすべてにおいて「あそび」がなくなり、ほんの少しの例外（リスク）が発生した時点で身動きが取れなくなってしまいやすいのです。

標準化に必要な「あそび」

　図1は、標準化において注力すべき観点についてまとめたものです。成熟度が高いプロジェクトとそうでないプロジェクトでは、強化すべきポイントが異なる点に注目してください。

図1●標準化において注力すべきポイント

[画像のクリックで拡大表示]

　この図から分かるとおり、標準化において不確実性に対応するために一番「あそび」を持たせやすい部分は「プロセス（手順）」になります。例えば課題管理 やリスク管理などの協力・改善を推進するための最低限のルールを中心に標準化することで、運用手順そのものには柔軟性を持たせ、不確実性（リスク）に対する対応力を高めることができます。

　その逆に、他のチームやプロジェクトへのインプットとなるインタフェース、成果物であるアウトプットに「あそび」を持たせるとどうなるでしょうか。各 チームの成果を取りまとめたり受け渡したりしにくくなり、標準化のメリットを阻害してしまいます。どんな場合にも、インプットやアウトプットに「あそび」を持たせるべきではありません。

「標準化」は、プロジェクト成熟度の応じて変わるものか？

　ここで一つ注意点があります。それは、プロジェクトメンバーの成熟度に合わせて標準化を進める必要があるという点です。

　同じようなプロジェクトを何回か経験して、仕事の進め方や成果物についての認識が共有化されているメンバーが多いプロジェクトでは、前述したようにできるだけ不確実性に強い“プロセス中心の”標準化の仕組みを作っていく必要があります。

　一方、プロジェクトメンバーの成熟度が低い場合においては、プロセス（手順）の「あそび」を少なくする方がいいと思います。各担当者の勝手な判断や自由 をある程度抑制し、プロセスをしっかりと標準化することで、一定の品質を確保しつつ生産性の向上を目指すべきでしょう。また、作業手順であるプロセスをがっちり固めてしまうことによって、（他チームへの）インプットやアウトプットの標準化も同時に行うことができます。

　とはいえ、前述したように、プロセスの標準化は不確実性（リスク）に弱い面があります。そこをフォローするために、プロジェクトマネジャーやPMOはリスク管理の徹底など不確実性に対応するための仕組みをしっかりと導入していく必要があります。

　標準は「一度決めたら不変なもの」ではありません。プロジェクトの成熟度に応じて、変えてよい部分と変えてはいけない部分をうまく使い分けて運用していくべきです。それが標準化をより効率的に使いこなすポイントになります。

第95回 そのプロジェクトに「意志」はあるか

プロジェクトマネジメントがうまくいっている現場というのは、必ずそこに「統一された強い“意志”」がある。その“意志”がプロジェクトメンバー全員に伝わっているプロジェクトでは、問題が発生してもうまく処理できる。長年、その“意志”とは何かについて考えてきた。今回はそれについて述べていきた い。反対意見もあるだろうが、それも含めて皆さんのプロジェクトを見直すきっかけになればと思う。

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

 

　現在、多くのプロジェクトで、程度の差はあれ進捗管理や課題管理を行っているはずです。大規模なプロジェクトであれば、社内標準のプロジェクト管理プロセスやPMBOKなど、管理標準を利用してプロジェクト管理を実施しようと考えるでしょう。

　ただし、社内にある標準やベストプラクティスをうまく利用し、どんなに素晴らしいプロジェクトマネジメント・システムを構築したとしても、経験上、そこ に“意志”がなければプロジェクトの失敗確率は高くなります。“意志”があっても、それがメンバーに浸透していないなら、やはり失敗する確率が高くなります。つまり、プロジェクトの成功には、「意志統一」が不可欠なのです。

　ここで言う「プロジェクトマネジメントにおける“意志”」について説明しましょう。私が考える“意志”の統一とは、以下の4つの“意志”をメンバー間で腹落ちさせ、共有化することです（図）。

（1）プロジェクトの目的
（2）QCD（品質、コスト、納期）の優先順位
（3）重要なリスク
（4）制約条件

図●プロジェクトマネジメントが機能するにはプロジェクトの意志が重要

[画像のクリックで拡大表示]

ベストプラクティスだけではうまくいかない

　皆さんも経験があると思いますが、PMBOKのようなプロジェクトマネジメントのベストプラクティスをそのままプロジェクトに適用しても、プロジェクトがうまくいくとは限りません。

　例えばPMBOKは、9つのエリアのプロジェクト管理プロセスの集合体です。各プロジェクト管理プロセスはプロジェクトマネジメントの構成要素であり、それぞれがお互いに、方針や手順、ルール、仕組みといった形で結び付けられます。もちろん、各マネジメントプロセスを完全に結びつけることはできません。 そこにPMOなどが介在することによって、プロセス間の断絶が発生しないようにすることが大切だと前回のコラムでも述べました。

　しかし、いくら完璧な断絶のないプロジェクト管理プロセスを作ったとしても、そこには、前述した”意志”を入れていかなければならないと考えています。

“意志”がもたらす効果

　プロジェクトマネジメントの視点から考えて、先に述べた4つの“意志”がもたらす効果は非常に大きいといえます。目的や優先順位、制約条件、大きなリス クを明確にしておけば、その“意志”を反映し、“意志”に沿った成果を出しやすくするプロジェクト管理ルールや手順が作り込まれていきます。そうなれば、 各プロセスが一貫性をもって動くようになります。

　例えば、先ほどの4つの“意志”として、下記のように意思統一されていたとしましょう。

目的：他社よりも先駆けて新製品を出し、この分野でシェアXX％を取る
優先順位：納期が最優先
リスク：他社が先に同様の新製品を出すこと
制約条件：この新製品のためには、A社の技術が必要不可欠

　この4つの“意志”は、プロジェクト管理プロセスやルール、手順にどのような影響を及ぼすのでしょうか。例えば、このように“意思”が統一されているプ ロジェクトにおいての進捗管理は、「どうすれば早く開発できるか」、言い換えれば「多少のお金をかけても、最低限の品質を確保した上でどれだけ早く問題を解決できるか」「遅れた場合には、いかに早く当初のスケジュールに追い付けるか」に皆の関心を集めることができるでしょう。

　また、品質管理の面では、最低限の品質を定義した上で過剰な品質を避け、A社の技術の確認に重点を置き、品質管理部門などもその“意志”に準じた検査を行うと思います。他のプロジェクト管理プロセスも同様です。

　このように、プロジェクト管理プロセスやルール、手順はベストプラクティスを基本にしながらも、そこにプロジェクトの“意志”を入れることで、より生きたものにすることができるのです。リスクについては『第8回 “リスク感度”を合わせ、問題発生時に一丸となる』でも詳しく述べていますので参考にしてください。

プロジェクトの“意志”の影響

　“意志”の統一がもたらす効果をもう少し具体的に見ていきましょう。“意志”はメンバーの振る舞いに以下のような影響を与えます。

（a）プロジェクトとしての“意志”は錦の御旗となり、メンバーは何を判断基準にすればよいか分かっているので、指示待ちがなくなる。
（b）プロジェクトの“意志”がプロジェクトメンバー全員にはっきり理解されることにより、プロジェクトのプロセス、方針、ルール、手順がシステムとしてぶれない一貫性を持つ。
（c）プロジェクトで問題が発生した場合、“意志”が問題解決の全体の指針となり、最小限の負荷で問題解決を図れる。

　別の言い方をすれば、プロジェクトメンバーが“意志”を理解し、“意志”に基づいたマネジメントプロセス（やプロセス間のつながり）を把握（可視化）できていれば、思いつきや場当たり的な決定をする可能性が小さくなるということです。勘や経験や度胸に基づく意思決定が入り込む余地も小さくなるはずです。

　プロジェクトの現場レベルでも、プロジェクトメンバーが多かれ少なかれ設計書の確定などにおいて意思決定をする必要があります。“意志”がない、または 薄いプロジェクトでは、意思決定や行動のための判断基準が存在せず、メンバーやチームの主観が混じり、プロジェクト全体としての一貫性がなくなってしまう危険性があります。問題に気付いた時、立て直そうとしても「もう手遅れ」というケースはよく起こります。

　プロジェクトの責任者やプロジェクトマネジャー、PMOは、ことあるごとに“意志”を唱え、プロジェクトに“意志”を吹き込むことが重要です。印象的なキャッチコピーを考えて、プロジェクトのスローガンとして掲げるのもいいでしょう。

第96回 グローバルPMOは「森を見て木も見る」官房長官になろう

　多拠点、多言語、多国籍のグローバルプロジェクトでは、国内プロジェクト以上にコミュニケーションに時間がかかり、早め早めの意思決定が求められ る。日本では聞き慣れぬ横文字も頻繁に登場する。「あうんの呼吸」に慣れたプロジェクトマネジャーがトップダウンで指示を出すと、情報の少ない海外拠点にいるステークホルダーは迷子になり、後工程で火が噴くことも少なくない。今回は、そのようなグローバル環境下でのPMO（グローバルPMO）が持つべきマ インドセットを考えてみる。

今仁 武臣
マネジメントソリューションズ PMP

 

　グローバルプロジェクトとは一般的にどのようなものを指すでしょうか。例えば、ワールドワイドの営業拠点への新事業展開、海外サプライヤーとのシステム連携、オフショア開発プロジェクト、海外企業の買収に伴う業務統合などが挙げられるでしょう。

　それらのグローバルプロジェクトに携わった筆者の経験では、PMOが最初に気にすべき視点は2つあると思います。1つは複雑性 （Complexity）、もう一つは変動性（Volatility）です。グローバルプロジェクトの複雑性としては、拠点、言語、時差、文化、組織など 多くの要素が関連します。また、日本だけではなく、海外拠点のビジネス環境の変化により、プロジェクトのスコープやステークホルダーの期待が頻繁に変化する場合（変動性）があります。

　複雑性と変動性の双方が高い場合、プロジェクトのリスクレベルはかなり高まり、PMOの活動の軸も多岐にわたります。また、英語を標準言語としたコミュニケーション品質も、より高いレベルが求められます。

　以下では、ワールドワイドの営業拠点に対する新事業展開において、日本をベースとするPMO（グローバルPMO）が新業務のカットオーバー時期を欧州、 米国、アジア、中東など複数地域のプロジェクトリーダーに伝え、課題・ToDoを推進する場面を想定しながら、グローバルPMOのコミュニケーション上の注意点を考えてみましょう。

グローバルプロジェクトでは「自己主張」「丁重」が肝

「You are talking about a final decision as a projectmanagement？（あなたの言っていることはプロジェクトとしての最終見解か？）」

　海外拠点展開プロジェクトの定例テレビ会議で、ビジネス側のリーダーにこう尋ねられたことがあります。国内プロジェクトでは、「いったん持ち帰ります」 とか「私の権限では…」と結論を先延ばしすることがあるかもしれません。しかし、グローバルプロジェクトでは、ProjectManagementと名の付くPMOがそのような会話を連発すると、海外のステークホルダーの信頼を失ってしまう場合があります。「Complexity」や「Volatility」が高い中、PMOのからの情報や伝達事項が本物か、信頼性(Credibility)を確かめている場合もあるのです。

　その場合、2つの方法があります。1つはアジェンダや想定問答をしっかり準備しておき、プロジェクトマネジャーや関係者と話す内容を綿密に確認し、正式にはっきり伝えることです。国境を超えた相手の立場に立ち、論理的に矛盾のない伝達をする必要があります。

　2つめの方法は、「XXではそうだが、YYについては至急確認する」など議事録に記録し、さらにはToDoとして追跡して、早めに正式な回答をすることです。グローバルプロジェクトでは、1つのミスが各国に伝搬し、修正するには時間とコストがかかります。責任の持てない回答をPMOはすべきではありませ ん。

　どちらの場合でも、筆者は2つのことに気を付けています。まず、自己主張（assertive）をしっかりすること。主張すべきことは具体的な理由とともに主張し、意見が対立した場合はきちんと議論する。

もう1つは、丁重（polite）であること。一緒にプロジェクトを成功させる、ステークホルダーやメンバーを尊敬し、間違った情報で時間を無駄にしないよう、「分からないことは分からない」と丁寧な英語で正直に伝えます。万が一間違った情報が各国に伝わった場合も、修正は謝罪とともに迅速に行い、 時にはメッセージングツールや、時差に注意しながら電話やショートメッセージ（SMS）でもフォローすることがあります。

　私は英国留学時にコミュニケーションの授業で「Polite Assertive」という言葉を講師からよく聞きました。もちろん、地域によってはもっとフレンドリーに接した方がいい場合もあります。一方、重要な局面では、「Polite Assertive」を活用したリアルタイムかつ高品質なマネジメントを通じ、複雑性と変動性があるプロジェクトやプログラムをコミュニケーションの面で「締める」必要があります。その場合、PMOはプロジェクトマネジャーの参謀とスポークスマンの両方の役割を持つ、いわゆる「官房長官」的役割を担っているのです。

グローバルPMOは「森を見て木を見る」

「As I said many times,…（何回も言いましたが）」

　「Polite Assertive」はメッセージを発信する側のマインドセットとして重要ですが、受信側が理解し、プロジェクトに必要なタスクを想定通りに実施できるかは別問題です。いつの間にか誤解されて伝わっている場合もあります。特に、前述した変動性の高いプロジェクトでは早めに誤解を修正する必要があります。

　先ほどの前置きの「As I said many times…」は、GlobalPMOとしてはあまり使わない方がいいでしょう。筆者は、1回では伝わらない、理解してくれない、忘れるという前提で、決定事項やお願い事項を何回も伝えることを心がけています。それは、メンバーが海を越え、各国に散らばっている場合は特に重要です。

　「一度伝えて、議事録にも書いてあるし、何回も言わなくて言いだろう」とか、「会議でYesと言っているし、少しそっとしておこう」といった考え方は、グローバルプロジェクトでは禁物です。「迷ったらもう一度言う」ことを心がけましょう。

　最近のグローバルプロジェクトで、欧米のシステム設計リーダーと協業する機会がありました。彼らは、重要なことは何度もメンバー（インド、シンガポー ル、南米、日本）に伝えていました。メッセージの受信者である各国のリーダーの立場に中立的かつ客観的でありつつ、コミュニケーション品質を上げていくことは、多様な人種との協業が一般的な国では当たり前なのかもしれません。

　『第38回「木を見て森を見る」マネジメント』 で、プロジェクトマネジャーやPMOにとって、一人ひとりのメンバーの状況とプロジェクトの大局的な状況を見る「木を見て森を見る」マネジメントを紹介し ました。グローバルPMOでは、逆に多国籍、多拠点のメンバーの状況にも気を配る「森を見て木を見る」という視点を通じ、高い変動性リスクに備えることが重要です。

　「サンパウロにいるプロジェクトリーダーは、マスタースケジュールの今回の変更についてちょっと誤解しているかも。よーし、挨拶がてら電話してみよう。えーっと、時差は…」

　グローバルプロジェクトでは、官房長官的PMOとして「森を見て木を見」ながら、多様なステークホルダーとの多国籍コミュニケーションを楽しんでみてはいかがでしょう。次回は、そのようなマインドセットを持つべきグローバルPMOの重要な活動として、多様な価値観への対応とステークホルダー管理の勘所を紹介します。

第97回 グローバルプロジェクトでの文化や価値観の違いの“楽しみ方”

　グローバルプロジェクトでは、海外メンバーの価値観との違いによりストレスをためてしまうことがしばしばあり、ほうっておくと多様で深刻なリスク に直面することがある。プロジェクトの初期フェーズで、グローバルPMOがステークホルダー管理プロセスを通じた「巻き込み」と定期的なコミュニケーショ ンの場を用意し、海外メンバーとリスクを共有しながら「一緒に」対処できる枠組みを作っていくことが肝と言える。

今仁 武臣
マネジメントソリューションズ PMP

 

　グローバルプロジェクトでは、国内プロジェクトではあまりみられない様々な文化や価値観の違いに遭遇します。例えば、新興国メンバーのプロジェクトマネジメントに関する理解不足やITリテラシーの相違により、以下のような場面が考えられます。

グローバルPMO：Can you update thestatus of the test？（テストの実施状況をアップデートしてもらえますか？）

海外拠点のメンバー：It's OK, OK. No problem.（OK、OK、問題ありませんよ）

　これでは、正確な進捗がわかりません。海外拠点への新業務・システム展開でコロケーションができない場合は、なおさら心配になります。

　言葉や単語の理解が違う、いわゆる語彙の違いに基づくリスクもあります。

海外拠点のメンバー：What do you mean by“Process”？ “Manufacturing process”？（「プロセス」とはどのような意味ですか。「製造過程」のことですか？）

　日本側で当たり前に使われる言葉の意味が海外でもそのまま通用するとは限りません。放置していると、丁寧に説明したと思っていた要求書や仕様書の内容の 誤解が後工程まで解消されず、深刻な事態となります。例えば、ユーザー受け入れテスト（UAT）でそれらが判明した場合、大きな手戻り作業につながること があります。

日本とビジネス状況が違うリスク

グローバルPMO：As described in ourmaster plan, the system-down for the go-live will be scheduled in the beginningof November.（マスタープランにある通り、本稼働に伴うシステムダウンは11月初旬を予定しています）

海外拠点のマネジャー：Why do we need the system migration and shutdown before Christmas time？ We need an approval fromthe CEO.（なぜクリスマス時期の前にシャットダウンしてシステム移行をする必要があるのですか？ それにはCEOの承認が必要です）

　日本と違い、クリスマス商戦が数カ月前始まる地域があり、その期間の業務上の変更は経営的にNGの場合があります。全世界を対象としたグローバルプロジェクトでは、例えば中国の春節も考慮する必要があるかもしれません。そのような日本にはない商習慣とプロジェクトの重要マイルストーンとの関連を見逃す と、プロジェクトの後半にスケジュール変更が発生し、全世界の拠点の業務、さらには商品売り上げなどの経営指標に影響を及ぼす場合があります。

　仕事の価値観や雇用状況など、文化の違いがプロジェクトに大きな影響を与えることがあります。

グローバルPMO：I would like to talkwith the PMO person in your area.（そちらにいるPMO担当者と話をしたいのですが）

海外拠点のマネジャー：Oh, he already left this company.（いやぁ、彼はもう会社を辞めてしまいました）

　海外では人の異動や入退社が激しい地域があり、せっかくの情報共有が台無しになってしまいます。

グローバルプロジェクトのリスクのカテゴリー

　「PMOを生かす」の第41回では「オフショア開発では双方にPMOを置く」必要性を説明しました。上記のような違いが日本と海外拠点のPMO間にあると、メンバーやマネジメントに伝わるにつれて情報不足や誤解が増幅し、グローバルプロジェクトのリスクレベルはさらに高まります。

　一般的には、グローバルプロジェクトのリスクのカテゴリーは「組織的（Organizational）」「技術的（Technical）」「外的（External）」の3つに分類されます。

　「組織的」リスクには、前述した、拠点が違うことによる文化や商習慣の違いに基づくリスクが含まれます。「技術的」リスクには、プロジェクトマネジメン ト・システムやコミュニケーションツールの不備が含まれます。「外的」リスクには、法規制や通貨の違い、治安などのプロジェクトマネジャー/PMOが単独 で対処できない外的要因による懸案事項が含まれます。

　グローバルプロジェクトでは、上記の「組織的」リスクを、できるだけプロジェクトライフサイクルの初期で認識し、対策を立て、実行しておくことが重要で す。例えば、システムの受け入れテスト中に、文化による品質の違いが表面化すると、当初のゴール、計画を満たすためのリカバリーはかなり困難になるからです。リスクテンプレート（過去の失敗事例と対策）を用意しておき、グローバルプロジェクトの初期フェーズにおけるチェックリストとするのも有効でしょう。

リスクに一緒に取り組む仲間作り

　前回述 べた「森を見て木を見る官房長官的PMO」のように、グローバルプロジェクトは複雑性（Complexity）と変動性（Volatility）に十分注 意する必要があります。特に複数の国と地域が関わり規模が大きいプロジェクトでは、日本人のプロジェクトマネジャーが1人で対応するのはかなり難しいで しょう。筆者の経験では、多拠点・多国籍のメンバーとともに仮想的なチームを作り、上記リスクの認識を合わせながら一丸となって取り組むことが有効です。

　では、そのようなチームはどのように作っていくのでしょうか。グローバルプロジェクトの初期段階で有効な取り組みの1つは、ステークホルダー管理プロセスを通じた「巻き込み」です。このプロセスを通じ、プロジェクトに関わる「人」と必要な「コミュニケーション手法」を定義、実行していきます。PMI（プ ロジェクトマネジメント協会）が出版している「プログラムマネジメント標準（第2版）」によると、ステークホルダー管理は4つのプロセスから構成されま す。

（1）ステークホルダー管理のプラニング
（2）ステークホルダー認識
（3）ステークホルダー関与（Engagement）
（4）期待値のマネジメント

　上記（2）を通じ、利害関係者がプロジェクトに対してどのような興味や心配を持っているかを初期仮説としてまとめ、主要ステークホルダーとその後のプロセスの優先順位をプロジェクトマネジャーと協議し、管理計画にまとめていきます。

　グローバルプロジェクトでは上記（3）が肝になってくるはずです。「Engagement」という単語から結婚指輪（Engagement ring）が思い浮かべそうですが、結婚という意味ではありません。外務省などの国際関連機関は「持続的関与」と訳しています。定例ミーティングやリスクワークショップを通じ定期的に関わる場（セッション）を用意し、プロジェクトのゴールや狙いを明確に説明し、議論することで、主要ステークホルダーを巻き 込んでいきます。また、そのような会議やメールでの会話を通じ、海外拠点側のPMO的なポジションのメンバーも決まってくることがあります。

グローバルPMOとしては、彼ら彼女らとの信頼関係を大事にしましょう。注意点は、一方的にならないようにすることです。プロジェクトオーナーやマネジャーの意向を正確に伝えた上で、プロジェクト検証やスコープ定義書を通じ質疑応答を「定期的」に実施するべきです。質問が全くないということは、無関 心かまだ巻き込めていない可能性が高いです。何でも言い合える双方向のコミュニケーションとそのマネジメントが、一緒にリスクに対応する「仲間」作りをするためのキーポイントといえます。

　1回目の関与を通じ、前述のステークホルダーの興味や心配に関する初期仮説を検証します。プロジェクトのゴールとステークホルダーの期待にギャップがあれば、上記（4）の期待値マネジメントプロセスを通じて、そのギャップを埋めていきます。上記（2）～（4）を定期的に回すことでコミュニケーション密度 が高まり、変動性リスクの顕在化を早めに検知することもできます。

　1～2サイクル目の上記（3）のEngagementセッション後には、海外拠点側のPMO的担当者との信頼関係が生まれてくるはずです。全世界の拠点 にいる彼ら彼女らが本社側に訪問するときは積極的に会いに行き、対面のミーティングを持ちましょう。何でも話せる「親友」として、リスクに一緒に対処する仲になっているのが望ましい姿です。

仲間から“一生の友”へ

It has been our pleasure as well working with you, andwould like to thank you for your support and contribution to date. Please docontact us when you visit this city to have a drink！（これまであなたと一緒に仕事ができてうれしいかったです。これまでのご支援と貢献に感謝します。こちらにお越しの際はご連絡下さい。一杯やりましょう！）

　これは、インド、オーストラリア、ドバイなどを担当していたシンガポール拠点のPMO担当からのメールの一部です。グローバルプロジェクトでは、言語の壁や文化の違いによる誤解など、いろいろなストレスの種があります。それらを「一緒に」乗り越え、できれば「楽しむ」ことで、PMO担当者の間には一種の絆のようなものが生まれます。旅行で海外拠点近くを訪ねたときは、ホームパーティーなどに招待され、家族ぐるみの付き合いが始まることも楽しみの一つかも しれません。

　近年、日本企業の海外進出は増加の一途をたどっており、今後さらに複雑で変動性のあるグローバルプロジェクトが増える可能性が高いでしょう。そのような プロジェクトの現場では、ステークホルダー管理プロセスとリスク対策を通じ、海を越えた一生の友ができるかもしれません。グローバルPMOの活動を通じ、 多くの日本人がグローバルプロジェクトを「楽しみ」、またプロジェクトマネジャーを担いたい若い人材が増えて、日本のプロジェクトマネジメントが元気になることを願ってやみません。