組織の拡大に伴って起業家が習得しなければならない最も大事なスキルの一つが、権限委譲（デリゲーション）です。創業間もない頃は、創業者自身がほとんどの仕事をこなします。創業チームと共に初めてのプロダクトの完成を目指してあれこれ思案する楽しさは、スタートップ時代の最も懐かしい思い出の一つでしょう。しかし、そのやり方でスケールはできません。企業を成長させるために、いずれは社員を増やし、タスクを任せていく必要があります。
根っからの起業家気質の人にとって、新体制への移行は決して楽ではありません。ですが、自ら物作りをする起業家が経営者に進化するには、いつ何を人に権限委譲すべきなのかを考える必要があります。でないと、マイクロマネジメントしていると言われかねません。実は、数ヶ月前に自分がそう言われてしまいました…（笑）チームの人が、自分はマイクロマネジメントしている、とフィードバックしてくれて初めて気づいたのです。それまで誰にも言われたことがありませんでした。これがきっかけとなって、なぜ自分がそうしていたのか、どうすれば人に仕事を任せられるようになるのか、そのようなことを考えるようになりました。
自分なりに探した中で一番まとまっていたのが、Founders FundのGPで（かつてSquareのCOO、LinkedinのVP、PayPalのVPを務めた）Keith Rabois（キース・ラボア）氏が示したフレームワークでした。そのタスクをこなすことに自分自身はどれだけの自信（確信）を持っているのかと、タスクを完遂できなかったときのビジネスへの影響度合いとに基づいて、権限委譲の判断をシンプルに示しています。ビジネスへの影響度合いを踏まえることが重要なのは、あなたがそのタスクを人に任せたか否かに関わらず、あなたがリーダーとしてどんな失敗であっても最終的に責任を取らなければならないからです。重要なのは権限委譲をし、権限放棄をしないことです。
2と3を選択することは簡単です。会社にとって失敗の影響が甚大で、そのタスクを自分自身であれば遂行できるという強い確信があるのであれば、2を選ぶべきでしょう。介入してタスクを完遂しましょう。アーリーステージ・スタートアップのCEOの場合、資金調達がこれに当たります。うまく行かなくても大した影響がない場合、そして、それをどう遂行すべきなのか自分自身では確信があまりない場合には、3を選んで完全に任せるべきでしょう。あなたのチームがこうした失敗から学ぶことに意義があるし、あなたもこうしたタスクに時間をあまり費やしてはいけません。
1と4はなかなかトリッキーです。1の場合、自身でタスクを遂行できますが、タスクが失敗に終わったとしても、ビジネスへの影響は大きくありません。その場合は、タスクの遂行方法を説明し、権限委譲をすべきです。ときには、チームメンバーがタスクの正しい遂行方法について確信を持っていて、そのやり方が自分の思っている方法と違う場合があります。「これがやり方なので、とにかく言われた通りにして」と言うこともできます。しかし、そうしてしまうとモチベーションは下がってしまい、あなたも上司としてその切り札をそう何度も使うわけにはいきません。Keith氏曰く、このような状況のときには、自ら考え決断できるようチームメンバーに裁量を与えるべきなのです。モチベーションが上がり、自分が間違っていて実は現場の声の方が正しい、と言う嬉しい誤算もあるかもしれません。いずれにせよ、そのマイナスの影響は少ないはずです。
4は、タスクの失敗によるビジネスへの影響が大きく、自分自身でもタスクを遂行できるという確信の度合いが低いような状況です。これがなぜ最も難しいかもしれないかというと、引き続き干渉しつつも、過干渉になってはいけないからです。例えば、ソフトウェアをローンチした後に深刻なバグが見つかったとしましょう。Keith氏でさえも、協働以外の明確な方法について言及していません。タスクの完遂を確実にしつつ、各々が自らの専門性を発揮しタスクを完遂できるであろうとチームを信頼する他ないのです。
マイクロマネジメントが妥当なのは2に該当し、4にもある程度該当すると思います。1と3のときには、マイクロマネジメントすべきではありません。権限委譲を検討する際にこのフレームワークがみなさんの一助となれば幸いです。
Founding Partner & CEO @ Coral Capital
