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

最近話題のPMO（プロジェクトマネジメントオフィス）とは、一体どんな役割を果たすべき組織なのか。この点を見失うと、あまりに多くの作業に忙殺され、PMOは簡単に機能不全に陥ってしまうだろう。本連載は、管理プロセスの導入、スタッフィング、管理工数の扱いといったPMOの実務に関する 知見を紹介していく。

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

　PMOというと、「プロジェクトマネジメントオフィス」または「プログラムマネジメントオフィス」を指します。プロジェクトとはルーティンワークではなく、目的と期限がある一つの仕事を意味し、複数のチームが集まって一つのプロジェクトを構成します。いずれにせよ、PMOという言葉がしばしば使われるようになってきたものの、一体何をすればいいかとなると、なかなか答えが出せません。

　本連載は、管理プロセスの導入、スタッフィング、管理工数の扱いといったPMOの実務に関する知見をお伝えしていくものですが、まず最初に、PMOの役割を考えてみたいと思います。以下では、PMOをプロジェクトマネジメントオフィスの略語として使います。

庶務的な仕事にばかり手をかけていられない

　PMOの仕事として、事務的なものがあります。とりわけプロジェクトの開始直後は、そうした仕事が多く、あえてPMOと呼ばず、事務局と言っている場合 もあります。事務的な仕事といっても幅広く、プロジェクトメンバーの入出管理やセキュリティーカードの発行手続き、パソコンの手配といった庶務的な仕事から、予算の立案やリソース配分の決定、体制図の作成、役割分担の調整などプロジェクトの目的や全体像を理解しなくてはこなせない仕事まであります。

　以上の仕事をなんとかこなし、プロジェクトの実行段階に入ると、今度は進捗の把握や課題の取りまとめ、上位管理者向けのレポート作成、場合によってはリスク検討会議のファシリテーションまで行ったりします。どれだけの人がこれほど幅広いスキルを持ち、PMOの仕事をこなしていけるのでしょうか。PMOに 配属されたスタッフの方々は、「自分はどのようにプロジェクトに貢献すればいいのか」「どうすればPMOのパフォーマンスを上げることができるのか」と苦 慮されていることが多いと思います。

　PMOに配属されるメンバーの人数と使える時間は有限ですから、数多いPMOの仕事に優先順位を付けて、社外に委託できるものは委託する必要があります。例えば、入出管理やセキュリティーカードの発行、パソコン手配などの庶務的な仕事は、派遣社員の方にお願いし、プロジェクトに新規メンバーが入るたび にオリエンテーションをしてもらったりできるでしょう。

　では、会議のファシリテーション、つまり会議を招集し、会議室の予約を取り、必要な資料を取りまとめてコピーを作成するといった準備をするスタッフはどうなのでしょう。ここでも仕事の重要度と難易度を吟味する必要があります。定例の進捗会議など、会議の目的や出席者がはっきりしており、所定の資料を用意 するだけでよい場合は、それこそ庶務的な仕事になるでしょう。といっても出席者が多い場合、資料のコピーだけでも大変です。

会議によっては、高いファシリテーション・スキルが必要

　定例とはいえ、プロジェクトメンバーが50人以上いる規模の進捗会議になると、司会進行も議事録作成も結構大変です。議事録の執筆、レビュー、出席者へ の確認メール、プロジェクト内での共有メールなどを含めると、議事録関連だけでも予想以上に作業時間が取られることが多いものです。これは庶務的な仕事と言えません。

　私の経験によると、メンバー数が50を超えるプロジェクトでは定例会議へ向けた準備やその後の対応に1日以上の工数を使います。この工数を、通常は PMOのスタッフや派遣社員で分担するわけですが、慣れてくると、会議中は司会進行をやりつつ、プロジェクタで資料を映写し、並行してパソコンに議事録を打ち込む、といった作業を一人でこなすことができます。とはいえ、議論を聞きながら議事録を取りつつ、時間配分も見ているので、かなりの集中力を要します し、あまりお勧めできません。といって、そのような会議のファシリテーションを月単価何100万円もするコンサルタントを雇ってやらせているプロジェクト をしばしば見ますが、コストパフォーマンス的にいかがなものでしょうか？

　プロジェクトのステークホルダーや、プロジェクトマネジャが出席するような会議のファシリテーションをするには、さらに高いスキルが求められます。チームリーダーをどこまで呼ぶ必要があるのか、さらにチームメンバーまで呼ぶ必要があるのか否か、といったことは、会議の目的や具体的な内容、プロジェクトの 状況を理解していないと判断できないからです。業務要件の検討会やプロジェクトスコープに関わる検討会議は特にそうです。

　PMOは庶務的な仕事から高度な仕事まで包含しているわけですが、あくまでも縁の下の力持ちであり、黒子だと思います。ただし、黒子ゆえにそのパフォーマンスを見せにくいという課題があります。会議のファシリテーションのようにやたらと時間を食うわりに、そのことが案外理解されません。

PMOが明確にすべきもの

　実際のプロジェクトをこなしていくチームには、いずれも明確な成果物があります。情報システムの開発であれば、業務フロー図や機能設計書、コンピュータープログラムといった具合です。これに対し、PMOの場合、成果物といっても、管理用のそれですから、あってもなくても良いように思われることもしばしばです。プロジェクトを始める前に、目的とやり方を明記した「プロジェクト憲章」を作りましょう、と物の本には書いてあります。プロジェクト憲章は、 PMOの重要な成果物と言うこともできますが、多くのプロジェクトで作成されていません。

　しかし、私は、明確な成果物を提示し、しかもPMOのパフォーマンスをはっきり示す仕事があると考えています。それは、プロジェクト全体の状況を可視化 し、プロジェクトマネジメント上の意思決定を支援することです。進捗定例会議のファシリテーションも可視化の一つです。進捗状況を目に見える形にして、プロジェクトメンバーと共有し、課題を洗い出し、会議を進行させ、プロジェクトマネジャの意思決定に貢献する。これこそが最も重要なPMOの役目でしょう。そのための具体策については次回以降述べていきます。

　さらに「会議体を整理する」こともPMOのパフォーマンスと言えます。様々な会議のコミュニケーションプロセスを明確にし、それぞれの会議の目的、出席 メンバーの条件をまとめ、整理した結果に基づき、複数の会議を一つにまとめたり、逆に新しいメンバーの会議を新設したりするのです。

　基本方針が不明確なプロジェクトではやたらと会議が多く開催され、時間ばかりとられることが多いものです。会議のための会議もあれば、現場が勝手に開いているプロジェクトから見ると非公式な会議も発生します。中には、立ち話程度の話し合いにもかかわらずプロジェクトの意思決定に大きな影響を与えるものも 出てきます。

　もちろん公式の会議だけでプロジェクト全体を調整できる訳ではありませんし、いわゆるタバコ部屋の意思決定もあるかと思います。それでも、プロジェクトを推進していく上で、公式な会議は何の目的で開かれるのか、会議結果のフィードバックはどのように行うのか、といった点をプロジェクトメンバー全員が理解 していないと無駄な会議がどんどん増えていきます。会議の整理は、PMOが切り込む重要な領域です。次回は、プロジェクトの可視化に必要な管理プロセスの 導入について考えます。

第2回 「何のために」を忘れると「管理のための管理」に

過去の成功プロジェクトで使われた管理指標や管理シートを、自プロジェクトに合うかどうかも考えず、そのまま流用するプロジェクトが多い。こ ういう場合、PMOは得てして単なる“管理屋”となりやすく、所定の管理シートに情報が漏れなく記入されているかどうかだけを気にするようになる。

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

　PMOの重要な役割の一つに、様々なマネジメントスキームの導入支援があります。進捗管理、課題管理、リスク管理、変更管理、品質管理、予算管理といった仕組みを、プロジェクトの中にうまく導入することです。マネジメントを「管理」と訳してしまうとニュアンスが変わってしまいますが、通例になって いるので以下では「××管理」と表記します。

　管理スキームは、プロジェクトの状況を把握するために必須です。PMOがそう説くと、メンバーの間で管理そのものは必要だと言う理解はされるのですが、ではそのスキームをプロジェクト全員に周知徹底しようとすると、骨が折れることがしばしばです。

　特に実行段階に入った大きなプロジェクトを、複数企業出身者の混成チームで進める場合、管理スキームの徹底で相当苦労します。メンバーが全員プロ ジェクト管理に慣れ親しんでいる方ばかりだとしても、それぞれが管理のやり方にこだわり出し、調整が難航してスキームの徹底が遅れかねないのです。

課題管理や進捗管理のルールをどう徹底する？

　課題管理一つとっても、管理で必要とする項目や、考え方が人によってそれぞれ異なっていたりします。課題のステータスを示す項目を「起票、対応 中、終了」という簡単なものにするか、「起票、事前準備、検討中、承認待ち、完了」と細かく分けるのか、一体どの項目を使うのか、調整が大変です。課題管理シートや課題管理プロセスを定義しても、それらを素直に受け入れる方と、こだわりがあって反発する方に分かれ、ここでもまた調整に時間を取られます。

　進捗管理についても、報告に様々なやり方があります。例えば、作業の進捗数値をパーセンテージで入れる場合、いくつかのパターンに分かれます。 10種類の設計書に対し5種類のプログラムが完成したから進捗を50パーセントと算出する場合もあれば、あらかじめ予算としておいた必要期間や工数を何 パーセント消化したかという予算消化率で表現することもあります。進捗数値の算出方法を決めるにも調整が必要となりますし、この調整もまたもめるところです。

　厄介なのは、感覚的に完成度合いを測っていながら、何パーセントと数値で報告してくるケースです。ある案件について「進捗率80パーセント」と報告した後、何週間経ってもやはり「80％」と報告してくる。実際、こうしたケースをしばしば見かけます。こうなると、残りが20%といっても、どのような 仕事がどのくらい残っているのか分かりません。こういう事態を無くすためにも、進捗管理の報告のやり方を決めておかないとならないわけです。

現場が息苦しくなる「目的不在の管理」

　一連の管理プロセスを決めるための調整工数を減らしたり、効率的に管理するために、プロジェクトマネジメントの方法論（メソドロジー）や、過去の 成功プロジェクトで使われた成果物（管理指標やシートなど）がしばしば使われます。PMOは、担当するプロジェクトに合った方法論や、応用できる成果物を 探し出し、プロジェクトメンバーに対して方法論の研修を実施したり、成果物を提供します。

　ところが現実には、そのプロジェクトを改善できる管理方法なのかどうか、プロジェクトに合っているのかどうかを検討せずに、方法論だけを導入しよ うとするケースがみられます。こうなると、PMOは単なる管理屋と化し、所定のフォーマットに情報が漏れなく記入されているかどうかだけを気にするように なります。これでは、本質的なプロジェクトマネジメントの改善につながりません。

　よく考えもせず方法論や管理ツールだけを導入しようとするPMOに限って、各チームリーダーにしつこく報告を求めたりします。各チームからすると、PMOが管理をしたいがためにチームへ報告を求めているように見え、「管理のための管理」と言わざるを得ません。PMOは、「何のために管理するの か」という基本について深く考える必要があります。

　管理することによって抽出された情報は、マネジメントに活用され、その結果、プロジェクトが改善されなければなりません。進捗管理により作業の進 み具合を測り、課題管理により進捗の阻害要因を把握し、リスク管理により将来起こる問題の発生可能性を測ることはすべて、マネジメントの意思決定に寄与します。つまり、管理はマネジメントの意思決定につながるべきであり、素早い意思決定や的確な意思決定が管理の成果、PMOの成果になります。

現場任せの問題解決には自ずと限界がある

　とかく日本企業の現場では、管理すること、管理されることの両方に抵抗感を示す文化があります。逆にアメリカ企業は管理を重要視しますが、それは トップダウンで意思決定を迅速かつ的確に行うことが求められるからでしょう。トップダウンの意思決定には、管理によって得られた情報が欠かせません。アメリカ企業のプロジェクトマネジメントが優れていると言っているわけではありません。

　日本のように現場が強い文化でプロジェクトを進める際には、上から管理されなくても現場が密なコミュニケーションをとって問題を解決していくこと ができます。プロジェクトマネジャの意思決定を待っていては作業が進まないこともしばしばです。機敏に動くために、日本の現場力を生かしたプロジェクトマネジメントも重要だと思います。

　しかし、プロジェクトの規模が大きくなり、プロジェクトメンバーが気心知れたプロパーの社員だけではなく、中途入社した社員や組織文化の異なる外 部の会社の社員、あるいは個人事業主のプロフェッショナル、さらには海外のメンバーが混在する場合、現場任せのマネジメントを行うことは大きなリスクを伴います。

　情報システムの開発プロジェクトを例にとりましょう。プロジェクト当初は互いによく知ったメンバーで作業を進めることになり、密なコミュニケー ションが取れ、夜も飲み屋で“ノミニケーション”の機会が頻繁にあり、管理に関してさほど注意が払われません。というより、この状態では管理の必要があまりないのです。

　プロジェクトが順調に進み、設計作業が広がってくるとメンバーが増え、ここに至ってPMOは、体制作りや予算取りに奔走することになります。管理プロセスが必要になりますが、急にPMOの作業が増えるため、様々な点について後手に回り、管理プロセスの導入についても十分な時間をかけることができません。そもそも現場は、仲良しメンバーでやっている心地よさをそのまま保ちたいと思っていますから、なおさら管理すること、されることに抵抗を感じます。

　このままプロジェクトが進んでいくと、中盤以降になって状況把握が困難になり、最後はシステム利用の遅延や予算超過に陥る。こうしたケースが多いと思います。今一度、プロジェクトの状況に応じた管理のあり方について考えてみるべきでしょう。

第3回 「管理される側」に示すべきこと

「管理される側」から見たPMOは、お役所、調整役、火消し役など、プロジェクトによって実にさまざまな見え方をする。こうした多様性は否定しないが、ただ一点、PMOとして堅持すべきことがある。それを忘れると「管理される側」からの信頼を失うだろう。

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

　プロジェクトを「管理する側」と「管理される側」の間には、いつも何となく不協和音が感じられるものです。「PMO（プロジェクトマネジメントオフィス）はいつも各チームの進捗や課題を報告しろと言うが、PMO自身の進捗や課題は一体どうなっているんだ？」。日頃、PMOにくどくど管理されて苛 立っているプロジェクトリーダーやプロジェクトマネジャなら、全体進捗会議の場でこう言いだすかもしれません。

　PMO側は、導入された管理プロセスに従い、各チームからの進捗や課題、またはリスクの情報を集めます。ルーチンワークではありますが、全体を管理する上で不可欠な作業です。その際、レポートの内容に不備があったり、提出が遅れたりすると、PMOはチームリーダーに注意を促して、催促します。

　ここでPMO側が、「お忙しいところ大変申し訳ないのですが、○○欄の記述をより具体的にして頂けませんか？」と丁寧にお願いすればよいのですが、「○○欄の記述が不明瞭なので、具体的かつ論理的な記述の徹底をお願いします」などと、事務的に、そっけなく表現してしまうこともあるでしょう。すると、チームリーダーには高圧的な態度と受け取られ、そこに「管理する側」と「管理される側」の対立関係が生まれることもしばしばです。

PMOの存在意義はプロジェクトによって変わり得る

　プロジェクトに限らず、社内の管理手続きに従うことや、管理部門から注意されることは心情的に嫌なものです。経費精算の提出期限を守らなかった り、人事の評価シートを適当に書いたり、私も昔はよく注意されました。きちんと締め切りを守り、ルール通りにしている方を「偉いなぁ」と思っていました。きっと、「決められたルールだから、従うのが社員の義務」というコンプライアンスの感覚なのでしょう。

　さて、このように管理手続きに対して「管理される側」からは多様な反応があります。プロジェクトにおいては、官僚的なプロセスと割り切り、管理レ ポートをテキパキと提出する方、プロジェクトマネジャへ進言してほしいと一生懸命に課題を記述される方、PMOへレポートを投げても自分たちにメリットは 無いと不満を示される方、などです。

　裏を返せば、PMOの存在意義についての理解がそれぞれ異なっていると考えられます。PMOは「単なるお役所、事務屋さん」という見方、「プロ ジェクトマネジャとの調整役」という見方など様々です。さらに、PMOの中にコンサルタントがいる場合だと、PMOはプロジェクトマネジャに対するコンサルテーションを行うので、「火消し役」という見方も出てくるでしょう。

　会社組織の場合、人事、経理、総務という管理部門の名前を挙げればどの会社でも大体のイメージをつかめると思います。しかしながら、PMOと言う と、人によって様々な解釈があるようです。このコラムではPMOを「プロジェクトマネジメントオフィス」として表現していますが、複数のプロジェクトを対象としたプログラムマネジメントオフィスや、事務局としての意味合いでプロジェクトオフィスという組織もあります。

「PMOがどう貢献しているのか」をメンバー全員に示そう

　誤解を恐れずに言うならば、プロジェクトの状況により、さまざまなPMOの役割があっていいと思っています。例えば、プロジェクトマネジャのマネジメントスタイルにより、PMOに求められるものは変わってきます。カリスマ的なプロジェクトマネジャであれば、細かな報告より、「要は何か」と要点を求めてくるでしょう。現場好きなプロジェクトマネジャであれば、管理情報よりも具体的な課題に関する情報を求めてきます。こうした要素が、PMOの役割を変 化させ得るのです。

　とはいえ、ただ一点、PMOには『管理される側の立場に立って管理情報を整理し、プロジェクトマネジメントの改善に貢献する姿勢』が常に必要だと考えます。例えば、何か課題が生じたとき、プロジェクト全体に影響する課題についてはその原因を分析し、解決のための会議をファシリテーションすることは 少なくとも必要です。加えて、プロジェクトマネジャとの調整も行えれば、言うことはないでしょう。もちろん、そこまで強力なPMOを組織するのは、現実的 に大変かもしれません。

　冒頭で紹介した、PMOと「管理される側」のやり取りをもう一度考えてみましょう。「PMOは各チームの進捗や課題を報告しろと言うが、PMO自身の進捗や課題はどうなっているんだ？」というPMOへの問い掛けに対して、PMOはどうするべきでしょうか。

　プロジェクトによってPMOの役割に多少の違いはあったとしても、PMOが「管理される側」に示すべきことは明確です。それは、「役割分担が不明瞭になっている」「担当が決まっていないタスクが存在する」「無駄な会議が多すぎる」「意思決定が遅れている」といったプロジェクトマネジメント上の課題 に対し、それらを改善するプロセスが進行中であること、そしてその進捗状況や懸案事項を報告すればよいのです。

第4回 PMOは「管理責任」を負うのか？

2007/06/15

改めて、PMOの責任範囲を考えてみたい。一般にPMOは「管理責任」を負うと考えられているが、PMO自らが管理を実行するわけではないし、そこには手を出さないほうがいい。PMOが負うべきは「説明責任」だろう。

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

　プロジェクトの終盤に作業負荷がピークを迎えた設計開発チームから見ると、PMOメンバーは暇そうに見えるかもしれません。私も導入支援チームリーダーなどをしていたころ、「PMOはいったい何をやっているのだろう？」と思ったりしたものです。

　PMOと設計開発チームでは、忙しい時期が全く異なります。PMOが忙しくなる時期は、予算調整、体制作り、管理プロセスの導入などが立て込む各フェーズの初期段階です。プロジェクト終盤になると、作業がルーチン化されるため、PMO自体の作業はそれほど忙しくはありません。もし、プロジェクトの終盤で PMOが非常に忙しくしていたら、そのプロジェクトはかなり危険な状態と言えるでしょう。

プロジェクトの終盤には成果物の作成も手伝う？

　プロジェクトによっては、PMOも設計開発チームと一緒に成果物を作成することが、しばしばあります。プロジェクト終盤に入り、予算不足・人手不足の中、プロジェクトメンバーが一丸となって取り組むことで、なんとか期日や品質を守ることもあります。

　もちろん、PMOには基本的に、プロジェクトの成果物を作成する責任はありません。システム開発プロジェクトの場合、要件定義書や詳細設計書、プログラムなどの作成責任は設計開発チームにあります。建築や造船、エンジニアリング系のプロジェクトでも、PMOが「もの」を作ることはないでしょう。

　とはいえ、何とかプロジェクトを成功させるためにPMOメンバーは手を貸したいと思う気持ちになります。毎晩、深夜まで残業している設計開発チームから「手伝ってよ」と頼まれたら、断りづらいでしょう。

　さて、ここで改めて、「PMOの責任とは何か」を考えてみたいと思います。

　一般に、PMOには「管理責任」があると考えるのではないでしょうか。このコラムの第2回でもPMOの役割として、進捗管理、課題管理、リスク管理、変 更管理、品質管理、予算管理といった仕組みを、プロジェクトの中にうまく導入することが重要という話をしました。その意味では「管理をさせる」ことに責任があると言えます。

果たすべきはプロジェクト・マネジメントの「説明責任」

　また、管理責任を「実行責任」（Responsibility）と「説明責任」(Accountability)に分けた場合、PMOが持つべき責任は 「説明責任」になるでしょう。整理すると、『PMOはプロジェクトの状況について説明する責任があり、そのために管理を徹底させる』と解釈できるかと思い ます。

　PMOの責任範囲を「管理責任」と定義してしまうと、PMOはこの責任を果たすために管理を強化しようとするでしょう。その結果、設計開発チーム側の管理負担が無駄に増える傾向にあるようです。「管理責任」は狭い意味で正しいかもしれませんが、広い意味で考えるとPMOの本来の責任は「プロジェクトマネジメントの生産性を上げること」にあるはずです。

　例えば、プロジェクト終盤における重要案件への対応を、「タスクフォース」で取り組む場合があります。タスクフォースとは特別作業部隊のことで、ある特 定の課題や問題に対し、時限的な組織として立ち上げます。実際に作業を行う担当者は設計開発チームとの兼任となります。PMOは、タスクフォースを立ち上 げるための調整や、タスクフォース内で実行すべきタスクの定義、進捗管理、課題管理、会議のファシリテーションなどを行います。

　プロジェクト終盤になると、開発チームはどうしても目の前にある作業に集中してしまい、プロジェクト全体に影響のある作業を疎かにしたり、後回しにした りします。そのような場合に、優先度の高い作業をタスクフォースで取り組ませることにより、PMOは解決を促すことができます。このような「プロジェクト マネジメントの生産性を上げること」に、PMOは全力で取り組まなければなりません。成果物を作る仕事との掛け持ちは、できるだけ避けたいところです。

　PMOが果たすべき主な責任は「説明責任」ですが、説明責任を果たすために管理を増やし、チーム内の負担を増やすことも避けたいものです。管理工数が増えすぎると、プロジェクトマネジメントの生産性が低下します。

　例えば、会議時間が増える、管理レポートを書くための時間が増えるといったことが生産性を低下させます。管理レポートについては、作業内容、遅延状況、 遅延への対策、エスカレーション課題、共有事項などを記入するテンプレートを利用するわけですが、とりあえず体裁だけ取り繕うために記入するチームリーダーもいます。そのようなレポートを読んでもプロジェクトの状況が分からないので、PMOがヒアリングのための会議を頻繁に開催するはめになる場合もあります。

第5回 意思決定を促す「教父」のような存在に

プロジェクト内の人間関係にごたごたがあると、プロジェクトマネジャといえども視野が狭くなることがある。こういうときPMOは、コンサルティングやカウンセリングのスキルを使って人間関係の調整役を務め、プロジェクトマネジャが的確な意思決定をできるように支援する必要がある。

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

　あるプロジェクトで、PMOからの提案にプロジェクトマネジャは怒りを爆発させました。もちろん、PMOとしてはプロジェクトの状況を精査し、ぎりぎりの妥協点を提案したわけですが、プロジェクト内の不和が一因となってプロジェクトマネジャが強く抵抗したのです。

プロジェクトマネジャ：「いまさらスケジュールを遅らせるなんて、問題を起こしたチームの責任はどうなるんだ？」

PMO：「全体の納期を変えるのではなく、後続作業に影響しない一部の作業を後回しにするだけです。他チームに影響のある作業に集中し、プロジェクト全体の遅延を回避しようという提案です」

プロジェクトマネジャ：「そもそも遅れているチームのリーダーは、『絶対に遅れずに完了する』と豪語していたではないか。遅れたから『は い、リスケします』では、他のチームに示しがつかないだろう。そんなことじゃ、プロジェクトをまとめることなんてできない。それに、一部の作業を後回しにしたところで、それ自体が遅延したらどうするんだ！」

　自らのリーダーシップに自信を持つプロジェクトマネジャは、妥協そのものがプロジェクト全体に悪影響を与えると考えています。このままPMOとプロジェクトマネジャが押し問答を繰り返すだけでは、状況は悪化するばかりでしょう…。

プロジェクトマネジャを動かすには、どうすべきか？

　いくら管理プロセスを徹底し、プロジェクトを可視化したところで、それだけではプロジェクトの遅延を回避できません。プロジェクトメンバーの力量やプロジェクトマネジャのマネジメント力なくして、プロジェクトは成功しません。前回のコラムで「プロジェクトマネジメントの生産性を上げる」ことがPMOの責任範囲であることについて述べましたが、プロジェクトマネジャの意思決定を促進させることは、その最も重要な責務の一つだと考えています。

　意思決定を促すためには、何が必要でしょうか。細かな進捗状況の報告や遅延している課題件数を報告することが、意思決定を促すことにつながるでしょう か。それらの情報だけでもプロジェクトの状況を把握し、判断できるかもしれません。しかし、プロジェクトの遅延や品質悪化の改善に向けた報告は、各チームからの報告内容をそのまま伝えるだけではほとんど何の役にも立ちません。

　報告の流れとしては、一般に「問題の背景」→「問題の源泉（なぜその問題が起きたのか？）」→「問題の解決策」となります。「問題の源泉」はロジックツ リーなどを使って論理的に説明すると分かりやすいと思います。また、「問題の解決策」として複数の案を出しておくと検討しやすい。それぞれのメリット、デメリットを併記するのもよいでしょう。

　ただ、いくら立派な報告内容であっても、最後はプロジェクトマネジャの腹一つで決まるところもあります。冒頭のやり取りのように、チームに対するプロジェクトマネジャの不信感が根強いと、論理的な説明だけではなかなか納得してもらえません。

　かといって、遅延を生じさせたチームリーダーを前面に出し、その責を問うたところで、事態が好転するでしょうか。プロジェクト全体の要員確保の問題や全体のマスタープランが厳しすぎたという問題もよくある話ですから、チームリーダーだけに責任を問うわけにはいきません。

　この場合、プロジェクトマネジャを説得し、チームリーダーに新しいスケジュールの順守をコミットさせるには、PMOが両者の間に立ち、調整役に徹すべきと考えます。

「組織の潤滑油」「教父」の役割が必要

　最もレベルの高いPMOは、人間関係の調整役までこなすPMOだと思います。特に、PMOの責任者であるPMOリードは、コンサルティングやカウンセリ ングのスキルを持つ必要があります。特殊なスキルというわけではありません。「組織の潤滑油」として存在感があればよいと思います。表立って話せない内容の相談を受けるようになると、公式な報告書や会議から読み取れない現場の実情が理解できるようになります。その内容を踏まえて、プロジェクトマネジャに進 言したり、各チームと調整したりすると、組織の一体感が生まれ、自然とプロジェクトマネジメントの生産性が高まってきます。

　ピーター・ドラッカー氏は1980年代の日本企業の研究の中で、次のような考えを示しています。日本企業では、ミドルマネジメント層の間で最も尊敬されている人々は「教父」と呼ばれ、社内の若い人々の面倒をみる。欧米の企業では古参の相談相手の役割を演ずるものがおらず、真の人間的な接触が欠如してお り、離職率が高くなっている。日本では、硬直した制度の非人格的形式性のために、ずっと昔から、こうしたしくみを提供しなければならなかった――としてい ます。

　これは日本企業の経営の話ですが、日本企業のプロジェクトマネジメントの現場でも、この「教父」役が求められていると感じます。その役割を担うべき者は、それこそPMOなのではないでしょうか。

第6回 チーム間の“連携不足”に目を配る

プロジェクト内の各チームは、どうしても自チームの課題対応にばかり目が向いてしまいがち。それゆえ、プロジェクトへの影響が大きい「チーム横断型課題」への対応が遅れやすい。PMOは、こうしたチーム間の“連携不足”に目を光らせることが肝要である。

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

 

　システム開発が山場を迎えようとするころ、プロジェクトルームで、しばしば次のようなやり取りを見かけませんか？

プロジェクトマネジャ：「課題Xは、AチームとBチームで対応するのだよね。進捗状況を教えてくれる？」

Aチームリーダー：「Bチームがユーザーと詳細要件を詰めた後に対応しようと思っています」

Bチームリーダー：「まだ詳細要件は詰めていません。そもそも、どのように進めるかをAチームと一緒に検討しなければと思っていたところです」

プロジェクトマネジャ：「解決が進んでいないという状況は分かったけど、期限はいつなの？」

Aチームリーダー：「申し訳ありません。期限も確認できていません」

　AチームとBチームの両方で解決すべき課題について、両チームリーダーとも把握はしているが、何も対応していないというケースです。期限も不明なため、このまま放置すると、大問題に発展する可能性があります。このように「解決のオーナーシップをどちらが取るのか」という点について、プロジェクトマネジャ がうまく指示をしないと、対応が遅れることがよくあります。

　このケースでは、お互いに相手チームの対応を期待していることが問題の原因です。相手任せの状態で、オーナーシップがないため、期限の把握もおぼつかな いのです。チーム個別の課題に対応するだけでも忙しい中、わざわざチーム横断型の課題を拾ってオーナーシップを取り、多数のステークホルダーと調整を進めるのは難しいことです。他チームの対応を受動的に待ってしまう傾向もよく見受けられます。

　また、マネジメントへの進捗報告の際、チーム個別の課題が進まない場合、すべての責任は自チームにありますが、チーム横断型課題の場合は各チームの責任 となるため、優先度を下げてしまう可能性もあります。言うまでもなく、チーム横断型課題は影響範囲が大きく、プロジェクトへのインパクトが大きいのですが、チームリーダーの意識は自チームの作業に向いているため、組織横断的な視点で見ることが難しいのです。先の例にある「Bチームがユーザーと詳細要件を詰めた後に対応しようと思っています」という発言にもつながります。

自チームで管理していない課題の優先度は低い？

プロジェクトマネジャ：「Cチームの課題管理表にある課題Yは、Dチームにも関係するの？」

Cチームリーダー：「えぇ、Dチームにも関係しますよ」

プロジェクトマネジャ：「Dチームの対応状況はどう？」

Dチームリーダー：「申し訳ありません。対応するのを忘れていました。いつまでの期限でしたっけ？これからすぐ対応します」

　これまた、よく見かける光景ではないでしょうか？

　課題YはCチーム側で管理しているのですが、Dチームにも関係しています。Cチームリーダーは、Dチームリーダーへ事前に対応を依頼しましたが、Dチームリーダーは対応を忘れている、というケースです。

　このケースでは、プロジェクトマネジャが機転を利かせ、Dチームの状況を確認することで発覚しました。しかし、これがなければ、対応期日にCチームリーダーがDチームリーダーへ確認し、大慌てすることになります。

　課題YのオーナーシップがCチームにあるため、CチームがDチームに対応を依頼しているのですが、Dチームは多忙な中、対応を忘れています。Cチーム リーダーに余裕があれば、Dチームの対応状況を都度確認していたかもしれませんが、なかなかうまく行くことは少ないと思います。

「チーム横断型課題管理表」でPMOが解決を促進

　上記2つのケースが示すように、複数のチームが関連しているチーム横断型課題は、解決がなかなか進みません。このような障害を取り除き、チーム横断型課題の解決を促進していく方法として、「PMOによるチーム横断型課題管理表の作成」が挙げられます。

　これは、チーム横断型課題をPMOがリストアップし、重点管理していく方法です。チーム横断型課題管理表には、「主担当チーム」「関係チーム」「期限」欄を設け、必須記入項目とします。また、関係チームごとにアクションプランや進捗状況を記録できるようにすれば、詳細なトレース管理が可能になります。 「主担当チーム」「関係チーム」欄により課題のオーナーシップを明確にし、「期限」欄により解決期限を明確にします。

　PMOがチーム横断型課題管理表を最新状態にメンテナンスすることで、チームの負担を最小限にとどめながら、チーム横断型課題のモニタリング・解決を促進していくことができます。また、多忙を極めるプロジェクトマネジャはすべての課題を把握できるわけではないため、プロジェクトへの影響範囲が大きい課題 の進捗状況を最優先で把握する必要があります。

　チーム横断型課題は、プロジェクトの行方を左右する重要課題です。その管理は、プロジェクトマネジャの意思決定を促進させる上で必要なPMOの役割です。

第7回 進捗報告が形骸化していないか？

各チームからの進捗報告は細かすぎても分かりづらく、粗すぎると状況を的確につかめなくなる。では、プロジェクトマネジメントに本当に使える報告レベルとは何か。これを指示し、進捗会議の改善を行うこともPMOの役割である。

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

 

　「月曜に行われる進捗報告会議のために土曜日に出勤し、しかも、こと細かに進捗報告書を書いて報告しているのに、プロジェクトマネジャはあまり中身を聞いてないよな。こんな報告書を作って、本当に意味があるのだろうか…」。

　土曜出勤で進捗報告書を作っている方は稀かもしれません。しかし、進捗報告書の作成に多くの時間を費やすわりに、必要性が薄いと感じる方は多いのではな いでしょうか。プロジェクトマネジャ側も、「リーダーがたくさん報告をしてくれるのはいいけど、問題点がよく見えないな…。まぁ、一応スケジュール通りだ し、大丈夫ってことかな」となりがちです。逆に「報告が粗すぎてよく分からないから、もっと詳しく書いてほしい」という場合もあるでしょうし、「細かく報告している割に、重要点は一切書かれていない」と思う場合もあるでしょう。

そもそもプロジェクトでは意思疎通が難しいもの

　古今東西、マネジメントに対する報告は常に頭を悩ますものです。「ほうれんそう」（報告、連絡、相談）を社内ルールとして掲げている企業も多く、会社の カルチャーとして根付いているのであれば、スムーズに意思疎通を図れるでしょう。しかし、プロジェクト型組織の場合、個々のプロジェクトは生まれて間もないため、そもそもカルチャーが熟成されにくい。複数の会社からメンバーが参画している場合は、特に意思疎通が難しくなります。

　プロジェクトで進捗報告の定型フォームを作成し、定例の進捗会議を行ったとしても、通り一遍の報告会議になってしまうことが少なくありません。その穴を 埋めるための会議が、公式・非公式にかかわらず多く発生することもあります。プロジェクト組織内のコミュニケーション・パターンを単純に1対1でとらえた 場合、例えば3人の組織であれば、3通りしかありませんが、30人の組織になれば435通り、100人になると4950通りにもなります。

　それほど多くの会議を設けることはないでしょうが、コミュニケーションの多さはお分かりになると思います。PMOには、コミュニケーションの効率を上げるために有意義な定例会議を開く責務があります。では、先ほどの例にあるように、プロジェクトマネジャが知りたいポイントとは何でしょうか。

　報告すべき観点は、品質・コスト・進捗(納期)に影響するものです。それぞれについて詳細な状況を説明するのではなく、まずは最も影響のある問題点と解決の状況および方向性について報告すべきです。プロジェクトマネジャの意思決定に必要な情報を絞り込み、各チームから報告してもらうよう、うまくファシリ テーションするのはPMOの役割です。

分かりやすく、共有しやすい進捗報告書とは？

　また、情報を絞り込むところまではうまくいっても、報告書に「何の問題もありません」の一言だけ記載されている場合もあります。その場合、本当に問題な いのか、PMOも客観的な状況を踏まえつつ、報告者に質問すべきです。もちろん、尋問ではありませんので、状況をかんがみて言葉を選ぶ必要はありますが。

　また、このようなケースもあることから、メールのみのコミュニケーションは避けた方がよいと思います。やはり直接会って話し合うことは、相互のコミュニケーションを密にする上で重要です。

　定型的な進捗報告書を用いずに、各チームが好き勝手なフォーマットで報告書を書いているプロジェクトもあります。プロジェクトの立ち上げ時であればよい かもしれませんが、マスタースケジュールがすでに作成され、予算も付いている場合、WBS（Work Breakdown Structure）や課題管理表とひも付いている報告書が最も分かりやすく、共有化しやすいものになります。報告書の作成が容易であるに越したことはありませんが、上記のような報告書を基に会話する方が、格段によい結果を生むでしょう。

　多くのプロジェクトで定例の進捗報告会議は形骸化しやすく、無意味な会議になってしまう傾向にあります。しかし、ポイントを絞って効率よく報告書を作成 することで、プロジェクトの状況はより見えるようになり、マネジメントの生産性は格段に向上します。また、コミュニケーションも効率化されるので現場の生産性が向上します。このような会議や報告の改善もPMOの責務の1つです。

第8回 “リスク感度”を合わせ、問題発生時に一丸となる

プロジェクトの「リスク」と一言で言っても、それに対する感じ方は人それぞれ。それをあいまいなままにしておくと、いざという時、プロジェクトの足並みがそろわない。では、プロジェクトマネジメント上のリスクはどのようにマネジメントされるべきだろうか。

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

 

Aチームリーダー：「地震なんてそうそう発生しないし、発生したとしても自分は大丈夫。人間、そう簡単には死なないもんだ」

Bチームリーダー：「そろそろ地震が起こるだろう。大地震でも崩壊しない家を建てて、保険にも加入して、準備万端にしておこう」

Cチームリーダー：「もしかしたら地震が発生するかもしれない。とりあえず、水と食料は用意しておこう。そうそう、帰宅支援マップも買っておかなくちゃ」

　もし地震が起こったら…。冒頭の例のように、将来発生するかもしれない出来事への考え方は千差万別です。どれくらいの確率で発生すると感じているか、いざ事が起こったときのためにどれだけ準備をしておくかなど、本当に人それぞれでしょう。

プロジェクトで、リスク感度が“人それぞれ”では危ない

　日常生活に関することであれば、それこそ個人の責任において“人それぞれ”でも構いませんが、プロジェクトではメンバーで認識を合わせ、プロジェクトとして準備をしておく必要があります。そこで通常、リスク管理表を作り、リスクの発生確率、影響度、対応策を検討します。しかしながら、個々のリスクについ て検討すると、リスクに対する感度、つまり受け取り方が人によって異なるため、例えば次のような意見の食い違いが生じます。

Aチームリーダー：「ユーザーは繁忙期だし、ユーザーテストに時間が取れないかもしれない。プロジェクトマネジャ経由で各部門に依頼を出しておいてもらおう」

Bチームリーダー：「ユーザーは繁忙期だけど、ユーザーテストに必要なメンバーは出してもらえるだろう。実際にテストを開始してみて、参加率が低かったら対応を検討すればいいと思う」

　このような場合、PMOはプロジェクトマネジャ、Aさん、Bさん、その他のリーダーを一同に集め、「繁忙期のユーザーがどれだけプロジェクトに参画するか」について、どう思うかを話し合い、プロジェクトとしてリスクへの感度を合わせるようにします。

　このミーティングでは、それぞれが感じていることを共有することが大事ですので、満遍なく意見を集めていくことがPMOに求められます。PMOはあえて 真逆の意見を出してみるのもいいでしょう。また、テーマを決めず、各メンバーが感じているリスクについて自由に意見を出してもらい、メンバーの懸念事項を共有することも大切です。

なぜリスクが発生するのか論理的に検証し、全員で意識合わせを

　多くのプロジェクトでは、「リスクの発生確率が80%なのか、60%なのか」などを議論し、管理上の落とし所を探す議論をしています。このような議論では、管理するための“決め事”の議論を行っているだけで、残念ながら対応の方向性について意識合わせをしているわけではありません。プロジェクト内での意識合わせをせずにいると、いざという時、プロジェクトの足並みがそろわない可能性があります。

　決め事を議論するよりも重要なことは、なぜそのリスクが発生するのかについて、具体的な個々人の経験、事実を積み上げた「論理的な検証」です。論理的に 積み上げた議論であれば、各メンバーのリスク感度を合わせ、リスクに対して足並みをそろえることが可能となります。この「足並みをそろえる」というお膳立てをし、定期的にリスク感度を合わせる場を設けることが、まさにPMOの役割となります。

　これから発生するかもしれない出来事への事前対応が可能となるのはもちろんですが、プロジェクトメンバーの懸念事項が共有されると、組織としての一体感が出てきます。ここがリスク・マネジメントの重要なポイントの1つです。

　そもそもリスクについての検討は否定的な意見を出すことなので、気持ちのよいものではなく、遠慮しがちな議論になります。まずはPMOが中心となって各メンバーが感じている懸念事項を共有することから始め、リスク検討サイクルを回してみてはいかがでしょうか。

第9回 課題管理表からゴミを取る

プロジェクトで次々に発生する「課題」。これらを的確に管理して対処していかないと、プロジェクトが頓挫するか、品質の低い情報システムを生み出し てしまう。だが、課題管理を安易に始めると、課題の中に「リスク」や「ToDo」「備忘録」的なものが混在してしまい、見るに値しない課題管理表になる。 このような“ゴミだらけ”の管理表では、とてもマネジメントなどできない。

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

 

　プロジェクトの課題管理について、会議中、次のようなやり取りを長々と言い合う場面に出会ったことはないでしょうか。

プロジェクトマネジャ：「Aチームの課題は総件数が152件。未決件数80件中、期日遅れが40件になっている。プロジェクトが始まって2カ月しかたっていないのに、どうしてこれほど遅れが生じているのか？」

Aチームリーダー：「重要な課題は3件と認識しているのですが、それ以外は各チームメンバーが記入しているものなので、あまり重要ではありません」

PMO：「重要でなくても、各チームメンバーの進捗を阻害している課題、例えばユーザーが要件を決めてくれない、成果物をレビューしてくれない、といった課題はチームリーダーが率先して対処すべきではないのか？」

Aチームリーダー：「私は直接そのような話は聞いていないですし…」

　課題の総件数が152件となっていますが、中身を見たら、各チームメンバーの備忘録であったり、リスクとして感じていることだったり、やるべき作業項目（ToDo）だったりして、とにかく“ごちゃ混ぜ”になっていました。その結果、チームリーダーはほとんど課題管理表を見なくなってしまいました。上記の 会話で、Aチームリーダーが歯切れの悪い話をするのは、そのせいだったわけです。

　現場ではPMOが指示した課題管理のテンプレートを使っているものの、中身の記述レベルが不徹底だったため、課題管理が形骸化していました。せっかく使っている課題管理表も、うまく生かされていません。また、課題解決を期待して起票しているチームメンバーも、このような扱いが続けば、次第に課題を挙げ なくなってしまうでしょう。このような問題は、課題、リスク、ToDoを明確に区別しきれていないことが一因となっています。

本来管理すべき「課題」とは何か

　このような問題を避けるために、PMOは何をすべきでしょうか。課題管理を徹底する上で非常に基本的なことではありますが、課題、リスク、ToDoの違 いを、メンバー全員に理解してもらうことから始めていく必要があります。PMOはプロジェクト全体にわたる管理プロセスの定着化に責任を持ちますので、テンプレートを提供するだけではなく、運用上の手ほどきを担うべきです。

　「課題」の定義はいくつかの観点により異なるでしょうが、プロジェクトマネジメント上、最も分かりやすい定義の仕方は「進捗および品質を阻害している原 因」と理解するのがよいでしょう。単純な例で言うと、タスクAの進捗が遅れているという問題があった場合、原因が要員の不足にあったとするなら、「要員不 足のため進捗が遅れている」ことが課題となります。

　進捗が遅れているとか、品質に問題があるという表現で課題管理表に記述してしまうと、原因がつかめず、対応策が出てこないという事態に陥ってしまいま す。これでは、いつまで経っても課題を完了できない可能性があります。必ず、「問題事象→原因究明→課題化→対応策」といったステップごとに考えていく必要があります。

　整理した結果、対応策まで見出せたらそれがToDoとなるものがあります。しかし、課題管理はToDoをメインに管理していくのではなく、あくまでも課題を管理していくものです。ToDoは、課題とは別に管理すべきです（いわゆる「ToDo管理」）。

　ToDo管理は、課題から導き出されたものだけではなく、やるべきタスクを忘れないようにチェックしていく備忘録的な目的で、各チームリーダーが自分のチーム管理の一環として実施していくことが多いようです。

　なお、リスクとは将来課題になりそうな事柄のことを指します。リスク管理上の注意点に関しては、「第8回 “リスク感度”を合わせ、問題発生時に一丸となる」にて説明しています。

　一口で言うと、課題は「過去に起こった問題の原因」、ToDoは「現時点でやるべき仕事」、リスクは「将来起こる可能性のある問題」と言えます。このように性格が違うものをごった煮にして管理しないように気を付けながらプロジェクトを推進していくと、プロジェクトの可視化が上手くいくようになると思いま す。

第10回 計画変更時の「見極め」を支援する

プロジェクト開始当初に計画していた作業内容よりも、予想以上に多くの作業が発生してしまうことは頻繁に起こる。PMOはその調整作業に一役買う必要があるが、一体どんな検討や準備をすべきだろうか。追加作業が発生したときの計画変更作業から最終的な意思決定までのプロセスを概観してみよう。

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

 

　プロジェクトの作業計画を立てるなかで、各チームの担当作業を決めますが、その時点ですべての作業を洗い出すことができない場合がよくあります。開発方法論に則ったシステム開発プロジェクトであったとしても、予想外の出来事が発生し、その対応に追われることもあります。

　例えば、プロジェクトの途中でユーザー企業側の担当役員が異動になった場合、プロジェクトの中止まで行かなくても、プロジェクトが縮小されたり、プロジェクト・スコープが変更されたりします。場合によっては、プロジェクトへの影響が極めて大きいケースもあるでしょう。

　困るのは、こうした変更が起こったにもかかわらず、「プロジェクトの予算や納期はそのまま」というケースがよくあることです。新しい担当役員からの評価を気にするあまり、“ガンバリズム”で決断してしまうプロジェクトマネジャもいるのではないでしょうか。

　ステークホルダー（利害関係者）間の調整に関するPMOの役割については、別の機会に書きたいと思いますが、今回は当初予期していなかった作業が発生したときにPMOはどのような役割を担うべきか、について述べたいと思います。

想定外の作業が生じたときこそ、マネジメントの力が問われる

　当初決められた役割や作業以上の仕事が出てきた場合、気持ちの上では敬遠したいと思うものです。結果的に、責任感の強いメンバーが無理をすることで対応 するケースが多いのではないでしょうか。ただ、このメンバーが病気や過労で休んでしまうと、プロジェクトがピンチを迎えるかもしれません。

　その一方で、追加作業が発生する都度、メンバーが一丸となって取り組むプロジェクトもあります。その姿には一生懸命さが表れていて、一見チームワークに 優れた、順調なプロジェクトのように見えますが、実は盲点もあります。プロジェクトメンバーが20人を超えるような場合、必要のないメンバーも会議招集さ れたり、あまり意味のない作業を任されたりして、本来やるべき作業になかなか手が付けられなくなるのです。これは想定外の問題から派生した“2次災害”と でも言うべきものでしょう。

　組織に一体感を持たせたいという気持ちもあるかと思いますが、追加作業に対応するときも、やはり役割分担を明確にすることはプロジェクトマネジメントの王道です。

　追加作業の役割分担を行うためには、作業計画に基づいたWBS（階層構造化された作業）およびアウトプットとしての成果物をまず定義する必要があります。そもそもWBSの作成で壁にぶつかる場合もありますが、プロジェクトのアウトプットから論理的に考えていけば、うまく行きます。

　それらのアウトプットに対して責任を持つチームおよびメンバーをそろえ、必要工数を見積もると、適正な役割分担が見えてきます。なお、ここでの役割分担は成果物作成のための実行責任を持つという意味に限定し、説明責任という役割は除外しておきましょう。

　追加作業に関する計画フェーズでここまできちんと整理できていれば言うことなしですが、現実には、なかなかそこまではできません。プロジェクトを進めな がら調整していくことも多いかと思います。仮に100％完璧な計画を作成していたとしても、前述のような想定外の出来事が再び起こるかもしれず、更なる変 更を余儀なくされる可能性もあります。

　プロジェクトは不確実性の塊です。少々乱暴な言い方かもしれませんが、「計画は変更するために作られる」と考えた方がよいでしょう。そう思っていれば、いざという時、ぐずぐずせずに済みます。精神衛生上も良いと思います。

「見極め」に必要な情報をPMOは蓄積しているか？

　追加作業に対して、予算や時間に余裕があれば、人員を追加することで対応できるでしょう。そのようなプロジェクトは幸運です。通常は予算や時間に余裕が ない場合が多く、先ほど述べたように責任感の強いメンバーが対応したり、何かしらの負担をメンバーに強いたりすることになります。予算の追加や納期の変更で対応する場合もあります。

　ただ、これらの決断は、最終的にプロジェクトオーナーやプロジェクトマネジャなど予算やスコープに責任を持つ人々が行うことです。PMOとしては、その意思決定に貢献する必要があります。

　プロジェクトの状況により異なるため、一概に言えませんが、追加作業が発生したとき、「現状のプロジェクト体制でどこまで踏ん張れるか」を見極めること が、意思決定支援に一番必要なことだと考えます。特に、システム開発のような、知恵や情報を生み出していくプロジェクトの場合、個々のメンバーの生産性やポテンシャルは見極めにくいものです。作業が意外に早く終わったり、意外に時間がかかったり、当初の見積もりは必ずしも当てにできません。

　PMOは、プロジェクト全体の生産性を見極める意味でも、日ごろから地道にプロイジェクトメンバーとコミュニケーションを取り、状況を把握しておく必要があると考えます。これが、想定外の作業が発生した際の「見極め」に大きく貢献するはずです。