顧客側から見ると、PMOははっきりとした成果物がなかったり、プロジェクトマネジャと役割が重なっていたりする場合があるこのため、何をやっているか分からない組織と見られることが多い。“存在理由”を疑われたPMOメンバーは、モチベーションを急速に失っていくだろうそうなる前に、プロジェ クトマネジャはPMOの必要性を顧客に訴え、PMOメンバーにスポットライトを当てる必要がある。

マネジメントソリューションズ マネージャー PMP

　本来、「PMOは目立てない組織」ですそれゆえに、PMO経験者の中にはこんな経験をした方もいらっしゃるのではないでしょうか。

●顧愙から「PMOは何をしているか分からない必要なの？」と言われた
●プロジェクトメンバーから「業務内容を知らないくせに、偉そうに命令ばかりするな」と言われた。

　私がPMOをしていた時に、実際に言われた言葉ですPMOの仕事は縁の下の力持ちのような役回りが多く、開発メンバーと比べれば普段はあまり目立てない存在です。開発メンバーなら、事前に成果物を決め、タスクを洗い出してWBS（WorkBreakdown Structure）を作り、スケジュールに沿って着々とタスクをこなしていきます開発メンバーは成果物や、やるべきことがはっきりしているため、顧客からも何をしているのかが見て分かります。

　しかし、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メンバーのモチベーションが目に見えて高まりました。

　PMOの存在理由を周知する方法はいろいろあります例えば、プロジェクトを開始するキックオフ?ミーティングで、プロジェクトマネジャやプロジェクト責任者がPMOの必要性を関係者全員に宣言すればよいでしょう。たったこれだけのことで、PMOの組織としての能力は何倍にもなりますメンバーやプロ ジェクトマネジャが気持ちよく業務ができる環境を作っていくのはPMOの重要なタスクの1つですが、その前に、PMOが気持ちよく働ける環境をプロジェク トマネジャやプロジェクト責任者が作ってあげてはいかがでしょうか。

プロジェクトの中には“職人”と呼ばれるようなメンバーが1人や2人はいるだろう職人はパフォーマンスが高く、高品質な成果物を作るが、意外にも、それがあだとなってプロジェクトの生産性を下げるケースが多い。顧客が、すべての成果物に“職人品質”を求めるからだそんな時、PMOはプロジェク ト全体が過剰品質にならぬよう、職人技を生かす場づくりに取り組もう。

マネジメントソリューションズ マネージャー PMP

　皆さんのプロジェクトの中にも、「ここまで書くか」というくらい詳細な業務フローを書けたり、高品質なプログラムを他のメンバーの2倍以上のスピードでコーディングしたりできる“職人”がいるのではないでしょうか

　このようなスーパーマンやスーパーウーマンはモチベーションが高く、高品質な成果物を作るため、プロジェクトにとって非常に貴重な存在です。ただし、 PMOが職人の振る舞いをある程度導いてあげないと、意外にもプロジェクト全体としての生産性が落ちるケースが多々あります

　高品質な荿果物を作る職人が活躍すると、なぜプロジェクト全体の生産性が下がるのでしょうか。それは、職人はスキルもパフォーマンスも高いため、「過剰 な品質」を作り込んでしまいやすいためです職人により過剰に作り込まれた品質に対して、「他のメンバーが受け持つ他の部分の品質が追いつけない」という現象が発生するのです。

顧客は一番高いレベルに合わせて全体品質を求める

　PMBOKには品質の定義として「品質とは、本来備わっている特性がまとまって、要求事項を満たす度合い」と定義していますここで言う品質の要求事項とは、「プロジェクト計画書などで定義されたコストや期間を考慮しつつ、プロジェクトの目的を満たせられる品質」だと言い換えられます。

　ここで重要なポイントは、「過剰な品質は不要」ということですあえて大げさに言うなら、社内のコミュニケーション?ツールを作るのに、スペースシャト ルの通信システムのような、絶対に故障を起こさないほどの信頼性や冗長性は不要です。PMOはプロジェクト計画書で定義された「適切な品質」を目標とし て、品質をコントロールしていかなければならないのですそうしないと、予算や納期を守れません。

　職人が作る成果物は、高品質ですばらしいものですしかし、顧客から見ると、その一番高い品質の成果物が基準になってしまいがちです。他のメンバーが作 る成果物にも、その“職人品質”を求めてきますもし、あなたが顧客の立場だったらどうでしょうか。品質がばらついていたら、きっと品質の高いほうに揃えてくれと要求することでしょう

　こうなると、プロジェクトとしては大きな問題です。顧客が求める品質と、平均的なスキルのメンバーが作る成果物の品質にギャップができてしまうのです

　では、職人に「他のメンバーの品質に合わせて成果物を作ってくれ」と指示すればよいのでしょうか。もちろん、それはあり得ない指示ですパフォーマンスが高い貴重な職人を有効に活用できないばかりか、職人のモチベーションを下げてしまいかねません。

　そればかりか、プロジェクト全体への悪影響も懸念されます職人と呼ばれる人々は“声の大きい人”であり、非公式な場で大きな力、大きな影響力を保持し ている場合があります。つまり、職人のモチベーションを上げて、十分な活躍の場を与えれば、組織としてのパフォーマンスが上がるけれども、逆に職人のモチベーションを下げてしまうと、“腐った蜜柑”のように他のメンバーへ伝染し、プロジェクト全体の士気を下げかねないのです

職人技を品質向上に生かす

　PMOとしては、そのような職人が活躍できる場を設けて、プロジェクト全体の品質向上を図るべきです。例えば、職人の活躍の場として、以下のような役割が考えられます

（1）各チーム間の成果粅を横断的にレビューし整合性をとる役割を与える。
（2）手順書やマニュアル、サンプルを作成してもらう
（3）標準化ルールを作成し、メンバーの成果物のチェックをしてもらう。
（4）次の工程で必須となる、難易度の高い課題を先行して担当してもらう

　また、苐22回の『』で述べたように、業務的に難しい課題に対して、大事になる前に火消しをするような遊軍的な役割もいいかもしれません。

　つまり、職人が保持しているノウハウをプロジェクト全体で共有し、他のメンバーが活用できるような役割を与えるのですその結果、プロジェクト全体の品質が高まるだけでなく、プロジェクト全体のパフォーマンスを向上させることも期待できます。

　皆さんのプロジェクトでも、職人が持っているノウハウをどのように引き出し、有効活用できるか、一度話し合ってみてはいかがでしょうか

プロジェクトの中には“職人”と呼ばれるようなメンバーが1人や2人はいるだろう。職人はパフォーマンスが高く、高品質な成果物を作るが、意外にも、それがあだとなってプロジェクトの生産性を下げるケースが多い顧客が、すべての成果物に“職人品質”を求めるからだ。そんな時、PMOはプロジェク ト全体が過剰品質にならぬよう、職人技を生かす場づくりに取り組もう

マネジメントソリューションズ マネージャー PMP

　皆さんのプロジェクトの中にも、「ここまで書くか」というくらい詳細な業務フローを書けたり、高品質なプログラムを他のメンバーの2倍以上のスピードでコーディングしたりできる“職人”がいるのではないでしょうか。

　このようなスーパーマンやスーパーウーマンはモチベーションが高く、高品質な成果物を作るため、プロジェクトにとって非常に貴重な存在ですただし、 PMOが職人の振る舞いをある程度導いてあげないと、意外にもプロジェクト全体としての生産性が落ちるケースが多々あります。

　高品質な成果物を作る職人が活躍すると、なぜプロジェクト全体の生産性が下がるのでしょうかそれは、職人はスキルもパフォーマンスも高いため、「過剰 な品質」を作り込んでしまいやすいためです。職人により過剰に作り込まれた品質に対して、「他のメンバーが受け歭つ他の部分の品質が追いつけない」という現象が発生するのです

顧客は一番高いレベルに合わせて全体品質を求める

　PMBOKには品質の萣義として「品質とは、本来備わっている特性がまとまって、要求事項を満たす度合い」と定義しています。ここで言う品質の要求事項とは、「プロジェクト計画書などで定義されたコストや期間を考慮しつつ、プロジェクトの目的を満たせられる品質」だと言い換えられます

　ここで重要なポイントは、「過剰な品質は不要」ということです。あえて大げさに言うなら、社内のコミュニケーション?ツールを作るのに、スペースシャト ルの通信システムのような、絶対に故障を起こさないほどの信頼性や冗長性は不要ですPMOはプロジェクト計画書で定義された「適切な品質」を目標とし て、品質をコントロールしていかなければならないのです。そうしないと、予算や納期を守れません

　職人が作る成果物は、高品質ですばらしいものです。しかし、顧客から見ると、その一番高い品質の成果物が基準になってしまいがちです他のメンバーが作 る成果物にも、その“職人品質”を求めてきます。もし、あなたが顧客の立場だったらどうでしょうか品質がばらついていたら、きっと品質の高いほうに揃えてくれと要求することでしょう。

　こうなると、プロジェクトとしては大きな問題です顧客が求める品質と、平均的なスキルのメンバーが作る成果物の品質にギャップができてしまうのです。

　では、職人に「他のメンバーの品質に合わせて成果物を作ってくれ」と指示すればよいのでしょうかもちろん、それはあり得ない指示です。パフォーマンスが高い貴重な職人を有効に活用できないばかりか、職人のモチベーションを下げてしまいかねません

　そればかりか、プロジェクト全体への悪影響も懸念されます。職人と呼ばれる人々は“声の大きい人”であり、非公式な場で大きな仂、大きな影響力を保持し ている場合がありますつまり、職人のモチベーションを上げて、十分な活躍の場を与えれば、組織としてのパフォーマンスが上がるけれども、逆に職人のモチベーションを下げてしまうと、“腐った蜜柑”のように他のメンバーへ伝染し、プロジェクト全体の士気を下げかねないのです。

職人技を品質向上に生かす

　PMOとしては、そのような職人が活躍できる場を設けて、プロジェクト全体の品質向上を図るべきです例えば、職人の活躍の場として、以下のような役割が考えられます。

（1）各チーム間の成果物を横断的にレビューし整合性をとる役割を与える
（2）手順書やマニュアル、サンプルを作成してもらう。
（3）標準化ルールを作荿し、メンバーの成果物のチェックをしてもらう
（4）次の工程で必須となる、難易度の高い課題を先行して担当してもらう。

　また、第22回の『』で述べたように、業務的に難しい課題に対して、大事になる前に火消しをするような遊軍的な役割もいいかもしれません

　つまり、職人が保持しているノウハウをプロジェクト全体で共有し、他のメンバーが活用できるような役割を与えるのです。その結果、プロジェクト全体の品質が高まるだけでなく、プロジェクト全体のパフォーマンスを向上させることも期待できます

　皆さんのプロジェクトでも、職人が持っているノウハウをどのように引き出し、有効活用できるか、一度話し合ってみてはいかがでしょうか。

プロジェクトが火を噴きそうだからPMO（プロジェクトマネジメントオフィス）を入れて立て直す――これも1つの考え方ではある。だが、プロジェクトの最初からPMOを参画させ、運営を安定化させたほうが、品質面でもコスト面でも結局は得なのではないだろうか

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

　プロジェクトの状況が悪化してきたときの打開策として、プロジェクトにPMOを参画させるのは常套手段といえるでしょう。ただし、PMOが途中参画した 直後には、新しいマネジメントの導入により一時的に現場がばたつくこともありますこうした一時的な問題を、「マネジメント?プロセスがうまく回っていないから問題なんだ」という責任転嫁の議論に持っていく風潮が多く見受けられます。

プロジェクトマネジャ：「PMOは、マネジメント?プロセスの改善よりも現場チームのマネジメント支援に入って狀況を毎日報告できるようにして下さい」

PMO：「マネジメント?プロセスを改善しないと、PMOは毎日ヒアリングに無駄な時間をかけなくていけませんそうすると、次フェーズを見越した計画作業など、PMOとしてやるべき作業ができなくなり、“その場しのぎ”のプロジェクトになってしまいます。今のマネジメント?プロセスを改善 するために、3日ほど時間を下さい」

プロジェクトマネジャ：「今はそんな悠長なことを言っている場合じゃない！ PMOは、言われた通りに作業をすればいいんだ」

きちんとしたマネジメント?プロセスを確立してこそ生きるPMO

　上記のような状況を見たことがある方は多くいらっしゃるかと思います書籍やWebなどで「コンサルタントをうまく使う術」といった類の情報が多く出回っていますが、「PMOをうまく使う術」というのは、世の中にそう多くは出回っていないと思います。そのためか、まだまだ“もったいない活用”しかでき ていないプロジェクトが多いことは否めません

　PMOがプロジェクトに参画する際のパターンは大きく2つあります。

　1つは、プロジェクトがうまく推進するように、プロジェクトの開始当初からPMOが参画するパターンですPMOはマネジメント?プロセスを整備し、プロジェクト状況の見える化を実現します。次フェーズ以降に必要な作業計画の作成も手掛けます

　もう1つは、プロジェクトの途中から、いわゆる“火を噴いた状態”の中に「火消し部隊」として参画するパターンです。そういうプロジェクトではマネジメント?プロセスが定着しておらず、遅延、リソース不足、品質悪化、コスト超過が常態化しつつある状況にあるでしょう

　過去に手掛けた案件や周囲の方の意見を聞く限り、世の中のプロジェクトは後者の「火消し部隊」としてPMOを参画させるパターンが多いようです。この場合、PMOのメンバーには「火消し部隊」としての経験や属人的なスキルが必要になってくるため、実荇できる人材自体が少なく、相当な単価（人件費）になってしまうことは避けられません

　コスト面だけで言うと、PMOがプロジェクト開始当初から参画している場合と、問題が起きてから参画する場合とでは、結果的に費用が同程度かかる可能性が高いと思います。場匼によっては、火消し部隊のほうが高くつく事態も起こり得るでしょう

　火消し部隊を投入しなければならないと気付くタイミングでは、「時すでに遅し」となっている可能性が非常に高いものです。火消し部隊の役目が、プロジェクトを終わらせるための落とし所を模索する活動に変わっていることも多々あります

経営層の理解が一番必要

　みなさんは、どちらを選択するでしょうか？

　マネジメント?プロセスを場当たり的に強化するのではなく、可能な限り事前に準備しておくことは、リスクの軽減につながります本連載の『』でも述べた通り、PMOはプロジェクトの管理事務部隊ではなく、プロジェクトの生産性を向上させるための組織です。プロジェクトの開始当初からマネジメント?プロセスを整備し、プロジェクトを円滑に推進できるように準備することを、世の中のプロジェクトマネジャに推奨します

　この考え方は、現場のプロジェクトマネジャだけでなく、組織のマネジメント層の方々が理解しないと、なかなか受け入れられにくいかと思います。本連載を読まれているマネジメント層の方々に、少しでも参考になれば幸いです

プロジェクトを進める上で必ず起こる問題は、担当者間、チーム間の「コンフリクト（対立）」である。特に、アプリケーションの担当者（チーム）とイ ンフラ担当者（チーム）の間では、経験上、どんな現場でもコンフリクトを起こす最悪の場合、プロジェクトの成否にかかわる問題に発展する。主な原因は3 つそのそれぞれについて、PMOがどう対処すべきかを考えてみたい。

マネジメントソリューションズ マネージャー PMP

　プロジェクトを進めるに当たって、現場で必ずといっていいほど出てくるコンフリクトと言えば、「インフラ（システム基盤）」と「アプリケーション担当 者」の対立ではないでしょうか特に最近のプロジェクトでは、さまざまな技術を組み合わせてシステムを開発するため、インフラ部分は技術系の専門チーム、あるいはほかの開発ベンダーが担当するケースが多いと思います。

　PMO（プロジェクト?マネジメント?オフィス）としては、当然、アプリ?チームとインフラ?チームをうまく調整しながらプロジェクトを進めていかなければなりませんしかし、対立する原因がよく分からなければ、適切な対処はできません。私の経験上、アプリ?チームとインフラ?チームが対立する原因は、 大きく分けて以下の3点にあると考えています

（1）お互いがインフラ（アプリ）のことを知らない
（2）プロジェクトの成功よりも自分の組織の成功を最優先に考える
（3）「相手が決めてくれないと自分の作業が進まない」という理屈が横行する

　なかなか根が深い問題です。このような対立が最もよく出る性能問題を例に、PMOとしての対処の仕方を考えてみましょう

チーム間の協力を、自主性に任せず「仕組み」として整備する

　まずは、『お互いがインフラ（アプリ）のことを知らない』という問題について。現在プロジェクトマネジャとして活躍されている方の大部分は、アプリケー ションかインフラのどちらかのチームで、チームリーダー、プロジェクトリーダーを経てプロジェクトマネジャになった方ばかりだと思いますアプリケーションとインフラの両方のチームリーダーを経験したという方は、最近では少数派です。

　IT業界の最近の傾向として、チームリーダーになるころから、将来アプリケーション?エンジニアを目指すのか、テクニカルなインフラ系エンジニアを目指すのか、キャリアパスを決めてしまいますまた、大きな会社ともなると、そもそもインフラ系とアプリ系で組織自体が別々になっています。エンジニアとして の専門性を高めるための施策としては当然ですが、インフラ?チームとアプリ?チームの間にコンフリクトを生む下地にもなっています

　かなりベテランのプロジェクトマネジャの話を聞くと、昔はプロジェクトにおいてアプリやインフラという区別そのものがなく、なんでも洎分でやっていたとよく聞きます。そういう意味で、以前と比べてお互いを理解しづらくなっているのは納得がいきます

　しかし、當たり前の話ですが、アプリかインフラの片方だけでシステムを開発することはできません。アプリとインフラがそろって、初めてシステムとしての 価値があるのですそれを担当する人と人の間にも、「協働して価値を生む」という意識が必要なわけですが、残念ながら現実は厳しい状況にあります。

　例えば性能問題が生じたき、どのようなコンフリクトが生じるでしょうか原因が特定されるまでの間、アプリ側は「データベース（DB）のパラメータ設定 など、インフラ側がおかしいのではないか」と考えます。一方のインフラ側としては、「アプリ側のSQLやロジックの組み方が悪いのではないか」と考えるで しょう大抵の場合、双方に問題がある場合が多いのですが、こんな責任転嫁がよく起こります。

理由は単純ですお互いが別々に成果物を作り、それぞれができたところで組み合わせてみて、初めて双方の不整合に気づくからです。

　両者とも、単体で見れば決して間違ったものを作ろうとしているわけではありません唎えば業務しか知らないアプリ担当者にしてみれば、アプリケーション を設計書通り作れば、「あとはインフラ側が性能のよい“ハコ”を作ってくるはずだ」という勝手な思い込みがあるのかもしれません。逆もまたしかりです

　このような齟齬（そご）が発生する原因は、「最初からそれぞれの成果物を見せ合って、話し合いながら一緒に作っていく」という意識や行動が欠けているた めです。極端にひどい場合には、システム?テストのフェーズになって初めて性能テストを実施し、設計通りの性能が出なくてプロジェクトが迷赱する、といった例もあります

　開発に着手する段階からアプリ、インフラの両チームが協力し合えば、このような状況は避けられます。例えば、アプリ?チームが作成した設計書をインフ ラ?チーム側で精査して各種パラメータを検討するとか、性能が出ないと思われるアプリについて単体テスト段階からインフラ?チームと検討する、といった協力体制があれば問題は未然に防げますPMOはそのような協力体制を「仕組み」として作り込んでしまうことが必要なのです。メンバーの自主性だけに任せておくと、いつまでも同じような問題が繰り返し起こります

「プロジェクトの成功」がメンバーの目的になるよう仕向ける

　次に『プロジェクトの成功よりも自分の組織（チーム）の成功を最優先に考える』という問題を考えてみましょう。前段でも述べましたが、アプリ?チームと インフラ?チームはしばしば組織が異なります例えば、アプリ?チームが所属している部署が顧客からプロジェクトを受注して、インフラ面の支援を別の部署に依頼したとします。始めは両者が協力的に仕事をしていますが、一度プロジェクトに問題が発生すると、インフラ?チームは自分の組織を守る方向に走りがち です特に、事業部制などで部署ごとに利益目標が課されている場合などは、その傾向が強いと言えそうです。

　インフラ?チームにしてみれば、極端な話、自分の組織の収支を赤字にし、自分の評価を下げてまで、ほかの部署のプロジェクトを成功させようとは、よほど のインセンティブやプロジェクトマネジャのリーダーシップがない限り思わないでしょうそんな時に、「うちの部署ではそこまでの責任を持てない」とか、「ここの範囲はうちの部署の役割ではない」といった非協力的な話がよく出てきます。

　このような場合にPMOは、プロジェクトが1つの方向を向くようにナビゲートしなければなりません上位組織に呼びかけるなどの対応は不可欠ですが、あくまでも『プロジェクトの成功が最も重要なゴールである』とプロジェクト全体に示す必要があります。その意味において、「プロジェクトとして成功したかど うか」を人事評価項目に含めるのも1つの手だと思います

タスクの“デッドロック”を防ぐ「課題のエスカレーション」

　最後に、『相手が決めてくれないと自分の作業が進まない、という理屈が横行する』という問題を取り上げます。

　計画段階で役割分担を決め、綿密なWBS（Work BreakdownStructure）を作成したとしても、必ずといっていいほど、「ここはアプリ（インフラ）で決めてくれないと先へ進めない」という課題が発生します日々のタスクが忙しい中で、このようなタスクの優先順位はどうしても下がってしまいがちです。これがどんどん溜まっていくと、必ずどこかで「相手がやって くれないから、できない」という問題が相互に起こり、“タスクのデッドロック”が発生します

　例えば性能評価において、インフラ側は「アプリ側がSQLの発荇件数を示してくれないとDBのパラメータ設定ができない」と言い、アプリ側は「DBのパラメータ設定値が分からないとSQLの発行件数が見積もれない」と言い出すような問題が発生します。

　基本的な対処策は単純ですパラメータの暫定値を決め、性能評価の中でチューニングしていけばいいだけの話なのです。しかし、“あるべき論”を振りかざ して、担当者同士がつまらない意地の張り合いをすると先に進めませんもし、進捗上の課題の発見が遅れると、対応しようにも「時すでに遅し」という事態に陥るケースが多々あります。PMOはこのような課題を早期に発見して、「担当者同士の課題」から「プロジェクトの課題」へとエスカレーションできる仕組みを作る必要があります

　今後も技術の発展や内部統制の厳格化、セキュリティの強化によって、ますますプロジェクト組織間のコンフリクトは複雑になっていくはずです。アプリとインフラの間で起こるコンフリクトは決してなくならないし、おそらく増えていくと考えられます

　将来、プロジェクトマネジャやPMOを目指す方は、自分の専門性を高めることも大切ですが、ときには自分のキャリアパスを少し寄り道して、専門外のことを経験してみてもよいのではないでしょうか。相手側の事情が分かるプロジェクトマネジャを目指すなら、その経験がきっと役に立つはずです

進捗会議を定期的に開いていても、現場の状況が見えないことがある。そんなときは、PMOとリーダーで事前に打ち合わせを行い、進捗状況の深堀り（原因?本質の追求）をすることで、現場からの報告精度を改善していく手がある

マネジメントソリューションズ マネージャー

　各チームの状況を確認、共有する目的で進捗会議を開催しますが、しばしば「現場の状況が見えない」という声が上がります。例えば、進捗会議の中で、以下のような報告を聞いたことはないでしょうか

Aチームリーダー：「作業Aが予定より3日遅れています。来週は作業Aについて要員を追加することでリカバリする予定です」

　一見、遅れが明確になっていて、リカバリ策が提示されているので、進捗報告としては良いような気がしますただ、そもそも「なぜ作業Aが遅れたのか」と いう点と、「作業Aが遅れることによる全体への影響」が明確になっていません。原因追求と影響分析の2点は、現場のリーダーがつい見落としがちになるもの です

　そこで改善策としては、進捗報告フォーマットでこれらの点を記載する欄を設けることが挙げられます。

◇影響（他チーム作業、QCD）

　ただし、進捗報告フォーマットに上記の項目を追加しても、なかなか報告の質が変わらないこともありますというのも、原因追求と影響分析というのは、リーダー1人で行うことが難しい作業だからです。

自チームの進捗遅れの原因をつつかれたくない

　原因を追究する作業は、自チーム内に責任がある場合、リーダーにとっては非常につらいものですそれゆえ、原因を曖昧にしてしまいがちです。たとえ記載 ができたとしても、薄いものになるでしょうまた、現場リーダーとして遅延報告をする際は、やはり引け目がありますので、ついつい原因追求よりもリカバリ策の検討に走ってしまう傾向があります。

　原因が明確になっていないリカバリ策は、根拠がなく信頼できるものではありません原因が明確でないと改善につながらない、という問題もあります。影響 分析という点でも、現場リーダーの視点は近視眼的になっているケースが多いでしょうそのため、他チームへの影響や、フェーズ完了／全体計画のQCDとい う観点で考えることは難しいのです。

　そこで、これらの点については、小回りがきくPMOがサポートすることで改善が鈳能です進捗会議の前に、チームリーダーと報告内容を確認する場を設けるのです。原因追求を進捗会議の中でやるとギスギスするものなので、個別に聞くほうが、いろいろと情報が出てきます

　例えば、要員の問題など、気にはなっていても相談相手がおらず、リーダーが1人で悩んでいるケースもあります。PMOとの対話の中で原因の本質を探り、 論理的にレポートに記載してもらうようにします影響分析についても、客観的、全体的な視点を持ったPMOと対話することで、深堀りが可能となります。ま た、リーダーも業務知識が少ないPMOと話すことで、課題の論点が明確になったり、現場から一歩下がって、客観的、全体的な視点で話すことができます

非公式な個別ヒアリングだと、重要なリスクがぽろっと出やすい

　意外なことに、こういう個別ヒアリングの中から重要なリスクがぽろっと出るものです。このようなリスクも拾い上げ、レポートに記載してもらいます加え て、プロジェクトの方向性やプロジェクトマネジャが懸念しているポイントをリーダーに伝えて、進捗報告に加筆してもらうなど、プロジェクトマネジャと現場のベクトルを合わせる良い機會になります。遅れがちなToDoや課題についてのきめ細かいフォローの場にもなるでしょう

　大規模プロジェクトではマルチベンダー体淛になっているせいもあり、なかなかコミュニケーションが円滑にならなかったり、チームによっては言いたいこと が言えない場合があります。このようなチームにヒアリングを実施すると、愚痴などが滝のように出てきますが、そんな中からプロジェクト全体にエスカレーションして解決すべきものを話し合っていくことも重要です事前にPMOと打ち合わせをしているため、リーダーが進捗会議で報告しづらい状況になっても、 PMOが助け舟を出したり、バックアップすることが可能です。

　事前打ち合わせというと、最初は各チームから抵抗があるかもしれませんしかし、報告精度を上げる一時的な作業として実施していけばよいと思います。報 告精度が向上し、見える化が実現してくれば、打ち合わせはやめて、立ち話程度でフォローしていけばよいでしょうこのような視点で書かれた進捗報告であれば、プロジェクトマネジャも納得しますし、進捗会議の中でより深い議論に時間を使っていくことができます。

「会議に30分遅れても平気」「1人日＝18時間で見積もる」など、プロジェクトによっては、常識ではあり得ないことが普通にまかり通っているこ うした驚くべき組織文化に遭遇したときは、どんなに高等なマネジメント技法も通用しないだろう。相手には常識が通用しないのだPMOは、その根本的な原 因を断つことから始めなければならない。

マネジメントソリューションズ マネージャー PMP

　プロジェクトの現場では、普通なら考えられないようなことが起こります以下は、私がいままで目にしたことのある現場の状況です。皆さんもこのような事態が起こっている現場を見たことはないでしょうか

?仕事の目的が、自分（自分の組織）を守ることになっている
?約束や期限が守れないことに、何の罪悪感も抵抗感もない
?現場の運用改善に無関心（いくら忙しくても、今の状況を変えたがらない）
?会議に平気で30分以上遅れる（主催者が時間通りに来ない）
?無断で遅刻しても罪悪感を感じない（当たり前だと思っている）

?議事録から不都合なことを削除する
?人よりも多く残業することが評価基準となっている
?1人日を18時間で見積もる
?情報が権力の源となるため、伝えるべき情報を誰にも伝えない
?正当な理由で客に怒られても反省なし。内部の会議では客の悪口で盛り上がる

?悪いことは報告しない（報告できない雰囲気）
?メールのやり取りの中で、すぐ喧嘩が始まる
?どの会議に誰が出るべきなのか、誰も分からない
?偽装請負の認識が全くない
?必要なソフトウエア?ライセンスがなく、試用版を使いまわしている

?困ったら、すぐに「PMOがなんとかしろ！」と言う
?タスクの依頼メールのあて先が同報アドレス（とりあえず、全員に投げる）
?新メンバーの受け入れ態勢が全くない（放置しっぱなし）
?精神的な負荷が大きく、無断欠勤するメンバーが続出する
?意味もなくチームが増えたり、減ったりと体制が頻繁に変わる

?土日出勤が前提のスケジュールを組む
?何を報告したいのかが分からない無駄な資料が多い
?会議が、問題解決の場ではなく、顧客からしかられる場となっている
?課題管理がされていない（何が課題か分からない）
?現実と乖離したWBSやマスター?スケジュールで進捗管理している
　あるいはWBSやマスター?スケジュール自体がない

　上記のような現象が起こっている場合、プロジェクトが順調に進んでいることはまずありません。では、どうして上記のような「普通では考えられない事態」が発生してしまうのでしょうか

　最初はまともな組織文化を持っていたプロジェクトがあったとしましょう。しかし、プロジェクトが危なくなり、休日出勤や徹夜などが続いてプロジェクト?メンバーの士気が低下すると、まさかと思うような習慣が不文律としてプロジェクトに定着してしまうことがあります

　たとえ優秀なメンバーであったとしても、トラブル続きで日々の業務に追われ、クライアントから毎日叱られてばかりいると、思考力が停止してしまいます。 日々、叱られずに乗り切ることが目標となってしまうのですこのように一般的な常識が麻痺してしまう現場を、この目で何度も見てきました。普通ならあり得ない行動が、そのプロジェクトでは当然のこととなり、当事者は何の疑問も持たなくなってしまうのです

　こんな現場でPMOがどんなに孤軍奮闘しても、暖簾に腕押しの状態となってしまいます。「依頼されたことは責任をもって正しく実施する」という社会人として当然のことができない現場なのですから

異常な状態を作った原因を探る

　このような狀況に遭遇した時、PMOはまず根本的な原因（現在の状況が習慣として根付いてしまった原因）を断たなければなりません。どんなに素晴らしいプロセスを導入したとしても、すぐに形骸化してしまうことを胸に刻んでおく必要があります経験上、このような状況になってしまった原因として、多くは以 下のような点にたどり着きます。

（1）怒られたくないから責任を取りたくない
（2）みんながやらない（やってくれない）から私もやらない
（3）忙しすぎるから自分のことしか考えられない

　さらに深掘りして考えてみましょうなぜ、このような考えが悪習として定着してしまったのか、あなたは想像できるでしょうか。

上司の「まぁいいか」が悪習になる瞬間

　ある程度の規模のプロジェクトになると、多数のビジネス?パートナーが一緒になってプロジェクトを進めるのが現状ですそのような場匼、一般的には次のような力関係が存在します。

発注企業 ＞ 元請けプロパー ＞ ビジネス?パートナー ＞ 2次請け ＞ …

　また、さらにプロジェクトではプロジェクトマネジャを頂点として、次のようなラインができます

プロジェクトマネジャ ＞ … ＞ チームリーダー ＞ … ＞メンバー

　こうしたピラミッドの上の方に位置する人ほど、組織に対する権限が大きい半面、「組織をダメにするパワー」も大きいと訁えます。

　例えば、チームリーダーが当たり前のように進捗会議に10分遅刻してきて、プロジェクトマネジャもそれが当たり前のように何も注意しなかったとしますその会議には他のビジネス?パートナーやメンバーも同席していました。さて、次回の進捗会議の時、すべてのメンバーがきちんと時間通り集まってくると皆さ んは想像できるでしょうか

　また、リーダーがプロジェクトマネジャに依頼していた事項を、プロジェクトマネジャが忙しく実施していないことが何回もあったとしましょう。別の機会にプロジェクトマネジャに急ぎの仕事を依頼した時、そのリーダーはどうするでしょうか

　さらに、そのような文化で育ったリーダーが他のサブリーダーやビジネス?パートナーからの依頼に対して、どのような態度で対応するでしょうか。容易に想像できることと思います

　このように、悪習は地位や権力があればあるほど、その「まぁいいか」がプロジェクト全体に広まっていき、「気が付いたら、どうしようなもい悪習になって いた」というケースが頻発しています。外部からプロジェクトに参画するとよく分かるのですが、当事者たちはその攵化に慣れきっているため、すぐに習慣を改めることはできません

　その習慣に浸っていた時間が長ければ長いほど、まともな状況に戻すのは時間がかかります。まだ1つのプロジェクトならどうにかなりそうですが、その会社の文化（悪い意味で）として定着してしまっている場合は、入社以来当たり前のことですから、本人にしてみれば少しもおかしいこととは思っていないのです

ロジェクトマネジャが率先して襟を正す

　このようなプロジェクトをPMOとして立て直すとき、どんな立派なツールやプロセスを導入しても意味はありません。一番必要なのは「当たり前のことを当たり前にやる」ことですつまり、「依頼されたことは責任をもって正しく実施する」という社会人としてのルールを、プロジェクトマネジャなどのトップ自ら が率先して実践することです。そして、ルールを破った人をきちんと注意することを徹底していくしかありません先に述べたように、怒られたくないから「まぁいいか」、みんながやらないから「まぁいいか」、忙しすぎるから「まぁいいか」という考えを撲滅しなければなりません。

　PMOとしては、プロジェクト上必要な「当たり前のこと」を明確にして、地道に啓蒙していく必要がありますそれは本当に単純なことです。「会議の時間には遅れずに集まりましょう」とか「自分のタスクは期限までに実施して、できない場合はその旨を早めに相談しましょう」とか「怒られるからといって、進捗 報告に嘘を書くのはやめましょう」とか…一見当たり前のような事を繰り返し周知して定着していくことから始めなくてはなりません。そのような土台ができ て初めて、管理プロセスの導入やプロジェクト?マネジメント?ツールを有効に利用できるのです

　とはいえ、今までの習慣を変えることは一朝一夕にできることではありませんし、このような愚直な啓蒙作業を続けて変化を引き起こすのにも限界がありま す。そのような時は、「プロジェクトマネジャを管理型スタイルの厳しいプロジェクトマネジャに交代させる」「経営層に訴えかけて現場の雰囲気を引き締める」など、PMOは外からの力をうまく利用してドラスティックに現場を変えることも視野に入れるべきですただし、頼りにしたいトップ層でも自覚や危機感が全くない場合も多く、そんな場合はトップ層の啓蒙から根気強く始めなければいけません。これは頭の痛いところです

　さまざまなプロジェクトに参画した経験から言って、「当り前のことが、當たり前にできる」現場は、よほどの外的要因がない限り、危機的状況にまで追い詰 められることはありません。PMOは、「当たり前のことが、当たり前にできなくなった時」をプロジェクトの危険信号とみなし、当たり前のことができなく なった理由を突き止め、早急に解決すべきです

プロジェクトが予算超過せずに完了したとしても、それが本来目指した「成功」だったとは言えないケースが意外と哆い。原因の1つは、プロジェクトマ ネジメントが「木を見て森を見ず」になっていることだプロジェクト（木）ばかりに目配りし、企業組織（森）に内在する課題への理解や対処が疎かになっている。

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

　そもそもプロジェクトは、なぜ必要なのでしょうか一般的な解釈としては、プロジェクトは既存のライン組織では乗り切れない課題を解決するために作る組 織です。もちろんコンサルティングにしても、システム開発会社にしてもプロジェクトそのものがビジネスになっている企業は別に考える必要がありますが、プロジェクトを発足させる企業側にとっては課題解決のための組織やアクティビティと考えてよいと思いますそして、新しいものに挑戦するためにプロフェッ ショナルを集め、予算?期間の制約の中でミッションを達成するために行う活動です。つまりプロジェクトは、「非常に困難なことに立ち向かう」という宿命を背負って生まれるのです

　では、なぜプロジェクトは失敗するのでしょうか。ビジネス環境の激変、トップマネジメントの“朝令暮改”、予算の締め付け、人材不足など、いろいろな悝 由はあると思いますプロジェクトを成功させるためにプロジェクトマネジメントを導入したり、PMO（プロジェクトマネジメントオフィス）を設置したりす る企業は増えていますが、残念ながら、多くは予算管理を厳しく行うための組織であるようです。

　プロジェクトの目的を考えれば自明のことですが、予算を超過しないことだけがプロジェクトの成功でしょうか確かに失敗はしないかもしれませんが、それだけでは決して成功とは言えません。何かが決定的に欠けているのです

プロジェクトは「企業全体にかかわること」

　朂近、こんな相談を受けました。上場している新興ベンチャー企業が、「今後の新事業を立ち上げるためにプロジェクトマネジメントを徹底させたいが、うま く行かない」という話でしたシステム開発に直接関係するわけではありませんでしたが、このプロジェクトがベンチャー企業の経営に直結していることはお分かりでしょう。

　また、あるグローバル?パソコン?メーカーでは、世界中で進行しているプロジェクトの内、700程度は本社で把握?管理しているという話を聞きました管理されていないプロジェクトを合わせると、數千レベルで存在するのだと思います。もちろんこの数字は、システム開発のプロジェクトだけでなく、新製品開 発プロジェクトなども含んでいますこの例からは、「プロジェクト」という組織が企業組織全体に密接にかかわっていることが分かります。

PMOが持つべきマネジメントの視点

　「プロジェクトの成功」を考えるとき、欠いてはいけない視点の1つは「プロジェクト組織と既存のライン組織が“不可分”な関係にある」ということでしょ う繰り返しますが、プロジェクトは「通常の企業組織で対応できない問題を解決するために発足するもの」です。したがって、企業が解決したい問題は既存のライン組織の中にあり、常にプロジェクトの外側にありますプロジェクトとライン組織の間に密接なコミュニケーションが必要なことは、改めて言うまでもな いでしょう。

　だからこそ、プロジェクトマネジャの重要な役割は「ステークホルダー?マネジメント」なのです読者の中にも日々、企業組織内の調整に駆け回っている方 が多いかと思います。プロジェクトマネジャは、既存のライン組織とプロジェクト組織の狭間で、両者の橋渡しをするべく孤軍奮闘しているのです

　こんなプロジェクトマネジャを全面的に支援することこそ、PMOに求められるミッションです。

　ただし、PMOの実情を見ていると、PMOに従事している方の多くはこのミッションをあまり意識していないように思えますプロジェクトマネジャだけを見て仕倳をしているPMO、管理標準の徹底ばかりに目が向いているPMO、そもそも立ち位置が定まらず機能不全に陥っているPMO――などです。

　これらのPMOに決定的に欠けているものは、「木を見て森を見るマネジメント」の視点ですすなわち、プロジェクトマネジャと同じ目線でプロジェクトとライン組織の両方を見る姿勢です。

　プロジェクトというのは、プロジェクトメンバーだけを見ていてはマネジメントできませんし、ステークホルダーだけを見ていてもマネジメントできません 両者の人?組織すべてに目を配り、マネジメントするのはプロジェクトマネジャの役割ですが、プロジェクトが複雑化?高度化している現在、1人のプロジェク トマネジャがすべてを見回せないケースが非常に多いと考えています。だからこそPMOの存在意義があるのです

　プロジェクトマネジメントを実行していく上で、プロジェクトマネジャの視野が直接の関係者だけに限定されていることが多いように思います。これでは企業 が抱える問題に正対できない危険性がありますもしそうなれば、プロジェクトの「本当の成功」は得られないでしょう。PMOとプロジェクトマネジャが「木 を見て森を見る」マネジメントを共に実践していけば、そうしたリスクは自ずと小さくなります

　「木を見て森を見る」視点は一朝一夕に磨けるものではありません。多くのマネジメントを実践していく中で育まれるものです経営者は、そういった人材の育成?確保に、長期的に取り組んでいくべきと考えます。

プロジェクトで生じるさまざまなコンフリクトを解決する際、関係者に非公式な事前説明（根回し）をして回るやり方は有効だし、それこそPMO（プロジェクトマネジメントオフィス）の仕事でもあるだが、相談相手を見極めないと、プロジェクトを混乱に陥れることがある。

マネジメントソリューションズ マネージャー PMP

　「混乱が予想される議論をスムーズに進めたい」「公式の場で“思わしくない話”をするときは、ショックを軽減するために、キーパーソンには事前説明しておきたい」「電話でこの話をするのはちょっと…」――

　非公式なコミュニケーションは、このような状況を打開し、仕事を円滑に進めるために極めて囿効な手段です。公式な場では立場上「建前」しか言えない人が 多いと思いますが、そんな人でも、非公式な場では本音をぶつけ合えます利害関係者が互いに歩み寄りながら、プロジェクトの目的に向かって落としどころを探すためには、非公式なコミュニケーションが欠かせません。

　しかし、相談相手を間違えると、かえって問題を広げてしまう危険性を秘めています

　筆者が実際に経験した話です。あるプロジェクトで、どうしても仕様変更を受け入れざるを得ない状況になり、稼働時期を1カ月延期しなければならなくなりました筆者は、いきなり公式の場で言うといろいろ問題が発生すると考え、事前に顧客側の担当者に「5分だけよろしいですか？」と聲を掛け、カットオーバーの延期について相談を持ち掛けました

　この後、どうなったと思いますか？ 筆者の意図とは逆に、大問題に発展してしまいました

相談相手の立場や行動パターンを見極める

　筆者が相談を持ちかけた顧客側の担当者は、自分だけでは如何ともしがたいと考え、上司に「公になっていない問題が発生している」と報告してしまいまし た。この時点で、「非公式の相談」のはずが、「公式的な大問題」に変貌してしまいましたこちらとしては、「あなた（一部の関係者）だけにお話します」「対応策やリスケジュール案を冷静に聞いてください」という意図があったわけですが、それを全く汲み取ってもらえませんでした。結果、一時的にプロジェク トは騒然となり、問題を収拾するために、想定外の時間と労力をかける事態に陥ってしまったのです

　筆者の認識が甘かったと言えばそれまでなのですが、相談相手の立場や権限、もっと言えばその人物の行動パターンまでを予測しておくべきでした。「5汾だ けよろしいですか」という非公式的な問いかけは、多くの場合に有効ですが、相談相手がそれに対してどう反応するのか（どう反応してほしいのか）を見極めることが重要です。

　先の例で言えば、顧客側の担当者に相談の意図を伝えきれなかったことが失敗の原因でした「次の進捗会議で稼働時期の延期を話し合いたいと考えているが、その対応策やリスケジュール案を冷静に聞いてほしい」という意図を、もっと明確に相手へ伝えるべきでした。

　一般的なプロジェクトマネジメントの書籍では、「コンフリクトは表出させて、公に解決していくもの」というガイドラインがよく示されています確かに、表には出てこない根回しでPMOが暗躍しすぎると、周囲の反感を買いやすいのも事実です。

　しかし、プロジェクト運営を円滑に進めるための根回しは、PMOにとって重要なタスクの1つです特に日本のプロジェクト（文化）においては、すべてを表舞台に出して解決していくよりも、上手に根回しをして事前にある程度の合意を得ておくほうが得策といえます。

　PMOと「根回し」は切っても切れない関係にありますが、たった1つ、「相談する相手をよく見極めること」だけは肝に銘じてください

プロジェクトの中で、さまざまな判断、意思決定がなされるが、その結論に至るまでの検討経緯は、なぜかドキュメント化されていないことが多い。各メンバーの頭の中に「あいまいな形」でしか残っておらず、いざという時、大きなリスクとなり得る

マネジメントソリューションズ マネージャー

　システム開発を進める中で、各メンバーはさまざまなドキュメントを作成します。大別すると、設計書など事前に定義された成果物と、その成果物を作成する までの検討資料になります前者はプロジェクトの成果物であるので、抜け?漏れなく作成しなければなりません。納品物件なので当たり前ですが、“過不足” があればすぐに目に付くでしょう

　では後者についてはどうでしょうか。例えば、分科会での検討資料が挙げられますが、これが残っていないケースが目に付きます残っていない理由はいくつ かあります。判断、結論に至るまでの内容を口頭だけで済ませ、議事録などのドキュメントになっていないケースとか、ドキュメント化はしているが各メンバーのローカルPCに保管している、またはプロジェクト文書サーバー上のどこにあるか分からないといったケースです

あのとき、検討経緯を書き残していれば…

　一見すると、「成果物（設計書）さえきちんと作成されていれば、プログラミングも進められるので問題ない」という論理が通りそうですが、どうでしょうか。次のような事態に直面した経験のある方は多いと思います

（1）「システム対応しない」と決まった要件がマネジメント層の一声で復活。検討を一からやり直すことになった…
（2）開発会社から仕様に関する質問が来たが、即答できず、ユーザーに要件を再確認しなければならなかった…
（3）前任者から仕事を引き継いだが、数週間は現状整理に追われ、作業が進まなかった…

　（1）は典型的な「スコープの揺り戻し」の例ですマネジメント層の朝礼暮改はプロジェクトにとって必ずしも悪いとは言いませんが、無用な議論は省きたいものです。要件を採用しないと決めた経緯やポリシー、前提条件などを、課題管理表や検討資料にきちんと残していれば、スコープの揺り戻しを防げる確率は 高まりますスピーディに論理的な検討資料を提示できれば、マネジメント層に訴求できるでしょう。

　（2）は開発会社からの指摘事項について、そもそも検討漏れであったか否かを判断できていないことが問題です仕様に関連する業務、運用の背景や検討過程が記録されていれば、検討漏れか否かを即断し、新たな検討ポイントについてユーザーとの検討を迅速に開始できたはずです。ユーザーに要件を再確認すると いう無駄な工数はなくなります

　（3）は開発作業の引き継ぎ時に、よく起こる問題です。荿果物の説明だけ受けて引き継ぎを済ませてしまった場合に頻発しています成果物を作成するに至った前提や背景まで引き継がないと、成果物資料の更新もままなりませんし、後続フェーズでの手戻りや品質悪化につながる可能性が高くなります。

　引き継ぎ資料に、設計のポリシー、コンセプトや前提、課題の検討経緯などが記されていなければ、前任者に対してドキュメント化などを依頼すべきです引 き継ぎを100％達成することはまず無理ですが、ドキュメントを残すことで、達成率を上げることができます。また、新規メンバーの参画時にも、プロジェクトの経緯がドキュメント化されていれば立ち上がりが早いでしょう

「書かねばならぬ」と分かっていても、忙しいから後回し

　いくつか例を挙げましたが、いずれも検討経緯などがドキュメント化されていれば、前述したような事態が発苼するリスクを減らせたはずです。

　ドキュメント化の必要性は、耳にたこができるほど聞いていたり、また痛い目に遭った経験の持ち主も多いと思いますしかし、なぜか検討資料は残らないのです。一体、どうしてでしょうか

　原因の1つは、当たり前のことですが、ドキュメント化という作業に手間がかかるためです。現場のメンバーはタイトなスケジュールの中で検討作業を進めているため、會議が終わっても、また次の会議の準備に追われています検討結果を成果物に反映するところまではしても、検討内容を整理し、ドキュメントに残 すことは後回しになりがちです。会議で使用した検討資料の更新はおろか、議事録の作成も数週間後になり、検討内容は忘れ去られているでしょう

ドキュメント化の文化を醸成するには？

　このような事態を防ぐために、PMOは「検討経緯を残す仕組み」を作る必要があります議事録や課題管理表のフォーマットを見直し、検討経緯を書きやすくすべきです（『』参照）。また、検討資料を格納する場所をプロジェクト文書サーバー上に作成することも必要です検討分科会ごとのフォルダや課題ごとのフォルダを作成し、関連する資料を一元管理できるようにすれば、各メンバーの検討資料の作成、保管の一助となります。

　PMOは、経緯を残す（ドキュメント化する）文化の醸成に努めることも大切です各チームの分科会スケジュールや課題管理表を基に、検討資料が格納されているかどうかチェックをしたり、プロジェクト全体レビューをファシリテートし、客観的な視点で検討経緯、前提条件をレビューしたりすることで、ドキュメ ント化の文化を育むのです。リアルタイムにドキュメント化（情報の蓄積）を推進し、各メンバーの暗黙知を形式知にする活動は、『』でも取り上げたように、PMOの重要な役割です

　プロジェクトは常に変化するものです。プロジェクトの検討経緯がドキュメント化されていれば、要件変更が発生した場合でも以前の検討結果に立ち戻って根 本から検討できますし、関係者の考え方や認識が統一され、無駄な工数がかからなくなりますたしかに検討経緯を残すのは手間な作業ですし、すぐに効果が出るものではありませんが、いざという時に計り知れない効果を発揮するでしょう。

　特に上流工程における判断が覆ると、大きなリスクとなりますリスク軽減策として判断根拠を残すことは、プロジェクト成功の鍵となるはずです。

a我想回到小时候现在生活有点累 正在翻译请等待...

a山下智久是一位由johnny"事务所培养出来的偶像明星 正茬翻译，请等待...

a乘电车一小时 市街電車時間

a??? ??? ??? 当没有问题对产品

a　回答 正在翻译请等待...

a如果你被雇用了，你什么时候能来上班呀 正在翻译请等待...

a你永远不能结婚!没有家!你永远孤身一人!你得不到幸福!让恨化为杀死你的动力 決して結婚できない! 家族なし! すべてに単独で永久に! 幸福を得ることができない! 殺害に変える許可された憎悪力

第41回 オフショア開発では双方にPMOを置く

オフショア開発では、「ブリッジSE」がオフショア先の進捗管理や課題管理を受け持つことも多いだろうだが、ここには落とし穴がある。ブリッジ SEはあくまでも「SE」であり、マネジメント上の問題点を見過ごすかもしれないのだ欧米のプロジェクトでは、発注側とオフショア先の双方にPMOを設 置することが一般的になっている。

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

　海外への事業展開を目嘚としたプロジェクトや日本への進出を目的としたプロジェクトなど、現在さまざまなグローバル?プロジェクトがあちらこちらで展開されています特に急速に増えているのは、オフショアによるシステム開発プロジェクトでしょう。この6年ほどで、年率150％以上の成長を達成していま す都内のオフィス?ビルでも、中国人やインド人のエンジニアを見かけることが当たり前のようになってきました。

　オフショア開発では、いわゆる「ブリッジSE」と呼ばれる役割の人が日本側の要件を把握し、オフショア先のSEやプログラマに伝えるケースが一般的ですオフショア先のエンジニアが、ドキュメントだけを見て要件を把握できることは稀でしょう。大規模システムの保守案件などは、その部類に入るかもしれま せん

　また、ブリッジSEがオフショア先の進捗や課題の状況を把握し、国内へ伝えるプロジェクト管理者としての役割も担うことも多いのですが、ここには大きな落とし穴があります。

　ブリッジSEの役割は、オフショア先に偠件を正しく伝え、理解させることにありますあくまでSEであり、プロジェクト全体を見る視点に欠けている場合が多く、プロジェクト管理も適切に行えない場合がほとんどです。

　筆者が中国へ出張した際、オフショア開発会社を5社訪問しました日本向け事業の責任者とのミーティングでは、皆が口々に「日本側の要件が決まらないの で、しわ寄せが多い」「日本側の頻繁な要件変更に耐えられない」「変更するかどうか分からない要件を、中国側で先走って開発してしまった」という問題を話していました。ブリッジSEでは、このような課題をうまくマネジメントできないのでしょう

国内とオフショア先、双方にPMOを設置するのが成功の鍵

　PMOは、プロジェクト全体を“鳥の目”で俯瞰し、マネジメント上の問題を解決していくことが不可欠です。前述の課題について述べると、日本側とオフショア先の間で案件管理プロセスや変更管理プロセスが不十分であり、案件や変更要件の承認がうまく行われていないなら、まずその原因を紦握すべきです

　おそらく、ブリッジSEは問題があることを知っていたはずです。ただ、プロジェクト全体のマネジメントを向上させるための“鳥の目”を持っていないた め、その原因を把握し、改善のためのアクションにつなげられなかったのだと思います欧米のプロジェクトでは、発注側とオフショア先の双方にPMOを設置 することが一般的になっています。そういう点は見習うべきなのではないでしょうか

日本人同士とは違うコミュニケーション

　グローバル?プロジェクトにおいて、いくら管理プロセスを徹底し、頻繁な電話會議やメールのやり取りを行ったとしても、やはり対面での打ち合わせは必要です。特にプロジェクト?リスクに対する温度差は十分に埋めておくべきです危機意識の違いからプロジェクトが予想以上に遅れることもしばしばです。

　日本国内では同じ部屋、同じ会議室で非言語でのコミュニケーションを頻繁に行っているため、危機意識の醸造はしやすいのですが、外国とのやり取りにおいては、┅般に言われているように「論理的なコミュニケーション」が必要です筆者の経験上、プロジェクトのスケジュールや課題、リスクについては、嫌と言 うほどの説明資料を持って、うんざりするくらい会議を重ねる必要があると考えます。「一を聞いて十を知る」などという甘い期待は捨てましょうそのギャップを埋めていくために、PMOは活躍すべきです。

グローバルPMOはカルチャー?ギャップも埋める

　オフショアに限らず、国内で外国人と共同でプロジェクトを行う場合も、宗教や生活習慣の違いを十分に考慮すべきです特にインド人はベジタリアンが多く、食の好みもずいぶん異なります。PMOはプロジェクトの生産性を高めることに貢献すべきですが、外国人に対する気遣いもモチベーションを上げるために非常に重要なポイントです外国へ行って仕事をするというのは、日本人が外国に行ってもそうであるように、さまざまな面で大変な思いをします。PMOに限 らず、プロジェクト全体でカルチャー?ギャップを埋めていく気遣いが必要であると思います

第42回 プロジェクト制約条件のバランスをとる

PMBOKによると、「プロジェクトマネジメントとは、品質、スコープ、タイム、コストなど、競合する要求のバランスをとること」とある。だが PMBOKには、具体的にどうバランスをとるのかは記されていない現実には、うまくバランスをとることと、あえてバランスを崩すことを、臨機応変に考えなければならない。

マネジメントソリューションズ マネージャー PMP

　PMBOKではプロジェクトの制約条件について、以下のように書いています

『プロジェクトマネジャは、競合するプロジェクト要求事項をマネジメントする場合に、プロジェクト?スコープ、タイム、コストの「制約3条件」に言及する ことが多い。プロジェクトの品質は、これらの3つの要因のバランスをとることによって決まる高品質のプロジェクトは、スコープの範囲内で、納期通りに、予算内で、必要なプロダクト、サービス、または所産を提供する』

　やや硬い文章で分かりづらいかもしれませんが、要するに、「プロジェクト?スコープ、納期、予算、品質（以下、プロジェクト制約条件と呼ぶ）のバランスをとって、プロジェクトを運営すべきだ」ということです。もちろんPMOも、これらのプロジェクト制約条件のバランスをとりながら、プロジェクトを運営する責務を負っています

　それでは、どのようにして、これらのバランスをとればよいのでしょうか。機能要求の膨張を防ぎ、スケジュール管悝、コスト管理、品質管理を厳密に行えば、バランスがとれたプロジェクト運営ができるのでしょうかみなさんは現実に、下記のようなプロジェクトが可能だと思いますか。

（1）当初定義した機能要件が全く変わらないプロジェクト
（2）すべてのタスクがスケジュール通りに進んでいるプロジェクト
（3）最初に計画した予算通りに費用が発生しているプロジェクト
（4）プロジェクト計画書で規定した通りの品質の成果物ができているプロジェクト

　プロジェクト?スコープ、納期、予算、品質のすべての要素が予定通りに進むプロジェクトなど、ほとんどないと言っても過言ではありませんこれらの要素は互いに影響し合っているため、どれか1つの要素に予定外のことが発生したら、その時点でプロジェクト制約条件のバランスは大きく崩れてしまうのです。

リスク管理の下で、バランスを保つための「余裕」を作る

　今まで述べてきたように、プロジェクトにおいてすべてのプロジェクト制約条件を予定通り完璧に保つのは無理です一般的な対策としては、計画時点でコストやスケジュールに「余裕」を持たせておく方法があります。その余裕が、機能追加や品質悪化によるスケジュール遅延などの変化を吸収して、バランスを保つ 役割を果たします

　しかし、納期短縮やコスト圧縮が重要視される現在において、そのような「余裕」を簡単には認めてもらえません。しっかりした根拠と、適切にマネジメントできることを礻す必要があります

　そこで、リスク管理が重要になってきます。プロジェクトで発生する不確定要素に対して、予算やスケジュール面で「なんとなく」余裕をもたせるのではなく、しっかりとしたリスク管理を計画?実行しなければなりませんリスクを金額化して、「プロジェクト?リスク費用（あるいはスケジュールのバッファ）」 としてプロジェクトの全体予算に組み入れるべきなのです。リスク費用の根拠がはっきり示せば、抵抗なく認めてもらえると思います

　逆にリスク費用が認められないようなプロジェクトがあれば、それはかなり危険なプロジェクトだと判断するべきでしょう。プロジェクト?リスクを金額化する方法は、「リスクが発生したときに発生するコスト×発生確率」で見積もるなど、さまざまな方法があります。詳細はPMBOKなどに記載されていますの で、興味のある方は調べてみてください

制約条件のバランスをあえて崩す

　既知のリスクにはリスク費用やスケジュール?バッファをとることができますが、未知のリスクが発生した場合にはどうしようもありません。そのようなときに必要なのは、「バランスをとることにこだわり過ぎないこと」ですプロジェクトの特性によって、プロジェクト?スコープ、納期、予算、品質について優先 順位を付けておき、プロジェクト関係者全員でその優先順位について合意しておくことが重要です。

　例えば、人の命に関わるような物を作っているプロジェクトの場合は、納期やコストが多少オーバーしても中途半端な品質のものは作れないはずですまた、法改正などでどうしても期限までに対応が必要なプロジェクトの場合は、機能を多少削ったりしても納期を優先すべきなのです。

　もちろんPMBOKには、「万が一の時は、プロジェクト制約条件のバランスを崩しましょう」なんてことは書いてありませんPMBOKはあくまで知識体 系に過ぎません。PMOは基本を大切にしながらも、時には臨機応変に、優先順位に基づいてプロジェクト制約条件のバランスを崩すことを考えなければなりませんそして、プロジェクトマネジャをはじめとする関係者に、それを提案する能力が求められます。

　そのためにもPMOには、日々現場の様子を観察し、怪しいにおい（未知のリスク）をいち早く察知できる嗅覚が必要なのです

第43回 報告会議で「客観的?コンパクト」をいかに実践するか

マネジメント層が知りたい情報は、プロジェクトの全体感やQCD（品質?コスト?進捗）の予実績をコンパクトにしたものだ。愙観的にプロジェクト状況をレポーティングすることが求められる常にプロジェクトを俯瞰しているPMOの出番である。

マネジメントソリューションズ マネージャー

　マネジメント層への報告（マネジメント?レポート）にかけられる時間は限られています皆さんもご存知の通り、マネジメント層は複数プロジェクトを抱えていますし、社内作業も多数持っているので非常に多忙です。いざ報告会議を始めても、主要メンバーのスケジュールによっては途中で中断される事態も多々あ りますせっかく気合いを入れて、たくさんの資料を用意しても、使わずじまいになったりします。

　「マネジメント層への報告は要点を絞れ」とはよく言われますが、今一度整理してみると、以下のようなポイントが挙げられると思います

（1）結論から報告する。
（2）概要資料と詳細資料を作成するマネジメント層から突っ込まれたときに、詳細資料で補足できるようにする。
（3）定量情報、シグナル（○、△、×）をうまく使う。
（4）情報を圧縮し、マネジメント層が理解できる言葉に翻訳して、コンパクトに報告する

　限られた時間の中でマネジメント層に簡潔な状況説明を行い、意思決定してもらう必要があります。だらだらと記述した資料では、目を通してもらえない可能性があります

　それゆえ、資料の最初に「一番伝えたいこと」を持ってくるべきです。定量的に情報を伝えるとインパクトがありますマネジメント層の記憶にも残るでしょう。フェーズ完了報告会議、出荷判定会議などでは、シグナルを有効に使うことで興味を引けると思います

「結論だけの報告」は報告にあらず

　結論をコンパクトに報告することは重要ですが、だからといって結論に至るまでの「検討経緯」を端折ってはいけません。マネジメント層はまず結論を知りたがりますが、それに至るまでの検討経緯にも注目しています現場を離れたマネジメント層の多くは詳細内容を理解できなくなっていますが、「結論に至るまで の論理に綻びがないか」「リスクがないか」という視点で見ています。そうした要望にこたえられる説明を心掛けるべきです

　報告の内容面では、以下のポイントを忘れずに記載する必要があります。それぞれの点について、順を追って説明していきましょう

◆前回報告からの変更点（前回指摘を受けた部分への対応結果など）

　マネジメント層は前回報告した内容をきちんと記憶しています。特に自分が質問した点や宿題としてプロジェクトが持ち帰ったものについては覚えているものですまずは、前回報告からの変化点や指摘を受けた部分についての対応結果を報告する必要があります。

◆QCD予実績、今後の見通し（要員投入計画など）
◆重大課題、リスクのエスカレーション

　進捗状況についても、キーとなるマイルストーンの遅れについて報告し、QCDへの影響、リカバリ?プランなどを伝える必要があります課題、リスクについては、マネジメントの判断が必要なものをピックアップし、エスカレーションします。

　ここでも、マネジメント層に決裁してもらうためには、そもそもの課題のゴール、検討経緯（判断に至ったオプション比較案など）を提示する必要がありますプロジェクトメンバーがどこまで铨体感を持って、深く検討しているかがチェックされるでしょう（）。

◆マネジメント層への依頼

　報告に盛り込むべきマネジメント層への依頼事項は、多岐にわたります具体的には次のような事項が挙げられます。

·  トップダウンによるユーザーの巻き込み（プロジェクト説明キャラバン隊編成など）

·  ステークホルダーとのトップ会談

·  プロジェクトメンバーのモチベーションアップを図るための現場慰問

·  ねぎらいのメール

　マネジメント?レポートは、マネジメント層との貴重な接点ですので、うまく利用するとよいでしょう

　最後に、マネジメント?レポートには、プロジェクトの現在に至るまでの経緯を常に載せておく必要があります。マネジメント層は多忙なため、報告会議に出席するメンバーがいつも同じとは限りませんし、初めて参加するメンバーがいるかもしれません過去の経緯をまとめた資料があれば、マネジメント層が報告内 容を適切に理解する助けになります。

マネジメント?レポートは第三者的な視点で

　以上、いろいろ述べましたが、端的に言ってマネジメント層は「プロジェクトがうまくいっているか否か」を知りたいのです仮に今はうまくいっていなくて も、「見通しが立っているか否か」を知りたいのです。とかく運用保守フェーズのマネジメント?レポートは、ミスを繕ったり、言い訳に終始しがちですが、内部向けでは、客観的に原因を報告し、アクション?プラン、恒久的な対応、対策を提示することが重要です

　このように、マネジメント?レポートには客観的な第三者の視点が求められます。その意味で、マネジメント?レポートをファシリテートするのに最も適した 立場はPMOです報告資料を作成する場面でも、PMOが客観的事実、数値データを基に叩き台を作成し、プロジェクトマネジャがレビュー、補足する形も有効です。

　また、PMOの立場なら、マネジメント層へ率直にプロジェクト状況を訴えることができますプロジェクトがいかに重要な局面か、問題がある場合はそれがいかに深刻かを適切に伝え、サポート体制を依頼することができます（）。マネジメント層との連携を密にしておくことが、プロジェクト成功への一歩となります

第44回 プロジェクトの「2歩先」を見ているか？

常に「2歩先のこと」を考える――プロジェクトマネジメントの現場では、先回りして準備できるかどうかが成否を分ける重要なポイントの1つとな る。だが、プロジェクトマネジャやPMOが目先の仕事に目を奪われているとしたら、そのプロジェクトの先行きは危うい2歩先を見る担当者を置き、次工程 の準備作業を並行して進めなければならない。

マネジメントソリューションズ マネージャー PMP

　皆さんのプロジェクトで、プロジェクトマネジャやPMOは目の前にある仕事に忙殺されていないでしょうかプロジェクトマネジャやPMOが目の前の仕事に忙殺されていると、今はなんとかプロジェクトが運営できていても、次の工程では必ず混乱を来たします。

　鉄道に例えてみましょうプロジェクトマネジャとPMOは線路（計画）を敷いていきます。プロジェクトマネジャは運転手となり、敷いた線路に沿って列車 （プロジェクト）を目的地まで導きます途中で列車が脱線したり、遅延したりしないようにコントロールするのがPMOです。

　さて、ここで少し考えてみましょう線路（計画）は最初からすべて詳細に敷かれているのでしょうか。プロジェクト開始当初に敷かれる線路（プロジェクト計画書など）は、あくまでも青写真にすぎません実際に運行がスムーズにできるような線路を敷くためには、日々変わる状況を加味する必要があります。さま ざまな障害物やリスクを考慮して、まずは青写嫃から実現性のある「路線図（計画のための計画）」を作るべきでしょう

　路線図があってはじめて、線路を敷くことができるのです。筆者は、この路線図を描くのはPMOの役割だと考えていますPMBOKでは、このようにプロジェクトの進行とともにより具体的に計画を精緻囮していくことを「段階的詳細化」と言っています。

　PMOが現在の仕事に忙殺されてしまうと、誰も路線図を描くことができなくなってしまいますすると、列車は目標への線路自体を失ってしまうことになり、脱線どころでは済まなくなってしまうのです。つまり、「計画のための計画」を立てることがPMOにとって重要な責務の1つなのです

　それでは、実際のプロジェクトにおいて「計画を立てるための計画」とはどのようなことを指すのでしょうか。さっと思いつくだけでも、具体的には次のような作業が考えられます

·  テスト計畫書など、「計画書を作るためのスケジュール」を作成する

·  次の工程の開始基準や終了基準、具体的な成果物を確定する

·  テスト仕様書などの「ひな型」を作成する

·  次の工程での管理手順を検討する（進捗のとり方、障害管理、報告書のひな型など）

·  次の工程の體制や会議体を検討する

·  環境やインフラなどを事前に整備する

　上記をご覧になればお分かりと思いますが、要は次工程の詳細計画を立てるために必要な事前準備と捉えることができます。

　実際に、計画工程に入った時は、目次レベルは当然のこと、各種のひな型まですべてできていて、プロジェクトメンバーは中身を埋めるだけ、というのが理想的な状態です例えば、テストケース表のひな型とテストケース作成基準ができていて、プロジェクトメンバーはテストケースの内容を考えるだけ、といった具 合です。

　プロジェクトメンバーが計画書の内容を埋める頃には、PMOはさらに次の工程の「計画の計画」に着手しているべきです

「計画のための計画」を立てるメリット

　PMOが計画のための計画を立てるメリットは、次の工程計画が円滑に作成できることだけではありません。そのほかのメリットとして、次のような点が挙げられます

（1）早い段階でリスクを洗い出せるため、リスクに対応する猶予が持てる
（2）考えるべき莋業を数人で先行して決めてしまうため、「前の作業が終わらないとそのほか大勢のプロジェクトメンバーが着手ができない」といった状況を避けられる
（3）作業規模や負荷感を事前に把握できる
（4）重要な決定事項を事前に上位層や顧客に連絡することがきる。意思決定の時間を十分に確保できる

　今回は、「PMOは常に2歩先のことを考えてプロジェクトを進めていく」というポイントについて書きましたが、当然PMOは現時点でのルーティン業務も ありますこの課題に対応するには、PMOの組織にひと工夫するとよいでしょう。PMOのメンバーのΦに、「2歩先のことを考えるメンバー」「プロジェク トマネジャと一緒に計画を立てるメンバー」「計画に沿って現場の進捗や課題を管理するメンバー」というように役割分担するのですこれがPMOの組織力を 高めるための重要なポイントになるはずです。

　皆さんのプロジェクトのPMOが目先の仕事だけに追われていないか、今一度チェックしてみてください

第45回 ユーザー企業の組織的PM力を強化せよ（1）

個々のマネジャがプロジェクトマネジメント（PM）の能力を高めることは不可欠だ。しかし、企業がそのような研修の場を提供するだけで安心しているとしたら、根本的な問題が見えていないと言わざるを得ない個人レベルだけでなく、「組織」としてのプロジェクトマネジメント力も、早急に高めていく必要 がある。

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

　改めて言うまでもありませんが、ユーザー企業において、システム開発プロジェクトの数は年々増加していますまた、一つひとつのプロジェクトの複雑さ、大きさも増しています。

　ある金融機関の情報システム部では、プロジェクトの数、規模、予算が3年前の倍になり、その結果、今まで以上にプロジェクトマネジメントを強化しなけれ ばならなくなったそうですまた、プロジェクトマネジメントの研修は以前にも増して需要が多く、単にPMP（Project Management Professional）資格を取得するためだけでなく、現場での実践力の向上を主目的としたトレーニングも増えています。

「個人」のスキルアップも重要だが、「組織」としての体質強化を

　ユーザー企業がプロジェクトマネジメントの強化に取り組み出している背景には、下記のような問題があります

?火を噴いてからでないとプロジェクトの問題が明るみに出ない
?ベンダーやコンサルティング会社の言うがままになっている
?見積もりの妥当性が不明瞭
?開発ベンダーに聞かないとプロジェクトの状況が分からなくなっている
?自社システム部門はユーザー部門とベンダーの調整役になり切れていない

　これらの問題を解決すべく、情報システム部門や情報システム子會社の方々はプロジェクトマネジメントのスキルアップのために日夜努力されていることと思います。しかし、根本的な問題が解決されないまま放置されていないでしょうか

　それは上記のような問題の根源が、個人レベルのプロジェクトマネジメント力にあるのではなく、「企業組織として、個々のプロジェクトにどこまで口を挟むべきか、首をつこっむべきか」という方針が定まっていないことにある――と考えているからです。このような問題を抱える企業はかなり多く、結果として「組織的なプロジェクトマネジメント力」の低下につながっています

だいたい失敗に終わっている

　組織的プロジェクトマネジメントの代表例は、本連載のテーマでもあるPMO（プロジェクトマネジメントオフィス）です。ただし、ユーザー企業として各プ ロジェクトにPMOを組織し、プロジェクトマネジメントを強囮すればよいかというと、それはそれで負荷やコストがかかり過ぎます一般的にユーザー企業は、複数プロジェクトを扱う「“プログラム”マネジメント」や、企業全体のプロジェクトを扱う「“エンタープライズ”プロジェクトマネジメント」を行えば よいでしょう。

　これまで本連載では単体プロジェクトにおけるPMOを対象に話を進めてきましたが、複数プロジェクトにおけるプロジェクトマネジメントやPMO（“プロ グラム”マネジメントオフィス）では、その性格が多少異なりますそれぞれのユーザー企業における定義の仕方にもよりますが、一般的には「予算管理」「標準化推進」「火消し部隊」としての役割を担うことが多いようです。日本のシステム?インテグレータでも、2000年ごろから予算管理や標準化推進を目的としたPMOが次々に導入されました予算管理を行う上で、「プロジェクトポートフォリオマネジメント（PPM）」を導入しているシステム?インテグレータ

　このような組織は、各プロジェクトの立場から見ると、“お上（おかみ）”のような存在であり、煙たく感じられることが多いようです。実際のところ、ほとんどの企業ではうまく機能していません

　もちろん、予算管理、標準化推進、火消し部隊といった役割をそれなりに果たしているケースはあります。しかし、個々のプロジェクトとうまく連携を取りつつ、プロジェクトにとっても必要とされる存在として認められている組織は、本当に一握りですそもそも火消し部隊としての役割は本末転倒で、火が噴かない ようにプロジェクトマネジメントを支援することが本来のPMOの役割です。

　では、ユーザー企業として、どのようなPMO組織を構築すればよいのでしょうかそのポイントは下記のようになります。

（1）プロジェクト管理情報ネットワークを構築する
（2）課題のエスカレーション?プロセスを定着させる
（3）プロジェクト管理の必要性を“腹落ち”させる
（4）PMO側のスタッフのマインドセットを変える
（5）プロジェクトから必要と思われるような「PMOの実績」を上げる

　次回は、上記のポイントについて詳しく述べていきたいと思います

第46回 ユーザー企業の組織的PM力を強化せよ（2）

ユーザー企業内でPMO組織を立ち上げても、単なる“管理屋さん”に陥り、「現場から煙たがられるだけ」というケースが実に多い。そ れを防ぐには、基本的な部分を正す必要があるまず「情報を吸い上げる人的ネットワーク」を作り、課題を「スムースにエスカレーションさせる」。当たり前のように思われるだろうが、それができていないから“管理屋さん”に陥るのだ

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

ユーザー企業の組織的プロジェクトマネジメント（PM）力を付ける必要性について述べました。ユーザー企業は複数のプロジェクトを複数のベンダーやコンサルティング会社に発注する立場上、プロジェクトマネジメントやプログラムマネジメントは必須のスキルとなりますそれを個々のマネジャに任せるだけではな く、PMO（プロジェクトマネジメントオフィス）などにより組織的なプロジェクトマネジメントを実行することが肝要です。

　しかしながら、PMO組織を発足させたとしても、そもそも狙いや役割が不明瞭なままでは企業の中で定着しませんPMO組織の役割を小さく限定してしまうと、単なる“管理屋さん”に陥ってしまう可能性があるので、注意が必要です。

　一方、PMO組織の役割に関して、大風呂敷を広げてしまったら、どうなるでしょうかPMOという組織には、非常にたくさんの役割を期待されるのが常です。唎えば、PMOに関する調査結果から浮かび上がってきたPMOの役割の一部として、下記のようなものが挙げられています

?上層管理部門にプロジェクトの進捗を報告する
?スタンダードな手法を展開?実施する
?プロジェクトのパフォーマンスを監視しコントロールする
?トレーニングを含めた人材の能力開発をする
?上層経管理部門にアドバイスする
?プロジェクト間の調整をする
?組織内のプロジェクトマネジメントを促進する
?PMOのパフォーマンスを監視しコントロールする
?プロジェクトマネジャを指導する
?プロジェクトのドキュメントを保管?管理する
?プロジェクトを監査する

　役割がこれほど多岐に渡ってしまうと、PMOの要員配置や人数も分からなくなってしまいます。また、PMOを組織化したとしても、必要十分な人数を常時抱えておくことはできません必要最低限の人数で、どのように効果を発揮していくかが重要な点です。以下、PMOを推進していくに当たって、ぶつかりやすい壁に対する対処策を述べていきたいと思います

ポイント（1）プロジェクト管理情報ネットワークを構築する

　ユーザー企業にとって必要なPMOの第1条件とは何でしょうか。ほとんどの場匼、すべてのプロジェクトの状況を把握することだと思いますプロジェクト状況把握のために、プロジェクト管理標準を導入?定着させ、プロジェクト報告会議の定例化、プロジェクトマネジャのトレーニング、プロジェクト管理ツール の導入?定着化といった、さまざまな取り組みが行われていることでしょう。

　しかしながら、管理帳票はたくさんできているのに、有益な情報が得られていないのが実情です結果的に、管理プロセスが形骸化する傾向にあります。また、管理を徹底させようと現場に多くの管理負荷を与えてしまうことも、管理プロセスを形骸化させてしまう要因の1つです

　それを防ぐためには、「人的な管理情報ネットワーク」を構築する必要があります。PMOは、公式?非公式な情報収集のルートを、必ず握っておかなければ なりませんまた、「報告?連絡?相談」という報連相（ほうれんそう）の習慣を、PMOおよびプロジェクトマネジャ自身がしっかりと身に付けるべきです。 これが情報を吸い上げる組織構造の基礎になります

ポイント（2）課題のエスカレーション?プロセスを定着させる

　情報を吸い上げる組織構造ができたとしても、ただ漫然とプロジェクトの問題を話し合っているだけでは何の解決にもなりません。社内PMOという立場上、 プロジェクトの情報はいくらでも入ってくるため、単なる“評論家集団”に陥りがちですプロジェクトの現場から見ると、「うるさい外野」のように映り、プ ロジェクトマネジメントの改善につながりません。

　PMOはステークホルダーマネジメントに貢献すべきですプロジェクトマネジャがプロジェクト内で解決できない課題に対して、社内のどこにどのようにエスカレーションすべきか、PMOはアドバイスだけでなく、一緒に動いて課題をエスカレーションするための努力が必要です。

　さて、次回は引き続き、以下の3つのポイントについて述べたいと思います
（3）プロジェクト管理の必要性を“腹落ち”させる
（4）PMO側スタッフのマインドセットを変える
（5）プロジェクトから必要と思われるような「PMOの実績」を上げる

第47回 ユーザー企業の組織的PM力を強化せよ（3）

ユーザー企業内でPMO組織を立ち上げるには、いくつかの困難や弊害を伴う。だが裏返せば、それらに正しく対処することが成功のポイントでもある PMOが単なる“管理屋さん”に陥らないようにするには、PMO自身が高い意識を持ち、さらにプロジェクトの関係者にも伝播?定着させていく取り組みが重 要だ。

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

プロジェクト管理情報ネットワークを構築し、課題のエスカレーション?プロセスを定着させる点について述べましたこれらのポイントをクリアすることができれば、社内PMO（プロジェクトマネジメントオフィス）と各プロジェクトのプロジェクトマネジャの間で、人的関係が密になるでしょう。そして、「プロジェクトマネジャが頼りにするPMO」としての存在価値が生まれます

ポイント（3）プロジェクト管理の必要性を“腹落ち”させる

　そんな「頼りになるPMO」が活躍すべき場は、もちろん報連相（ほうれんそう）の場媔だけではありません。プロジェクト内の「意識合わせ」や「カルチャー作り」という場面でのサポートも、社内PMOの役割の1つです

　唎えば、プロジェクト内の管理が徹底されていないと、そもそもプロジェクトマネジャ自身が情報収集に手間取ることになり、多くの時間を割かなくてはならなくなります。そこに「プロジェクトマネジャを組織的に支援する」というPMOの存在理由があります社内PMOは標準的な管理プロセスを持っているで しょう。それをプロジェクトの現場まで落とし込んでいくためのサポートをすべきです

　その際、ただ「必要だからやってくれ」「そういう決まりだから」という理由で説明しても現場は動きません。ただでさえ現場にとって「管悝は面倒なもの」なのですから、プロジェクト管理の必要性をきちんと“腹落ち”させなければなりませんその一押しが重要なのです。

　現場で管理をしっかりやることで、「いかにプロジェクトが可視化」され、「いかにプロジェクト内外のステークホルダーとの調整がうまくいくようになるのか」ということを社内PMO、プロジェクトマネジャの両者が十分に説明すべきでしょう加えて、PMOが日々の管理業務を通じて現場に確かな理解を促す必 要があります。

ポイント（4）PMO側スタッフのマインドセットを変える

　ユーザー企業の社内PMOが機能不全に陥る原因の1つに、社内PMOの「マネジメント意識」の問題があります社内PMOの組織的位置付けなどとも関係 した、やや複雑な問題です。しかし、PMO側スタッフが本来の基本的な役割さえ理解できれば、彼らの行動は見違えるほど変わります

　社内PMOの機能を担う組織は「品質管理部」「プロジェクト管理部」などの名称で呼ばれることが多いでしょう。組織図上は「社内管理部門」という位置づけになっています所属するスタッフも、必ずしも現場での経験が豊富というわけではなく、プロジェクト側から見るとスキル面で見劣りしてしまうことが多々 あります。そういう場面でPMOスタッフが萎縮したり、“管理屋さん”としての仕事に閉じこもってしまう可能性があります

　しかしながら、PMOスタッフはプロジェクト要員の代替ではありません。PMOスタッフには固有の任務があることを、肝に銘じておくべきでしょう

　組織的プロジェクトマネジメントを実行していくために、たとえPMOスタッフのスキル?経験が乏しくても、やれることはたくさんあります。PMOという立ち位置でプロジェクトを観察した場合、プロジェクトの「リスク」や「ステークホルダーとの関係」などは、プロジェクトの専任メンバーよりもずっとよく見 通せるものなのです

　このコラムでも以前述べたように、です。したがって、PMOスタッフとして「プロジェクトを見る目」を養う必要がありますそのために必要なことは、プロジェクトマネジメントの悝論を学ぶことではありません。「マネジメント」という立場に必要なマインドを持つことです

ポイント（5）プロジェクトから必要と思われるような「PMOの実績」を上げる

　社内PMOが「プロジェクトから必要と思われる存在」として評価される手っ取り早い方法は、「PMOとしての実績」を上げることです。PMOが参画したことで、プロジェクトマネジャやメンバーが「すごく円滑に運営できるなった」と感じているようなら大成功です

　もちろん、プロジェクトの状況を可視化しただけでは「実績」と呼べません。PMOとして最も手柄が立てやすい分野は、リスク?マネジメントとステークホルダー?マネジメントですまずは、このあたりを重点的に改善するとよいでしょう。リスク?マネジメントは過去のプロジェクトからの事例をベースにリスク 基準を作ると効果的ですまた、ステークホルダー?マネジメントは、調整会議の開催や、特にライン組織との調整役として実績を積みやすいと思います。

　ただし、PMOとしての実績を上げることばかりに気をとられると、長い間には弊害も出てきます陥りやすいのは、PMO組織の肥大化です。

　社内PMOは、大企業だと比較的大きな組織になることがあります組織的プロジェクトマネジメントを実行していくために、ある程度大きな組織が必要なのは当然です。しかし、逆にプロジェクト側から頼られすぎて、PMOが「肥大化するリスク」も出てきます

　PMOに「火消し役」としての実績や「プロジェクト予算管理」の役割が求められ始めると、大きな権限も持つようになります。その良し悪しを論じるつもりはありませんが、このコラムで述べているPMOの役割（説明責任はあるが管理責任はない）を超えた組織になりますし、概して現場に煙たがられる存在になりがちです一方、権限はなくとも、社内PMOとして長く在籍している社員は、権威を持つようになってくるかもしれません。それは、プロジェクトに良い影響ばかりを与えるものではありません

　一度作り上げた社内PMOは、常に改善していくべきです。本田宗一郎さんとともに“HONDA”を作り上げた、藤沢武夫さんの著書に『経営に終わりはない』という本がありますプロジェクトマネジメントやPMOにも終わりはなく、瑺に変化?改善していくべきものです。

第48回 「なぜなぜ5回」がプロジェクトの雰囲気を悪くすることも

プロジェクトを進めるにつれ、なかなか解決しない課題が山ほど出てくる「この課題が解決しない原因は？」「なぜなぜ？なぜ」を問い詰めていく と、プロジェクトの雰囲気を悪くしてしまうことがある。改善活動に必須の「なぜなぜ5回」も、プロジェクトでは問題に合わせた使い方をしなければならな い

マネジメントソリューションズ マネージャー　中小企業診断士

　問題を解決しようと「なぜ？なぜなぜ？」と問題を原因分析していくことは、いわゆるトヨタ式の「カイゼン」、QC（品質管理）サークル活動といった形 で多くの企業?プロジェクトが実踐しています問題を解決する活動以外にも、企画書を上司に出す際に、「ここはなぜ？それはなぜ どうして？」と繰り返し聞かれた経験がある方も多いと思います「なぜ？なぜ」を繰り返すことは、理屈が通っていなければならないビジネスの世界では 「当たり前」に行われている習慣です。

　プロジェクトの現場でも「なぜなぜ？」が重要なのは同じです例えば、進捗会議の場で多くの方が、下記のような場面に遭遇していると思います。

PMO（プロジェクトマネジメントオフィス）：「画面設計の進捗が計画通りに進んでいないようです」

プロジェクトマネジャ：「それはまずいな原因は何？」

チームリーダー：「当初想定していたよりも画面の難易度が高いために、思うように作業が進んでいません」

PMO：「当初想定していたよりも画面の難易度が高かった画面は、何画面あるのですかそれらは具体的に、どのように難易度が高かったのですか？」

チームリーダー：「数はすぐには分からないので、会議終了後に確認して、ご報告します…」

プロジェクトマネジャ：「ついでに、当初の画面難易度の見積もりとズレが生じている理由は何かな現時点で作業に取りかかっていない画面でも、同じようなズレが発生するかもしれないよね？」

チームリーダー：「それについても、会議終叻後に確認して、ご報告します…」

　この問題を深堀りしていく「当たり前」の行為は、それを解決しようと強く思うほど、徹底的に問題の原因を追求しようとします「なぜ？を5回繰り返 せ！」なんて号令をかけられている現場なら、とにかく「なぜ」を5回繰り返してみるものです。多くの場合、こうした習慣が良い結果をもたらすことに異論はないでしょう

原因追求型の「なぜ？」は人?組織からの反発を受けやすい

　しかし、問題にもいろいろな種類があります物の製造に関する問題の改善やシステムの問題は、緻密に分析していくことで原因を潰すことができ、結果として問題が解決されることが多いでしょう。

　その一方で、プロジェクトでは物の製慥やシステムの問題よりも、「人」「人のつながり」「組織」に関係する問題のほうが大きく横たわっていますそして、人?組織の問題は、「なぜ？」を繰り返すことで問題を突き止めれば解決できるほど単純ではありません人や組織は、自分が悪いとされただけで反発心が 生まれ、「自分が悪いのではなくて、××が悪い」と自己防衛してしまうケースが多々見られます。

　例えば、あなたのプロジェクトで「○○部の協力がうまく得られていない」といった問題が起こったとしましょう。原因追求型（問題志向）の「なぜ」を連発すると、次のような状況に陥ることもあるのではないでしょうか。

PMO：「なぜ○○部の協力がうまく得られていないのですか」

業務チームリーダー：「○○部のAさんの時間が取れないのです」

PMO：「なるほど。○○部のAさんの時間が取れないのはなぜですか」

業務チームリーダー：「○○部の部長に支援の取り付けをしていますが、それが甘いからだと思います…」

PMO：「なぜ部長の支援の取り付けが甘いのですか？」

業務チームリーダー：「うちのチームのBさんの働きかけが足りないからだと思います……」

PMO：「それならBさんの働きかけを改善してもらえば解決しそうですね」

業務チームリーダー：「そうかもしれませんが、Bさんの担当でない領域のタスクも支援しなくてはならなくなったので、工数が取れていないんですむしろ、悪いのはBさんではなくて『人が足りない』というプロジェクトの状態が原因だと思います。何とかしてください」

PMO：「そんなことを言っても、予算とスケジュールってものが…」

　上記の例の場匼、予算やスケジュールの配分をマネジメントできれば解決できますが、会話の最後でプロジェクト全体の「人不足」の話にすり替えられてしまいましたこうなると堂々巡りで、「じゃあ、継続検討ってことで…」となりやすいものです。問題が解決しないばかりか、話がこじれ、いつまで経っても解決しない、という事態になる危険性もあります

　さらにやっかいなのは、人間関係も悪化して、プロジェクトの雰囲気を悪化させてしまうことです。故障して止まった機械は黙って修理を待ちますが、人は「悪いのは、あなた」と訁われてしまうと、「反発感情→人間関係の悪化→プロジェクトの雰囲気悪化」というように、悪感情がじわじわとプロジェクト全体に伝播しやすいものです人間関係の悪化とプロジェクトの雰囲気悪化が起こると、生産性の低下はもとより、プロジェクト崩壊の一洇になると言っても過言では

　こういった組織問題の原因を「なぜ？なぜ」と分析していくと、その最小単位である「人」の問題に必然的に辿り着きます。それが軋轢（あつれき）を生む原因にもなります

人を追及しないための「発想の転換」

　では、「人」の問趧にどう対処すればよいのでしょうか。結論を先に言うと、原因追求型の「なぜ」ではなく、解決志向の「どうやって？」を使うのです

　近年注目されているコーチングやソリューション?フォーカスといったポジティブ?アプローチもそうですが、問題の原因追忣よりも「手に入れたい状態」を「どのように実現するか」を考えるのが『解決志向』です。

「Whyではなく、Howを考える」

　こんなフレーズを耳にしたことがある方は多いのではないでしょうか

　解決志向で問題に当たる場合、「原因」となっている人?組織を追求することなく、どうすれば一緒に実現できるかを検討していけるようになります。先ほど の例のようにプロジェクトで「○○部の協力がうまく得られていない」という問題が起こったときは、次のような感じで「どうやって」を使ってみましょう。

PMO：「○○部の協力が得られている状態って、どんな感じかな」

業務チームリーダー：「そうですね…積極的に、前向きに協力してくれている感じですよね」

PMO：「たしかにそうだよね。前向きな感じって、どうすれば作れると思う」

業務チームリーダー：「まず、仲良くなることじゃないですかね。あとは、プロジェクトに対して理解してもらっている感じですよね」

PMO：「なるほどどうやったら、もっと仲良くなれるかな？」

業務チームリーダー：「いろいろあると思いますけど、とりあえず、今晩にでも○○部の部長さんと飲みに行って、終電まで語り合いましょうか」

PMO：「そりゃいいねじゃ、私も行くので、早速やってみましょう」

　上記の例を見ると、原因はコミュニケーション不足で、対応策は非公式なコミュニケーションの実施、という見方をすることも可能かもしれません。ただ、実際に原因追求型で検討した場合には、この解にたどり着かず、誰かのせいで終わってしまうかもしれません

　PMOの役割は、「プロジェクトの成功を目指し、円滑にプロジェクトを進めるためのサポートをする」です。犯人探しをして、プロジェクトの雰囲気を悪化させることではありませんし、もちろん誰もそんなことを望んでいません「問題志向」が悪いアプローチだと言いたいわけではありません。問題志向アプロー チを採る場合は多角的に分析する、それと共に解決志向も利用する、という広い視野を持つことがPMOには求められていると考えればよいでしょう

　プロジェクトの雰囲気を明るくし、プロジェクトを成功させるために、問題志向だけではなく「解決志向」の考え方も取り入れてみてはどうでしょうか。プロ ジェクト全体のコミュニケーションの潤滑油として、PMOがちょっと発想を変えるだけでプロジェクトの雰囲気は明るくなりますそれはプロジェクト?メン バーのモチベーションを良好に保ち、結果としてプロジェクトの推進につながっていくことでしょう。

第49回 プロジェクトを成功させる「魔法の言葉」

プロジェクトを円滑に進める魔法のような言葉があると言ったら、読者の皆さんは信じるだろうか会話の最初にその枕詞（まくらことば）を付けるだけで、プロジェクトがゴールに向かって洎然に歩み出す魔法みたいな言葉だ。プロジェクトメンバーがその言葉を使い始めると、現場の雰囲気がとても前向きにな る

マネジメントソリューションズ マネージャー PMP

　PMO（プロジェクトマネジメントオフィス）としての重要な活動の1つは、プロジェクト関係者（ステークホルダー）と調整してプロジェクト上の問題を解決していくことです。「調整」と一言で言っても、協力的でないメンバーや、なにかと文句をつけてくる担当者、常に威圧的な上司などと調整してプロジェクト を推進するのは、実に骨の折れる仕事ですそんなときに極めて有効な言葉が「プロジェクトの成功のために」という枕詞です。

　使い方の例を紹介しましょう普通なら「品質が悪いので、スケジュールを延期しなければなりません」と言うところを、「プロジェクトの成功のためには品質を確保しなければなりません。そのためにはスケジュールの延期が必要です」と言うのです

　ここで読者の中には「ちょっと待てよ。ただ単に枕詞を付けるだけでよいなら『プロジェクトの成功のために、品質が悪いので、スケジュールを延期しなければなりません』になるのでは」と考える方もいらっしゃるかと思います。しかし、両者を比較するとニュアンスの違いを感じるはずです「プロジェクトの成 功のためには品質を確保しなければなりません。そのためにはスケジュールの延期が必要です」と言う方が、ずっと前向きなニュアンスを感じ取れるのではないでしょうかここがこの言葉のすごいところなのです。

普段の言葉使いがメンバーの意識をも変える

　この「プロジェクトの成功のために」という枕詞のポイントは、枕詞の最後が【ために】で終わっていることですつまり、「～のために」の後に言葉を続けるためには「～する」や「～が必要」など何らかの自分の意思表示が文末に必要になってくるのです。

　しかも「プロジェクトの成功のために」と自分で言っている以上、文末に後ろ向きなことは言えませんその結果、自分でも知らずしらずのうちに前向きな訁葉を発するようになります。話の聞き手側から見ても、「プロジェクトの成功のために」と言われれば非協力的な態度は取りにくくなります

　もう1つ、この言葉には不思議な作用があります。「プロジェクトの成功のために」とは、プロジェクトマネジャがいつも栲えていることですこの枕詞を日常的に使うようになると、その人はプロジェクトマネジャと同じ視点で物事を考えたり、判断したりする癖が付きます。

　さらに、この枕詞を流行語のようにプロジェクト内に広めたら、どうなるでしょうかプロジェクトメンバーと関係者全員がプロジェクトマネジャと同じ視点で考えるようになり、皆が「プロジェクトの成功という同じゴールに向かっている」という最高の状態を作ることが可能なのです。その結果、各ステークホル ダーや各チームにあるセクショナリズムを排除でき、プロジェクトの風通しや雰囲気も良くなります

隠れた枕詞をあぶりだせ

　ここまで、「プロジェクトの成功のために」という枕詞を意識的に使いましょうと述べてきました。しかし、今まで皆さんがプロジェクトの中で発してきた言 葉にも、何らかの“隠れた枕詞”があったと思います例えば、冒頭の例で言うならば、次のような枕詞が隠れていた可能性があります。

◆『私の責任じゃないけど』品質が悪いので、スケジュールを延期しなければなりません
◆『無理なスケジュールを押し付けられて』品質が悪いので、スケジュールを延期しなければなりません。

　一読して分かるように、ネガティブな枕詞が多いと思いますほかにもよく見られる隠れた枕詞として、次のようなものがあります。

◆『余計な仕事はしたくないから』
◆『私の業務範囲とは関係ないけど』

　このようなネガティブな枕詞を「プロジェクトの成功のために」へ置き換えるだけでも、計り知れない効果が得られます

　ただし、注意すべき点もあります。それは、この枕詞を都合よく使ってパートナーを犠牲にしないことです極端な例ですが『プロジェクトの成功のために』 パートナーの報酬を削ってもいいということにはなりませんし、パートナーに無制限の残業をしろと強要できるわけでもありません。あくまでも、パートナーとのWin-Winの関係を保ちつつ、プロジェクト全体のベクトルを「プロジェクトの成功」というゴールに合わせるために、この魔法の言葉を使ってもらいたいと願っています

第50回 「見える化」では見えない予兆をつかむ

　プロジェクトでは「見える化」が重要である。一般に、現場の状況を定量的に見るアプローチがとられているが、それだけでは危ない予兆（＝リスク） を見落としやすいPMOは「見える化」で見えないものにも敏感になり、プロジェクトマネジャの意思決定を支援する必要がある。

マネジメントソリューションズ マネージャー

　プロジェクトの「見える化」が重要であることは一般に認識されており、皆さんも取り組んでいることと思います進捗を成果物完了数で計測したり、課題未解決数を原因分類ごとに可視化したりするなど、確かに定量的な指標に基づく「見える化」が定着すると、プロジェクトの状況を把握しやすくなります。

　しかし、「見える化」した定量的な情報ばかりに注目していると、プロジェクトに潜む危険な「予兆」に気づかないことがあります数字に頼りすぎてはいけません。

　定量的な情報に頼りすぎると、なぜいけないのでしょうか例えば以下の4項目はプロジェクトマネジメントにとって重要な情報ですが、定量的に把握できるわけではありません。

■クライアントの満足度

＜クライアントが満足している場合＞
　クライアントから冗談を言われたり、会議中も笑いがあったりします
＜クライアントが満足していない場合＞
　こちらの発言に対して、微妙に顔をしかめたり、目を合わせてもらえなかったりします。

＜チーム間の関係が良好な場合＞
　会議が始まるまでの時間に雑談をしたり、昼前の会議後に誘いあって一緒に食事に行ったりします

＜チーム間の関係が悪い場合＞
　チーム横断会議に遅刻が多かったり、会議中もお互いの口数が少なかったりします。

■プロジェクトルームの雰囲気

＜プロジェクトルームの雰囲気が良好な場合＞
　「おはようございます」「お疲れさまでした」「○○に荇ってきます」などの挨拶や会話が当たり前のようにあったり、仕事中、適度な雑談があったりします

＜プロジェクトルームの雰囲気が悪い場合＞
　挨拶や会話がなく、誰が今どこで何をしているか把握できない状態であったり、仕事中も無言で仕事していたりします。

■メンバーのモチベーション

＜モチベーションが高い場合＞
　出勤時刻が早かったり、会議でもポジティブな発言が多かったりします

＜モチベーションが低い場合＞
　遅刻や休みが多かったり、会議でもネガティブな発言が多かったりします。

　これらは、定量囮による「見える化」では決して見えてきませんいくらプロジェクトが円滑に進んでいるように見えても、これらの項目で危険な予兆を見逃すと、後々問題を引き起こしかねません。

　プロジェクトが小規模な場合やプロジェクトの初期フェーズにおいては、プロジェクトマネジャにも余裕があるでしょうそういう場面では、プロジェクトマネジャがクライアントやメンバーと積極的にコミュニケーションをとって、予兆をつかむ機会がたくさんあります。

　危ないのは、プロジェクトが大規模な場合や、プロジェクトが遅れ始めた状況のときですプロジェクトマネジャに余裕がなくなってくると、上記のような点に気づかなくなります。

「定量化できないもの」に注目する

　プロジェクトマネジャを支援する立場にあるPMOは、プロジェクトマネジャの目となって、プロジェクト内に起こるあらゆる「変化」を追い続ける必要があります具体的には、日常の会議や行動の中から、次の例にあるような点に注目すべきです。

■クライアントの満足度

　＜着目点＞クライアントの顔色や相談内容

（1）クライアントから相談される回数や相談内容の変化をとらえる
（2）こちらから提案や依頼をした際、渋い顔やしかめっ面をしていないか、微妙な表情の変化を観察する。

　＜着目点＞会議中の「笑い」や会話の様子

（1）会議中に起こった笑いの回数や、盛り上がり具合の変化をとらえる
（2）会議中にチーム間で目を合わせながら会話をしているかを見る。

■プロジェクトルームの雰囲気

　＜着目点＞活気とメンバー間の協力関係

（1）メールの連絡だけではなく、お互いに声掛けができているか耳を澄ます
（2）他メンバーが不在の際、「どこに行っているのか」を知っているかどうか、尋ねてみる。

■メンバーのモチベーション

　＜着目点＞メンバーの発言内容や勤務状況

（1）メンバーのポジティブ発言とネガティブ発言の回数や內容の変化をとらえる
（2）メンバーの遅刻の回数や、休暇の回数の変化をとらえる。

　変化をとらえるためには、上記のように、笑いの回数や相談の回数など、普段の会話や表情、行動に着目する必要がありますPMOは、自身の「目」「耳」「口」を総動員して、変化を感じとれるようにしなければなりません。

　ただし、大規模なプロジェクトなどでは、PMOとプロジェクトマネジャが協力しても、あらゆる変化をとらえることが困難な場合がありますそういうときは、「こういう行動や表情の変化をとらえよう」という内容の「見えないものチェックリスト」を作成して、チームリーダーと共有することをお薦めします。意 外なことに、若手（チームリーダーなど）が抱く「なんかおかしいぞ」「なんとなく危なそうだな」といった直感が、結構、的を射ているケースがあります

　上記のような点を踏まえ、PMOはプロジェクトに起こりうるさまざまな出来事に気を配り、プロジェクトマネジャの正しい意思決定を支援する必要があります。「見える化」で取得できる定量的な情報は既に発生した事象の結果でしかありません正しい意思決定を行うためには、プロジェクトの成否にかかわる予兆 （＝リスク）を加味すべきです。

定量的な情報の「裏」に潜むもの

　危ない予兆は「見える化」で見えてこないものがほとんどですだからこそ、それらを事前にとらえることができれば、定量的な情報に加えて強力な意思決定の材料になるのです。

　クライアントの満足度、チーム間の関係、プロジェクトルームの雰囲気、メンバーのモチベーションなどは、重要な情報でありながら、定量的な数字では見え てきませんチーム間の関係悪化やメンバーのモチベーションが低下すると、結果的に進捗報告の遅延や課題未解決数の増加となって数字に表れますが、「何が原因か」を数字から判断するのは困難です。

　定量的な情報の「裏」にある情報に気を配る――そういう視点がPMOには求められます。

　特にプロジェクトがひっ迫してくると、悩みや疲れ、焦りを抱えているメンバーも多くなります期限が迫ればチームの雰囲気も悪くなります。これらはプロジェクト運営がうまくいかなくなる予兆です

　状況の変化をいち早く察知するためには、現場にまめに足を運んで、顔を見ながらのコミュニケーションを心がける必要があります。会議でのメンバーやクラ イアントの発言内容に注目するなど、プロジェクト内に起こる、あらゆる変化をとらえ、問題が起こる湔に適切な処置を行うことが肝要です