コンセプチュアル・マネジメント

◆リスクマネジメントはうまく行っているのか

これをみて、なんだ、リスクの話かと思った人はもう少し読み進めてほしい。その通りなのだが、意外と認識されていないことだ。

組織からプロジェクトを見たときに失敗することが一番問題で、失敗させないためには徹底的にリスクを洗い出して、最初に手を打っておきたいというニーズがあるため、リスクマネジメントは組織的に、かなりコストを割いて行われているケースが多い。

しかし、実際に行われているリスクマネジメントには、コンセプチュアルスキル由来の問題がある。これについては、戦略ノートに記事を書いたことがあるので、読んでみてほしい。

【戦略ノート305】リスクマネジメントは具体的か

◆経験頼みのリスクマネジメント

この話は一旦おいて、なぜ、組織はプロジェクトマネジャーを信頼できないのだろうかということを考えてみたい。計画レビューのような場で組織全体でリスク分析をすると、確実に言えることは、複数の経験豊かな人が考える分、プロジェクトマネジャー一人で考えるより、いろいろなリスクが出てくる。

要するにリスクを識別できるかどうかは経験頼みなのだ。リスクをチェックリスト化し、分析ツールに使うのはこれを体系的にやろうとしているだけに過ぎない。

ところが、ここに矛盾がある。プロジェクトには新規性なるものがある。したがってリスクも過去の失敗やトラブルの経験からは分からない部分があるのだ。言い換えると二つとして同じプロジェクト計画などない。リスクチェックリストはこのような前提の中でリスクをチェックリスト化していることを理解しておく必要がある。

◆チェックリストとは何か？

つまり、リスクチェックリストはある程度抽象的にならざるを得ないのだ。

たとえば、プロジェクトＡのプロジェクト計画とプロジェクトＢのプロジェクト計画は違っていた。Ａは要件定義のスケジュールが遅れた。Ｂは要件定義のとっかかりが遅れた。

この２つの事象をリスクチェックリスト化するときにそのまま掲載しても役に立たない。そもそも、ＡとＢでは要件定義の仕方も違うかもしれないし、ほかのプロジェクトでも違うかもしれない。すると、要件定義のどの時期に起こった問題は意味を持たない。

そこで、ほかの共通点を探すことになる。たとえば、Ａではユーザが開発サイトに任せっぱなしで要件ヒヤリングに応じなかったのでスケジュールが遅れた。Ｂでは、ユーザが忙しくて時間が取れなかったのがスケジュールが遅れた原因だったとする。

このレベルまで抽象化するとこれでもいいが、リスクチェックリストによってはもっと抽象化し、顧客の分担の作業できちんとした対応がしてもらえないというリスク事象にまとめたとしよう。

その上で戦略ノート３０５に書いたように、抽象的に蓄積されているリスクを、当該プロジェクトの計画を踏まえて具体的に識別できて初めてリスクとして意味のある事象になる。つまり、前回の議論と同じで、リスクチェックリストを有効に使うには、具体化する想像力が非常に大切なのだ。

◆リスクとして識別できなかった問題への対応

さて、ここまではいいと思うが、次の問題は進行中のプロジェクトにおいてリスクとして識別できていなかった事象が生じたときにどういう対処ができるのかという問題だ。

ここで、２つのケースが考えられる。一つは具体的なリスク事象は想定していなかったが、発生したリスク事象を抽象化すればリスクチェックリストに含まれているケース。これは、上に述べたように具体化が不十分だった（見落としがあった）ことになる。

もう一つのケースは、抽象化された事象そのものがリスクチェックリストにないケースだ。この場合は単に同じトラブルを起こさないだけでは不十分である。まず、抽象化するが、そのあとで、その具体的な事象として起こる可能性のあることを徹底的に洗い出す必要がある。

言い換えるとリスクチェックリストに新しい事象が登録されたと考えて、もう一度リスク分析をやり直すのだ。

こういうことがコンセプチュアルスキルが高くなるとできるようになる。