リスクと不安の哲学的考察（プロジェクトの人間学）

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

未来にはあらゆる可能性がある。そして未来の可能性は未だ現実化していないものである。可能性は現実化されていないが故に可能性であり、未来は未だ来ぬが故に未来だからである。

また、人間は常に不安と共にある（時には潜在的ではあるにせよ）。不安を持たない人間はいない。そして、未来の可能性の中には「意識にとって好ましくないもの」もある。不安とこのような好ましくない未来の可能性が結合する。するとそれはリスクと呼ばれることになる。不安の無い人はリスクに気が付かない。気が付く人がいなければ、リスクは顕わにならない。

リスクとは、不安と共に生きる人間が措定するものである。つまり不安の外出しがリスクなのである。その意味ではリスクもまたクオリアに過ぎない。それ自体で存在するものではない。これはリスクの定義からも明らかである。つまりリスクは可能性であり、可能性は現存しない。

リスクが課題として扱えるレベルまで具体化されたとする。それは常に「もしこうなったら、どうするか」という問いに帰着する。要するにリスク、リスクと騒いだところで具体化すれば大したことではない。単なる好ましくない可能性が、「リスク」というクオリアとして現れている、それだけの話である。

ビジネスの世界では、リスクに対して事前にアクションを取ることが求められる。自分がいつ死ぬかも分かっていないのだが、リスクに対しては「ああすればこうなる」式の対応が求められるのである。原因は常に時系列から見ると後に来る、と先に述べた。つまり常に結果が先に起こり、原因は後付けなのだ。しかし意識はそうは思わない。事象の時系列を逆転し、原因を先に持ってきたがる。そして事象を解釈し直し、あの時ああしなければこんなことにはならなかった、と嘆く。意識は未だ発生しないところリスクに対してすらも、その原因への対応を求める。今こういうリスクが分かっているのだから、事前に対応を取らなければならない、意識はそう主張する。もっともである。しかし問題はトラブルがすでに起こってしまった事象であるのに対し、リスクはまだ発生していない、という点にある。だからはっきり言って語の厳密な定義から言ってしまえば、事前に正確にそのリスクを潰す対応を取ることはできないのである。だってリスクの対象は未だ存在していないのだから。要するに「リスクに対応する」とは、リスクが発生したとしてどうするか、という事後的な対応を検討することに他ならない。

トラブルの種が存在するのは「今」である。だがリスクはトラブルとは違う。「不安」と関係するだけ、もう少し形而上的なものである。「想定通り行かない可能性がある」。これがリスクの本質である。だからリスクは「今」よりもむしろ「未来」にある。具体的な感性で把握できるものではなく、不安から生じた抽象的な概念である。だから具体的に対応しにくい。具体的に対応しにくいから作業スコープと完了基準が明確にならない。だから例えば「リスクを潰す」旨のタスクを定義したとすると、いつまでたってもクローズできないことになる。何をすればよいのか分からないタスクになる。

だが事後的な対応にならざるを得ないとは言え、リスクをある程度まで定義できたのならば手をこまねいている訳には行かない。人として何らかのアクションを取らなければならない。みすみす犠牲を出す訳には行かない。だが、どこまで対応するかはあらかじめ考えておく必要がある。リスクの対象が具体的でない以上、それへの対応もきりがない可能性があるからである。いつまでたってもリスクはなくならない。それはいつまでたっても不安がなくならないのと同じである。どこかで対応を完了させなければならない。だから費用対効果を意識してリスクに対応する必要がある。

恐るべき敵と思われた存在が、後になって実は何でもないと判明することがある。風車と死闘を繰り広げたドン・キホーテのように。ただ少なくとも、プロジェクトにはドゥルネシア姫は存在しない。従って我々はドン・キホーテより冷静に計算できるはずである。つまり風車と戦う必要はないのだ。だからリスクには冷静に対応すべきであろう。

手段と目的が逆転する（プロジェクトの人間学）

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

人が仕事するとき、常に手段と目的が逆転する危険がある。本来の目的が失われ、手段や組織の維持が目的となる。この例を上げるとすれば、わが国の官僚組織だけで十分であろう。

プロジェクトでも官僚組織ほどの規模ではないにせよ、同様に手段と目的の逆転が発生する。例えば以下のようなものがある。

－ツールとその目的
　何のためにツール（プロジェクト管理ツール、開発支援ツール）を導入したのか。
－障害対応とその目的
　何のために障害解析をしているのか。
－会議とその目的
　何のための会議か。
－成果物とその目的
　何のために作っているのか。

手段こそが目的となる。なぜそういうことになるのか。理由はいくつかある。忙しすぎて当初の目的を忘れてしまう。あるいは手段をもてあそんでいると仕事をしている気になり、不安がまぎれる。あるいは手段に集中していると楽しい。などなど。

手段と目的が入れ替わることで優先順位を見失う。本来リソースを投入すべき作業が後回しとなり手段に拘泥することになる。手段があったとして「何のために」が少なくとも２回問われなければならない。そしてそれをしなかったとしてどうなるのか、とさらに問わなければならない。

例にそって考えてみよう。プロジェクトの雰囲気がよくない。状況把握のためにメンバーの士気を調査しようとする。調査するためにヒアリングシートを作成、配布し、記入して貰う。そのヒアリングシートを元に面談をする。

以上、プロジェクトの現場をご存知ないマネジメントが思いつきそうなストーリーを例に見てみよう。「プロジェクトの状況を把握する」ためだけに、これだけのタスクが発生してしまう。コスト対効果を考慮して諦めるか別の方法を検討する方が正しいように思われる。少なくとも筆者ならそうする。しかし、プロジェクト運用を指南した書籍には副作用や体力を一切考慮せず山ほど体力と時間をかけてプロジェクトの状況を把握させようとするものがある。ここではマネジメント層がこのストーリーを採用し、実行に移したとしよう。このタスク群の中に多くのトラップがあることに気が付いて頂きたい。

1. ヒアリングシートの作成が目的となってしまう
ヒアリングシートの作成に無駄な体力を掛けてしまう。最初の目的からすれば面談の取っ掛かりになればよいはずである。それは最低限の基準かもしれないが、最低限の基準だからいけない、ということはない。コストを掛けても掛けなくても効果がさほど変わらないのであれば、コストを掛けない方がよい。その意思決定が出来るかどうか。

2. ヒアリングシートの記入が目的となってしまう
今度はヒアリングシートを展開された側の話である。本来の目的は面談のネタだったはずのヒアリングシートであるが、記入が依頼されたが故にヒアリングシート用ストーリーの作成に体力が掛けられてしまう。

3. ヒアリングシート（面談結果）の分析が目的となってしまう
なぜ山に登るのか。そこに山があるからだ。なぜ分析するのか。そこ数字があるからだ。ある種の人間は、数字を見るとどうしてもグラフを書いたり分析したい衝動に駆られてしまうらしい。だがデータが存在するからといってそれを分析してもよい、ということにはならない。

4. 面談プロセス自体が目的となってしまう
プロジェクトの状況を把握する当初の目的が忘れられ、面談自体が問題となる。「あーよい面談だった」で終わってしまい、付け刃的なアクションプランが取られる。当然効果はない。一時的に親交が深まったかもしれない。でも、ただそれだけ。最初に目的を措定した段階で、次のアクションまでの射程を持っておくべきであった。

手段と目的の逆転は上記に限らない。全ての作業／成果物が逆転し得る。

コスト対効果をちゃんと考慮すればよいなどという単純な話ではない。いちいち細かい意思決定にコスト対効果を考慮する時間などない。そしてタスクというものは一度走ってしまうと、止められなくなってしまう。細かいタスク一つ一つについて、手段と目的を意識するべきである。

例えば上司やマネジメントから作業指示を受けたとしても、必ず最初に目的を明確にしてから指示を受けた方がよい。特に彼らは思いつきで「それっぽい」だけのタスクを思いつきがちだからである。「それは何のためですか？」「とすれば最終的にはこうなることを目的としているわけですね？」「目的からすると成果物はこういうトーンでまとめる方向ですね？」。そしてたたき台として８割型の完成度のものをレビューしてもらう。受けた指摘を修正し、９割５分の出来まで完成、タスク終了となる。上司（マネジメント）の指示だからといって絶対視する必要はない。