新米チームリーダーの私に役立った8個の考え方
はじめに
この記事は、組織の中でこれからリーダーになる人、または最近リーダーになった人に向けて、リーダー業をこなすにあたって役に立ちそうな考え方を、個人的な視点からまとめたものです。
私自身、KTC（KINTOテクノロジーズ）では2023年11月に初めてチームリーダーを任されることになりましたが、前職含めてそれまでまったくと言っていいほどリーダーを経験したことがありませんでした。なので経験のなさを補うため、アサインが決まったタイミングから「リーダーシップ・マネジメントの考え方」を書籍・Web記事・上司に求め、いくつかの考え方を学んできました。
学んだことすべてを網羅的にご紹介できればよかったのですが、理解が追い付かない・当たり前・今は必要ない・興味が湧かないといった理由で、いまの自分には響かなかったものもあります。それは「いまの自分にはインストール不可である」と諦めて、次の巡り合わせに任せることにしました。
そんな中で、いまの私がインストールした考え方を8個ご紹介します。 偏ったリストですが、何かしら皆さんの仕事のヒントになればうれしいです。
集団で狩ったマンモスを各自で山分けする
「組織のメリットは仲間との結束感だ」と言う人もいます。もちろんそういう面もあるでしょうが、それは副次的な利益です。 マンモスを狩った集団は、まさに同じ釜のメシを食べることになり、結果的に仲良くなったことでしょう。 肉が先にあり、仲間意識は、おまけでついてきます。
安藤 広大 『リーダーの仮面——「いちプレーヤー」から「マネジャー」に頭を切り替える思考法』
チームリーダーになることが決まって最初に手に取ったのが『リーダーの仮面』でした。私はリーダーについて、最初「メンバーのモチベーションを上げる」とか「メンバーと心を通わせる」みたいな側面を主にイメージしていたのですが、そんな中で触れた「識学」のドライさに戦慄した記憶があります。
ですがモデルとしての識学、特に、集団でマンモスを狩るから個々人に分け前が入るという
先に「集団の利益アップ」があり、そのあとに「個人の利益アップ」がある。これが正しい順番です。
という考え方には納得し、判断の指針の1つになっています。
管理職の役割は「目標達成」と「集団維持」
いろいろな考え方があると思うんですが、「PM理論」という、パフォーマンスとメンテナンスの機能に着目した理論があります。 それになぞらえて考えてみると、まずは「目標達成機能」。パフォーマンスの機能は目標達成機能です。メンテナンスは「集団維持機能」ですね。チームを維持したり、チームを活性化したりする役割・機能があるということです。
引用元の記事では、環境と時代の変化によって目標達成・集団維持どちらも難易度が上がってきていること、最近は集団維持に重きが置かれすぎて戦略策定〜目標達成できる管理者が育たないこと、などが述べられています。
が、その辺の難しいことは置いておいて、シンプルに「管理職の仕事は『目標達成』と『集団維持』である」というフレームを得たことで、管理者である自分が何をしたらいいのかがはっきりしたのが精神衛生上よかったです。
目的を伝えて手段は任せる
スタッフや部下のトライアンドエラーを「ロス」ととらえ、スピードを速くするために、最初から正解を教えたり、手取り足取り教えたりしてしまう。この考え方は、絶対にＮＧです。 経験とともにしか人は成長しません。 （中略） 答えを与える組織は、結果として速度が遅くなります。部下が成長しないので、長い目で見ると速度は落ちるのです。
安藤 広大 『リーダーの仮面——「いちプレーヤー」から「マネジャー」に頭を切り替える思考法』
力量が十分にあると思われる人には「目的だけ」を伝えて、あとは任せるのがいいでしょう。 若干、力量不足かと思われる人については、「目的と、自分ならこうやる」という具体的な行動のヒントを与える。 そして力量が足りていない、まだ未熟だという人については、「目的と行動」を一緒に伝えるということです。
山口 周『外資系コンサルが教えるプロジェクトマネジメント』
マイクロマネジメントはたいていの場合悪手である、というのはなんとなく理解していますが、そもそも自分にマイクロマネジメントし続けるようなキャパシティなどないことはチームリーダー初日から自覚しているので、マイクロじゃないマネジメントを（現在進行形で）模索しています。
実現すべきゴール状態と満たすべき要件だけ握ってあとはメンバーに一任する、一任されても進められるようメンバーをサポートする、という関わり方を目指しています。
好きな仕事なら負担に感じない
好きな仕事なら負担に感じない。それは人それぞれで、単純な量では測れない。 それぞれのメンバーがどんな仕事を好きなのかを掴んでおくと良い。 きちんとタスク・工数管理するのもいいが、手間のわりに劇的な効果はない。
「メンバーの負荷状況が把握できていないので、仕事を依頼するキャパがメンバーにあるかどうか判断できない」という相談をマネージャーにした時にもらったアドバイスです。「負荷状況を把握するために各自のタスクを細かく見たほうがいいですかね？」という質問に対して、「見てもいいけど手間に見合う効果はない。厳密なタスクマネジメントではなく、人の好き嫌いを把握して、それに応じた仕事の割り振りができているかを確認するのがが良いよ」とアドバイスをもらいました。負荷状況は残業時間で把握しつつ、適材適所になるように各自の好き嫌いを把握しておけ、ということです。
細かくタスク・工数管理すると、可視化や合理化のための辻褄合わせなど本質的でないところに時間を取られる気がしましたし、そもそも細かくマネジメントできるような力量も自分にはなさそうでした。なのでそれはやめて、基本的にはメンバーの担当領域に応じて仕事をお願いしつつ、「人の好みに応じて仕事の割り振りができているか？」という観点を意識するようになりました。
時速60kmで交差点に突っ込めるようにする
例外をつくってしまうと、チームや組織は、非常に脆くなります。 「急いでいるから赤信号でも走っていいと思ったんです」 そんな車を1台でも許してしまうと、道路は一気に混乱します。
安藤 広大 『リーダーの仮面——「いちプレーヤー」から「マネジャー」に頭を切り替える思考法』
あなたの周りの業務で「決められたことを 100% 守ってくれる」と信用できるメンバーがどれだけいますか？納期、月初データ処理、エスカレーション、ファイル共有などなど、仕事には様々なルールがあるはずです。逆に信用できないとどうなりますか？ 暗黙的に誰かがこっそり監視をしていたり、リマインドしてくれたり、裏でデータやモノを手直ししてくれていたりしませんか？結局、誰かがべったりとタスクに張り付くことになるのです。 これが、疎結合化を阻害する大きな要因となります。
業務の仕組み化は日々進めていますが、効率化のためには「担当者が誰にも確認せず単独遂行可能」という領域を増やしていきたいです。不確実な部分が1つでもあれば確認が必要になりますし、事故も起きます。確実なら確認は不要です。ルールがあること、そして確実にそのルールが守られていると誰もが信用できることが重要です。
もちろん、ルールに縛られて本来目指す価値から離れてしまっては本末転倒ですが、基本的には可能な限り、ベースとなるルールをたたき台でもいいので設定するようにしています。
定数と変数と「限りなく定数に近い変数」
林先生と森岡さん共に共通していたことが、この定数と変数を見極めて、変数を動かすこと。つまり、自分の力でどうにかできることに対して人生の時間とエネルギーを使うことが大切である点です。
この考え方は社内の打ち合わせで部長から共有されて学びました。
確かに周りのマネージャーたちを見ていると、流れに逆らってなんとかするというよりは、「力学を見極めたうえで自然とそうなるように状況を整えている」ように感じます。
部長からの共有の中で特に印象的だったのは、
本来は変数だけど今は定数に近いこともある。(ここのミキワメが重要)
という点です。
会社の中での文化や、制度や、人の考え方がそれにあたります。それはちょっとやそっとじゃ変わらない定数のような存在ですが、本当は変えられる変数なんだ、ということを忘れないでおくことが重要だと思いました。
人は1回言われたぐらいじゃ忘れる
部下は、「仕事ができない上司」よりも、「何を考えているのかわかりにくい上司」のほうが動きづらいです。 たとえ大事なことでも、1回伝えただけでは、日々の情報のなかに埋もれてしまいます。
重要なのは、思考プロセスの中でプロジェクトの目的に立ち返って考えるという行為を繰り返させることで、一種の判断基準になるよう仕向けていく、ということです。 部下から質問が来た時、常のプロジェクトの目的に立ち返らせる質問を返す。こうすることで、プロジェクトチームのメンバーはやがて、判断に迷う際にいつもプロジェクトの目的に立ち返るようになります。
山口 周『外資系コンサルが教えるプロジェクトマネジメント』
私自身忘れっぽい性格で、「前言ったじゃん」と言われてぐぬぬとなることも多々あります。反対に自分が言ったことを相手が忘れている時、コミュニケーションは個人ではなく2者間の問題なので、忘れないように伝えきれていなかった自分にも責任はあると考えています。
共有したい想いや考えは、ことあるごとに口にするぐらいがちょうど良いようです。
上機嫌なリーダーと不機嫌なリーダー
エドモンドソンは、心理的安全性を「率直に発言したり懸念や疑問やアイデアを話したりすることによる対人リスクを、人々が安心して取れる環境のこと」と定義している。
チームの中で流通する情報の量が減ると、必ずといっていいほど、プロジェクトは危険な状況に陥ります。 （中略） 情報を伝えた相手がどのように反応するか、情報の送り手側が判断できない場合、情報の流通量は低下することになります。 （中略） 結局のところ、上機嫌なリーダーが率いるチームではメンバー相互間、あるいはメンバーとリーダーとの間での情報量が増加するのです。
山口 周『外資系コンサルが教えるプロジェクトマネジメント』
たくさんの後輩やスタッフと仕事をしてきた経験から、「みんなのモチベーションを上げる方法」にかぎって言えば、次のひと言に要約できる。リーダーがだれより本気で楽しそうに働くこと。これに勝る育成法はない。
佐久間 宣行『佐久間宣行のずるい仕事術——僕はこうして会社で消耗せずにやりたいことをやってきた』
シンプルに、上司が不機嫌だと、気まずいし気を遣うのでメンバーは仕事に集中できません（少なくとも私は）。なので基本は上機嫌に、なにを言ってもOKの空気を作ることを心掛けています。
とはいえ、常に本心から上機嫌かと言われるとそうではありませんし、不機嫌にもかかわらず上機嫌を演じていれば心は消耗します。あなたの周りでキツそうなリーダー・マネージャーを見かけたらそっとねぎらってあげてください。
おわりに
いかがでしたでしょうか？少しでも皆さんのお仕事に役立つ要素があればうれしいです。
ちなみにKTCにおけるリーダーは、メンバーより偉いとかスキルが高いとかではなく、ただの機能・役割です。組織・事業状況に応じた最適なフォーメーションのためつけ外しも発生します。裏を返せば、リーダーがただの機能ならメンバーもただの機能だと思います。
結局はチームで仕事をしていくので、メンバーが動けばいいわけでもなく、リーダーが抱え込めばいいわけでもなく、チームとして解決できればOKなのだと思います。
気負わずやっていきましょう！
関連記事 | Related Posts
We are hiring!
【データサイエンティスト（リーダークラス）】分析G／東京・名古屋
分析グループについてKINTOにおいて開発系部門発足時から設置されているチームであり、それほど経営としても注力しているポジションです。決まっていること、分かっていることの方が少ないぐらいですので、常に「なぜ」を考えながら、未知を楽しめるメンバーが集まっております。
【部長・部長候補】／プラットフォーム開発部／東京
プラットフォーム開発部 について共通サービス開発GWebサービスやモバイルアプリの開発において、必要となる共通機能＝会員プラットフォームや決済プラットフォームの開発を手がけるグループです。KINTOの名前が付くサービスやTFS関連のサービスをひとつのアカウントで利用できるよう、様々な共通機能を構築することを目的としています。