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

第21回 プロジェクト運営の「失敗学」

PMOには、失敗から学び、学習していく組織を作る責務がある。もし同じような失敗を繰り返しているようなら、それはPMOの怠慢による結果だ。プ ロジェクト運営に「失敗学」を生かし、「現地・現物・現人」による失敗原因の究明や「悪いことこそ進んで言える場作り」を目指してみてはどうだろうか。

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

 

　プロジェクトを運営していく中で、小さな失敗から大きな失敗まで、さまざまな失敗を経験します。皆さんはそれらを「良い失敗」なのか「悪い失敗」なのか、見極めているでしょうか。

　「失敗から学び、失敗を未然に防ぐ」ことを追求する考え方として、工学院大学教授・東大名誉教授の畑村洋太郎氏が「失敗学」を提唱しています。この失敗学によれば、失敗を「良い失敗」と「悪い失敗」に分けて考えています。

　「良い失敗」とは、予知できなかった防ぎようのない失敗で、同じ失敗を繰り返さないための教訓になるものです。「悪い失敗」とは防ぐことができた失敗、 言い換えれば1度経験した失敗ということになります。PMOは「良い失敗」から教訓を学び、「悪い失敗」を未然に防ぐという、いわゆるリスク管理の能力が求められています。

原因分析と対応策を“現場任せ”にしていないか？

　進捗報告の場で失敗が報告された時、あなたがPMOのメンバーなら、どのような行動をとるでしょうか。一般には、次のような行動を思い浮かべる方が多いと思います。

　・上位層へのエスカレーションを判断する
　・失敗に対する原因分析を実施させる
　・ほかに影響がないか調査させる
　・原因に対して対応策を立てさせる
　・対応策の実現性があるかどうかを見極める
　・対応策が計画通りに実行されているか管理する

　どの行動も間違っていません。ただ、PMOが担当者の報告内容を鵜呑みにしているとしたら問題があるでしょう。もしかしたら、現場の状況は報告内容よりひどい状況かもしれません。また、報告や対応策が適切かどうかをチェックするとしても、表面的な数値（バグ数など）で安易に判断していたとしたら、やはり 問題です。数値から分かるのは、現場の一部の状況に過ぎないのですから。

　残念ながら、ほとんどの現場でPMOがこの過ちを犯しています。失敗の原因分析と対応策の立案を現場の担当者に任せてしまい、PMOは対応状況だけを管理しようとしています。

　こう書くと、「PMOだからといって、すべての報告や対応策が正しいかどうかまで確認できるわけがない」と思われるかもしれません。確かに、その通りのことを実行しようとしたら非現実的だと思います。しかし、重要なものだけに絞り込めば、確認は可能です。例えば、プロジェクト運営にかかわる重大な失敗と してエスカレーションされた事項については、PMO自身が原因究明に関与し、本当に正しい対応策かどうかを判断すべきではないでしょうか。

失敗究明の極意は「三現」、PMOだから作れる現場との架け橋

　失敗の原因を究明し、対応策が正しいかどうかを見極める際に役立つのが、失敗学で言う「三現」という考え方です。三現とは「現地・現物・現人」のことで、失敗学において「原因究明は三現で実施すべし」というガイドラインがあります。

　例えば、設計書どおりにシステムが出来上がっていないという問題が発生したとしましょう。このケースで、「三現」による原因究明は以下のようになります。

（1）現地…開発の現場に実際に行って、自分の目で何が起きたのかを確かめる
（2）現物…成果物の現物（設計書やシステムそのもの）を自分の目で確認する
（3）現人…問題を起こした本人（設計者や開発者）に直接確認する

　三現で確認した原因に対して、適切な対応策が立てられているかが重要だということは言うまでもありません。ここでなぜ三現について述べたかというと、PMOだからこそできる役割があるからです。

　PMOの大きな役割の1つに、「マネジメント層と現場をつなぐ」という重要な役割があります。そのような意味において、PMOはエスカレーションされて きた重大な失敗の報告に対して、「現地・現物・現人」で確認ができる最適な組織なのです。「ロジックツリー」や「特性要因図」による机上での問題解決も役に立ちますが、現場に入り込んで問題解決を行う行動力こそ、PMOに求められる重要な能力の1つではないでしょうか。

「人」でなく、起きた「こと」に注目する

　失敗学においてもう1つ大切なことは、「人」ではなく起きた「こと」に注目するという点です。大きな失敗をしてしまった時、「誰が悪い」という責任問題をつい先に考えてしまいがちです。しかし、プロジェクトを円滑に推進するためには、責任問題はいったん置いておいて、起こってしまった「こと」に注目する ことが必要となります。

　また、失敗した「人」にばかり注目してしまっては、ネガティブなことを進んで言えなくなる組織になってしまいます。「罪を憎んで人を憎まず」という雰囲気を作り、「悪いことこそ進んで言える場」を作っていくこともPMOの大切な役目だと信じています。

教訓の蓄積が大きな財産となる

　最初から失敗を1つもしない完璧なプロジェクトは存在しません。どんなプロジェクトにも必ず失敗は発生します。さまざまなプロジェクトの「良い失敗」から教訓を1つでも多く蓄積し、「悪い失敗」をいかに事前に防ぐことができるのかが大切なのです。言い換えれば、PMOのこのような地道な活動は、ほかの多 くのプロジェクトを成功に導くための大きな貢献でもあるのです。

　「今日の失敗からは何が学べたか？」。これが私の座右の銘です。

第22回 PMOは火消しの「遊軍」たれ

「雑用は何でもPMOへ」――。あなたのプロジェクトは、このような状況になっていないだろうか。PMOが“何でも屋”になってしまうと、いざという時、本当に重要な問題への対応ができなくなってしまう。PMOは、少し余裕がある「遊軍」としての働きが求められる。

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

 

　連載第1回の「事務局にあらず、庶務係にあらず」で書いたように、PMOは“何でも屋”ではありません。その半面、事務局・庶務係的な役回りをある程度期待されている組織であることも否定できません。実 際、「担当が曖昧な仕事や雑用的な仕事をPMOが何でもやってしまう」というプロジェクトは、一見PMOのおかげでうまく回っているように見えます。

　しかし、ちょっとした雑務の積み重ねの結果、仕事量がPMOの許容範囲ぎりぎりになっていたとしたら、どうでしょうか。PMOは、進捗管理や課題管理な どプロジェクト運営には欠かせない横断的なタスクを抱えています。もし、PMOが対処すべき新たな横断的タスクが発生したとき、プロジェクト運営自体が停 滞してしまう危険性があります。

　特に、次のような負のスパイラルに陥るリスクがあることに注意すべきです。（1）PMOが対処すべき突発的な課題が発生→（2）PMOの負荷が増大 →（3）ほかのプロジェクト運営タスクに遅れが発生→（4）ほかのプロジェクト活動へ影響→再び（1）に戻り別の突発的課題が発生、という悪循環です。 PMO自身が新しい課題を誘発してしまうようでは、このプロジェクトはもう泥沼状態の一歩手前と言えるでしょう。

PMOは少し余裕があるくらいがちょうどよい

　繰り返しになりますが、PMOはプロジェクト運営にかかわる横断的なタスクを実施していく組織です。そして、プロジェクトを推進する中でプロジェクト横断的な問題は突発的に発生します。それに備えて、PMOは普段から「本当にPMOで実施すべき仕事」なのかを選別して、少し余裕を持っておく必要があります。この余裕がないと、想定外の事象に素早く対応できません。たとえ開発チームから「暇そうだねぇ」と嫌味を言われたとしても、PMOは「遊軍」たる一面を持っているべきなのです。

　PMOは開発チームとは違い、作業工数が増えたからといってすぐにメンバーが増員される組織ではありません。逆に、工程が進むにつれてPMOのメンバー は減らされていく運命にあります。この点を踏まえて、自ら実施すべき仕事の範囲を調節しておかないと、いざという時に「人手が足りない」という最悪の事態に陥ってしまうわけです。

　PMOには、課題管理や進捗管理などの重要なルーティン業務を着実に実施するという重要な役割があるので、厳密な意味においては純粋な遊軍ではありません。しかし、ぼやが発生した時、大火事にならないうちに素早く対応するという役回りは、プロジェクト状況を俯瞰しているPMOという組織だからこそできる仕事だと思います。皆さんのプロジェクトでも、PMOの現在の状況や役割をもう一度考えてみてはいかがでしょうか。

第23回 挫折しないリスク・マネジメント

将来起こり得るリスクを洗い出して、あらかじめ対応策などを決めておく「リスク・マネジメント」は、プロジェクトの成否に大きな影響を及ぼす重要な ものである。しかし、リスク検討会を1回か2回開催しただけで、形骸化してしまうケースが非常に多い。やり方を工夫して、効率的なリスク・マネジメントを実施していきたい。

田口正剛
マネジメントソリューションズ 取締役

 

　キックオフからおよそ1カ月後、まだ課題管理と進捗管理くらいしか実施していないプロジェクトで、次のような会話があった。

プロジェクトマネジャ：「そろそろマネジメント向け会議があるから、リスクを洗い出して報告してくれないか？」

PMO：「今のところリスク・マネジメントは実施していませんが、当プロジェクトではリスク・マネジメントを導入しますか？」

プロジェクトマネジャ：「何を言っているんだ？ 当たり前だろ！」

PMO：「言葉が足りませんでした。『当プロジェクトでは、リスク・マネジメントにどの程度の工数（＝コスト）をかけますか？』という点を確認したかったのです」

　皆さんのプロジェクトでも、似たような議論が起こっていないでしょうか。リスク・マネジメントとは、プロジェクトを進めていく中で将来起こるかもしれな い内容（リスク）を想定し、それに対する対応策を決めておくことです。その際、プロジェクト内でリスク内容と対応策についての共通認識を持ち、準備を整えておくことが肝要です（詳細は「第8回“リスク感度”を合わせ、問題発生時に一丸となる」を参照）。

　ところで、プロジェクトの開始直後から課題管理を導入していると、いつのまにか管理表の中に「リスク」と考えていることや日々やるべき「ToDo」が混入してしまうことが多いものです。こういうとき、リスクとToDoをそれぞれ別の管理表に分けるべき、という内容も「第9回 課題管理表からゴミを取る」にてお伝えしました。

　ここで、課題、リスク、ToDoをそれぞれ別の管理表とマネジメント・プロセスで定着化を図るとき、筆者の経験からして最も難しいのは、リスク・マネジメントだと感じています。

教科書通りのやり方で効率的に運用できるか？

　PMBOK（Project Management Body ofKnowledge）が一般的になり、リスク・マネジメントを実施するプロジェクトが多くなってきました。大抵のプロジェクトでは、リスクの「発生可能 性」と「影響度」を指数化し、数値が高い（優先度が高い）リスクを重点的にモニタリングしていく方針で運用していることと思います。プロジェクト・マネジャ、PMO、チームリーダーの全員でリスクを管理する上で、リスクに優先度を付ける2つの指標には大きな意味があります。

　しかし、はたしてこのプロセスをうまく運用できているプロジェクトはどのくらいあるのでしょうか。このパターンだけで運用を開始した場合、リスク検討会 を1回か2回開催しただけで、形骸化してしまう例をたくさん見てきました。なぜなら、将来顕在化するか分からないリスクに対して、予想よりずっと多くのマネジメント工数が必要だと分かり、挫折してしまうことが多いのです。リスクは時間が経つにつれて変化していく性質があるため、定期的にリスクを評価し直す 場（リスク検討会）が必要となります。そして、そこにかける工数が、無駄と思えるほど多いことに、すぐ気付くはずです。

　打開策としていろいろな考え方があるかと思いますが、実際に運用してみて効果があった方法を1つ紹介したいと思います。それは、「チーム単位でモニタリングするリスク」と、「マネジメント・レベルでモニタリングするリスク」を分けて管理することです。リスク管理表には、管理主体がチームかマネジメント・ レベルかを区別するフラグを1つ追加します。

　管理主体を分けると、まずプロジェクトマネジャやPMOの負担が大幅に減り、プロジェクト全体に影響を及ぼす重要なリスクに集中できるようになります。そしてチームリーダーは、プロジェクトマネジャに報告する内容（リスクやその状態）をチーム内で吟味してからエスカレーションするようになります。このた め、意外と要点を突いたリスクが挙がりやすくなるのです。プロジェクト全体で見るべきリスクの共通認識も持ちやすくなるでしょう。

　マネジメント・レベルで管理すべきリスクは、例えば『ユーザー受入テストを実施するに当たり、エンドユーザーの参画調整がうまくできず、使われないシス テムになる恐れがある』など、プロジェクト全体で対応策を検討し、定期的にモニタリングをしていくべきことです。一般的には、プロジェクト全体で識別した総リスク数の2割程度でしょうか。マネジメント・レベルのリスクとして管理していくことが決まった事項は、短期間で状態の変化がなかったとしても、PMO などが週次会議などで継続的に確認し、プロジェクト全体で発生を防ぐべく認識を合わせる活動をしていきます。

　一方、チーム単位でモニタリングするリスクは、チーム内で懸念されるリスクの感度をチーム・メンバーで合わせることに主眼を置いています。必ずしもすべ てのリスクをプロジェクト全体の週次会議などで報告する必要はありません。2つの指標（発生可能性と影響度）に基づく優先度に従って報告頻度を調整すれ ば、毎週すべてのリスクを評価し直すこともなく、工数を削減できます。これなら挫折することなく、リスク・マネジメントを運用していけるのではないでしょうか。

第24回 もう納品でドタバタしない

プロジェクトの節目で、メンバーは課題対応やドキュメント作成にばかり気をとられ、納品作業（契約）を忘れがちになる。納品作業は、ユーザー・営 業・現場を巻き込んだ一大イベントであり、契約に関わる重大なタスクだが、いつもドタバタしがちである。そんな時、全体調整に長けたPMOが力を発揮して ほしい。

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

 

　小規模プロジェクトであれば、ユーザーと現場の関係が密になっており、日ごろから作業状況も共有されていることでしょう。そういうプロジェクトでは、納品作業が問題になることは少ないと思います。

　しかし、大規模プロジェクトでは、納品作業に苦労することが多いのではないでしょうか。「納品はしたが、認識の齟齬が発生しており、検収が遅延した」という苦い経験をした方は決して少なくないと思います。

監査・内部統制が重視され、検収は厳密に

　納品作業が滞らないように、大規模プロジェクトでは、フェーズ開始前に成果物を定義し、契約書にも記載します。ですが、プロジェクトはまず予定通りには 進まないので、「当初予定していた成果物が作成できない」という事態も起こります。現場では、特定の成果物を作成できない理由が共有されているので、当然、その成果物は作成しないものと思っていますが、契約という次元では通用しません。そのため、ユーザー側の契約担当者（納品担当者）に、事情を論理的に 説明しなければなりません。

　契約担当者がプロジェクトの現場に入っていれば説明は不要でしょうが、大抵はきちんと説明しないとトラブルに発展しかねません。特に近年は、監査・内部 統制が重視されています。契約担当者は、論理的な説明がない限り、契約書と少しでも異なる納品物を検収することはできません。

　また、大規模プロジェクトでは、契約・納品作業を、現場のメンバーではなく、営業担当者が行うことがあります。この場合、営業担当者との認識齟齬にも注意すべきです。

　例えば、月末検収を行うため、「納品は月末から3営業日前にする」ということを当該フェーズの開始前に現場へ連絡していたとしましょう。しかし、フェーズの終了時にはすっかり忘れられていて、現場はその月の最終営業日に納品する予定で作業を進めていたりします。また、納品物をPDF化して納品するルールとなっている場合などで、現場と営業担当者のどちらがPDF化するのか決まっていなことが多々あります。互いに相手がすると思っていて、納品当日にドタバタしてしまうこともよく見る光景です。

ユーザー・営業・現場の認識を合わせ、納品の要所を押さえよう

　では、上記のような事態を回避するには、どうすればいいでしょうか。ポイントは、フェーズ終了前にユーザー、現場リーダー、営業担当者を集め、納品作業 に関する認識を合わせていくことです。意外に知られていませんが、納品作業で最も大切なことは関係者の「認識合わせ」なのです。小さなことでも、情報を共有する手間を惜しむべきではありません。

　ここまで説明すれば、一連の納品作業を誰が仕切れば最もうまくいくか、皆さんには想像がついているでしょう。そう、もちろんPMOです。PMOはプロ ジェクト全体を見渡す視野を持ち、全体調整に長けています。契約担当者、営業担当者、現場の橋渡しをして、納品作業の要所要所を押さえていくのに適任です。

　関係者の認識を合わせるための打ち合わせは、フェーズ終了間際ではタイミングが遅く、かといって1カ月以上前だと早すぎて打ち合わせの内容を忘れてしまいます。ですから、2～3週間前から打ち合わせを始め、納品までのタスク、スケジュール、担当者を明確にし、進捗管理をしていくことが必要です。

　ユーザー側の契約・納品担当者と、プロジェクト状況や最終納品の形を共有する場も事前にセッティングしておきましょう。チームが多い場合は、PMOがプ ロジェクトの状況や成果物の作成状況などを整理して取りまとめ、契約担当者に一括して説明すると効率的です。もちろん、詳細な説明は現場担当でないとできませんので、チームリーダーには同席してもらいます。契約書上の成果物との差異、差異が生じた理由、リカバリー案をマネジメントの視点で論理的に説明すれ ば、スムーズに納品、検収が進むでしょう。

　ここまでPMOが手配すれば、もう納品でドタバタすることはないでしょう。

第25回 「モチベーション」だって見える化できる

メンバーの「モチベーション」という目に見えない問題に対して、PMOならではの役割がある。「現場の悩みを引き出しやすい面談の場作り」をプロジェクトマネジャやチームリーダーに助言したり、マネジメント層とメンバーとの“橋渡し役”として、現場の悩みやモチベーションの状態を見える化したりす ることに注力できる。

今井 昌史
マネジメントソリューションズ

 

　進捗会議の一コマ。いつものように2人のチームリーダーがプロジェクトマネジャに進捗を報告し始めました。しかし、Bチームリーダーの報告は、かなりあいまいな内容でした。

プロジェクトマネジャ：「Aチーム、Bチームの進捗状況を報告してください。では、まずはAチームからお願いします」

Aチームリーダー：「はい。現在顧客抽出条件に関する質問の回答待ちで基本設計が2日ほど遅れていますが、先行して詳細設計のうち抽出条件に直接関係のない部分を実施していますので、今週末までに抽出条件の回答がもらえればスケジュールは挽回できます」

プロジェクトマネジャ：「なるほど。ではBチームはどうですか？」

Bチームリーダー：「えーっと、少し遅れている作業はありますが、まぁ、大きな問題はありません。来週にはリカバリできると思います」

　Bチームリーダーは覇気なく、こう答えました。さて、このような報告を聞いたときに、プロジェクトをマネジメントする立場として、どんなことを意識すべきでしょうか。

　Aチームリーダーの報告は非常に具体的で、課題や進捗状況が明確に報告されています。一方、Bチームリーダーの報告はあいまいで、課題や進捗状況が具体化できていません。その点で、Bチームリーダーの報告の仕方はいただけません。しかし、問題はそれだけでしょうか。

年に数回の面談ではメンタル問題の発見が遅れることも

　実は、BチームおよびBチームリーダーはそれ以上の問題を抱えていました。その影響で仕事に対するモチベーションも相当低くなっており、報告の仕方に表れていたようです。PMOとして報告の仕方を注意することも必要ではありますが、このケースでは、裏に見え隠れする問題やモチベーションの低下に気付くことのほうがより重要です。

　進捗の遅れなどは定量的に測れますが、メンバーのモチベーションを定量的に測定するのは非常に困難です。そのため一般には、人事評価の面談などを通じてチームリーダーやプロジェクトマネジャがメンバーのモチベーションを把握し、ケアをしていることが多いと思います。

　ただし、年に数回の面談だけでは、モチベーションの低下を把握する機会が十分とは言えません。面談してみたときには、すでにモチベーションの低下どころ か、精神的に相当参っていた、という状況も考えられます。それだけに、できることなら普段からメンバーのモチベーションをケアしておきたいところです。

　こういった、非定量的で管理のしにくい問題に対して、PMOは何ができるのでしょうか？

まずは面談の内容を改善しよう

　面談の中で、メンバーが抱えている問題をチームリーダーやプロジェクトマネジャが聞きだしたいと思っていても、実際にはうまく聞き出せないことがありま す。リーダーやプロジェクトマネジャには「人事評価者」としての顔がありますし、少しでも説教じみた態度が出てしまうと、メンバーが相談しにくくなってしまうことがよく起こります。メンバー自身が相談したいと思っていても、いつの間にか気持が萎えてしまうこともあるのです。

　これでは、年に数度の機会を十分に生かせず、危険信号を見逃してしまいます。PMOとしては、後からリーダーやプロジェクトマネジャにヒアリングするなどして、「メンバーが相談しやすい雰囲気の面談だったかどうか」をチェックするとよいでしょう。また、PMOがメンバー役となってリーダー、プロジェクトマネジャと模擬面談を実施し、面談での態度や面談内容を直接チェックする手もあります。

　もし、面談内容に問題があった場合、PMOはリーダーやプロジェクトマネジャに問題点をフィードバックし、面談の内容、進め方、態度などを改善していくように助言します。こうした場作りを支援していくことで、メンタル面の問題を見える化しやすくなります。

危険な兆候を示しているメンバーにはPMOが臨時面談を

　明らかにモチベーションが低下していると思われるメンバーに対しては、人事評価の面談とは関係のない非公式なヒアリングを実施します。この場合、直接の 上司がヒアリングを実施してしまうと、そこで話した内容が評価などにつながるというプレッシャーになり、素直な意見が聞けなくなることがあります。そのため、直接の上司ではなく、PMOがヒアリングすると効果的な場合があります。

　モチベーションが低下しているメンバーを見分けるポイントとしては、以下のようなものがあります。

（1）高い作業品質を保っていたメンバーの作業品質が突然落ちた
（2）残業時間は長いのに作業の進捗がいまいち
（3）会議での発言が著しく少ない
（4）上司との会話をしているときに目を合わせていない
（5）会話のスピードが以前より遅くなった

　こういったメンバーを見つけた場合には、PMOが上司の代わりにヒアリングをしてみるべきでしょう。

なるべく短い周期でマイルストーンを設定する

　長期のプロジェクトでは、いつまでたっても作業のゴールが見えないことでモチベーションが低下することがあります。そういう問題を避けるには、スケ ジュールの立て方に一工夫するとよいでしょう。なるべく短い単位でマイルストーンと目標を設定し、「それが守れたら成功」とする体験を積み重ねるように計画するのです。短期的な目標が見えていること、そして成功体験を繰り返すことでメンバーに自信が付き、それがモチベーションの維持・向上につながります。

　PMOには、プロジェクトマネジャをサポートする一方で、メンバーとプロジェクトマネジャの“橋渡し”となり、メンバーが抱える問題を吸い上げる役目が あります。プロジェクトの管理テクニックを学ぶことはもちろんですが、メンバーに信頼されたり、メンバーに自信を付けてもらうためのスキルを持っていることも非常に重要です。

　メンバーのモチベーションが向上することで解決する問題も実は少なくありません。目に見える部分の問題点がある程度解決され始めたら、次は『人の心』という目に見えない部分をケアしていくという難しい課題にも取り組んでみてください。

第26回 コミュニケーションの潤滑油になろう

プロジェクトマネジャを前にすると、気後れするメンバーが少なからずいる。そんなメンバーは、プロジェクトマネジャに相談したいことがあっても自分 で抱え込んでしまいやすい。プロジェクト内のコミュニケーションに“よどみ”を見つけたら、PMOは潤滑油としての機能を発揮してほしい。

金子 啓
マネジメントソリューションズ

 

　プロジェクトマネジャがコミュニケーションのために費やす時間は、総作業時間の70％～90％と言われています。しかし、実際のプロジェクトを考えてみ ると、プロジェクトマネジャとメンバーが十分にコミュニケーションを取れているとは言い難い面があります。1日5分でもプロジェクトマネジャと会話できて いるメンバーは、プロジェクト内に何人いるでしょうか。プロジェクトマネジャと日常的に会話している人、少し距離を取ってしまう人、それぞれだと思います。

　プロジェクトでよくこんな会話を耳にします。「この件について、プロジェクトマネジャはどう考えているのだろうか」とか、「この件は、プロジェクトマネ ジャにレビューしてもらわないとダメだよね」など、プロジェクトマネジャに尋ねてみなければ始まらないような話です。皆さんもそのような会話をした経験、聞いた経験はあるでしょう。

　しかし、口ではいろいろ言っても、なかなか行動に移せないことも多いのではないでしょうか。つまり、「この件は、プロジェクトマネジャにレビューしても らわないと駄目だよね」と口では言っても、実際にはプロジェクトマネジャにレビューをお願いせず、自分だけで判断してしまうようなケースがあるのです。

　改めて理由を言うまでもないでしょうが、一部のメンバーはプロジェクトマネジャに対して、ちょっとした距離（人によってはものすごい距離）を感じています。こんな意見もよく耳にします。

「プロマネから、いつも資料のダメ出しをされる」
「プロマネにレビューしてもらうと、逆に宿題をたくさん出されてしまう」
「プロマネにこんな質問をしたら、相手にされないかも」
「プロマネはいつも忙しくしているから時間が合わないな」
「プロマネにこの件を相談したら、会議が深夜まで続きそう」
「今日、プロマネの機嫌はどうかな」
「プロマネは、存在が偉大過ぎる、怖い」
…

メンバーとプロジェクトマネジャの距離を縮める役割

　このように見られがちなプロジェクトマネジャですが、「経験」「専門知識」は豊富です。メンバーが日々直面するさまざまな課題について、プロジェクトマ ネジャから気軽にアドバイスをもらえたら、どんなにいいでしょう。メンバー全員が、臆することなくプロジェクトマネジャに相談できるなら、それが理想です。

　しかし、現実にうまくいっていないなら、PMOの出番です。気後れしているメンバーがいたら、「プロジェクトマネジャにぶつけて、アドバイスをもらってみませんか？」と背中を押してみましょう。そして、関係者を集めた打ち合わせの場もセッティングしましょう。メンバーとプロジェクトマネジャが一度うまく 会話できれば、きっとそこから先は良い関係が築けると思います。

　もちろん、プロジェクトマネジャは忙しいですから、メンバーが何も考えずに「どうしたらいいでしょうか？」と聞くような相談の仕方を勧めてはいけませ ん。すごく難しい課題であっても、まずメンバーに調べられる範囲で調べてもらい、できれば、ざっくりとでも解決案を考えてもらいましょう。

　その後、「ここまで考えてみたのですが、この先が分からないのです」と相談すれば、プロジェクトマネジャも悪い顔はしません。「過去のプロジェクトでも 似た問題があったから、Aさんに確認してみてあげる」とか、「○○○で解決できるんじゃない？」といったアドバイスを引き出せるのではないでしょうか。

　PMOは、プロジェクトにおける“コミュニケーションの潤滑油”でもあります。「プロジェクトマネジャには声を掛けにくいけど、PMOには気軽に相談できる」という雰囲気を作り出せていれば、プロジェクト内の意思疎通は図れます。それがプロジェクトマネジャとメンバーの距離を縮め、両者が足並みをそろえ るための力となります。PMOが実践すべきファシリテーションについては、「第15回 マネジメントと現場のベクトルを合わせる」でもお伝えしました。併せて参考にしてください。

第27回 必要なら，プロマネに逆らっても「助けて！」と叫べ

体制図上、PMOに対する直接の指揮・命令権限はプロジェクトマネジャにある。とはいえ、PMOはプロジェクトマネジャに絶対服従してしまってもよ いのだろうか。ときにプロジェクトマネジャが機能不全に陥ることもある。そんな時、プロジェクトマネジャをいさめ、プロジェクトマネジャに逆らってでも上位組織に「助けてくれ！」と直訴できるのはPMOしかいない。

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

 

　体制図から考えるとPMOに対する指揮・命令権限はプロジェクトマネジャが持っています。ですから、PMOはプロジェクトマネジャの方針に従うべき組織 です。普段、プロジェクトに何か問題が発生した場合は、プロジェクトマネジャはPMOと共にいろいろな対策を実施します。対策に実現性があり、根本的な原 因に対処できているうちは、これでよいでしょう。

　しかし、プロジェクトが危なくなると、次々に現れる問題にその都度対応するといった“モグラ叩き”のような状況になります。そして、モグラ（問題）の数 が増えると、プロジェクトをゴールに導くことよりも、モグラを叩くことばかりに目を奪われがちです。さらにモグラが増えて、プロジェクトマネジャ、PMO が制御不能に陥ると、プロジェクトの危機が一気に表面化します。

　ここでPMOは、プロジェクトマネジャの命令だからといって、いつまでもモグラ叩きをしていてもよいのでしょうか。問題や課題を制御できなかったことに関しては、PMOにも責任の一端があります。しかし、その半面、PMOはプロジェクトとプロジェクトマネジャの状況を、冷静な目で判断しなければなりません。

プロジェクトマネジャから「助けてくれ！」とは言い出せない

　皆さんも経験があると思いますが、立場や役職が上がれば上がるほど、ほかの人に助けを求めにくくなります。プロジェクトマネジャともなれば、経験もそれ なりに積んできて、プライドもあります。ましてや、自分の評価にもかかわってくるので、プロジェクトマネジャから「助けてくれ！」とはなかなか言い出せません。やっと「助けてくれ！」と言った頃には、すでに時遅し。悲惨な状況になっているケースも多いでしょう。

　PMOはプロジェクトマネジャをサポートする組織ではありますが、プロジェクトが危機に陥ったら、プロジェクトマネジャに代わって「助けてくれ！」と大声で叫ぶ勇気が必要です。プロジェクトマネジャの立場から見ると、PMOに裏切られたように見えるかもしれません。しかし、この勇気は後にプロジェクトマネジャだけでなく、プロジェクト関係者全員を助けることになるのです。

プロジェクトマネジャの暴走を食い止める

　それでは、PMOとして、プロジェクトマネジャの危険信号をどのように見極めればよいでしょうか。筆者の経験上、次の兆候のうち複数があてはまるようだったら要注意です。

（1）プロジェクトメンバーがプロマネの指示に納得していない
（2）指揮系統を無視して、末端の担当者にプロマネが直接指示する
（3）顧客との関係が悪化している
（4）メンバーからプロマネへの不平不満や悪口が噴出している
（5）協力会社に対して無理難題を押し付けている
（6）プロマネが何をしているのか、メンバーが分かっていない
（7）プロマネ一人だけが何日も深夜残業や徹夜をしている

　これらは、プロジェクトマネジャがなんとかプロジェクトを回復させようとして対策を打つものの、周りが見えなくなっていることを示す兆候です。前述した ように、プロジェクトマネジャの内面的な問題により、視野が狭くなってしまうと起こります。放置すれば、メンバーのモチベーションの低下やプロジェクトの混乱を招くことは、容易に想像できると思います。

　一方で、プロジェクトの予算超過や品質悪化、スケジュール遅延についても、悪い兆候として見極めるべきだという意見もあるでしょう。当然、これらの事実にも常に目を向けて、随時対策を実施していかなければなりません。

　ただし、それらはプロジェクトが傾いた「結果」の状態です。これらの問題が起こる前に手を打てるなら、それに越したことはありません。早期に手を打つには、プロジェクトマネジャの危険信号を見逃さないことです。

緊急時のホットラインがプロジェクトを救う

　プロジェクトマネジャをサポートする組織としては、プロジェクトマネジャの上位管理者である「プロジェクト責任者」や、「プロジェクト管理室」などと呼 ばれる横断的な組織（プログラム・マネジメント・オフィス）を設置している会社もあるでしょう。さて、ここであなたに質問します。もし、プロジェクトマネジャが機能不全に陥ってしまったとしたら、PMOであるあなたは何をすべきでしょうか？

　答えはお分かりですね。PMOの役割は、プロジェクトマネジャに代わって、迅速に上位サポート組織へ助けを求めることです。そのためには、普段から、上位サポート組織へのホットラインを確保しておくことが重要になります。間違っても、「プロジェクトマネジャの代わりに、PMOだけで何とかしてやろう」などと考えないように。

第28回 「教訓」の活用・蓄積をいかに促すか（前編）

PMOは教訓を生かしたプロジェクト運営を行い、そこで得た教訓をほかのプロジェクトにフィードバックする責務を負う。しかし、教訓の活用・蓄積が現場に定着しているとは、お世辞にも言いがたい。今回と次回の2回にわたり、この問題に対する具体策を解説する。今回は、教訓の「活用」に焦点を当てる。

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

 

　PMBOKガイド（A Guide to the ProjectManagement Body of Knowledge）には、9つの知識エリア（統合、スコープ、タイム、コスト、品質、人的資源、コミュニケーション、リスク、調達）があります。そのすべての知識エリアにおいて、一貫して述べられていることがあります。

　PMBOKを通読なさった方はお分かりだと思いますが、それは教訓の活用、および教訓の蓄積です。『第21回 プロジェクト運営の「失敗学」』でも解説したように、プロジェクト運営の中でPMOは「良い失敗」から教訓を学び、「悪い失敗」を発生させないという重要な役割を担っています。

　このプロセスの大切さは皆さんご理解なさっていると思いますが、システム開発の現場においては、教訓の活用・蓄積がなかなか定着できていないのが実情で はないでしょうか。「失敗から教訓を学び、蓄積して活用せよ」と一言で言っても、具体的にどうすればいいのか、PMBOKを読んでも具体的な答えは書いて ありません。そこで、今回と次回にわたって、PMOとして何を考え、どのように行動すべきなのかを述べていきたいと思います。

何のために教訓を蓄積するのか

　PMOには進捗管理、課題管理、リスク管理など、プロジェクト運営における重要な仕事が多くあります。PMOがこのようなプロジェクト管理をしっかり行えば、プロジェクトが成功する確率は高くなります。

　しかし、そのプロジェクトが終わり、反省も総括もしなければ、そこで得られた経験や教訓はそのメンバーの個人の中ににしか蓄積されません。あるプロジェ クトで大小さまざまな失敗を経験したとしても、そこでの教訓はほかのプロジェクトには生かされず、当然ながら同じような失敗を繰り返す確率が高くなります。それは、会社全体から見ればとても非効率です。

　PMOのミッションの1つは「プロジェクト関係者の調整を行うこと」ですが、それはプロジェクト内で閉じた話と考えるべきではありません。PMOは、プ ロジェクトをまたがった横断的な活動を行う組織なのです。蓄積された教訓を活用し、得られた教訓をさらに蓄積・昇華していくことは、PMOの一番大きな組 織貢献活動だと言っても過言ではありません。PMOのメンバーが、参画プロジェクトの成功のために貢献するのは当然ですが、「将来のプロジェクトを成功に導くための貢献も必要」という視点で行動できれば、これほど会社にとって素晴らしい組織はありません。

教訓を活用・蓄積する7つのプロセス

　ではPMOとして具体的に、教訓をどうやって蓄積・活用していけばよいのでしょうか。下記の図、「教訓の活用と蓄積のサイクル」をご覧ください。（1）は教訓の活用プロセス、（2）～（7）は教訓の蓄積サイクルを表しています。まずは、教訓の活用プロセスから考えてみましょう。

図●教訓の活用と蓄積サイクル

教訓を「チューニングする」とは？

　組織によっては、教訓がまだ1つも蓄積されていない場合があります。そのような場合は、同じようなプロジェクトを経験したプロジェクトマネジャや有識者からのヒヤリングから始めることになります。教訓や有識者からのヒヤリングを基に、PMOはプロジェクト管理プロセスを改善したり、プロジェクトリスクを抽出してリスク管理表にまとめたりします。

　この時に重要なのは、プロジェクト特性を考慮して教訓やリスクをチューニングすることです。「チューニングをする」とは、参加するプロジェクトにおいて教訓や考えられるリスクをそのプロジェクトに当てはめて考え直してみるという作業です。

　例えば、「プロジェクト開始前までには、該当業務を知っているメンバーを確保すること」という教訓があったとしましょう。あるいは、プロジェクトにおいて「該当業務を熟知しているメンバーがいない」というリスクが抽出されたと仮定します。

　この時のチューニングの要素として、「期間が短く、専門性が非常に高い」というプロジェクト特性があったら、どう考えるべきでしょうか。このケースで は、「該当業務に精通している協力会社を探す」とか、「ユーザーに、プロジェクトへの専任要員を要請する」などがリスクへの対応策になります（厳密には既に発生したリスクと考えられるため、課題とみなされます）。

　もし、チューニングの要素として、「期間が長く、研修を受ければ専門知識を学習できる」というプロジェクト特性の場合はどうでしょうか。「プロジェクト に該当業務を理解するための学習期間を設ける」、または「外部の専門的な研修をメンバーに受講させる」といった対応策になると思います。

書籍や専門サイトにもチューニングのヒントが

　皆さんご承知のように、全く同じプロジェクトというものは存在しません。したがって、蓄積された教訓をほかのプロジェクトに活かすには、プロジェクトの 特性を考慮してカスタマイズすることが必要なのです。チューニングの要素には、プロジェクトの「開発規模」や「業務の難易度」、プロジェクトマネジャの「経験」など、さまざまな要素があります。

　これらのチューニング要素に関して、社内に規定がある場合はそれを使用してください。社内に規定がない場合は、プロジェクトマネジメントを扱っている書籍（ITプロジェクトの「見える化」 上流工程編など）や、ソフトウェア・エンジニアリング・センター（SEC）のWebサイトなどから情報を入手できます。

　しかし、教訓に対してこれらの要素がどのように影響し、どうチューニングすべきなのかは、それこそプロジェクト運営の中で検証を繰り返しながら地道に蓄積する以外に方法がありません。最初は試行錯誤を避けられませんが、その中からもいろいろな教訓が学べるはずです。

　今回は、PMOの立場から教訓をどのように「活用」すべきかを考えてみました。次回は、教訓をどう「蓄積」していくのか、具体的な方法について考えてみたいと思います。

第29回 「教訓」の活用・蓄積をいかに促すか（後編）

教訓を活用・蓄積するための仕組みづくりは、PMOの一番大きな組織貢献活動だと言っても過言ではない。前回は教訓の「活用」に焦点を当てたが、今回は教訓の「蓄積サイクル」にフォーカスする。どうすればこの蓄積サイクルを現場に定着させられるか、PMOの役割を考えてみたい。

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

 

　初めに、前回の復習を簡単にしておきましょう。PMOはプロジェクト運営の中で、「良い失敗」から教訓を学び、「悪い失敗」を発生させないという重要な役割を担っています（詳細は第21回 プロジェクト運営の「失敗学」を参照）。この仕組みを図示したのが、以下の「教訓の活用と蓄積サイクル」です。（1）は教訓を活用するプロセス、（2）～（7）が教訓を蓄積するサイクルを表しています。

図●教訓の活用と蓄積サイクル

　プロジェクトが始まるとまず、PMOは教訓のデータベースからリスクを抽出し、プロジェクト管理プロセスを改善するなどして、その成果物をプロジェクトマネジャに提供します。プロジェクトマネジャは、これらの成果物を基にプロジェクト計画書を作成し、プロジェクトを正式に開始します。これが教訓を活用す るプロセス（1）です。

　ここでPMOとして重要な仕事は、教訓の蓄積サイクルをプロジェクト計画書に明記しておき、「教訓の蓄積サイクルは、非常に重要なプロジェクト管理プロセスだ」ということをメンバーに周知徹底することです。その土壌があってこそ、日々のプロジェクト運営の中で生まれた「改善」、さまざまな問題への対処を 通じて得た「教訓」などを形式知にして残そう、という活動につながります。蓄積サイクルの（2）は、こうした活動そのものと、それを支援するための土壌づ くりを指しています。

予想できなかった失敗から教訓を学ぶ

　教訓蓄積サイクルの（3）と（4）は、リスク管理や課題管理プロセスの中から教訓を抽出・検証する作業を指しています。一般に、プロジェクトの計画フェーズではリスクを洗い出し、リスク管理を実施します。また、実施フェーズの中でリスクを発見すれば、それをリスク管理表に追加し、課題が発生すれば課 題管理表に記入して管理していきます。さらに、リスクが顕在化したら、それを「課題」と捉えて課題管理表に移し、対策を立てて実施します。

　この一連のプロジェクト管理プロセスにおけるPMOの重要な仕事は、「新たに発生したリスクは、計画フェーズで予見可能だったかどうか」を検証することです。検証の結果、予見できなくてもしかたがないリスクの場合は、それを新たに教訓として追加します。

　同様のリスクが教訓として存在していたにもかかわらず、今回リスクとして抽出できなかった場合は、「どうしてそのリスクを事前に予測できなかったのか」 を検証する必要があります。そのような活動を通して、教訓を貯めるだけでなく、「どうすれば教訓を生かせるか」という重要な教訓が蓄積されていくのです。

対応の効果を検証し、整理する

　次にPMOとして重要なタスクは、蓄積サイクル（5）のように、課題に対する対応の実績を整理することです。

　皆さんにお聞きしたいのですが、プロジェクトの課題管理表には課題とその対策、対応方法が記述されているでしょうが、その結果がどうなったか、きちんと 書かれているでしょうか。筆者が経験してきたプロジェクトでは、単に「完了」とだけ記入しているケースが多く見られました。プロジェクトメンバーから見れば、「課題が解決すればそれで完了」という気持ちが強いのはよく理解できます。

　しかし、課題に対応する作業の中にも教訓は潜んでいます。「最初の対応方法が失敗したのはなぜか」とか、「こう対処していれば、もっと短時間で済んだ」 などです。課題管理表に対応結果や気づきがきちんと記述されていれば、そこから教訓を抽出して蓄積できます。PMOは、対応結果から得られる教訓の重要性 を周知して、プロジェクトメンバーをナビゲートする必要があります。

教訓の蓄積はリアルタイムがベスト

　プロジェクトが終了すると、プロジェクトメンバーが集まって「振り返り」を実施し、その内容を含めた完了報告を作成します。これが蓄積サイクル（6）で す。さらに、「振り返り」から新たな教訓を抽出して形式知にするのが蓄積サイクル（7）です。ここで、重要なポイントが2点あります。

　1点目は、「振り返り」の場で話す内容です。この場では、プロジェクトの最中に整理してきた教訓の候補に対して、より本質的な原因を探ったり、より効果的な改善策を検討すべきです。避けてほしいのは、「さぁ、みなさん。プロジェクトを振り返って、教訓を出してください」という問いかけです。メンバーは思 い出すのに時間がかかり、教訓があまり出てこない恐れがあります。しかも、普通のプロジェクトでは、終盤に向かうにしたがってメンバーが減っていきます。振り返り時にはメンバーがほとんど残っていない可能性もあるのです。

　実のある振り返りを実施するには、PMOが中心となってリアルタイムに教訓を蓄積していくべきです。振り返り時には、メンバーが「生の教訓」から「他のプロジェクトに伝えるべき教訓」を導き出せるよう、準備しておくのです。

　2点目は、振り返りに参加するメンバー構成です。協力会社を含めた現場担当者全員に参加してもらいましょう。参加メンバーが多い場合は、プロジェクトを離れる際に教訓になるべきことがなかったかアンケートを行うのも1つの手です。

　なぜ、そうする必要があるのか、理由は簡単です。元請けや一次請けのメンバーのみで振り返りをすると、実際に現場で何が起こっていたのか、詳細を把握できていないケースが多いからです。

　ましてや、元請けのメンバーが「協力会社の管理能力が悪かったので、協力会社の管理能力を事前に厳しくチェックする」といった教訓を挙げてしまうと、単 なる責任転嫁になってしまいます。なぜ協力会社の管理能力が悪かったのか、本当の原因が分かりません。もしかしたら、元請けが仕様変更をコントロールできなかったため、協力会社の管理が混乱してしまったのかもしれません。

　真の原因が分かっていないのに、それを教訓とするのは非常に危険です。教訓を生かそうとする将来のプロジェクトで、かえってリスクを高めてしまう可能性があります。これを避けるには、PMOが中立的な立場で、その教訓の妥当性を厳しくチェックする必要があります。

まずは身近なところから

　前回と今回で、教訓の活用と蓄積のサイクルをどのように運用すべきかを述べてきました。このサイクルを完璧に運用するには、プログラム・マネジメント・ オフィスなどの専属組織を用意しないと、うまく行かないかもしれません。それほど難しいものだと思います。CMMI（能力成熟度モデル統合）なら、レベル 3以上の実力が求められます。

　プロジェクトを完了に導いた後、その成功体験や失敗体験から教訓を導き出し、蓄積し続けていくことは、とても根気と労力がいる仕事です。だからこそ、 PMOが日々のプロジェクト運営の仕組みとして組み込んでしまい、教訓が自動的に溜まっていくようにすることが重要なのです。教訓はプロジェクトの事例が多ければ多いほど多様な教訓が蓄積され、信頼性も高くなっていきます。

　教訓を蓄積していくには、そのメリットを顧客や開発ベンダーの経営者に理解してもらい、協力を仰ぐことも重要です。教訓を蓄積する一連の作業は、PMO が片手間に実施できるほど簡単ではなく、それなりの工数が必要です。短納期・コストダウンの要請が厳しい中で、これらの作業を認めてもらうのは大変だと思います。それでも、「教訓の蓄積は将来への投資である」という点を理解してもらえるよう、努力してみましょう。カイゼンの文化を持つ製造業では、こうした 考え方が当たり前なのですから。

　教訓データベースを整備している組織は、まだまだ限られているのが実情です。まずは、今参加しているプロジェクトから教訓を集めてみて、その教訓を次の プロジェクトの担当者に活用しもらったらどうでしょうか。最初は1つのプロジェクトから始めて、徐々に教訓の輪を広げていけばよいと思います。

第30回 プロジェクト内のあらゆる「無駄つぶし」に注力せよ

PMO（プロジェクトマネジメントオフィス）を「コストセンター」だと思っているプロジェクトは、「プロジェクトマネジメントオフィス」という呼び名を止めるべきである。PMOは、開発/マネジメント・プロセスやコミュニケーションの無駄を省き、結果的に利益を生み出す責務を担っている。プロジェクトの生産性向上に寄与しない仕事には、手を出してはいけない。

田口正剛
マネジメントソリューションズ 取締役

 

　PMOの役割・責任については、これまでに繰り返し述べてきました。しかし、IT業界やプロジェクトマネジメントの世界で確固たるイメージや理想像が存 在するかといえば、答えはノーです。PMBOKガイド（A Guide to the Project ManagementBody of Knowledge）発祥の地である米国でも同じ状況です。

　プロジェクトメンバーもPMOに対していろいろなイメージを持っていることでしょう。あるチームリーダーは、PMOはコストセンターなのだから事務的な 作業はすべてPMOにやってもらおうと思っていたり、チームの作業が逼迫してきた時、PMOが支援するのは当然だと思っていたりします。別のチームリー ダーは、チーム間で調整が必要な課題など、2チームで話し合えば済むような課題もすべてPMOが解決をしてくれるものだと思っているかもしれません。例えば、次のような感じです。

PMO：「Aチームの課題の中に、『Bチームの方針が決まらないと成果物を作成できない』というものがありますね。この課題、もう1カ月もそのままの状態だけど、何かアクションを起こしている？」

Aチームリーダー：「あれっ、PMOは、チームをまたがる課題を解決してくれるのではないのですか？」

PMO：「もちろんそうだけど、チームをまたがるすべての課題を解決することはできません。PMOは全体の課題を把握し、そこで滞っている課題のテコ入れをするけど、チーム同士の打ち合せもしていない状況では支援できませんよ」

Aチームリーダー：「えっ？ それなら、PMOって何のためにいるんですか？」

PMO：「……」

　プロジェクトにPMOを設置してみたものの、PMOは一体どんな役割・責任を担うべき組織なのか曖昧なままプロジェクトを推進してしまうと、上記のような問題が多発します。プロジェクトメンバー1人ひとりがPMOに対して異なるイメージを持っていると、PMOはメンバー全員の期待にはこたえられません。 その結果、PMOに対してさまざまな不満が出てきます。一体、PMOはどうすべきでしょうか。

　PMOにとっては、ここがちょっとした“勝負どころ”です。PMOが強い信念を持っていないと、メンバーの不満を解消しようとして、本来のタスクではない作業にまで手を出したくなるでしょう。

　しかし、PMOは手を出すべきではありません。PMOに余裕がある状況なら許されそうに思われるかもしれませんが、そうではないのです。PMOが本来の タスクの範囲を超えて手助けすると、それを見たメンバーが「この仕事はPMOがやってくれる」と思うようになります。そしてPMOが忙しくなってきても、 同じようにPMOのサポートを求めてくるでしょう。PMOは、プロジェクトの行方を左右するような重要な課題解決に取り組むかたわらで、優先順位がずっと 低い仕事も進めなくてはなりません。こんな状況が続けば、PMOもプロジェクトも崩壊の危機にさらされてしまいます。

PMOの人件費　＜　プロジェクト全体の生産性向上

　本連載第1回の「事務局にあらず、庶務係にあらず」、第4回の「PMOは管理責任を負うのか？」でも述べた通り、PMOの役割は「プロジェクトの生産性を高めること」です。言い換えると「プロジェクトの状況を見える化し、無駄を取り除いて効率的にプロジェクト運営をしていくこと」となります。PMOは決して事務局や庶務係ではなく、コストセンターでもありません。プロジェクトに内在する無駄な工数を削減し、結果としてプロジェクトに利益をもたらす役割を担っています。

　「プロジェクトの予算が厳しいから、PMOは設置できない」と言うプロジェクトマネジャには、こう提案したいと考えています。「PMOを参画させれば、 プロジェクト全体から無駄な工数を削減可能です。PMOがプロジェクトの生産性を高め、予算削減とスケジュール順守につながるからです」。

　例えば、チームリーダーが月に使っているマネジメント工数を全体の5割程度（1日稼働8時間・月160時間稼働の前提で80時間）だと仮定し、そのうち PMOがマネジメント・プロセスの改善（無駄取り）をすることによりリーダーのマネジメント工数を3割削減させた場合、毎月24時間の工数削減になりま す。リーダーの人数が増えるほど削減工数は大きくなるため、マネジメントの役割を担うリーダーが7人を超えたら、単純に1人分のPMOの工数が捻出可能となります。もちろん、無駄取りの効果はリーダーだけでなくメンバーにも影響してきますので、それ以上の効果が見込めるでしょう。

PMOの人数はプロジェクト総人数の8％前後に

　当社がこれまでに手掛けたプロジェクトの実績から、PMOの人数をプロジェクト総人数の8％前後にするのが最もうまくプロジェクトを推進できる割合だと考えています。したがって、プロジェクトメンバーが13人辺りから専任のPMOを設置していくのが良いと言えます。

　具体的にどうやって生産性を高めるかは、過去のコラムで述べたとおりです。さまざまなマネジメント・プロセスを導入・定着させ、無駄な作業を減らすこと によって工数削減につなげます。PMOは当然ながら、自らの人件費を上回るだけの生産性アップを図るため、最も優先度が高い課題の解決に全力を挙げるべき です。

　この感覚がないPMOは認識を改めるべきです。また、PMOを生かすためには、PMO以外のメンバーにもこの認識を持ってもらう必要があります。プロ ジェクトにこういう認識がないと、本来PMOがすべきでないタスクをしないとPMOの評価が下がり、PMOは余計な仕事にばかり手を出してしまいます。そ うなるとプロジェクトマネジメントは負のスパイラルに陥り、プロジェクトの成功から遠ざかっていく恐れがあります。

　第22回の「PMOは火消しの遊軍たれ」で解説したように、本当に問題が起こった時だけ各チームを支援するようにしなければいけません。また、PMOがチームの支援に入ったとしても、あくまで仕事の進め方に問題（無駄）がないかどうかを見つけ、うまく推進していくことを最優先に考えるべきです。

　間違っても、チームの「成果物作成支援要員」になってはいけません。PMOが突然成果物の作成を始めても、その人のバックボーン次第では全く機能しないこともあるでしょう。そればかりか、プロジェクトの遅延をもたらす危険性すらあります。もし、成果物の作成に人手が足りないなら、プロジェクト全体から精 鋭を集めて支援に回すべきです。

PMOの役割をメンバー全員が知っているか？

　PMOが本来のタスクに専念できるようにするには、プロジェクトマネジャ、PMO、チームおよび職階ごとの役割・責任をあらかじめ明確にする必要があり ます。「役割・責任マトリクス」を作成し、プロジェクトマネジャやチームリーダーの合意形成をした上で、それぞれの役割・責任を周知徹底しましょう。

　その役割から逸脱しているチームやメンバーが出た場合などは、PMOが状況を把握し、いち早くプロジェクトマネジャに報告して、しかるべき対応を取る必 要があります。そうした活動を地道に実施していけば、各チーム、各メンバーが正しい方向を理解し、結果としてプロジェクトの成功につながるはずです。