Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

Engineering Managerの役割を無くしてみた

こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2021 の22日目の記事です。

アカツキでは数年前よりEngineering Managerの役割をおいているのですが、この度、Engineering Manager(EM)の役割を公式に無くしました。私の個人的な活動で、EMによるEMのためのPodcastをやっている*1、社内でもそういう活動を知っている人がいるし、世間からするとお前がそれを言うのか〜と言われそうなのでなかなか勇気のいる決断でした。ただ、今後の会社の方針を考えたときに、今見直すタイミングなんじゃないかと思い、思い切って無くしてみました。

本記事ではなぜ無くすことにしたのか、これからどうしていくのかを書いていきます。

EMのやることが消滅したわけではない

アカツキのEMはエンジニアのマネジメントと、プロジェクトマネジメントが主で、techのマネジメントも必要とあらば入っていました。

なぜこれだけいろいろなことをやる役割が必要なのかでいうと、プロダクトには、エンジニアだけでなく、プランナー、ディレクター、プロデューサー、デザイナー、QA、マーケターなど様々な職種が入っているからです。それらの様々な職種が混在するプロダクトチームが一体となって開発・運用を行うためには、狭い領域の専門性を磨く人も必要でしたし、広くプロダクトチームをカバーする人も必要で、EMは後者の役割でした。

ただ、EMといえどスーパーマンではないので、人事領域に強い人もいれば、プロジェクトマネジメント領域に強い人もいて、同じEMと言えども強みの発揮のやり方は違っていました。近年ではモバイルゲームがより成熟化してきていて、高度な専門性が求められるようになってきました。高度な専門性が求められれば求められるほど、同じEMと言いながら異なる強みを利用して価値を発揮しているようなEMに対して、EMは何をする人なのか、という質問が至るところで湧いてくるようになりました。さらに、Engineering Managerという言葉の響きからtechのリードとしての期待が暗黙のうちに持たれることもあり、その期待とのずれから、それぞれのEMの強みが否定されかねない状態になってきました。

私は、EMを社内にも社外にも広めた立場であるものの、EMという名称を使うことでこういったネガティブな状態になるのは本意ではありませんでした。一方で、EMのやっていたことがいらなくなったわけではないです。どの業務も必要だったからEMという役割が存在していたのは間違いありません。そこで、EMという名称を社内から無くしはするが、これまでEMが担っていた役割をどうすればより良い形で組織で実現出来るか、もう一度役割を整理し直しました。そのために改めて、エンジニア組織をどういう組織にしたいのか、ゼロベースで考えました。

より技術力を高められる組織にしたい

まず、考えたのは、アカツキの技術力をもっと高めたいというものです。技術力がもっと高まれば、より豊かなゲームの表現が出来るようになり、プレイヤーにもっと満足していただけるゲームが作れると信じています。

そのためには、未来の技術を考え、技術を引っ張るリーダーの存在と、技術を正当に評価する体制が必要だと考えました。

技術リーダーを設置した

これまでのエンジニア組織はCTOとVPoEの体制になっていて、CTOが全社の技術を引っ張る役割、VPoEである私がエンジニア組織の組織マネジメントを行う役割として分かれていました。しかし、技術発展は著しいため、それぞれの技術の専門性をもった技術リーダーの存在が必要となってきました。

そこで、モバイルアプリケーション側を専門とするClient Engineering Leadと、サーバー・インフラ側を専門とするServer Engineering Leadの2人の技術リーダーをエンジニア組織に設置することにしました。この2人の技術リーダーが存在することで、これまでCTOに全ての技術の相談が行っていたところを、2人の技術リーダーに分散することができ、さらに、より深く、未来の技術に向けた話が出来るようになりました。

評価体制を変更した

元々はエンジニアの納得感を優先して、評価されるエンジニアが評価者を選ぶという仕組みにしていました。EMがプロダクトチームのエンジニアのマネジメントを行う機会が多かったので、評価者としても選ばれやすかったです。これはこれでうまくいっていたところは多かったですが、技術的に組織全体を引き上げるということに関しては、目標設定・評価の段階で組織だって動けていませんでした。

今回2人の技術リーダーを設置したことで、より未来の技術の方向性がクリアになっていくため、評価もこの2人が最終意思決定出来るようにするのが良いと考えました。とはいえ、現在いるエンジニア全体を2人が評価するのはさすがに無理があるので、プロダクト単位で評価が行えるようにTeam Leadを各プロダクトに設置しました

Engineering LeadはTeam Leadと、Team Leadはエンジニアメンバーと目標設定のすり合わせと評価のすり合わせをします。さらに、Engineering Leadはエンジニアメンバーの目標設定の内容も確認し、高い目標を掲げられているか、伸ばしたい技術の方向性として正しいかもチェックしていきます。

Team Leadがエンジニアメンバーの技術評価をする責任を持ったことで、今後プロダクトチームで技術的な課題が出たときは、EMではなくTeam Leadが担うことになります。これにより、EMの役割が一つ分解できました。

よりエンジニア組織の人事領域を強化したい

エンジニアが増えていく中で、採用ニーズが複雑化、エンジニアのキャリア形成が多様化などが課題となってきました。

これまで、VPoEである私を中心に、各プロダクトに配属されているEMたちと定期的にやりとりを行ってこのあたりの整理を行ってきました。しかし、プロダクト増にEMの採用が追いつかなかったり、1人分の仕事がそもそも無かったりと、エンジニアのマネジメントを満足に行えていない現状がありました。

Engineering Officeの立ち上げ

そこで、Engineering Officeの部署をエンジニア組織内に立ち上げ、エンジニアの採用ニーズやキャリア形成のための相談をサービス化することにしました。また、これまで全社の人事部門にあったエンジニアの採用部隊をこのEngineering Officeに統合することで、エンジニアの人事全般を一手に引き受けるようにしました。

Engineering Officeには人事領域に強みのあるEMが入ることになりました。さらに、人事領域に元々興味のあったエンジニアメンバーも入ることにもなりました。Engineering Officeが設置されたことで、エンジニアの一つのキャリアパスに人事が加わったのは、組織的に一つ深みを増せたと思います。

ちなみに、Engineering Officeはメルカリさんの影響を大いに受けているので、この場を持って感謝の言葉をお伝えさせていただきます。ありがとうございます!!

よりプロジェクトマネジメントの領域を広く、深くしたい

EMはこれまでスクラムマスターとしての動きをしていたり、開発チームの課題発見・解決を行ってきました。しかし、いざゲームの運用となると、開発チームのマネジメントだけでなく、アセットを作ってデプロイする運用チームのマネジメントであったり、開発した機能をうまく運用にのせる必要がありました。これまではなんとなく、いろんなやり方でうまく回してきたのですが、モバイルゲームがより成熟化していくにつれ、プロダクトチーム全体の動きをうまく統合してマネジメントしていくやり方が求められるようになってきました

また、開発チームのプロセスをマネジメントしたり、運用チームのプロセスをマネジメントする人は、今後のプロダクトが増えていくときに無くてはならない存在です。一方、大規模ゲーム開発・運用経験 × プロジェクトマネジメントというのは、専門性も要求されるばかりか、そういった経験を積んでいる人はあまりにレアな存在であるため採用も難しいという課題がありました。

プロセスマネジメント職の立ち上げ

そこで、開発のプロセスや、運用アセットの製作プロセスをマネジメントするための専門職を立ち上げました*2。エンジニアだけでなく、プランナーやデザイナー、QAなどの様々なバックグラウンドを持つ人がこのプロセスマネジメント職*3に就くことで、それぞれの経験や人脈を活かしながら、プロダクトチームの課題を解決出来るようにしていきます。そして、このプロセスマネジメント職を社内で育成できる体制を整えることで、採用に左右されることなく、長期的な目線でプロダクトの増加に備えることになります。

プロジェクトマネジメントに強みを持っていたEMがこの職に就くことで、よりプロセスマネジメントの専門性を深めながら、プロダクトチームに影響力を発揮していくことになります。

実はこの職が出来ることでもう一つ嬉しいことがあって、スクラムマスターを採用出来るようになりました。今まで、EMがスクラムマスターとしての役割も担っていたと書きましたが、逆にスクラムマスターに対してもEMとしての役割も期待していたが故に、より広範な知識や経験を要求してしまい、採用が難しかったという側面があります。これからはスクラムマスターにはスクラムマスターとしての業務のみを期待するようになり、よりスクラムマスターとしての専門性を評価出来るようになるので、良い方向に向かうと確信しています。

最後に

以上のように、EMという役割を無くすところから始まり、エンジニア組織を一から考え直してみました。結果として、今考えられる中で一番良い形になったのではないかと思います。

また数年後にはやっぱりEM復活しました、と言ってそうですが、組織はそのときに一番あった形に最適化していくのが当然やることだと思っているのでそのときはご容赦ください:)

*1:更新が滞っていてすみません

*2:正確にはこれからではあるのですが

*3:プロジェクトマネジメント職ではなくプロセスマネジメント職。プロジェクトマネジメントとすると、これまたいろんな業務を期待されてしまうことがわかった。いろいろ話を聞いていくと、プロジェクトマネジメントに期待しているのはほぼほぼプロセスマネジメントだとわかったので、あえてプロセスマネジメントとすることで業務の幅を想像しやすくなるようにした