こんにちは。
先月、この記事を書いたところ、同僚やチームメンバから後半が大振り過ぎるからもうちょっと書けっていわれちゃいました。
ということで、少し分解して書こうかなって思った話の第1弾です。
今回は、「生産性を高めるための８つの習慣」のうちの「サーヴァント・リーダーシップ」あたりについてです。
「生産性を高めるための８つの習慣」については、牛尾さんのブログをご覧ください。
サーバント・リーダーシップとは
サーバントリーダーシップって聞いたことない方も少なくないかもしれません。
ぼくが所属するところでも、よく PM/PL が足りないとか、どうやって育成するのかとかの話題が自分のところに来ることがあります。
その中で、「サーバントリーダーシップ」というキーワードを初めて聞くという人もいます。
なので、まだなじみのない言葉なのかもしれません。
以下のサイトで説明されていますので、興味のある方はご覧ください。
ぼくの中では従来型のリーダーシップ(この記事では、コマンドタイプのリーダーシップと表記します)とは違うリーダーシップというくらいに認識しています。
コマンドタイプのリーダーはダメか？
コマンドタイプのリーダーはダメかと聞かれた場合、正直に言うとダメではないと思っています。
理由は、2つあります。
1つは、短期やスコープが小さいプロジェクトだったら、コマンドタイプのリーダーで失敗する可能背は低いですし、失敗したところでダメージも少ないから。
もう1つの理由は、リーダーには権限が与えられていて偉いって思ってる人が多分少なくないので、多くの人がイメージするリーダーそのものだからです。
組織が小さいときには、コマンドタイプのリーダーが組織を牽引するのにとても力を発揮する場合があります。
いわゆる、ワンマン社長ってのが、もろこれですね。
サーバントリーダーシップを勧める理由
コマンドタイプのリーダーの方が、人材の確保も簡単だしいいんじゃない？って思う人もいると思います。
それはそれでいいんだけど、コマンドタイプのリーダーには以下の大きな欠点があります。
- パワハラ体質になりがち
- 組織の成長の上限が、コマンドタイプのリーダーの成長の上限と等しくなる。
これは組織の課題であるため、組織を考えない人にはちょっと関係ないように感じるかもしれませんね。
ですが、個人の観点でもコマンドタイプのリーダーは、コマンドタイプでいる限り苦労が絶えないと思いますので、どこかで切り替えることをお勧めします。
勧める理由(組織の観点)
まずは関係ないって思う人が多そうな組織の観点でのサーバントリーダーをお勧めする理由ですね。
パワハラ体質
まぁー、パワハラはあかんですよ。。。
人は人の上に立つと、命令したくなっちゃうんですよ。
これは、昔から繰り返されていることなので、多分永遠に変わらないです。
で、リーダーとは、ロール(役割)なわけであって、人として偉いかどうかってことは何も関係ないですよね。
だから、そもそも命令しちゃいけない(偉くてもしちゃいけない)ですし、ひたすら命令で人を支配していくと、従業員からハラスメントでコンプライアンス委員会とかに訴えられちゃいます。
多分これされると、その組織はプロジェクトやってる場合じゃなくなると思います。
ですから、コマンドタイプのリーダーシップを許容している企業は、パワハラ問題でトラブルリスクや、従業員の過重労働の問題を抱えるリスクを持っています。
ちなみに、発注側だから関係ないって思ったそこのあなた。
そういう場合は、下請法違反に該当することをされるかもしれません。
これらは、「生産性を高めるための８つの習慣」の「階層関係のパワーバランス」にも該当すると思います。
組織の成長の上限
これはとても単純ですよね。
だって、命令してそれに従わないといけない組織だったら、その命令している人の成長の上限が組織の上限となりますよね。
なので、創業社長で1代で企業終わるのは多いんですよね。
従って、持続して成長をする組織を目指す場合、コマンドタイプのリーダーは成長を妨げる障壁にいつか必ずなります。
勧める理由(個人の観点)
コマンドタイプのリーダーは上述の通り、いつか成長が止まるんですよね。
それでも命令しなければ、組織が死んでしまうので超必死になりますよね。
休日も働き、夜も働き。
過重労働に苦しみます。
それでも、メンバが増えたり組織は大きくなるので、加速度的に売上を求められ、利益を出し続けなければいけません。
どう考えても、超大変。
しかも、パワハラで訴えられるかもしれないリスクと常に隣り合わせで。
これ解決するの簡単なんですよ。
サーバントリーダーになっちゃえばいいんです。
全部、自分1人で考えなくていいんです。
メンバに考えてもらいましょ。そして、その意見を聞きましょう(傾聴)。
傾聴してれば、チーム内がギスってるのとか、問題を抱えているのを気づきやすくなるし、フォローするタイミングも早くできるので、問題が小さいうちに沈静化できますよね。
なので、サーバントリーダーの方が圧倒的に楽ですよ。
ただ、コマンドタイプのリーダーには、人に任せるというところがすごく難しいんですよね。
そういうのは、ひとまず任せながら、最悪の場合はリカバリできるように状況把握をして、最悪のケースになっちゃったらみんなに指示して一気に片づければいいんです。
全部1人で計画たててた時よりも、有事の方がスコープは圧倒的に小さいですからね。
まとめ
サーバントリーダーになるために何が必要かって聞かれたら、リーダーとして遂行している業務の全てをメンバに委ねるだけだと思います。
したら、リーダーいらなくね？って話になりますよね
じゃーそもそもリーダーって何するロールなの？ってことなんですよね。
リーダーって、そのチームなり組織をリード(導く)人に与えられるロールですよね。
だから、ゴールに迎えば何でもいいんですよね。
で、プロジェクト初期とかはゴールがあいまいなので、どっちに進んでも正直いいと思うんですよね。
ただ、ゴールに近づいてるか遠ざかっているかで、次のアクションが変わるだけで。
もちろん、メンバもゴールを目指しているわけですから、メンバの意見自体もゴールと全然違うところに行くリスクはどんどん減っていくわけですし。
なので、もっとメンバのことを信じて、1歩引いたところでゴールへの距離感をつかむことを心がけると、結果的にサーバントリーダーになってるって感じなんだろうな～。
コメント