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

第71回 「負けるが勝ち」のマネジメント

プロジェクトをマネジメントする立場にいる者は、メンバーとの接し方を一歩間違えると、現場から強い反発を受けて孤立してしまう。最悪なパターンの 一つは、地位の高さや経験の豊富さを武器に、メンバーを常にやりこめてしまうこと。これが感情的な対立に発展すると、プロジェクトの成功はおぼつかない。

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

 

　「PMOを生かす」のコラムの中で筆者が一貫して述べていることは、「プロジェクトのメンバーが気持ちよく作業ができる環境を作ること」がPMO（プロ ジェクトマネジメントオフィス）の一番の任務だということです。ここで言う環境とは、仕組みや運用ルールだけでなく、「メンバーが気持ちよく」作業ができる雰囲気や気持ちも当然含みます。

勝ってばかりいると相談されなくなる

　PMOとしては、ときとしてメンバーに対して耳が痛くなるような嫌なことも言わなければなりません。そんなときでも、PMOとメンバーの意見が対立したときには、「相手にいつも勝っていてはNGだ」と考えることが重要です。

　筆者の実体験を話します。進捗会議で「なぜ、遅延しているんだ！」「そのキャッチアッププランで本当に追いつけるのか？」「遅延している原因は正しいのか？」など、メンバーを追い詰め過ぎてしまったことがあります。次の進捗会議からは、不都合な情報が隠されてしまい、重要な情報が上がってこなくなりまし た。

　このときのメンバーは、個人の能力がないと批判されているように捉えてしまったようです。筆者にそんなつもりは毛頭なかったのですが、結果的にはPMOに対して「敵意」を抱かれかねない状況でした。

　PMOという仕事柄、どうしても「好かれる」立場にはありませんが、「敵意」を抱かれたら大変です。プロジェクトに必要な情報が隠されてしまうだけでなく、プロジェクト内に「感情の対立」が生まれ、雰囲気が悪くなってしまいます。

PMOは「2勝3敗」ぐらいがちょうどいい

　プロジェクトには当然様々な「対立」が発生します。一般的なプロジェクトマネジメントの教科書には、「対立」は「きちんと表面化させて解決しましょう」とあります。プロジェクト上必要なコストや品質、進捗、優先順位などの決定事項が対立する際には、確かに教科書通りに「対立」をあぶり出し、しっかりとマ ネージメントすることが必要です。
　しかし、これが「感情の対立」に発展してしまうとプロジェクトのコミュニケーションが分断されてしまい、プロジェクトが傾く大きな原因となってしまいます。特にPMOとメンバーが対立した場合には「感情の対立」に発展しかねない大きな落とし穴があります。

　PMOとメンバーそれぞれの地位や経験は、大体において「PMO＞メンバー」となることが多いのではないでしょうか。すると、どういうことが起きるかは、皆さん想像がつくと思います。そう、意見が対立したとき、PMOの意見がいつも勝ってしまうのです。そのような状況が続くと、当然メンバーの心には不満がたまっていき、「どうせ何を考えてもPMOの言う通りにするんでしょ」という気持ちがメンバーにわいてきます。

　これはメンバーの主体性を奪うことになり、ひいては「言われたことを言われたままやる」といった事態を引き起こしかねません。もしそうなってしまったら、「プロジェクトのメンバーが気持ちよく作業できる環境」かどうかは改めて言うまでもないでしょう。また、メンバーがPMOにどんな感情を抱いているかは察しがつくと思います。

　上記の話も、実は筆者がまだPMOとして駆け出しだった頃の失敗談です。筆者がこの失敗から学んだことは、「PMOとして負けてあげる」ことの重要性です。負けてあげるとは、相手の意見を十分に尊重する、相手の意見を基にして考えを発展させる、ということです。

　メンバーは「プロジェクトの成功」という共通目標を持っています。対立が起こるのは、目標を達成するための「前提事項」や「進め方」が対立するためです。PMOには「いままでこのやり方で成功してきたのだから、次もこうするべきだ」という考えがあるかもしれません。しかし、たまには相手の意見を受け入れるだけの余裕を持っておくことも大切なのです。経験から言うと、「2勝3敗」ぐらいがちょうどよいのではないでしょうか。

LOSE But Finally WIN

　ただし、ここで注意が必要なのは「譲れないところは、決して譲ってはいけない」ということ。プロジェクトの成功という共通の目的に対して、PMOとして「ここだけは譲れない」という場面が必ず出てくると思います。

　例えば「品質が第一」と考えて進められているプロジェクトで、進捗の遅れが目立ち始めたとします。そこで遅れを取り戻すために、あるメンバーが「品質を 担保するための工数を減らしたい」と主張してきても、PMOは突っぱねなければなりません。ここは「勝ち」にこだわるべきところです。

　ただ、いざというときに勝っても、不満を残さないようにするためには、普段の対立において譲れるところは譲り、気持ちの上で“貸し”を作っておくので す。よく、WIN-WINの関係を作りましょうと言われますが、ことPMOにいたっては「LOSE　ButFinally　WIN」（負けても、最後に勝つ＝プロジェクトが成功する）という心づもりが必要なのではないでしょうか。PMOがメンバーと（感情的 に）張り合っても、何の得にもなりませんから。

メンバーの特性に応じたマネジメント

　PMOがメンバーとの「感情的な対立」を起こさないためのポイントとしては、画一的なマネジメントを強制しないことが挙げられます。プロジェクトルールとして最低限守らなければならないことは別として、各メンバーに応じたマネジメントができるように、ある程度の柔軟性を持たせてあげることが重要です。

　例えば、進捗の遅れが発生したときに、あるリーダーは「PMOと一緒になって遅れを挽回するためのプランを考えたい。PMOに原因を分析してほしい」と 考えているかもしれません。また別のリーダーは、「チーム内の進捗にいちいち口を出してほしくない。リーダーとして責任を持ってキャッチアップするから、結果だけ見ていてほしい」と考えているかもしれません。

　前者の場合であれば、PMOは積極的に関与してリードしていきます。後者の場合は、経過を観察してキャッチアップの傾向がみられれば、そのまま状況だけ観察していきます。もちろん、何週間も改善が見られない場合はPMOとして介入しますが、最初から介入するのと、任せた結果を見てから介入するのとでは、リーダーの納得感が全然違います。

状況に応じて対立マネジメント

　今回はPMOとメンバーの対立を中心に記載しましたが、状況によってはいろいろな対立をマネジメントしなければなりません。アプリケーションチームと技術チームの対立であれば「第35回 アプリvs.インフラ、担当者はなぜ分かり合えない？」を参考にしてみてはどうでしょうか。プロジェクトマネジャや上位マネジメント層が関係する対立であれば、「第27回 必要なら、プロマネに逆らっても「助けて！」と叫べ」や「第31回 プロジェクトマネジャはPMOの良き理解者に」も参考になると思います。

　すべてに共通することは、相互の信頼をベースにしたコミュニケーションが必要がということです。そのためにも、PMOは日ごろから関係者との良い信頼関係を築いていきたいものです。

第72回 木を見て森を見ても、まだ足りない何か

プロジェクトマネジャやPMOにとって、一人ひとりのメンバーの状況とプロジェクトの大局的な状況を見ること、つまり“木を見て、森も見る”という 視点を持つことが重要だ――。筆者は数多くのプロジェクトをこなしている中で、いつもこう考えてプロジェクトを推進してきた。しかし、どれだけ注意していても、どうしてもうまく行かない事象に何度も直面した。その時に思い知ったのは、“木を見て、森も見る”だけでは、まだ何かが足りないということである。

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

 

　大局的にプロジェクトを俯瞰し、細かい点までプロジェクト運営に注意を払っても、同じような問題が竹の子のように何度も出てくることがあります。そういう時、原因を追究していくと、大体は人の問題に行き着きます。しかし、さらに「なぜ、その人がそのような失敗をしたのか？」と追求していくと、最終的には 環境の問題に突き当たることが少なくありません。

　実例を挙げましょう。あるプロジェクトで、プログラミングのミスが多発しました。その原因が担当者の不注意やコーディングレビュー不足であることは容易に想像できましたが、なぜそうした不注意や不十分なレビューが起こったのかを追求してみました。

　たどり着いた結果は、「担当者が他のプロジェクトと掛け持ちをしていて残業が続き、注意を欠いていた」ということでした。また、レビューで適切な指摘ができなくてもレビューワーは何の責任も取らなくてよいので、「真剣に集中してレビューしていなかった」という事実が判明しました。つまり、プログラミング ミスが起きやすい環境ができていたのです。

　「木を見て、森も見る。さらにはその環境も考える」。これが上記の経験から学んだ教訓でした。

マネジメントに行き詰まったら、環境を見直してみよう

　別の角度から見ると、「木や森は、環境に合わせ育つ」とも言えるでしょう。例えば、「開発期間は短いが、納期は絶対順守」という環境であれば、その環境に合わせたマスタースケジュールや全体計画（森）、各メンバーの作業計画やWBS（木）が作られます。ここでどんなにプロジェクトの全体をコントロールしようと努力し、各個人の細かい作業にまで目配せしても、そもそもの環境が厳しければ、その環境に沿った問題が発生するということなのです。

　ここまで述べてきたように、同じような問題が何度も発生する場合、「環境を変えること」が根本的な解決につながることがあります。もちろん、一言で「環境を変える」といっても、プロジェクトの前提になっているような条件は変更できません。変更可能な環境要素を探り、改善していくしかありません。

　プロジェクト内で一般的に利用できる手段としては、悪い環境を矯正したり、悪い環境からの影響を緩和したりするための「仕組み化・ルール化」を考えてみるとよいでしょう。

目の前にある環境は、良い木を育み、良い森を作れるか？

　冒頭のプログラミングミスが多発した例で考えてみます。まず、プロジェクトを掛け持ちする場合なら、一定期間は1つのプロジェクトに集中できるように取 り決め、その期間は「ほかのプロジェクトからの問い合せは禁止」というルールを設定してみてはどうでしょうか。また、同じミスを繰り返さないために、一度起こったミスはチェックリスト化して、必ずセルフチェックするような仕組み作りが考えられるでしょう。

　レビューの精度を上げる問題については、プログラムミスが判明した場合の責任をレビューワーが取り、同じようなミスの再発防止策を必ず立てさせ、発表させるというルールを作ったり、各レビューワーのレビュー状況を調べて、適切な指摘ができているかを可視化する仕組みを作ったりすることが考えられます。い ずれも、レビューワーが真剣に取り組まざるを得なくなる心理的なプレッシャーとして作用するはずです。

　このようにプロジェクトをマネジメントする際の視点として、今までよりもう一段高いところから見渡し、プロジェクトが置かれた環境にも目を向けることが大切です。目の前にある環境が良い木を育み、良い森を作れるのかどうか、いま一度考え直してみてはいかがでしょうか。これまで手を焼いていたような問題に 対して、違ったアプローチを導き出せるかもしれません。

第73回 マネジメントメンバーの育成は「愛のつぶやき」と「ぶれない軸」で

プロジェクトマネジメントの人材育成では、上司から部下へどんなメッセージを伝えていけばよいだろうか。私見を述べれば、決してぶれることのない行 動原則を繰り返し伝え、自発的な行動を促すための「愛のつぶやき（ぼやき？）」をしつつ、「見守っているよ」というメッセージを送り続けることだ。その底辺にあるのは信頼関係にほかならない。

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

 

　プロジェクトマネジメントの人材育成には、いろいろな考え方や方法があります。今回は、筆者が実際に部下を育てた経験を踏まえながら、プロジェクトマネジメント人材をどのように育てていくのかをさまざまな観点から考えてみたいと思います。賛否両論あるでしょうが、プロジェクトマネジメントができる人材を 育てる上での参考にしていただければ幸いです。

マネジメントチームとしての心得を伝える

　私はPMO（プロジェクトマネジメントオフィス）のリーダーとして、私に初めて付く部下には、最初に必ずPMOの目的や存在意義を徹底的に教え込みます。主に3つのポイントがあります。

　1つめは、「PMOの一番の役割はプロジェクトメンバーが気持ちよく作業をできる環境を作ること」。これはPMOメンバーとしての行動原則の1つです。その理由は、このコラムで何度も書いている通りです。

　2つめは、「PMOの仕事はWBS（Work Breakdown Structure）にすべて記載されているわけではなく、自ら問題を探し出して解決していくことも仕事だ」ということ。この話は、特にシステムエンジニア（SE）やプログラマーの仕事しか経験したことがない部下に言っています。SEやプログラマーは、WBSに基づいてスケジュール通りに所定の作業を完了 させることが主な仕事ですが、プロジェクトマネジメントの仕事ではその考えを捨ててほしいからです。

　3つめは、特にコンサルタント経験者などに対して言うのですが、「PMOは組織としての機能であり、決して個人技ではない」ということ。つまり、お互いがカバーしあいながら、PMOの機能を提供し続けなければならないという意味です。

　次に話す点としては、「このプロジェクトを通して、PMOとして何をどこまでできるようになりたいか」を部下と納得いくまで話し合います。例えば、「進 捗会議を独力でファシリテートできるようになる」だとか、「プロジェクトのリスク管理について、リスクの洗い出しから予防策・対応策の立案、モニタリングまで、関係者を巻き込みながら推進できるようになる」といった具体的な目標を確認します。

問いかけ続ける「プロジェクトの目的は？」という行動原則

　PMOメンバーとしての最初の指導は上記のようなことですが、実際に部下がPMOとしての業務をある程度まわせるようになってきたら、次はプロジェクトの目的を徹底的に意識させています。様々なタイミングで、「このプロジェクトの目的は何だっけ？」とメンバーに問いかけるのです。

　なぜかというと、ある程度仕事を回せるようになると、自分で仕事に対していろいろなアレンジをしてみたり、自分独自のやり方で問題を解決しようとするからです。その行為自体には、もちろん何の問題もありません。ただし、ときに手段が目的化してしまい、プロジェクトの目的から外れてしまう事態が起こりま す。

　そんな時、「このプロジェクトの目的は何だっけ？」と問いかけ、今のやり方や成果物が本当にプロジェクトの目的達成に役立つのかを意識させるようにしています。この問いかけを繰り返し聞かされると、PMOメンバーはプロジェクトの目的と自らの作業を常に照らし合わせ、最適な選択をできるようになっていきます。常に「プロジェクトの目的達成（成功）」を目指すのも、PMOメンバーとしての行動原則の1つと言えます。

あなたは、部下のやり方を認め、我慢して見守ることができるか

　プロジェクトマネジメント人材の育成は、どうしてもOJT（On theJob Training）が基本になります。その際に私が人材育成で気をつけているのは次のような点です。

（1）自分のマネジメントスタイルを押し付けない
（2）我慢して見守る。多少失敗してもやらせる
（3）部下との定期的な認識合わせ

　（1）については、自分の成功体験を押し付けたりせず、できるだけメンバーのそれぞれのやり方を尊重しています。「マネジメントのスタイルに画一的な正解はない」というのが私の考えです。

　したがって、彼や彼女なりのマネジメントの仕方を身に付けられるよう、サポート役に徹します。何か問題が起こったときでも、「私がその状況の時は、こう やって解決したことがあった」と、あくまで自分の経験を語るだけのスタンスを心がけています。もちろん、純粋に「このようにやりたいのですが、どう思いますか？」というような相談を受けた時は、より踏み込んで相談に乗るべきなのは言うまでもありません。

　（2）の「我慢して見守る。多少失敗してもやらせる」というのはPMOだけの話ではありませんが、やはり重要です。一度任せたら、多少危なかしくても口出しせずに見守る、ということです。

　筆者が駆け出しのころ、上司から箸の上げ下ろしにまで口出しをされて、とてもやりづらい経験をしたことがあります。これでは部下が伸びません。そうでは なくて、多少失敗しても、失敗から何かを学ばせるぐらいの心持ちで部下を見守っていくのが、部下の成長を促す一番の栄養ではないか思います（とはいえ、我慢できずについ口を出してしまい、後悔することが今でもありますが）。

　（3）の「部下との定期的な認識合わせ」は、（2）と関係があります。私には、多少失敗したとしても部下に経験を積んでもらいたい、という思いがあります。しかし、部下からすれば「自分がこんなに困っているのに、この上司は何も助けてくれない！」という風に不満を抱いているかもしれません。

　そのような感情が起こらないように、部下と定期的な認識合わせをするのです。「私は助けてやりたいが、あなたの教育のためにわざと突き放すこともある。 本当にダメだと思ったらいつでも全力で助けるから、その時は遠慮なく頼ってくれ」と定期的に伝えるようにしています。こう伝えることで、「独力でできるところまでは頑張ってみよう」というモチベーションを持って仕事に打ち込んでもらえたんだと考えています。

愛のつぶやき大作戦

　さて、「我慢して見守る」とは言いましたが、重要な業務など「決して失敗してはいけない場面」には必ず遭遇します。また、「あと少し工夫すれば成功できる」という場面もあるでしょう。そんな時によく使うのは『愛のつぶやき大作戦』です。

　これは元プロ野球チーム監督である野村克也氏の「ぼやき」に似ています。わざと本人に聞こえるように独り言を言って、気付きを与えるという作戦です。例 えば、「このチームからの報告って嘘が多いよなぁ。コミュニケーションとってんのかねぇ」とか、「最近、この機能からの不具合がなんでこんなに多いんだろ」というような具合です。

　最初は、「こいつ、よくぶつぶつ独り言をいうやつだなぁ」と部下に思われるだけかもしれません。しかし、しばらくすると私の「独り言」が遠まわしな「ア ドバイス」なのだと気付くようになります。こちらとしてはあくまで独り言なので、部下がそれを受け入れるか、受け入れないかは部下の自由です。とはいえ、大体において何かしら作用したのではないかと感じています。

部下から「気付き」をもらう

　実際に私が携わったプロジェクトで、これまで述べてきたようなやり方で当時20代の若手メンバーを育てたことがあります。その時に、当の部下たちにアンケートをとったことがありますので、その時のコメントを紹介しておきたいと思います。

Q1：仕事の上で自分が何をすべきか、明確に役割がわかっていましたか？

　⇒はい。現場に近い側でチームリーダーをサポートしつつ、管理ルールをプロジェクト内に定着化していく役割を理解していました。

Q2：自分の業務を実施するために上司から適切なアドバイスやサポートを受けることができましたか？

　⇒はい。アドバイスやサポートが無いと感じたことはありませんでした。一つの場面としてアドバイスやサポートが無いことはありましたが、それは自身の育成のためと理解していました。PMOメンバーに作業を割り当て、とりあず一度考えさせて、困った時に手を差し伸べるというやり方には賛成です。ただ、レビューの都度、方針に対する意見が変わってしまうのは困りました。

Q3：自分の考えや意見を尊重してもらえましたか？

　⇒基本的にはそうでした。一部違う考えはありましたが、腹落ちした上で行動していました。

Q4：自分が経験したい仕事をさせてもらえましたか？　また、自分の仕事に納得していましたか？

　⇒基本的にはそう思います。ただし、本当に事務的な作業については、事務要員を別途追加してほしかった。

Q5：PMOという仕事のOJTを通じて自分が成長できたと感じますか？

　⇒はい。今回のプロジェクトで初めて真にPMOという仕事ができ、いろいろ経験できました。得るものが多く、勉強することもたくさんあって、モチベーションを高く保てました。しかし、難しい仕事を割り振られて忙しい時に、上司の「暇だなぁ～」の一言にモチベーションが下がることもありました(注：教育 の一環として、あえて少し難しい仕事を若手メンバーに任せたとき、私は自分の仕事が減ったため「暇だなぁ～」と失言してしまったようです)。

　アンケートのコメントにもあるように、まだまだ私自身もPMOメンバーの育成について勉強不足なところがたくさんあります。部下への育成を通じて、実は自分の方が部下に教えてもらったり、気付きをもらったりすることがたくさんあります。

部下との信頼関係、上司としての「ぶれない軸」

　このようにお互いに学ぶことができるような関係になるためには、部下の考えを一度は素直に受け入れることが重要です。そして、素直に受け入れるためには、普段からの信頼関係が不可欠です。

　なぜなら、なんら信頼関係のない間柄では、決してその人の声は相手の心には届かないからです。そもそも相手に対して、特に上司に対して「自分の意見は届 かない」と分かっていたら、自分の意見を言おうなんて思いもしません。そういう意味で、一番重要なことは上下関係や立場に関係なく、言いづらいことでも部下がきちんと進言し、上司がそれを受け入れられる信頼関係を、普段から築いていることではないでしょうか。

　部下を育てるためにも、上司は自分の今までの成功体験を押し付けるのではなく、こうあるべきだという固定的な考えや自分のプライドにとらわれない議論を部下と一緒にしてみるといいでしょう。

　もちろん、部下から一度受け入れた意見をそのまま鵜呑みにするのではなく、部下がより高い視点から物事を見られるように上司はサポートすべきです。その 議論の中では、『PMOの一番の役割はプロジェクトメンバーが気持ちよく作業をできる環境を作ること』といった「ぶれない軸」が必要不可欠です。上司としては、当然ながら「自分のぶれない軸」を持っていなければなりません。

第74回 「失敗の本質」に学ぶ

人情を重んじるとプロジェクトが失敗する確率が高くなるという。感情に支配され、客観的事実に目をつむってしまったら、プロジェクトはたちまち失敗 へと向かうだろう。しかし、人間は感情の動物だ。人情・感情を無視したらモチベーションは絶対に上がらない。このトレードオフの均衡点はどこにあるのだろうか。

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

 

　年末・年始に本の整理をしていたら、以前読んだ『失敗の本質---日本軍の組織論的研究』（中央公論社）という本を見つけました。最初に読んだ時はまだ 社会に出たばかりの頃だったので、正直なところ、あまり記憶には残っていませんでしたが、今回なんとなく気になり、もう一度読み返してみることにしました。

　この本には、「失敗はなぜ起きてしまうのか？」という多くのメッセージが詰まっていました。それはまさに、プロジェクトマネジメントに携わっている者にとっては、プロジェクトを失敗させないための珠玉のメッセージでした。

　今回は、私がこの本を読んで「プロジェクトマネジメント」と「失敗を引き起こす感情」いう視点から考えたことを読者の皆さんにもお伝えしたいと思います。興味がわいた方には『失敗の本質』も一読をお薦めします。

「体面」「人情」「組織内の融和と調和」を重んじてはならない

　『失敗の本質』では、失敗を避けるために、「体面、人情、組織内の融和と調和を重んじてはならない」としています。その理由は、体面、人情、組織内の融和と調和を重んじると感情に流されやすくなり、その結果、客観的事実を無視（軽視）して「目的や実現性が乏しい計画」を実行に移してしまうという。さらに コンティンジェンシープランのようなリスク管理も甘くなる。つまり、「体面、人情、組織内の融和と調和を重んじる」と失敗する確率が高くなるというのである。

　これをプロジェクトマネジメントに当てはめて考えたとき、私はまず「人間は感情の動物」であり、それを無視してしまったらモチベーションと生産性を著しく低下させてしまう恐れがあるのではないか、と感じました。それゆえ、それらの感情を全く無視してしまうのは問題があると。

　例えば「調和を大切にすること」は、組織が持っている「組織感情」、分かりやすく言い換えればプロジェクトの雰囲気を、風通しのよい状態にすることに大きく貢献していると思います。

　しかし、この「体面」「人情」「組織内の融和と調和」を重んじるということは、諸刃の剣です。「感情に訴えれば許してもらえる、見逃してもらえる」という甘えの文化を醸成してしまう恐れがあります。

　人情に訴えて許しを請おうとする場面に、皆さんも出会ったことがあると思います。例えば進捗会議で「徹夜して頑張ったのですが…（こんなに頑張ったのに 文句を言うのか！ 努力を認めないのか！！）」とか「3回以上レビューを実施したんですよ！（だから、多少のミスが見つかっても仕方がないでしょ！）」といった発言をよく耳にするのではないでしょうか。ちなみに（　）内は発言者の心の声です。

「人情に流される」とどうなるか？

　心の声を「察する」とか「空気を読む」というのは、いかにも日本的なコミュニケーションです。こうしたコミュニケーションがプロジェクトの目的達成の助けになるなら、どんどん相手の立場になって「察して」あげるべきだし、それによって効率よく仕事が進むはずです。

　しかし、多くの場合、「これは目的に対して悪いこと」と分かっていても「人情に流されて」見逃してしまう、あるいは、許してしまうということになっては いないでしょうか。人情に流されると客観的事実を無視してしまい、あたかも「奇跡が起こる」ことを当然のように期待してしまいがちです。

　私が実際に経験した話をしましょう。進捗会議で、客観的に見れば実現不可能なスケジュールが出てきました。しかし、「みんな、土日も出て、毎晩終電まで 仕事をすれば必ずできます！！メンバー全員で頑張りましょう！！」とリーダーからの必死の訴えを繰り返し聞かされたら、なんとなくできそうな気がしてきました。そして、客観的な事実に 基づいて計画を見直すべきだと言える雰囲気ではなくなっていました。もちろん、その会社やプロジェクトの文化・雰囲気の影響もあると思いますが、必死の訴えに心を動かされ、常軌を逸した行動に駆り立てられてしまったのは事実です。

当事者は失敗を想定していない

　このように、客観的事実が軽視され、感情に訴えかけられている場合、たいていの当事者は失敗することを想定していません。ですから、失敗した場合にどう するかということも考えていません。プロジェクトマネジメントで言えば、リスク管理ができていない状況といえるでしょう。

そういう人の多くは、過去に危機的な状況を精神論で乗り越えた経験を持っています。それが「成功体験」となり自分で選択肢の幅を縮めてしまっていま す。似たような状況のプロジェクトを5回経験して、そのうち4回失敗しているにもかかわらず、残りの1回が成功してしまえば、それが「成功体験」として心 に強く焼きついてしまうようです。

　その成功した1回にしても、「失敗が覆い隠され、成功したように見えるだけ」とか「神風が吹いて状況が奇跡的に変わっただけ」というケースもあります。そこに失敗から学ぶ気持ちは生まれず、「奇跡」に助けられたこともすぐに忘れ去られてしまいます。

感情を受け入れつつ、客観的事実に基づいた行動を促す一言

　それでは、PMO（プロジェクトマネジメントオフィス）として「人情や感情に訴えられた」場合、どうすればいいのでしょうか。ポイントは「感情」と「客観的事実」のバランス感覚だと思います。

　「感情」の部分を全く受け付けないと、プロジェクト運営に必要な信頼関係やモチベーションに支障を来たします。メンバーが人情や感情に訴えてくる背景に は、案外「頑張っていること」「努力していること」を認めてほしいという気持ちも多くあります。「頑張り」や「努力」を大いに認めて共感することは大切です。

　一方、実際の行動は、改めて言うまでもなく「客観的事実」に基づいて決定すべきです。これができなければプロジェクトマネジメントではありません。問題は、感情に支配された当事者たちをいかに説得するか、という点です。

　そこで重要なのは、先ほど少しだけ触れたリスクマネジメントの考え方です。「1回あなたの言うとおりにやってみましょう。ただし、来週金曜日までにここからここまでの作業が終わらなかった場合を考えて、一緒にその場合の対応策を考えませんか？」と持ちかけて、コンティンジェンシープランを作ってみてくだ さい。

　まずは相手の意見を受け入れましょう。その代わり致命傷にはならないチェックポイントを設定し、そのチェックポイントをクリアできなければ別の方法を潔 く実施してもらえるようにしましょう。PMOとして、相手の「感情」と「客観的事実」のバランスをうまく取るように心がけてください。

第75回 ボトルネックがひと目で分かる進捗管理

どんなプロジェクトでも必ず必要な管理作業は「進捗管理」だ。やり方はいろいろあるが、「プロセス単位の進捗管理」をぜひ心がけてみてほしい。この 方法なら、プロジェクトのボトルネックをひと目であぶりだせる。今回はプロセス単位で進捗管理する方法について、筆者が実際に現場で実施している考慮点と併せて解説したい。

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

 

　皆さんが進捗管理を実施する目的は何でしょうか。もちろん、「プロジェクトの各タスクの進み具合を管理して、遅延しているタスクを明らかにし、対策を打つため」だと思います。

　しかし、進捗管理の仕方によっては、「どこに遅延の原因があるのか」「その遅延原因を本当に正しく把握しているのか」「原因に対して正しい対策を計画しているのか」が見えてこない場合があります。

　言うまでもなく、進捗管理の目的はプロジェクトを計画したスケジュール通りに進めること。それならば、「計画どおりに進めるにはどうすればよいか」が進捗管理の結果から自ずと見えてくるのが理想です。

　そこで、私がPMOとして利用している進捗管理方法は、成果物の作成の一つひとつのプロセス単位で進捗管理を行う方法です。

設計書1本ごとの進捗は分かっても、遅れの原因は見えてこない

　その前に一般的な進捗管理方法を見てみましょう。図1を見てください。例えば、あるシステムで200本の設計書を作成する場合、皆さんはどのような進捗管理を実施するでしょうか。よくあるのは、設計書の完了予定と実績を1本ずつ管理したり、全数のうちの完了数をパーセント（％）で数値化したりすると思います。

図1●一般的な進捗管理

このような進捗管理では、何がボトルネックで遅延が発生しているか把握しづらい

　皆さんも経験があると思いますが、この管理方法だと設計書1本ごとの着手から完了までの状況がよく分かりません。プロジェクトによっては、「着手したら 進捗率10％」「作成完了で50％」「レビュー終了で80％」といったルールを決めて進捗率（％）を把握するところもあるようです。しかし、これを用いて も、着手から完了までの間の何が原因で進捗が遅れているのか、詳細に分析していかないと分からないのが実情です。

ボトルネックを探すための進捗管理

　次に図2を見てください。例えば同じように設計書を作るというタスクにおいて、そのタスクを（1）設計書作成 →（2）設計書1次レビュー →（3）1次レビュー結果反映 →（4）設計書2次レビュー →（5）2次レビュー結果反映、のように細かなプロセスに分解します。フェーズによっては、「画面標準化の確認」や「帳票イメージの確認」などもっと細かくプロセスを分けてもいいでしょうし、オフショアで開発しているなら、オフショア先のレビューと日本側の受け入れ、それぞれのプロセスがあってもいいで しょう。

図2●プロセスレベルの進捗管理

設計書の作成遅延は、2次レビューがボトルネックとなっていると把握でき、効率的な対策が打てる

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

　そして、プロセスごとに「完了数/全数」と「完了実績数/完了予定数」を把握していきます。この進捗管理方法の優れたところは、設計書を完成させるという一連のプロセスのどこにボトルネックがあるかを可視化できることです。例えば、（3）設計書1次レビュー結果反映までは完了予定に対しての実績が 100％であるのに、（4）設計書2次レビューについての実績が50％ぐらいであるならば、2次レビューがボトルネックになっていることが分かります。

　このレベルでボトルネックを特定できれば、「2次レビューの担当者がレビュー時間を十分に取れないのか」「レビューアーの数に対してレビュー対象物が多 すぎるのか」「2次レビューアーの知識不足でレビューに時間が掛かりすぎているのか」など、原因の当たりがつきやすくなり、またその原因に対して正しい対応もとりやすくなります。

　実際の現場では、これらの数字から生産性を求めます。それを基に、「このまま行ったとして、残りの期間で完成するか」「残りの期間から“1日に完了すべき本数”はいくつか」といった指標を出すなど、いろいろな情報を付加して現場と共有しています。

データ収集が多少面倒でも元は取れる

　このような進捗管理を実施する上でのポイントは、進捗管理の仕組みとして最初から指標を算出するためのデータ収集を組み込んでしまうことです。

　ただし、間違ってもこのような進捗管理に力を入れ過ぎて、メンバーに余計な負担をかけてはいけません。PMOは各フェーズが始まる時にあらかじめ進捗管理フォーマットを用意しておき、その進捗管理フォーマットに従って実績を記入してもらうようにするのが得策です。

　「そもそも、細かい単位でメンバーに進捗を記入させる方が負担がかかる」という意見もあると思います。しかし、筆者の経験上、プロセス単位で進捗を見るほうがそもそもの計画（予定）を正確に見積もることができます。さらに、遅延の予兆や原因も早く見つけだせます。結果的には、プロジェクトをより効率的に 進められると考えています。公式にこのような進捗管理をしていないとしても、進捗が遅れ始めたとき、チームリーダーはどこかで（頭の中かもしれませんが）同じような作業をして原因を見つけようとしているはずです。それを仕組み化することが肝心なのです。

　もちろん、プロジェクトの規模やフェーズによって進捗管理の考え方を変える必要があるでしょう。それでも、大規模なプロジェクトで、設計/開発/テストフェーズであるならば、今まで述べてきた進捗管理方法を適応してみる価値はあります。

第76回 標準化が定着しない理由

　システム開発の現場には、システム開発標準やプロジェクトマネジメント標準など、様々な標準があるだろう。プロジェクトでは、それらの標準に沿っ た運営が求められる。しかし、実際のところ、それらの標準は本当に「現場のため」になっているのか。疑問に思うことが多々ある。

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

 

　システム開発において、「標準化」と聞いて皆さんはどのようなイメージを思い浮かべるだろうか。「システム開発をを効率よく進めるために大変有効なもの」と答える人もいれば、「実利のない、面倒くさい手続きばかりで生産性を下げるもの」「品質を確保するために必要なのは理解できるが、ここまでやるべき か、ふに落ちない」など様々な意見があると思います。一般に、システム開発における標準化のメリット／デメリットを挙げると、以下のような点が挙げられます。

【システム開発における標準化のメリット】
（1）関係者が同じ言葉を用いることにより、コミュニケーションロスが少なくなる
（2）同じ標準を用いて開発したシステムとの比較ができる
（3）標準を改善していくことで、より効率よく高品質なシステムを開発できる
（4）アウトプットとして同じ品質が期待できる
（5）サンプルやテンプレートを利用することで開発プロセスや成果物の検討時間を短縮できる

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

　システム開発現場の視点から単純に「標準化」を見た時には、これらのメリットだけを見るとまるで「魔法の杖」のように思えることでしょう。その半面、現実に「標準化」を取り入れたからといって、必ずしもプロジェクトに定着するとは限りませんし、さらに言えば、そのプロジェクトが成功するわけでもありませ ん。

　それは、なぜでしょうか。

同じプロジェクトは存在しない、という自明な前提

　PMBOKでは「プロジェクトとは､独自のプロダクト､サービス､所産を創造するために実施する有期性のある業務である」（PMBOK第4版　第1章序論より）と定義されています。つまり、各々のプロジェクトが独自の目的や制約をもっており、全く同じプロジェクトは存在しないということになります。

　客観的に見て、そういう定型でないプロジェクトに標準を無理やり当てはめ、「標準どおりにすべてやりなさい」と押し付けも、うまくいくものではありません。一生懸命に標準を作っても、あまり適用されなくなってしまう理由の一つがそこにあります。本来、標準をそのまま適用したくても、適用できないものなの です。

標準化のテーラーメイドはPMOの重要な仕事

　ここでPMOが標準化の導入について大きな役割を果たします。それは、標準をテーラーメイドしてプロジェクトの形に合わせるという作業です。

　標準の中には、「どのようなプロジェクトでも絶対に守らないといけない普遍的なもの」と「プロジェクトの状況に合わせて変えてもよい、あるいは変えるべ きもの」があります。例えば、会社として決めている「プロジェクトコストの計算方法」や法的規制に関わること、全体最適の面から標準化が必須なものは「絶対に守らないといけない普遍的なもの」です。

　一方、課題管理・進捗管理の方法や変更管理のフロー、プロジェクト内での情報共有の方法などは、そのプロジェクトの状況に合わせて変更しても構いませ ん。簡略化あるいは省略しても標準化の目的を達成できるならそうすべきですし、逆に効率化のために作業やルールを追加すべき場合もあるでしょう。

　ここで重要なのは、2つの目的のバランスをとりながら標準化を進めるべきだということです。2つの目的とは、「上位のマネジャーが必要としている標準化 された情報を提供すること」と「現場のメンバーが効率よく作業を進められる仕組みを定着させること」です。PMOは、ときとして現場からの情報を上位層が 必要とする情報へ翻訳してあげるような役割を担うこともあります。

テーラーメイドする際の注意事項

　PMOとして標準のテーラメイドを実施する際には以下の点に気をつけるとよいでしょう。

（1）手段であるはずの標準化が目的化してしまわないこと
（2）現場の規模や状況を無視した理想論を掲げないこと
（3）現場のリーダーやメンバーの負荷を著しく増やさないこと
（4）導入する作業や仕組みについて現場の理解を得ること

　また、経営・社会学者のピーター・ドラッカーは著書『マネジメント 基本と原則』の中で「管理手段の要件」として7つのポイントを挙げています。ここでは説明しませんが、標準化という管理手段のエッセンスと言えるでしょう。興味のある方はそちらも参考にしてみてください。

第77回 新任PMOが悩むPMOの立ち位置（1）

初めてPMO（プロジェクトマネジメントオフィス）という立場でプロジェクトに着任した時、皆さんはどのようなことに悩み、どのように解決しただろうか。今回はPMIフォーラムにて講演した内容を基に、今までPMOをやったことのない人がPMOとして着任した際に、どんなことに悩み、どのように解決 していったのかをお伝えしたい。

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

 

　皆さんは、PMOとは何をすべき存在だと思いますか。もちろんプロジェクト管理ですが、プロジェクト管理といっても内容はさまざまです。進捗管理、課題管理から、標準化の定着・導入、“コミュニケーションハブ”としての役割、プロジェクトマネジャーの補佐、はたまた、プロジェクトの事務局から火消し役までいろいろです。PMBOKにもPMOの記載はありますが、これといってこの仕事をしなさいと定義されたものではありません。この点がPMOをやっていく うえで一番悩む点ではないでしょうか。

PMOとして仕事の壁を作らないという意識が重要

　ここで、私がPMOの心得の1つとしていつも大切にしていることがあります。それは「プロジェクトの成功のためならば、必要な仕事・役割は何でも拾う」というスタンスです。

　皆さんは、「それではPMOは何でも屋じゃないか。PMOに何でも持って来られたら、忙しくなりすぎて、まともにこなすことなんてできない！」と思うかもしれません。ここで重要なポイントは、「拾うこと」と「自分でやること」はイコールでない、という点です。

　PMOに何かしら困りごとが持ち込まれたとき、PMOがとるべきアクションにはいくつか選択肢があります。「自分でやる」「サポートする」、または「そのタスクの適任者を見つけて説得し、仕事を割り振る」などです。PMOはこれらのアクションを通してプロジェクトの成功に貢献するわけです。

OJTを行う上での重要ポイント

　「プロジェクトの成功のためならば、必要な仕事・役割は何でも拾う」というスタンスでPMOとして仕事をしていく場合、新任PMOに対してOJTで教育する時に気を付けていることが2つあります。

（1）プロジェクトの成功のためには何が必要かを常に自問自答できる人材を育てる
（2）プロジェクトの成功を未来から現在に向かって見たときに「何が足りないのか」を見抜く力を養う

　そのためにはある程度の経験はもちろん必要ですが、「今はこのプロジェクトには何が必要だと思う？」というような問いかけをこまめに行い、新任PMOが自ら気付きを得られるように仕向けることを心がけています。

　実際のところ、最初は何回言っても理解してもらうのが難しいかもしれません。しかし、1カ月、2カ月と根気強く、口酸っぱく問いかけていくうちに、新任 PMOも普段からのそのような視点でプロジェクトを見る癖がだんだん身に付いていきます。そのような癖が身に付いてしまえば、PMOとしての成長は格段に 速いものとなるでしょう。

第77回 新任PMOが悩むPMOの立ち位置（1）

“何か足りないもの”はどこにあるか？

　さきほど、PMOが身に付けるべき観点の1つとして、「プロジェクトの成功を未来から現在に向かって見たときに、何が足りないのかを見抜く力」が大切と述べました。では、具体的に「何が足りないかを見抜く」とはどういうことなのでしょうか。

　ここで図1と図2を見てください。「何か足りないもの」というのは、多くの場合、何かと何かの「すき間」にあります。（1）人と人の間、（2）組織と組織の間、（3）プロセスとプロセスの間、（4）ツールとツールの間などです。誰の守備範囲でもなく、誰も気にしていないようなところです。誰の守備範囲でもないところに問題があると気付いても、周辺の人・組織が“お見合い”をして手を出さない場合もあります。

図1●「何か足りないもの」がある場所

「組織と組織との間」「人と人の間」に、誰の守備範囲でもない場所がぽっかりと空いている。

図2●「何か足りないもの」がある場所（続き）

「プロセスとプロセスの間」「ツールとツールの間」にも、誰も気にかけていない“空白地帯”が存在する。

　PMOとしては、「こうしたすき間をどのように埋めていくべきか」と考えることで、自分の役割、次に実行すべきアクションが見えてきます。

　次回は、どうすれば「何か足りないもの」を探し出せるのか、そしてどう行動すべきか、という点を考えていきましょう。

第78回 新任PMOが悩むPMOの立ち位置（2）

　前回は、プロジェクトの成功のために、PMOには“何か足りないものを見抜く力”が必要だと述べた。今回はその“何か足りないもの”をどのように探し出し、どう行動をすればよいのかを考えたい。

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

 

　プロジェクトを成功に導くうえで“何か足りないもの”があるとすれば、それをどのようにつかめばよいのでしょうか。前回、何か足りないものは、（1）人 と人の間、（2）組織と組織の間、（3）プロセスとプロセスの間、（4）ツールとツールの間のどこかに存在するものだと説明しました。今回はそれらを詳細に見ていきたいと思います。

　最初に、人・組織の間で足りないものを見てみましょう。図1のように、組織における縦方向と横方向の隙間、または人と人の間にある隙間に注目してください。

図1●「何か足りないもの」がある場所

「組織と組織との間」「人と人の間」に、誰の守備範囲でもない場所がぽっかりと空いている。

　具体的には、組織間や担当間の役割分担で抜けている役割があるとか、大きな課題が発生した場合のエスカレーションパスが不明瞭になっている、といったことです。また、役割が重複している場合も注意が必要です。主担当と副担当というように意思決定の順序が明確になっている場合はいいのですが、同じ領域で同 じレベルの意思決定者が複数人いると、意思決定に時間がかかります。意思決定者の2人の意見が異なるときの調整コストを考えると、良いことはありません。

　PMOは、組織の役割や権限を交通整理することによって、それぞれの守備範囲の隙間で“ポテンヒット”が生まれないようにしなければなりません。もちろ んポテンヒットをすべて防ぐことは不可能なため、ポテンヒットをPMOが自ら拾いに行って、拾ったボールを適切な場所に投げるという行為をPMOが主体となってすることが必要です。その際、ボールを投げる適切な場所がなければ、PMOはプロジェクトマネジャーとともにボールを受け取ってくれる組織や担当者を決めて説得しなければなりません。

　次に、人と人の間という観点では、前述したようにメンバー間の役割の間を埋めることも重要ですが、より必要なことは「感情の間」を埋めることです。

　プロジェクトが円滑に活動できていない場合の代表的な失敗パターンとしては、プロジェクトマネジャーや核となるプロジェクトメンバー間で良い人間的関係を築けていないことがよくあります。こんな時にPMOは多少面倒でも、その対立の間に立って仲を取りもつことも必要になってきます。簡単に言えば、コミュニケーションの断絶が発生しないように、人間関係（コミュニケーション）の潤滑油的な動きを行うということです。あまりに感情面での対立がひどい場合は、 人を変えるという選択肢も視野に入れなければなりません

プロセス・ツールの間に足りないものとは？

　次にプロセスやツールの間にある足りないものを見てみましょう。

　図2にある通り、プロジェクトマネジメントにおける一般的な管理プロセスでは、プロセスとプロセスの間にポテンヒットが発生するホットスポットができやすい状態になります。

図2●「何か足りないもの」がある場所（続き）

「プロセスとプロセスの間」「ツールとツールの間」にも、誰も気にかけていない“空白地帯”が存在する。

　例えばリスク管理について考えてみましょう。新たにリスクが発生した場合、そのリスク対応のために課題管理や変更管理が必要となります。また、対応する ためのリソースやコストも増えます。品質管理の範囲も広がるでしょう。この例では、リスク管理のプロセスから課題管理プロセス、変更管理プロセス、リソース管理プロセス、コスト管理プロセス、品質管理プロセスに影響が波及することになります。その際にプロセスの間（例えば、リスク管理→課題管理）を埋め、プロセス間の整合性をとっていくことが欠かせません。

　同じことはツールについて言うことができます。課題管理やリスク管理、変更管理などツールを利用して効率的に管理しているプロジェクトも多いと思います が、どんなに頑張ってもツールですべての管理プロセスの間を埋めるには限界があります。その間には、やはり人（PMO）が介在してすき間を埋め、整合性を とっていく必要があるのです。

新任PMOが陥りやすい罠

　新しくPMOになる方は、今まで述べてきたような、PMOとして“何か足りないもの”を見つける観点を知っておくことは重要です。

　しかし、“何か足りない”という嗅覚を身に付けるには、ある程度の経験を積むことが必要であり、一朝一夕にできることではありません。そのようなPMO としての嗅覚ができる前に現場に出る新任PMO人たちには、陥りやすい失敗のパターンがあります。それは下記の4パターンに分類することができます。

（1）食べ過ぎ消化不良型
（2）灯台下暗し型
（3）タコ壺型
（4）自己未完結型

　次回は、この4パターンを見ながら新任PMOが陥りやすい罠について考えてみることにしましょう。

第79回 新任PMOが悩むPMOの立ち位置（3）

　前回は、プロジェクトを成功に導くうえで“何か足りないもの”があるとすれば、それをどのようにつかめばよいのかを具体的に見てきた。今回は、新任PMOが陥りやすい失敗パターンについて考えていきたい。

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

 

　PMOの実行サービスを提供してきた様々な経験から、新任PMOが着任した際にうまく立ち回れず、失敗してしまう事例をしばしば見てきました。これらの多くの失敗事例を分析していく中で、新任PMOが陥りやすい失敗パターンとしては大きく分けて4つに分類できます（図1）。

図1●新任PMOが陥りやすい4つの失敗パターン

　新任PMOが最初に当たる壁としては、多くの場合、このどれかのパターンに当てはまるのではないでしょうか。また、複数の失敗パターンに同時に陥る人もいます。これらのパターンを事前に知ることで、失敗の罠に入り込まないよう、事前に手を打ちことを考えてみましょう。

パターン（1）食べ過ぎ消化不良型

　まず最初は、食べ過ぎ消化不良型です。このパターンにはまってしまう方が圧倒的に多い、ということが分かっています。簡単に言ってしまえば、PMOとい うもの自体が何をすべきか十分に理解できていないため、とにかく手当たり次第に何でも手を出してしまい、負荷に耐え切れず自滅してしまうというパターンです。

　特にPMOという機能が定着していない現場では、現場の方々もPMOが何をやるのか分かっていません。そのため、「とりあえず困ったら何でもPMOに振ってしまえ」という風潮になっている現場をよく見てきました。

　ここでのアドバイスとしては、PMOとしてタスクに優先順位を付け、かつ、本当に自分がやるべきことなのかを自問自答してみることです。もしくは、PMOとしての有識者が交通整理をしてあげることが大切です。

　筆者が今まで経験してきたプロジェクトで、PMOが一杯いっぱいになっているプロジェクトはほとんどうまくいっていません。逆に、PMOに少し余裕があ る状態（つまり、緊急時にPMOが主体的に行動できる余裕がある状態）だと、うまくいっているプロジェクトが多いということが言えます。PMOは、いつも 100％の負荷状況にあるのではなく、少し余裕を持つぐらいのスタンスで臨むことが肝心です。プロジェクトの成功のために、“今”何が一番重要なのかを考 え、タスクを取捨選択できるようになると、食べ過ぎ消化不良型に陥ることを防げるようになると思います。

　そのためにもマネジメント層は、最初にプロジェクトメンバーに対して「PMOは何でもやってくれる」というような過度な期待を抱かせないように配慮しなければなりません。PMOの負荷（PMOへの期待値）を適切にコントロールすることは、新任PMOを支援するために重要なポイントとなってくるのです。

第79回 新任PMOが悩むPMOの立ち位置（3）

パターン（2）燈台下暗し型

　燈台下暗し型の失敗パターンとは、PMOは自らが計画を立てる役割を担っているのにもかかわらず、計画がないから自分の作業が分からないと言って思考停止になってしまうパターンです。よくある例としては、チームメンバーに対しては「計画を立てなさい」と言ってはいるが、メンバーが計画を立てるための計画 （方向性）をPMOとして示せておらず、計画を立てろと言っているPMOの計画が全く立っていない状況です。これはまさに灯台下暗しです。

　この失敗パターンは、PMOとして「計画がないから何をやっていいか分からない」という人が結構いることを示しています。別の言い方をすると、「“計画の計画を立てる”のがPMOだということに気付いていない」ということです。

　PMOは、曖昧模糊とした中から計画を作っていく（だんだん輪郭をはっきりさせていく）ことが大きな役割の一つだということを理解してもらわなければなりません。ここを理解しているかどうかで、PMOとしての動きに大きな差が出てきます。また、プロジェクトの特性にもよりますが、課題管理や進捗管理といったルーティン的な仕事はPMOの仕事の40％程度しかなく、残りの60％は調整や次フェーズの検討作業など、WBSに落とすのが難しい非定型的な仕事です。

　この「WBSに落とせないタスク」がたくさんあるということが、そもそもPMOが何をやっているのか分からない理由でもあります。それでもPMOとして は、その60％の時間で非定型的な作業（つまり、WBSのインプットとなるような道しるべ）を行っていくものだということを理解すると、新任PMOの動きが変わってきます。

パターン（3）タコつぼ型

　タコつぼ型の失敗パターンとは、役割分担にこだわるあまり、PMOが仕事に壁を作ってしまい、タコつぼに引きこもるような問題を指します。

　特にプロジェクトマネジャーやプロジェクトリーダーを経験した方は、「役割分担」や「スコープ」という言葉に敏感に反応します。やや極端な例ですが、自分の責任範囲をきっちり決めてしまい、それ以外の問題にはまったく興味を示さないPMOもいます。

　PMOになった際にこのような感覚が残っていると、すき間を埋めるはずのPMOが、逆にすき間を作ってしまうことになりかねません。また、そのような方は責任感が強く、“間に落ちている何か”を見つけて自ら拾ってしまうと、PMO自身がそれを解決しなければならないと思う傾向があります。

　冒頭でも話しましたが、「すき間に落ちている何かを拾うこと＝自分がやること」ではありません。PMOが問題を拾う行為は「交通整理をすること」であり、担当者を見つけ、解決までサポートすることです。『第66回 組織力を駆使したプロジェクトマネジメント』でも述べたように、PMOは「組織としての機能」だということを忘れないでください。

　PMOの仕事は、WBSのように個人個人にタスクが割り振られるようなものではありません。“すき間に落ちている何か”を埋める、潤滑油のような機能になるべきです。PMOの各個人でなく、PMOという組織でどのように対応していくかという視点も必要になるのです。

パターン（4）自己未完結型

　最後は、自己未完結型です。PMOの失敗事例の中では2番目に多いパターンであり、いままで個人技に頼って仕事をしてきた人が陥りやすい罠とも言えます。何でも自分中心で判断し「自己完結型」で課題を解決しようと突き進むのですが、周囲の協力なくして完遂できるはずもなく、結局は「未完結」のまま失敗 してしまうパターンです。

　自己未完結型のPMOを一言で説明すると、「チーム作業ができない」ということです。先ほどのタコつぼ型のところでも説明しましたが、「PMOは組織と しての機能」です。決められた成果物を一人で黙々と出していくのではなく、プロジェクトを成功させるために、成果物という形にならない作業も多く手掛けなければなりません。そのためには、チームとして協力して、プロジェクトのすき間を埋めていく作業は欠かせません。

　実際に、個人の力を過信しすぎて、お客様を置いてけぼりにしてしまい、間違った方向へ一人で突っ走ってしまった例を何度も見てきました。個人がいかに優 秀でも、プロジェクトとしてメンバーをマネジメントし、同じ目的に向けて音頭をとることができなければ、PMOメンバーとしては失格です。

　また、あまりにもプライドが高すぎて「人に聞けない」「頼れない」というのも、自己未完結型にある特徴です。だれかに聞けば分かるかもしれないことを、 「この仮説は正しい」という建前のもと、間違った方向に進んでしまうのです。特に個人技に優れていて、多少の問題は手先の器用さで解決してきたような、コンサルタント経験者に比較的多いパターンです。

　こうしたPMOには、問題解決の主体は「私」ではなく、「私たち」なのだと発想の転換を促すことが必要になります。

　次回は、「新任PMOが悩むPMOの立ち位置」シリーズの最終回として、実際にPMOという立場を初めて体験した人へのアンケート結果から、そのメンバーがどのような壁に突き当たり、どのように乗り越えていったのかの実例を紹介したいと思います。

第80回 新任PMOが悩むPMOの立ち位置（4）

　「新任PMOが悩むPMOの立ち位置」シリーズも今回が最後となる。4つの失敗パターンに陥らないようにするためには、新任PMOはどんなことを身に付けておくべきだろうか。実際にPMOの仕事を初体験した方々へのアンケート結果を基に、解き明かしていきたい。

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

 

　前回、PMOとして陥りやすい4つの失敗パターンを紹介しました（図1）。実はその4つのパターンに陥る傾向として、「それまでどのような経験を積んでPMOになったのか」というキャリアがある程度関係しているようです。

図1●新任PMOが陥りやすい4つの失敗パターン

　「食べ過ぎ消化不良型」はプログラマーやSEからPMOになった方に多くみられます。なぜならば、マネジメントや管理、PMOというものに対しての理解や経験が不足しているため、手当たり次第に自分のタスクとして拾ってきてしまう傾向があるからです。

　「燈台下暗し型」もプログラマーやSEからPMOになった方に多くみられます。WBSや作成すべき決まった成果物（設計書やソースコードなど）がある状 況での仕事に慣れてしまっているため、「自分たちが計画を作る」ことや、「WBSにはない、すき間の問題を発見する」という経験が少ないためではないかと 思われます。

　「タコつぼ型」は、プロジェクトマネジャーの経験者や、ラインのマネジャーなど管理職経験者によく見受けられます。自分の作業範囲を決めて、その中で成果を出していくことに慣れてしまっているためではないでしょうか。個人としての権限を持って仕事をしていたため、「権限はあまりないけれどプロジェクトを 推進しなければならない」というPMOの特性に慣れるのに時間がかかるのかもしれません。

　「自己未完結型」は、前職がコンサルタント系だった方に多くみられる傾向があります。前回のコラムでも述べましたが、個人技に優れているため、今までチームとして成果を出す活動が少なかったためでしょう。PMOという職種になっても、コンサルタント時代と同じように個人技で乗り切れると考え、迷っても誰にも頼らず、相談せずに間違った方向へ進み、最後にお客さまに文句を言われるという王道パターンがあります。

PMOとしての組織マネジメント力

　「食べ過ぎ消化不良型」「タコつぼ型」「自己未完結型」には、PMOとしての組織力を生かして業務を遂行していく、というマネジメント力が必要となります。簡単に言えば、PMO内での役割分担ということになります。ポイントは、コラム『第66回 組織力を駆使したプロジェクトマネジメント』でも述べたように、PMOは組織として機能しなければならないということです。そしてPMOは、ときに相反す る問題の間で、うまくバランスをとっていくことが求められます（図2）。

図2●PMOのバランス

　トップダウン（問題は何？）　⇔　ボトムアップ（支援が欲しい）
　客観的（あるべき論、標準化）⇔　主観的（現場の状況、感情）
　未来（先の計画を考える）　　⇔　現在（今を何とか乗り切る）

　これらのバランスを一人でとって行こうとするのは、大変難易度が高いことです。一人ではなく、PMOの組織としてうまく機能分担（例えば、Aさんは状況の見える化【現在】、Bさんは次のフェーズの準備【未来】）しながら作業を進めていくと効果的です。

　当然、コスト的にPMOが一人しかいないプロジェクトもあると思います。そういう現場においては、プロジェクトマネジャーやプロジェクトリーダーと仮想的にPMO組織を作り、プロジェクトの管理チームとして対応してくことが重要になります。

　「灯台下暗し型」に当てはまる方が気にしてほしいのは、曖昧性を受け入れて対処していくという視点です。ポイントは下記の3つです。

（1）日々変わる状況に応じて、「今何を一番実行すべきか」を自問自答できる力
（2）自分で問題を見つけた時に適切な人にディスパッチするコミュニケーション力
（3）完璧に計画してから進むのではなく、計画しながら進める推進力

PMOとして持っておきたい「政治を見極める力」

　「タコつぼ型」と「自己未完結型」に当てはまる方々が身に付けるとよいスキルは、政治力（言い換えると人間力）です。要点は以下の3つです。

（1）人の立場やポジション、価値観を理解して、その人に合わせてアプローチを行い、プロジェクトの成功を導く力。感情を害さず、気持ちく仕事をしてもらうための力です。。管理屋が陥りがちな「みんなに同じ管理手法を強要する」といったことはせず、柔軟に対応できるスキルが大切です。

（2）PMOを組織として機能させるための政治力（公式パワー、非公式パワー）。PMOが業務を遂行するために必要な権限を自ら調整できる力です。

（3）曖昧な中を進んでいくための協力を得る推進力。みんな不安な中、関係者を説得して進めていくコミュニケーションの能力は不可欠です。プロジェクトが混迷していて、みんなが行き先を失い迷っているときに、進むべき道を照らす、または照らすことができるようにプロジェクトマネジャーをサポートする突破力 を身に付けておきたいものです。

実例1◆プロジェクトマネジャーが何を望んでいるか分からない

　さて、実際新任PMOとして任命された担当者はどのような悩みにぶつかり、克服してきたのでしょうか。新任PMOへのアンケートを基に、3つの典型例を紹介します。

【悩み】
　プロジェクトマネジャーがどのような情報を欲しがっているのか、どのような動きを期待しているのかが分からなかった。

【解決の過程】
　「もし、自分自身がこのプロジェクトマネジャーだったら？」という視点で考えるようにした。明らかに経験不足だったが、懸命に考え抜いて出した答えは、プロジェクトマネジャーの求めるものだった。

【考察】
　この方は、着任してからの最初の3カ月ぐらい、「プロジェクトマネジャーに必要とされるPMO像」がつかめず苦労していました。その問題に気づくまでは典型的な「食べ過ぎ消化不良型」で、手当たり次第に何でも仕事をしていた人です。

　この方の前のキャリアはSEだったので、プロジェクトマネジャーの立場になるという視点の転換（言い換えると、成功に向けて一番必要なものは何かと考える視点への転換）に苦しみました。しかし、プロジェクトマネジャーだったら何が必要だろうと一生懸命考えることによって、この困難を切り抜けました。

　SEから、マネジメント経験を経ずにいきなりPMOへキャリアチェンジした場合においては、視点を1レベル上げていくことに相当苦労するのが実情です。 有識者はその視点から「私がプロジェクトマネジャーだったら、このように考える」といった意見を伝えることが有効なアドバイスになると思います。

実例2◆管理することと生産性を上げることのジレンマ

【悩み】
　決められたルールを決められた通りに運用し、逸脱したものにはその理由にかかわらずルールの徹底を促していた。現場で一方的に強制すると、逆にメンバーのモチベーションと生産性を下げてしまうことがよく起こり、このジレンマに悩んでいた。

【解決の過程】
　現場の状況をよく見て、極端に言えば一人ひとりに合うようなルールの改善、アソビの部分を持たせること、などが必要だと分かった。今は人によってアプローチを変えている。もちろん基本のルールを決めておくことは大前提。

【考察】
　これも、実際の現場ではよくある悩みだと思います。PMOとして、それぞれメンバー個人の仕事の仕方やプロジェクトに対する思い、性格を知ることがとても重要になります。なぜならば、プロジェクト全体としての多様性をコントロールし、生産性を高めていくには、各個人が気持ちよく仕事ができる状況にあるこ とが必要だからです。事例にもあるように、とても難しいのですが、画一的な管理ではなく、メンバーが生き生きと仕事ができるマネジメントを心がけていきたいものです。

実例3◆PMOとしてどこまで踏み込んで良いのか分からない

【悩み】
　「自分の作業は終了したので、帰ります」というスタンスだと、「このPMOさんはドライな感じがする」と思われ、かといって「プロジェクトの成功のために、何でもやります」というスタンスだと、タスクが溢れてしまって元も子もない状態に陥ってしまった。

【解決の過程】
　お客さんの要求レベルを確認しながら、それをちょこっと上回るくらいのさじ加減が必要だと思い、細目にわたりお客様のキーパーソンと“期待値合わせ”を実施した。

【考察】
　この悩みも新しくPMOになった方にはついて回ります。この方は、仕事をしていく中で、自分なりの踏み込み具合のスタンスを固めていきました。これは、クライアントが変われば、当然、要求レベルも変わってきますので、一概にこのやり方ですべて問題が解決できるわけではありません。ただ、日々お客様と期待 値を合わせていくというのは、非定型的な作業が多いPMOにとっては重要なことだと思います。

　　　　　　　　◇　　　　　　　　◇　　　　　　　　◇

　以上、4回にわたり新任PMOが悩む問題についてお伝えしてきました。PMOという職種はまだまだ発展途上であり、人によって様々なPMO像がありま す。「PMOとは何か」を一生懸命定義することも重要かもしれませんが、PMOが入ることでメンバーが「自分のやるべきことに集中できる環境でできて、仕 事がはかどっている」と実感してもらうことがより重要だと考えます。