意思疎通ができない

	プロセス１４：プロジェクトマネジメントクリニックケース１７：火消しに定石はあるか？
■相談２０：（Ｔさん、ＳＩベンダー、４２歳）来週からプロジェクトの火消しにプロマネとして入る予定です。過去に何度も経験しているのですが、結局、その場の判断かなと思っています。ただ、pmstyleに書かれた記事を読んでいると、プロジェクトマネジメントと同じように方法論があるようなことが書いてありますので、もし、定石のようなものがあれば教えてください。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■好川哲人の見立て ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆リカバリーの定石プロジェクトのリカバリーについては、いろいろとノウハウとして言われていることはありますが、Ｔさんはリカバリーの経験が豊富だとのことですので、よくご存知だろうと思います。２～３、例をあげると　・むやみに新規の要員の投入をしない　・むやみにメンバーに残業、休日出勤をさせない　・責任を追及しない　・このままいくとどうなるかを分析し、それを基準にして実現可能な対策をするといったことです。このような知恵は大切ですが、もっと大切なことは、原則をしっかりとすることです。リカバリーというのは通常のプロジェクトとくらべものにならないくらい、不確実性があります。たとえて言えば、リスクの海で泳ぐようなものです。したがって、どのような事態になっても迷わずに進んでいけるように原則が必要なのです。 ◆原則１：論理的な行動をするまず、最初の原則は、論理的に行動することです。プロジェクトでトラブルに遭遇すると、えてして、目先のことが気になり、そのために衝動的な行動が増えてきます。そのような行動によって、傷口が広がることも少なくありません。たとえば、上にあげた要員の投入です。スケジュールが遅れてどうようようもないということで、原因の所在を確かめないで要員を投入して辻褄を合わせようとします。チームに新たなメンバーが加わる場合にはそのメンバーがスムーズに参加できるようにサポートするというのはプロジェクトマネジメントの基本のひとつですが、トラブルの発生している状況でそのようなオペレーションは困難です。結果として、既存のメンバーが余計な仕事を抱え込むか、新メンバーがまったく戦力にならないかのどっちかになるケースが多いようです。もちろん、標準開発プロセスの有無など、組織によって若干の差はあると思いますが、結果があまり変わるとは思えません。そこで必要なことは、原因を徹底的に追究して、それに対して手を打つことです。ここで、注意しなくてはならないのは、打ち手の評価基準を明確にすることです。評価の方法として最も妥当性があるのは、ほったらかしにしておいた場合と較べた効果の見通しです。要員投入の例はまさにそうなのですが、放っておいた方がよいケースも少なくありません。リカバリーが必要になるようなトラブルですので、とりあえず、コストは一旦度返しするのは仕方ありませんが、だからといって、お金で済ましてしまうことがうまい方法ではありません。クライアントの印象をよくするためにお金をかけ、要員を投入するなど、本末転倒で論外です。打ち手の評価基準を決めないと得てしてこのような落とし穴にはまってしまいます。 ◆原則２：モードを切り替える２つ目の原則は、モードを切り替えることです。トラブルが起こったときによくあるのは認めたくないという心理が働いてしまうことです。スケジュールが遅れている、品質が作れていないといった事実は客観的なものですので、これを否定することはできません。しかし、自分のやり方を否定されることとなるとまた別で、「もう少し、スキルの高いメンバーを投入すればなんとかなる」、「もう２～３名、ＳＥを増やせばなんとかなる」といった形で、今のやり方を崩さないで、何とかするという方向に走る傾向があります。結果として、プロジェクトマネージャーを変えるという形でしか、リカバリーできないといった状況になることも少なくありません。ここで必要なことは、リカバリーというのは緊急事態だという認識をしっかりとすることです。緊急事態ですので、やり方もかえる必要があるという認識を持つ必要があります。ご存知の方も多いと思いますが、Windowsにはセーフモードというモードがあります。パソコンで何かトラブルが起こったときに、ＯＳの必要最小限の機能だけを走らせ、そこで切り分けをしたり、リカバリーをしたりするモードです。まさに、リカバリーというのはこのようなモードでの作業だといえます。ここで、重要なことは、「とは言っても、やり方を変えることがよいかどうかは別の問題だ」ということです。たとえば、メンバーが変わらなければ確実にやり方を変えると確実に生産性が下がるでしょう。事実、著者がリカバリーのコンサルティングに入ったときに、やり方を変えようとすると、たいていのプロジェクトマネージャーはまずこの点を指摘します。極めて正しい指摘です。つまり、必要なことは変えることではなく、トラブルに至ったやり方に固執しないで、いろいろな選択肢を検討し、メンバーの慣れも含めて評価し、適切な方法を決定することです。同時に、今までとはモードが違うのだから、やり方を変えるのが当たり前というくらいの割り切りも必要です。 ◆原則３：プロジェクトの目的とリカバリーの目的を切り離すモードを変えることの意味は単にやり方を変えるだけではありません。つまり、リカバリーモードでは、目的も、目標を変わります。これが３番目の原則です。リカバリーの際の目的は、プロジェクトの目的と一旦切り離すべきです。誤解している人が多いのですが、リカバリーというのは計画変更とは根本的に異なります。計画変更というのはプロジェクトの目的（たとえば、顧客のビジネスにコミットし、さらに大きな受注をする）を守るために計画という目標を変更することです。たとえば、納期が遅れてしまっても目的そのものが達成できなくなるわけではありません。しかし、リカバリーを行う状況（トラブル）というのは、目的自体を変えざるを得ない状況です。つまり、計画変更をしてもプロジェクトは失敗したとはいえませんが、リカバリーを行うプロジェクトはプロジェクトとしては失敗であり、如何に失敗を小さくするかに焦点が移ります。リカバリーの最大の難問は、如何にして主要なステークホルダ全員が納得する目的を再設定するかなのです。このように考えるとお分かりいただけると思いますが、リカバリーというのは、プロジェクトマネジメントプロセスでいえば、立ち上げ（イニシエーション）に近いと考えた方がよいものです。もちろん、本来の立ち上げは前提条件、制約条件はありますが、白紙に絵を書くような作業ですが、リカバリーの場合には、負の資産がそこにあり、負の資産の償却をしながら、絵を書かなくてはなりません。ここが難しいところです。これがリカバリーという作業ですが、これは、何らかの理由で一旦不安定になった（目的が見えなくなった、もちろん、計画も意味がなくなっている）プロジェクトを安定化する作業だといえます。ここをしっかりと認識しておく必要があります。 ◆ゆとりが大切以上が、著者の考える３原則ですが、最後にもうひとつ重要な原則をあげておきます。それは、ゆとりを持つことです。リカバリーでは何とかして損失を最小限にしようとするあまり、無理な計画を作って、さらに状況を悪くするということがよくあります。開き直るというとあまりイメージがよくありませんが、よい意味で開き直って、ゆとりを持ってリカバリーを進めていくことこそ、リカバリーを成功させる最良の方法です。このことをよく頭に入れておきたいものです。　（２００５年８月４日号より）
購入はこちら