見出し画像

マネージャーになりたての自分に伝えたい10の観点

現職にデータチームのマネージャーとして入社してから3年が経ちます。改めて振り返ると、この3年間は試行錯誤の連続でした。上手くいった記憶も苦い経験もあり、日々新しい課題に向き合って慌ただしかったりしますが、総じてこの仕事を楽しめていて、マネジメントに対する解像度も少しずつ上がってきている気がします。

本記事は、私個人の経験をもとに、マネージャーになりたての自分を想像しながら、当時知っておきたかった知識や心構えを(10個の観点として)まとめたものです。内容は誰でも読めるように配慮はしていますが、主な想定読者はタイトルにある通り「マネージャーになりたての人」になります。また、私自身はエンジニア組織に所属しているものの、内容はエンジニアマネージャーというよりマネージャー全般における話になります。

私は誰?
● 株式会社エウレカという会社でData Directorを務めています
● 事業会社のデータ領域で10年近く活動しています
● プレイヤーとしてはデータ分析、AI開発、FP&A、マーケティング、ゲームデザイン、PdMなどいろんな経験をさせていただいてきました(詳しくは以下noteにまとめています)
● 現在の組織規模は公表できませんが、入社時点から3倍近くまで成長しており、BI・AI・データマネジメントに関わるデータ組織としてはそこそこの規模だと思います
● マネジメントとプレイイングの割合は(時期によりますが)9:1くらい


1. マネジメントスキルは想像よりも広くて深い

そもそも「マネジメント」とは何でしょうか。プロジェクトマネジメント、ピープルマネジメント、など「マネジメント」とつく単語は山のようにありますが、使われる文脈や粒度はまちまちです。マネジメントキャリアを振り返って圧倒されるのは、この役割に求められるスキルの多さです。

マネージャーの仕事がなんとなく「チームを管理する」「人事評価をする」ものだと考えていたらすぐにつまづきます。スキルの広さだけならまだいいですが、やっかいなのは「人事評価をする」という個別タスクですら、大量の知識と経験値が必要になることです。これから踏み出す領域は、広さも深さも想像以上だと理解してください。

そこでまず、どのようなスキルが必要になってくるのか地図を書きましょう。プレイヤーだったころに想像していたマネージャーの仕事はたかが知れていて、その外側には大量の足りていない観点が見つかるはずです。マネジメント研修を受けることもあるかもしれませんが、短期間の研修で紹介される観点は氷山の一角でしょう。確実なのは、まず社内外の先輩や昔の上司に話をたくさん聞くこと。きっと生々しい失敗談やアドバイスをしてくれるはずです。次に本をたくさん読むこと体系化された知識と巨人の肩には全力で乗っかりましょう

マネージャー ≠ 取りまとめ役
マネージャーになるタイミングは人それぞれですが、周辺の話を聞いていると、プロジェクトのリードをしていたり、部門横断で取りまとめをしている人がReady状態と見なされて昇格するというケースが多いように感じます。

リーダーっぽい動きをしている人がマネージャーになる、というのは自然にも聞こえますが、一方でプロジェクトのリードやファシリといったスキルはマネジメントのごく一部分でしかありません。実際にマネージャーになると、仕事のスコープは単体のプロジェクトから「チーム」や「事業全体」に広がりますし、課題の抽象度や難易度も高くなります。

個人的にも他の方々がどうやってこの段差を超えてきたのかもっと事例を聞いてみたいですが、昇格前後のギャップを知ると、メンバーをマネージャーに引き上げるべきタイミングを見極めるのは本当に難しいなと感じます。結局は自分で試行錯誤をして、時には痛い目にあいながら要所を見極められるようになったり、本質的な仕事にフォーカスできたり、胆力がついたりするのを待つしかないのかもしれません。一方で、「心構え」みたいなものはもっと事前に知っておきたかったなという気持ちもあります。そこで、本記事はそんな「心構え」について、まとめられる限り整理していこうと思います。


2. マネジメントには型がある

身に付けなければならないスキルに途方もなくなってきますが、マネジメントは100%アートではなく、テンプレとなる「型」があります。課題に向き合ううちに経験値が溜まって、自分なりの型を確立する人もいるかもしれませんが、似たような経験と失敗は先人たちも山ほど繰り返していて、構造化した知識体系が残されています。

個人的に何度も助けられたのは、以下に紹介する長村さんのブログです(昨年書籍化もされました)。ここで紹介されている「ベンチャーマネジメントの「地図」」は、マネージャーが課題をメンバーに落として、それを成果につなげるまでのフローを分解し、注意すべきメンバーのモチベーション低下要因を要素分解したフレームです。

マネージャーの仕事は、大雑把に言うと「事業・組織課題の分析」「役割と目標の定義」「方針・KPIの策定」「仕組みの構築」、の結果生み出される成果を「評価」というフィードバックによって回していくものです。メンバーが思うように力を発揮できていなかったり、組織が成果を生み出せていない状態というのは、プロセスのどこかに課題を抱えており、それさえ見極めれば対処も明確なのです。

マネジメントは経験でもセンスでもない。「型」を学んで実行するのみ。』(長村, 2021)の「ベンチャーマネジメントの「地図」」の基本動作部を再構成。

モチベーション管理というと、ともすればソフトスキルの文脈で語られがちですが、むしろサイエンスできる領域です(もちろんソフトスキルが大事な局面が多いことも追記しておきます)。「なんとなく上手く行っていないな」というモヤモヤした状況からでも、フレームに従って現状を観察すれば、対応すべき課題はちゃんと決まります。

この改善サイクルを回すときに大切にしている考え方が「納得感」です。マネージャーが計画を作っても、全体会や1on1で紹介しただけで「メンバーに方針を伝えた」と思っていませんか?残念ながら、どんなに計画や背景を伝えたところで「実は全然伝えたいことが伝わっていなかった」ということは多々あります。メンバーによって持っている情報量はバラバラだし、受け取り方も様々です。頭で理解はしているけれども、実のところ腹落ちできていない、みたいなこともあるんじゃないでしょうか。

納得感の作り方は様々なアプローチがありますが、個人的には

  • 相手との信頼関係(過去に蓄積した信用貯金)

  • 共通認識・共通言語(KPIやビジョンなど、粒度は様々)

  • 相手と自分の情報ギャップの理解(相手目線に立った適切な説明)

  • 相手が知るべき情報の判断(情報設計)

が総合的に満たされることで成り立つものだと考えます。「チームが思うようにワークしていない」というのは計画の内容よりも伝え方に問題があることがほとんどです。マネージャーはアラインメントの技術が最も求められるのではないでしょうか。上述のブログ・書籍はマネジメントを振り返る際の診断ツールとして定期的に読み返して使っています。


3. マネジメントスタイルは状況が決める

世の中にはマネジメントスタイルについてたくさんの分類方法があります。説得型、協調型、放任型、など様々ですが、自分がどういうスタイルのマネージャーなのか考える意味はあまりありません。むしろ考えるべきは「自分の」マネジメントスタイルがどうか、ではなく「チームやメンバーの」状態に合わせてマネジメントスタイルを変える、ことの方が本質的です。チーム状態とメンバー状態について、高い解像度を持ちましょう。

❐ チーム状態

多くのマネージャーのバイブルとも言える『エラスティックリーダーシップ』では、チームを自己組織化していくための方法が述べられています。

目の前のタスクをこなすのにいっぱいいっぱいになっている「サバイバルモード」から抜け出して、続く「学習モード」ではチーム能力を拡大するためのコーチングを行い、最終的にはマネージャーが関与しなくても自走・進化できる「自己組織化モード」に導いていくのが好ましい、という論調です。

『エラスティックリーダーシップ』を参考に整理

ここで気をつけるべきは、チーム状態というのは前にも後ろにもコロコロ変わるということです。「自己組織化モード」にいたはずのチームが、事業状況が変わったり、メンバー構成が変わったり、難易度・抽象度が高い対応に追われた時に「サバイバルモード」に変化してしまうこともあるでしょう。

❐ メンバー状態

メンバー状態も同じです。よく参照される成長のフレームワークでは、
1.  慣れ親しんだタスクをこなしているだけの「コンフォートゾーン」
2.  ある程度新しい状況に遭遇しながら無理のない学習が続く「ラーニングゾーン」
3.  自分が抱え込める以上の課題に遭遇してストレスだけが溜まっていく「パニックゾーン」
の3種類があるとされています。1on1などメンバーとの会話機会を活用して、ラーニングゾーンにい続けられるようにするサポートが必要です。

個人の状態も、プロジェクトのフェーズやアサイン変更によって変化します。マネージャーによるティーチングとコーチングの割合も変わるでしょう。

つまり、チームにしてもメンバーにしても、必要なのは「現在のチーム・メンバーはどういう状態なのか(それに従ってマネジメントスタイルが決まる)」という精度の高い観察であって、決して「自分がどのようなマネジメントスタイルか」という自己認識ではありません。ここは取り違えないこと。

「成長」は必要なのか?
成長フレームワークというと、なんだか新しいことにチャレンジし続けないといけない成長圧を感じるかもしれません。マネジメント文脈で頻出する「成長」は、捉え方を間違えるとメンバーを成長ストーリーの型にはめてしまうだけだけのものにもなりがちです。

私は「多くの人にとって成長は必要」という立場を取ります。これはなにも、常に鍛錬しながら上のキャリアを目指すべし、休日も自己研鑽に捧げるべし、といったマッチョな話ではありません。

一般論として、自分が今持っているスキルだけで食べ続けていくというのは(特に変化の大きな業界では)難しいことです。技術やそれを取り巻く生態系は常に変わっているので、慣れ親しんだ仕事が通用しなくなるリスクを抱えています。

「コンフォートゾーンから抜け出そう」というのを新陳代謝のように捉えてみたらどうでしょうか。スキルは常に陳腐化し続けるわけだし、求められるスキルも常に変動し続けるのだし、その変化に合わせたストレッチの場が用意されてようやく現状維持になる、という考え方です。もちろん、人によってキャリア形成や価値観は異なるので、メンバーに合わせて度合いを意識することを忘れずに。


4. プレイヤーでもあり続ける

「マネジメントをしながらどうやって最新技術にキャッチアップしていくのか」というのはマネージャーが集まった時に必ず議論になる定番ネタです。恐らく背景には、

  • マネージャーの仕事はマネジメントなのだから、(プレイヤーの時のように技術を追い続けるのは諦めて)新しい責務に集中すべきである

  • プレイイングをしていないとどんどん最新技術から取り残されていくのが不安(事実、技術によってはメンバーの方が詳しくなったりする)

  • 調整役のようなタスクが多く、自分がエンジニアであることに自信が持てなくなる

  • 逆に技術力さえ高く維持し続けられればチームを束ねられるのではないかという希望的観測

といった感情や思惑があるのかもしれません。この問題について私も様々な悩み方をしましたが、結局は、マネジメント力も技術力もどちらも必要だよね、という元も子もない結論に落ち着いています。

前提として、あなたの職務はマネージャーなので、必要とされる(多岐にわたる)マネジメントスキルを磨き続けて、チームを自己組織化し、メンバーの成長を後押ししないといけません。

一方で、技術を知らないマネージャーができるマネジメント活動は制限されてしまうのも事実です。技術力がないと、いざチームやメンバーに対して積極的な関与が必要になったりティーチングが必要になった場合に、中途半端で曖昧な指示しか出せません(そのしわ寄せはメンバーが引き受けることになります)。マネージャーになったということは、ある程度プレイヤーとしての実績が評価されているからだと思いますが、過去のスキル貯金だけでは将来的な可動域は次第に制限されていくでしょう。

結局、言い訳はできないということです。勉強して、手を動かし続けましょう。もちろん、これがどれだけ難しいのかも理解しているつもりです。時間リソースは有限なので、その中で少しでも上手く動くための工夫はいくつかあります。

  • 寿命の長いスキルに投資する:時間が限られているのであれば、せめて優先度を付けましょう。構造化された知識体系は陳腐化のスピードも遅いので、表面的な技術よりはそこに横たわる基礎の方に優先してリソースを割くように心がけます。

  • 業務にプレイイングを取り入れる:意識的にプレイヤーの時間を作ってしまうのもありかもしれません。実際には難しいことも多いですが、小さいタスクや副業で手を動かすなど、考えようによってはいろんなパターンが考えられます。

  • インプットの時間を戦略的に作る:時間を強制的に作ってしまうパターンです。毎日一時間は自己学習の予定をブロックしたり、1年の特定の時期にインプットを集中させて、限られた時間をなるべく密度濃く過ごします。私個人は、毎週土曜日をインプットの日にしています。コードを書いたり、馴染みのない分野に手を出してみたり、散歩しながら考え事をしたり、粒度は様々です。ただ、家族と過ごす時間が大事なので、自分で決めた範囲を超えてインプットに使うことはありません。

この話題が延々と繰り返されるのは、それだけ両立が難しいことの反映かもしれません。マネジメントもプレイイングもどちらもできるスーパーマンになれれば苦労はないのです。仕事よりも優先度の高いものはたくさんあるでしょうし、時間制約の中で(無理せず)二兎を追い続けるしかない、というのが現時点での私の立場です。

本記事は「職場」の世界の話しかしませんが、もっと広い人生の中での時間配分に悩んでいる方には、『限りある時間の使い方』という本をオススメします。


5. ソフトの力学を過小評価しない

私が好きなフレームワークに「マッキンゼーの7S」と呼ばれる組織改革に使われるものがあります。Waterman, Peters, Phillipsらによる論文"Structure is not Organization"で言及され『エクセレント・カンパニー』で一躍有名になりました。

Waterman et al., "Structure is not Organization" を参考に再構築

組織を改善したい時に、一番分かりやすいアクションは組織の構造(Structure)や戦略(Strategy)などのハードな要素を変えることです。配置換えをしてみたり、事業構造に合わせてトポロジーを変えたり、新しい戦略を策定したりと、手を付けやすく進捗感を得やすい領域です。ただ残念ながら、組織構造や戦略を変えただけでは物事は動きません。実行段階では、メンバーのスキルや動き方が新しい組織にフィットしているか、共通の価値観を持てているか、など様々なソフト要因が絡み合いながら成否が決まります

マネージャーとしては、組織における「ソフトのモーメント」を過小評価してはいけないと考えています。どれだけ戦略が正しかったりハードを整えているつもりでも、人の気持ちを追いつかせるにはしつこく説明を繰り返す必要があり時間がかかります。

組織を構成しているのは人間です。自分を振り返れば分かるように、人というのは気持ちがブレるし、言われたことを100%理解しきれないし、様々な認知バイアスを抱えながら好き勝手に情報を解釈してしまいます。ロジカルに成果を出すためにこそ、価値観や感情といった力学を理解しないといけません。ソフトなモーメントは味方になれば大きな推進力になる一方で、コミュニケーションを間違えれば取り返しのつかない負債になります。


6. 不完全な情報との向き合い方

過去に多くの意思決定の場面に立ち会う中で、一言に「意思決定」と言っても様々な種類があるなと感じています。

例えば、ある施策をやるかやらないかを決める場合には、期待効果(リターン)とリスクを天秤にかけて、リターンがリスクを上回ればやればいいです。また、2つの施策のどちらを優先するか決めたい時には、それぞれのメリット・デメリットを整理して、期待値が高い方(もしくはリスクが低い方)を選べばいいでしょう。

これらは意思決定問題としては簡単な部類で、誰でも迷うことなく決断できます。実際には、より抽象度や難易度の高い意思決定を扱う場面の方が多いのが現実です。意思決定問題をちょっと難しくしてみましょう。

❐ 不確実性が高い場合

そもそも、判断に必要な全ての情報がきれいに揃っていて、メリデメ表のような分かりやすい形式にまとめられることは多くありません。情報が足りなかったり、あるいは情報は揃っていても判断を邪魔する要素があるのが普通です(以下によくある不確実性の種類をまとめてみました)。

もちろん、情報が足りないのであれば少しでも手がかりを集めてマシな方向を探りますし、不正確な情報に対してバイアスを取り除く努力をします。ただ、経営レベルの意思決定では、「時間」というリソースが貴重すぎるために、欲しい情報が十分揃っていない段階での素早い判断が必要とされます。スタンスを決め込んで決断をし、間違っていたら別の選択肢を打ち続けるだけです。

問題が情報の側ではなく、判断者の側にあることもあるでしょう。私がとても好きな本に、『NOKIA 復活の軌跡』という、iPhoneに市場を奪われたノキアの生々しい復活劇をテーマにした回顧録があり、こんな記載があります。

二〇〇八年に、ノキアの危機を予見する人はほとんどいなかった。しかし、私がよく思うのは、ビジネスでは、誰もがフロントガラスが巨大なバックミラーになっている車を運転しているということだ。そのミラーには小さな穴があって、そこから前方を見ることができるが、私たちは総じて過去の測定基準を重視し、この先にあるものについて直接的な情報を探し出す能力も意思もほとんど持ち合わせていない。過去のデータから推定される間接的な情報に満足してしまうのだ。この巨大な財務的なバックミラーで見るものがすべて素晴らしい場合、実際には根本的な競争力がここ数年ですでに大きく失われていることを、どうしても理解できなくなってしまう。 正気であれば、そんな車を運転したいとは絶対に思わないだろう。しかし、私たちはまさにそういうやり方で巨大ビジネスを運営している。

『NOKIA 復活の軌跡』より抜粋

私自身は別に毎日のようにシビアな決定にさらされている訳ではないですが、難しい状況でスタンスを決めないとけない場合に、以下のようなことを考えている気がします。

  • 事業としての正しさ:「経済性を高めて、その結果として社会に大きなインパクトを出す」という大局的な方向性に進んでいるかを中心軸にする。

  • 組織としての準備:7Sのフレームワークで紹介された要素がそれぞれ準備できているか、あるいは走りながら用意できそうか、どこに一番無理が生じるか。

  • 納得感:自分自身が判断に腹落ちできるか、それをメンバーとも共有する自信があるか。

  • リカバリーの可能性:判断は巻き戻すのにどれくらいのコストがあるか。そもそも「Two Way Door」なのかどうか。

❐ トレードオフがある場合

意思決定の際に注意したいのが「トレードオフの罠」です。何かを選択することで、別の何かを捨てるタイプの判断はたくさんあるでしょう。

  • 目先の売上にはつながるが、長期的に顧客の離脱が進むかもしれない

  • マネタイズ施策にチームのリソースを振り切るとリテンション施策が動かなくなる

  • A部門の数字を達成するために、B部門の目標を諦めないといけない

これらの「どちらかを取るともう片方を捨ててしまうので決めづらい」タイプの課題には、以下の2つの問題が立ちはだかっています。

  • 見せかけの対立項に踊らされている:リテンションとマネタイズのどちらを取るのか、といった場面でよく遭遇します。これらは構造的に整理すると、(事業ドメインやエコシステムによりますが)どちらかがもう片方に内包されていたり、方向性として近かったりすることがあります。それを「AかBの両極端から選ぶしかない」と相反する対立軸として捉えて自縄自縛状態から動けなくなってしまったら本末転倒です。一見相反する「A or B問題」は、対立項として捉えないほうが良い判断ができたり、ちゃんと考えればそもそもの優先度が自明である場合がほとんどです。問題を自分で複雑にしないこと。

  • 捨てられない執着が邪魔をしている:選択肢に愛着があったり、捨てることが怖くて中途半端な立場を取ってしまう場合です。これは単に覚悟の問題なので、普段から「自分は何を軸に判断をしているのか」を観察して、思考のクセを確認しておくこと。


7. 思考の「強度」があなたを救う

インテル創業者のアンディ・グローブは『ハイアウトプットマネジメント』で、「厳密な機能別編成組織」と「ミッション中心型の組織」のどちらに寄るかで悩んだ末に、両者のハイブリッドを採用するに至った経緯を以下のように書いています。

インテル社がハイブリッド組織になったのは、あいまいさが気に入っているからではない。他のこともすべて試みてはみたが、他のモデルでは、あいまいさこそ少ないものの、とにかくうまく機能しないのである。ハイブリッド組織とそれに付随する二重所属制度の原則は、民主主義と同じで、それ自体が偉大なわけではない。たまたま、組織化が必要などの事業においても、それらが最善の方法であるにすぎない。

『ハイアウトプットマネジメント』より抜粋

ここで印象に残っているのは、彼がそれぞれの選択肢の意味を十分深く理解した上でこの決断を行ったことです。恐らく、そこまで深く考えなかったとしても、(どちらかに振り切れずに折衷案を採用して)同じ決断に至ったもしれません。ただ、表面上は同じ決定でも、深く検討と言語化を重ねた方がより上手く組織運営できるのは間違いないでしょう。

私がこれまで優秀だと感じたマネージャーの共通点に「思考の強度が強い」という特徴があります。「思考の強度」というのは以下のような意味合いです。

  • 「なぜそのように考えるのか」について強い根拠と判断軸がある

  • 自明に思えることも、腹落ちしきるまで自身で言語化している

  • 背景にある哲学が一貫していて、全体として整合性がある

平たく言うと「物事を深く考えている」「芯が通っている」みたいな意味合いです。こういう人は、様々な角度から「So What?」や「Why So?」を投げかけても必ず応えが返ってくるし、どんな課題に対峙しても場当たり的ではない一貫したアプローチを取っています。

後戻りができない判断も多いからこそ、マネージャー本人の「腹落ち」を磨いて、どんな質問が飛んできても説明責任を果たせるように日頃から自身の判断を言語化すること。中途半端なレベルで深堀りを止めると後で割を食うのは自分です。


8. 動かしにくいものを動かす

前節で登場したアンディ・グローブは、マネージャーのアウトプットを、自分の組織のアウトプット+自分の影響力が及ぶ隣接諸組織のアウトプット、と表現しました。ここまでチーム外についてあまり意識せずに書いてきましたが、自分のチームが成果を出すためには、外部の協力を仰いだり、サポートを受けられる体制を作っていく必要があります。

同じ船に乗った者同士、快く協力を得られることの方が多いとは思いますが、部外に負担がかかる場面や新規プロジェクトを動かす場合には、多くの「抵抗」に出くわすこともあるかもしれません。ここで話す「抵抗」とは、何も強烈な反対勢力のことではなく、現状維持バイアスからくる腰の重さだったり、不確実性への不安からくる懸念表明だったり、無関心だったり、抵抗とまでは言えないような感情も含みます

このような状態で、物事を進めていくためによく参照しているのが『抵抗勢力との向き合い方』という書籍です。タイトルが仰々しく見えますが、本書は「モヤモヤ・違和感」の段階から「潰しにかかる」強い段階まで、抵抗を広く定義し、その発生メカニズムからコミュニケーション設計、解決の糸口について整理しています。マネージャーに関わらず、ステークホルダーとの関係作りに興味ある方はぜひ一読して欲しい一冊です。ここで書かれているようなことが頭の中で整理されていれば、きっと隠れた抵抗を上手く解決して、そのままでは動かしにくかった事柄が前進していくでしょう。

関係者がまとまらない原因には様々なものがあって対処可能ですが、個人的に一番警戒するシグナルは「他責」です

人というのは、複雑・不確実・不明瞭な状態を避けたがり、コントローラブルな領域に留まっているのが心地良い生き物です。その上で、自分の外で発生する障害を、外部要因として切り離したがる傾向がある気がします。「A部門が上流でもっと課題を言語化してくれたら仕事がしやすいのに」「(特定個人の)Bさんがもっと早くタスクを進めてくれればいいのに」「経営陣がこの問題に向き合ってくれたらいいのに」と、様々な形で不満を聞くことがあるかもしれませんし、あなた自身もそう思っているかもしれません。その感情がどこから発現しているかを理解して、解決に向かわせるのは他でもないマネージャーのあなたです。

当然、「他責(の感情)」と「真っ当な(事実の)指摘・批判」は区別するべきで、他人や組織について何も言うべきではない、という意味ではありません。ここで注意したいのは、一見真っ当な指摘の中にも他責の感情が紛れ込むことがあることで、そうした感情の発生には敏感になった方がいい、ということです。

レアケースかもしれませんが、メンバーによる会社批判に遭遇した時には、安易な同調はやめましょう(もちろん、実際そのような経営課題はあるのだろうし、あなたが解決に向かわせるという前提で)。

メンバーが会社の批判をしている時、マネージャーはメンバーに同調したほうが、その瞬間はメンバーと意気投合できます。そちらのほうがメンバーの信頼が勝ち取れそうに思うこともあるでしょう。でもその瞬間、非常に大きなものを失っていることになります。「メンバーが、マネージャーをマネージャーとして認識しなくなる」ということです。 会社の批判をメンバーと同調してするということは、そのマネージャーは経営陣の一員でも何でもないわけです。皮肉ですが、良かれと思ってメンバーに同調したマネージャーの言うことは、その後一切聞かれなくなります。経営陣の一員どころか〝反逆者〟ともいえる人の話は信用できないし、その人の言うとおりに動いたところで会社からは評価されないだろうと感じるからです。 メンバーと同調するのではなく、また焦って無理に火消しをするわけでもなく、経営陣の一員としてその意見に向き合い、経営陣の一員として自分の意見を述べ、対処すべきは対処しましょう。「自分は経営陣の一員である」という立ち位置を見失ってはいけません。

『急成長を導くマネージャーの型』(長村, 2021)12章より引用

※ 本節のレビューに際して、Akihiroさんより、NVC(Nonviolent Communication)について紹介をいただきました。批判的な気持ちについての向き合い方が丁寧に整理されているので、興味ある方はぜひ。


9. 自分のモチベーションを維持する

ここまでいろんなTipsを紹介しつつ、やはり一人のマネージャーが学ばないといけない領域や身につけるべきスキル、時間的・精神的な負荷は大きいなと感じます。毎日何かしら起こって大変だと思うかもしれませんが、あなたのしんどさはメンバーに取ってはどうでもいい、というのも事実です。ここでは「もしモチベが維持できない時はどうすればいいのか」という気持ちに寄り添って、3点ほどモチベーションの維持方法について考えてみます。

❐ (前提)自分の役割を理解する

まず、マネージャーというのはただの役割だということを理解しましょう。昇格したからといって突然偉くなったわけでもなく、会社に雇用されたサラリーマンとして事業に価値を出せるかが評価されています。ここでの価値とは、事業の経済性を高めて、それによって社会に影響を与えることです。それを実現する手段の一つとして、チームマネジメントやリーダーシップを担当しているにすぎません。

扱う課題は難易度の高いものかもしれませんが、それでもできることを愚直にこなしていく他になく、変に肩肘を張る必要はありません。過剰な期待値や自意識が膨れているのであればさっさと捨てましょう。求められているのはあくまでもアウトカムなので、山の登り方は格好悪くてもよく、一人で解決できないことは人に助けを求めましょう。

❐ マネジメントをしている意味を見出す

チームや事業にどう報いるかという話ばかりしていましたが、マネージャーであることで享受できる自身の利益は真面目に考えたほうがいいです。日頃の大変さを上回る意味やリターンを言語化できているかどうかはモチベーションに大きく影響します。

例えば、私がマネジメントを楽しめている理由(の一部)は以下のようなものです。

  • 一人では出せない量のアウトカムを生み出せる:自分が2倍のパフォーマンスを出すよりも、メンバーが1.1倍の力を発揮した方が得られる成果は大きい(マネジリアル・レバレッジ)。

  • 技術課題の最前線にいれる:マネージャーに上がってくる技術課題は、基本的に(教科書的には解けない)難易度が高いものが多くなります。どうせ同じ時間働くのであれば、なるべく難しい課題をたくさん打ち返している方が成長スピードは早まります。そういう意味での時間コスパの良さはあるかもしれません。

  • 背負う側にいれる:マネジメントを志すきっかけになった理由の一つに、事業や組織の課題を(自分が)解決したい、というものがあります。組織について感じているモヤモヤを、直接自分が裁量を持って解決するために動ける、というのは心理的にかなりヘルシーです。外からあれこれ言うのではなく当事者として背負ってしまった方が馴染む(そして結果得をする)、という考えはモチベーションを大きく支えてくれてます。

  • キャリア上のプラスが大きい:これだけスキル需要が変わりやすい市場でも、マネジメントのスキルは枯れません。仮にプレイヤーに戻るとしても、マネージャーを経験してからの方が成果を出しやすいと思うし、ここでの経験は今後もキャリアの糧になっていく確信があります。

❐ 自分の機嫌をとる

事業やチームにコミットしている分、自分がないがしろにならないようにしてください。家族との時間や、趣味や勉強の時間など、確保したいものはたくさんあると思います。どうすれば自分のご機嫌が取れるのかを理解しましょう。そして目一杯楽しみましょう。

個人的には、プライベートや趣味を除けば、よく飲みに行ったり雑談したりする社外のつながりがありがたいなと感じます。同じような課題に直面していたりする分、共感し合えることは多いし、別に解決策を出してくれる訳ではなくとも、そういう友人たちの存在はすごく心強いのです。


10. 質問リストを持つ

『戦略質問』というお気に入りの本があります。この本は、コンサルタントである著者が、本質的な物事に集中させるために意識的に問いかける「質問」とその効用をまとめています。

何度も繰り返しているように、人間の意思というのは不完全で、特に長期的・抽象的な課題ほど上手く考えるために意思の力や訓練が必要です。そんな時にクイックに使えるツールが「質問(自問)」です。「なぜプロジェクトが上手く進まないのか」「なぜ仕事をしているのか」などなど、自分の思考を意識的に課題に振り向かせる質問の力はとても大きいのです。

私も、毎日・毎週・毎月のそれぞれの粒度で問いかける質問リストのようなものを持っているのですが、プライベートなものも含むので、あくまでも例として質問のテンプレを考えてみました。

ここに「自分は今楽しいのか」とか「趣味の時間を確保できたか」などプライベートなリストを追加してもOKです。ぜひ、質問リストを仕事以外も含めたバランスを取るために活用してみてください。


最後に

マネージャーになりたての自分を思い出しながら、社内外で関わったマネージャーのことを想像しながら、私が仕事で意識していることを言語化してみました。読み返すと、いろんなことを偉そうに語っていますが、テキストを書きながら今の自分にはまだ足りないなと振り返る部分もありました。

個人的には、もっとマネジメントという仕事に興味を持って、面白みを感じる人が世の中に増えるといいなと切に願っています。私自身、チームメンバーと一緒にいい経験をさせてもらっているし、「事業と組織を成長させる」という重要なコトに向き合えて、責任も自分が引き受ける、という環境は本当にいろんな景色を見せてくれます。ここで学んでいることは、仕事以上にプライベートや生き方に好影響を与えてくれているようにも感じます。

本記事では、あえて触れなかったテーマがあります。お気づきの方もいると思いますが「採用」と「評価」です。これらはマネージャーとしての最重要タスクなのですが、あまりにもテーマとして大きく、分量が多くなりすぎるため、いずれ別記事として(公開できる範囲で)考えをまとめていきたいと思います。

本記事を書くにあたってフィードバックをくださったhurutoriyaさんkuri8iveさんAkihiroさん、同僚のみなさん、有益な指摘ありがとうございました。

私自身、いろんな人の話を聞くのが好きなので、もし本記事を見てなにか話したい、という方がいたら Twitter: @pacocat にご連絡ください。本記事が、過去の自分のような悩みを抱えている人に届きますように。


この記事が気に入ったらサポートをしてみませんか?