課題管理の方法 （ その 2 ）
外資系転職や海外転職、ビジネス英語などグローバルキャリアに役立つ情報が満載！<グローバル転職NAVI>

前回のコラムでは、外資が重視する「課題管理」の概略をお話しました。簡単におさらいしておくと、課題には「 Risk 」 ( 問題が発生しそうな兆候がある状況 ) ・「 Issue 」 ( 近い将来に問題が起こることが確実な状況 ) ・「 Problem 」( 実際に問題が発生している状況 ) の 3 段階があり、「 Risk 」ないしは「 Issue 」の段階で何とか解決してしまえば、問題は起こらないということでした。今回のコラムでは、特に「 Risk 」・「 Issue 」の管理方法についてお話しましょう。

一般に、「 Risk 」にはどのようなものがあるでしょう。日常生活で考えてみると、車で事故を起こすかもしれない、病気になるかもしれない、会社をクビになるかもしれない ･･･ なんてところでしょう。リスクを挙げてみるとわかるのですが、われわれは個人的なリスクをヘッジ ( hedge: 回避 ) するために、「保険」に入っていることに気付きます。損害保険や生命保険に入ることで、いざというときの金銭的な保証を得ているわけです。

ビジネス、特にプロジェクトにおけるリスク管理の方法も、個人の場合と同じことです。まず、そのプロジェクトが持つリスクを洗い上げ、それを「オカネによってどのように保証できるか ? 」という観点で分類します。

次に、保険で手当てできるかどうかを検討します。例えば、最近では「天候デリバティブ」なんていう方法があります。天気が晴れか雨か、気温が高いか低いかによって、会社の業績が著しく異なるリスクがあるような場合には、保険料を支払ってでも、リスクをヘッジしておきます。遊園地などのリゾート産業では、「週末に雨が降った場合には、 1 日につき、○百万円の保証金がもらえる ･･･ 」なんていうデリバティブを購入して、雨というリスクに備えたりしているわけです。

しかし、すべての金銭的なリスクが、損害保険や天候デリバティブで解決できるわけではありません。例えば、「新しいシステムの導入時点に、パソコンの納入が遅れて、システムが導入できない ･･･ 」なんていうリスクについては、あまりにも個別の事情すぎて、損害保険では対応できません。こんな場合には、その納入業者との契約で、「納入期限に遅れた場合には、 1 日につき、○百万円の損害賠償を支払う ･･･ 」なんていう契約を結んでおくことが必要です。

また、他人が関与している事柄は契約書で縛りをつけることができる一方で、自分が原因を作ってしまうようなリスクについては、契約で対応することはできません ( 自分自身で契約を結ぶわけにはいきませんから )。例えば、「予想以上に出張費がかさんでしまい、予算をオーバーしてしまう ･･･ 」というリスクについては、プロジェクトのスタート時点で、それを見越した「多めの予算」を確保しておくことが必要です。

外資系企業では、これを「コンティンジェンシー予算 ( contingency budget )」と呼んでいます。もちろん、日系企業でも同様の予算を確保しているのが通常ですが、私の経験では、外資のコンティンジェンシーの金額は、日系企業とは比較にならないほど大きいと思います。感覚的には、外資の場合、プロジェクト費用の20% 程度は、コンティンジェンシーだと思います。一方、日系は 10% 程度ではないでしょうか。

同じようなプロジェクトであっても、外資の見積金額が高いのは、まさにコンティンジェンシーの積み方に差があるのです。日系企業というのは、たとえそのリスクが想定できるものであっても、何とか「気合」で乗り切ろうとします。そうやって、見た目の割安感を出すわけですが、外資の場合は、経験上想定できるリスクについてはコンティンジェンシーを確保しないと、そのプロジェクトを実施することすらできなかったりします。外資の場合は、お客さんであろうが、業者であろうが、想定できるリスクはすべて共有すべきだという考えに基づいています。業者がリスクをすべてかぶって、泣き寝入りしてでも値段を下げようとする日系とは、大きく違う部分といえるでしょう。

次は、 Issue 管理です。どんなにリスクを把握し、コンティンジェンシーを積んでいたとしても、想定できない問題は発生するものです。そもそも上記に述べたように、リスクへの対応は主に金銭的に手当てされます。しかし、プロジェクトはオカネさえあれば問題なく進められるものでもありません。非金銭的な部分はリスクヘッジが難しい部分なのです。

Issue 管理で最も重要なことは、「いかに素早く対応し、 Problem として露見させないで済ませられるか」ということにつきます。 Issue とは、あくまでも「近い将来に問題が起こることが確実な状況」なのであって、その段階で食い止めておけば、具体的に損害は生じないのです。 Problem として実際に問題を発生させなければよいのです。

では、 Issue の段階で解決するにはどうすればいいのか ? これについては「魔法の杖」は存在しません。やるしかないのです。外資はこのことをよく理解しているからこそ、 Issue 管理がプロジェクト管理の中心となります。

具体的には、「 Issue DB ( イシューを管理するデータベース )」を作成し、プロジェクトメンバーに対して、 Issue と思われるものをすべて上げさせます。このときに重要なのは、「メンバー自身に Issue かどうかを判断させない」ということです。どんなに些細なことであっても、メンバーには Issue を上げてもらい、その判断は 「 Issue Manger ( イシュー・マネージャー: Issue 全体を管理する人、 PM を補佐する立場の人が就くケースが多い )」が実施します。

こうして選別された Issue について、 Issue Manager は、その Issue を解決する「責任者」を、ほぼ独断でアサインします。「おいおい、こっちは忙しいんだから、勝手にアサインすんなよ ･･･ 」と言いたくなるのですが、 Issue の解決というのは、どんな作業よりも重要だと位置づけられるので、無理やりにでも、その責任者が対応しなければならないのです。

かなり強引なやり方のように思いますが、これぐらいやらないと、 Issue なんてものは解決できないのも事実です。 Issue Manager は、アサインした「責任者」の背後に常に張り付いて、「解決したかぁ～、やったのかぁ～」と呪文のように唱えながら、 Issue のトラッキングのみに終始します。

一方、多くの日系企業の場合は、Issue の段階では個別の解決担当者をアサインしたりしないように思います。その最大の理由は、 Issue が解決できずに Problem が発生してしまった場合に、個人的な責任を取らずに、組織全体の責任にしてしまいたいからではないでしょうか。「みんなでやった結果こうなったんだから、仕方ないよね ･･･ 」としておけば、だれも傷つけずにすみます。しかし、それではプロジェクト全体に影響が及び、取り返しのつかない Problem に発展してしまうケースがあるのも事実でしょう。

このような外資の考え方は、日系企業にはなかなか受け入れられないかもしれません。しかし、Issue の段階で「死んでも」解決しようという姿勢については、参考になる部分が多いように思います。