はじめまして、@mshibuyaです。2019年7月よりメルカリにて働いており、メルカリシステムを支えるインフラを運用しサービスの信頼性を担保するSREチームにおいてエンジニアリングマネージャーをしています。
マネージャーとして約半年ほど取り組んできた中で、「マネージャーの成果ってなんだっけ？」となってしまうことがあったので、あらためてそこについて考えてみようという主旨のエントリになります。

なおこの記事はEngineering Manager Advent Calendar 2019の8日目のエントリです。

背景

前述の通り入社後半年ほどマネージャーとして取り組んできたわけですが、正直何かチームや会社に「これが自分の成果です！」と示せるような何かポジティブな影響を及ぼせたかと言われるとそんな気が全然していないです。
で、そうなってしまっている要因としては

• 社外からマネージャーとしてチームに入っていくのは一般に困難
• 自分自身、わりとインポスター症候群的な感じ方が強いタイプ（という自覚がある）

みたいな要素も多分にあるとは思うのですが、やはり大きな要因としては

• プレイングマネージャーから純粋なマネージャーへのロールチェンジを迫られている過渡期である

ことがあるのではないかと考えました。
エンジニアチームのマネージャー、というロールは前職でも3年ほど経験があるのですが、当時はプレイングマネージャーとしての色合いが濃く、マネジメント対象となるチームの大きさを抑えめ（3-4人とか）にしてもらい、業務の半分以上は自らも手を動かしエンジニアリングタスクをこなす時間に当てていました。
一方現在は14人からなるチームのマネジメントを一人で担っており、こうなってくるとマネジメント以外のことに使える時間というのが大変限られてくる感覚があります（いや、お前はマネージャーだから自分の時間の使い方についても裁量があるはずだろ、と言われればまぁそれはそうなんですが、正直努力でなんとかなるというより物理的に限界が見えてくるイメージです）。
そうなると、プレイングマネージャーとしては「プレイヤーとしての成果+マネージャーとしての成果」で自身の成果を捉えていたのが、「マネージャーとしての成果」のみで語らざるを得なくなり、結果これまで経験的に見えていた自分自身の成果より大分見劣りする状態になってしまっているのでは…という流れです。

といった点を踏まえ、マネージャーに求められる成果についてここで一度整理しておくのがよいのではないかと考えました。

考え方

まず、マネージャーに求められることは「チームの成果を最大化すること」であり、わりと自明とは思うのですがちょっと論点を分割して考えてみます。

そもそも成果とは？

「チームの」という文脈だけで考えてしまうとちょっとわかりづらい感覚があります。例えば他のチームの成果を差し置いてまで自チームの成果を追い求めることは圧倒的に正しくないわけなので…。

我々会社に所属する人間は、みんなが持っている様々な能力を結集して結果ビジネス的ななんらかのインパクトのある成果を残そうと頑張っているわけなので、会社としてのビジネス上のゴールにより近づけられる何かを達成することが成果であるはずです。
とはいえ、大きなゴールを目指そうとすればより細かいステップ、細かい責務に分けることが必要になるわけで、そうやって細分化された責務がチームとしてのミッションとなります。会社のゴールとチームのミッションがちゃんと対応づいていることはOKRやMBOみたいな目標管理制度が担保することになるわけですね。

チームの成果と個人の成果の違いとは？

「チームに所属する個人の上げた成果の総和＝チームの成果」であるのか否か？という話です。
これはちょっと悩ましい点があると思っていて、例えば「特にチームとして方針を立てたり計画したわけではないが、すごい人が個人で動いた結果なんとなく成果が出てしまった」として、それがチームの成果と言えるかという話です。
で、自分としてはそれもチームの成果だと思っていて、というのは「そういうすごい人が自発的に動き何かを成し遂げられるような環境を提供できる」というのはチームの貢献だったりそれを促進するマネジメントがあればこそと考えるからです。

成果を最大化する、とは？

難しいですね、「最大化」。もちろんとある成果を上げたとしてそれが最大であることは示しようがないので、「なるべく大きくする」程度のニュアンスで使われているはずです。
で、それが十分に大きいか否かについては

• ビジネスへの貢献度合い・インパクト
• 過去の成果との比較
• （比較可能であるなら）他チームの成果との相対的な比較

みたいな観点から判断される感じですよね。

マネジメントとチームの成果の関係

同じく今年のEngineering Manager Advent Calendarへの参加エントリである「コーチやメンターとの付き合い方」にもある通り

マネジメントの結果が出るのはいかんせんロングスパンなのですが、

というわけなので大変難しいですよね。この四半期にチームとして上げた成果のうち多くの部分はこの四半期のマネジメントによってもたらされたものではない可能性が高いわけですよ。
これではマネジメントが良かったか、悪かったかを評価しようって無理ゲーじゃないですか…？正しく評価するには長い期間を経て成果がどのように変動したかのデータを待つ必要がありますし、そうなると時間による状況の変化がもたらす影響を取り除いて純粋に比較することが難しくなってしまうわけで。

そこについては言えることは、「成果について、できるだけ定量的に示せる尺度を持つべき」ということじゃないかと思っています。「あの頃のチームはよかった」みたいな感覚的な話から脱却するにはちゃんとデータで示せないといけない。
例えば我々のようなSREチームであるなら、目指すサービスの信頼性を正しく定義し、それがどの程度のレベルで維持されているのかを定量的に記録する仕組みを持つことが重要であるはずです。

とはいえなんですが、「マネジメントの成果」ということで言えば「チームとしてそこそこのパフォーマンスを維持できている」といったレベルであってもある程度は成果であると言っちゃっていいんじゃないかと思ったりもするのです…。
SREチームのようなシステムの運用に関わる方にはよく分かってもらえると思うのですが、システムは何もしなければあらゆる隙を突いて勝手に動かなくなろうとしてしまうので、単に動かし続けるだけでも大変労力を要するじゃないですか。チームもきっと同じようなもので、平穏無事に動いているように見えるチームであっても、相応のマネジメントの努力によって支えられ、維持されているのではないかなと…そんな風に考えるようになりました。

まとめ

このエントリではエンジニアリングマネージャーとしての成果についてつらつら考えたことを書きました。とりわけ新規性はなかったとは思うものの、成果について考える上で一助となる論点を提示できていることを願っています。

現在メルカリSREチームでは自分と一緒にこんなことを考え、SREチームの成果を最大化するために力をお貸しくださるエンジニアリングマネージャーを絶賛募集中です。

Engineering Manager, Site Reliability - Mercari, Inc.

少しでも興味をもって頂けた方がいましたら、こんなbosyuもありますのでまずはカジュアルに食事でもどうでしょう。
上記bosyuないしTwitterアカウント宛でも大丈夫ですので、どうぞお気軽にお声がけください！現場の生の課題感などあれこれ語らいましょうー