はじめに
3月決算の企業であれば、そろそろ来期の話が始まり、来月辺りには新任マネージャーの内示も出てくるような時期になってきました。
年末年始は時間があるので、色んなことを顧みますね。
2023年を振り返っていたところ、急に飛躍して気づいたら私がマネージャーとして過ごした年月に思いを馳せていたので、勢いで何か書くことに決めました。
どんな人が書いてるか
私は2018年度から課長職に就いており、2022年度から副部長という職責を持っています。
つまりマネージャとしてはもうすぐ6年のキャリアを持つことになりますので、そこそこの中堅ですね。
私の所属企業は50年の歴史を持つ上場企業です。
私個人は新世代のマネージャー(年齢というよりもパーソナリティで)という見られ方をしていますが、それなりに歴史があるので一般的に想像するようなマネージャーの要素も求められます。
組織マネジメントをするメンバーはだいたい10～15人くらいです。
プロジェクトマネジマントという観点でいうと、60名くらいをマネジメントしていました。
事業ポートフォリオとしては、プロダクト開発とSIを両方持っている企業ですが、私はずっとSIの事業に携わっています。
つまり純粋なエンジニアリングのマネジメント以外にもビジネス開発的な役割も一部求められます。
マネージャーになった動機
マネージャーになる動機で個人的に一番理想だなと思うのは「やりたいことをやろうと思ったらひとりではできなかった」というパターンです。
やりたいことをスケールさせようと思ったときに、メンバーの力が必要だったというのが一番理想的ですよね。
ここで多くの場合語られるのは、プロダクトだとかサービスの軸です。
つまり、自分の思い描く最高のプロダクトを作りたいんだ！という感じのやつです。
私の場合はSI事業に携わっていたこともあり、こういうプロダクトを作りたい、みたいな強い思いはありませんでした。
ノウハウをパッケージングしてサービス化することはありますが、それは通常業務として企画できていたというのもあります。
ただ、こういうチームを作りたい、という思いはありました。
私自身は若い時からかなり自由に色んなことにチャレンジさせてもらった経験があります。
当時、そんなチャレンジを後押ししてくれた人たちに聞いたところ、「楽しそうだから」と言ってもらったのを覚えています。
楽しそうだから応援してくれるって素敵だなと思い、そうありたいと強く思いました。
なので、みんなに楽しそうに仕事をしてほしい。
そして昔の私のように楽しそうにしてる人が応援されるチームが理想で、その数をもっと増やしたいと思ったんです。
で、それを実現するには自分がマネージャーになるのが一番早いと思ったんですね。
本当は「こんなプロダクト作りたい！」とかの方が恰好が付きますが、長年やってみてこんな理由でも十分だなと感じます。
むしろ、これも「やりたいことをスケールさせようと思ったときに、メンバーの力が必要だった」という私の理想の形のひとつですよね。
大事だと思うもの
ということで、やっぱり「俺は/私はこうしたいんだ」という思いは必要だと思います。
これがないと結局言われたことをやるだけで、それを自分でやるかメンバーにやってもらうかだけの違いになってしまいます。
そして、大事だなと思うのは、ちゃんとその思いをわかりやすく周囲に伝えることですね。
「この人はこういうことがしたいんだな」と理解をしてもらうことで、フォロワーが出てきます。
ビジョンを伝える、と言ったらそうなのかもしれないですが、ちゃんと振る舞いの中にそれがにじみ出てくることが重要かなと思っています。
多くのメンバーと接する中で実感するのは、これは別にマネージャーに限った話ではないということです。
やりたいことがあって、それをちゃんと伝えている人は自然と(役割ではなく本質的な意味での)リーダーになっていきます。
変わろうと意識したこと
たぶん結果的に色々と変わってるのですが、明確に意識しているものはひとつです。
よく「視座を高く」と言われますが、これって具体的にどういう意味でしょうか。
経営レベルでは全然話が変わってきますが、現場レベル、つまりメンバーとファーストラインマネージャーの違いであればある程度明確です。
それは見ている時間軸の違いです。視座を高く=高いところから見ているんだから少し遠くを見る、ということです。
私の場合はどうしてもSIの例になりますが、SIではプロジェクト、というのがひとつの単位になります。
プロジェクトというのは有期ですから、必ず終わりが来ますし、別の始まりも訪れます。
そうすると、メンバー単位で見たときに現プロジェクトから次プロジェクトにうまくシフトするか、だとか、プロジェクト単位で見たときに始動するプロジェクトの体制構築のために現有プロジェクトの扱いをどうしていくかとかを見据えて先に対処をしておく必要性が出てきます。見ているのは少し先の未来だということですね。
メンバーだったときは、まず今参画しているプロジェクトを成功裏に終えることが至上命題ですから、時間軸としては現在を中心にみていることになります(もちろん次工程とかは見るわけですが)。
ファーストラインマネージャーが大変なのは、現在と未来を同じくらいの解像度で見ないといけないからです。
現場に入りすぎるのがよくないとされるのは、現在にばかり目が行ってしまうからですね。
自分が何か月/何年先のことを考えて今の行動をしているのかを意識するようになりました。
技術との向き合い方
マネジメント職は技術から離れてしまうのでしょうか。
マネージャーになった当初は思い切りプレイングマネージャでしたから、「技術バリバリのままでいく」と強く思っていました。
ところが年数が経ちビジネスレポートをたくさん作っているうちに、気づくと技術から距離が遠くなっていました。
もうちょっと具体的に言うと、意識だけはあるので、たとえば技術記事には目を通します、トレンドも押さえます。
ですがフィジカルに時間が必要なもの、つまりオフラインイベントへの参加やコードを書くことが圧倒的に少なくなりました。
どうしてもミーティングなどで時間拘束が増えますから、油断していると必ずこうなります。
この辺りは強い意志を持って時間を確保しないといけないということがわかったので、ある時からちゃんと時間をブロックするように意識をしています。
一方で、思いがけず良かった部分もあります。
メンバーのおかげで技術が習得できる
エンジニアでマネージャーになるということは、いくつかのポイントを押さえたらある程度その技術の全体像を理解できるだけの経験を持っていると思います。
このポイントを押さえるという部分は、メンバーと一緒にやることで一気に効率を上げることができます。
マネージャーの視点から見ると「やってみた」を全部０からやる必要がなくなるのです。
（一方でメンバーから見ると、ポイントを伝えてもらうことで、自分でも気にするポイントがクリアになっていきます）
また、日ごろからそういった関係を築けていれば、メンバーが技術的な困りごとに当たったときに相談に来てくれます。
そうすると自分のところに集まるのは選りすぐりのトラブルシューティングになりますので、これも技術の理解度を一気にあげてくれる要素となり得ます。
あるときにフロントエンドもバックエンドもあまり使ったことのない技術を使ったことがあったのですが、このときはそれぞれを担当してくれたメンバーからの情報を集めることで、一気に両方の理解が深まりました。
結果私が一番得をしているのではないかと少し申し訳なく思った記憶があります。
ということで、メンバーとの関係性というのは非常に重要になってきますね。
メンバーとの向き合い方
ご存じの通り、メンバーとの向き合い方に正解はないですね。
正解/不正解は脇に置いて、自分の頭で考えて色々試してみることが大事だなと思います。
私の場合は、特に以下の２つを意識していました。
自己評価と周囲の評価が噛み合うようにタイミングを合わせる
ある程度の年数を社会人として過ごした方であれば、「今年は私にとって勝負の年だ」と意気込んだり「転機になりそうな気ががする」という予感めいたものを感じるタイミングがあったと思います。
メンバー個々人のそういったタイミングをちゃんと見て、プロジェクトへのアサインなどを考慮します。
私の所属会社では、活躍した社員を表彰するための制度があります。
極端なことを言うと、本人の意気込みと照らして「今年は絶対に彼/彼女を表彰してもらう」という決意をします。
これは本人にとって勝負の年に、ちゃんと勝負できる環境を整えてあげる、という話です。
もちろん実際の表彰者の選出にあたって便宜を図るわけではありません。ひいきとは一線を画す必要があります。
作られた成功では、自己評価との乖離で逆に苦しむことになりかねません。
無理に引き上げるのではなく、自分が頑張ったと自負できたタイミングで周囲の評価が付いてくることでより飛躍できるのです。
予期せぬ出会いを演出する
開発組織というのは、どうしても生産性の向上と切っても切れない関係にあります。
エンタープライズの開発に携わっている場合、優秀なエンジニアが定型化した雛形に則って開発を進めるのが全体として最も効率が良いということに結論になりがちです。
一見してこれは一昔前の話を持ち出しているように聞こえますが、実際は歴史上何度も繰り返しています。
これ自体は別に悪い話ではありません。いわゆる最適化にあたります。
マネジメントをしていると割と振り切ることが大事で、最適化に行くなら最適化に振り切るのが大事です。
ただ、あまりにも最適化が進んでしまうと、次の雛形を作る人が育たない、あるいは生成AIの登場のようなイノベーションに追従できないという問題があります。
そこに追従するだけのエンジニアの成長をどうやって両立するかということに意識が向きました。
エンジニア個人の成長を見たときに、何でやる気スイッチがオンされるかって、結構偶発的な出会いだったりします。
私でいうと、まだ生まれたての頃のパブリッククラウドとの出会いがやる気スイッチオンのきっかけでした。
ただ、最適化の中で偶発的な出会いってなかなかないですよね。
なので、いわゆる20%ルールみたいな枠組みが必要になってきます。(80%の方は振り切る)
この20%の使い方で、なるべくメンバーと一緒に何かをしていくのが大事だと思うようになりました。
この20%の使い方って、ほっておくと自己研鑽になりがちです。資格をとりましょう、で終わりにしてしまいがち。
ですが、この20%を使って何か一緒にやることで、偶発的なやる気スイッチオンができないかと考えています。
実はこれは最近強く思いまだ試している最中です。結果はいかに。。
マネージャーの喜び
長年マネージャーをやっていると、メンバーの喜び/悲しみがそのまま自分の喜びになるような感覚を覚えます。
・メンバーにスポットライトがあたったとき
・メンバーの成長を目の当たりにしたとき
これらの喜びは本当に筆舌に尽くしがたいものがあります。
一方で、どんなにいい関係のマネージャーとメンバーであっても、卒業のタイミングは必ずやってきます。
幸いにも私はまだメンバーから退職の申し出を受けたことはありませんが、それでもずっと一緒にやっていれば独り立ちのタイミングというのは絶対やってきます。
これはもちろん喜ばしいことなのですが、心情的な寂しさはありますよね。
長年やっているおかげで、独り立ちしたメンバーが活躍している声を聴くことも増えてきました。
そんなときは心情的な寂しさを喜びが上回るので、やっぱりやっていて良かったと思う瞬間です。
おわりに
ただ振り返っただけで、とりとめのない話を書いてしまいました。
世の中の記事を見ても、いわゆる誰が見てもすごい人の話は出ていても、普通のマネージャーの話ってあんまりないなって思ったので勢いで書きました。
2018年、初めてマネージャーになって実感したのは、周囲のマネージャーって色んなことを考えているんだなということです。
これを読んでいるメンバーの方が居たら、マネージャーの方に聞いてみると実は思ったより色んなことを考えているかもしれません。
そんな話のきっかけにもなればいいなと思い書きました。