TL;DR;
Engineering Managerを降りることになりましたので、振り返りとまとめです。
※会社は辞めませんので、退職エントリではございません（別チームへの異動です）
時系列
- 2017/10頃: SREのチーム内において会社のReport Line上にはプロットされないリーダー的なポジションをやりはじめる
- この時はまだManagerではない。採用や評価に対するResponsibilityがないのがマネージャとリーダーの簡単な違い
- 2018/04: SREのEngineering Managerに登用される
- 当時 Microservices PlatformはReport Line上はまだSRE内に包含されていた気がする
- どこかのタイミングで Report Lineとしても独立して、2チームを兼任する形で引き続き担当していた
- 2018/10: 2チーム兼任からMicroservices Platform専任になる
- この辺の経緯は、過去のインタビュー記事にも書いてある
- 2019/08: Engineering Managerを降りる
- 今回はココの話
マネジメントっぽいことだと2年弱。正式登用からだと1年4ヶ月。チームを絞ってからは10ヶ月。と、振り返ってみると大して長くない経験だったかもしれない。。
Engineering Managerやってる間の主なできごと
メルカリのMicroservices化が本格開始
それまでのMonolithic ArchitectureからMicroservicesに切り出し、Migrationしていくという意思決定がなされたのがちょうどマネージャに登用されたタイミングと一緒。この会社の大きな意思決定を推し進めるところからがMicroservices Platformのスタートだった
北海道地震
SRE側で大きな出来事は2018年9月に起きた北海道地震。データセンターの状況とサービスの継続を考えるまさに劇的な非日常だった。 その後のDisaster RecoveryやBCPと言った文脈にも繋がっていった。
チームの拡大と挫折
SRE/Microservices Platformそれぞれの活動軸があったが、自身のリソース配分としては大体四半期単位で2018/04-06はMicroservices Platformの初期推進が主だった一方、07-09はSRE業務や地震対応が逼迫していた。この間に両方のチームメンバーは合わせて20人位になっていた。2つの異なる軸を管掌しつつ、20人を担当するというのはさすがに無理だった。。
なので、この時ギブアップ宣言をして、SREの担当を外してもらった。SRE/Microservices Platformのどっちを取るかというのは悩んだが、mixiの時の経験と後悔から、サービスとして伸び盛りの時期にアーキテクチャ移行を行うという挑戦をどうしてもしたかった。なのでそれに最もコミットできるMicroservices Platform側を選んだ。
メルペイリリース
2019年2月にメルペイがリリースされた。メルカリと違い、メルペイは最初からMicroservices Architecutreを採用しており、徐々にMigrationされるメルカリと異なり、Platformにとって多くのMicroservicesつまり顧客が一気にリリースされた。その準備のために直前はチーム全体でフルコミットするなどしていた。
振り返り
過去のマネジメント経験を活かせたこと
自分以上の技術スキルの人のマネージャになる
自分より技術力が高く優秀な人が多く、技術的にリードするというようなことは全く必要なかった。これについて悩む人もいるかもしれないが、個人的には全くそれはなかった。ただ、技術力のキャッチアップは今回は失敗した。
まずやってもらう
↑の件とも絡むけど、基本的にやりたいようにやってもらって、それについてフィードバックするというのが理想だと思っていた。まず何か言うから始めていたらResponsibilityやOwnershipを持ってもらえない。これはタスク単位だけでなくチーム運営とかに対しても同様のスタンスでいたのだが、それが故に至らぬ部分もあったことが学びのパートに繋がる
意思決定を素早くする
これはかつての上司から学んだこと。どれだけ多く意思決定をするかがマネージャのパフォーマンスだと思っている。上長に「これどうしましょう？」と相談した事はたくさんあったけど、「どうやって決めたら良いでしょう？」というつもりで聞いていた。最初から答えの判断を仰ぐつもりで相談したことは少なかったと思う。
今回新しく経験して学んだこと
技術力キャッチアップとマネジメント作業のバランス
2チーム兼任時代はSREのOnCall対応も行っていた。これは現場感を保つためにとても良い作業だったが、マネジメントにかけられるパワーが割かれるという側面もあった。チームの拡大と共にマネジメント作業がパンクしたせいもあり、その時にOnCallから外れる決断をした。マネージャがどこまで現場で手を動かすかについては様々な議論があるが、この時に限っては手放すのが正解というかそれしか選択肢はなかった。
一方で、Microservices Platform専任になってからは、現場の作業をキャッチアップできていないという課題が起きた。それが起きてから振り返ってみると、OnCallなどで少しでも現場感覚を養っておけばという反省がある。特にMicroservices Platformのアーキテクチャについては元々経験があるなどのアドバンテージもなかったので、キャッチアップがより必要な状況で以前よりそれを怠れば、ギャップは危険域に達するというのは自然な話だ。
課題に対する危機意識はあったし、OnCallへjoinする予定は検討していたのだが、EMを降りるという意思決定を先にすることになったのは、見込みが甘かったのもまた反省要因であろう。
当たり前に自分がメンバーに求められること
元々自分自身マネージャに対する期待値が低かった事もあり、基本的に皆何も求めてないだろうというスタンスでいた。何かあれば言ってくるだろう、もっと言うと何かあっても言ってこないパターンだってあるだろう。 「俺らはお前の仕事なんか知らんけど、とりあえず俺らに害がないようにいい感じにやっておけ」 が期待値だと思っていた。
ただ、今回はマネージャとして動きやチームに対してなど色々な意見を聞かれたり求められたりした。そんなに求められることに慣れていなくて戸惑ったというのが正直な感想。今にして振り返れば、最初の時にマネージャに何を期待しているのか？を認識合わせしておけば良かったなと反省する。これによって数ヶ月分のパフォーマンスを変えられたかなと思う。
良かったできごと
採用活動
SRE/Microservices Platformそれぞれで多くの人を採用させてもらったが、特にMicroservices Platformの採用は時系列で振り返ってもおもしろかった。
- 2018/04
- マネージャになったこの時点でメンバーは4人、俺が直接採用に関わって入った人はまだいなかった。
- 2018/07
- 社内の別チームから異動という形で最初にチームを拡大する機会が訪れた
- マネジメント観点で見ればSkill Transferを伴ったケースで、それに対する不安もあったが、「見知った社内メンバーすら受け入れられないなら外部からの採用なんかできないだろう」と思ってチャレンジしてみた
- 2018/08
- 初の外部からの採用。俺にとっては採用フローに関わってから初のケースだったのでやはり緊張した事を覚えている
- 外国人ながらネイティブレベルの日本語を話すスキルの持ち主だが、それでもカルチャーマッチなど心配な点はあったが、「稀有なJapanese Speakerな人すら受け入れられないなら、Non Japanese Speakerな人なんか採用できないだろう」と思ってチャレンジしてみた。
- 2018/10
- 福岡在住の方で、初のリモートケースの採用
- 実は全社的にリモートワークの前例はなかった。なので、その事例を作るために会社に提案するところから始まった
- 基本的にリモートワーク導入時に課題となるのは、時差・物理的距離・物理的環境などが異なりそれがパフォーマンスを発揮してもらうのに影響してしまうケースがある、というあたりだ
- それに対してこのケースでは福岡のBranch Officeでの勤務が可能だったので、
- 時差: 日本国内なのでない
- 物理的距離: 六本木オフィスから福岡オフィスはその気になれば3時間で行ける
- 物理的環境: Branch Officeであるためファシリティや福利厚生は同じものを提供できる
- であるため、それらの条件はほぼ取っ払えた。この状況で福岡オフィスで働き、六本木オフィスのメンバーと一緒にパフォーマンスを発揮してもらえれば、それによって『リモートワーク』が成功したという事例が作れる。全社視点で見て、リモートワークという取組を検証するのにこれほどリスクが少なく、パイロット案件として相応しいケースはない。逆にこれがクリアできなければ海外でWork From Homeする敏腕エンジニアを採用する、など到底できない。という点を推して採択してもらった。
- 2019/02
- 初のNon Japanese Speakerの採用
- もうここまで来ると、「Non Japanese Speakerチャレンジしなくてどうする」だし、実はチームとしては発足時からSlackとドキュメントを全部英語にするのをメンバー達自身で徹底していた
- MTGを英語化するというチャレンジにフォーカスできたのは、そのような環境を予め作り上げてくれていたおかげだ
振り返れば、どれも 初 なケースばかりで似たようなパターンはなかった。採用の度に新しいチャレンジをさせてもらったし、その度にチームのダイバーシティを拡大できたとも思っている。採用した数で言ったら他のチームより少ないと思うけど、 採用によってチームのパフォーマンスを伸ばせたか で言ったら他のチームに負けてないと自信を持って言える。
チームが自律していたこと
学んだことの項から、メンバーの依存度が高いように読み取れるかもしれないが、実際はとても自律したチームだった。リクエストされる内容で、個人的な本音ベースで言えば面倒だったり、共感できなかったりで困った事ももちろんあったけど、マネージャとして考えてやった方が良いだろうなと思える事がほとんどだったので、やるべきだと思ったし、やって良かったとも思う。彼らのそういうリクエストは「自分たちでチームを改善していく」というアクションから来ているので、その志の高さがなにより受け甲斐があったポイントだ。
なんで降りるの？
いくつかあるけど、まぁ端的に言えば 力不足 が主な要因。『力』をもう少し分解すると
- 技術的キャッチアップ
- Proactiveなアクション
あたりになる。
技術的キャッチアップに関しては、EMが現場メンバーと同等（あるいはそれ以上）の技術力を有するというのは至難の技だ。少なくとも俺にとっては。
となると、どの程度劣っていることが許容範囲内なのか？おそらく「メンバーの技術力を見極め評価すること」「時に技術的な意思決定やメンバーフォローができること」だと思っている。
評価に関してはメンバーからも不十分であるというフィードバックを貰えた。ちなみにこのようなフィードバックをメンバーから貰える透明性と公平性も良かったと思っている。
後からのキャッチアップが難しい分、目標の認識合わせを厚めにするなどアプローチする時期を変えることで改善できた部分もあったが、完全に要求を満たすことはできなかった。やはり元々イチBackend Engineerの自分にとってContainerを始めとしたインフラの先端を掴むには時間と努力が足りなかった。
Proactiveなアクションは、例えばチームのロードマップを立てるみたいな先手を打つことだ。さらにここにCompany Valueでもある Go Bold という接頭語が付いてくる。そもそも自分にBoldっぽさがない事は自覚としてあるし、先手を打つような潜在的なニーズ・リクエストに応えるより、顕在化したIssueに応える方が得意かつ志向するタイプであるため、こういう動きはどうしても鈍くなる。
まぁロードマップそのものを作るのを求められている訳ではなくて、その成果をチームとして出せれば良い。誰がロードマップを作るのがチームにとって良いかで言うと、最高のTech Leadをおいて他にはいないのでそのための環境をどこまで整えられるかが俺のミッションだと思っていたが、そのアクションが不十分だったということだと思っている。
ちなみに、遅れさせてしまったが最終的にTech Leadがロードマップを導き出してくれたので、チームとしてはそれを元に前進できるようになったのは今後の良い話だ。
他にも理由はあるが、ポジティブなものとしては、俺より優秀なマネージャを採用できたから、というのももちろんある。
メンバー採用は前述の通り楽しみと成功体験があったが、マネージャ採用に関してはずっと叶わず、それが故に自分で抱えきれなくなってギブアップする（結果、兼任を止める)という事態を起こしてしまったのも課題だったが、最後はどうにか最低限の形は作れたと思う。
TIPS
今回のManager在籍期間でトライしたTipsをいくつか残しておく
1on1 docsの公開範囲
もちろんメンバーと1on1をやるので、MTG noteを作るのだが、メルカリではGoogle Docsを用いる事が多い。
その公開範囲はもちろん絞られるべきで、何も考えなければ 俺 + メンバーの2人のみの範囲になるのが自然である。なのだけれど、それに加えて俺の上長も必ず公開範囲に含めるようにしていた。
1on1とはマネージャとメンバーの信頼関係の積み上げ資料でもあり、メンバーの成長の助けにもなるべきものだ。メンバーが成長するために、彼らはマネージャに、あるいは会社に様々な事をリクエストできる。それに応えるのがマネージャの仕事だ。メンバー自身の悩みや課題を書いたり、会社への疑問やリクエストを書くこともある。もしこれらが適切に扱われない場合、メンバーはどうすれば良いか？クローズドなドキュメントで処理されていると、メンバーが何もできずに行き詰まってしまうので、それを避けるためにエスカレーション先を提供したかったというのが意図だ。
メンバーと初めて1on1するときにdocsの一番最初のアジェンダにはいつも以下のように書いていた。
閲覧権限は @XXX(上長の名前) にも付与してあるので、何かあればエスカレーションしてください
加えて、口頭で
もし俺と1on1をしていて、「こいつダメだ」と思ったら、この1on1 docsをエビデンスとして使いつつ、上長にアラートしに行ってください。
と補足していた。メンバーから見て、マネージャとの1on1というのは、そこが会社とのインタフェースでもあるので、フォールバック先を提供するのは会社というSystemのReliabilityのためには必要な事だ。
過去のBlog Postで書いた内容
Blogに書いておくと、こういう時にTipですと言ってスッと出せるのが良いところ
考えを言語化してアウトプットすること
メンバーと日々コミュニケーションしていく上で、バックグラウンドを共有しないと話せば話すほど認識がズレていくという課題があった。定期的に1on1していても、やはり踏み込んだ会話をしていくと、それぞれの考え方があるんだなぁ、というのを何度も感じた。例えば、評価フィードバックの時に『○○はGo Boldで良かった』と伝えても、なぜ・どのように・どれくらいそれが評価されるのか？とか、もっと突き詰めると『そもそもGo Boldって何なのか』みたいな話になったりする。
またそういうのって、別に誰か一人じゃないので、何度も言うことになる。となればDRYの原則に沿うのがエンジニアとしてすべきことなので、それもあってメルカリのValueの自分なりの解釈のようなエントリも書いたりした。
特にこの「何度も言う事を書く」っていうのは意識したことで、メンバーそれぞれに微妙に違う情報を伝達するリスクを防ぐ目的でもある。（むしろ、同じ情報を提供したとしても人によってそれぞれ解釈が違うものである）
ドキュメント化については、正直苦手でもあり、費用対効果を軽視していたが、Microservices Platformチームの文化としてドキュメントをしっかり書く事が効率的かつ合理的だと学んだこともあり、こうしてブログを書くことなどは意識してやってみたことだ。
またマネージャをやると、どうしてもコードを書いていた時に比べてアウトプットが減る感覚に陥る、というか事実減ると思う。やはりエンジニアとしてアウトプットしたくなるが、そこでコード以外のアウトプット方法として考えたのがドキュメント(=ブログ)だった。アウトプットしてモチベーションを保ったり、フィードバックを貰ったりという効果があるのはコードもドキュメントも変わらなかったのはやってみた良い気づきだ。
自分のマイナス評価結果をメンバーに共有した
四半期ごとに行われる会社の評価結果でマイナス評価を受けた際にそれをメンバーに共有した。これは会社にとっても非常にセンシティブな項目であり、気軽に真似しないでいただきたい。この共有ために気をつけたポイントはいくつもある。
まず背景として何故共有しようと思ったか？
一つは、こういうパフォーマンスだとこういうマイナス評価になる、だから皆はそうならないように気をつけてくれ。と反面教師の意味で伝えるため。
もう一つは、このマイナス評価はメンバーからのフィードバックも反映された結果となっている。つまり皆のフィードバックが評価システムの中で正しく扱われている。だから次の時も正直なフィードバックを書いてくれ。という事を伝えるためだ。
何故そこまでして伝えるか？
メンバーから見て、自分自身の評価者である人の評価を厳しく書くことは非常に勇気のいることだ。報復されて逆に自分自身の評価を下げられるのでは、と考える人がいてもおかしくない。なので書いてくれたメンバーには報いる必要があるし、書いてくれた成果がある事を知ってもらう事が重要だと考えたためだ。
これを実行するために具体的に気をつけたことは以下である。
- 俺の評価者に事前に相談し、共有することを了承してもらう
- 基本であり、全てはここから。俺の上長に対して共有の許可を貰った
- 共有現場には評価者にも同席してもらい、補足説明もしてもらう
- 評価内容が正しく伝わらないのは評価システムで最も避けなければならないことだ。そのために評価内容を正しく伝えられる人、つまり評価者が同席する必要がある
- 逆に言うと、被評価者である俺自身が客観的に評価内容を伝えることなどできるハズがない。良くて通信簿の見せ合いっこになるだけだし、最悪の場合、評価者を悪者にすることもできてしまう
- 公開範囲はメンバーにのみ限定し、その場以外ではその情報にアクセスできないようにする
- あとから情報が独り歩きするのは要らない副作用やリスクしかおきない。同じく評価内容が正しく伝わらなくなる可能性がある。そのためドキュメントをシェアするのではなく、評価画面をその場でスクリーンシェアするのみに絞る
- 評価内容のみ共有し、等級や給料などの情報は見せない
- あくまでメンバーからのフィードバックの扱われ方を焦点にしているためである
それなりにインパクトのある情報であったと思うがメンバーは真摯に受け止めてくれたし、その次の機会の際に、遠慮して厳しい点を書かないようなメンバーがいなかったことが本当に素晴らしかった。Be A Proなメンバーに恵まれたと思う。
なので、全てのケースでこれが効果的であるとは思わないし、全ての評価結果がオープンであるべきとも思わない。周りの人の理解と協力があって成立した良いケースだったという意味でTIPsレベルの情報だ。
まとめ
チームが最高だった！みたいのを(思ってても)言わないのは、チーム自体はこれからも続いていくので、俺が俺の時間軸で結論づけるものではないかと思う。
やってる時は辛いことが多かったけど、終わってみれば楽しかったかなと思える経験でした。
振り返ってみればそこまで長い時間ではなかったことと、もう一つ「メンバーの1段上のマネージャ」の役割・成果しか出してない、というのがポイントかと思う。
1on1 docs に上長を入れること、評価結果を共有するのを上長に協力仰ぐこと、など成果の要所には俺の上長が存在する。これは上長がいるレベルのレイヤのマネジメントタスクが主だったという証拠であり、会社にとってより大きなインパクトを残せなかったのは課題かもしれないし、前回と比べて成長していない部分かもしれない。
体調的では、これまでストレスは胃に来るタイプだったのだが、今回のマネージャ期間においては色々趣向をこらしてきた。去年の夏にはメニエール病に片足突っ込んで、めまいで起き上がれないような事態になった。これは初めての経験だった。また、これはマネージャ業がどこまで関連しているか不明だが、膵臓の一部パラメータが異常値を計測したため、アルコールの摂取を医者に止められることになった。これによって実は、酒が今後一生飲めなくなった、というのが最近の出来事だったりする。(色々検査して命に別状ないので、当面はすこぶる元気です）
一方(良い方の話で)個人的事情もあり、マネージャ交代というのは前々から考えていた。そもそもマネージャに登用された際に宣言した目標が『俺よりスゴいマネージャを連れてくる』だった。実際の結果は元々のその予定とはタイミングと引き継ぎ期間が異なった事もあり、宣言内容をやや強引に実現する形になってしまった。
最初に宣言したことをちゃんと果たせなかったので、「マネージャ作業」というこのプロジェクトを振り返るなら残念ながら『失敗』だったと結論づけるしかない。 ただし、俺のプロジェクトが失敗したことと、メンバーが成長しチームが成果を出したことは違う話であり、それはその成功要因が俺にあるわけではなく、メンバー達自身にあるためである。
ちなみに次はそこそこ違うことをする予定ですがそれについては結果が出た時にエントリを書けたら良いなと思っています。
※【再掲】会社は辞めませんので、退職エントリではございません
