コラム

参謀 川勝 洋輔

ルールを作ったら思考が停止した話

 

ルールは効率よく組織をまとめるには便利な一方で、一歩間違えるとそれに依存し、思考が停止する危険性もはらみます。今回は私が経験したルール作成の失敗談を書きたいと思います。

 

***

 

あるとき上司から「品質不良が続いているが、商品の企画・開発時点で回避できる事項が多い。企画・開発者に守らせる”開発禁止事項” を作ってくれ」と言われました。「合点承知」と過去の不良を漁り、体系化し、禁止事項を作成しました。

 

 

■運用

 

数シーズン運用しながら、不良は減りました。が、一方で魅力的な商品も減っているようにも感じていました。…なぜだろう?でも気のせいかもしれないと思いながら、日々を過ごしていました。

 

そんなある日、企画・開発の担当者を交えたミーティングの中でこんな会話を聞きました。

企画 「ここに○○の仕様を入れたいのですが」

開発 「ダメだよ、開発禁止事項に書いてあるだろ」

企画 「そうですか…」

と。その時、自分の中にあった違和感の答えに気付きました。

 

 

■ルールの弊害

 

開発禁止事項というルールを作ることで、確かに不良は減りました。過去の過ちを活かし、効率良く再発防止を図るには良い方法だったと思います。しかし一方で、担当者の試行錯誤や考える機会も奪っていました。「よく分からないけど、ダメって言うんだからやめておけ」というヤツです。なぜそのルールが出来たのか、何が原因で、何が問題とされたのか…。禁止に至った理由や背景が横に置かれ、「この仕様はダメ、以上」という雰囲気になっていました。

 

ここから私が学んだのは、ルールは効率よく組織をまとめるには便利だが、一方で固定概念を作り思考を停止させてしまうということです。似たような話に「五匹の猿」という例え話がありますが、過去の習慣や常識を疑え、が教訓となります。

 

五匹の猿

まず始めに、部屋に5匹の猿を入れます。部屋の中央にははしごが設置されており、登るとはしごの上のバナナを手に入れることが出来ます。しかし、猿がはしごを登ると、登らなかった残りの猿に氷水が降り注ぐようになっています。この状況で実験を開始しました。

 

しばらくすると、猿達は氷水をかけられたくないので、はしごを登る猿を攻撃するようになります。すると、どの猿たちも段々とはしごを登ろうとしなくなりました。

 

そこで、元々いた5匹のうち1匹を新しい猿に入れ換えます。新しく来た猿は、はしごとバナナを発見します。なぜ他の猿達がバナナを取りにいかないのか、と不思議に思いつつも、新参者の猿ははしごを登ろうとします。すると、他の猿達はその新入りの猿を攻撃します。新参者の猿はなぜボコボコにされたのか理解できませんが、攻撃されたくないので、早々にはしごを登ることを諦めます。

 

また同様に、もう1匹を新しい猿に入れ換えます。新参者の猿ははしごを登ろうとしてボコボコにされます。以前ボコボコにされた新参者だった猿も、他の皆がやっているため、今回の猿をボコボコにする行為に加担します。しかし、なぜはしごに登ろうとする猿を攻撃しなくてはならないのか、全く理解していません。

 

このように、5匹の猿を1匹ずつ入れ換えていき、5回目には元々いた猿は全員部屋からいなくなっています。今、部屋に居る猿は氷水を浴びせられたことがありませんが、はしごに登ろうとする猿もいません。全ての猿は、なぜこんなことをしているか分からないまま、はしごに登ろうとする猿が現われるとボコボコにするのです。

 

出典:https://curazy.com/archives/71660

 

■開発禁止事項の見直し

 

この件ではその後、方法を見直しました。「開発禁止事項」ではなく、「過去の事例集」と名前を変え、何をしようとしてどんな仕様にしたのか、結果としてどのような不良が起こったのか、を記載するように変更をしました。その上で、それらはあくまで過去の事例集のため、技術発展や違う手法でその不良が解消出来たり、その不良を上回るメリットを打ち出す商品など、個々の対策は現場に委ねることにしました。紆余曲折はありましたが、現場の方達に考えてもらうことで、事態は少しずつ良くなっていくように感じました。

 

 

■まとめ

 

何事にも一長一短あり、何かを取るということは何かを捨てる、ということと同じだと感じた一件でした。今回はルールを作成することの一長一短を挙げましたが、皆さんの周りにも似たようなケースがあるかと思います。何を取るべきなのか、何は捨てても良いのか、を考えるきっかけになればと思います。

Free-PhotosによるPixabayからの画像