エンジニアのマネジメントをやりたいと思いませんか

この記事は ウェブクルー Advent Calendar 2018の　３日目の記事です。
昨日は@haruka_kouyamaさんの「UX視点で新規事業アイデアを発想するブレスト手法」でした。

はじめに

私はスーパーなマネージャーでもなければ、エレガントなエンジニアでもありませんが、
少なくともマネジメントに真面目に取り組んでいる者です。
急にボールが回って来た Advent Calendar 2018 への寄稿ですが、こんなことをちょっとだけ体系立てて書かせていただこうと思います。

• 一開発チームのリーダーになってから今のマネージャー職まで駆け足3年の間で、マネジメントについて学んだこと
• 社外のCEOやCTO、マネージャーの方々とお話しさせていただいて気づいたこと
• マネジメントをやる前と後で考え方が変わったこと
• 今だに答えが出ずに悩んでいる課題

そして、一人でも多くのエンジニアに、マネジメントについて興味を持ってもらい、
マネジメント職に就きたいと思ってもらいたいと願っています。
毎日一緒に仕事を頑張ってくれている同僚エンジニアに向けたメッセージであったりもします（笑）。
よろしくお願いします。

エンジニアのマネージャーって何をやるのか

エンジニアのマネジメント職に付いている肩書きや呼び方も色々あったり、役割も業態や会社によって違いますが、世間一般的には、エンジニアのマネージャーがどういったことを求められているのか、色んな企業の「求人情報」から調べてみました。

・組織の環境改善

・エンジニアの目標管理・評価
・エンジニアの採用
・エンジニアの育成やメンタリング、キャリア形成
・組織課題を見つけ障壁を取り除く
・組織の成長を支える制度設計
・関係部署との調整、運用
・プロジェクトへのエンジニアアサイン
・チームの方針決定
・プロジェクトマネジメント
・オフショアや外注のコントロール
・技術面以外も含めたあらゆる問題解決
・他部署・他業種・事業リーダー・経営陣との調整
・勉強会の運営
・1on1などでメンバー個人と向き合う
・開発体制の安定化
・コミュニケーションの仕組みづくり
・開発プロセスの改善や環境整備
・テクニカルディレクション
・IT戦略の立案と遂行
・新規サービス立ち上げの絵を描ける人

などなど、いろんな会社でマネージャーに求めたいとされる役割の抜粋ですが、中にはCTO、VPoE、VPoPの範囲と重なると思われる部分もありますね。とても参考になります。

私なりに考えた、マネージャーが果たすべき役割は、
一言でいうと、
「持続的に成果を出し続けることができるエンジニア組織を作ること」
と捉えています（今のところ）。
「持続的に」と言うところがミソですね。

そのための具体的なマネージャーの活動として、
今回は、大きく４つくらいに分類して、私の学んだことなどを書きます。
１．エンジニアの目標設定・評価
２．エンジニアの採用
３．エンジニアの育成
４．組織の環境改善

１.　エンジニアの目標設定・評価

これはマネージャーにとって、とても業務比重が大きく、また責任が重い仕事です。想像していた以上でした。
エンジニアに限らず、人を評価する、と言うことは、その人の生活や将来を左右するものと言っても過言ではありません。
「人が人を評価する」という、そんなある種、神の領域でもあることを、あえて会社組織で必要なことであるならば、誠意と謙虚さを持って評価しようと、自分に言い聞かせています。

目標設定・評価で重要と考えること

• 誰が評価しても同じ評価になるような目標設計と評価基準を目指したい
• そのためになるべく定量的な目標設定にしたい
• 全てを数値化して評価することは、エンジニアという職種では本質からズレることもしばしばあるので、定性的な目標設定も取り入れる
• 定性的な目標は評価が難しいので、期初に評価基準をメンバー本人と時間をかけてすり合わせる
• マネージャーにとって、メンバーの目標設定は、会社や組織の方針に沿うようにメンバーに促す唯一かつ最重要な手段
• 評価者は毎日が勝負。期末の成果や状態だけで評価してはいけない
• 給与アップは投資、成果に対しての清算は賞与、という視点を持つ

２.　エンジニアの採用

昨今、とても難しいのがエンジニアの採用です。拡大フェーズの企業であれば、マネージャーの仕事の大半が採用に関わることもあるようです。
たくさんの方がおっしゃているように、採用は本当に、「ご縁」 と 「タイミング」 だと思います。

採用で重要と考えること

• 面接はコミュニケーションをとって相互理解を図る場であり、選考してふるい落す場、いい人を見つけ出す場、という考え方ではない
• １時間の面接で聞くことができることはわずかであり、志望者に多くの時間を話してもらうよう配慮する
• 面接の質を上げるために、事前にできる限り応募者のイメージを膨らませておく（経験、どういった思いで転職活動をされているか、etc）
• スケジュール調整や質問へ回答するスムーズさ
• 胸を張って「我が社に来てください」とオファーするためには、それだけの環境を社内に作る必要がある
• 一緒に働くエンジニアとの相性を見極める
• 志望者が一年後、どのような成果を残しているかを妄想する

３. エンジニアの育成

個人の学習や勉強会の開催、外部セミナーへの参加は当然支援していく（邪魔しない）として、
大企業であれば、じっくり教育して成長させていくことも出来るかもしれませんが、
我々規模の事業会社であれば、いかに早く成長していってもらうか、がとても重要と考えます。

育成を加速させるために重要と考えること

• 会社としてやるべきことと、エンジニア本人の成長につながることをいかにマッチさせるかに時間を費やす
• メンバーにセルフスターターになってもらう動機付け
• 隣のエンジニアの仕事や、上司の仕事を自ら奪っていくイメージを持ってもらう
• エンジニアとしてビジネスサイドと対等に接することができるような調整や後ろ盾

4. 組織の環境改善

環境面や組織課題はいろんな観点がありますが、
ここでは、心理的安全性　と 1on1 について書かせていただきます。

心理的安全性への考え方

• これがないと、エンジニアの成果は確実に落ちると見ている
• 心理的安全性が確保されてはいるが、裁量と責任が伴っていなければ、単なるぬるま湯であるわけで、
  裁量と責任もあり、かつ心理的安全性が確保されている環境が必要となる
• 賞賛しあえる関係性だったり、ちょいズルくらいは笑って認めてあげるくらいの環境は作りたい
• いろんなバックグラウンドを持ったエンジニアが集まっていて、得意なことも不得意なことも十人十色なわけで、
  それを認めて、いかに会社組織の成果につなげてあげるか、という心がけがマネージャーには必要
• ないがしろにされがちなのが、マネージャー自身の心理的安全性
• メンバーの心理的安全性が保たれ、マネージャーにそれがない状況は、過保護パターンというらしい

1on1への考え方

• 悩みや不満、不安に思っていることをカジュアルに言える場として必要
• 遠慮して言ってもらえていないこともまだまだあると感じているので 「傾聴力７、質問力２、雑談力１」 なコミュニケーション力を身に付けたい
• 質問力Upは難易度高く、うまく聞き出す力、本当に言いたいことを導き出す力は常に磨きたい
• メンバーが障害を発生させた時や、ミスした時に派手に騒ぎ立てるのではなく、メンバーが素晴らしい成果を残した時や成功した時に賞賛してあげる
• １on1 を実施することで、次の1on1までの生産性を上げることを目指したい

最後に

足掛け３年ほどマネジメントに携わって、今になって強く思うことがあります。

まず、マネージャーはマネージャーが果たすべき仕事にもっと集中すべき。
どうしてもプログラムが書きたくなるし、どこか面白そうなプロジェクトに入りたい気持ちにもなりますが、
エンジニアのマネージャーの期待される役割はそこではなく、もっと組織全体が幸せになることに注力すべきだと感じます。エンジニアとして自分がそれまでに持っていた仕事やナレッジはどんどん後進のエンジニアに移譲して行くことが、組織全体としては健全に作用するのは明白だと実感しています。なかなかこれが出来そうで出来ないんですけどね。コードを書かない後ろめたさとか、そういう余計な心情に苛まれるのはグッと我慢したいです。それから、マネージャーになった瞬間、自分に替わる次のマネージャーを育てる、くらいでちょうどいいと思いますね。

もう一つは、エンジニア達に「マネージャーになりたい」と思わせるような存在にならないといけないです。
「物を作る」ことの面白さの方を知ってしまっている以上、エンジニアにとってマネジメントがそこまで魅力的な仕事、ポジションには映らないですよね。
実際に楽しそうには見えないかもしれませんし、色んな人から色んなことを言われて疲弊している、と見られているのかもしれません。
マネージャーよりプログラマの方がお給料が高くなる時代もそう遠くはないかもしれませんし、
身近に尊敬できるマネージャーがいないことも、やりたくない大きな理由でしょう。
マネージャーになりたい、マネジメントをやりたい、と思ってくれるエンジニアを増やすことが、結果として、「持続的に成果を出し続けることができるエンジニア組織を作ること」 につながるはずと。

ありがとうございました。

明日は @wc_omuroさんです。
よろしくお願いします。