2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。
ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1
マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2
というかこれは個人の日記ですよ〜。（ここまで防衛線）
マネジャーになった背景 / 当初の役割
記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということで各オフィスに各専門性ごとのマネジャーを立てることになりました。
それからしばらくして東京オフィスのWebエンジニアが約20名になる頃、さすがにマネジャー1人では負担が大きすぎるために分担することになり、その時点ですでに相対的に古株でもあった自分にもやってくれないかと打診がありました。
Quipperはスキルも自走力もあるエンジニアに絞って採用しているから人のマネジメント*3はさほど要らないはず。しかし評価制度を導入したからには評価を行い、説明責任を果たすロールが必要
引用風に書いたけどなんの引用でもなく、そのような説明を受けたな〜と。
Quipperのエンジニアリングチームがピラミッド組織化していくことや、（世間一般で語られるような負の意味合いでの）マネジャーロールを誰かに押し付けることには僕も不安を抱いていたのですが、責任範囲をだいぶ限定したマネジャーなら必要性を十分理解できるし、やってもいいかなと納得し、やってみることにしました。*4
それから1年ぐらいの"無"と"失策"
当時のメンバーや、もしかすると今の同僚が聞いたらいろいろ怒ってしまうかもしれないのですが、「マネジャーの立場にいながら"最低限のこと以外 何もしない"ということが、これまで通りのフラットかつ自律的なエンジニアチームの持続に寄与するのではないか」と考えていました*5。当時の同僚やチームメンバーも、もともとマネジメントを期待していたわけではなかった…と思っていました。
結論から言うとこれは誤りだった。そう、今は思います。
チームや組織も運用する中で生じた課題に優先度を付けて解決していかないとどこかへの負担や歪みが大きくなっていくこと*6、無策でフラットさに固執しても個人の情報処理能力には限界があるのでスケールしないことがわかってきました。
失敗から学んだこと
特に最初の1年の失敗と学びが無限にあって辛いのですが、いま2年半前に戻って過去の自分に何か言えるなら「以下の3つは徹底しろ」と言う。かもしれません。
- 課題の発見と優先度付け
- 情報の制御
- 期待のアラインメント
いや、本当はもっとたくさんあるんですが。
あと言わずもがなですが、上記がどの会社のどの環境のエンジニアリングマネジャーにも有効というわけではないと思っています。
1. 課題の発見と優先度付け
大抵の場合、組織課題はまず表象のみが観測されます。なんか開発のスピードが出ない、チームの雰囲気が悪い、他部署とのコミュニケーションがうまくいかない…。
そんな中で負の感情が醸成されると他部署や自分より上のレイヤーなどに向き先がいくことがありがちですが、そうした責任を分散させることで解決する課題や新たに見いだされる価値はほとんどありませんでした。
それを横目に見つつ放置していたのが1年目の失敗です。
本当に向き合う問題はなんなのか。そしてそれは今解くべき問題なのか。真因の発見と解くべき問の優先度付けをきちんとやっていく。そのように組織課題の解決に向かって計画・実行するロールがないと、安易に対立構造に持ち込まれたり、永遠に解決されないまま放置されたりするような課題が、数十〜数百名規模の会社ではあるとわかりました。
その動きをお手本のように見せてくれたのがかつてのVP of Productでした。今でもめちゃめちゃ尊敬しており、「彼ならどういうふうに行動するか」と考えて行動したりもしました。
2. 情報の制御
情報の制御と言うとたいてい"情報の透明性の毀損*7"だとか"階層型組織寄りの統制"だとかネガティブに捉えられがちですが、チームメンバーが特定の物事や成果達成に集中できるような環境を作ることを意図します。
本当にフラットですべてうまくいくならチームの人数が何人であってもよいし、チームが担当する領域がどれだけ広がってもよいことになるけど現実はそうではない。人数の閾値を超えるチームはコミュニケーションコストが高くなり、担当範囲が広すぎるとスイッチングコストが増大し、個々がすべての情報を処理しきれなくなります。
上述のように他人に責任を求めたりする原因の一端には、個々が処理できないほどの情報が組織内に流れている、というのがあると思います。
これを気付かせてくれたのはG.M.ワインバーグ先生の本にある以下の一節でした（うろ覚え）。
マネジャーは情報の流れを制御する力を持つ… この力を適切に扱う必要がある…
- 作者:G.M. ワインバーグ
- 発売日: 1991/10/01
- メディア: 単行本
タイトルはアレですし約30年前の本ですがめちゃめちゃ学びがありました。というかマネジメント、人間学って数百年の研究がすでにあるので古典から学ぶことがかなり多い分野なんですよね。
僕個人の失敗としては、企画メンバーから「まだ確定してないけどやりたいことがあるのでマネジャーに相談してみよう」みたいに話しかけられることも多かったのですが「伝言ゲームで齟齬を生みたくないからメンバーを集めて話してほしい」と返してしまい。すると多くの情報が全員にインプットされたのは良いけど情報の繋がりがわからないとか、アップデートのたびに共有受けていては開発の時間がなくなるとか…。
そうした失敗もあり、どの情報が誰にどのタイミングで渡ると価値が最大化するのかを強く意識するようになり、必要に応じて人・情報・チームを繋ぐことができるようになってきました（たぶん）。
また、個人やチームのスコープを可能な限り局所化する努力にも繋がりました。実際にはエンジニアだけでなく周辺組織と合わせてチームを編成する必要がありなかなか苦戦し続けたところでしたが…。
3. 期待のアラインメント
情報の制御とも関わるのですが、「何を達成してほしいか」、メンバーへの期待値をきちんと伝えることでメンバーがどの範囲の情報をキャッチアップすれば良いかの自律的な判断を促せます*8。理論的には…ね…。期待値を伝えきるのは難しい。
ここも当初の1年は全く意識できていませんでした。自分が勝手に描いていたフラットかつ自律的なエンジニアチームというのも丁寧なアラインメント抜きでは新たに入社したメンバーからすれば「？」という感じでしたし、すれ違っていて当然でした。
また、メンバーからマネジャーに対する期待値合わせも本当に大事です。「Engineering Managerって何やっているの？」の問いに答えるのが難しい*9理由の一端として会社や組織や時期やメンバーが違えば向き合う課題が違う、というのがあると思います。「前職ではマネジャーはこういうロールだった」からといって自分がそのロールを担う必要は必ずしもないのですが、期待がすれ違っていると気付かないうちに不満が溜まったり、成果を出すために必要な信頼関係が構築できなかったりします。
反省してからは、新しく入ったメンバーには必ず「マネジャーに何を期待するか」と「マネジャーとしてあなたに期待すること」を伝えるようにしています。
従前のメンバーに対してもチーム変更や評価のタイミングなどの折にふれてやっていく必要があるのですが、こちらは振り返ってみると充分ではなかったかもしれません…。
マネジメントへのモチベーション
ところで、マネジャーをやっていると「何がモチベーションなんですか？」とよく聞かれました。*10
マネジメントをやりつつ、というかマネジャーというポジションを活かして技術力を伸ばす話を以前に書きました。こういう働き方ができるというのはモチベーションの一つでした。
この記事はおおむね技術面にフォーカスしていて、「じゃあ人と関わること、ピープルマネジメントに対してのモチベーションはどうなんだ」という感じなのでその辺についても書いておきたいと思います。
人間は不得手
関わったことがある人の一部は存じ上げているかもしれませんが、自分は業務を円滑に進めたり成果を上げたり問題を解決するためのコミュニケーションはどちらかといえば得意なほうですが、人間は不得手です。突然不穏になってきました。
「できること ----- できるけど疲れること ----- できないこと」のグラデーションの真ん中に "対人" がある感じです。
もちろん仕事でこそプロとして為すべき振る舞いや職業倫理を優先しています。知らない言語を触るとかフロントエンドに転向するとかで「苦手な領域の仕事をやることになったら学習する」のと同じで、「人間が苦手なら人間を学んでキャッチアップする」、プロとして向き合うという気持ちです。そういう振る舞いをしていると対人格闘のスペシャリストに間違われることもあると思います…
まぁ、必ずしも"対人"だけがマネジメントではないですが、そういうメンタリティの人間がマネジメントを続けるモチベーションってなんでしょうか、というのが問です。
それは…健康への意識でした。
健康
皆さんご存知でしょうか。「厚生労働省の平成29年 労働安全衛生調査（実態調査）」によると、「過去1年間にメンタルヘルス不調により連続1か月以上休業した労働者割合」が最も高い業種は情報通信業です。（この年は1.2%）
2018年頃は組織課題が顕在化していた時期で、エンジニアリング組織に限らず健康を害してしまったメンバーを観測しました。自分とは離れたチームではあったものの、まったく他人事ではなくいつ自分が健康を害するかわからない不安の中で、健康な組織・開発環境づくりへの意識がとても高くなりました。
個人としての中長期的なキャリアを考えたときに業界には盛り上がっていてほしいし、自分や同僚が健康でサステイナブルにやっていきたい。
マネジャーは組織を設計・実装できる立場です。不得手な業務が増えることになっても、あえてそこに飛び込むことで自身が楽しく健康的にやれるのであればやってもいいかな…と。それが自分のモチベーションでした。とはいえ、会社やプロダクトやチームや同僚が好きで、自分ができるあらゆる面で貢献したいと思えなければ自分にはやれない仕事だったと思います。
ちょっと格好つけましたが、自分が凡人でメンタルも鋼でないという自認があるので、他人から見ればささいな失敗や何かで、健康や精神を害する可能性を常に考えています。最悪のケースを避けるために自分にできることがあるなら自衛的にできることをやっていったほうがよいという、利己的なものですよ。
社外活動 / Engineering Manager Meetup
そんなこんなで社内でも様々な失敗や学びがあったのですが、エンジニアリングマネジャーの知見や失敗をもっとオープンに交換できる場がほしいと考え、2018年にはEngineering Manager Meetupというイベントとコミュニティを立ち上げました。
エンジニアリングマネジメントに関するコミュニティをやっているとマネジメントの専門家なのではと誤解されることもあるのですが、逆です。学びたいからコミュニティを作ったのです。
また、その後にDevSummit 2019で枠を頂いたりEOF 2019にもコアメンバーとして関わらせてもらいました。
このコミュニティからは本当に多くを学ばせてもらいました。上述の「学んだこと」も大部分はこのコミュニティで話すうちに言語化できたものだったりしますし、現場でその時々に悩んでいる課題への解決のヒントも貰いました。
EM Meetupのこれから
これまでは僕が悩んでいたり人の話を聞きたいと思ったタイミングで開催していたので、「次はいつやるのですか」「開催頻度をあげてほしい」という声にあまり応えられていませんでした。
しばらくはマネジメントが本業ではなくなるのでEM Meetupを個人ではなくコミュニティで運営することにしました。本業でなくとも関心領域ではある*11のでサポートやウォッチをしていければと思います。
そして、強いやっていきのある運営メンバーがすでに次回の初のオンライン開催を企画しております。実験的でどうなるか未知数ですが早速参加者が集まっていてすごい...顧客が本当に欲しかったものだ…!!
engineering-manager-meetup.connpass.com
うまくやれたこと
うまくやれたと判断するには指標というか理想との距離が埋まったかどうかを測りたいのですが、そもそもマネジャーとして目指していた理想は何だったのでしょうね。
そのときどきの状態や文脈に強く依存するのですが、ここ数年を振り返ってみて一貫して目指したことといえば上述した健康に対する意識に端を発するような、エンジニアとして健康で継続的に仕事ができる環境・組織文化づくり だったのかなと。
組織文化の醸成、特に互いが協力しあうカルチャーについては苦闘しつつも一定の手応えがあったと感じています。*12
できなかったこと / 足りなかったこと
一方、大局的な技術面での投資やロードマップ作りや実行にはあまり貢献できなかったという反省があります。
「重要度 小~中 × 緊急度 高」案件をけっこう場当たり的に処理してしまった感覚があり、「重要度 高 × 緊急度 中以上」にもっと腰を据えて取り組むべきでした。
自分ができなかっただけで社内ではBackbone.js->Reactのフロントエンド刷新・マイクロサービス化・MongoDB脱却・学習データ基盤整備・Kubernetes化...等々ここ数年で技術領域の面白案件がいくつもありました。このうちいくつかには関わったものの主体的に課題を発見して提起してリードして完遂したとはいえない…。React Nativeやめた話ぐらいです。
すごーく雑な感想ですが、自分の技術力が技術領域のマネジメントのボトルネックになっていたのかもしれません。
その他にも成果志向のマネジメント、今以上に率直なフィードバックを送り合うカルチャーづくり、チームをまたぐ機会づくりの創出などやりきれなかったことはいくつかあります…。
おわりに
8,000字書いておいてなんですが、書こうと思えばもっと無限に書けたような気もします。評価制度づくりとか採用活動とか1-on-1とか。
これといって締める言葉が見つからないのですが、そうですねぇ、これからも健康的にエンジニアリングしていきたいと思っています。そのために重要な知見をマネジャー経験で学んだと思いますし、これから1エンジニアとして働く上でもとても重要な視座を獲得出来たと考えています。*13
なんにせよ、本記事が誰かにとって意味ある文章になれば幸いです。
*1:いっそ削ろうと思ったが、いま書かないと一生書けなくなりそうなので
*2:インターネットでマネジャーが失敗について語ると息巻いて攻撃する方を一定数見てきたのですが、せっかくの知見や経験の流通を妨げていて本当によくないと思っています
*3:成長支援、個人間の問題の解消、いわゆるピープルマネジメント
*4:「評価だけ」と軽そうに書いたが、評価むずかしいですよね…。そのうえ僕がエンジニアリングマネジャーになった頃は海外拠点のマネジャーと電話会議があったりメンバーの評価を英語で書いたり口頭で説明したりして大変だった…。
*5:マネジャーを特別扱いしない、なんでもかんでもマネジャーに押し付けない
*6:ソフトウェアの運用でもアップデート (機能追加、バグFix、依存ライブラリ更新 etc.) を必要とするのと同じく…
*7:情報が公開されているだけで透明性ではない、というのを『組織における透明性』に書いた
*8:情報処理能力および感度が高い人は分割されたチームにおいてさえも周辺ユニットから情報を得ようとします。それはポジティブですが、それによりパフォーマンスが下がるかどうかは本人ないしはマネジャーがモニタリングしてフィードバックしていけると良い
*9:難しいシーンが多いと個人的には感じています
*10:（近年はそうでもないですが）大変でエンジニアがやりたがらないロールと認知している方や悩まれている方から特に多く聞かれた気がします。
*11:エンジニアリングもわかるマネジャーではなくマネジメントもわかるエンジニアでいたい、とはマネジャーやっている時から思っている
*12:決して数だけで語れるものではないですが退職者もずいぶん減り、eNPSの数値も上がりました。マネジャーが何かするだけでポンと変わることはなく、peerの関係やメンバーによる実行・実践が本当に大事なので同僚全員の頑張りです。
*13:これはポジショントーク満載ですが、実際、マネジャー経験のあるエンジニアには強い人が多いですね。同僚にもそういう方が複数名いました。
