10XにおけるEngineering Manager

こんにちは。 Software Engineerのsota1235です。

この記事は10X アドベントカレンダー2日目の記事です。

好きなスーパーはSainE よしやで、よく買う商品はお魚全般です!(お魚の品揃えが良すぎて、売り場を歩くのが楽しいスーパーです)

今回は10XにおけるEngineering Manager(以後、EMと書きます)の話をしようと思います。

※ 2022/9までEMとして働いてたので、EM最後の仕事(?)としてこの記事をしたためています

この記事で伝えたいこと

  • EMの定義づけの意義
  • 10XにおけるEMとは
  • 定義を言語化することで目指したいこと

EMの定義付けの大事さ

ここ数年でEMという言葉はよく聞くようになりましたが、その意味や定義は会社によって異なります。

どの組織でも概ね「エンジニアリング組織におけるマネージャーRoleを担う人物」というところは共通していそうですが、もう少し踏み込んでみるとその役割や責務は様々です。

10XでEMが誕生したのは今年の1月ですが、そこから約1年間でEMに求められる責務や期待値が言語化されてきました。

この記事ではその内容を紹介できればと思います!

10XにおけるEM

組織としての整理

まず最初に、10Xの組織制度上EMがどのような扱いになっているかについて軽く触れます。

10Xでは事業・組織の成長を見据えてマトリクス組織を導入しています。

この体制の中でマネージャーは全職種を通してのRoleとして定義されています。

そのため10Xでは「エンジニアリング本部に所属するマネージャー」がEMの実像です。

また、マネージャーは基本的に縦軸か横軸での1つのチームを見ることになります。

各チームに求められるミッション

上記の前提を踏まえた上で各チームに求められる責務は「事業の拡大に備え、スケーラビリティのあるチームを作り上げる」ことです。

スケーラビリティのあるチームを具体的に言い換えると、「より少ない人数で多くの価値を生み出し続けるチーム」です。

私たちが日々開発に取り組んでいるStailerは、実際に商品を購入するお客さま、Stailerを利用してECを展開するパートナー企業の両面のスケーラビリティを確保する必要があります。

特にパートナー企業の増加に対してのスケーラビリティに関してはよく考えた上でシステム、組織をデザインしないとN人 x パートナー企業数のエンジニアが必要な組織になってしまいます。

事業のスケールに合わせてある程度、組織が拡大していくことは自然なことですがチームの生産性をいかに高く、維持し続けられるかも重要な要素です。

EMに求められる責務

EMはこのチームミッションを前提としながら、以下の視点を持って業務に臨むことが求められます。

自分のチームにおける「スケーラビリティのあるチーム」の定義

チームに求められるミッションがそのチームであればどういう状態なのか、を定義します。

例えば、私の所属するリライアビリティ&セキュリティ部であれば、「エンジニアが増えた時、サービス信頼性を最小のコストで維持するための仕組みはどうすればいいのか」のようなテーマを考えていく必要があります。

定義した状態を達成するためのAction Planの策定やGoal設定のリード

定義した状態と現状のギャップを埋めるための戦略策定を行います。

例えば、パートナー企業の課題に向き合うパートナー事業部は「より少ない人数でより多くのパートナー企業のサービス運用・改善を行う」という状態を目指すため、「最小工数で最速で新規パートナーのリリースを行うための自動化システムの構築」というAction Planを推進しています。

この戦略策定はEM 1人で行うのではなく、チームを巻き込みつつ必要であればチーム外のメンバーも巻き込みながら行っていきます。

チーム外に対して、チーム状態の説明責任を果たす

チームがAction Planを推進していくにはメンバー・予算といったリソースが必要です。

当然、それらのリソースは有限なのでチームの上のレイヤ、すなわち経営としてはどのチームのどのレバーを強く引くかを決める必要があります。

EMはその意思決定の質が最大化するよう、自分のチームで提示できる選択肢を説明可能な状態にし、共有していく必要があります。

また、1度引いたレバーの状況も共有し、細かい軌道修正を繰り返すことで会社全体として最適な方向へ走れるような状態を目指します。

責務は分かったけど、じゃあ具体的に何をすればいいの?🤔

EMが向き合うべき課題は状況によって目まぐるしく変わるため、その達成手段は明確に定めていません。

とはいえ、「ミッションを達成するための必要なことをやってください」だとEM経験が無い場合は手探りで仕事を進める必要があります。

そこで今年の9月に行ったオフサイトでの議論を元に、「EMがFocusすべきこと」をマインドマップの形でまとめました。

EMがFocusすべきことをマインドマップ形式でまとめたもの
EMがFocusすべきことをマインドマップ形式でまとめたもの

例えば「10XのEMはプレイングマネージャーとして振る舞っても良いか?」という問いに対しては「チーム成果の最大化」を達成する手段として有効と判断できればYesであると整理ができます。

ここに上がっているものはあくまでこれまでのEM陣の経験をまとめたものであり、10Xとして初めて直面する課題が出てきたらその時はAs One Teamでどう解決するかを考えていく必要があります。

EM定義の運用

ここに書いた内容は社内ドキュメントとして整備し、全社に公開しています。

社内で公開しているページ
社内で公開しているページ

目的は以下です。

  • 社内外含め、初めて10XのEMになるメンバーの認識を揃える
  • メンバーにも開示することでEMへの期待値の認識を揃える
  • EM間での認識を揃える

冒頭でも述べた通り、EMの責務は会社や状況、事業によって変わり得ます。そのため定期的に責務を再認識し、ドキュメント化することで認識を揃えることは重要だと考えます。

なんにせよ大事なこと

ここまでつらつらと10XにおけるEMとは、について語ってきましたが個人的に一番大事だと思っているのは、マネージャーRoleであっても「事業のあるべき姿から逆算してGoalを設定し、Issueを解いていく」のはIndividual Contributorと何も違いがないということです。

予算の調整や1on1、他チームとのMTG、評価、打刻管理等々、一見すればルーチンワークで事業につながらないように見える業務も全て、究極的には会社が成功する=事業が成長するために取り組むことです。

どんな業務であってもそれを意識できるか、できないかでは自分のマインドセットも変わってきますし、アウトプットにも影響が出ますし、何より楽しく仕事に取り組めるかが変わってくると個人的には思います。

とはいえ理想のEMの姿というのは会社の数ほどあるでしょうし、10Xにおいてもあくまで今時点での定義なので今後の事業・組織の変化に合わせてまた進化していくはずです。

楽しみですね!

最後に

10Xではエンジニアリングマネージャーを募集しています!

この記事に共感してくれた方、やりがいがありそうと思った方はぜひカジュアル面談しましょう。

「いや、俺の考えるEM像はこれだ!」という方、ぜひ情報交換しましょう!

10X アドベントカレンダーはまだまだ続きます!

明日の記事は@tenjinさんがお届けします。スラムダンク公開日を狙っての日取りなので個人的にとても楽しみです🏀