2つの事例から見るエンジニアリングマネジメント業務の再現性

　本記事はEngineering Manager Advent Calendar 2021の3日目です。
　2日目は@naoprさんの「かつてEMをやりたくなかった俺たちへ」です。エンジニアリングマネージャー（以下、EM）やりたくなかった時期・・・私にもあったなぁ。

かつてEMをやりたくなかった俺たちへ - るさんちまん

はじめに

　私は2017年夏頃よりEMを名乗って業務をし始め、本記事を書いている2021年冬時点で2つのプロダクトでEMを経験しました。
　EMを名乗って業務をするうえで、特定のチームでしか業務が出来ないのでは活躍の場が広がりません。ただ、恥ずかしながらつい私は最近まで業務の再現性というものに意識を向けていませんでした。
　本記事では、私自身のEM業務を事例として挙げて振り返りながら、EM業務の再現性を考えてみます。

本記事で指すEM業務とは

　EMが担当する業務は多岐に渡ります。そのなかでも、本記事は、以前Engineering Manager Meetupで議論され作成された「エンジニアリングマネジメントトライアングル」で指すところの ”Team Design”, “Team Development“ あたりを指しています。

【EM必読】エンジニアリングマネジメントトライアングルの考察：序 - STEAM PLACE

事例

チームA

チームの強み：

• 職種を越えたチームの一体感、仲の良さ

• エンジニアもプロダクトを成長させたいという気持ちを持っている

チームの課題：

• システムのレガシー化の深刻化

• プロダクトが思うように成長していない

チームB

チームの強み：

• 新しい技術領域への挑戦とレガシー改善をバランス良く進められる

• プロダクトが堅調に成長している

チームの課題：

• 組織のサイロ化が進み、他職種や他チームとの交流がない

• エンジニアが「やらされ感」「受託開発感」を感じている

類似点と相違点

　こうやって強みと課題を並べてみると、同じ会社のプロダクトであるにも関わらず、正反対の性質を持っているような印象を受けます。この2つのチームに共通点と相違点があるのか、更に深堀りを進めてみます。

共通点

　別の会社だったり、別の事業ドメインだったりすると、組織が持つ性質はもっと異なっただろうと思いますが、同じ会社、同じ事業ドメイン、更には似た性質のシステム構造と、共通するものが多くありました。
　振り返ると、異動後比較的すんなりとEM業務が出来たのは、この共通点に助けられた部分が大きいように感じます。

• 同じ会社の従業員で構成されていること

  • 同じコーポレートビジョンに共感している

  • 同じ給与体系に存在している

• システム的にはもともと近い構成で実装されていたこと

  • 最初はLAMP構成で実装されていて、Ruby on Rails化・クラウド化を目指している

  • 人材領域にフォーカスしたデータベースメディア

相違点

　同じ会社、同じ事業ドメイン、似た性質のシステム構造を持ちながら、なぜ正反対の特徴をもったチームになったのか考えてみます。
　まず大きく違うのは、プロダクトが生み出す利益です。利益率が高いほうが、技術的な投資に当てられる余裕が大きくあるように感じます。ここであえて明記したいのは、どちらのチームも、私目線ではEMと事業責任者との関係性は比較的良好で信頼関係も一定築けていたことです。
　エンジニア組織としてはプロダクトの状態に関わらず技術的な投資は常に行っておきたくて、EMはそのリクエストを事業責任者に伝えなければなりませんが、結果的に数年単位で継続的な技術投資が実現できているのはプロダクトが利益を生み出せているほうのチームでした。
　次点ではチーム構成が挙げられます。なぜチームAがうまく実現していて、チームBが実現できないのか、根本的な理由が見えているわけではないですが、どちらのプロダクトも運用開始から相当な年月が経過しており、それぞれの文化が醸成されているため、その差がもしかしたら影響しているのかも知れません。

• 開発ロードマップに占める新技術導入・レガシー改善に対する割合

  • チームAに比べ、チームBはプロジェクトごとにレガシー改善をしたり、新技術を導入する余裕があった

• 職種混合のチーム構成

  • チームBが明確に職種ごとのチーム編成になり、それぞれの業務に集中できる状態であったのに対し、チームAはプロジェクトごとに職種混合の仮想チームが編成されており、積極的に交流がなされていた

EMとしてトライしたこと

　冒頭でも記しましたが、恥ずかしいことに私は異動に際し特に何も考えず、異動して何となくEM業務を始めてしまい、幸か不幸か大失敗もなくここまで来てしまいました。なので「EMとして業務に再現性はありますか？」と問われたとき、言葉に詰まりました。この問いは、別の言い方をするならば「別の事業ドメインのプロダクト開発チームに異動したり、あるいは別の会社に転職したりしたとき、あなたは変わらずEMとして価値を発揮できますか？」だと思いました。とても焦りました。
　EMとしてトライしたことはいくつかありますが、そのなかから印象的なものをピックアップして振り返ってみます。

エンジニアとの1on1

　EMの業務としては、もはや当たり前のように語られますし、どちらのチームでも実施しています。大人数で話しているときに、課題というのはなかなか言い出せないものですし、話していく中で課題を探り当てるという行為に大人数は不向きに感じます。組織の潜在的な課題の抽出や、エンジニア個人のキャリア相談などには効果がありました。

振り返り会

　これもどちらのチームでも実施していたのですが、人数の関係上、開催頻度や参加者は異なっています。チームAのほうはPdM、デザイナーも含め全員参加で隔週開催していましたが、チームBのほうはエンジニアのみで毎月開催しています。チームBで職種間の隔たりが出来ている問題には、職種混合の振り返り会の実施が効くかも知れません。

PdMや事業責任者との対話

　どちらのチームでも実施していたのですが、私自身まだ改善の余地があると感じているのは「技術投資の優先度を下げた結果中長期的にどのようなことになるのか」という議論が弱かったと思っています。先日@takesue1011さんが同様の記事を書いていらっしゃいます。

　直近の施策や中長期的なプロダクトの方向性については議論を継続している割に、技術投資の話になるとEM側も「ちゃんと理解してくれるかなぁ」とか「今売上目標に届くか微妙だしなぁ」とか思いませんか？私は自分自身を振り返ると正直そういうところがあったと思っています。

エンジニアの存在意義とは
　事業会社におけるエンジニアは何のために所属しているのでしょうか。
　一つは業務委託や外注に比べて人件費が安いことでしょう。明確です。
　一つは業務委託に比べて比較的長期的に企業にコミットしてくれるからでしょう。ただ昨今は早期退職化が進んでいますし、業務委託のエンジニアでも数年単位で参画してくださる方もいらっしゃるので、理由としては弱くなりつつあります。
　人件費削減のために企業に所属したいと思うエンジニアはそう多くはないと思います。となると、自分たちの存在意義を会社に納得してもらう必要があります。

• エンジニア目線でプロダクトをより改善するための施策を考え、実行に移す

• プロダクトの生産性をあげ、技術的にプロダクトに価値を付与していくための開発を実施する

このあたりを明らかにし、伝えていくのもEMの仕事の一つだと思います。

振り返りから考えるEM業務の再現性とは

　振り返ると、エンジニア・PdM・事業責任者とそれぞれコミュニケーションを取る中で、EMとして改善する方法を模索していたことがわかりました。

• 会話の中から曖昧な課題を抽出し、本質的な解決策を模索する

• エンジニアだけではなくPdM・事業責任者・その他の職種と会話しながら、様々な角度から問題を捉える

• 相互に信頼しつつ、勘違いから誤った捉え方をしていないかを疑ってみる

• 自分たちがどうありたいかを明確にし、広く伝える

• 会社の経営陣や事業責任者の考えを理解し、エンジニアが納得できるような言葉にコンパイルして伝える

　具体的に取るべき手法は組織や環境によって異なるでしょうから、何をしたいか・何を解決したいかを意識して組織に向かうことが、EMとしての業務再現性につながるのではないかと考えました。
　もしEMの方で業務再現性について一家言ある方がいらっしゃれば、是非DMなどでご教示頂けるとありがたいです。

謝辞

　本記事を執筆するにあたり、「再現性」という気づきを頂き、議論させていただいた@yta026さん、@taison124さんに、この場をお借りして御礼を申し上げます。

Engineering Manager Advent Calendar 2021の4日目は @tunepolo さんです。