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

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

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

インプットを続ける

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

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

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

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

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

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ヶ月なので、圧倒的に経験不足！！

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

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

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

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

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

エンジニアが辞めない組織について本気出して考えてみた

いつもは技術系の記事ばかりですが、最近ビジネス書を読んで「なるほどなー」と思ったので、
エンジニアが居続けてくれる組織についてあれこれ考えてみます。

読んだ本↓

辞めない採用、即戦力の育成で儲かる会社になる！

まだこの本しか人事本は読んでないので、この本の受け売りが多いです。（他の著者のをもう数冊読まなきゃね！）
あとは自分がエンジニアやっていて感じることからの感覚をミックスして。

0. 本の概要

さてさて、この本の概要ですが、一番言いたいところは
『人の成長なくして企業の成長なし』
ここに尽きると思います。
社員教育にお金と時間をかけられていない会社は、そのうち企業成績が頭打ちになるぞ、と。

社内で優秀な人を生み出せなければたしかに将来的にはそうなりますね。
「優秀な人を外から採ればいい」という考え方もありますが、現在社内にいる人との軋轢(あつれき)が生じたり、
この本にも書かれていますが、他社で業績を上げた人が必ずしも自社でパフォーマンスを発揮できるとは限りません。

それは、なにも転職者が経歴を大きく見せたとかいうわけでなく、
その人が優秀に見えるようにサポートした優秀な人が他社にはいたとか、
優秀な人が満足して働ける下地（社風、上司、資金体制）が自社にはないとか様々な理由があります。

この作者さんの会社は営業マンを育ててるので立場は違いますが、
「成長できない会社に居る意味はない」と考えるエンジニアとは利害関係が一致しそうですね。

「優秀になって会社辞めていく人いるじゃん！」というツッコミはありそうですが、
優秀な人を作らないよりはマシです。
教育をせずに優秀な人を1人も生み出さないよりは、
50人優秀な人を作って30人辞めていくことのほうが遥かに会社の未来が輝きます。
教育を受けたことを実感する人は会社に恩義を持ってくれますので、自社に仕事を持ってきてくれることや、社に再び戻ってきてくれる可能性だってあります。

1. 採用と教育

「辞めない組織」と考えると、職場環境の改善を考えてしまいますが、
そもそも採用に失敗している可能性があります。

たとえば、「優秀な人だけをとる」。
会社立ち上げ時に凄腕エンジニアを2〜3名確保する、というのはいいかもしれませんが、
3名前後揃ってきたなら、会社の理念に共感してくれ、未熟だけど素直でやる気にあふれてる人を1人は採るべきです。

まず、優秀な人は簡単に辞めます。
理由は単純で、優秀だからです。
他に働きどころはいくらでもあります。

そしてエンジニア業界は狭いので、
優秀な人が辞めると「あそこはあんまりいい会社じゃないかも」という印象が生まれます。（退職エントリが書かれることもありますし）

ですので、優秀な人だけをとらず、未熟な人を入れます。

そして、優秀な人達には未熟な人を教育してもらいます。
この教育には様々な効果があると私は考えています。

• 教える側が、知識の再確認ができ成長できる
• 人的マネジメントスキルのある人（リーダーに向く人）がわかる
• 母性本能の目覚め

最後アホなこと書きましたが、男女問わずいわゆる母性本能は多かれ少なかれあると思っていて、
人を育てていると、「この子の面倒は最後まで見なくちゃ」という気持ちが芽生える人がいます。
そうすると、優秀な人であれどその職場で働く特別な意味というのが生まれ、長く居着いてくれる原因につながる可能性があります。

この、「職場で働く意味」というのはとても大事で、
本の中ではコミュニケーションを密にすることで『職場が居場所の１つになっている』ことが辞めない環境づくりの１つの策だと書いてありますが、
優秀なエンジニアの居場所は多いです。ネットや他社との付き合いなど、居場所はありますしすぐに作れます。

自社で働く意味を持たせられる組織づくりがあるなら積極的にしていくべきでしょう。

教育する側と教育される側の密な関係がある組織というのは、
「フリーランスをするよりも会社で働くほうがいい」と思わせる大きな効果が望めるでしょう。

エンジニア人事としては、教育する側と教育される側のバランスが悪くならないよう、採用に気を付けるのもそうですし、
教育される側だった人が教育する側に回れるタイミングを見つけられるよう、教育する側の人たちのフィードバック、
教育する側に向いている人を知るために教育される側の人たちのフィードバックをとるなど、
各エンジニア間の相互フィードバックを見られるシステムづくりをしておくことも大事になります。

2. 優秀になる人を採る

さて、先ほど「会社の理念に共感してくれ、未熟だけど素直でやる気にあふれてる人」と書きました。

会社の理念に共感してくれる人を選ぶのは、長く居てもらうためです。
社長の考え方と大きくかけ離れている人は、いずれ会社の方針との衝突を起こします。
しかもプログラマーはロジカルに考えられる人が多いので、その人の意見にも筋が通っていたりして困ります。

これがコミュニケーションが密な職場で、かつ、社長と対等に話し合える職場であればいいのですが、
そうでない場合は新入社員の不満はどんどん溜まっていき、「いつか辞めてやる……」とストレスを抱えていきます。
社長は強い意志をもって方針を考えているわけで、それを簡単に曲げるわけもないので、人事としては会社の方針に共感してくれる人を優先的に採用するのが無難でしょう。

「イエスマンだけ採用しろ」と書いてるみたいで自分でも書いてて気持ち悪さはあるのですが、
ただ、会社の向いてる方向と違う方向を向いてる人が多くては会社はいっこうに進みませんし、
社長目線としては、会社の方針をしっかり理解してくれているポストがいなければ社長が抱えている業務を安心して任せられません。
そういうわけで、全てにイエスである必要はもちろんありませんが、会社理念には同意してほしいかな、というところです。

次の素直でやる気にあふれる人については、単純ですね。
教えがいがあるからです。

教える側になる人たちは教えることの専門家ではないですから、
モチベーションが保てなくなれば放棄します。
モチベーション維持となるのは、やはり結果が見えることです。

ですので人事は、教えがいのある人を採用してくるのが大切になりますし、
教える側の上の立場の人は、新人の成長を本人だけでなく教える側の人にも伝えてあげてください。
子どもの成長が褒められるのは、親として当然うれしいことです。

そして、素直でやる気にあふれる新人は、速いスピードで教える側へと成長を遂げてくれることでしょう。

3. 不満のキャッチアップ

この本……えっと、間が空いてしまったのでもう一度貼っておきます。この本ですね。

辞めない採用、即戦力の育成で儲かる会社になる！

この本でこのような記述があります。

コミュニケーションが足りない職場では、最初は小さかった不満の種が、放置されることによって日に日に増幅していく。
その結果、「どうせ誰も自分を気にかけていないのだから、我慢する必要はない」と辞めてしまう。
十中八九、このパターンです。

＞ それな ＜

という気持ちです。

本当にこれです。
別れるカップルと同じです。

不満へのケアが足りていないと、しだいに「不満あつめ」をしだします。
最初は「△△がイヤ」という不満だったのが、
時間が経つと「△△がイヤだし、▽▽もいけてないし、××もダメ」とどんどん嫌なことが目についていきます。

友達に相談したら当然「えー、それならもう辞めちゃいなよ」ということになりますし、
自問自答でも「辞めるしかない」という結論に達するので、辞職の意志が固まります。

辞めることを決意したあとでは、それの理由付けのためにますます「不満あつめ」は加速していきますし、
その状態ではもう上司の「辞めないでよ」という声は厚い壁に阻まれてちっとも届きません。

辞職願を出されてからではもう遅いのです。
大切なのは、常に不満へのケアが出来ることです。
必ずしも改善まで結びつく必要はありません。聞いてあげるだけでも大きく違います。

では、不満を常に言ってもらえるようにするにはどうすればいいかという点については
密なコミュニケーション。これに尽きると思います。

本の中では質も大事だけどそれ以上に量が大事としており、
上司が部下とのコミュニケーションを積極的にとるような仕組みづくりについても触れられています。

本の中では飲みニケーションを仕組み化している点が記述されていますが、
なにもお酒を飲むことに限らず、（飲めない人もいますし）
おいしい料理を食べることや一緒にゲームをすることでも気はゆるみますので、
そういう機会を多く設けることが有効でしょう。

社内の人とのランチ補助制度や、部活制度を設けてる会社がありますが、
こういう狙いだったんだなと気付き感心しました。

『優秀な技術者を追い出してしまう方法』という記事がありましたが、
これらは具体的すぎる内容でどの会社でも等しく起こる問題ではないですから、
会社としてまずおこなうことは、コミュニケーションを密にして上司が部下の不満を常にキャッチアップできる環境づくり、というところでしょう。
その上で、記事にあるような不満が出てくるかもしれませんが。

コミュニケーションの数、そして、気がゆるんでなんでも話せる場（お酒だったりおいしい食事だったりゲームだったりがある場）の用意、
あとは「最近なんか困ってることある？」と聞くようにすれば、自然と不満をキャッチアップできるようになっていくことでしょう。
最初は部下は遠慮するでしょうが、回数を重ねて少しずつ壁がなくなればよいかと思います。

4. おわりに

以上、『辞めない採用、即戦力の育成で儲かる会社になる！』（著：小山昇）を読んで
自分なりにまとめてみた意見でした。

この本とても良くて、1000円ちょっとで買えるのに、

• 新卒採用・中途採用における人の選び方
• 新卒へのアピール方法
• 新卒採用の教育手法
• 中途採用の注意点、教育手法
• 社員に長く居てもらうための仕組みづくり

など、網羅的な人事の考え方を実例とともに読みやすい文体で書いてあって良書だなと感じました。

もちろんあくまで一人の考え方をまとめた本なので全てを鵜呑みにするのは良くありませんが、
なかなか説得力のある発言にあふれていました。

エンジニア採用の現場ではよく「優秀な人（＝即戦力を指す）に来てもらいたい」なんて声を耳にしますが、
本当にそれでいいの？ 新人教育って必要ないの？ など考えるところはいくつかあったので、今回の記事で考えをまとめられてよかったです。

話の流れで入れられなかったのですが、私の考える「優秀な人」は情報共有の出来る人です。
どれだけプログラミングが出来る人でも、会社は組織立って動くところですから情報共有をしてくれないと困ります。

勝手に実装進めてたけど、他の人がプルリク見て初めて、急ぎでない用件のほうを実装してたことがわかるとかは困ります。
なにも情報共有されていないと、その人が辞めたあとによくわからないコードの山が残ります。

逆にプログラミングが多少できなかろうと、悩んでいることを共有してくれるのなら周りはアドバイスができます。

どうしたら情報共有の出来る人って採用できるんだろうと考えちゃいますが、
ひとつは伝達力を測ることでそれを望めるのかなと思ったりはします。
たとえば「バナナとはなにか説明してください」のような、ふだん説明しないようなものの説明を、
多すぎないしゃべりで、的確に表現できる人は情報伝達力が高いなと感じます。

いろいろ考えてみましたが、
人事というのはなかなか最適解がなくて、プログラマーよりよっぽど難しい職業のようです。大変面白いですね。