Hatena::ブログ(Diary)

naoyaのはてなダイアリー

February 07, 2013

権限委譲、リーダーシップ、チーム

いいか、覚えておけ。おれにしてもお前にしても、それなりに成功するってことは、なにかは得意なんだ。でも大体のことは不得意極まりない。全部自分でやろうとするな。自分よりも何かで優れている人たちが、その何かでお前のためにチカラを貸したいと思うような人間になれ。

それがリーダーってもんだよ。

「それがリーダーってもんだよ」

この記事が話題になってた。リーダーシップというのは力を貸してやろうと相手に思われることだという、いい話。

この手の話は、誰もが否応なしに社会で経験することだから、みんなそれぞれ自分の考えを述べたくなる・・・という話題でもありますね。例に漏れず、自分も少し経験から感じることを書いてみよう。

「権限」を「委譲」する?

「上司が何かを部下に任せる」という文脈でいくと、このストーリーは「権限委譲」の話にもみえる。確かにテーマとしてはそうなのだが、自分は一般で言う「権限を委譲する」という考え方そのものにちょっとした落とし穴があると思う。

「権限」なるものを「委譲する」という言葉には、前提として権限というものがすべて自分の側にあってその一部を相手に手渡す・・・というニュアンスが含まれているのではないか。

http://dl.dropbox.com/u/2586384/image/20130207_110156.png

相手と自分の間には明確な上下関係があって、意志決定権限・リソース・器、なんでもいいのだけど自分のほうが全部あるいはたくさん持っていて、その中の一部を相手に渡す・・・。そういう考え方が無自覚にも潜んでいる。「相手のできることは、自分のできることのサブセットである。」

でも、それでいいんだっけか?

小さなチーム

立ち上げたばかりのプロジェクト、例えば有志で集まってカンファレンスを開こうとしたときの事務局とか、オープンソースで何かソフトウェアを書こうとか、知人と一緒に漫画を書いてコミケに出展しようとか、あるいはスタートアップなベンチャー企業でもいい。なんでもいい。

そういうプロジェクトは得てしてゴールが明確だけどその達成のために色々と大小課題が沢山転がっているというところからスタートする。

http://dl.dropbox.com/u/2586384/image/20130207_110218.png

こういう状況の場合、良いチームでは、先の「権限委譲」みたいな考え方で物事が進むのではなくって各個人がそれぞれ「おれこれやるわ」「じゃあ私は前にやったこともあるしこれを」という感じで課題が消化されていく。ありがちな言葉で言えば共通のゴールをみながら各メンバーが自発的にプロジェクトに「コミット」する・・・という空気。スクラムとかが目指しているプロジェクトのあり方、というのはそういうことだと思う。

自分はこの手の話になったときに実体験からよくする話があって、立ち上がったばかりの数人のスタートアップっていうのはおかしな話「水を買う」ということすら誰かがやらなければいけないということ。当たり前なんだけど。

会社に行って水が飲みたいと思っても水がない。だから水を買わなければいけない。大きな組織では水くらいはだいたいあらかじめ用意されているか、あるいは決まった人が購入しておいてくれる。それだってもともとは始まったばかりのころに「水飲みたいよね」「じゃあおれが定期購入の手続きしとくわ」というやり取りがあって、その組織では水が飲めるようになったという経緯があった・・・はず。たとえ営業だろうが技術職だろうが、ちいさなチームでは「水を買う必要」みたいな各人の職業上役割に収まらない話が日々発生するので「おれの仕事は水を買うことじゃない」とか言ってても何も物事が進まない。だから、自然と各個人が自発的にそれぞれの課題をこなす、ということになりやすい。実際それで自分は水を買ったことがある。その時には決して「水を買ってよし!」と権限を委譲されて買ったわけではない。というか、そんなの嫌だ。

リーダーの役割

何かの課題を複数人で解決するという同じテーマに対して「権限委譲」の方で示した構造と、後に示したチームの構造は大きく異なる。で、自分の考えるリーダーの役割というのは決して「権限を委譲する」、みたいな「自分の中から一部を相手に託す」ことでななく、チームの構造を後者の形になるように整えるということなんじゃないかなとおもう。

チームの構造を後者の形にするためには、目指すゴールがみんなと共有されていなければいけないし、どんな課題が解決されていないかが見えていなければいけない。How to で言うなら、カンバン で課題を見える化して、毎日5分のスタンドアップミーティングを開いてチームが正しくゴールに向かっているかを確認するとか、そういうことをオーガナイズする。

もちろん大切なのはやり方ではなくて、何のためにそれをするのか、ということ。リーダー自身がそれをすることもあれば、結果的にオーガナイズする人を見つけてやってもらうというリーダーもいると思う。

そしてその、チームがチームとして機能する枠組みを整えるということも、先の図でいうところの「丸」のひとつにすぎない。それをやる人と、その他の丸、例えば技術的な課題を解決するとか、水を買うとか、あるいは新しい人を採用してくるとか、それぞれの丸の間に上下関係や優劣は存在しない。それが理想の状態だと思う。なかなか理想通りにはいかないのだけど、少なくともそれに近づける努力があるべきだと思う。

自分は過去10数年働いてみて、大きな組織が苦手だなということが身に染みてわかった。小さな組織では、あまり苦労しなくてもチームがその理想に近いチームとして機能する方向に全体の力学がはたらく。小さなチーム、大きな仕事で37シグナルズが言っているのはそいうこと。最近話題になっている github の働き方 にも共通するものがあるんじゃないかな。

大きな組織では、小さなチームで守られていた「本音」がどこかで機能しなくなっている。まあ、当然大きい組織じゃなければできないこともあるし、大きい組織だからこそそういう小さいチームのときのやり方では回らないことがたくさんある・・・ということぐらいはこの歳になると分かった気にはなる。だから一概に "大企業が駄目だ" とか否定はしないけれども、それでもやっぱり自分は苦手なのだった。

リーダーシップにはいろいろな「型」があるだろうから、必ずしも自分の考え方がベストであるとは思わない。けれども、経験的には前者よりも後者の方がみんな活き活きするようには見えます。

なによりそのほうが、人間関係が良好だったな、ということも最後にひとつ付け加えておきたい。

追記

この状況が成り立つにはメンバーのモチベーションが重要だとか、スタートアップみたいな環境だから・・・という反応があるのだけれどもそこは追記で説明します。

"チームの構造を後者の形になるように整えるということなんじゃないかなとおもう。" と書いたとおり、そういう状況においても、メンバーが自発的に行動するように導くよう場を整えるのがリーダーあるいはオーガナイザの役割であり、リーダーはそれを実現することに責任を持つ・・・ということが言いたかったんです。たとえベンチャーや小さなチーム、始まったばかりのプロジェクトでも、ヨーイ!スタートからいきなりみんなが自発的に動いてゴールに向かっていく、なんてことはあり得ません。リーダーなり、リーダーシップを持ったプロジェクトメンバーがチームをうまくそういう状況に導くのにコミットするからこそそれが実現されるんです。

もちろん、モチベーションがゼロの人たちをその状態まで持っていくのは大変な話だというのは理解します。スタートアップや小さい組織ではその前提が成り立ちやすいから良かったという感想を自分も書きました。前提が成り立たない組織、大きな組織では理想的な状況を実現するのは大変ですが、だからといってリーダーシップとはどういうことかという本筋は変わらず一緒だろうと思います。