一度、マネジメントを振り返る

直近2年ほどマネジメント職を専任したり兼任したりしながらやってきましたが、転職に伴って一度マネジメント職から離れることになったので、この2年間の振り返りをしようと思います。

定義

マネジメントといっても言葉の意味が幅広く、何をやってきたかを説明する上で読み手の解釈が分かれやすい用語だと思っています。そのため、マネジメントという言葉を使う場合は以下の項目が含まれているものとします(併せて経験した期間や回数についても書いてあります)。ただし、比率としてはピープルマネジメントの歴が長いので、今回の内容としては、その内容に関してのものがほとんどとなります。

• ピープルマネジメント(2年)

• プロダクトマネジメント(1年ちょっと)

• テクノロジーマネジメント(適宜)

• プロジェクトマネジメント(数回)

専任？兼任？

冒頭に専任・兼任という言葉を使いましたが、大きな違いとしてはコードを書いていたかどうかの違いです。Webエンジニア(以下、エンジニア)としての役割をしつつ、マネジメントをしていた時期を「兼任」、エンジニアとしての数に自身を入れていなかった時期を「専任」としています。

専任と兼任をしていた期間としては下記のとおりです。

• 専任: 2021年9月〜2022年4月

• 兼任: 2020年10月〜2021年8月、2022年5月〜2022年11月

ここで、専任と兼任をそれぞれどのように移り変わったのかについて説明します。

まず、兼任から専任への変更は役職の変化でした。マネジメントを始めた2020年10月はマネージャーとしての役職でしたが、2021年9月から部長となりました。既に頼れるエンジニアが何名もいたこと、成長の機会を生み出したり、プロダクトを前に進めるための動きをした方が組織として良いと思い、このタイミングで専任で動くようになりました。実際、人数も増えていき、様々なプロジェクトが並列で動いていたので、必要な変更ではありました。

一方で、専任から兼任に変更した理由は体制変更と事業方針の変更です。詳細は割愛しますが、プロダクト開発への力の入れ方が変わったため、マネジメントにかける時間がこれまでよりも必要ではなくなりました。また、体制の変更によって全体の開発スピードが落ちたこともあり、自身もエンジニアとしても動くようになりました。プレイヤーをしつつマネジメントもするというのはなかなか難しいという話もありますが、専任時にメンバーに任せていることも増えてきていたので、なんとか回っていました。

大切にしたいこと

今後、もし再びマネジメント職につくようなことがあった場合に、この2年間の経験の中で次もマネジメントをする上で大切にしたいと思うことを3つ挙げてみます。もちろん、これ以外にも大切なことはあるのですが、3つに絞って書いていきます。

精神的な安定感

マネジメントをする以前にも安定感について記事に書いたことがありますが、特にマネジメント職になってから重要に思うようになりました。

自分の特性として機嫌の波があまりなく、「なんか楽しそうだね」と言われることが度々あったので、この点で苦労するということがあまりなかったのは良かったです。他の人から顔色を伺われる、機嫌の良し悪しを見られることで、スピードが落ちたり、ストレスになったりすることは本当に避けたいので、遠慮なくストレートに言ってもらえる人でありたいです。

状況に応じた動き方をすること

自社でサービスを提供している会社にいたので、事業の状況によって求められる動き方が変わってきます。例えば、組織化に力を入れる時期や事業開発に力を入れる時期など、事業の状況によって優先度は変わっていきます。

そのため、マネジメントに専念したり、兼任したりする動き方は振り返ると良かったのではないかと思っています。もちろん、その都度状況を把握して、必要な動きを取らないといけないので大変ではありますが、結果に繋がるための行動をすべきなので、やるべきことをやれていたと思います。

また、プロダクトとして何かを作る、より良く変えるだけではなくて、使われなくなった機能をなくす、見た目を変えずに内部的により良い構造に作り変える動きも必要です。これを「より高くジャンプするためにしゃがんでいる状態」と表現していましたが、この先を見据えた動き方も機会を見て組織として取り組んでいけたのは良かったと思っています。

成長への期待を持つ

チームにいた方々の多くは自分よりも若い人が多かったですし、優秀な方々でしたので、その人がやっていきたいことやその人に合う機会を任せて、成長に繋げてもらいたいという思いを持ってマネジメントに取り組みました。これは会社のカルチャーの影響をかなり受けていて、自分自身が過去の実績としてはそこまでない中で多くの機会を任せていただいたことが要因となっています。

もちろん本人の努力が必要ですので、期待通りにいくかどうかは分かりませんが、少なくともマネジメントをやるからには、特にピープルマネジメントにおいてはその人の活躍を期待して、その人の成長を期待して任せていきました。その結果として、成果を出して給料を上げてもらいたいと思って動いていました。

今後変えていきたいこと

上記とは逆に、もし次にマネジメントをする機会があるのであれば変えていきたいことを挙げていきます。ただし、これはマネジメントに限らずチームのメンバーとして動く場合においても大切なことも含まれているので今後はやっていきたいです。

相手は自分ではないという意識をもつ

マネジメントをやっていて特に思ったこととしては自分と相手の考え方や行動のギャップです。

「自分であればこう考える・行動する」といったものは、自分にしか適用されないケースがほとんどです。同じ情報を持っていたとしてもその情報をどう解釈して発展させるか、どう行動に移すかは人それぞれ違います。これは本人の性質やこれまでの経験、持っている知識、関心対象などによって影響を受けるので、完全に一致させることは難しいです。

そのため、ミッション・ビジョン・バリューなど、考え方や行動する上での組織としての指針が大切になってくるのですが、これも初めから同じ考え方で動く集団であれば不要ですし、指針があったとしても完全にリンクさせることは難しいです。次の項目に繋がるのですが、前提として「相手は自分ではない」という意識がどれだけ持てるかが重要になると思いました。裏を返せば、この段階で止まっている場合は特にピープルマネジメントを行うことがどこかで難しくなる印象です。

浸透させるためのコミュニケーションを取っていく

「相手は自分ではない」ので、コミュニケーションを取らずに集団で何かを成し遂げることは難しいです。

それは頭にありつつも、組織としてどうしていきたいかを語ること、思っていることを伝えることが自分には足りていなかったと思います。もちろん、全くしていなかったわけではないですが、その頻度や伝え方などは上手く出来ていなかったと思っています。

また、開発組織とビジネスサイドをより繋ぐことで、プロダクトの開発に反映すべきでしたが、そこも上手く出来ていたかといえば疑問が残るところです。仕組みや体制を作ることはしていましたが、行動に移ってもらえなかったり、上手く回せていなかったと思います。(※1)

考えの共有や浸透のためのコミュニケーションは、組織全体が同じ目標に向けて、同じ考えを持った上で前に進むために必要なことです。それらの行動が自分は弱かったと思います。(※2)

期待値を調整する

期待値といっても様々ですが、一例として自分に対して期待するものが合っていないと思う場面がありました。

たとえば、自分としてはその決定を任せているつもりが、相手は自分に決めてほしいと思っていることがありました。自分より立場が上の人に決めてほしい、任せたいと思っている可能性がある一方で、自分が意思決定をしなければいけない場面もあるので、任せるところと自分が決めるところは明確にすべきだなと思いました。

マネジメントも専門スキルで継続的に学習が必要

トータルすると2年ほどマネジメントをしてきましたが、この領域は現時点だと才能ではなくスキルだと思いました。(※3)

自分自身、役割を任された時はマネジメント未経験だったので、既にマネージャーをなさっている方の真似をしたり、それまで苦手だったビジネス書を読んでみたり、各社のマネージャーが書いている記事を読んだりした上で、実際に試すことで少しずつ形にすることが出来ました。

スキルなので、他のスキルと同様に得意・不得意や向き・不向き、関心のある・なしがあります。特にマネジメントは人に関係するスキルなので、向き・不向き、関心のある・なしの差が生まれやすい印象があり、そのため、ある種の才能のように思えてしまうのかと思います。

最近では、マネジメントに関する本が様々出ており、特定領域(ファシリテーション、1on1など)に特化したものから『エンジニア』という職種に対してのものまであるので、それらを読んでみるのも良いのではないでしょうか。

また、これは印象なので特に根拠はないのですが、そのようなマネジメントに関する本が販売されたり、そういった役職に就く人が生まれることで、これまでぼんやりしていたやるべきことの言語化や専任化が進んだ結果、年々マネジメント職の人がやるべきことが増えているように見えます。そしてプロダクトや組織の大規模化に伴い、新たにやるべきことも増えているようにも思います。

どんどんと難易度が上がっていくため、継続的に学習したり、実践の中で試してみたりする必要がありますが、これを1つのスキルという視点で見るとエンジニアが日頃学習していることとあまり変わらないと思いました。

おわりに

期間としては2年という短い期間ではありますが、この経験はやって良かったと思いましたし、これが今後の自分のキャリアの中心になる可能性もあると思っています。ただ、現時点だとマネジメント職ではなく1人の開発者として再度頑張りたいという思いもあるため、まずはそっちでやりきれるだけやってみたいと思います。

※1: もちろんそこまで意識や手が回っていなかったという考えもありますが、どうすればもっと良くなるかの意識の浸透は出来るので、そこまでやるべきでした。

※2: 理想でいえば個々人がそれぞれ考えを持っているけどちょっとずれているからその微修正を行うくらいが良いのですが、大きくずれていることもあったのでそう上手くはいきませんでした。

※3: 自分の経験できた範囲なので、これが超大規模になってくると才能が必要かもしれません。ただ、ほとんどの場合はスキルで片付けられると思っています。