Engineering Manager 1年目失敗談

このストーリーは、Engineering Manager Advent Calendar 2023 の1日目の記事です。

Engineering Manager になって1年たった

ウォンテッドリーで Engineering Manager というタイトルが自分についてから今日で1年と3ヶ月を数えます。実際にはその半年ほど前からそれ相当の業務をしていましたが、タイトルが付くということは自分の仕事に名前がつくということであり自分のメンタリティーにもチームメンバーのメンタリティにも影響を与えるようになります。そこで自分はちょうど今が2年目に入ったタイミングだと認識しています。

2年目に入って自分の1年目を振り返ると様々な反省と失敗談があります。もちろん自慢したい話や楽しかった話もたくさんありますが、それよりも失敗と反省にフォーカスするほうが共有することで誰かに学びを提供できるかもしれないと考えています。そこで今回はその失敗をまとめることで、今後職責が増える人にとっての一つのサンプルを提供できればと思います。

開発組織40人にEM3人

まずはコンテキストを示します。ウォンテッドリーにおける EM はざっくり2階層以上でトータル10人程度をマネジメントすることが求められます。自分は新卒で入社して5年目に任命されました。自分がここで書く内容は主に開発組織40人~ 程度を3人の EM (VPoE を含む) でマネジメントしているときのものです。

失敗1. アウトカムの期待を高くしすぎた

EM になって継続的に組織課題に取り組むことになりました。本記事で言う組織課題とは前述の40人程度の開発組織をより良くできる課題のことです。ここでは明確に定義しませんが、具体的には下のようなアクションで解決に近づけるものを念頭に置いています。

• 制度設計/改定/廃止
• 文化や知識の浸透
• 採用 / 育成

これを解決していく速度の期待を高く置きすぎたというのが第一の失敗です。

権限不足が言い訳にならない

権限不足がいいわけにならなくなったことをEM になってすぐに実感しました。もちろん小さい組織なので EM になる前も組織課題を解きたいときに権限不足がボトルネックになることはなかったし、権限不足を言い訳に組織課題を見て見ぬふりをしたつもりもありません。そもそも組織統制的に重要なものを除き、誰がどこまでの意思決定をしていいかが明文化されるわけでもないので権限が問題にも武器にもなりません。しかし、明確に立場ができると「権限不足が問題になることはない」という前提が重く感じました。

組織課題が自分の課題に

組織課題を解いていくのが自分の仕事になると「組織に責任を求める」ということができなくなります。これも権限不足の議論と同様にこれを言い訳にしてきたつもりはありませんが、明確に自分の仕事となると責任感を覚えてしまいます。例えば「みんなが自主的に xx をしない状態が良くない」と感じても「自主的に xx しない力学を自分が作ってしまっているのではないか?」とか「その力学を作っていくのが自分の仕事なのにそれができていないということなのでは?」とか思ってしまうわけです。そしてそれは実際その通りなわけです。

「解けるはず」が解かれていないストレス

つまり組織課題が下のように見えるようになりました。

• 全てが解決可能になった
• 全てを自分が取り組むべき

原理的に解けるはずで解くべきだと思っている問題がゼロにならない状態をずっと目にしていると「自分の仕事が不十分である」という錯覚をしてしまいました。

こうなると不幸で、もっと自分ができるようにならないと行けないという焦りばかりが感じられるようになる。

「やったほうがいいこと」ではなく「今やるべきこと」に着目するべき

まず前提として「やったほうがいいこと」の全てをやるのは不可能です。したがって「やったほうがいいこと」の何%くらいできているだろうか、と考えると絶対に100点が得られません。むしろ視野が広がるたびに分母が大きくなって点数が下がってしまいます。そうなると組織に目を向けることにストレスを感じてしまうのでMPが削られていきます。

そこで「今やるべきこと」の何%くらいができたかどうかをみるほうがよいと思います。ここで言う「今やるべきこと」とは、リソース都合やその時重要視するべきタイムスパンなども加味したもののことです。例を挙げるとしたら「backlog の全て」という意味での「やったほうがいいこと」ではなく「今 sprint に積んだタスク」という意味での「今やるべきこと」に集中するべきということです。

別の言い方としては「アウトカムの期待を高くしすぎた」があると思います。自分が一定期間の間にできることには限界があるのに「いま見えている組織問題の全てが解決されるのが理想」という捉え方をしていたということです。自分としては今のウォンテッドリーの状態として EM がなすべきことのごく一部しか実行できていないと感じています。しかし、自分のキャパシティを如何にして大きくしていくかということとと自分の限られたキャパシティをどのように使うかは別で考えないと勝手に燃え尽きるしまいます。そこで「できていないことがたくさんある」という事実と「自分ができる限りのことをやっているか」という問いはあえて分離していくことが大事だと感じています。

失敗2. インプット期待を低くしようとした

アウトカムの話が出たのでインプットの話もしたいなと思います。これは後から意味づけたことですが、自分はインプットを少なくすることでアウトプットの少なさを説明をしようとしていました。具体的には忙しさという言い訳を求めていました。

忙しさに逃げる

「やったほうがいいこと」の全てをやるのは不可能だとするといつも「もうちょっと頑張ったらできたはずだった」ということが出てきます。EM としてのそれは誰かが待っているものであることもよくあります。例えば「xx をするための制度設計ができないか」みたいなものが進められないとそれを期待している人を待たせることになってしまいます。

自分はこういった事が増えるときに「時間の制約上できないものはしょうがない」という言い訳を求めることがありました。具体的にはカレンダーが埋まっている方が「忙しかったからしょうがない」と言えて安心感を覚えたり、夜になって「就業時間だから今日はこれ以上できない」と言えてホッとしたりすることがありました。

ゴールを決めるべき

結局前述の「今やるべきこと」をしっかり考える、プランニングをしっかりするということに行き着きます。大事なのは限られた時間の中でなにを達成するかです。ベストエフォートで頑張ろうという気持ちではできていないことばかりを考えてしまうので良くない。

ただしこれは簡単ではないことも認識しておく必要があります。自分が一ヶ月頑張った後に組織のパフォーマンス / 満足度 / 離職率 の変化のすべてを定量的に計測するのは無理だし外部要因の影響も受けます。すると、なにができたら ok なのか?を明確に決めることは基本的に無理です。そこで自分は定性的な観測に加えて、行動目標で考えて「その行動目標は良いものだったか?」を定期的に考え直すのが基本的には合理的だと感じています。

自分の時間をしっかり持つべき

自分の時間をどう使うかという話はアウトプットの量にも影響を与えますが、質に対する影響も大きいと感じています。暇な時間を持てないとクリエイティブな発想や十分な組織観察ができなくなります。するといろんなことが後手に回ってしまい、また時間が奪われてしまいます。当初自分は「EMこそ泥臭いことができるべき」という気持ちがあり、自分がやらなくていいものも色々巻き取ってしまっていました。確かに泥臭いことができる気持ちとスキルは常に持っていたいです。しかし、自分の役割は誰でもできることをやることではありませんでした。

今は積極的に自分のチームメンバーに頼って任せていくべきだと感じています。自分の仕事をよく知ってもらうことにもなるので、自分なら15分でできる気がする程度の小さいこともどんどんチームメンバーを頼ることのしています。限度が難しいところですが、自分の意見では EM をやることになる人は自分でなんでも巻き取ろうとしてしまう傾向があると思うので思い切ってなんでも頼っていくのでちょうどいいのではないかなと思っています。

失敗3. チームの安定を当たり前だと認識した

ここまで組織課題に対する取り組みばかり語ってみましたが、もちろんそれ以外の仕事もたくさんしています。一番大きなものは自分が見ているチームとプロジェクトを安定させたり成功させたりすることです。組織課題を解いていくようなアクションはまずこの安定があって取り組めるようになります。自分のチームのパフォーマンスが上がっていなかったりプロジェクトが問題だらけになることを犠牲に開発組織に対する提案をするのは優先順位が間違っているわけです。

組織の安定化には常にエネルギーが必要

自分はチームメンバーに恵まれていることもあり、チームやプロジェクトを安定させることに大きな課題は感じていません。ただそれは自分が安定化になにもしなくて良いということではありません。障害が少なくなってもその状態の維持のために SRE が努力を続けるのと同様に、チームが安定していてもその状態が維持できるように時間と労力を割いています。当然ながら組織が安定しているという状態を維持できているのも一つの成果なのですが、自分はそれを軽視していました。

組織の安定も成果

あるときは自分のチームでの様々な気になる兆候に対して対応することで数日から一週間時間がなくなってしまうこともあります。こういうときに表面上はなにも変わっていないので「今週は何もできなかった」と感じたりしました。自分のアクションでチームの安定が維持されたのであれば(そう証明するのは難しいが)それは成果であるはずです。

もちろん自分のチームだけを見ていてもだめなのですが、少なくともチームの良い状態が維持できていることは誇るべきです。今月もなにも問題がなかったのであればそれも成果だと捉えるべきだと認識しました。期待するチーム状態を定量化するのは難しいし、それに自分のアクションが及ぼしたという影響の証明も難しい。しかし自分の上長とチームの安定化の期待を握っておくことは重要である。

失敗4. 自分が周りに合わせに行った

チームメンバーのやりやすい状態を維持したかった

自分はトップダウンに自分が色々いうよりも、チームメンバーから色々議論を上げたり自主的に意思決定したりするスタイルを好みます。どんな技術的課題も自分よりうまく解けるメンバーがチームに居るので彼らのクリエイティビティに頼るのが得策だと考えてきました。

レポート形式も任せた

すべてを任せる、が行き過ぎて目標設定やレポーティングの形式も決めてもらっていました。この結果自分の認知負荷が増え、チームメンバーからしても「何が求められているのかわからなくて混乱」という状態をもたらしてしまいました。

自分が欲しい物を打ち出すべき

そう思うのに少し勇気が必要でしたが、周囲の人に「自分の都合に合わせてもらう」をやっていく事が大事だったと感じています。自分が認識しやすいレポート形式、コミュニケーション設計を始めとしてやってほしいことを明確に伝えていくことがチームメンバーの認知負荷軽減につながるし、自分も楽になり色々な他の手を打てるようになります。

失敗5. 完璧であろうとした

模範的でありたい欲求

EM になって模範的でなくてはいけないという気持ちが強くなりました。それ自体は重要なことだと思っています。組織に浸透させたいことは自分から率先してやったり、他の組織全体の方針にアラインした発言をしたりすることがタイトルの付く人に求められるアクションです。

しかしこれが行き過ぎて下のような気持ちになってスピードが落ちることがありました。

• xx を完全に理解した上で発言しないといけないのでは?
• 他のチームの方針の変更などを全て把握した上で意思決定をしないといけないのでは?

組織のすべてを理解して振る舞えればそれは理想ですが、それのためにプレッシャーを感じてアクションや判断速度が犠牲になってしまってはよくありません。

ちょうど良い量の情報見続ける

これはまだ少しずつ解決していっている段階ですが、「ここまでの情報を見て間違えるならしょうがない」というラインを(明確に引ける訳では無いことが大変ポイントだが)考え続けて短時間でのインプットができる状態を作っていく必要があるなと思います。

間違えてもいい

失敗から学んでいけたらいいので、まずはアクションしてインプットが足りなかったと思ったタイミングで自分の考え方やワークフローを見直していく、という勇気が必要だなと思っています。

自分の認知負荷はみんなの認知負荷

もう一点大事なこととして、自分の理解が漏れていたり忘れたりするポイントは組織全体にとってそうである可能性が高いということがあります。周りを自分に合わせて行く気持ちに近いものがありますが、自分にとっても組織全体にとってもいろんな情報を認知しやすくするコミュニケーションの仕方に近づけていくことも重要だと考えています。これもまだ発展途上のことが多い組織課題の一つです。

今のままで良いという意味ではない

基本的にここで書いてきたことを総括すると基本的に EM がやるべきことの逆も意識するべきだという話が多いなと思います。タイトルが付いたからと言っていきなり自分の期待値を上げすぎないということです。ただしこれは「そのままで良い」ということを意味しません。組織課題の解決のベロシティと質は個人としても組織としてももっと上げていく必要があります。個人と組織の成長に取ってちょうどいいチャレンジをし続けることが持続性を持ちつつ組織を良くしていく良い方法だと思います。もっとできないといけないが、無理をしない効率的なアクションを目指して今後も頑張っていきます。

今日ここで書いたことは「できていなかった言い訳」とも読むことができます。これを言い訳ではなく冷静な分析と言えるようになるかが2年目の課題だと考えています。