1. Ray Wow FM
  2. #10 承認プロセスの問題点トッ..
2020-01-15 15:39

#10 承認プロセスの問題点トップ5

承認プロセスで起きがちな問題点と、それが助言プロセスではどう解決されるかについて話をしました
00:05
おはようございます、Rayです。
本日も、Ray Wow FMの時間がやってまいりました。
Ray Wow FMでは、主に株式会社耳に関する様々なテーマを扱って、
時にはゲストもお招きしながら、ゆるくやっていくラジオとなっております。
本日は、承認プロセスの問題点について話をしたいと思います。
特に、承認プロセスの問題点に関して、トップ5の問題点というところを説明したいと思います。
では、まずトップ5から、第5位、自分で決めたという覚悟が生まれにくい、自分で決めたという覚悟が生まれにくいですね。
承認プロセスの場合は、承認者に対して許可をもらう、承認をもらうという形で進めるので、
最終的に自分で決めたという、自分で決めた感がやっぱり少ないんですよね。
そういう意味で言ったときに、やっぱり覚悟が生まれにくいというところが問題点の一つかなと思っています。
ゆめみの場合は、許可をもらうという形で、典型的なのが、サントリーさんの言葉でやってみなはれということがあるんですけれども、
ある意味、創業オーナーが寛容な形で、どんどん挑戦しなさい、その中でチャレンジしていくという形のやってみなはれというところを最初に、
助言プロセスというところで、コンセプト、
定めていたんですけれども、なんとなくやっていくというのにちょっと違うなと。
やってみなはれというのは、やはり許可をもらってやるという、そういうのに近いなと思っていたんですね。
サントリーさんのように、飲料メーカーで、いろんな飲料の商品がたくさんあるような、そういうプロダクト性の場合、プロダクトマネージャーがいて、
その人がどんどんどんどん決めていく、そういった会社としてはいろんなプロダクトマネージャーがいて、いろんな製品があって、
どれかがヒットすれば、10個のうち何個かがヒットすれば、経営としては成り立つというような、ポートフォリオ経営をするようなタイプの事業モデルの場合は、
このやってみなはれというところは、すごくいいと思うんですよね。
ゲーム会社とかも同じような形だと思うんですよね。ゲームのうち何個かに、10個に1個か、10個に2個とかがヒットすればいいと。
そういったところであれば、どんどんどんどんやりなさいという形でいいんですけれども、特にイネミのビジネスのような場合というところは、
ある意味、1つのプロジェクトも失敗してはダメな部分というところがあるので、やってみなはれという形でやっていいよと言われても、なかなか難しい場合があるんですよね。
そういう場合に重要なのは、許可をもらってやるのではなくて、やっぱり自分が決めたという覚悟を持って、一歩踏み出して、危険を顧みず、境界を乗り越えて、一歩やってみて、
その失敗も含めたいろんな体験から、よし次はこうしようという形で、またもう2歩進んでいって、3歩という形で、
どんどんどんどん、
自分で覚悟を決めて進んでいくというのが重要なので、やっぱりこの承認プロセスというところではなくて、
03:04
助言プロセスによって自分で決めるというところは非常にいいというふうに感じています。
次に第4位。承認プロセスの問題点第4位は、権限を移譲されても承認者への忖度が発生する。
権限を移譲されても承認者への忖度が発生する。これは何かというと、
承認プロセスの場合、
プロセスの場合にも、どんどんどんどん上司から承認をもらう中で、もうお前にこれを任せてよ、いいよみたいな形で上司も判断した場合に、
部下の人に権限移譲という形で、ある一定の範囲をお前に任せたぞという形で任せられる場合があると思うんですけれども、
いざそういう形で権限を移譲されたとしても、都度何かあったときに相談をすると思うんですよね、上司に対して。
そのときに上司からいろんなアドバイスをよかると思ってもらうと思うんですけれども、
やっぱり承認者ではあるので、いくら権限移譲されて任されたと言われても、
その上司からもらうアドバイスをやっぱりちょっと聞かないとまずいかな、忖度を失わないといけないかなというところが発生する。
この承認者への忖度というところは、権限移譲されたとしても残る。
これのさじ加減というところがものすごく承認プロセスの難しいところで、
松下晃之助さんが言っているように、上司のマネジメント、権限移譲の心得として任せて任さずという言葉があるんですけれども、
任せた上でも、どんどんどんどんチェックしたりとか、どんどん状況を聞きましょうというのがあるんですけれども、
部下からすると、なかなか相談したときにどこまで上司のアドバイスを聞くかというところの、
そのさじ加減というところが非常に難しいというところが、承認プロセスの問題点ですね。
では、承認プロセスの問題点第3位。
何階層にもわたって承認が必要。
これはもうね、典型的ですよね。
特に大きな組織になればなるほど、
上司の上司の上司のという形でどんどんどんどん、
特に大きな組織になればなるほど、
どんどんどんどん承認が、エスカレーションが発生するので、
時間がかかる。時間がかかるというのもありますし、
伝言ゲームでどんどんどんどん情報が歪められたりとか、
話が食い散らってくるみたいなところもあったりする。
そういったところがやっぱり、常にインターネット社会だとか、
インターネットビジネスだと、Winner takes allというように、
早くデータとかユーザーを獲得した企業が、
どんどんどんどん、よりユーザーからのフィードバックをもらったり、
データが溜まっていって、よりサービスが優位になっていくという形で、
やっぱり早くサービスを展開していくというところが大事なんですけれども、
こういう承認プロセスというところは、
何階層にもわたって承認が必要なので、
やっぱり時間がかかるとか、というところがやっぱり問題点ですよね。
なので、何階層にもわたって承認していく中で、
結果として否決されてしまうと問題なので、
やっぱり事前のネゴというところが発生するんですよね。
この事前のネゴというところは、
06:01
実は助言プロセスとある意味近い部分もあるんですよね。
意思決定する前に相談するという意味では、
相談というのが途中で最初に事前に入るという意味では同じなんですけれども、
その承認プロセスの場合は、
やはり水面下でこの事前のネゴというところが行われがちなんですよね。
表向いてやってしまうと、誰かからチャチャ入れられて、
意見を潰されてしまうということもあるんですよね。
そういった部分で、いわゆる政治行為とか、
そういったものにつながりやすいですね。
なので、何階層にもわたって承認が必要だから事前のネゴを行う。
でも、それがやっぱり水面下で行われるから政治行為になりがちというところが、
結構根深いこの承認プロセスの問題点かなと思っています。
では、第2位。
混ぜると危険。承認プロセスに助言や教育が混ざっている。
混ぜると危険。承認プロセスに助言や教育が混ざる。
混ぜると危険。承認プロセスに助言や教育が混ざっている。
混ぜると危険。承認プロセスに助言や教育が混ざっている。
これ何かというと、典型的なのは例えば倫理書。
倫理というところを捉えてみたときにあるんですけれども、
倫理というのも実はいろんな関係各所に倫理書が回っていって、
最終決済者が決済するんですけれども、
その途中の段階でいろんな関係各所に倫理書が回っていく中で、
これはああじゃないか、こうじゃないかという形で、
関係各所の意見とかというところが入るという意味では、
これも実は助言プロセスと意図と同じなんです。
けれども、本来は助言プロセスという意味で、
助言をもらうはずの倫理の関係各所への連絡というところが、
なぜか全部の人たちに承認をもらわないといけないみたいな形で、
全員がOKと言わないといけないみたいな、あの条件になっちゃうと。
これ結構難易度が高い無理ゲーになっちゃうんですよね。
全員がOKと言うってなかなか難しいじゃないですか。
なので本来は、実は倫理というところは、
最終決裁を例えばOKってもらうけれども、
その前に一応関係各所にお目通しして、
意見をもらっておこうみたいな、
念のため助言をもらおうみたいな、
目を通してもらおうみたいなところのはずが、
全員承認をもらわないといけないみたいな形で、
混ざっちゃってると。
承認プロセスに助言とか教育が混ざっちゃってるっていうところが、
ややこしい感じですね。
もう一個が、
承認プロセスの中に、
教育的観点っていうところも混ざる場合があるんですよね。
これ結構昔の会社だと、
いわゆるいろんな倫理っていうか、
上司にいろんな提案をしている中で、
上司が何回も何回も部下からの提案をこけおろすっていうか、
どんどんいいものにするっていう意味で、
何度も何度もこれ違う、これ違うっていう形で突き返して、
いいものに仕上げてしょうがないなっていう形で、
最終的に承認するみたいなところがあると思うんですけれども、
実はこれっていうのは、
教育的観点っていうところでやる場合もあって、
本当はその提案っていうところは、
実際のところはもうビジネスを進めるっていう意味ではOKなんだけれども、
その部下の教育的観点からどんどんどんどん、
09:01
あえてそれじゃダメだっていう形で否決するみたいな形で、
承認しないっていう形でやることがあるんですよね。
これがまたちょっとややこしくなると、
部下からすると、あれ?なんで承認されないんだよみたいな、
何がダメなんだよみたいな感じで思うんですけれども、
上司からすると、実はそれ教育的観点で、
何がダメなんだと。
そこが、お互い、上司と部下の間で、
暗黙の合意があればいいと思うんですよね。
こういう形でどんどん否決されるけれども、
これはあくまで教育だから、
決してその内容自体が、
ビジネスの現状にそぐわないわけではないという形で、
部下も分かっていればいいと。
上司も部下が分かっていることを前提で、
腹毛的に、これはダメだみたいな形で振る舞うっていうところが、
成立してればいいんですけれども、演劇として。
それがなかなか、今のどんどん社会になると、
なかなか、そんな何回も何回も突き返している間に、
ビジネス進んじゃうから、それよりもどちらかというと、
まず小さい段階で実際にやってみて、
ユーザーからのフィードバックをもらった方がいい、
っていうところのやり方が変わってきている、
っていうところがあるので、
そういった意味では、この承認プロセスに、
教育的観点が混ざっちゃう。
部下からすると、なんだよみたいな、
どこがダメなんだよみたいな形で、
理解の合意に進まないんですよね。
そういった部分が混ぜるときに、
この承認プロセスに、
いろんな助言とか、
教育が混ざることによる問題点ですね。
では、最後の問題点、第1位。
上司ガチャで外れる問題ですね。
外れの上司ガチャ、
引いちゃった場合の問題点ですね。
これも、
皆さんもいろんな会社で経験したかもしれないんですけれども、
アホな上司にね、
ガチャを引いちゃうと、本当に大変ですよね。
僕は、
幸いながら、
会社勤めをしたことがないので、
そういうバカな上司に、
ガチャを引いたことはないんですけれども、
まあまあ、
お客さんでね、
なかなか理解がないお客さんがいた場合に、
何を言っても提案してもらえないと。
提案して理解してもらえない、
みたいなことがやっぱりあったので、
そういう部分でね、
いろいろ苦労する問題っていうのが、
この承認プロセスであるんじゃないかなと。
特にね、
上司を第一関門としてくぐって、
どんどんどんどんエスカレーションしないと
何も通らないみたいな場合に、
その第一関門の上司っていうところが、
外れる場合は大変ですよね。
何を言ってもアホだから理解してもらえないとか、
あるいは自分のことが嫌いだ、
で、嫌われてるみたいな、
逆に自分がその上司のこと嫌いみたいな、
まあそういう場合は、
本当にもうどうしようもないですよね。
移動を出すにも、
なかなかその上司の移動元の、
今所属している上司の承認をもらわないといけないとか、
まあそういう問題もあったりするので、
これはなかなか大変だと思うんですよね。
で、助言プロセスの場合っていうところは、
上司も自分も、
同じコミッターなんですよね。
なので、
上司の言うことっていうところは、
助言として聞くけれども、
12:00
最後自分が決めるっていうところがありますと。
特にイミミの場合は、
全員CEOなので、
まあそういった部分で権限っていう意味では、
イコールなんですよね、全員が。
まあ、
なかなかこの上司ガチャっていうところの問題は、
深いんですけれども、
まあこれは承認プロセスっていうところ以外に、
権限構造の問題の組み合わさっていうのが、
問題ではあるんですけれども、
やはり一番大きな問題かなと思います。
ただね、この承認プロセスっていうところは、
実は使いどころみたいなところがあって、
やっぱり承認者、
承認者っていうのは、
一般的な結果責任というかね、
最後の責任っていうところを負う部分もあるので、
ある意味その承認者に大きな、
意思決定の承認をしてもらえれば、
その後は、
この人たちはのびのびと、
遂行をすればいいっていう形で、
先ほど話したような大きな投資をするような、
ゲーム会社であったり、
そのプロダクト製の
いろんなメーカーさんであったりとかは、
やっぱりめちゃくちゃ大きな投資しますからね。
そういった部分で、
そういった権威がある人、
創業からいる人で、
その人が失敗するのは仕方ないな、
みたいな前提が成り立つ人に、
やってみなはれみたいな形で、
承認してもらった上でやるっていう形で、
のびのびやって、まあそれでね、
楽しみながらやりながら、
ビジネスを成功させて、
それでまたこう、どんどんどんどん
再投資していく、みたいな好循環を
作るっていう意味では、
この大きなものをね、
博打みたいなものを意思決定するときに、
やっぱり承認者にやってもらうっていうのは、
結構いいですよね。
もう一つが、取り返しのつかないことっていうところは、
やっぱりこの承認プロセスで、
ある意味、門番というか、
ゲートウェイ機能を持って、
やっぱり承認してもらうっていうのは大事で、
特に取り返しがつかないことって、
2つあると思ってるんですけど、
採用とオフィス移転みたいな、
アメリカさんだと工場をね、
作るとか、そういう大きな設備投資を
するっていうのは、やめたっていうのは
なかなかいかないので、採用もそうですね。
人取ってやめたって、なかなか
日本の場合、特にはいかないので、
まあそういった意味では、やっぱりこの
承認みたいな、関門を
作るのはいいのかなと思っていて、
まあいわゆるその、アジャイル的な組織の
代表として、アマゾンっていうのがあると思うんですよね。
AWSみたいなものは、
どんどんどんどんアジリティ持って、
作っていくっていう意味では、典型的な
アジャイルチームなんですけれども、
アマゾンの採用基準、採用によって
すごく特徴的なのが、
バーレイザー、バーレイザーっていう人が、
役割の人がいて、その人が
ある意味、バーを高くする、レイズする、
上げていくっていう、その役割なんですよね。
現場の、その
採用担当者ではない人が、バーレイザーの
役割を担って、その人が、その
採用基準が、これ甘いんじゃないのみたいな、
現場の人が、人が足りないからって言って、
ちょっと基準を甘くしてない、みたいなところが
あったときに、めちゃくちゃ高い基準、
本来の高い基準で、ガンガン落とすと。
どんどん人が足りなくても、
関係ないという感じで、
そういう採用チームが
あるんですよね。っていう形で、
アマゾンみたいな会社では、やっぱ採用っていう
ところは、取り返しがつかないっていうところも
あると思いますし、高い
15:00
基準で採用するっていう、その
決意みたいなものもあると思うんですけれども、
やっぱりこの採用と、
大きな設備投資っていうところは、
やっぱりなんだかんだ、承認プロセス
っていうのを設けるのは、合理的かなとは
思ってますね。
まあね、この
承認プロセスっていうところに関しては、
いろんな問題があるんですけれども、
いみみの場合ですね、
この助言プロセスっていうところをもって、
進めていく。で、また助言プロセスは
助言プロセスでね、いろんな
課題とかっていうところはあるんですけれども、
それはまた次回、話ができればなと思っております。
はい、今回は
承認プロセスの問題点
トップ5の説明でした。
15:39

コメント

スクロール