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

第11回 チーム間の「遠慮」を打ち砕く

プロジェクト内の各チームは互いに遠慮している場合が多く、これが対面コミュニケーション不足を引き起こす一因となっている。チーム間の壁を壊し、 対面コミュニケーションを増やすためには、PMOがファシリテーション能力などを発揮する必要がある。それは、コミュニケーションを一変させるほどの効果 を生むかもしれない。

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

 

　プロジェクトを進めていくと、「チーム間の風通しが悪い」「コミュニケーションが取れていない」という問題がしばしば起こります。特に、大規模プロジェ クトでチームが多数存在する場合や複数ベンダーでプロジェクトを進めている場合は、必ずと言っていいほどコミュニケーション不足の問題に直面するのではないでしょうか。

　例えば、ユーザー側で追加要件が発生し、自チームだけでなく他チームにも影響が及ぶ場合、他チームへ影響分析を依頼しなければなりません。このとき、メールで依頼するだけで済ませているケースがよく見受けられます。

　確かに、プロジェクトにはスケジュール・期限がありますので、すばやく追加要件を依頼して、さばいていくことが求められます。また、関係メンバー全員に同じ内容を伝える手段としてメールは有効です。

　ですが、メールだけでは認識のズレ（とそれに伴う品質低下）が発生することを、誰もが経験しているでしょう。会話が少ない“静かな現場”に、不安を覚えるマネジメント層も多いと思います。

本当は対話の必要性を感じているのに、遠慮してしまう

　では、なぜ、メールへの依存体質は改善されないのでしょうか。筆者は、“遠慮”と“面倒”というチームメンバーの気持ちが原因の1つだと考えます。

　先の例では、「この程度の軽い追加要件で、多忙を極める各チームを集めて会議を開催するのは申し訳ない」という遠慮の気持ちが起こりやすいものです。ま た、関係チームが多かったり、他社メンバーと相談したりしなければならないときに、「あまり面識がない他チームのメンバーと打ち合わせるのは煩わしい」という面倒臭さが、心の中でむくむくと頭をもたげてきます。こうした気持ちがメンバーを会議などの対面コミュニケーションから遠ざけ、メールでの伝達で済ま せてしまうのだと思います。

　そこで、1つの打開策として、「PMOが会議をファシリテートする」ことが挙げられます。軽い追加要件であっても、少しでも懸念すべき点があるなら、会議を開催し、資料には書かれていないリスクを共有すべきです。初対面のメンバーとの打ち合わせなどでは、お互い緊張してしまうものですが、PMOが間に 入ってフォローすれば、コミュニケーションを円滑にできるはずです。

　関係チームが多数の場合や作業場所が離れている場合なら、なおさらPMOが会議をアレンジすべきです。会議時間、場所を調整する手間をなくすことで、会議の開催者（追加要件が発生したチームのメンバー）は会議に集中できるようになります。

PMOがお膳立てすれば、コミュニケーションは一変する

　筆者の経験上、会議前は各メンバーとも乗り気ではない場合でも、会議が始まると、いろいろな課題が出てきますし、それに伴い要件の深堀りや精査が進みま す。また、メールでは簡単な質問をしづらいものですが、対面コミュニケーションであれば気軽にできます。確認程度の簡単な質問が、意外と重要だったりするものです。

　会議が終わったときには、「ちょっとしたことでも、関係チームが集まって課題を確認できてよかった」「こういうミーティングをプロジェクトの初期段階か ら、どんどんやっているべきだった」などの言葉を頂いたことがしばしばあります。また、会議後もなかなか自分の席に戻らず、別要件の話を続けている光景を見ると、プロジェクト内のコミュニケーションが不足していたことを痛感すると同時に、ちょっとした工夫でコミュニケーションは一変するのだなと実感しまし た。

　とかくプロジェクトの初期では、チーム間の壁も高く、会議などの対面コミュニケーションを敬遠しがちです。ただ、先に挙げた「この程度の軽い追加要件 で、多忙を極める各チームを集めて会議を開催するのは申し訳ない」とか、「あまり面識がない他チームのメンバーと打ち合わせるのは煩わしい」という感情の裏には、「時間があれば、追加要件の背景など、詳細内容を説明しておいたほうがいいんだが…」「会議は面倒だけど、メールだけで伝わるかどうかは不安だ…」といった思いがあることも見逃してはいけません。

　PMOは、チームメンバーがこのように心の奥で感じている前向きな気持ちを察して、背中を押し、支援することに気を配りましょう。

第12回 作業の「依存関係」を1ページで見せる

各メンバーの日々の進捗を管理するのは「細かすぎ」て管理負荷が高く、マスタースケジュールを基にすると「粗すぎる」。この溝を埋めるために、 PMOが独自の進捗レポートを作成してみてはどうだろうか。その要となる情報は、WBSで定義した作業間の「依存関係」だ。ここだけを抜き出して1ページ で図示すれば、クリティカル・パスを管理するより、はるかに実践的な進捗管理ができるだろう。

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

 

　PMO（プロジェクトマネジメントオフィス）が把握しておくべき進捗状況について、「細かすぎず、粗すぎず」という点が重要なのは、「第7回 進捗報告が形骸化していないか？」 でもお話しました。最も細かな作業というと、個々人で把握している日々の作業ですが、プロジェクト全体の作業を把握するためにそこまで情報収集は行いません。あるメンバーに作業負荷がかかり過ぎている場合などに、日々の作業状況をチェックすることもありますが、通常の進捗把握のためにそこまで行うことはな いでしょう。一般的にはWBS（Work Breakdown Structure）として作成された作業スケジュールに対する進捗だと思います。

　ご存知とは思いますが、WBSを一言で言うと、「実施すべき作業を最小単位にまで分解し、階層化したもの」です。初めにプロジェクトで作成すべきアウトプットから必要な作業を洗い出し、それらを細かく分解していきながら、最終的に構造化していくのです。

　だれにでも分かりやすい例として、「カレーライスを作る」という作業を考えてみましょう。大きな作業単位としては、「1.計画」、「2.買出し」、 「3.調理」と分けられます。次に「1.計画」は、「1.1.レシピ作成」「1.2.材料洗い出し」「1.3.予算作成」と分解できます。さらに 「1.1.レシピ作成」は、「1.1.1.インターネットで検索」「1.1.2.雑誌で調査」「1.1.3.母親へヒアリング」と分解が可能です。ここま でのところを書き出すと、次のようになります。

1.計画
　1.1.レシピ作成
　　　1.1.1.インターネットで検索
　　　1.1.2.雑誌で調査
　　　1.1.3.母親へヒアリング
　1.2.材料の洗い出し
　1.3.予算作成
2.買い出し
3.調理

　「1.1.1.インターネットで検索」をより細かく分解することも可能です。例えば、「どのサイトで、どんな手順で検索するのか」というところまで分解できますし、「レシピを印刷する」という作業を追加できるとは思います。しかし、このケースでは、WBS上でそこまで記述する必要はありません。

プロジェクト全体の進捗に影響する作業は何か？

　ここで、PMOの話に戻りましょう。プロジェクト全体の進捗を把握するためには、「1.1.レシピ作成」の階層レベルが適当なのでしょうか、それとも 「1.1.1.インターネットで検索レベル」が適当なのでしょうか。PMOとして、ときどき判断に悩むことがあります。特に小規模のプロジェクトであれ ば、「1.1.1.」のレベルで把握することはできますが、プロジェクトメンバーが20人以上になってくると、細かすぎて逆によく分からないということも あります。

　「ざっくり、ポイントだけ教えてほしい」というプロジェクトマネジャもいます。その際に、最も粗いスケジュールとして、プロジェクト全体のプランを示したマスタースケジュールを用いて説明すると、今度は「ざっくり過ぎるよ」ということにもなります。

　WBSを用いたスケジュール作成の際に重要な点は、作業ごとの「依存関係」を明確にすることです。前述したカレーライスの例で言うと、「1.1.レシピ 作成」が遅れれば「1.2.材料買い出し」が遅れ、「1.計画」が遅れ、プロジェクト全体の進捗が遅れることにつながります。

　「1.1.1.インターネットで検索」「1.1.2.雑誌で調査」「1.1.3.母親へヒアリング」の3つは、担当者がそれぞれ異なる場合、依存関係はありません。それぞれが同時並行で進みます。

　PMOとして最低限把握すべき進捗状況は、この「依存関係にある作業」の部分です。プロジェクト全体の進捗に影響を与え、時間的に余裕のない一連の作業をクリティカル・パスと呼んだりしますが、システム開発の現場では、しばしば「クリティカル・パスそのものがよく分からない」という問題が起こりやすいも のです。

　クリティカル・パスの把握も重要ですが、作業間、組織間で依存関係にある作業を洗い出し、マスタースケジュールとWBSの間をつなぐ進捗レポートを PMO側で作成することの方が実践的と言えます。この進捗レポートを作る際は、プロジェクト管理ツールやExcelを使用するよりも、 PowerPointのようなプレゼンテーション・ツールを使用した方がビジュアルで分かりやすいでしょう。

　進捗レポートの体裁は、週単位または月単位の進捗状況を１ページのドキュメントとしてまとめます。縦軸に各組織（チームなど）をとり、横軸を時間軸にし ます。その枠の中で、作業間、組織間で依存関係にあるタスクのみを記述します。PMO側でこの資料を作成することにより、全体進捗の把握とマネジメント・ レポートが同時に行えるため、大変効果的です。

第13回 プロマネが言えないことを言う

プロジェクトをブレなく推進するためには、「プロジェクトチャーター（プロジェクト憲章）」や「プロジェクトスコープ記述書」が有効なツールとな る。しかし、これらの名前を知っていても、どのように作成すべき文書なのか、まだ十分に理解されていない。その作成をITベンダーなどに丸投げすると、偏 りのある内容になってしまいがちだ。客観的な立場でプロジェクトを見ることができるPMOには、文書を実のあるものにする、大きな役割がある。

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

 

　システム開発プロジェクトにおいて、詳細設計フェーズ以降、プログラミング、単体・結合テスト、システム・テストなどでは、ほとんどの作業が明確にな り、担当者もほぼ完璧に割り振ることができるでしょう。このため、大きな仕様変更でもない限り、作業の抜け・漏れをほとんどなくすことができます。詳細スケジュールとして作成したWBS（Work BreakdownStructure）はうまく活用され、計画と実績の対比も有効に行えます。

　しかしながら、プロジェクトの立ち上げフェーズや計画段階、またはシステム開発プロジェクトにおける要件定義フェーズなどでは、作成したWBSがすぐに 現実と乖離してしまうでしょう。計画と実績の対比はおろか、担当者の作業の負荷状況も見えにくくなることがよく起こります。当初予定していた作業工数よりも少ないのであれば対応も容易なのですが、ほとんどの場合、予定外の作業が出てきたり、思っていたより調整が難航したりするケースが多いものです。

確固たるスコープは作業のブレを小さくする

　そのような事態に陥らないために、プロジェクトのスコープや前提条件を盛り込んだ「プロジェクトチャーター」や「プロジェクトスコープ記述書」を作成す ることが有効な対策の1つです。プロジェクトチャーターはPMBOK日本語版でプロジェクト憲章と訳されているようですが、「プロジェクトの背景と目的、内容など、これから実施するプロジェクトの定義を明記した文書のこと」であり、「プロジェクト外部でその作成と認可が行われる」とされています。

　ただ実際には、プロジェクトを客観的に定義できる外部の人間が作成するのではなく、プロジェクトマネジャが作成したり、ITベンダーやコンサルタントが作成することが少なくありません。特にコンサルタントやシステム開発を請け負うITベンダーが作成した場合、総花的なプロジェクト憲章やプロジェクトスコープ記述書となり、自社に都合のよい内容になることもしばしばです。

　また、他のプロジェクトとの関連やプロジェクト実施中に発生し得る様々なリスクも加味して作成すべきですが、利害が偏るため、なかなか網羅的な内容になりません。

　PMOは、客観的にプロジェクトの状況を把握する立場として、このプロジェクト憲章およびプロジェクトスコープ記述書の作成に、積極的に関与すべきです。一部のITベンダーでは、プロジェクトの開始前に採算を判断するためのPMOを組織し、収益改善に貢献していますが、プロジェクト憲章の作成段階から PMOが参画することで、プロジェクトを推進していく中でもスコープ調整に貢献することができるようになります。

客観的な視点から率直に意見を出す

　もちろんPMOの役割は、他のチームのようにプロジェクトの成果物を作成することではありませんから、中身にまで突っ込んだ議論ができないジレンマもあります。しかし、ある意味コンサルタント的な役割でプロジェクトにかかわり、客観的な視点で貢献することができるため、プロジェクトマネジャやチームリー ダーとは違った意見を出せるでしょう。

　例えば、想定されるリスクを洗い出す際、プロジェクトマネジャが言いにくいことであっても、PMOの立場であれば言える場合があります。また、コンサルタントやITベンダーの意見を取りまとめ、調整することも可能です。このようなプロジェクト開始当初からのPMOの参画は大変重要であると考えます。

第14回 相談しやすいマネジメント人材の条件

マネジメント・プロセスをいかに洗練させようとも、利害関係や人間関係に内在する問題により、リスクが表に出てこないことが多い。中立的な立場の PMOは、メンバーからの相談を引き受け、その問題の調整役となるべきだ。しかし、PMOのスタッフとして「相談しやすい人」と「相談しにくい人」がいる。

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

 

　「進捗報告では大丈夫と言ったけど、本当はAさんの品質が悪くて危ないんだよな。でも、プロジェクトマネジャのXさんに言っても、『お前が何とかしろ』と言われるだけだし」――。

　いくらマネジメント・プロセスを徹底しようが、いくら進捗報告のレベルを改善しようが、人間関係に内在する問題まで炙り出すことはできません。すべてを正直に報告してしまうと波風が立つので、「大人」の対応をしてしまうこともあるでしょう。

　「ベンダーBは、できもしない“あるべき論”ばっかりなんだけど、うちの上司は気に入っているし、仕方ないか…。会社同士の関係もあるしなぁ」――。

　リスクとして表に出したいことであっても、立場上言えないこともあるのではないでしょうか。リスク会議の場でも、利害関係が絡み合っていると、なかなか本音ベースで話し合うことはできません。

ベテランばかりのPMOは「機能不全」に陥りやすい？！

　このような時、中立的な立場のPMO（プロジェクト・マネジメント・オフィス）が受け皿となり、根回し的な調整を行うと効果的です。しかし、PMOのスタッフ構成によっては、うまく機能しない場合が多々あります。

　プロジェクトメンバーがPMOに相談しにくいパターンとしてよくあるのは、PMOのスタッフがベテランで固められている場合です。特に、社内のプロジェ クトマネジャとして経験の長いスタッフばかりだと、プロジェクトメンバーが相談を持ちかけても、逆に説教されてしまう恐れがあります。また、PMOのス タッフが、いわゆる管理色の強い人だと、相談しても動いてくれないとか、通り一遍の対応しかしてくれないという場合もあります。

　こうした問題が出てくるのも、「PMOとして何をどこまでやるべきか」というPMO自らの立ち位置に、明確な指針が示されていないことが一因だと思います。この連載では、これまでPMOの機能を生かすための事例を紹介しながら指針を述べてきました。

　ただし、いくらPMOの機能や指針が明確になったとしても、その機能を担う人が適切に配置されていなければ、うまく作用しません。では、どのようなスタッフィングを行うべきでしょうか。

「マネジメント経験年数5～10年」「志のある人」が適任

　私はPMOのスタッフィングを考える際、いつも3つの層に分けて考えています。（1）事務局的な役割を担う層、（2）管理プロセスや管理標準を導入する 層、（3）さまざまな問題解決を促進する層です。それぞれの層に対するスタッフィングを考えると、各層の役割が明確になり、どのようなスキルや経験の人が適当か分かりやすくなります。

　「人間関係に内在する問題を調整する」という今回のテーマにおいて重要なのは、問題解決を促進する層に充てるスタッフです。当然、プロジェクトマネジメントの経験者が望ましいことは言うまでもありません。

　しかしながら、前述した通り、経験豊富なスタッフだとプロジェクトメンバーが相談しにくい場合があります。逆に、若すぎて未熟なスタッフだと、アドバイ スを聞き入れてくれないこともあるでしょう。私が最適だと思う人材像は、プロジェクトを客観的な立場で見ることができ、相談もしやすい「マネジメント経験年数5～10年」、年齢で言うと「20代後半から30代くらい」のスタッフです。

　もちろん、そのスタッフの経験内容も考慮すべきですが、将来的にプロジェクトマネジャとしてのスキルを身に付けたい人、プロジェクトマネジメントを極め たいという志を持っている人であれば適任だと思います。プロジェクトマネジャの志願者が少ないという話もよく耳にしますが、PMOという場で経験を積み、 いつかプロジェクトマネジャとして巣立っていくことを願ってやみません。

第15回 マネジメントと現場のベクトルを合わせる

プロジェクトを進めていると、ときおり重要な新要件が出てくるなど、常に状況が変化していく。そんな折、プロジェクトマネジメント層と現場のメン バーの間では、立場の違いなどが原因となって、両者の思考・行動のベクトルが離れていきやすい。ほうっておくと、プロジェクトがバラバラになる。プロジェクト全体のベクトルの方向を合わせ、成功へ導いていくには、PMOの支援が必要とされている。

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

 

チームリーダー：「課題Aについてですが、ユーザー側の意思決定がなされず、進んでいません」

プロジェクトマネジャ：「どうして、課題Aの検討を続けているの？ プロジェクトを左右する新要件が出てきたのだから、それに注力してくれ」

　プロジェクト全体進捗会議で、このような状況を見かけたことがないでしょうか。重要な新要件が出てきて、プロジェクト全体として新要件への対応を急ごう としているというのに、肝心の現場がこれまでの仕事を引きずっていた…、という状況です。プロジェクトは日々変化していきますが、その際、マネジメント層 と現場リーダーの間で進むべき方向性が噛み合わないことは、しばしば起こります。「再三、方向性を示しているのに、現場が付いて来ない」と憤りを感じているマネジャは多いかと思います。

　では、どうして、このようなマネジメント層と現場のギャップが起こるのでしょうか？

視野の違いが行動の違いを生む

　筆者は、組織階層における視野の違いがこのようなギャップをもたらすと感じています。プロジェクトマネジャは、「カットオーバー」を視野に入れて、プロ ジェクトの変化に対してアクション・プランを考えます。一方、現場リーダーは、フェーズなど「数カ月のスパン」で対策を考えています。現場メンバーでは、せいぜい「数週間」くらいの予定で動いているでしょう。開発期間が1年を超えるような規模のプロジェクトになれば、ますますマネジメントと現場のギャップが大きくなります。

　例えば、設計フェーズで出てきた課題について、現場リーダーが開発フェーズまでのスパンでしか対応策を検討していないとしましょう。そうるすと、カット オーバーまで見据えているプロジェクトマネジャから見れば、「場当たり的」な対応策にしか思えません。テスト・移行・運用保守のことまで検討をして、はじめて納得するのではないでしょうか。

　とはいっても、フェーズごとの納品に追われ、実ユーザーとの対応をしている現場としては、最終的なゴールを忘れてしまうことがしばしばあります。

重要な状況変化は、“ワン・ボイス”で伝える場を

　このような状況を打破する1番良い方法は、プロジェクトの要所でマネジメント層と現場の意見交換を行える場を、PMOが随時セッティングすることです。

　先の例のようにプロジェクトを左右する新要件が持ち上がった場合などは、全メンバーを集め、プロジェクトマネジャから対応方針、方向性を明示する場を セッティングすることが重要です。大規模プロジェクトになると、総勢100名以上になりますので、場所や時間などの調整が大変難しいですが、方針転換など 重要事項をストレートに伝えるためには、全メンバーを集めて、プロジェクトマネジャの“ワン・ボイス（one voice）”で発信するのが有効です。

　PMOはこのような場のファシリテーションを行い、マネジメント層、メンバーのベクトルを合わせていくことが重要です。方針転換の各ポイントで、プロジェクトマネジャに提言してみてはいかがでしょうか。

第16回 ドキュメント管理の要はPMOが握れ

　プロジェクトで作成するドキュメントは、メンバーが増え、時間が経つと急激に増えていく。ドキュメント管理規定があっても、周知徹底は意外に難しい。シンプルなルールを定めた上でチームの裁量を認め、ドキュメント管理の要所をPMOが握るようにするとよい。

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

 

「9月3日の役員プレゼンで使った資料はどこにあるの？」

「8月27日の進捗会議の議事録はどこにいれた？」

「プロジェクトの共有フォルダの構成がぐちゃぐちゃじゃない！ 何がどこにあるのか分からないから、分かるように整理してよ！」

　このようにプロジェクトマネジャから突然言われても、一度始まってしまったドキュメント管理の混乱は一朝一夕に収まるものではありません。

“魔窟”と化したドキュメント・フォルダには、手を付けたくない

　本来、プロジェクトで作成する膨大なドキュメントは、ドキュメント管理規定に基づいて分類・管理されていなければなりません。しかし、「ドキュメント管 理規定に書いてあるフォルダ構成やファイル名を守っていないメンバーが悪いんじゃないか」と思い、ずるずると無統制な状態を続けていることが実情なのではないでしょうか。筆者もプロジェクトの中盤でPMOとして参画した場合に、この問題をよく見かけます。正直、腫れ物に触るがごとく、あまり手を付けたくないと思ってしまいます。

　ドキュメント管理規定を作成したとしても、運用するにつれ、実態に合わなくなってしまうことがよく起こります。その原因はいろいろです。当初想定してい たフォルダ構成では足りなくなったりすることもあれば、中間的な成果物を管理するフォルダが増えたりすることもあります。また、体制が変更されたため、そもそもチーム名が変わってしまうなど、プロジェクトの多様な変化の中で規定そのものの順守が難しくなったりしてしまいます。

　自分で作業をしているファイルにもかかわらず、それらがどこに行ったか分からなくなることも、意外にあるものです。それほどドキュメント管理は難しいと 言えるでしょう。ドキュメントを整理するためにグルーピングするフォルダを作っていくのですが、フォルダの階層が深くなりすぎ、まさに魔窟の状態になります。最近はGoogleデスクトップという便利な検索ツールがあるので、自分のパソコン上であれば探せないことはありませんが、プロジェクトで共有しているファイルだと無駄な検索時間を使ってしまいます。

　ファイル管理用のツールを導入することも対策の1つだとは思います。しかし、そもそも莫大に増える電子ファイルを運用するのはプロジェクト管理上の問題です。ツールだけで解決できる問題ではありません。

ドキュメント管理、5つのポイント

　筆者はさまざまなドキュメント管理を見てきた経験上、以下の5つのポイントを踏まえた運用が重要だと考えます。

（1）プロジェクト共有フォルダと各チームのワーキング・フォルダを分ける

（2）プロジェクト共有フォルダへの格納ルールをドキュメント管理規定に盛り込む（何をどのタイミングで格納するのか）

（3）各チームのワーキング・フォルダは各チームの運用に任せる

（4）プロジェクト共有フォルダのフォルダ構成および作成はPMOが行う

（5）フェーズごとに新しいフォルダを切り、必要なファイルだけ移行する

　プロジェクト管理全般に言えることですが、規定は細かすぎたり、複雑であればあるほど運用に耐えられず、結局手戻りが発生し、すべてを見直す羽目になります。

　最近は情報セキュリティも厳しくなってきていますので、セキュリティ上の細かな規定を順守することは義務であり、徹底しやすいかもしれません。しかしな がら、守っても守らなくてもよいルールはなかなか運用がうまくいかないものです。そのためにもルールをシンプルにし、ある程度の裁量をチームに持たせ、プロジェクト管理上しっかり握るべきところをPMOが握っておく、という点が非常に重要だと考えます。

第17回 PMOは変幻自在な“カメレオン”だ

PMO（Project Management Office）の役割は、実態として企業組織やプロジェクトによって大きく異なる。PMOのあり方に悩んでいる現場の方々にすれば、「そんな定義では、 PMOとしてどうしたらいいか分からない」と悩むだろう。しかし、これでいいのだ。PMOとは変幻自在な組織なのである。

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

 

　「PMOは一体、何をどこまで行う組織なのか？」――。

　この疑問に対して明確に答えることのできるプロジェクトマネジャやコンサルタントは数少ないと思います。そもそも明確に定義できるものなのか、と見る方 も多いでしょう。本連載を通してPMOの役割を具体的に示してきましたが、ここでもう一度、PMOの役割について考えてみたいと思います。

「PMOの役割には大きな幅がある」、これが世界の常識

　まず、プロジェクトマネジメントの知識体系であるPMBOKガイド（AGuide to the Project Management Body of Knowledge）は、「PMO」を次のように定義しています。

　「管轄するプロジェクトを集中的にまとめて調整するマネジメント活動の、さまざまな責任が割り当てられた組織体。PMOの責任はプロジェクトマネジメントの支援を提供するところから実際のプロジェクトを直接マネジメントする責任をもつところまで幅がある（PMI、PMBOKガイド　第3版）」

　プロジェクト管理の手法は分かっているものの、「PMOという立場でそれをどのように使っていけばよいのか」「プロジェクトマネジメントやチームのアウトプットに対してどのように手を出してゆけばよいのか」などと悩んでしまうのは、PMOの責任に幅がある（ありすぎる）ところだと思います。PMBOKも それを認めています。

　さらに、PMI（Project ManagementInstitute）が会員向けに出している「プロジェクトマネジメントジャーナル」という季刊誌にも、PMOに関する興味深い調査結果が報告されていました。北米を中心とした500の事例から、さまざまな分析を行っているものです。そこからは、「PMOをどのように生かすか」という課題に対して、多くの 企業が試行錯誤の最中であることが読み取れます。

　この調査結果で最も興味深かったのは、やはり「PMOの構造や役割、妥当性はそれぞれの組織によって大きく異なる」（Project Management Journal Research Quarterly, Volume 38, Number 1,March, 2007）と結論付けていることです。広範な調査に基づいた結果であり、PMOの本質的な特性をうまく言い当てていると感じました。

　一方、日本においては、2000年ごろからシステムインテグレータがこぞってPMOを立ち上げています。日経コンピュータの2004年2月23日号で、その内容が特集されています。ここでは次のような点が指摘されていました。

「問題点を指摘するだけで、後は現場まかせ」
「現場のプロジェクトメンバーから本音が聞けない」
「プロジェクトの状況をレビューする人員が質・量ともに不足」など

　PMOはさまざまな問題をはらんでいるという内容でしたが、PMOの役割が明確でなく、もがいていることの裏返しと見ることもできます。この状況は、今もあまり変わらないのかもしれません。

ならば、臨機応変に自らの役割を変化させていこう

　筆者は、プロジェクトの複雑性や多様性に対応するために、PMOの定義はプロジェクトごとに違っていても構わないと考えています。これはPMIの調査結果と同じです。

　さらに言うならば、筆者は『プロジェクトのフェーズやタイミングに応じて、PMOの役割は異なってしかるべき』とも考えます。例えば、代表的なPMOの役割には次のようなものがありますが、これらをプロジェクトの状況やタイミングに応じて使い分けていくとよいでしょう。

（1）プロジェクトマネジャと同じレベルでマネジメントを実行するPMO
（2）管理プロセスを導入するPMO
（3）プロジェクト運営の事務作業を担うPMO

　仮に、プロジェクトマネジャの負荷が非常に高くなっている状況であれば、PMOが一時的に（1）の役割を担うべきでしょうし、状況が落ち着いてくれば （3）の役割に徹してもいいでしょう。管理プロセスが徹底されていない組織・メンバーなら、プロジェクトを通して（2）の役割を引き受けることも必要で しょう。

　とにかくPMOは、プロジェクトがその時点で抱えている課題に対し、自らの役割を変幻自在に適応させていく“カメレオン”のような存在になるべきと考えます。このようなPMOの活動により、プロジェクトマネジメントはより一層成熟するでしょう。

　では、プロジェクトの「状況変化」に直面した時、PMOは具体的にどんなアクションをとるべきでしょうか。この点については、今後も本連載「PMOを生かす」で述べていきたいと思います。

第18回 PMOの組織も変幻自在

　プロジェクト管理を行う上で雑多な仕事もたくさんある。それらの仕事を片付け、プロジェクトマネジャを支援するのもPMO（Project Management Office）の重要な役割の1つだ。しかし、ベテランのPMOスタッフが、こまごまとした事務作業を受け持つのは、どうにも費用対効果が悪い。そんな 時、プロジェクトに参画している庶務スタッフを巻き込み、PMOスタッフとして組織化するのも1つの手である。

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

 

　「このマスタースケジュール、古くない？ この前のミーティングで設計スケジュールの変更が承認されたはずだけど」

　「もういない人の名前が組織図の中にいつまでも残っているけど、更新してくれない？」

　たくさんの検討会議に出席し、議事録を取り、課題の調整にひた走っていると、一度作ったドキュメントの更新までなかなか手が回らず、古いままになってい ることがよくあります。更新しなくても何とかなると思ってしまったら、優先度が低くなってしまい、手を付けるのが一層遅くなります。これでは、いずれ問題が大きくなります。

　特にプロジェクト共通で使用するドキュメントは、適宜更新しなくてはなりません。新メンバーが参画する際にプロジェクト全体説明のオリエンテーションを 行いますが、ドキュメントの更新を怠っていると、情報が古いまま伝達されてしまいます。小さな問題のようですが、こうしたミスコミュニケーションが積もり積もれば、全体として大きな無駄につながります。

メンバー入出管理などの庶務は「組織図の更新」にもリンク

　ミスコミュニケーションが今後拡大していきそうなら、PMOは早期に対策を考えなけれなければなりません。ただし、だからといってPMOのリードクラス の方が、こまごまとしたドキュメントの更新に時間や労力を割くことは無駄です。外部のコンサルタントを雇い、PMOのサポートを依頼する場合もあります が、この手の機械的な作業に注力してもらっても費用対効果が悪すぎます。

　このようなケースでは、プロジェクトにいる庶務スタッフに協力を求めるとよいでしょう。前回説明したように、PMOは目の前に起こりつつあるプロジェクトマネジメントの課題に対して、変幻自在に対処していくべき組織です。PMOのメンバー構成についても、それは言えます。

　プロジェクトがある程度大きくなれば、プロジェクトの事務・庶務を担当するアシスタント的なスタッフが必要となります。顧客企業側から人を出すこともあ れば、システムインテグレータ側から人を出す場合もあるでしょう。いずれにせよ、この庶務スタッフには、（1）プロジェクトメンバーの入出管理、（2）文 具類などの備品管理、（3）プロジェクトが属する企業内での事務作業（予算管理など）などを依頼することが多いと思います。

　ご覧のように、庶務スタッフの仕事にはプロジェクトに直接かかわらない作業も含まれていますが、例えば冒頭で紹介したような「組織図の更新作業」は、 （1）入出管理と密接に関係していることが分かるでしょう。庶務スタッフと言えども、プロジェクトマネジメントとの接点は少なくないのです。

庶務スタッフをPMOに巻き込め

　この点にもっと注目して、庶務スタッフをPMOのスタッフとして組織化していくことを考えてみてはどうでしょうか。庶務スタッフの本来業務の延長線上にPMOの仕事があるのですから、それほど難しいことではありません。

　その際、庶務スタッフをPMOのスタッフとして正式に位置付け、庶務スタッフに受け持ってほしい役割や日々のルーチンワークを明確に定義することが重要です。プロジェクト全体を見てもらえるよう、意識合わせと動機付けを行うためです。庶務スタッフの意識を高めることで、積極的にプロジェクトマネジメント にも取り組むことができ、プロジェクト共通ドキュメントの更新に限らず、さまざまな役割を担ってもらえるようになると思います。

　庶務スタッフが顧客側から来た人であればコスト負担の調整が必要ですが、庶務スタッフはPMOにとって戦力になり得る存在です。

第19回 “死に体”の運用ルールを蘇生させよ

ドキュメント作成や課題管理に関する各種ガイドライン、運用ルールは作成されているが、うまく運用されていないことが多々ある。PMOは、その導入・定着を推進する“場作り”のために、実行力を発揮しなければならない。

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

 

　プロジェクトの開始直後に、プロジェクト運営にかかわる「ガイドライン」や「運用ルール」を作成することが一般化してきました。「WBS（Work Breakdown Structure）はどのくらいのレベルで記述するか」とか、「課題の管理項目はこれとこれ」など、さまざまな決め事のことです。これも、PMBOKガ イド（A Guide to the Project ManagementBody of Knowledge）が普及してきたことの表れでしょう。

　しかし、なかなか運用が軌道に乗らず、「仏作って魂入れず」という状態に頭を悩ましているマネジャは多いのではないでしょうか。例を挙げれば、次のような問題が起こりがちです。

（1）WBSが最新状態に更新されない
（2）課題管理フォーマットがチームごとにバラバラになっている
（3）課題管理表に課題以外のToDoなどが混ざっている
（4）リスク管理表が更新されない
（5）定例会議の参加者が減ってくる

　プロジェクトの開始直後は、ガイドライン通りに運用しているかもしれません。ところが、徐々に陳腐化してきたり、チームごとに独自の方法で運用し始めたりするケースが多々見受けられます。一体、何が悪かったのでしょうか。

現場がルールを守らないワケ

　原因の1つに、ガイドラインや運用ルールが硬直的になっていることが考えられます。ガイドラインを改善するための更新フローがなかったため、各チームの判断で勝手にカスタマイズして運用してしまうのです。

　例えば、課題管理表のフォーマットについて、「担当」欄をシステム側担当者とユーザー側担当者の2つに分けたいという要望があるチームで出てきたとしましょう。そのチームでは、「これくらいの変更なら問題ないだろう」とか、「そもそも誰に変更要望を知らせるべきか分からない。まぁいいか」と考えてしまい やすい。これが原因で課題管理フォーマットのカスタマイズが起こるわけです。
　こうしたカスタマイズがチーム内だけに閉じたものならまだいいのですが、大抵はプロジェクトマネジメントや他のチームに影響を及ぼしてしまいます。プロジェクトマネジメント側は、課題リストからいろいろな集計作業を行っているはずです。課題管理表に対する小さな変更であっても、それらの集計作業に影響を 及ぼすでしょう。

「改善」をしつこく、楽しく

　プロジェクトの状況は日々変化しますので、ガイドラインや運営ルールについても適宜改善が求められます。改善を怠ると、すぐ陳腐化、形骸化が始まりま す。PMOが更新フローについて明確化し、また各チームの状況をヒアリングし、その都度ガイドラインの見直しを実施することが必要です。特に次フェーズへの準備として、ガイドラインの更改を行うことは必須であると考えます。

　プロジェクト運営ルールの徹底は一朝一夕ではいきませんので、PMOが主体的に運用・定着化を実践していくことが大切です。ガイドラインを作成して終わりではなく、実行段階における各チームへのフォローアップが欠かせません。

　運用ルールを定着させる中でルールの陳腐化が発見されたら、従来とは違う方法を試してみるなど、迅速に手を打つべきです。また、成果が出るまで改善を続ける「しつこさ」が必要だと感じています。

　さらに、「変えようとするカルチャー」を大切に育み、「改善のプロセス」を楽しくして、自立的な改善サイクルを確立していくことが何より必要でしょう。このサイクルの中心にいるべき存在は、もちろんPMOです。

第20回 「危機意識」がユーザーを突き動かす

ステークホルダーをプロジェクトに巻き込むことは、昔も今も容易ではない。うまく巻き込めないと、プロジェクトを崩壊に導く“爆弾”にもなり得る。 特効薬はないが、ステークホルダーを突き動かせるものがあるとすれば、それは「危機意識」にほかならない。PMOらしいやり方で、ステークホルダーに訴求 するとよい。

松永幸大
マネジメントソリューションズ マネージャー

 

　「システム開発が期限通りに終わり、不具合の修正も終わっていること」――。あなたが関与するプロジェクトでも、システム開発の計画書には「ユーザーテスト・フェーズ終了時の前提条件」として上記のような文言が記載されていることでしょう。スケジュールや品質、コスト（予算）についての前提条件は、多く の計画書で明示されていると思います。

　しかし、「分かっているけれど言えない前提条件」、さらには「意識されていない前提条件」というものも存在します。例えば次のようなものがあります。

「ユーザーテストでは、ユーザーがテストに十分な時間を割り当て、積極的にテストを行うこと。また、ユーザーが新業務を理解していること」

「プロジェクトオーナーはプロジェクトの課題に対して、タイムリに判断・助言を与えること」

「ライン部門のマネジャは、プロジェクトに積極的に協力すること」

　いずれも、ユーザーがプロジェクトに積極参加することを前提条件としたものです。いわゆる「ユーザー（ステークホルダー）の巻き込み」に関することで、 今も昔もトラブルを起こしやすい、やっかいな問題です。場合によっては、これがプロジェクトを崩壊に導く“爆弾”となり得ることを、多くの読者は実感され ていることでしょう。

　本来、上記のような前提条件を担保する責任を負うのがプロジェクトオーナーやプロジェクトスポンサーなどの上位管理者であるべきですが、なかなかうまく 動いてもらえないのが実情でしょう。そして、前提条件が崩壊し、プロジェクトが立ち行かなくなると、プロジェクトマネジャに責任を転嫁しがちです。「あのプロジェクトマネジャは関係者をしっかり巻き込めない。リーダーシップやコミュニケーション能力がない」と。

ステークホルダーに危機意識を！

　こういった事態に陥らないためにも、ステークホルダーとのコミュニケーションを取り、当たり前すぎて言えない前提事項についても、きちんと合意すること が重要です。プロジェクトのリスクを減らすには、基本的なステップを一歩ずつ踏んでいく以外に方法がありません。ステークホルダーが一堂に会するステアリングコミッティを通して、定期的な報告と協力要請をしましょう。また、プロジェクト説明会では、プロジェクト目標などの浸透、個別の打ち合わせ、交渉など を積み重ねていく必要があります。

　ユーザーを巻き込むために、コミュニケーションを通して伝え続けるべきメッセージはたった1つ。ステークホルダーに当事者意識を持ってもらうことです。言い換えれば危機意識を持ってもらうことです。「このプロジェクトがうまくいくと自分にこんなメリットがあり、失敗するとこんなデメリットがある」という ことを強く意識してもらうことです。組織として、個人として危機意識を持ってもらうことで、協力関係はより強固なものになっていくことでしょう。

　とはいっても、「このプロジェクトが失敗すると、オーナーである事業部長は私と一緒に責任を取ることになりますよ」などと言うのは得策ではありません。 あくまでも上位管理者との関係は良好に保ちつつ、「現場は、もう崩壊寸前です」といったアラートを的確に出し、危機意識を持ってもらうことが大切です。

客観的・論理的な情報に“生っぽさ”を合わせる

　こうした声掛けは当然プロジェクトマネジャもしますが、PMOも、PMOらしい方法で声掛けして、プロジェクトマネジャを支援しなければなりません。「プロジェクト状況を客観的に把握し、論理的に説明できる」という立場から、ステークホルダーたちに訴求するのです。

　ただし、気を付けてほしいこともあります。多くのプロジェクトでは、プロジェクト進捗や課題対応状況のレポートを「客観的・論理的」に作成していると思 います。定期報告ではその「客観的・論理的」な形式が必要とされるわけですが、「ユーザーを巻き込みたい」と思う場面においては訴求力が足りません。「客観的・論理的」なレポートにはプロジェクトの“生っぽさ”や“臨場感”がなく、ステアリングコミッティの場で報告しても、切迫した現場の雰囲気がほとんど伝わらないからです。

　そこで、客観的・論理的な情報に“生っぽさ”を合わせるのです。相乗効果により、非常に強い訴求力を生み出します。普段から現場の声を聞きまわっている PMOが「現場が崩壊しそう」といったシグナルを察知したら、これまでにもあるような客観的・論理的な情報と合わせてステークホルダーに強く訴えるのです。

　ステークホルダーは、いつもと同じ体裁の報告書を見ていながらも、頭の中には現場の窮状が浮かんでくるはずです。これにより、「現場」～「プロジェクト マネジメント・チーム」～「ステークホルダー」の橋渡しができ、ステークホルダーに当事者意識、危機意識を持ってもらうことが可能となります。

　もし、PMOに協力会社のメンバーが参画しているなら、そのメンバーにプロジェクトの状況を解説してもらう場を設けるのも手です。組織内のしがらみのた め、思い切ったことを言えないプロジェクトマネジャの良き代弁者となってくれるでしょう。プロジェクトマネジャとPMOが一体となることで、ステークホル ダーを巻き込んだプロジェクト運営が可能となります。