権限移譲のモデル - How to delegate
今回はDelegation = 権限移譲について書きたいと思います。この内容は以下のPodcastで話した内容をベースに、書き起こし時に編集したものになります。
多くのスタートアップや起業したばかりの会社の社長・創業者の仕事は多岐に渡ります。その上、各業務に対してオーナーシップを持つことになるので、多くの権限というものが、1人あるいは2人、もしくはその経営チームなどに集中することになります。
10Xでは創業から2020年の頭までワントップで会社を作ってきましたが、2020年の夏秋くらいから徐々に権限移譲を進めてきました。さらに、その後1年弱が経過し、「次のステージに進んできた」という手応えを感じている部分もあるので、目的・重要な点といったモデルについて整理してみようと思います。
権限移譲の目的
権限移譲の目的は、大きく下記の2つに分けられると思っています。
- その組織体におけるリーダーシップの発揮総量を最大化していく
- 権限を渡した側に非連続的機会が生まれる
例えば、自分がプロダクトの権限を渡すことによって、新しい事業機会を探すことや、2倍,10倍と非連続に成長していく方法を見つける「探索」に時間が使えるようになります。このように、実は渡した側に非連続的な変化をもたらすためのきっかけが生まれていきます。
権限移譲は、会社が非連続に大きくなるために目的であり手段であるといった側面があり、おそらくこれよりも有効な手段はあまりないのではないかとも考えています。
権限移譲における3つの大事なポイント
SmartHR CEO 宮田さんが2019年12月に「権限委譲する技術」という素晴らしいブログを書かれていました。そのブログを読み「なるほど。宮田さん当時こんなことを考えていたんだ。」と参考にする程度でしたが、実際に10Xで1年ほど権限委譲というものをやっていく中でこういうモデルという理解が深まってきました。
それを整理し、権限移譲していく上でHowとして気をつけていることを3つ考えてみました。
- 期待値が明確な採用を行い半歩先のイシューを渡す
- 自立に対してオンボードをする
- 背中を合わせられるようにする
1. 期待値が明確な採用を行い半歩先のイシューを括り出して渡す
まずは「適切・明確な期待を置くこと」と「戦略に対する理解度を揃える」ことが土壌になります。
例えば、Stailerのビジネスモデルだと「GMVが伸びれば最高ですか？」と聞かれたら「良いけど最高ではない」と答えます。決してGMVが伸びるだけで「我々のビジネスがベストな状態になる」あるいは「社会やパートナーがベストな状態になる」とは言えません。いかにシンプルや素晴らしいKPIであっても、適切に目指してる状態を数字だけで示すことは不可能です。
そういう意味では「適切な言語」を使って、明確にしたゴールを置く必要があると思っています。10Xが会社管理上で大事にしていることです。その状態が明確になった上で「ゴールまでの走り方」も揃ってないと、走り方・考え方・意思決定のプロセスなどがバラバラになってしまいます。
この状態を目指すにあたって、登り方には様々な方法があります。むしろ無限にあって、どれを選ぶかが「問い」です。その際に共通のプロトコルがないと「会社として築いてきたアセットが全く活かされないので遅くなってしまう」「それぞれが別の登り方をしているが故に、適切なエンパワメントが会社としてできない」といった問題が生じてしまいます。
つまりは、ゴールまでの走り方、すなわち戦略について理解度を揃える必要があります。こういった前提をしっかりと築いた上で、はじめて「期待値の明確な採用を行い半歩先のイシューを渡す」の話になります。
「期待値」「半歩先のイシュー」の範囲を的確に設定することがスタートです。
半歩先というのがキーで、「私はどこまで決めていいのか」「私はどこまで自由に考えてやっていいのか」といった部分が明確でないと、結局その都度、上司に確認が入るようなシステムになってしまいます。
これはお互いのリソース、あるいはリーダーシップの最大化に繋がってるとは思えないので「どのレベルまであなたには決めてほしい」「解決してほしい」ということを明確にした上で、「そのイシューについては完全に背中を合わせます」を適切に伝える必要があります。
その人のポテンシャルや現状発揮できるバリューに対して、適切な括りのイシューということが非常に重要です。実はこの「適切な括り」というものを、うまくできないままイシューを渡してしまうケースが結構多く、個人的にも失敗したケースでは多かったと思っています。
相手を見てしっかり観察した上で、今の状態、そして彼・彼女が「どういう状態になってほしいか」で「半歩先はどういう状態か」というのを見定めた上で、イシューを適切に括って渡していくべきです。
また、「そういう仕事の仕方をする」「そういうことを目指している」を採用時点に伝えておいたり、入社時の期待値として握ったり、あるいは期待値が変わっていくのであれば、その都度しっかり個人が目指す場所も含めて明確にしていくことが重要です。
例えば「XXをXXできるようにする」みたいなイシューに対して、渡した先の人がどう到達するかについては、渡した側である僕も渡された側である彼・彼女も「分からない」という前提なので、「分からないからこそ、たくさん試してほしい」と思っています。
なので、たくさん試せるように環境を整えてあげることは、渡した側の責務であると考えています。例えば、チャレンジの機会が見つけられないのであれば、見つけるところを手伝ってあげるとか、見つけるための方法論をインストールすることを手伝ってあげるといったことが考えられます。
あと、心理的な面でも「失敗することが怖い」という状況になってしまうのは上の者の責務だと考えているので、失敗やチャレンジについては無条件で称賛することも大事です。
他方で、称賛してはいけないチャレンジもあり、会社が大事にしていることから反れているものについては、フィードバックをかけて直す方が良いと考えています。
10Xの場合だと、例えば何かイシューが渡されたときに、「とりあえず100個考えて1から順番にやってみる」みたいなアプローチを取っていたとしたら、「それはちょっと違うよね」となります。「10Xから逆算する」「自律する」「背中を合わせる」というバリューから見て、「その中でも優先順位はあるはずだよね」と逆算的なアプローチを、バリューベースでフィードバックしていくことが必要と思っています。
とはいえ、それらを踏まえた上での失敗・チャレンジというのは「誰がやっても同じ失敗するものだ」という風に捉えているので「どんどんやってください」「ありがとうございます」「素晴らしいです」という言葉をかけるのが良いと思っています。
2. 自律に対してオンボードする
自律してもらうためには、惜しみなく情報が行き届いている必要があると思っています。
例えば権限を委譲する私とあなたという関係の中で、情報の質や量に格差があったり、入ってくるインプットの総量に格差があったりすると、同じ判断ができるとは到底思えません。なので、情報の格差がない状態、オープンな状態をどうやって作るか、つまり「道を整える」というのは会社や渡す側の責務だと考えています。
オープンな状態の上に、初めてコンテキストを揃える土台ができます。ただ、コンテキストは情報が取れる状態があれば揃うかというと”No”だと思うので、丁寧にコンテキストを揃えていく必要があります。
一番大事なことは「これをなぜやるのか」とか「なぜこれが大事なのか」、つまり”Why”です。
なので、どんなアウトプットに対しても「Whyが一番大事」だと常に繰り返したり、そのWhyが明確でないときは、しっかり壁打ちしてあげて、自立できるように手伝いをしていくのが良いと思っています。
イシューを渡すときにタスクを渡してしまうとHowを渡すことになってしまいます。しかし、イシューはWhyのレイヤーです。だからWhyを括り出して渡すことが非常に重要です。
例えば、何らかの業務のプロフェッショナルの人は、タスクのプロだったりHowのプロだったりWhatのプロだったりすると思うのですが、そこからWhyのレイヤーを実行するということは非連続なチャレンジだと思います。
だからこそ、「相手のレイヤーをしっかり上げてあげる」という点も、自立に対してオンボードする上では、非常に重要な点と考えています。
3. 背中を合わせる
権限移譲の過程で、いろいろなイシューを渡し、それに対するアウトプットが出てきます。初めはそのアウトプットに対して、適切にフィードバックを渡していく必要があります。
会社から外に出ていくアウトプットというのは会社の顔になります。その品質をどのレベルである必要があるかについては、目線を合わせる意味で、アウトプットに直接フィードバックするのが有効であると思っています。
他方でアウトプットよりも重要なのは「プロセス」や「プロトコル」のように、「どう考えて作るか」というものです。そもそもアウトプットのレベルが一定以上担保できるようなシステムを権限移譲側が作っておくべきであり、それがないことは基本的に移譲する側の責任だと思います。
そのシステムを使った上で、適切なアウトプットや個人の+αが乗るようなアウトプットが出るように、フィードバックの力点をプロセスにずらしていくことが重要です。その後、最後にはチームへの直接の干渉から手を引いていくのが一番良い形と考えています。
そうすると、決めたり考えたりするところも含めた最終的な意思決定、あるいは提供する品質のレベルをどこにチューニングするのかも含めて、「背中を合わせられる」チームが作れていくのかなと思っています。
順番でいうと
- 「アウトプット」に対するフィードバック→「プロセス」
- 「考え方」とか「バリュー」とかコンテキストといわれるレイヤー
- 「チームへのフィードバック」をチームのマネジメントに依頼する
この形の権限移譲が一定スムーズではないか、と思います。
10X 採用情報
私たちは今、Stailerを通じて「すべての人の買い物体験を10xする」ことを目指しています。誰もが日常的に利用するお店での買い物体験や、小売の現場でお客様を365日支える方々の仕事体験。「買い物」をとりまく体験を、プロダクトの力で理想の姿にしていくのがStailer事業です。
もっと便利で、もっと多様な購買体験に、日本中の誰もが当たり前にアクセスできる社会を目指して。私たちの仕事は、私たちが大切にしたい誰かの生活と確かにつながっています。