【戦略ノート250】難局を乗り切るマネジメントとリーダーシップ（４）～危機から学び、守りから攻めへスイッチを切り替える
◆リカバリーをしたら、リードタイムが短くなった
過去に一度だけ、トラブルリカバリーをして、当初の計画より早く新製品（生産財）が完成し、かつ製品は当初計画より多くに売れた。この話を研修ですると、５人に一人くらいピンとくる人がいる。読者のみなさんのなかにも、気がついた方がいらっしゃると思う。製品機能を予定されていたものから削減をしたのだ。それも、既存機能だ。
スコープを削減する場合には、新規機能を対象とすることが多い。新規機能を対象に考えると、理由にもよるが多くの場合は、頑張ってなんとか実現しようということになる。新規機能に対してマーケティングしているのだから、ある意味、当たり前だ。
ところが、このケースはちょっと事情が違った。スケジュール遅延を引き起こした技術的な問題の解決のためには、既存機能を削るか、新しい機能をあきらめるかという選択をせざるを得なかった。
そこで、ラインナップを変更し、既存機能を削った新製品を開発することになった。
◆トラブルにおける力関係
問題はなぜ、このような進め方ができたかだ。一言でいえば、危機時効果である。大げさにいえば、問題が起こっているときは、「変革」のチャンスである。
製品がガラパゴス化していく大きな理由は、抵抗勢力の存在にある。既存の機能を温存することは、「読める」売り上げにつながる。そこに新しい機能によって新しい顧客（市場）の獲得が期待できる。これが、機能を捨てたくない人の発想である。もちろん、そんな言い方はしない。「既存の機能を削ったら、既存顧客の買い替え需要にどう対応するのか」などというわけだ。たとえば、マイクロソフトはWindows vistaの発売から、前モデルのWindows XPのフェードアウトまでに４年を要している。
既存のものの廃止に反対する人たちは小泉元首相流にいえば抵抗勢力になるわけだが、平時には、抵抗勢力は意外にも強いものだ。特に、生産財の場合には継続性が重要なので、一段と強い。平たくいえば、いうことを聞かないなら、プロジェクトマネジャーを変えるという態度に出れるからだ。ところが、プロジェクトがトラブルに陥ると、相対的にプロジェクト側が強くなる。よく問題が起こったときにプロジェクトマネジャーを変えるというが、現実にはほとんどできない。理由はよく言われるように人がいないということではない。変えるという意志決定の責任が生じる。トラブル時にその責任をとるのは、相当な覚悟と度胸がいる。今回震災で、崩壊寸前だった菅政権が息を吹き返したのと同じ理屈である。
ここに、抵抗勢力を抑え込んで、プロジェクトの方向性を自らの意図どおりに持っていくチャンスが生まれる。
◆トラブルに対する正しいスタンス
そううまくはいかないだろうと思う向きもあると思う。確かに、実際のトラブルプロジェクトを見ていると、プロジェクトは当事者能力を失い、上位組織や顧客対応部門のいいなりになって右往左往しているケースが多い。
問題はトラブルへのスタンスである。ここで参考になるのが、ＰＭＢＯＫ（Ｒ）のプロジェクト・ステークホルダの概念である。ＰＭＢＯＫ（Ｒ）のステークホルダは、プロジェクトマネジャーやプロジェクトスポンサーではなく、「プロジェクト」を中心に考える。あくまでもプロジェクトの利害関係者である。
つまり、プロジェクトマネジャーも、上位組織も、顧客もすべて同じ位置にいる。トラブルのプロジェクトにおいてはこの考えを徹底すべきである。つまり、問題が起きているのはプロジェクトであって、プロジェクトマネジャーではない。問題のオーナーシップはプロジェクトマネジャーにあるが、ステークホルダ全員の問題であって、プロジェクトマネジャーだけの問題ではない。
このように考えることによって、プロジェクトで起こっている問題を共有し、その上で、プロジェクトマネジャーが問題のオーナーとして改めて指名されるという認識を作ることができる。
この認識ができれば、問題が発生していることによって、プロジェクトマネジャーがプロジェクトの進め方にイニシャティブを持ち、強い力を持ち、冒頭に紹介した事例のような対応を可能にする。
プロジェクトは、目標を達成するためのオペレーションである。したがって、トラブルが発生することは、オペレーションとしてのスムーズさを欠くことになり、どうしても、トラブルを拡大させないようにしようという守りの姿勢になる。しかし、トラブル状況において、守りに入ることは防戦一方になり、トラブルを大きくすることが多い。
◆守りから攻めへのスイッチの切り替え
もちろん、一定の時期は立て直しであるので、問題の拡大を防ぐことに集中することは仕方ないことだ。しかし、最後まで防戦だけでいくのは、合理性がないし、機会損失でもある。重要なのはスイッチを切り替えることだ。
前回、トラブルにおいては、戦略を作り、計画的に、長期戦を覚悟してという話をした。前回も述べたが、トラブルに陥ったプロジェクトを救うのに、いきなり、状況分析して作った戦略や計画はほとんど意味がない。先がよく見えないところで作っても、現実的な戦略や計画にはならないからだ。たとえば、過去１か月スケジュールが１週間ごとに３％ずつ遅れているとしよう。これを分析して、このままでいくと１か月で１５％遅れるという予測を立てることはあまり意味がない。プロジェクトが不安定なのだから、ある日、突然１０％遅れてもおかしくはないのだ。
したがって、計画を作るにあたっては、まずは、プロジェクトを安定化することが必要である。たとえば、スケジュールの遅れを止める、コストの増加を止めるなどだ。その上で、プロジェクトの分析を行い、リカバリーの戦略を立て、リカバリー計画を作り、計画に沿って粛々とプロジェクトを進めていく。
そして、安定化したプロジェクトに対しては、再び、戦略リスクをとれるようになる。ここがポイントである。つまり、安定化したところで、残り半年で２カ月遅れているとすれば、２か月遅れのスケジュールではなく、思い切って、納期通りに完了するという戦略目標の設定をし、その方法を考えることができる。
プロジェクトが不安定なままでこれをやると、ほとんど失敗するが、プロジェクトが安定していると可能性が出てくる。むしろ、そのような攻めの戦略、計画が期待される。
これが正しいリカバリーのあり方である。
ということで、難局を乗り切るマネジメントとリーダーシップは今回でとりあえず、一区切りとしたい。
| | 
コメント