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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高橋信也(たかはししんや)

 1972年福岡生まれ。修猷館高校を卒業した後、上京。上智大学経済学部卒。ゼミは組織論、日本的経営の研究。大学卒業後、アンダーセン コンサルティング(現アクセンチュア)入社。CやC++によるプログラミングから業務設計まで幅広い工程を経験した後、2001年よりキャップジェミニのマネジャとして経営管理・業績管理のコンサルティングプロジェクトに携わる。

 コンサルタントとしての外部の目からだけではなく、内部の目でマネジメントを経験したいとの思いから、SONY Global Solutionsへ入社。その当時、最年少プロジェクトマネジャとなる。グローバルシステム開発プロジェクトのPMOリーダーとして活躍。インドにおけるオフショア開発を経験。

 コンサルテーションから、自社開発のソフトウエア提供、改革実施後のチェンジマネジメントまで、「知恵作りのマネジメント」を支援するマネジメントソリューションズを設立し、現在に至る。連絡先は info@mgmtsol.co.jp