オルタナティブ・ブログ > プロジェクトマジック >

あるいはファシリテーションが得意なコンサルタントによるノウハウとか失敗とか教訓とか

建設的に監査をやることの困難さ、あるいはインドのコブラについて

»

「0ベース思考---どんな難問もシンプルに解決できる」という本を読んだ。
「ヤバイ経済学」という本を書いた二人組が、常識にとらわれないで物を考えよう、みたいな事を書いている。個人的には、「ヤバイ経済学」の方が面白かったかな。

その「0ベース思考」の中に、こんなエピソードが出ていくる。

インドでコブラを退治するために、「コブラを捕まえてきたら1匹につき○○ルピー払う」という御触れを出したら、コブラを山ほど養殖して大儲けする奴らが現れた。もちろん野生のコブラは全然減らなかった。

「△△したら、○○してあげる」を設定するのをインセンティブ設計というが、コブラの例でよく分かるように、すごく難しい。世の中にはずるいこと考える人が山ほどいて、「本質的にはなんの意味もないけれども、インセンティブだけもらえる作戦」をすぐに思いつくからだ。

だからコンサルタントとして、お客さんの社員が「もっとこういう風に行動してくれたらいいのに」という問題に直面しても、インセンティブで釣るという作戦はほとんど採用しないことにしている。

例えば、営業さんにAという商品を売ってもらいたいとしよう。
本当は上司から「Aを売れー」と号令をかけたらAを売りまくって欲しいところだ。だが実際にはそんな軍隊みたいな組織は稀だ。特に営業のように「自分の成績」が大事にされる部署では。
そこで、「Aを1つ売ったらボーナスに○円上乗せ」みたいなインセンティブが設計される。
日本の会社ではインドのコブラほどひどいケースにはならないが、よく観察していると「インセンティブがもたらす行動の歪み」が生まれてしまうことが多い。
例えば、お客さんに「商品Aを定価で買ってくれたら、こっそり商品Bの方で値引きしておきますから」みたいな感じで。
営業マンはインセンティブをもらえてハッピー。お客さんは値引きしてもらえてハッピー。会社はハッピーではない。難しいものです。


そうやって人参で釣るような作戦よりは、「人々がAを売ったほうが本質的に得だと思う状況を作る」作戦の方が、結局は効く。例えば、商品Aの商品力を高くして、本当に売りやすくするとか。それが無理なら、売るときの事務手続きを劇的に楽にする方法を考えるとか。商品Aを売る時だけ、本社から応援部隊が来てくれるとか。
どれも当たり前ではあるが、こういうことを地道にやるしかない。これも広い意味でのインセンティブ設計だ。ボーナスのように直接的ではないし、考えるのが大変だけれども。


ところで、話は全然変わるんだけど、「監査」って何であれ嫌なものですよね。
会計監査、品質監査、作業プロセス監査など、大きな組織で大きな仕事をやろうとすると、何かしら第三者チェックが入る。社外から監査人が来る場合もあるし、社内に監査部門を持っている会社も多い。
僕の仕事の場合はプロジェクト監査というのがある。プロジェクトの当事者が「順調です」「お金がこれくらいかかります」と言っていてもたまに大嘘の時があるから(悪意があるかないかは別として)、第三者がチェックする。僕は社内から監査してもらった経験もあるし、お客さんのプロジェクトを監査したこともある。


監査する側とされる側、両方の立場に立ってつくづく思うのは、監査という活動を建設的なものにするのはとても難しいということ。
監査される側はとにかく「嫌なところを突かれて、面倒なことにならないように」と思ってそつない受け答えをし、本当にマズイことは巧妙に隠そうとする。
監査人は第三者だから内部事情には疎い。監査される側が本気になって隠そうとしたら、マズイことが見つかるものではない。

本来監査というのは、「当事者にとって盲点になりがちな問題を洗い出し、どれくらいヘルシーかを客観的に示し、必要ならば健全化に向けた手を打つためのもの」であるはずだ。だが、上記のような「突かれたくないから、とにかく隠す」という、本来の目的からは外れたマインドになりがちだ。
この「監査の本来の目的を外れ、とにかく隠す」という構図って、「野生のコブラを減らすという目的から外れ、とにかくコブラを持っていってお金をもらう」というインセンティブ設計の失敗例に似ている気がする。政府がコブラ養殖人に勝てない様に、監査人は本気で隠そうとする人々には中々勝てない。



僕は監査の経験がすごく多い訳ではないが、コツらしきモノが一つあると思っている。


「監査人は警察になるな。協力者になれ」
「監査を受ける場合は、警察に踏み込まれたと思うな。協力者が来たと思え」


ということだ。
特に、監査人の側の心がけが大事だと思う。

監査で本質的なことが見つからなくても、何かしらの違反とか「べきではない行い」を指摘することはできる。
・書式が決められた形式通りではない
とか
・予め予想したバグの発生数より、テストで出たバグが少ないじゃないか!
とか
・軽微なルール違反でセキュリティレベルが少し甘くなっている
とか。

本質的なことは見つからなくても、何かは指摘しないと仕事をしていない様に見えるから、どうでもいいことでも指摘する。監査される側は少しホッとしながらも、「はいはい」と言って従う。
こういうやりとりって、監査人が自分たちが警察官みたいな存在だと思っているから起こるのではないだろうか。もうそういう不毛なやりとりはやめた方がいい。

そうではなくて、監査される側が難しい仕事をやっていることを十分理解した上で、「どうしたら、仕事の現実に沿った形でセキュリティレベルが上がるのか」「プロジェクトがより健全にできるのか」みたいなことを相談する相手になったほうが、ずっと建設的だ。そうしてオープンな関係を築いて定期的に監査していると、本当にヤバイ場合に見つかりやすくなるし、そもそもヤバイ状況に陥りにくくなる。

もちろん、機械的に「形式要件を満たしているか」をチェックするよりは、ずっと難しい。専門家としての経験や知見が必要とされる。でも、どうせ形式要件を満たしているかどうでは本質的なことは分からないのだから、それをやらないと意味が無いと思うんだよね。

Comment(1)