【補助線】情報を集めれば、真実が見えるのか？

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

◆「情報を集めれば真実が見える」は正しい？

プロジェクトマネジャーが上位管理者に対して持つ不満の一つに、報告は求めるが、フィードバックがないという不満がある。つまり、報告は求めるが、行動はしないということだ。実はメンバーの中にもプロジェクトマネジャーに同じような見方をしている人も結構、多い。

なぜ、上位管理者は情報を欲しがるのか。直接的な動機は、さらに上位に報告するために必要だということに尽きると思うが、それにしても、この行動にはある前提がある。それは、

情報を集めれば真実が見える

という前提である。ついでもいっておくと、この前提に基づく行動の中で、目につくのは、情報共有である。情報共有をすることが自分の仕事にどんなメリットがあるかを明確に説明できる人は多くないだろう。

ここで疑問に思うのは、この前提は本当に正しいのかということだ。ものを決めて、行動しなくてはならないときに、先送りするのは情報が不十分だからであることは間違いない。問題は、どの程度の情報があれば十分なのかである。

◆情報を集めても真実はみえない

いろいろな意思決定の場面をみていると、決めるタイミングは、即決か、デッドラインかのいずれかであるケースが多い。つまり、情報量と決めることはあまり関係ないのだ。これが現実だと思う。

しかし、それでも情報を集めることによって、解にたどり着くと信じている。少なくとも、解の範囲が絞られ、解に近づけると思っている。残念ながらこれは、錯覚だと思う。

意思決定という視点から考えてみるとよくわかる。解にたどり着くということは、決まるということだ。つまり、この前提は、情報を十分に集めれば、決まるということである。こんなことはほとんどない。多くの人がそう信じている「問題発生」でこの問題を考えてみよう。

たとえば、スケジュールが遅れているとする。いろいろと情報を集めてみると、状況として、想定していた工数より多くの工数が発生し、遅れが発生していることが分かった。
そこで、問題点はいくつかに絞られてきた。

・工数や生産性の見積もりの問題
・作業方法の問題
・作業者スキルの問題
・ステークホルダの協力の問題

などに問題がありそうだ。問題点は複数あるかもしれないが、もう少し情報があれば、もう少しはっきりしたことが分かると思う人が多い。

そこで、行ってきた作業を詳細に分析する。そこでさらに何かが分かると期待しているわけだが、実はわからない。なぜなら、作業方法とか、作業スキルとか、ステークホルダの協力に問題があるかどうかは、共通の認識ができないからだ。作業方法は標準があってそれから外れていれば問題があると考えられるが、標準より細かなレベルは主観の問題である。同様にスキルに問題があるかどうか、協力に問題があるかどうかは、人によって感じ方が違う。


◆最後は決めなくてはならない

つまり、問題があるかどうかは、主観の問題であり、しかるべき人が決めるべきことである。いくら情報を集めても、「正解」が見つかるわけではない。

以上のような意味で、「それは情報を集めれば真実が見える」という前提は正しくない。だとすれば、情報を集める活動はどうすればよいのか。２つポイントがある。

一つ目は、決めることから入る。つまり、何を決めなくてはならないかを明確にし、そのために必要な情報だけを集める。

それでも収拾がつかなくなる可能性もあるので、二つ目として決めることに対して十分かどうかを見極める。ここで重要なことは確率を考えることである。


◆確率的な発想が必要

そのためには、まず、１００％正しい答えを見つけようとしない。だからといって５０％しか正しくない答えでは不十分である。今、持っている情報からどの程度確かな答えを導けるかということを考えるのだ。この確率的な思考をする習慣を身につける必要がある。

ここで、意識してほしいことは、確率は主観的な値だということだ。

実は確率的な発想は、意思決定だけではなく、品質管理のように本来、完全性を求める活動においても重要である。シックスシグマという概念があることからも分かるように、ワールドクラスの品質といっても、１００％ではない。つまり、品質に１００％はありえない。カバレッジの問題である。この際に、一般的な生産財やコンシューマー商品においては、どのくらいの確率で問題が起こるかを想定することは極めて重要である。いわゆる品質基準だ。

ところが、品質基準というのはあるようで、意外と明確になっていない。たとえば、バグ率を品質基準とし、目標値を決める。ここまでは、ソフトウエアエンジニアリングをそれなりにやっていれば実施している。問題は、バグ率の目標を何を以って設定しているかである。本来は最終製品の稼働率などの品質メトリクスに照らし合わせて、構造的な分析をして決められているべきなのだが、これは通常のソフトウエアプロセスだと難しい。結局、経験的になり、そこでは確率的思考が意味を持ってくる。