【戦略ノート278】スマート・リスクマネジメント

本ブログは移転しました。こちらをご覧ください

◆「Right Risk」

プロジェクトリスクマネジメントの考え方は、当たり前だがプロジェクトを前提にしている。プロジェクトの制約が厳しくなり、また、創造性が求められるようになってきた今、好む、好まざるにかかわらず、リスクを取らざるを得なくなってきている。

「Right Risk」という言葉がある。（正しい）ゴールを達成するために、取ることが妥当なリスクのことだ。少なくとも、「Right Risk」は取らざるを得ない。

そこで、リスクマネジメントを組織で行うべきだという話が出てくる。これは何を意味するのだろうか？

よく行われているのは、プロジェクトの立ち上げや、計画の時に、プロジェクトだけではなく、上位組織も知恵をだし、リスクを評価し、対策を考えることである。これは、視点の多様性ができるという意味で、確かに有効な方法であり、実際に効果も出ている。

あるいは、リスクマネジメントを知識化し、リスクチェックリストや、リスク兆候の知識化、リスク対応策のナレッジベースの構築などを作る取り組みをしている組織もある。知識化は、リスクマネジメントへの効用だけではなく、教育という面でも効果があるよい取組である。

これらは、プロジェクトリスクマネジメントに対する組織としての取り組みとして位置付けられる。

◆リスクを組織として軽減する

これらは相当普及してきたが、これに対してあまり普及してきていない取り組みがある。それは、リスクの組織としての軽減、あるいは、対応である。

そもそも、リスクチェックリストという発想は、あるプロジェクトでリスクだったことは、別のプロジェクトでもはやりリスクになるだろうという前提である。リスクの性格によってはこの認識は正しいが、たとえば、「上流工程のエンジニアのスキル不足」というリスクが、リスクチェックリストに入っているのは本当に適当だと言えるのだろうか？

もちろん、そのリスクがあるのであればチェックリストに入っていていなくては困るという現場の意見は当然だが、このリスク対策がプロジェクトのスコープでしか行われないので、チェックリストに入るわけだ。

つまり、組織的なリスクマネジメントをするとは、組織全体の視点からリスクの評価をし、対策を取ることである。これは一種のエンタープライズリスクマネジメントである。一種のと書いたのは理由がある。エンタープライズリスクマネジメントは、組織目的があって、その目的を達成するためのリスクに対するマネジメントであるが、受動的な立場のリスクマネジメントを指すことが多い。

もっとも重要な組織目的は売り上げと収益の確保であり、その多くは定常的な業務によってもたらされる。従って、定常的な業務のパフォーマンスを守るために、外部リスク、内部リスクに如何に合理的に対応していくかが課題になる。基本的にはリスクを排除（回避）していくことが方針となる。「Right Risk」といえど、リスクは好ましくないと考えるのが普通だ。


◆スマート・リスク

これに対して、プロジェクトは業務変革であり、一般的には戦略目標を達成するために意思決定を行い、業務遂行を行う。その意味で、「Right Risk」が多くなれば、成果も大きくなることが期待できる。

そこで発生する多くのリスクは、プロジェクトの固有の問題ではなく、戦略実行全体に関わるリスクであることが多い。たとえば、要員のスキル不足は、戦略実行によって新規分野に入っていけば、さまざまな関連プロジェクトで発生する。これに対しては、エンタープライズなアプローチが必要である。

つまり、リスクを取ることを前提にして、できるだけそのリスクが原因でプロジェクトが失敗しないように努力する必要がある。スキルの問題であれば、戦略実行に必要な人材の明確にし、全社を挙げて人材開発をし、スキルフルな人材をプロジェクトに配置できるようにするといったプロセスを作っていく必要がある。このような対応をされたリスクを「イノベーションのジレンマ」のクレイトン・クリステンセン博士は、「スマート・リスク」と呼んでいる。

特にイノベーションのように、リスクがあることが当たり前の世界では、「Right Risk」ではスマートリスクを取るようにすべきだ。


◆リスクをスマート化する

業務変革において、リスクをスマート化するポイントは決して少なくない。たとえば、グーグルはように次から次に、新しいサービスを提供している。新しいサービスの提供をするリスクは生煮えのアイデアで走ることだ。よく知られているように、グーグルは２０％の何をしてもよい時間がある。２０％の時間を確保するという制度によってこのこのリスクは小さくなる。グーグルの本当にすごいのはこのルールを社長も含めた全員が守っていることだ。現場の担当者だけではなく、管理者や、経営陣がそのような時間の使い方をすることは非常に大きな意味がある。その時間を使って現場のアイデアが育っていくような環境を作ることができるからだ。アイデアの評価、アイデア実現プロセス、人事評価など。

これこそ、新しいサービス開発プロジェクトにとっては非常に大きなリスクマネジメントである。

業務変革をどの範囲だと考えるかは企業によって差があると思うが、たとえば、顧客の立場で行うＳＩプロジェクトは、ベンダーにとって業務変革である。これに対して、ベンダーは組織としてどのようなリスクマネジメントをしているのか？このあたりのことをもう一度、考えてみる必要があるのではないだろうか？