15
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

LITALICOAdvent Calendar 2022

Day 25

マネジメントのアティチュード (マネージャー用アタッチメント編)

Last updated at Posted at 2022-12-25

こんにちわ、LITALICOのCTOをやっている@yuyaichihashiです。

この記事は『LITALICO Advent Calendar 2022』のカレンダー3最終日の記事です。
昨年にも増して様々な職種の人たちがバラエティに富んだ記事を書いていますので、ぜひ他の記事も覗いてみてくださいね!

はじめに

どういう記事か?

マネジメントについての書籍は良書がたくさんあり、具体的な手法や取り組みについて、今年の弊社のアドベントカレンダーでも良い記事を書いてくれているマネージャーが何人もいます。
そこで、具体的な手法ではなく、自分がマネジメントの仕事をする上での物事の考え方や、それにもとづいた姿勢や心構えについて、言語化してみました。

そういった内容ですので、多分に個人的な見方や解釈を含んでおり、間違っても何かの正解のようなものではなく、読まれた方々が自分なりの考えを深めるヒントになることがありやなしや、といったものであることをご了承ください。

ちなみに、自分でも、これから書くことを完璧に実践できているかというと、そんなことはありません。
(できています、なんて言ったら、LITALICOのみんなに総つっこみをもらいます。こういう心がけでいるんだなと、優しい眼差しで見守ってください笑)

注意事項

直接スタッフを部下に持つ1チームのマネージャーから、複数チームを束ねるマネージャー、さらに複数の部署を束ねるマネージャーなど、様々なレイヤーのマネジメントを役割とする人を総称してマネージャーとして扱います。

自分自身は、1チームのマネージャーであった時期はもう10年以上前ですので、視点は上位レイヤーに偏っていると思いますが、どのレイヤーのマネージャーでもヒントになる部分はあるのではないかと思って書いています。

また、網羅性は考慮せず、重要度が高いものからピックアップ、などもしていないため、また別の機会に色々と後出しするかもしれません。

構成

どうも書いていると、マネージャーに限ったことではないものも多々あるため、厳密に分類しづらいものもありますが、2つの記事に分割しました。
標準装備編は、マネージャーではない方も参考になることがあるかもしれません。

  • マネジメントのアティチュード (標準装備編)
  • マネジメントのアティチュード (マネージャー用アタッチメント編)

本記事は「マネージャー用アタッチメント編」です。
* 「標準装備編」はこちら

マネジメントのアティチュード (マネージャー用アタッチメント編)

大きく、以下の章に分類してみましたが、その中の項目は関係し合うものも多いです。

  • 基本姿勢
  • 未来を作る
  • みんながパフォーマンスを発揮できる
  • 組織を作る

基本姿勢

この章では、僕がマネジメントの仕事をする上での基本的な姿勢や心得ていることを書いてみます。

人への向き合い方の基本

マネージャー自身がコードを書いて、直接、ユーザーへの価値提供に繋がるアウトプットをすることはありません。(プレイングマネージャーという形もありますが、それは2つの役割を担っているだけですので。)
いつでも、最終的に、ユーザーや社会に届ける価値を生み出してくれているのは、職種に限らず、スタッフとして仕事をしてくれているみんなです。

マネージャーは、チームのみんなの力を、ビジョンの実現に向けて、あるべき方向に、最大限の価値を創出できるように、必要なあらゆることをする人です。

ですので、何はともあれ、チームメンバーをはじめとした、人への向き合い方がとても重要だと思います。

僕は、人に向き合う基本姿勢として、以下のようなことを意識しています。

  • 公平であること
  • 誠実、真摯であること
  • 自分を飾らないこと
  • 裏表なく、本音を話すこと
  • 正面から向き合うこと
  • 傾聴すること
  • 相手を思うこと
  • リスペクトを持つこと
  • 感謝すること
  • 過ちを認め、謝罪し、軌道修正できること
  • 相談は可能な限り優先して聞くこと

褒める、認める、感謝する

これは、自分の性格というか行動特性もあって、(賞賛するという意味での)褒めるということが少ないと、近くで仕事をする人たちには思われているんじゃないかなぁと思います。

ただ、自然とそうなってしまっているだけではなく、以下のように考えていたりします。

褒めるというのは、そこに評価が内包されていると思います。
つまり、その人の複数の行動や成果の中での、相対的なものになると思います。
ですので、何を褒めて、何を褒めないということには、一定の基準があり、それがフラフラしないことが大切ではないかなと考えています。
特に、その日その時の自分の気分が混ざってしまわないように気をつけたり、その成果によってピンチを脱したなどの周辺要因が混ざってしまわないように気をつけたりしています。(もちろん、ピンチを脱したのですから、一緒に喜んだり、労ったりはしますよ。)
もちろん、基準は相手によって違いますし、同じ相手であっても、その人の成長に応じて、基準を変えていくことはしています。

一方で、認めるというのは、しっかり伝えていくことが大切だと考えています。
こういうことに気が回って素敵だね、この進め方はこういう工夫があっていいね、こういうことができるようになって成長したね、みたいなことは、なるべく口に出して伝えていった方が良いと思います。
それは褒めてるんじゃないの?とも思うかもしれませんし、言葉の定義の問題かもしれませんが、自分の中では、これは、事実を事実として認めるという感じで、褒めるはもっと賞賛のニュアンスを含んだ理解をしています。
ですので、任せて、信頼する、などと同じように、その人のことを認める行為だと思っています。

また、感謝も、小さいことへでも、大きいことへでも、いくらでも伝えて良いものですし、伝えた方が良いものだと思います。
ありがとうは、多すぎることはないので、溢れてくるだけ、できるだけ伝えていけるように心がけています。

自分の態度やあり方

マネージャーの態度として、ブレないことが重要だと考えています。

ブレないためには、意思決定の軸や、言動の元となる、自分の芯となる考え方をしっかり持つことが大切だと思います。

もちろん、時には間違った判断をしてしまうこともあります。
その時は、いきなり覆すのではなく、判断を誤ったことを伝え、謝罪し、軌道修正し、調整できるスケジュールは調整したり、手伝えることがあるならリカバリを手伝いましょう。
それもまた、ブレない、ということの一つだと考えています。

ちなみに、ブレないことと、成長しないことは違います。
より良い意思決定をできるように、自分の考えをアップデートしていくことは必要です。

また、自分の感情の波や体調の良し悪しなども、当然あるのですが、人への接し方や言動、意思決定の軸からは、可能な限り切り離すように意識をしています。
たまには出ちゃったりはしますが、ちょっと今日体調が〜と伝えたり、ごめん、さっき別のことでイライラしてたのが出ちゃったかもとか、正直に伝えるようにしています。

システム障害などトラブル発生時も同様です。
内心は「うっわー、やっべー、どうしよー、何起きてんのよ?」とか思っていても、淡々と状況を整理し、みんなのアクションを決めていけるように心がけています。
(これで、今度からは、LITALICOのみんなには、内心焦ってんな?と思われるようになりましたが笑)

  • 関係者へのエスカレーションと、経過報告プロセスや顧客アナウンスプロセスの開始
  • サービス回復優先、と同時に、影響内容/範囲の割り出し、可能な限り、解析に必要な情報の確保
  • システム回復に必要な原因解析と回復、必要に応じて、運用回避策の検討
  • 回復後の状況整理と報告
  • 発生要因や根本原因の解析や、解消/改善のための計画

など、基本の流れや方針を、自分に刷り込んでおくと、動じない態度でいやすいです。
自分の記事でなんですが、こういった思考の段取りを身につけておくことも有効だと思います。

構造と力 (上下関係)

組織構造には、上下関係が発生します。
CTOかVPoEカEMかTLかICかなど、役割分担の話なのですが、その役割の組織上の権限や責任範囲上、偉いとかそういうことではなく、構造としての上下関係はあります。

ですので、マネジメントレイヤーにいる人間は、その人が望もうが望むまいが、権威性が生じます。
マネージャーではなくても、キャリアの長さとか、社歴やチーム所属歴の長さとか、他の要素でも発生しますが(ですのでマネージャー以外も気をつけましょう)、マネージャーの場合、そこに具体的な権限も付加されているので、一層、そのことに自覚的になる必要があると考えています。
人事権を有している場合、自分の発言はほとんど暴力じゃないか?くらいに過敏になってもよいと思っています。

こういった力が働くので、

  • Noと言えない、反論できない
  • 疑問を呈することができない
  • 意見を言えない
  • うまくいっていないことを伝えられない
  • 問題が起きたことを伝えられない
  • マネージャーが好む意見を考えてしまう
  • ユーザーにとっての価値より、マネージャーの正解を探してしまう

ということがスタッフに起きても、それは、構造的に自然なことだと思います。
これは、その人に問題があるのではなく、この力学を意識した上で、マネージャー側がどういう振る舞いをするか、どういう組織環境や仕組みを作っていくかが必要だと考えています。

幸い、現職では、僕に疑問をぶつけてくれたり、意見をしてくれたりすることもあって、ものすごくありがたいですし、どうしたら、みんなが意見を言えるかは、継続して改善を続けたいですが、それでも、自分に必要十分な指摘をしてもらえることはないと考えた方が良いと思っています。
ですので、標準装備編に書いたように「常に自分を疑う」ことが、より重要だと思います。

未来を作る

だけではなく、未来を作ることは、マネージャーの重要な役割の一つだと考えています。
これは、上位レイヤーのマネージャーほどウェイトが上がる役割だと思います。

可能性の海、意思決定の束

マネージャーになると、自分がやるべきことを誰かから明確に与えられることはなくなっていきます。
それはマネジメントの責任範囲が大きくなっていくほど、より顕著になっていきます。
自組織に期待されること、前提条件や制約条件、達成条件など、全てが抽象的であいまいになっていきますし、流動的になっていきます。

前提として、上位のマネージャーと、その責任範囲についてはすり合わせておく必要がありますが、その責任範囲においては、自分の意志で、カオスをコスモスに変えていくことが、マネージャーの仕事とも言えるかと思います。

その具体的な行為は何かと言ったら、意思決定だと思います。

時間が流れ続ける、つまり、未来だったものがになり過去になっていく、ということは、無限にある可能性が、1つの可能性に収束し、事実として確定するということだと思います。
ただ、ある会社/事業/特定組織/プロジェクトといった範囲で、からの連続性の影響が及びやすい5年とか10年とかの時間単位では、可能性は無限ではなく、ある程度有限な幅は持っていると思います。

この可能性の幅(=未来)を望ましいものに変えていくのは、収束した1つの可能性であるとして、どの可能性を選択する(=意思決定)かだと思いますので、マネジメントの仕事として、意思決定することを重要視しています。
マネージャーとしてのレイヤーが上がっていくほど、責任範囲が大きくなり、つまり、向かい合う可能性の幅が大きくなり、自分の意思決定が及ぼす影響が大きくなる、と考えています。

1つの意思決定が未来に大きく影響する、という意思決定の機会も時にはありますが、基本的には、日々の意思決定の積み重ねが、望ましい未来を作っていくと思います。

標準装備編で書いたことの多くも、意思決定の質を上げていくために繋がることだと思っています。

未来を仕込む

マネージャーになると、さらに、マネジメントする組織単位が多くなっていくにつれ、より長い時間軸での仕事が必要となっていきます。
今やったことの成果が現れるまでの時間が長期化していきます。

そのため、時間軸を長く捉え、ターゲットとする未来の状態像を描き、現在地からそこへ辿り着くためのステップやプロセスを考え、今、そのための仕込みをする、というのが重要だと考えています。
もちろん、今のための仕事も必要ですが、今のための仕事にどれくらい、1年後のための仕事にどれくらい、3年後のための仕事にどれくらい、といった感じで、自分がどのようにリソースを割り振れているのかを意識しています。

どれくらいの時間軸の長さまで扱うかは、自身のマネージャーとしてのレイヤーによっても違うと思いますが、僕の場合は、おおむね以下のような意識で仕事をしてきました。
(会社のフェーズであったり、他にも左右する要素はあると思います。)

  • 1チームのマネージャー時代:1〜2年
  • 複数チームを束ねたマネージャー時代:2〜3年
  • 特定領域を担う部署のマネージャー時代:4〜5年
  • 現在(CTO):5〜7年

LITALICOには部長職として入社し6年弱経ちますが(途中でCTOになりました)、入社当時、4〜5年後にこういう状態にしたいと描いたところから、おおむね今の状態は違っていません。
いくらかビハインドしましたし、もちろん、多くの人の力があってこその今ですが、ターゲットとなる未来を描き、そこに向けて意思を持ってアクションをしなければ、こうはならなかったかもしれないですし、もっともっと時間がかかったかもしれません。(ほっといても、僕がいなくても、こうなったかもしれませんが笑)

みんながパフォーマンスを発揮できる

繰り返しになりますが、マネージャーの仕事は、いかにみんなが、あるべき方向に向かって、パフォーマンスを発揮できるようにするかが重要だと考えています。

そのために、以下のようなことを意識しています。

  • 安心して、気持ちよく、楽しんでチャレンジできる
  • ビジョンを共有する
  • 方針や価値観を共有する
  • 情報を渡す
  • 横の繋がりを作る
  • マネージャーを道具として渡す
  • 任せる
  • トップダウン?ボトムアップ?

安心して、気持ちよく、楽しんでチャレンジできる

そもそもの基本として、安心して働ける、気持ちよく働ける、チャレンジを楽しめる、という状況が、一人ひとりの人が十分にパフォーマンスを発揮できる状況だと考えています。

安心については、心理的安全性ももちろん、働き方に関する制度設計や報酬設計であったり、過度な負荷が無いとか、職場や仕事だけでなく、日常生活を安心して送れることも大切だと思います。

気持ちよく働けるには、安心という土台があった上で、一緒に働く仲間がお互いのことをよく知り、お互いへのリスペクトがあったり、自分の仕事が誰かの助けになっている実感があったり、達成感を感じられたり、関わるプロダクトに誇りが持てたり、成長できている実感が持てたり、などなど、一人ひとり何が大切かどれくらい大切かは違ったりしますので、偏った見方をしたり、固定的な考え方をしないように意識しながら、より良い組織環境を作っていくことが必要だと考えています。

会社組織として、特定の実現したい目的(会社のビジョンやプロダクトビジョンなど)を共有する集団である以上、安心して気持ちよく過ごせるだけではなく、チームも個人もチャレンジをし、成長したり、ビジョンに向けて事業を推進する必要がありますが、とはいえ、チャレンジもまた、楽しんでチャレンジできた方が良い結果を産みますし、繰り返し、チャレンジしていくことにも前向きになれます。
そこには2つあって、1つは、適切なハードルのチャレンジであることや、適度な息抜きがあったりすることだと思います。
もう1つは、組織(会社やチーム)のビジョンや目標と、個人のビジョンややりたいこと学びたいことの重なりが大きいことだと考えています。

ビジョンを共有する

年度/半期/クォーターなどのチーム目標ももちろんですが、チームとしてのビジョンを明確にし、チームで共有することが大切だと考えています。
チームがあらゆる場面で向かう先を迷わないための北極星です。

チームのフェーズや状況などにもより、マネージャーが作って共有することもあれば、チームのみんなで考えることもあれば、その間の色んなバランスがあると思いますが、どういうプロセスを取るにしろ、ビジョンを描き共有するということは、マネージャーの責務だと意識しています。

方針や価値観を共有する

ビジョンとして、チームの向かう先を示すだけではなく、そこへの向かい方としての方針や、その過程で大切にしたい考え方や価値観などもまた、明確にし、またはチームで考え、チームで共有すべきものだと考えています。
向かう先だけではなく、何かを考えたり判断する上で、チームのみんなが迷わないための指針です。

情報を渡す

マネージャーになると、会社や他部署/チームなどの様々な情報が、スタッフの頃より多く入ってくるようになります。
より上位レイヤーに上がるほど、それは増えていきます。

もちろん、どんな情報でもチーム内に共有して良いわけではありません。
インサイダー情報はもちろん、不確定であることで混乱を生むために、伝達範囲やタイミングが設計された情報もあります。
設定された条件を守る、条件が明示されていなくても、多角的にメリット/デメリットを考慮し判断をする必要がありますが、原則として、情報はオープンに、可能な限り共有した方が良いと考えています。

自分が受け取った状態の情報は、マネージャーである自分を受け取り手として想定した内容や質や量であったりしますので、ものによっては、ただそのままチームに渡すのではなく、

  • 必要な補足情報や背景をセットで伝える
  • 馴染みの少ない領域や種類の情報は、咀嚼のしかたも教える
  • 他の情報と繋げて、そこに見出せる意味を示す

など、みんながその情報を活用できるように工夫することも意識しています。

横の繋がりを作る

自分との縦の繋がりだけでなく、その人にとって、有益な情報交換ができたり、サポート関係になりそうな人を見つけて、チーム内はもちろん、チーム外の横の繋がりや斜めの繋がりができるように意識をしています。

その人が仕事を進めたり、成長する上で、自分(マネージャー)からのサポートだけでにならないことが大切だと考えています。

マネージャーを道具として渡す

チームのみんなにとって、自分(=マネージャー)は、利用できるリソースの一つだと考えるように伝えています。

マネージャーとは、何か自分に指示をしたり、自分の仕事の進め方にアドバイスをくれたり、成果物のレビューをしてくれたりするだけの存在ではなく、自分のミッションを達成する上で、マネージャーという権限があったらこう進められるなとか、マネージャーが持ってる社内の繋がりがあれば、この人の知恵を借りられるなとか、必要なら、自発的に使って良いんだよという話をしています。
アドバイスやレビューにしても、決められたタイミングに受動的に、だけではなく、最適なタイミングに主体的にお願いして良いものだとしています。

スタッフとしては、そう言われても、なかなかそれはハードルが、、、とは思ったりもするでしょうが、とはいえ、まずはこちらからそう伝えていかないと、そうそう自発的にマネージャーを有効活用する人は少ないと思います。

任せる

任せるというのも、マネージャーの重要な仕事であり、逆に、これをうまくできるようになれば、マネージャーの役割の半分は果たせるのではないかとも思っています。

任せるというのは、何か大きな役割を委譲するとかだけではなく、タスクを分解し、3時間で終わるチケットを1つアサインするとかまで含めて、全て、任せるという行為だと考えています。

また、任せたことについて、成果物をもらうまで一切関与しないというだけではなく、途中途中で議論やチェックのポイントを設けたり、やり方も示したりしたとしても、それは任せ方の違いであって、任せるという行為だとも思っています。

つまり、任せるとか任せ方自体には、マイクロマネジメントかマクロマネジメントかということはなく、マイクロかマクロかというのは、その人が今できることに対しての相対的なものだと考えています。

任せるをうまくやるには、2つのポイントがあると思います。

1つは、今の話の流れにあった通り、その人の今にとって、適切な内容や難易度やサイズで任せるタスクや任せ方を設定することだと考えています。
簡単過ぎず、難し過ぎない、適度なチャレンジ度合いの見極め。
そのタスクを達成するにあたって想定される、その人が成長する必要があるポイントに対して、どれくらいの関わり方が、やり過ぎでもなく、不足し過ぎでもないかの見極め。
また、1つのタスクの視点だけではなく、その人の今の力で実施できるタスクの量に対して、チャレンジ要素のあるタスクをどれくらい混ぜるかの見極めも大切だと思います。

もう1つは、そのタスクのアウトプットの質やパフォーマンスの許容幅の見立てであったり、そもそも許容することだと考えています。
当然、すでにそのタスクを十分にこなせる力を持った人にアサインした時と比較して、終えるまでに時間もかかるでしょうし、成果物の品質も違うはずです。
それは至極当然のことで、そうやって、みんな成長してきたはずですし、今のチームのみんながそうやって成長していくことで、未来のチームのパフォーマンスが向上していくのです。
一方で、チームにはもありますので、チームの未来のバランスを考慮しながら、何をいつ誰に任せていくのか考えることも大切だと考えています。

トップダウン?ボトムアップ?

チームができたばかり、スタッフも新入社員ばかり、など、チームの状況によっては、ある程度トップダウンで進める必要がある場合もありますが、基本的には、自分が全てを決め、指示し、みんなに実行してもらうというスタイルだと、自分の思考や能力がチームの限界になってしまうため、みんなが自発的に、自律的に考え動けるチームにしたいと考えています。

色んな状況やメリット/デメリットがあるので、トップダウンを否定しているわけではなく、トップダウン/ボトムアップの両極だけではないバランスも含めて、ケースバイケースでの様々な選択があると思っていますが、原則として、個人では成し得ないことを成すためにチームがあると考えると、その時に適したバランスの幅の中で、できるだけ、トップダウンではないあり方を考えたいと思いっています。

そのため、

  • 「安心して、気持ちよく、楽しんでチャレンジできる」で働く土台があり、
  • 「ビジョンを共有する」「方針や価値観を共有する」で枠組みがあり、
  • 「情報を渡す」「横の繋がりを作る」「マネージャーを道具として渡す」で武器やリソースやサポートがあり、
  • 「任せる」で能動的に力を発揮できる状況がある、

ということを意識しています。

組織を作る

組織を作ることもまた、マネージャーの大きな役割の一つだと思います。
組織とはまた人です。箱や仕組みを作るだけではなく、仲間を集め、人を育てることも、組織作りです。
(執筆期間の都合もあり、この章は特に網羅性に欠けます。採用とか大切なことはたくさんあるのですが。)

構造と力 (組織図)

経験上の観測結果としても、組織図が、どういう構造で、どういう組織があって、それらにどういう名前が付いているか、というのは、みんなの意識や行動に影響をすると思っています。

ですので、組織設計する時には、その設計の意図がうまく表現できているか、よく考える必要があると考えています。

また、どのような企業のどのようなフェーズでも最適なコレ!という組織構成はありません。
ある瞬間において、全ての面で優秀な組織構成もありません。
その時々のフェーズや経営戦略/事業戦略/技術戦略から、特定範囲の組織であれば、関係するスコープの各種戦略や、その組織単位のミッションやビジョンから、メリットとデメリットのバランスを考え、設計する必要があると思います。

設計する組織単位が大きくなるほど、数年後に目指す組織設計を描き、逆算して、段階的に変化させる必要があることもあります。

オンボーディング

新しく仲間として入社してくれる方々が、本来持っている力を発揮できるようになっていくには、お互いの協力のもと、オンボーディングというプロセスが必要です。

これは、入社される方が、新しい環境に合わせるため、新しい環境を知り、自分をそこにピッタリ形を変えてはまっていくことでも、受け入れる会社やチームが、入社される方が活躍できるように、その方のやりやすい環境や仕組みとなるように、チームの形を変えピッタリとその方にフィットしていくことでも、どちらでもなく、双方が、お互いを理解し、相手に手を伸ばし、ハンドシェイクするプロセスだと考えています。
お互いを理解し、認め合い、良いところを活かし合い、入社される方も力を発揮し、チームも進化するのが理想的なあり方だと思います。
新しく入社される方を迎えるというのは、チームにとっても進化する大きなチャンスです。

また、オンボーディングについて思うことのもう1つは、等級が高い(弊社には等級制度があります)方が入社する、マネージャーなどの役職者として入社する、という際のオンボーディングのあり方です。

お手並み拝見しようじゃないか、などと意地の悪い人はいないかもしれませんが、どこか無意識的に、シニアだし、マネージャーだし、自分で必要なインプットをし、自律的に活躍し始めてくれるんじゃないか、と思ってしまったりすることがあると思います。

たしかに、自発的に情報を取りにいくなどの行動は見られたりすることもあると思いますが、僕は、逆に、シニアな方、マネージャーとして入社する方などの方が、より力を発揮できるまでに多くのサポートを必要とすると考えています。

そういったポジションの方への期待値や役割を考えると、その仕事のために必要なドメインの理解、事業や組織の理解、プロダクトの理解、これまでの背景やコンテクストの理解などは、より多く深いはずです。
APIを1つ実装できるようになるまでに必要なそれと、PdMとともに1プロダクトの開発ロードマップを作れるようになるまでに必要なそれでは違うはずです。
それは、そのポジションを任せる方として入社するのに、十分なスキルや知見や経験があることとは別の話です。
そのことを、受け入れるチーム内はもちろん、関係する他職種のチーム含め理解し、意識することが大切だと考えています。
また、入社した本人もまた、シニアやマネージャーの方ほど、早く活躍しないとという自己へのプレッシャーを強く持っていることが多いので、本人にもこういった考え方を伝えていくことが大切だと思っています。

目標/評価へのマネージャーの関わり方

会社によって、制度や仕組みは様々ですが、ある一定期間に対して、一人ひとりが目標を設定し、期間の終わりに評価をするという会社は多いと思います。
弊社では、半期ごとに目標設定と評価のサイクルを回しています。

このサイクルの中で、特に、評価へのマネージャーの関わり方について、以下のように考えています。

  • いざ評価のタイミングになって始めて、良かった悪かったと裁定を下す役割ではない
  • 期中を通じて、振り返りや気づきを促したり、フィードバックしたり、アドバイスをしたり、目標を達成できるようにサポートするのが役割

マネージャーの仕事は、目標達成しませんでしたねとか、ここが成長しないままでしたね、とかを半年に一度スタッフに言うことではなく、みんなが成長し、チームのパフォーマンスが向上し、より良い価値をより多くのユーザーに届けることだと思っています。

また、僕は上位マネージャーとして、マネージャー自身の目標設定や評価を行いますが、マネージャーのみなさんには、チームの事業目標の他に、

  • チームやスタッフのコンディション
  • チームやスタッフの成長

について、目標に含めるようにお願いをしています。

チームが担当しているプロダクトで、目標通りの品質やスピードで機能リリースをできたとしても、みんなが疲弊していたり、チームがバラバラであったり、何の成長機会も無い半年を過ごしたのと、一人ひとりが成長し、みんなが協力し合い、チームとしても仕組みやコラボレーションが改善されているのでは、継続性や未来のパフォーマンスは違うからです。

後任を作る

特に成長企業では、上にも横にも組織が広がっていきます。

事業機会や投資機会があるにも関わらず、マネージャーを担う人がいないことで、組織のキャパシティを広げられず、ボトルネックになってしまう可能性があります。

一方で、育成にしろ、採用にしろ、そう簡単なことではありません。

常に、自分の後任となりそうな人がいないか考えたり、育成したりといったことはしておいた方がよいと考えています。
また、その際には、今の自分の役割そのままとは限らないことにも留意するとよいと思います。
組織が拡大していくので、今は自分がカバーしている範囲を分割して、より専門的に扱ってもらう可能性などもあるためです。

おわりに

いかがでしたでしょうか?
個人的な要素が強いので、読まれた方にとって、どこまで参考になるのかわかりませんが、何かのヒントになることがあれば幸いです。

繰り返しになりますが、自分がいつでもこの通りにできているわけではありません。
ただ、こういった自分なりの考えを持つこと自体が、大切なことではないかなと思います。

また、それも固定し切ってしまうのではなく、(自分の芯となるので安易にではないですが)常に新しい気づきを取り入れ、アップデートしていくことも大切だと思います。

15
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
15
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?