そういうときがよくあります。
マネジメントを仕事にしたのは今の会社が初めてだけど、きっとこれから先も会社に所属している限りは、なくならない気持ちなんだと思います。
だから、そんなときに振り返れるようなものを残しておきます。
...時が経つのは早いもので、コードレビューを受けるのがつらかったわたしも、気がついたらチームリーダーになっていました。
今では、当時自分自身が書いた記事を読んで、レビュアーとして考える日々を送っています。
煽りタイトルで申し訳ないのですが、マネジメントを始めてまだ1ヶ月しか経っていません。
けれど、なんとなく、
- コードを書く時間が減ってしまったことに対する不安
- 自分は何も生産していないのではないか
- 今後のキャリアどうしよう？
- 職場の人間関係に対して常にアンテナを張っていなければいけない気がする不安
- Slackから目が離せない
- あそこで話している人たち、何を話しているのだろう？
こんな感じで、うっかり夜遅くまで残業することになってしまったり、やや寝不足ぎみになってしまったり、なんとなく胃腸の調子を崩したりしています。
それが自分だけならまだしも、どうやら他のリーダーも遅くまで残業したり、どこか顔色が悪そうだったりするのです。
もしかして、こうして悩んでいるのは自分だけではないのかもしれないと思い、約1年ぶりに「つらくなったときは」というタイトルで記事を書くに至りました。
特につらいこと
自分は幸いなことに、そういう機会が巡って来ることは今のところないのですが、周囲の話を聞いているとマネジメントのお仕事で一番つらいのがこちら。ネガティブメンバーのマネジメントだそうです。
i47.hatenablog.com
現状
自分がチームリーダーになってからのスタンスは、以下の記事に近いです。ちなみにこの翌日のアドベントカレンダーがリアル上司ですw
takaking22.com
社内の人に読まれていそうなのですごく書きづらいんですが、特に、なるべく「情報を筒抜けにする」のは、やってみてかなり良い感じです。メンバーとの距離も広がらないですし。
そして自分を取り巻く現状としては、以下の記事が近いです。たぶんお会いしたことのある方の記事です。
kobakei.hatenadiary.jp
いかんせんコードを書くことの成果が見えやすいので比べてしまうのですが、ここで出てくる 「エンジニアの生産性」って、どうやって成果としてはかるものなんだろう？ と最近は疑問に思ったりもしています。
よく言われる「プレイヤーとして優秀なエンジニアが昇給していくためには望んでないのにマネジメントにならないといけない」問題の対策として、マネジメント系のキャリアパス以外にもエキスパート系のキャリアパスを定義し、「それぞれのキャリアパスの各グレードってどういう役割が期待されているんだっけ」などと考えて設計しています。
ここは最近、自分も部署内で問題提起をしました。
だって、昇給したくてマネジメ(自主規制
というのはおいといて、わたしはこうあるけれど、チームメンバーにはエキスパート系のキャリアパスを早く見せたいな、と思っています。
悩みは「悩みを言えないこと」
先の記事の「意識低い系」スタンスで、けっこう悩みを言ってしまうことは多いです。でもやっぱりあんまりよくないなあ、と最近は思っていて、チームリーダーだけで話し合う場を設けたり、他の部署との交流を増やすなどして工夫しています。
あとは採用ですね。「一番大事なのは採用」と記事にもあるとおり、マネジメント難易度を下げるための採用、したいです。。
今の自分にはなかった考えがあった
この記事を書くにあたり、例によって「チームリーダー つらい」とか「エンジニアリングマネージャー つらい」とかいうググり方をしたわけですが（笑）、そんな中で新しい発見もいくつかありました。
toyokeizai.net
上記の記事は2ページ目から「退職を伝える前に試してみること」がいくつか上がっているんですが、
- 仕事のやり方をパクる
- チームメンバーの個性を知る
- 準備をする
あたりは自分も意識している一方で 「助けを求める」 という案はなかったな、と思いました。
先述の通りわたし自身にも上司がいるので、あまり抱え込まずに頼ってもいいのかもしれません。
次に、以下の記事です。
geechs-magazine.com
この 「マネージャーになると起こる変化」 の中で自分が「おっ」と思ったのが以下です。
- 技術の習得範囲が広がる
- 非エンジニアとのコミュニケーションが増える
マネージャーなのに技術の習得範囲が広がるのはすごく不思議なんですが、マジです。
自分は最近インフラまわりを勉強しているんですが、たまたま自分のチームにインフラが得意なメンバーがいたり、自分と同じようにインフラ勉強したいって思っているメンバーがいるので、一緒に勉強している感じがして楽しいです。まあ、あっという間に自分だけ置いていかれちゃうんでしょうけどw
あと、チームメンバーのインフラの設計レビューに出ることもあるんですが、CTOが直々に出てきてハイレベルなやりとりが見れるのも（傍観者だからというのもあり）ちょっと楽しいです。傍観者だけど、事前に自分も必死で予習しました。笑
非エンジニアとのコミュニケーションが広がるというのは、コミュ力のある方ならマネージャーにならなくともできるかもしれないのですが、規模の大きな企業になってくるとなかなか難しかったりします。
リーダー同士での会話や、リーダーのみが対象になるイベントは、大きな企業の中でも比較的優秀なメンバーが集まってやることが多いので、お互い話してみると普通に面白かったりします。
わたしの理想
個人的には、こういう感じが理想です。タイトルがアレですがw
eri-twin.hateblo.jp
最初に出てくる、こういうリーダー、ほんとうによく見ます。
リーダーはただのスーパーマン。
要件からバックログのタスクにする。調整して、みんながタスクに集中できる環境をつくってあげられる。コード書いてタスクを燃やせる。なんでもできる。リーダーすごいよ。
なんでもできるのは確かに良いことなんですけど、この記事にあるような「リーダーに甘えていたボンクラコーダー」を生み出すような人はチームビルディングできない人なんだな、と思います。なので、そうならないように意識はしているつもりです。
「プロジェクトの目的のために行動できる人になる」のは、リーダーだけじゃいけない
こういう話は他の記事でもありまして、
developers.freee.co.jp
上記のfreeeさんの記事ではCTOみずから新卒のメンバーに 「3年間でスモールチームのCTOになってほしい」 と伝えていますし、
www.m3tech.blog
上記の記事はエムスリーさんですが、実際にCTOを任せちゃってます。
マネジメントはやりたくなかったわけじゃない
わたし自身、本当に昇給のためにマネジメントを始めたのかというと、今のタイミングだけ見たらイエスなんですが（笑）、そのうち子供ができて、生まれて、子育てして、それを2人か3人くらいやって、本格的に復帰して現場にコミットできるようになった段階では、どのみちもう一度やろうと思っています。今のところ。
以下の記事にもあるんですが、
qiita.com
機械を直接相手にする必要はなくなりますが、チームの価値を最大化するという課題にたいしエンジニアリングすること自体にかわりがない
この通りでして、たしかEM.FMの第1回かな？同じような話を広木さんあたりがされていた記憶があります。
大学時代オーケストラサークルにいたときに、どうやったら効率よくメンバーに動いてもらえるんだろうって思って、マネジメントとか、心理学に関する本を読み漁って、トライアンドエラーを繰り返していた時期がありました。
そういうのもあって、どうやら自分は他人よりもその手のスキルがあるらしい？と思うこともあるのですが、単にエンジニアの中にいるからかもしれません。
ただ、今のタイミングではもう少し技術力を強化したい気持ちもあって、その間で揺れてしまうことも多いです。
エンジニアのためのマネジメントキャリアパスという本の5章でも、以下のようにあります。
いきおい管理者は経営と人的管理に関する職務に忙殺され、仮に技術的な作業に時間を割こうとしても夜間か週末しかない、ということになります。自分の会社がこういう企業なら、「コードの作成やシステムのデザインはもう十分マスターした」と得心するまでは技術力の強化に専念し、納得がいった時点で初めて経営系に舵を切るか否か判断するとよいでしょう。いったんコードを書く作業から遠ざかってしまうと遅れを取り戻すのが大変です。機が熟する前に離れてしまうと、中間管理職より上に昇るのに必要な技術力を十分身につけられずに終わってしまう恐れがあるのです。
いつだってプレイヤーに戻れる
先に紹介したエンジニアのためのマネジメントキャリアパスの3章には、こんな文章があります。
あなたが望めば進路変更も可能だ、ということを忘れてはなりません。ある時点で管理職に就いてはみたが、やはり自分には向いていないと判断し、技術畑に戻る人も少なくありません。どちらの選択肢も決して恒久的なものではないのです。いずれにしても常にしっかり目をあけていること。どちらの道にもメリット、デメリットはあり、どの仕事が一番自分に向いているかを見定めるのはあなた自身なのです。
わたし自身、この文章にすごく救われました。
今日も、他の部署の方と話している中で「戻ったって良いんだよ、そうしたいと思ったら伝えてごらん」と言ってもらうことがありました。ですので、つらくなってしまったときも過度に悲観的にはならないでいたいな、と思います。
また、以下の記事では、えふしんさんが「エンジニアリングマネージャは入れ替わっても良い」と述べています。
devblog.thebase.in
そして、ここからが大事なことですが、必ずしもエンジニアリングマネージャは永遠にその立場でいる必要もなく、一定期間で別の人に入れ替わっても良いと考えています。期待するのは大人としてチームの活躍を支えるチームディレクションとしての役割です。ディレクションかプレーヤーかというのは、その都度、役割を入れ替えることはあってもよいと思います。
なによりそうすることで、たくさんのエンジニアが人の成長を支える仕事の難しさを知ることができるし、一度、エンジニアリングマネージャを経験した人は、より広い視野での仕事を期待できるわけなので、改めて現場でコードを書く役割にコミットしながら、開発プロジェクトマネジメントやメンバーの育成においてもエンジニアリングマネジメント力を発揮することが期待できます。
そうこうしてるうちに新しい事業アイディアが出てきた時には、そういう人が率先してエンジニアリングマネージャとしてチームを作れるようになることで組織のスケーラビリティは向上します。
このようにエンジニア組織全体としては、立場を入れ替え可能であることと、マネージャという役割をエンジニアとしてのキャリアの幅や柔軟性を高める役割として定義することで、プログラマ35歳定年説に代表されるような、コードを書かなくなって、エンジニアとしての死を迎えるみたいな不安な世界を終わらせることができるのではないかと考えています。
まとめ
マネジメントを任せてもらえるというのは信頼されている証しで、成長している証しです。そしてきっとマネジメントという仕事を通して、エンジニアとして技術的にも人間的にも、もっと成長できることがあるはずです。いっぽうで、コードにコミットできる今だからこそ手を動かしてスキルを伸ばしたい！と思うこともあります。
まあ、マネジメントはやりたければいつでもできるという話でもないので、もうしばらく、この貴重な機会を味わっているつもりです。
余談
...という日々を過ごしている中で、そういう気持ちをもっともっといろんな人とお話ししたいので、サイゼリヤミートアップをしようと思いconnpassで下書きまで作ってあるんですが、予約できるサイゼリヤが見当たらなくてできないでいます...！
もう普通の居酒屋でやろうかなあ。
