#12 ミッション実現へ向かうための経営システム

「経営システム」という耳慣れない言葉について考えました。

昨日、息子と一緒に今年もセミの幼虫の羽化を見るために夕方頃に近くの公園を散策していました。台風が近づいていたこともあり幼虫探しは難航したのですが、無事今年も幼虫を捕獲でき、深夜にかけて羽化する様子を一緒に観察しました(成虫はすぐに近くの公園へ戻しました)。

そしてこの文章はその時に考えたものを書き留めたものです。

yamotty | 矢本真丈 (10X) @yamotty3

セミを眺めていたら、経営システムとは何を目的とし、具体として何を構築すべきかが言語化できてきた

August 7th 2021

16 Likes

なぜ「経営システム」が必要か

「判断」の品質と総量を向上させるためです。

逆説的に言うと、会社がスケールする上でこの判断の品質と総量は何も手当をしなければどんどん急落していきます。

経営とは企業活動のインフラです。このインフラが安定的な土台を供給してこそ、「事業」「文化」「制度」といったアプリケーションは初めてその価値を発揮できます。そしてインフラの許容キャパ以上にアプリは絶対にスケールしません。経営は企業の上限を定めるのです。

あらゆるインフラは「スケール」によって帯びる性質が非連続に変化します。例えばソフトウェアのトラフィックを捌くインフラエンジニアであれば、100RPSと10,000RPSの2つのサービスが存在する場合、これらに対峙する戦略や求められるスキルは全く異なるはずです。

これと同様のことが経営についても起こります。具体的には「事業のスケール」「組織人数のスケール」などに応じて、経営がカバーしなくてはいけない論点の範囲は広がり、答えを出さなくてはいけない問は増え続けます。

2名で起業したときと、100名に組織が膨らんだときで同じプロトコルを使っていては絶対に”足りない”のです。経営がボトルネックとなり、場当たり的な判断が多くなり、品質が下がることは目に見えるでしょう。これを未然に防ぎ、「判断のボトルネック」を解消するために必要なのが「経営システム」であると考えます。

(ちなみにカッコつけてソフトウェア的なものとアナロジーで経営を結びつけてみましたが、完全な一致を測るのが難しいなと感じたのでこの先ではアナロジーは捨てます)

経営システムは何で構成されるか

「判断の品質と総量をスケールさせる」いうイシューに対して、自分自身は以下の2つのサブイシューを設定しています。

• 判断しなくて良い問を拡大し続ける

• 判断が必要な問を収集し続ける

これらのサブイシューへ対処していくために経営システムに何が内包される機能を考えてみると、「指針・移譲・フィードバック・評価」の4つではないかと思いました。

「判断しなくて良い問を拡大し続ける」ためには、限られた経営を担うメンバーだけではなく、「判断が民主化された状態」を目指す必要があります「100の問題を、100人で1問ずつ解く経営」というSmartHR宮田さんの記事そのものですね。  このためには「判断の型」となる指針や、「どこまでの問であれば、自分は決めていいのか」という委譲範囲の明示化、そして明確な移譲が必要となります。 

また「判断が必要な問を収集し続ける」ためには、常に企業全体が抱えている問を拾い上げるプロトコルが必要になります。局面で下した判断の結果を評価し、さらに浮かび上がってくる問がフィードバックされたり、システムに再度織り込まれるようなプロトコルが必要となります。

移譲のチャレンジ

4つの機能のうち、自分が特にチャレンジだと感じてきたのは「移譲」です。

以下は2020年9月のスクリーンショットですが、このときにスタートしたプロダクトの移譲を皮切りに、人事、採用、ファイナンス、グロース、BizDevなどを(それぞれメリハリはあるものの)次々と移譲してきたのがこの1年間でした。しかし簡単だと思えたものは一つもありません。それでも創っては渡すを止めることができないのは常にスケールしているからです。最終意思決定責任を持つ自分が常にボトルネックとなることが会社にとっての一番の悪と捉え、チャレンジしてきました。

権限移譲するときのはじめのチャレンジはメンタルモデルの変更です。「自分が手や判断を加えて品質をコントロールする」といった選択肢を捨てるという大胆な変化が必要となります。特に細部に神が宿る系メンタルの持ち主はジレンマを感じやすいのではないでしょうか。

次は「品質のためにチーム作りに心血を注ぐ」という結果とプロセスの距離の変化です。例えばプロダクトデザインの品質を高めようと思ったとき、これまでは自身のスキルを磨けばよいという「結果とプロセスが直結した状態」から、他の誰かが品質を再現したり、上回ったりすることができる環境を創っていくことにフォーカスを変える必要がでてきます。プロセスと結果が直結しなくなるのです。そしてその距離はスケールに合わせて大きく開くことでしょう。

最後がこの結果で生じる「現場との乖離や現場間の乖離を埋めるモデルをつくる」ことです。現場で起きる多数の問から、経営側へエスカレして抽象度高くシステムへフィードバックしていくべきことを漏らさずに行うにはどうすればよいか。

どれも難問であり、100社あれば答えは100通りでしょう。これらを考え尽くしてシステムに落とし込むことが移譲の難しさだと思っています。

つなぐこと

とはいえ、こうしてまがりなりにも経営システムを創っていくと、会社が得られる弾力を最大化できる実感があります。市場の成長や、顧客の変化に対してダイナミズムを持って対応できるしなやかさが育っていることを感じられ、その瞬間の楽しさは「一人の職人」としてプロダクトを創っていたときを超えるものがあります。

しなやかさ、と書いていて思ったのですが、自身の経験から優秀なアスリートとはもれなく関節が優秀です。可動域が広く、高い筋力をそのまま対象に伝えることができる関節を持っています。しなやかさのボトルネックは関節であるとすると、これは組織設計にも活かせるアイデアかも知れません。

経営システムをつくり、移譲によってたくさんのサブチームが生まれる。各所のパフォーマンスが一定程度担保された世界線では、よりこのサブチームをつなぐ関節としての機能が経営により強く求められるのでしょう。

チームとチームを繋いでアライメントを正していく。「全社の整骨院」こそがスケールしたチームにおける経営システムのメイン機能なのかもしれません。