「メンバー全員を救いたい」という思考をする人はリーダーになるべきでない理由
資源が有限の中でチームメンバー全員は救えない
当たり前なんですけどね、最近改めて思ったもので。
どんな組織(会社、研究室、スポーツのチーム)でも
- 時間
- お金
- モノ
- 技術
など使える資源は有限ですよね。
そして多くの組織は、利益や研究成果などの結果を出さなければいけないないということは言うまでもないでしょう。
この『有限のリソースを使い結果を出す』という行為には、必ず『不要な資源を切り捨てる』という考え方がセットになるわけです。
つまり合理的に不要なものを切り捨てられない人がリーダーになると、組織は確実に死へ向かうことになります。
特に資源を『ヒト』に限って言うと「メンバー全員を救いたい」という人は基本的にリーダーになるべきではないということです。
リーダーも人間なので同じチームのメンバーに厳しく接することが辛いことはわかりますし、そうするとチームから嫌われてマネーじできなくなるのではないかと心配する気持ちだってあるはず。
自分にもチームメンバーみんなに好かれ、組織と足並みが揃わないメンバーも全員救える人が良いリーダーだと思っていた時がありました。
でも結局そういう方針のリーダー・組織は、やっぱり最後に結果を出せないんですよねぇ...
ぼくが経験した限りでも
- みんな楽しく仲良くやりたいと言ってできない方の人に合わせてレベルを下げるサークル
- 何度チャンスをあげて諭しても反省しない学生の尻ぬぐいに自分の時間を割いてまで付き合う指導教員
- 仕事をしない管理職を「これまで頑張ってくれたから」とクビにせず他の社員に負担を押し付ける社長
などなど...
これに懲りて以降、ぼくは「女神的リーダー」を志すのをやめ、少なくともしっかり決断ができるリーダーになろう!!と思うようになりました。
リーダーにとって決断すべきことの一つは「組織に必要なメンバーを選ぶこと」であり、その決断ができない人がリーダーになれば、組織は確実に殺されるということです。
「メンバー全員を助けて仲良くなれるオレ、カッコイイ」とか女神様気取りのリーダーは、いつまでも組織のベースレベルを上げられず優秀な仲間に見限られ、気づいた時には大事なところにリソースが回せない状態になって全員共倒れ必至です。
勘違いしないでほしいのは「仲良し組」でいたいというならそれでいいし、リソースが実質無限にある、または成果を求めない組織なら、言うまでもなくこの考え方は不要だということ。
成果を出したいリーダーが選ばなければいけないのは「仲間」であって「友達」ではないということを頭に叩き込まないといけないですね。
チームメンバーのトリアージ
トリアージとは、負傷者を重症度、緊急度などによって分類し、治療や搬送の優先順位を決めることであり、救助、応急処置、搬送、病院での治療の際に行う。 ※トリアージ（Triage）は、治療（Treatment）、搬送（Transport）とともに、災害時医療で最も重要な３つの要素（３Ｔ）の一つである。
トリアージの意義 - 横須賀市医師会
極端な話「この人は重症過ぎて助かる見込みがほぼないけど、代わりに他の軽症者10人を手当した方が助かる見込み高いよね」っていう感じで『優先度を付けて負傷者を助けよう!』という考え方がトリアージです。
ビジネスパーソンなら誰でも「優先度を付けて『タスクをこなす』」ことは実践していると思います。
しかしリーダーは「必要な結果に対して優先度を付けて『メンバーを選別』」しなければなりません、それも「合理的な理由にもとづいて」です。
もし結果が全く出ていないなら、「創業期から頑張ってくれているから」というのはメンバーを残す合理的理由にはなりません。
既に述べたとおり、有限なリソースで成果を出すのに不要なヒト・モノ・カネを削る必要性は必ず出てきます。
本気で成果を出したいなら、あれこれ考えてネガティブな気持ちになる前にさっさとトリアージする決断を下しましょう!!
優先度付けとしての評価はメンバーのためでもある
このCAでの評価制度のように、組織に向いていない人を洗い出すのは、実は本人のためでもあったりします。
なぜならたまたまその組織に向いていなかっただけで、別の環境なら十二分に成果を発揮できる可能性があるからです。
もしリーダーが決断せずにダラダラと成果にコミットできないメンバーをおいておけば、その分メンバーにとっても本来他の環境で出せたはずの成果を逃すことになるわけです。
メンバーを追い出すことをなにもネガティブに捉える必要はなく、むしろ「君にとって、もっと良い環境があるよ♪」とポジティブに考え話しをすれば、お互いハッピーになれること間違いなしだと思いますよ。
エンジニアの自分が、個人受託したWeb制作でもSlackが必要だと思った3つの理由
ぼくは個人でとあるサイトの制作を受託していますが、制作開始時からクライアントさんとのやりとりにSlackを使っています。
エンジニアやデザイナー中心の大きな会社やチームでないとメリットがないと思われるかもしれませんが、少人数や1人でのWeb制作であっても導入してよかったなと思ったので、個人的に感じられた導入のメリットをまとめました。
1. メールを前提にした話をされることがない
エンジニア的な常識では「メールはオワコン」なのですが、それはエンジニア界隈での話であって、世の中ではメールが最新の非同期コミュニケーション手段になっているわけです。
そもそもクライアントさんの中には「チャット」という存在すら知らない方さえいらっしゃいます。
なのでメール使用を前提に仕事を進めていくと
という話が出てくる可能性が十分にあります。
しかしSlackを使えばこうしたコミュニケーションにおけるニアミスを防ぐことができます。
まずは制作開始時にクライアントさんへ「メールよりも格段に優れた非同期コミュニケーションツールがありますよ」と伝えてあげたうえで、できれば設定までしてあげましょう。
その後のオーバーヘッドがなくなり、大変スムーズにコミュニケーションが取れます。
2. ちょっとしたファイルの共有が楽にできる
上記と関連しますが、制作や運用を進めていくとクライアントさんとのちょっとしたファイルの送受信も多くなります。
例えば
などなど。
やりとりやチャネル数がそこまで増えなければ、スクロールやファイル一覧のビューで大抵のファイルはすぐに見つけられるはず。
またスマホからのアップも可能なので、もし「モバイル版で不具合が出た」というような報告を受けてスクショを送ってもらうといったことが容易になります。
3. 通知が集約される
一番デカイのはこれかなと。
Webアプリと違って、静的サイトではCIでテストを走らせるなどという必要はありませんが、サイト上で何かイベントがあった場合はなるべく通知してほしいもの。
このプラグインを使うと
- 新しい投稿があった場合
- 投稿がレビュー待ちになった場合
- 新しいコメントが付いた場合
といったイベントを通知してくれます。
特に一人でやっていると、監視しなければいけないことが多くあるように思います。
例えば制作初期には、クライアント側さんがコンテンツを更新した際、制作側の意図しなかった表示のバグや不具合が入る可能性があります。
ぼくが受託しているサイト制作では、Slack上に通知があったら重要と思われるものについては、その都度サイトを確認するようにしています。
ぼくが受託しているサイト制作では、Slack上に通知があったら重要と思われるものについては、その都度サイトを確認するようにしています。
当然通知は制作側、クライアント側どちらも見られるため、自分の知らないところでイベントがあった場合にも通知が来ますし、何も通知がないときに比べてバグの発見に早く気づくことができるうえ、その後何が問題だったかの議論も容易に行うことができます。
