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

◆こんなリスクを特定していませんか

さて、この戦略ノートのテーマのリスクである。たとえば、リスク特定をするときに、

「スケジュールが遅れる」
「要員のスキルが不十分である」
「顧客の対応が緩慢である」

といったリスク事象を挙げている人はいないだろうか（研修はもちろんのこと、実務の計画書でもいることが分かっているのでこの記事を書いている）。このようなリスクを「抽象的なリスク」だといっている。

これを計画に書かれても、一体、何がリスクなのかよく分からない。このリスクに対して、リスク対応策を策定するとどうなるか。たとえば、スキルが不十分だというであれば

「メンバーに○○技術の教育を受講させる」

といった対応策しか出てこない。計画時点でこんな対応策しかなければ、忙しいプロジェクトで実行される可能性はまずない。確かに、抽象的だと行動できないので、ダメだ。机上の空論である。


◆抽象的なリスクは単なる懸念にすぎない

問題があるのは「要員のスキルが不十分である」というリスクが抽象的であることだ。少なくともＰＭＢＯＫ（Ｒ）のリスクマネジメントを前提にして考えるなら、リスクは具体的でなくてはならない。具体的とはどういうことか。

８月２０日～３０日かけて行うアクティビティＸにおいて、担当メンバーのＡはＸ技術の十分なスキルが不十分だ

せめてこういうリスク特定をしなくてはならない。このようにリスク特定すれば、リスク対応策も

「Ａに８月１日にあるＰ社のＸ技術の研修を受講させ、８月２０日までの間に実務への適用の準備をさせる」

という具体的な対応策を策定できる。


◆リスクチェックリスト

今、リスクマネジメントに熱心な企業はリスクチェックリストを作っている。過去の失敗経験の貴重なエッセンスともいえるマテリアルだが、折角作ったのに使い方が間違っている組織が少なくない。

リスクチェックリストは抽象的なリスクをリスティングしたものである。いろいろなプロジェクトで起こったことなので、当然、そうなる。それを自分たちがこれから行うプロジェクトではどうかというチェックをするのは価値のあることだ。

だが、一つ見落としがあるのは、リスクチェックリストは単にプロジェクトレベルのリスクを抽象化したものではないことだ。プロジェクト、つまり、アクティビティレベルや活動レベルのリスクも抽象化されていることが多い。アクティビティレベルであれば上に述べた意味だ。活動レベルであれば、たとえば、コミュニケーションが不調であるというリスクがあるとすれば、これは誰と誰のコミュニケーションかということが抽象化されている。

したがって、リスクチェックリストは、抽象的に自分たちのプロジェクトにそのリスクがあるかどうかを判断するだけではなく、アクティビティレベルでそのリスクはないか、活動レベルでそのリスクはないかと具体的にチェックしなくては意味がない。


◆なぜ、リスクが抽象的になるのか

さて、では問題はなぜ、リスクが抽象的になってしまうかである。

原因ははっきりしていて、計画が抽象的だからだ。計画は、（最低でも）時間、予算、スコープ（仕様と作業）の３つを具体化して、その関係性をつけることである。この関係性があまりにも抽象的なのだ。

本来は抽象的な計画などあり得ない。にも関わらず、なぜ抽象的な計画ができるかというと、関係付が不明確だからだ。

たとえば、ＩＴ業界だと時間と予算の関係づけをしていない企業がある。それは極論だとしても、マイルストーンの単位でしか関係づけが行われていない計画は少なくない。つまり、あるマイルストーンまでの間にどのような成果物を作って、いくらお金と時間を使うという計画は作るのだが、要素成果物に対して、誰が何時間従事し、いくらのコストがかかるかまでは計画していない。

そうするとリスク計画も、あるマイルストーンと次のマイルストーンの間でスケジュールが遅れるとか、その間のいずかの作業で担当のスキルが不十分になるだろうというレベルでしか特定できない。


◆コンセプチュアルスキルがないと計画が大雑把になる

では、なぜ、このような計画しかしない（できない）のだろうか？プロジェクトマネジャーの言い分を聞くと、「そんな細かく計画している時間がないので、やることはだいたいわかっているし、細かな作業計画はメンバーに任せている」というのがほとんどだ。

結構、誤解している人が多いのは、上に述べたような関連付けが必要なのは作業計画ではない。作業計画は段取りなので、予算は関係ない。関連付けが必要なのはベースライン計画である。


では、なぜ、できないのか？ここがポイントである。答えは

コンセプチュアルスキルがないから

である。コンセプチュアルスキルというと抽象化してものを考えるスキルだと思っている人が多い。だから冒頭のような反応になる。

しかし、抽象化すること自体はそんなに難しいことではない。考えればできる。本当に難しく、コンセプチュアルスキルの本質であるところは、具象化するところである。つまり、抽象的な考えを具体的に展開するところ。ここは、相当な創造力と頭のよさがないとできない。なぜならば現実（具象）には制約があるからである。


◆抽象化より、具体化の方が難しい

抽象的な考えを具体に落とすときには、辻褄があっていればなんでもいいというわけではない。たとえば、スケジュール遅れの対応で「１日の生産量を上げる」という結論になったする。ここで抽象化レベルの制約として、絶対的に人が足らないとか、生産性を高めに見積もっているといった制約がなければこの結論自体は問題がない。

そこで具体化するために、要員投入をするという方向性を決め、具体的に人と期間を決めようとすると、その人の稼働状況とか、スキルとかが問題になってくる。その問題をクリアするためにいろいろと考えなくてはならない。これが難しい。

話がそれるが、抽象的に考えても駄目だという人はこの点を言っていることが多い。最初から現実的な制約を考えないと意味がないと。ただ、この言い分が適当でないのは、生産量を上げるという結論からは、要員の投入だけではなく、いくつもの具体的な方法が考えられることだ。具体だけで考えてラテラルシンキングのようなことをするなら、抽象化して考える方が合理的である。

話を元に戻すが、コンセプチュアルスキルというのは抽象化して考えるスキルではなく、抽象化して考え、具体化してみて、うまくできなければもう一度、抽象に戻り、考え直す。この繰り返しのことである。リスクマネジメントを例にとれば、具体的なリスクを洗い出して、リスク対応策が思いつかなければリスクを抽象化してみて、リスク対応策を考え、その対応策を具体化してみればよい。これは創造的問題解決の原理でもある。

そして、これは仕事ができる人が普通になっている方法でもある。