00:00
おはようございます、ゼロトピックです。
今日は、How to delegateということで、権限以上についてお話ししたいと思っています。
まず、10Xという会社において、自分の権限以上の歴史みたいな話で言うと、
ほとんどのスタートアップだったり、起業したばかりの会社というのはそうだと思うんですけど、
社長だったり、創業者の仕事というのは、すごく多岐にわたります。
多岐にわたるし、そのそれぞれでオーナーシップをすごく持つことになるので、
多くの権限というものが、その1人、あるいは2人、もしくは経営チームとかに集中することになります。
僕らの会社、10Xではどうなったかというと、
2020年の頭ぐらいまでは結構ワントップみたいな状態で会社を作ってきたところから、
2020年の夏、秋ぐらいから権限以上を徐々に進めて、
チームでミッションを達成していくというような体制に、少しずつ少しずつ移行できてきたのかなと思っています。
さらに、秋からだと約1年ぐらい、1年も経ってないですけど、9ヶ月とかそのぐらい経ってきて、
またかなり次のステージに進んできたなというふうに手応えを感じている部分もあるので、
今日はその値についてお話ししようかなと思っています。
まず、デリゲーションというか権限以上の目的なんですけど、
個人的に大きく2つに分けられるかなと思っています。
1つ目は、組織体におけるリーダーシップの発揮総量を最大化していくというのが、
デリゲーションの大きな目的かなと思っています。
もう1つが、権限を異常した側、要は渡した側ですね。
渡した側に非連続機会が生まれるというのが、もう1つ大きい目的かなと思っていて、
例えば、自分がプロダクトというものを渡すことによって、
より新しい事業機会を探ることとか、現状の事業を1.1倍ずつ伸ばしていく方法じゃなくて、
2倍、10倍って増やしていく方法を見つけるという探索に時間が使えるみたいな形で、
実は渡した側に非連続的な変化をもたらすためのきっかけが生まれるんですよね。
そもそもその余剰が空いていない場合、基本的にこの人は非連続の変化をする機会すら生まれないと思っています。
というので、この大きな2つ、リーダーシップの総量を最大化するという話と、
渡した人が非連続変化する機会を作れるという、
この2つが権限以上デリゲーションの目的かなと思っています。
これは要は会社が非連続に大きくなるためには、目的であり手段であるみたいなところがあって、
おそらくこれよりも有効な手段ってあまりないんじゃないかなと思っています。
03:03
そこからさらに、僕がデリゲーションしていく上で、
ハウとして気をつけていることを3つちょっと考えてみました。
これについては、スマートHRのCEOの宮田さんが2019年の12月に、
権限以上する技術っていう素晴らしいブログを書かれていて、
そのブログを読んで、あ、なるほど、宮田さん当時こんなこと考えてたんだって参考にする程度だったんですけど、
自分も1年ぐらい権限以上ってものをしっかりやってくる中で、
結構こういうモデルだなっていうのに理解が深まってきたので、
それをちょっと整理してお話ししようかなと思います。
3つあるっていう風にお話ししたんですけど、
1つ目が期待値が明確な採用を行うってことと、
採用したメンバーあるいは会社の中のメンバーに対して、
半歩先のイシューってものをくくり出して渡すってのが1個目です。
2つ目が自立に対してしっかりオンボードする。
3つ目が我々のバリューそのままなんですけど、
背中を合わせられるようにするっていう、この3つがすごく重要だなと、
個人的に大事にしています。
1つ目、期待値な明確な採用と、
半歩先のイシューをくくり出して渡すっていう部分なんですけど、
これいくつかステップあるかなと思っていて、
そもそも10Xなというか非連続な状態をゴールに置かないと、
良い期待値って提供できないかなっていう風に思ってます。
例えばKPIみたいなインジケーターを使った数値での目標設定っていうのは、
歪みうるものだと思うんですよね。
1つはその数値って1つで完全に状態を表すことは不可能なんですよね。
例えば我々のビジネスモデルだとGMVって言われるような、
ステーラーってプロダクトを通る流通学があるんですけど、
これが伸びれば最高ですかって聞かれたら、
まあいいんだけど最高ではないかなって答えると思います。
決してGMVが伸びるだけで我々のビジネスがベストな状態になる、
あるいは社会がベストな状態になる、
パートナーがベストな状態になるとは言えないんですよね。
という意味で、いかにシンプルだったり素晴らしいKPIだっても、
適切に目指している状態を示すことっていうのは無理なんですよね。
そういう意味では、やっぱその2Bについては、
適切な言語を使って明確にしてゴールを置く必要があると思ってます。
それが我々が大事にしている、会社管理上を大事にしていることです。
じゃあその状態が明確になった上で、ゴールまで走り方も揃ってないと、
結局走り方がバラバラで、考え方とか意思決定のプロセスとかがバラバラだと、
全然揃わないわけですよね。
例えば状態を揃ってます。この状態を目指そうって言ってるのに、
06:00
そこの登り方っていうのは色んな方法がある。
むしろ無限にあってどれを選ぶかっていう問いだと思うんですよね。
どれを選ぶかっていうときに共通のプロトコルがないと、
例えば会社として築いてきたアセットが全く活かされないから遅くなってしまうとか、
それぞれが別の登り方をしているが故に、
適切なエンパワーメントが会社としてできないみたいな問題が起きちゃいます。
という意味ではゴールまでの走り方、すなわちそれは戦略だと思うんですけど、
戦略の理解度を揃える必要があると思っています。
こういった前提をちゃんと敷いた上で、
期待値のメーカー採用で半歩先の意思を渡すという意味で言うと、
まずは期待値、半歩先の意思、
どちらも範囲を的確に設定する必要があると思ってます。
半歩先っていうのは結構キーだとは思うんですけども、
私はどこまで決めていいのか、私はどこまで自由に考えてやっていいのか、
自由にといっても例えば会社のバリューに沿って考えてやっていいのかっていう部分が
明確じゃないと結局その都度、
例えば上司、僕だったりに確認が入るようなシステムになっちゃうんですよね。
それは決してお互いのリソースのあるいはリーダーシップの最大化に
つながっているとは思えないので、
どのレベルまであなたには決めてほしいとか解決してほしいっていうことを
ちゃんと明確にした上で、その意思については
完全に背中を合わせますっていうことを適切に伝える必要がある。
そういう意味で、範囲を的確に設定する必要があると思ってます。
この的確にっていうところがポイント、半歩先っていうところがポイントで、
例えば新しく入社した人に、
じゃああなた明日から例えばテスラと同じ会社作ってくださいみたいな意思を
渡したとしても当然無理だと思うんですよ。
人にのポテンシャルだったり現状を発揮できる
バリュみたいなものに対して適切な
括りの意思っていうのがすごく重要なんですよね。実はこの適切な括りってものを
うまくできないまま意思を渡してしまうケースっていうのは結構
多いのかなっていうふうに、個人的にも失敗したケースでは多かったかな
っていうふうに思っていて、その相手を見てしっかり観察した上で
今の状態、そして彼彼女がどういう状態になってほしいか。
半歩先はどういう状態かなっていうのを見定めた上で
意思をカットして渡していくっていうことがすごい重要だなと思ってます。
あとはそういう仕事の仕方をするよとか、そういうことを目指している
ってことを採用の時点で握っておくとか、入ってきてもらうときの期待値として握ったり
あるいはそういう期待値が変わっていくのであれば
その都度しっかりその個人が目指す場所も含めて
明確にしていくっていうのが重要かなと思っています。
その渡したイシューの中で
さっきも同じなんですけど、そのイシュー、例えば何々を何々できるようにする
みたいなイシューがあった状態の中で、そこに対して
09:02
渡した先の人がどう到達するかについては
僕も彼彼女も分からないっていう前提なので
分からないだから、たくさん試してほしいんですよね。
たくさん試せるように環境を整えてあげるっていうのが渡した側の責務かなと思っています。
例えばチャレンジの機会が見つけられないのであれば
見つけるところを手伝ってあげるとか、見つけるための
方法論をインストールするのを手伝ってあげるとか
あとは心理的な面でも失敗することが
理想共通認識を持って
範囲が的確になった上で
失敗することが怖いっていう状況になってしまうのは
自分の責務だとは思っているので、こういうものを踏まえた失敗とか
チャレンジについては無条件で称賛するみたいなのもキーかなと思っています。
これは宮田さんもすごくおっしゃっていた部分ですね。他方では
称賛してはいけないチャレンジもあるかなと思っていて、それは会社が大事にしている
ことからそれているものについては、ちゃんとフィードバックをかけて
直す方が良いなという風に思っています。うちでいうと
TXが逆算するとか、自立するとか、背中を合わせるみたいな
バリューがあるんですけど、例えばなんかイシューがポンと渡されたときに
とりあえず100個考えられる点を1から順番にやってみる
みたいなアプローチをとっていたとしたら、それはちょっと違うよねと
その中でも優先順位ってあるはずだよねっていう逆算的な
アプローチをしっかりバリューベースでフィードバックするみたいなのが
必要かなと思っています。とはいえ、それらの
踏まえた上での失敗、チャレンジっていうのは本当に
どうせ誰がやっても同じ失敗するものだっていう風に
捉えているので、どんどんやってください。ありがとうございます。素晴らしいですっていう
言葉をかけるのが良いのかなと思っています。僕の場合はちょっと
怖いらしいので
気をつけますと。2つ目が自立でオンボード
するっていうところで、自立してもらうためには惜しみなく
情報が行き届いている必要があると思っています。例えば
権限を異常する私と
あなたっていう関係の中で、情報量に格差があったり
入ってくるインプットの総量に格差があったりすると
同じ判断ができるとは到底思えないです。なので
情報の格差がない状態、オープンな状態をどうやって作るかっていう
道を整えるっていうのは会社だったり、私側の責務だなと思っています。
そういうものがあった上で、初めてコンテキストを揃える土台があって
ただコンテキストって情報が取れる状態があれば揃うかっていうと
ノーだと思うので、丁寧にコンテキストを揃えていく必要があります。
例えば一番大事なことは何か。それはこれをなぜやるのかとか
なぜこれが大事なのかっていうコンテキストだと思うんですよね。ホワイですと。
なのでどんなアウトプットに対してもホワイが一番大事だと常に繰り返したり
ホワイが明確でないときは
12:02
それをしっかり壁打ちしてあげて、自立できるように手伝いしていく
っていうのがいいと思っています。
なのでイシューを渡すときにもタスクを渡してしまうと
かなりハウを渡すことになっちゃうんですよね。イシューってのはホワイのレイヤーなんですよ。
だからホワイをくくり出して渡すってのがめちゃくちゃ重要です。
通常、例えば
何らかの業務のプロフェッショナルだったりする人ってのは
タスクのプロだったり、ハウのプロだったり、ホワットのプロだったりすると思うんですけど
これからホワイのレイヤーをやるってのはまた非連続なチャレンジだと思うんですよね。
だから相手のレイヤーをしっかり上げていってあげるってところも
自立に対してオンボードする上ではめちゃくちゃ重要なのかなと思っています。
3つ目が背中を合わせる
っていうところなんですけど、バリューそのままで
当然いろんなイシューを渡してアウトプットが出てくると思うんですよね。
はじめはそのアウトプットにもちゃんとフィードバックしてあげる必要があるものは
やるべきだと思っています。理由は会社から
特に外に出ていくものっていうのは会社の顔になるものなので
そこの品質ってどの品質に落ち着かせなきゃいけないのか
っていうところについてはちゃんと目線を合わせる意味で
アウトプットで直接フィードバックするっていうのは有効かなと思っています。
他方でアウトプットよりも重要なのってやっぱプロセスとか
プロトコルみたいな、あとはどう考えて作るかっていうものだと思ってるんですよね。
もともとそもそも
アウトプットのレベルが一定以上担保できるようなシステムを
我々側が作っておくべきはずで
それがないことに対しては基本的にこっち側の責任だと思っています。
そのシステムを使った上で適切なアウトプットだったり
その個人のアルファが乗ってくるようなアウトプットが出るように
プロセスに対してどんどんフィードバックの力点を
ずらしていくっていうのが重要。最後にはチームへの直接の
鑑賞を手を引いていくっていうのが一番いいかなと思っています。
そうすると最終的に意思決定、決めたり考えたりするっていうところも
含めて、あるいは提供するものの品質のレベルをどこに
チューニングするのかっていうところも含めて背中を合わせられる
チームが作れていくのかなと思っていて、徐々に徐々に
はじめはアウトプットみたいなとこからよりプロセスに入っていって
考え方とかバリューとかコンテキストみたいなところに入っていって最後は離れる
チームのフィードバックはそこのマネジメントにお願いする
っていう、そういう形の権限異常が一番スムーズなのかな
というふうに思っています。ということでちょっと長くなったんですけど
大きく3つ、僕が権限異常するときに気を付けていること
期待値の明確な採用と半歩先の意思を渡す
自立へオンボードする、背中を合わせるっていう、この3つについて
お話ししました。もう少し
言語化して整理したいなっていう部分もあるので
15:02
ぜひこの内容はそのうちブログかなんかでも書こうかな
と思っています。では今回も聞いて
くれてありがとうございました。それでは
