エンジニアマネージャーに必要なことってなんだろう？

最近、ありがたいことにチームリーダーをやらせてもらっているのですが、
経験が無いのでどうすればいいのか手探りでやっています。

今後どうしていけばいいのか、
今の時点で得られていることを頭の整理としてまとめておきたいと思います。

インプットを続ける

エンジニアに大切なことは技術力の向上ですが、
マネージャーはそれにプラスしてマネージング力の向上を続けていかなければなりません。

そのためには人事、経理、組織論について、本やネット記事を読むだとか、
職場の他のマネージャー、他社のマネージャーに話を伺いに行き、手法を学び続ける必要があります。

そうしないと自己流が出来上がってしまい、「自分は上手くやれてるはずなのに」と、しだいに頭の固い人間になってしまいます。
上手くやれてるつもりになるのが一番危ないです。

どうすればチームがダメになるのかを知る

いくつか手段があると思います。

1. 経験する
2. 聞く・読む
3. チームメンバーの性格を把握する

1 はつまり自分や自分の所属するグループが崩壊をすることです。
自分の経験なので記憶に強く残りますから、同じ失敗はしにくくなります。
問題点はそんなに何回もチームの崩壊を経験できないことです(笑)

ということで、2 の、人から聞いたり記事を読むことになるわけです。
他社の「こんな状況からこう正常化させた」という記事から、逆説的に、ダメな状況がどういうものかを学べます。

3 は上記とは別軸の話です。
一般論としての 1, 2 ではなく、現在のチームの特性としての 3 です。
個人のやる気を下げる要因がなんなのか知ることは、チーム崩壊を起こさないために大事なことです。
何がイヤなことであるか直接聞いたり、現在の職場で気になりつつあることを聞いたり、前の職場を辞めた原因はなんなのか聞いたり。
1 on 1 や普段の会話で、個人個人のNGポイントを集めておきましょう。

上司が何を欲しているか知る・予見する

これはマネージャーに限らず大切なことですが、
上司が何を欲しているか予見して動くことは非常に大切です。

マネージャーの上司はマネージャーです。
チームマネージャーはメンバーの行動や未来を考えますが、その上司のマネージャーは
「チームが何をしているか」「チームがこれからどうしたいか」などを気にしています。

チームの四半期目標だったり、1 on 1 の結果報告だったり、チームが達成したことの週次報告（月次報告）だったり、
チームの状況を知るために必要なことは聞かれる前に上げていくくらいにしましょう。

あなたがチームリーダーとして上司からの信頼を得られることは、
チームが好きに動きやすくなれることにもつながります。大事なことです。

自分が頭いいと思わない

自分の頭がいいと思ってしまうと、あらゆることを自分でやろうとしてしまいます。
それはスケジュール的に自分の首を絞めてしまうばかりでなく、
結局のところ自分が気付いていないだけで他の人のほうが上手くやれることだったりして、
周りの反感を知らず知らずに買っていたりします。

周りの人間を信じましょう。
その人は失敗するかもしれませんが、失敗から学ぶこともあります。
子どもが怪我をしないように公園で遊ばせない親がいい親とは言えません。
（ただし大怪我に気付けるよう、公園のベンチから様子を確認してはおきましょうね？）

メンバーの成果は褒め称える

何かしてもらったら「ありがとう」と言うべきですし、
良い成果を上げたのなら「ナイス！」と伝えるべきです。

信じて任せて感謝する。
聞いた話だとこれがけっこう難しいらしいです。

信じられて任せられて感謝されたら、誰もが気持ちよく働けるでしょう。

メンバーの市場価値を高める

エンジニアはひとつの会社には留まりません。常に新しい環境を求める生き物です。
そのとき――チームメンバーの転職――は必ずやってきます。

それは他の会社に嫁（婿）に出すようなものだと私は思っています。
ですので、親の立場となるマネージャーがそのときまでにすることは、
「どこに嫁（婿）に出しても恥ずかしくない人間にする」ことだと私は思っています。

そのために必要なことは、会社でいろいろなことを経験させること、そしてそのおこなったことを説明できる能力を身に付けさせることです。
面接で絶対に聞かれることは「前職でおこなってきたこと」です。
ここの説得力は面接の結果を左右します。

1. いろいろな業務を経験させる
2. その業務で何をしたのか、何を工夫したのか、チームの振り返り会や 1 on 1 で振り返らせる
3. プレゼンテーション能力を向上させる（社内勉強会の開催など）
4. 社外へのアウトプット（勉強会での登壇やブログなど）を勧める

これらのことを継続的におこなうと、メンバーの市場価値は上がっていくのではないでしょうか？
このことによって会社の利益が出るとかはないでしょうが、続けていけば何かいいことがある……はず？ ……たぶん。

夢を持つ

自分がすごく苦手なところなんですが、夢を持つのは大切だと思います。
チームメンバーに将来どのようになりたいのか聞いてキャリアプランを設計すべき人が、将来どうなりたいのかを持っていないってのは意味がわかりませんし、
そんな人にはメンバーも正直に夢を語ってはくれないでしょう。

夢って、難しいですね……うーん、自分は将来何をしたいんだろう。
『夢をかなえよう』って曲の主人公並みに夢について考えちゃうぞ。

これは現在の自分が特に出来ていない課題です……。

1 on 1 で何を話せばいいのか？

今までのことの総まとめになります。

• 最近会社で気がかりなこと（嫌なこと）はないかの確認
• 直近の業務で何をしたのかの振り返り
• 次にどういう業務をやってみたいかヒアリング
• 会社に欲しいもの、導入したいツール
• 短期的・長期的な個人目標

など、エンジニアマネージャーとしてチームを回していく上で必要な情報の収集をおこないます。
基本は気軽に雑談をすればいいと思いますが、
こういった、チームを回していく上で必要な情報を得られていないのなら、
1 on 1 の機会を利用して積極的に情報収集をしていくべきでしょう。

【追記】1 on 1 についてより掘り下げた記事を書きました！

おわりに

以上が、現時点で考えるエンジニアマネージャーとして必要なことです。

考えたり経験したり、読んだり聞いたりして情報を集めてはいますが、
いかんせんまだリーダー経験としては2ヶ月なので、圧倒的に経験不足！！

足りないところや間違いなどがあり、数ヶ月経ったら更新したくなりそうですが、
今の時点で一度、得たことを振り返っておきたかったのでまとめました。

まだマネージャー職という自覚がなくて、
「メンバーのタスク状況の確認とか文章書いたりでコードあまり書いてないし、重たい実装タスクはメンバーに任せてるし、私って仕事してないのでは？！」
と思う日々が続いています。

同業の人に相談したら、「いや、コードはあまり書かなくなるものだよ、それでいいんだよ」と言われましたが、
突然リーダーになってしまいコードを書くことが仕事という考えから抜けられない私はまだ戸惑っています。
慣れるかな・・・？

最後に、最近読んでよかった本をアフィリエイトとしてぺたりとー。
自分やチームメンバーが今なにが出来て、次はなにを出来るようになればいいかを考えることができる良書でした。

人事の超プロが明かす評価基準―――「できる人」と「認められる人」はどこが違うのか (三笠書房 電子書籍)