Hacking HR! #2 に参加して採用業務の失敗を聞いてきたよ
会社にとって 一番大事なもの ってなんでしょう？
間違いなく 採用 です！
ろくでもない人を雇うと、周りと衝突を起こしたりマネジメントコストが増えたり、
疲れて周りの人が辞めていったり……とまあ、ろくなことになりません。
そんなろくでもない人を部長職にでもしちゃおうものなら、
部単位でどんどん人が辞めていくし、ろくでもない部長がろくでもない人を入社させてしまうのでまあ簡単に会社が腐っていきます。
一人辞めると一人採用する必要があるわけで、それにかかるコストは
エージェントに支払う金額だけで 200 〜 300 万円ほど。（それ以外に掲載費用などもかかるわけですが）
会社の人材の質が下がるだけでなく実質的な費用もかかるので、
採用は本当に気をつけないと、すぐに大変なことになっていきます。
（そういえば昨年こんな記事を書きました）
0. Hacking HR! #2 に参加したよ
さて、前置きが長くなりましたが、
そんな採用に関するおもしろそうな勉強会を発見し、参加してきました。
Hacking HR! #2 です。
スタートアップ企業の人事の勉強会で、特に採用に関してのテーマでやっているようです。
今回のテーマは『実録！「採用」業務の失敗談』
いいですね、このテーマだけであと5回くらいはできるんじゃないかって気がします。
会場は Repro さんです。
トイレにミューズ泡ハンドソープが置かれていて、
「わかるわ〜、ビル備え付けのハンドソープって全然泡立たないよね、置くよね」って思いました。
（私の勤めてる会社にも置いてある）
【医薬部外品】ミューズ 泡 ハンドソープ オリジナル 本体ボトル 250ml 殺菌 消毒 手洗い 保湿成分配合
- 出版社/メーカー: レキットベンキーザー
- 発売日: 2015/02/22
- メディア: ヘルスケア&ケア用品
- この商品を含むブログを見る
1. scouty 伊藤さん (@tetsuyaito_2)
「合否判断が分かれて気付いた！ 採用要件の明確化がもたらした2つの価値」
トップバッターは最近サービスが正式リリースを果たしました scouty さん。
（今までのってオープンβ版だったんですね）
scouty さんは 3〜4ヶ月前にお話を聞きに行ったばかりで、おもしろい人事制度をしているな〜と感じている企業さんです。
まさにこのイベントタイトルの「Hacking HR!」って会社ですね。
そんな scouty さんで起こったのが、営業を雇うにあたって
メンバー間で判断が分かれたこと。
じゃあどうしたかと言うと、採用基準をもっと明確化しました。
超詳細な採用基準 です。
「なになにをこうやったことある」「こういう環境でこれをやったことある」といったファクトベースに基づいた、
解釈が人によって分かれないような採用基準を、
細かく細かく超詳細に落とし込んだそうです。（その項目リスト見てみたいですね！）
その結果として、採用すべきかの判断にかかる時間を少なくすることができたばかりでなく、
リファーラル（知人採用）がおこなわれやすくなりました。
どういうことかと言うと、採用要件が非常に明確になっているぶん、
「じゃあこういう人が合うんだ」と社員も理解しやすいので、人を連れてきやすくなるということです。
結果、月におこなわれた50件の面談のうち、採用担当由来の面談は13件、
つまり 70% 近い 37 件がリファーラルを元とする面談となったそうです。マジで?! すごい。
なお、scouty さんは採用候補者と社員全員がご飯を囲むのですが、
その際、全社員が書くその人に関する判断のチェックシートも非常に細かく項目があるそうですよ。
2. ナーブ 大野さん
「5回転職し6社で採用に関わって感じた、採用を失敗させる共通要因」
VR系スタートアップのナーブに勤める大野さんが、現在までの経験談を語ってくれました。
ご本人さんによるまとめ記事はこちらです！
やはり多いのが、そもそも離職する組織構造になっている場合。
「とりあえず人が足りないから採用しよ」と採用を走らせたところで、
組織に問題がある場合は底の空いた桶に水を注ぐようなもので徒労。
採用するのであれば、
- 候補者をどうアサインするか決まってるか？
- 候補者が入社の時点でやるタスクは変わらないか？
→ 〇〇という技術が得意な候補者を、〇〇を使う△△プロジェクトに充てようと採用したが、入社時には△△プロジェクトが無くなっていた、というケースがあったらしい……
→ 〇〇をやりたいと思って入ってきた人は当然すぐ辞めてしまうし、悪い噂につながる - タスクが誰かに行きやすいような組織構造になっていないか？（タスクマネジメントが出来ているか）
→ 即戦力と言われたメンバーが必死で数々のタスクを巻き取っていたケースがある
→ よほどの超待遇なら別かもだが、ふつうは高負荷でつぶれて病み、会社に来なくなる
などを確認しましょう。という話をしていました。
いずれも当たり前の話ですが、
「どうアサインするか決まってるか？」は、けっこう見過ごしがちなポイントなので要注意です。
「いま人が足りていないんです、忙しいんです、だから少なくともあと○○人はください」という
現場の声をそのまま人事が受け取って採用すると、
（大方そういう場合タスクマネジメントが機能していないので）結局なぞに忙しいままだったり、ヒマになる人が出たり、
あまり良い結果につながりません。
最終的な解決はそのチームやその上長の手でおこなうとしても、
「○人欲しい」の要望に対してそのまま受け取らずに、
「それはどうして？」「どういうタスクをやってもらうの？」などのヒアリングは
人事として大事な仕事と言えるでしょう。
3. Speee りゅっくさん (@_kei_y_)
「元マーケターが採用で失敗した話」
こちらで記事にしてくださっています。ありがとうございます！
マーケターをやっていたので、つい、数字で見ればいい！ と思って行動したところ、
広告業界と違ってユーザーまでの距離が近いので、相手の個人の人間としての気持ちの動きを見るのが大切 という結論に落ち着いたという話でした。
（例えばエンジニア採用で、人事からスカウトメールを送るよりも、エンジニアからスカウトメールを送るほうが、相手が心を開いて返信しやすいはず、などの心理的部分に着目するのが大事）
スカウトメールを送った際の遷移率（離脱率の逆。何割の人がメールから面接に至ったか、一次から二次に至ったかなどの値）を求め、
そこから募集人数を採用するために必要なスカウトメールを送信し……とやったところ、
質より量になってしまいスカウトメールが低質なテンプレ化。
返信率は下がってしまった、という苦い思い出を話されていました。
一方で、会場からは
「大企業の新卒採用のような母集団がでかい場合には、マーケティング的な発想が効くかもしれない」という案も出ました。
懇親会では、昔、私がエンジニア組織推進室（現在のものづくり組織推進室……ですよね？）の渡邊さんとお会いしていたので、
渡邉さんがプロダクト推進室に異動になり、りゅっくさんが6月にものづくり組織推進室へ異動になるまでの顛末などおもしろく聞かせていただきました。
渡邉さんとの話で、「エンジニアは極論、ネットですべてが完結してしまって会社で働く必要がない。
それならエンジニアに来てほしい会社はどうすればいいか、ネットとの隔たりを出来るだけなくしていく」という思考の元、
社内で勉強会・ミートアップを人事主導で間髪入れず開催したり、
有名なエンジニアと会社で会えるようにしたりなどの施策を意識した。
という話は、1年前の面談での会話ながら今でも印象に残っています。
4. キュービック 森實（もりざね）さん
「組織拡大後に気付いた採用の失敗」
採用コンサルタントとして活躍されている森實さんです。
ITベンチャーにジョインし 30名から 300 名への組織拡大に携わる一方、それにともなう失敗も経験されたそうです。
4-1. 「〇〇さんと働きたい！」戦略の失敗
入社当時の会社は小さく、知名度が低く、給与が高いわけでもなく、採用で勝てる要素が少なかった。
そこで、「ざねさん（森實さん）と働きたい！」と言われるような状態を作り、
候補者の意欲を上げるために、自分の露出を増やしていったそうです。
その目論見は成功したものの、
会社規模が大きくなっていったときに組織がまとまらない問題が出てきました。
- Philosophy：会社の理念
- Profession：仕事内容・プロダクト
- People：人・社風
- Privilege：給与
組織の束ね方の 4P のうち、「この人と働きたい」という個人を推し出す採用の結果、
Philosophy や Profession の部分、つまり会社自体に魅力を感じて働く人が少なかったことに気付いたのです。
会社はその後、理念の浸透のために会社スローガンの作成をしたり、
でもスローガンは結局浸透しないので、社員にテストしたりと迷走したそうです……。
（当然、テストは「軍隊の洗脳みたい」と社員から大不評だった）
4-2. リファーラル意識の薄まり
もともとは 「採用や広報はみんなでやるもの」 という意識が社内にちゃんとあったのですが、
30名だった会社が100名になる頃にはその意識がすっかり無くなり、
現場は「人事がなんとかしてくれる」と思うようになり、リファーラルの文化が消滅（！）
リファーラルプロジェクトを発足させたものの、
マインドセットを取り戻すのには苦労したそうです。
人事だけががんばっていると、思考レベルでみんなから採用意識が無くなっていくので注意。
これ、カヤック社のぜんいん人事部化計画を思い出しますね。
「ぜんいん人事部化計画」「エイプリル採用」カヤックのユニーク人事を支えるたった1つの問い - ログミーBiz
4-3. 「多様な価値観」問題
「多様な価値観を持った人を採用したい」という要望通りに採用していたら、
たしかに良く言えばいろんな人がいる会社になったのだが、
会社のカルチャーは薄まり、組織の結束力が弱くなってしまったという話。
多様な価値観という言葉は聞こえは良いけれど、
「私達は何をしたい集団なのか」の答えとなるような人材を集めることが本当は大切なこと。
だから、「多様な価値観を持った人を採用したい」に対しては下記のような質問に対する
答えを持ち合わせたほうがよい、というお話をされていました。
4-4. 福利厚生訴求採用の失敗
「福利厚生」が並んでるといい会社に見え応募者が増えるので、
職場に猫とかありとあらゆる福利厚生を求人票に書いていたそうです。
しかし、それで応募してくる人は会社に対して
「ホワイトな会社！」というイメージを強く持ち期待値が上がってしまうため、
（実際はベンチャーで土日出社もあるところだった）
少し何かあったときに「ホワイトじゃないんですね……」と裏切られた気持ちにさせてしまうことが起きたそうです。
あまり応募者の期待値を上げすぎてしまう求人票もそれはそれで良くないようです。
（ところで、「ベンチャーだから深夜残業や土日出社は当たり前」みたいに言う会社をたまに見ますが、やっぱ休むときは休んだほうがいいもの作れるんじゃないかなー、と思います個人的には）
4-5. 総括
「応募者を増やす戦術」を考えてしまうと失敗をしてしまう。
「会社がどうなりたいのか」の 戦略を考える人事 が必要だというまとめをされていました。
うちの会社はどこのポジションになっていくのか、競合はどこなのか、
それらの経営戦略を考えて採用に用いていくのが大事。ということでした。
そのためには当然、経営層が関わってくるわけで、
経営層が人事に積極的でないと、採用は成功に至れない という話につながっていくかと思います。
森實さんの講演は濃かったですね。
5. Repro 畑中さん
「口説いたら引かれた ~超えられない壁~」
ラスト！ Repro の畑中さんです。主催などありがとうございます。
登壇資料はこちらです！（GitPitch のシェアURLはディレクトリ指定ができないっぽいので直接Markdownへのリンクです）
創業から２〜３年目、坊主と眼鏡のシニアメンバーばかりだったとき、
業務拡大に伴いコンサルを20名くらい採用する必要が発生しました。
その人数の経験者を採用するのは難しかったのでポテンシャル採用も含めた結果、
今度はその人達をマネジメントするマネージャーが必要となりました。
ここまででちょっと失敗してる気もしますが置いておいて、
今回はそのマネージャー採用に苦労した話です。
なんと驚きの圧倒的辞退率：90％！
これには会場の皆さんから笑いが。
ヒアリングをおこなってみると、大きく理由は5つに大別されるとわかりました。
- ビジネス領域の違い
- 経験したいフェーズの違い
- 年収
- カルチャーアンマッチ
- 家族の理解が得られない
1. 〜 3. はどうにもできないとして、
4. と 5. についてはコントローラブルと考え、改善することにしました。
どうも候補者としては、
- ベンチャー企業は結果が全て→悪かったら即座にひどいことになる
- 土日も当たり前のように働かなくてはいけない
- 妻から同様に「全ての時間が会社に取られる」という認識で、「仕事漬けなのに給料下がるし、ストックオプション本当にもらえるの？」などの嫁ブロック
という誤解があるようで、そこを説明。必要あらば奥さんにも説明。
そうして、採用に至れるよう改善していった、とのことでした。
会場からの質問では「口説き文句は？」というのがあがりました。
「『自分は会社のこういう良いところに惹かれて入社したんですよ』を言うと刺さる可能性が高い」というお答えでした。たしかにそうかも……
6. おわりに
懇親会もとても良かったですね。
採用担当の方が多いからなのか話し上手な方が多く、
非常に楽しい懇親会を過ごすことが出来ました。お食事もいっぱいありましたし。
Schoo の武井さんとお話して、適性分析の分野において
Schoo@me （2017/04設立）が大学との共同研究をしている話の子細を伺ったのは、最高に熱くて燃えましたね。
自分らしさを解析して、誰もが個性を活かせる社会をつくる | SchooMembers
まずベンチャーが R&D （研究開発）の子会社を作るって時点ですでにすごいですからね。
何を出してくれるか期待大です。
そして……
Hacking HR! #3 が 9/25 に開催されます！
ハッシュタグは前回同様 #hackinghrs です。
今回は私としては興味あるテーマではないので参加はしなさそうですが、
今後もぜひとも参加したい、とても良いイベントでした。
人事って最高ですね！
マネジメント半年やったので良かったことと改善すべきこと
エンジニアでありながらもマネジメントポジションを経験させていただき、
だいたい半年が経ちました。
前回のマネジメント関連記事がこちら。
これができて良かったなぁ、と自己満足ながら良かったことを振り返りたいと思います。
Good 1: なんでも情報共有
とにもかくにも情報共有です。
出来る限りこなせたかなと思います。
マネージャーというのはただの役割に過ぎなく、チームは平等なので、
マネージャーだけが知っててチームメンバーが知らない、なんてことはできるだけ作らないのが良いと信じています。明日私が死ぬかもしれないし。
1-1. 朝会の内容まとめを投稿
朝会で各人のタスクをその日のインタビュアーが聞いて、
それをSlackにまとめて投稿する形にしました。
（以前の組織では、各人が順番に発表する形でしたが、私の場合、自分の番が回ってくると頭が真っ白になることがよくあったので、話しやすいインタビュー形式をとりました）
Slackにチームタスクを投稿するのは、周囲からの反応が良かったです。
各チームが何をしているのかわからなくなっていくのは上の人ほど抱える不安なので、Slackにそれが示されているのであれば不安も減ります。
しだいに他のチームでも、Slackに各人のタスクのまとめが投稿されるようになりました。
周りに広がっていったのはとてもうれしかったです。
1-2. 困ったらチームメンバーに相談
採用などの混み入った話も含めて、「今こういうことで迷ってる（困ってる）けど、どうするといいかなぁ」をチームに相談するのは
いろんな良いことがありました。
みんなからアイディアをもらえて私が助かりましたし、
みんなはマネージャーの視点を持つことが出来ます。
お互いに成長の機会を得るので、これは特に続けていきたいです。
1-3. この人はこれが得意だよ、を共有
採用面接で私とは会っているけれど他の人とは会っていない人が入社してきました。
私は、履歴書を読んでるし面接で話してるから、
「この人は〇〇が得意で、〇〇をお願いしたいなあ」と頭にあったのですが、
それは私の頭の中にあるままでした。
チームにその人がジョインしてきたものの、
なんとなく周りとなじめず、また、得意分野でないところで何度か大きな失敗をしました。
で、これ放っとくと「なんであんなの入社してきたの？」だし「入社させたの？」って感情がメンバーに生まれて、
距離が発生したり大きな不満になったりする（→離職）可能性があるんですよね。
そこで、その人と面接したのは私だけだったことを思い出し、
「〇〇さんは〇〇の分野においてスペシャリストだから、そのことでわからないことがあればなんでも聞いてください」と機会を見つけてメンバーに話しました。
これはよかったと、あとになって思いました。
けっこうエンジニアの得意な分野って異なりますから、（特に現在チームの担当分野がフルスタックに近いものですのでなおさら）
どこが得意なのかを宣伝してあげることで、いいリスペクトのある関係性が結果としては生まれてくれました。
採用の理由をちゃんとメンバーに話すのって大事だと思うので、
次はもっと早く伝えるように気を付けようと思います。
Good 2: メンバーを信じられる
ここ成長しました。
以前の記事で、
信じて任せて感謝する
って書いてましたが、書いてた当時これが全く出来なくて悩みでした。
進捗が気になって、いま何をやっているのか頻繁に聞いちゃうんですよ。
なにか困ってることがあるかを尋ねるのは大事だと思うのでバランスなんでしょうけど、前はけっこうそのバランスが悪かったです。
あんまり介入しすぎるとメンバーの成長を阻害してしまうことがあることを意識し、
以前よりはタスクを一任できるようになったかなぁ……と自分としては思います。
元がおせっかい焼きの心配性だから苦戦するところです。
Good 3: 勉強会、輪読会、KPTなどのチームイベント
- 朝会（毎日10分） - 頭の整理・タスク情報の共有
- 勉強会（45分） - 情報収集能力・伝達能力の向上
- 輪読会（45分） - 知識習得
- タスク振り返り・洗い出し会（30分） - 振り返り・タスク状況の確認
- KPT会（30分） - 振り返り・称賛・改善
といったおおよそ一般的な取り組みが、安定して出来るようになってきているのがとてもいいです。
KPT会から始まり、少しずつ増やすことが出来ました。
勉強会は技術関係なしでもいいことにしていますが、それでもやっぱり登壇者不足しがちです。難しい。
あとは、「なんだか最近仕事ばかりしてるな」と個人的に感じたときに、
不定期で「チームビルディング」と称してボードゲーム会を就業時間内に2時間くらいやっています。
チームで一緒に遊ぶ思い出づくりは、日頃のチームワークに良い影響が与えられると信じています。
今は2ヶ月に1回くらいですが、1ヶ月に1回くらいの定期イベントにしてもいいかなと思っています。（でもどこにも確認取らず就業時間中にやってるので、誰かに怒られるのではとビクビク）
Good 4: 1 on 1 が少しわかってきた
以前の記事を書いた少し後くらいに、
『ヤフーの1on1』という本が良いよと、元Yahoo!の笹子さん（日本エンブレース）に教えてもらって読んだら、すごくためになりました。
まだまだ出来ているとは言えませんが、1 on 1 にどのように取り組めばいいのかわかって、以前よりは行いやすくなっています。勧めてもらってとても感謝しています。
とは言えしっかり実践できているとまだ感じられませんので、繰り返し読むことが大事だと思います。
Good 5: 納得できないことは交渉する
1度だけ納得出来ないことがチームに要求されたことがありました。
そもそも入社時の労働条件にはないことでしたから、それを強要されるなら私だったら会社辞めるな……ということなので、
これについてはチーム会議を開いて全員の納得できるラインを聞き、労務方面と対価など交渉しました。
その結果、当時のチームメンバーの妥協ラインはなんとか押さえられる物になってよかったです。
この部分ができるのってチームマネージャーなので、
いくら会社としてやらなくていけないことであっても、労働に直接響くところの変更を
チームの合意無しで進めるようなことは絶対におこなわないように今後もしなければと思いました。
1回決まったことはそのまま続いていって、全員が苦しむことになりますからね……。
Bad 1: まだ面接が苦手
面接が上手く出来ている気がしません。
相手の本質とか技術力を測ることが全然出来ていないんじゃないかなぁ、と私としては思います。
あと、わりと緩めに通してしまう傾向があります。
採用はリスクマネジメントってこの本に書かれていますから、
もっと慎重になるべきなんですけどね。
会社の仕組みとして一次面接が人事で二次面接がチーム、という形だったんですが、
一次面接に出席させてもらうようにして、
人事の横で上手い面接を学びやすく、かつ、面接に参加する回数を増やせるようにしたのですが、まだまだですね……。
上手なエンジニア採用面接をどうやったら学べるのかもわかっていなければ、
どうやったら上手くなったと言えるのかの分析もわからなくて、
ここは今後も苦しみそうです。
Bad 2: マネジメントしてるようでしてない
なんだか最近チームが上手くまとまっちゃって、
チームメンバーも自分で考えて動いてくれる人が多いので、
最近はそこまでマネジメントがんばってる感はないんですよね。
良くない兆候（タスクの粒度が大きくなってしまっている傾向や、他のチームとの絡みが少なくなっているなど）があったらKPTで提案して微小な軌道修正はしていますが。
安定してるのは良いこととも言えるのかもしれませんが、
なんだか何か大事な欠点を見落としているのではないかとも不安になる日々です。
それはそれとして、面接と 1 on 1 はまだ上手くできてる実感がないので学んでいかないとですね。
Bad 3: タスク管理の最適解とは
「これが最高」がないのがつらいところです。
今はホワイトボードで物理カンバン管理をしているのですが、
これは利点も多くて、すぐ目の前に自分の Doing が見えるので自分が何をしなきゃなのかすぐ思い出せる。
タスクの追加がおこないやすいし、追加されるときはみんなの目に留まる。
ToDo や Doing がいっぱいになってることがひと目でわかるので、タスクの洪水を防ぐ危機管理が行いやすい。
他のチームの人も、通りかかるとホワイトボードが見えて「こんなことやってるんだ」がわかりやすい。
などなど、いいところがある一方、
会社の外にいると見られない。
詳細は書きにくい。（付箋のスペース的に）
Done をオンラインログに残すために転記が必要。
などのネットでないゆえの問題もあります。
これらの解決法として、
大型ディスプレイを置いてそこに常時 Trello や Wrike などのボードを表示しておくという手法があるのではとも思いますが、
コストが張る問題や、それを表示するためのマシンはどうするの、などの問題が……。
同じ課題を抱えていたのか、Google が Jamboard という電子ホワイトボードを作ったのは大変おもしろいなと思います。
しかしお値段なんと64万円と、これもやっぱりコストが・・・(笑)
Googleのスマートホワイトボード「Jamboard」がついに発売、どんなことができるのかが一発で分かる新ムービーも公開 - GIGAZINE
私達は理想的なタスク管理手法を手に入れることができるのでしょうか……。
おわりに
幸いにも「良いチームだ」とメンバーから言ってもらえていてありがたいことですが、
じゃあ逆に「悪いチームだ」とメンバーが直接 1 on 1 で言ってきてくれるかと言えば、必ずしもそうとも思えないので、
どうすれば悪くなるかを引き続き考えて注意しながら、
気を緩めず進行していければと思います。
エンジニアマネージャーは、
マネジメントの勉強をしつつ、
社内全体の変化に過敏であり、
チームがつらい状況になっていってないか気にし、
チームメンバー個々人が成長できる機会を得られているか気にし、
かつ自分自身がエンジニアとして錆びつかないよう家での学習も欠かさない、
と、書き並べてみるとやること多くておぞましいし、実際、全然全部はできていないですが、
バランスよくこなしていけるようになりたいと思います。自分としては楽しいです。
おしまい！
エンジニアマネージャーに必要なことってなんだろう？
最近、ありがたいことにチームリーダーをやらせてもらっているのですが、
経験が無いのでどうすればいいのか手探りでやっています。
今後どうしていけばいいのか、
今の時点で得られていることを頭の整理としてまとめておきたいと思います。
インプットを続ける
エンジニアに大切なことは技術力の向上ですが、
マネージャーはそれにプラスしてマネージング力の向上を続けていかなければなりません。
そのためには人事、経理、組織論について、本やネット記事を読むだとか、
職場の他のマネージャー、他社のマネージャーに話を伺いに行き、手法を学び続ける必要があります。
そうしないと自己流が出来上がってしまい、「自分は上手くやれてるはずなのに」と、しだいに頭の固い人間になってしまいます。
上手くやれてるつもりになるのが一番危ないです。
どうすればチームがダメになるのかを知る
いくつか手段があると思います。
- 経験する
- 聞く・読む
- チームメンバーの性格を把握する
1 はつまり自分や自分の所属するグループが崩壊をすることです。
自分の経験なので記憶に強く残りますから、同じ失敗はしにくくなります。
問題点はそんなに何回もチームの崩壊を経験できないことです(笑)
ということで、2 の、人から聞いたり記事を読むことになるわけです。
他社の「こんな状況からこう正常化させた」という記事から、逆説的に、ダメな状況がどういうものかを学べます。
3 は上記とは別軸の話です。
一般論としての 1, 2 ではなく、現在のチームの特性としての 3 です。
個人のやる気を下げる要因がなんなのか知ることは、チーム崩壊を起こさないために大事なことです。
何がイヤなことであるか直接聞いたり、現在の職場で気になりつつあることを聞いたり、前の職場を辞めた原因はなんなのか聞いたり。
1 on 1 や普段の会話で、個人個人のNGポイントを集めておきましょう。
上司が何を欲しているか知る・予見する
これはマネージャーに限らず大切なことですが、
上司が何を欲しているか予見して動くことは非常に大切です。
マネージャーの上司はマネージャーです。
チームマネージャーはメンバーの行動や未来を考えますが、その上司のマネージャーは
「チームが何をしているか」「チームがこれからどうしたいか」などを気にしています。
チームの四半期目標だったり、1 on 1 の結果報告だったり、チームが達成したことの週次報告（月次報告）だったり、
チームの状況を知るために必要なことは聞かれる前に上げていくくらいにしましょう。
あなたがチームリーダーとして上司からの信頼を得られることは、
チームが好きに動きやすくなれることにもつながります。大事なことです。
自分が頭いいと思わない
自分の頭がいいと思ってしまうと、あらゆることを自分でやろうとしてしまいます。
それはスケジュール的に自分の首を絞めてしまうばかりでなく、
結局のところ自分が気付いていないだけで他の人のほうが上手くやれることだったりして、
周りの反感を知らず知らずに買っていたりします。
周りの人間を信じましょう。
その人は失敗するかもしれませんが、失敗から学ぶこともあります。
子どもが怪我をしないように公園で遊ばせない親がいい親とは言えません。
（ただし大怪我に気付けるよう、公園のベンチから様子を確認してはおきましょうね？）
メンバーの成果は褒め称える
何かしてもらったら「ありがとう」と言うべきですし、
良い成果を上げたのなら「ナイス！」と伝えるべきです。
信じて任せて感謝する。
聞いた話だとこれがけっこう難しいらしいです。
信じられて任せられて感謝されたら、誰もが気持ちよく働けるでしょう。
メンバーの市場価値を高める
エンジニアはひとつの会社には留まりません。常に新しい環境を求める生き物です。
そのとき――チームメンバーの転職――は必ずやってきます。
それは他の会社に嫁（婿）に出すようなものだと私は思っています。
ですので、親の立場となるマネージャーがそのときまでにすることは、
「どこに嫁（婿）に出しても恥ずかしくない人間にする」ことだと私は思っています。
そのために必要なことは、会社でいろいろなことを経験させること、そしてそのおこなったことを説明できる能力を身に付けさせることです。
面接で絶対に聞かれることは「前職でおこなってきたこと」です。
ここの説得力は面接の結果を左右します。
- いろいろな業務を経験させる
- その業務で何をしたのか、何を工夫したのか、チームの振り返り会や 1 on 1 で振り返らせる
- プレゼンテーション能力を向上させる（社内勉強会の開催など）
- 社外へのアウトプット（勉強会での登壇やブログなど）を勧める
これらのことを継続的におこなうと、メンバーの市場価値は上がっていくのではないでしょうか？
このことによって会社の利益が出るとかはないでしょうが、続けていけば何かいいことがある……はず？ ……たぶん。
夢を持つ
自分がすごく苦手なところなんですが、夢を持つのは大切だと思います。
チームメンバーに将来どのようになりたいのか聞いてキャリアプランを設計すべき人が、将来どうなりたいのかを持っていないってのは意味がわかりませんし、
そんな人にはメンバーも正直に夢を語ってはくれないでしょう。
夢って、難しいですね……うーん、自分は将来何をしたいんだろう。
『夢をかなえよう』って曲の主人公並みに夢について考えちゃうぞ。
これは現在の自分が特に出来ていない課題です……。
1 on 1 で何を話せばいいのか？
今までのことの総まとめになります。
- 最近会社で気がかりなこと（嫌なこと）はないかの確認
- 直近の業務で何をしたのかの振り返り
- 次にどういう業務をやってみたいかヒアリング
- 会社に欲しいもの、導入したいツール
- 短期的・長期的な個人目標
など、エンジニアマネージャーとしてチームを回していく上で必要な情報の収集をおこないます。
基本は気軽に雑談をすればいいと思いますが、
こういった、チームを回していく上で必要な情報を得られていないのなら、
1 on 1 の機会を利用して積極的に情報収集をしていくべきでしょう。
【追記】1 on 1 についてより掘り下げた記事を書きました！
おわりに
以上が、現時点で考えるエンジニアマネージャーとして必要なことです。
考えたり経験したり、読んだり聞いたりして情報を集めてはいますが、
いかんせんまだリーダー経験としては2ヶ月なので、圧倒的に経験不足！！
足りないところや間違いなどがあり、数ヶ月経ったら更新したくなりそうですが、
今の時点で一度、得たことを振り返っておきたかったのでまとめました。
まだマネージャー職という自覚がなくて、
「メンバーのタスク状況の確認とか文章書いたりでコードあまり書いてないし、重たい実装タスクはメンバーに任せてるし、私って仕事してないのでは？！」
と思う日々が続いています。
同業の人に相談したら、「いや、コードはあまり書かなくなるものだよ、それでいいんだよ」と言われましたが、
突然リーダーになってしまいコードを書くことが仕事という考えから抜けられない私はまだ戸惑っています。
慣れるかな・・・？
最後に、最近読んでよかった本をアフィリエイトとしてぺたりとー。
自分やチームメンバーが今なにが出来て、次はなにを出来るようになればいいかを考えることができる良書でした。
人事の超プロが明かす評価基準―――「できる人」と「認められる人」はどこが違うのか (三笠書房 電子書籍)
- 作者: 西尾太
- 出版社/メーカー: 三笠書房
- 発売日: 2017/03/07
- メディア: Kindle版
- この商品を含むブログを見る
