Engineering Manager vol.2 Advent Calendar 2019 の 16日目、12/16（月）の記事です。

簡単に私のことを説明すると

デジタルサイネージを作るチームを0から立ち上げた（開発開始から2ヵ月でリリース済み）
現在は Engineering Manager, 開発責任者, Product Manager など、様々な呼ばれ方をしている
役割は技術調査・設計についての壁打ち相手になる・開発項目を決める・スケジュールを決める・実装・協力会社とのやり取り・採用・開発チームをよくしていくこと
が主な役割・やってきたことになります。

今回はそのうちの、Engineering Manager(em）について書きます。
これは現在のプロジェクトを立ち上げる前の自分に贈るクリスマスプレゼントみたいなものです。

そもそも何を実現するためemなのか

emにも人それぞれスタンスやポリシーがありますが、
まず
社会のエコシステムに属しているので、経済活動が成り立つこと
を前提としています。（R&Dなチームも含む）

それを細かく分けていくと

役に立つプロダクトを作り、それが人々のためになる（価値提供）
お金になって
チームを潤す
継続的に価値提供できる体制・仕組みを作り
継続的にメンバーを幸福にする
結果、メンバーのやる気が出る
-> そして新たな価値提供をする(1 に戻る)
このサイクルを作ることがチームとして実現したいこと。
このように分解してみると、このうちemが主に関わるのが4, 5, 6になります。
それを一言で表すと メンバーの成長をイノベーションに変換していくこと がemの役割になります。

メンバーの成長とプロダクトの価値提供

ではどうやって メンバーの成長をイノベーションに変換していく ことができるのでしょうか。
プロダクトの価値だけにフォーカスしがちですが、
それだけだと メンバーを使い捨てる という行為を排除することができません。
それはゆくゆくは首を締めることに繋がり、組織の継続的な成長を実現できません。
メンバーの成長 をミッションに加えていない組織は、 目の前の事業の成功にしか注目しない ので
結果、 新規獲得にしか興味がない組織 になっていきます。

それでは当然、人は離れていきます。そして組織にナレッジがたまりづらく、
なかなか組織力が上がらない組織になっていきます。
また、 使い捨て が蔓延している組織で働いて幸せでしょうか？
使い捨てる のも 使い捨てられる のも未来を感じませんよね。
それどころか実利という意味でも、テンションが下がって何もいいことはありません。
使い捨て な組織でイノベーションは生まれるのでしょうか？
それらの理由から、 メンバーの成長 をミッションに加えることが、マネジメントをする立場にとっては重要だと感じています。
いろいろ書きましたが、そもそも メンバーの成長 を大切にした方が楽しいですからね。

やりがいをどうやって引き出すか

目標というと、ついつい評価期間（弊社では半期ごと）に設定しがちですが、
本当の意味でのやりがいは半期ごとの コミット目標 ではなかなかやりがいに繋がりません。
もちろんたまたま やりたいこと ≒ 組織としてコミットしてもらって嬉しいこと になっていれば合うのでしょうが、
評価期間に合わせてやりたいことがぴったりハマる というのは経験上、あまり多く有りませんでした。
そこでもう少し長く、1年・2年・・・ゆくゆくは・・・くらいの期間で どんな自分になっていたいか を設定したところ
やはり朧げながらも 〇〇なメンバーになりたい □□を作れるようになりたい という願望が出てきます。

これをメンバーと一緒に考えながら、その実現に向けてコミットしていくことが大切。
emとして最大限コミットをすることで、やりがい・チームへの貢献度が上がっていきました。

emがするコミットとは

それではemとして、どのようなコミットをすればいいのでしょうか。
普段コミットしていることと、その理由についてお話しします。

メンバー一人一人と向き合う

週1で なりたい自分 いまやりたいこと 実現したいこと のイメージを確認する
なりたい自分 のイメージを一緒になって膨らます
規定外のことを言われても、まずは受け止めて何ができるか考え、一緒になって行動する
メンバーの良かった点、 〇〇ができれば更に良かった という点を伝える
なりたい自分 に合うようなタスクにアサインしていく

頻繁に面談を行い、メンバーの見ている方向を認識します。
しっかり何を思っているのかを認識しないと力を引き出せないからです。
前回の面談から本人がした行動のうち、

どんな振る舞いがチームとして良かったのか
これを意識できると更にチームとして嬉しいのか

を伝えます。
そしてチームとして何が必要なのかを伝え、本人の希望にあったタスクに合わせていく。
こうすることで本人の力を最大限チームへの貢献に変えることができます。
向いてる方向が違うと徒労に終わりますし、メンバーの価値提供という意味でもその価値が薄まってしまいます。
一人一人と向き合うことで、メンバーの力を最大限価値提供に変えていくことができます。

外的要因によるチームへの影響をコントロールする

少しでも組織が大きくなると、当然複数のチームが存在します。
そうすると全体最適が始まり、逆に個々のチームのパフォーマンスが落ちる事象も発生します。
ある程度は仕方ないですが、

メンバーのテンションに関わるもの
効率に関わるもの

についてはしっかり議論する必要があります。
外部から組織変化を発生させている方達は、色んな意味で 良かれと思って やっているケースがほとんどなため、
ノールックで通すことはせず、
影響を把握する必要があります。

チーム外からの影響も、必ず背景があります。
一見テンションが下がるような話でも、議論しメンバーが納得することで
むしろ組織に貢献しよう という雰囲気になることもよくあります。
そういう意味でも、外からの影響はしっかり把握・対応した方がいいですね。

技術的チャレンジを応援する

OSSへの貢献
趣味や副業への応援

上記は一見して仕事へのコミットが薄まる気がしますよね。
でも実はポイントを抑えればコミットが薄まるどころかプラスになることが多いです。
ある意味、チームの仕事以外で自ら成長してくれる ということなので、うまくワークすれば本人・チームにとってかなり良い影響になります。
ではポイントとは何でしょうか。
それは しっかりパフォーマンスを計測する こと。
そもそも在籍している以上、 チームへ貢献しなくてはまずい と誰でも思います。
メンバーがやったことを把握し、それを評価につなげていく。
裁量労働制なので、ちゃんと貢献できていれば他でどんな過ごし方をしていても問題ないはずです。
チームへの貢献を把握する ことができていないからマネジメント職は不安になって制限するのですよね。
不安にならず、どんな貢献をしたのかしっかり把握すれば、ほとんどの場合問題になりません。

上下関係がないと徹底する

技術的なバラツキやこれまでの経験の違いから、
どうしても技術的な能力差は発生します。
技術的に優れている人はどうしても天狗になりがちで、
丁寧でないコミュニケーションを取る方は、それ以外の方を萎縮させてしまいます。
xx Manager という役割も当然 ただの役割 で、
偉くなったと錯覚すると、途端にツマラナイ組織になります。

丁寧でないコミュニケーションを取る方が居て、そんな人とプロダクトの未来について語り合えるでしょうか。
技術的な議論が活性化するでしょうか。
そんなことはありませんよね。
乱暴なコミュニケーションはチームへ悪影響を及ぼすので、 上下関係はない と徹底することが重要です。
上下関係のない世界は活発な議論と成長を促すため、これもチームにいい影響を与えます。

本当にやるべきことだけをmustなタスクにする

ビジネスを深く理解し、やるべきことを色濃く抽出。
やるべきことにフォーカスして開発すると、 期限に追われ、ピリピリした雰囲気になる確率 を下げることができます。
ピリピリした雰囲気がなくなり、安心して開発できるようになると、逆にメンバーのテンションが上がって効率が上がったり
メンバーが成長しやすくなります。
mustなタスクが終わっていれば、 あったらいいな的なタスク も実装するので、結局早く実装できます。
mustとwantをきっちり分ける。
それはビジネスを理解しないとできませんし、システムの方向性を描くからこそ、できることです。

運用にかける時間を最小化する

手運用やdbにinsertしないとできないもの。運用にどれくらい時間を割いていますか？
エンジニアのみならず、ビジネス職も同様ですが、
判断が不要（または条件分岐で終わる程度）のものに人の時間を使ってた ら、そこは改善できるポイント。
無駄に人の時間を使う=イノベーションに使える時間を奪う のと同義なので、
手運用が発生しているところがあったらそこから優先して潰しましょう。
また、そういうことが発生しないシステム設計にしましょう。

まとめ

チームをよくしていく手法は、あくまで手法であって正解とは限りません。
チームの状態、メンバー構成、取り組むプロダクトによって効果的な手法は異なります。
では何が本質なのでしょうか。
大切なのはメンバーと向き合うこと。メンバーの一番の理解者になるよう努力し、職場はもちろん職場以外も含めて応援すること。
マネージャーという立場は、ただ管理するだけでなくメンバーの力をプロダクトに活かしていく役割ですから、まずは向き合うことが重要です。

成長しない組織に未来はなく、楽しくもありません。
私にとってEngineering Managerという役割は、
メンバーの好奇心をイノベーションに変えていくこと が一番のミッションだと考えています。
イノベーションが全くない二番煎じのプロダクトならいいでしょう。
しかしほとんどの場合、プロダクト固有の 新規性を獲得する領域 は必ずありますし、
それを軽視するプロダクトはやがて抜かれ、沈没していきます。

メンバーを大切にしてますか？
対話してますか？
せっかく使わせてもらっているメンバーの時間（人生）を最大限活かせてますか？
イノベーションが発生するような組織になってますか？

どうせマネージャーをやるなら、メンバーが楽しく過ごせてイノベーションを起こせる組織にしていきたいですね。

お約束

随時採用していますので、
上記のようなチームで成長したい方、新しいものを作ってみたい方は採用ページをご覧ください。
https://www.cyberagent.co.jp/careers/professional/
https://www.cyberagent.co.jp/careers/students/tech/
https://www.cyberagent.co.jp/careers/students/designer/
https://www.cyberagent.co.jp/careers/students/biz/