マネジメントの意思決定は関数であれ
この記事は、stand.fmで配信している実況スタートアップ経営 | Sho's roomの「マネジメントの意思決定は関数であれ」をAmazon Transcribeで文字起こしして、読みやすく編集したものです。
こんにちは、Sho's roomです。このラジオでは、メトロエンジンというスタートアップで僕が普段どんなことを考えながら経営しているのか、などをお話しています。
今日は、マネジメントの意思決定は関数であれ、という話です。
マネジメントといっても、役員から部長職、プロジェクトマネージャーまで、いろんなレイヤーがありますが、どのレイヤーにおいても、マネジメントにとって意思決定は仕事の中で大きな割合を占めます。
僕も、役員として、いかに良い意思決定をできるか、という点には普段から脳みその大部分を費やしています。
関数とは
まずは、「関数」についておさらいしておきましょう。ずいぶん昔のことなのにわりと鮮明に覚えているのが、高校数学の授業で先生が「誰か関数の定義わかりますか？」と聞いたときに、わかる人はほとんどいなかったので、おそらく関数の定義を自信持って言える人は少ない気がします。
関数は、中学１年の数学で習いますが、y = f(x) において、x が変化するとそれにともなって y の値が１つ決まる、というものです。
たとえば、y = 3x という等式があったときに、x = 2 を代入すると、y = 6 と一意に定まります。x = 2 を代入したときに、ほとんどの場合 y = 6 になるけどたまに y = 2 になるとか、y = 2, 6 と複数の y が出てくるとかではなく、常にただ１つの y が定まる。これが関数です。
ちなみに、y = 4 になる x は１つである必要はありません。y = x^2 （x の二乗） のとき、y = 4 になるのは x = -2, 2 の２つになりますが、これはOKです。
大事なのは、関数においては、同じ数字を x に放り込むと、常に同じ y が吐き出されるという点です。
意思決定というものは、こうではなくてはなりません。
意思決定にも大きいものから小さいものまで色々ありますが、今回の場合、例えば、メンバー（部下）に「A社に導入提案をしていて、10%値下げを要求されているんだけれども、5%値下げで逆提案してもいいですか」という提案・相談を受けたときに、OKなのか、ダメなのか、もしくは違うやり方で進めるべきという判断をするのか、という意思決定をイメージしてもらうと分かりやすいと思います。
このような提案を受けるときには、事前情報も一緒に伝えてもらうことになります。A社の企業規模、キーマンと話しているのかどうか、競合とのコンペになっているのか、A社の導入スケジュールと予算、など。事前情報がなければ、意思決定のしようがありませんよね。
これらの事前情報が、先程の関数における x となります。そして、意思決定が y です。
つまり、一回まとめると、同じ事前情報が与えられたら、常に同じ意思決定をせよということです。
関数は公開せよ
事前情報が変わってないのに意思決定が変わってはいけません。前回、全く同じ状況でOKだったのに、今回はNG、みたいなことが起きると、現場が混乱しますよね。
こう聞くと当たり前の主張のように思えますが、ポイントは、意思決定ロジックを関数として意識することによって、そのロジックがブラックボックスにならずに、メンバーにも見える形で公開される点にあります。
「マネジメントの意思決定が関数のようである」メリットは、組織の生産性を高めることにあります。
どういう状況、どういう事前情報のときにどういう意思決定がなされるのかメンバーが理解できていれば、メンバーがマネジメントのように考えて現場で自ら業務を遂行していけます。これはいわゆる、「経営的視点を持つ」というやつです。
経営的視点を持て、というのはよく言われますが、これはメンバーの心持ち以前に、意思決定ロジックが公開されていることが必要です。経営的視点を持て、という言葉自体は、その実行性の低さから批判されることも多いですが、現場でお客さんの生の声を聞いたり、情報をヒアリングしたり、提案をするメンバーが経営的視点を持つこと自体は、強い組織になる上で大切なことです。
意思決定が関数になることで、メンバーとしては、「なるほど、こういう事前情報を与えるとこういう意思決定がなされるんだな」ということを学習しますが、それだけではやや非効率的です。
x と y の関係性から、中の関数を推定することは、試行回数が増えてくれば可能ですが、より明示的に、マネジメントの頭の中にある関数を言語化したほうがよいですよね。
例えば、さっきの「A社に導入提案をしていて、10%値下げを要求されているんだけれども、5%値下げで逆提案してもいいですか」という提案に対して、A社の導入スケジュールと予算が事前情報として与えられなかったとします。
意思決定として一番よくないのは、事前情報として与えられたときだけ考慮して、与えられないときには考慮しない、というやつです。これは暗に、意思決定ロジックが確立していないことを意味しますし、つまり、関数として成り立っていません。
次によくないのは、（導入スケジュールと予算が分からないんだったら、A社の規模感で考えると、おそらく決算月の3月が一つポイントで、予算もだいたいXX円くらいだろう）と自分の頭の中で欠損情報を補完してしまうことです。
意思決定の関数はできているが、それが公開されていない状態ですね。
良いのは、「導入スケジュールと予算は確認した？」と聞き、それが聞き漏れではなく、まだそこまでの関係を構築できていないなどの理由で聞けていないなら、「じゃあ決算月の3月が一つのポイントとしていったん考えようか」と、必要な事前情報が欠損しているときの補完ロジックを口に出しながら意思決定までもっていきます。
こうすることで、導入スケジュールと予算は意思決定に必要な情報だということが明確になりますし、次から、マネジメントの意思決定ロジックに沿った形でメンバーから提案がなされるようになります。
こうなってくると、組織としてのスピード感も上がってきます。なぜなら、稟議に時間がかからなくなってくるからです。
マネジメントの意思決定ロジックがメンバーにインストールされれば、稟議は単なる作業になり、提案が却下され、再度情報収集をして、再提案をして、というプロセスがなくなります。
最終的には、うまくインストールできているメンバーに権限を移譲していくことになります。
あと、メンバーにとっても、意思決定が関数のようであり、公開されていれば、日々変なストレスを感じずに業務に集中できるのも大きなメリットですね。
おまけに、これはマネジメント側にも脳みそのメモリー消費を抑えるメリットがあります。
僕は意思決定の関数化を進めた結果、どんな意思決定をしたか忘れてしまうようになりました。忘れてしまうようになったと言うと良くないことのように聞こえますが、覚えておくことに脳みそを使わなくてもよくなったということなんですね。
以前意思決定をしたときと同じ事前情報が与えられれば、そのときと同じ意思決定を導き出せるということなので、そこに脳のメモリーを使わなくてもよくなり、楽です。
メンバーには「忘れんなよ」と思われてるかもしれませんがw、貴重な脳のメモリーは、不必要なことの記憶よりも、より重要な意思決定に対して使ったほうがいいと考えています。
関数は更新せよ
ところで、関数は常に固定しておくべきかというと、そうでもありません。改善できるならすべきです。
短期的にコロコロ変わるとよくないですが、もしそうなっているなら、それはおそらく改善が繰り返されているわけではなさそうです。中長期的には、より良い意思決定ができるような関数に更新されるべきでしょう。
例えば、以前は競合の動きを強く意識していたけれども、多くの経験を積んだ結果、顧客が持つ課題の強さのほうが重要で、競合の動きはあまり強く意識すべきではない、という意思決定ロジックの変化はありえます。
そのときには、関数の中の重み付けが変わってくるので、以前と同じ事前情報を与えているのに、下される意思決定が違う、ということになるでしょう。
なので、メンバーとしても、マネジメントの意思決定ロジックをインストールすれば終わりではなくて、継続的にアップデートしていくためのすり合わせ作業は必要になります。
ありがとうございました
stand.fmでは、平日ほぼ毎日以下チャンネルでスタートアップ経営について配信しているので、聞いてみておもしろかったらぜひフォローしてみてください。
この記事が気に入ったらサポートをしてみませんか？