Engineering Managerを廃止して1年経ちました

こんにちは、ゆのん(id:yunon_phys)です。このエントリーはAkatsuki Games Advent Calendar 2022の14日目の記事です。昨日はMaxBaconPowerさんの「巨大数でわかる Elixir の魅力」でした。Elixirが再帰が得意とはいえ、良くこんな題材を思いついたなと感心しました。早くふぃっしゅ数を見てみたいものです。

さて本題に入るわけですが、昨年、Engineering Manager(EM)を廃止して3つに分割したという話を書きました。そこから1年経ち、どのような状態になったのか、ふりかえりも含めて書いていきます。本記事は前回の記事を読まなくても読めるようにしていますが、更に背景理解したい方は前回の記事も読んでみてください。

hackerslab.aktsk.jp

ずばりEMを無くして良かったのか

これはマクロに見ると明確に良かったと思っています。ただし、ミクロに見ていくと、良かったところ、改善すべきところは見えてきています。EMをTech評価とEngineering Office(エンジニアの人事部門)とプロジェクトマネジメントに分けたのですが、それぞれ自分なりにふりかえっていきます。

Tech評価のやり方変更

EMを無くす前は、EMがプロダクトメンバーの評価を行っていました。正確には、エンジニアメンバーが自分を評価して欲しいメンバーを選ぶという仕組みにしており、エンジニアのピープルマネジメントを行うEMが選ばれやすいという状態になっていました。この評価のやり方に大きな問題は無かったものの、アカツキゲームスとしてより技術力を上げていける組織を作っていこうという動きがあり、技術的な評価がより出来る体制を整えていくことになりました。それを実現するために各プロダクトに技術的なリード(Team Lead)の役割を作り、Team Leadがエンジニアメンバーの評価を行っていくよう評価体制を変更しました。また、これと共に普段から技術的な相談がリードに出来るようにと、普段の1on1もTeam Leadが行うようにしました。

この変更により、評価内容に技術的な内容がより盛り込まれるようになり、メンバーの成長・会社としての技術レベルがアップしていくための土台が出来てきました。評価者が変わったことで評価水準のすり合わせをより細かくやらなければいけなくなりましたが、それは組織をスケールさせていくためにも必要なプロセスだなと感じています。

一方で、このやり方は必ずしも全員がハッピーな変更とは言えませんでした。おわかりのように、Team Leadは突然ピープルマネジメントを追加でやることになったわけです。業務をうまく分散できないと、Team Leadに負担がいってしまう構造にどうしてもなってしまいました。特に、技術のスペシャリストとしての価値貢献が大きい方・価値貢献をしたい方からすると、このTeam Leadの役割追加が良いやり方ではありませんでした。各エンジニアのキャリアパスを考慮したTeam Leadの任命、Team Leadの業務がより分散出来るようになるためのEngineering Officeのサポートのあり方など、この制度を持続可能な状態にするためにはアップデートが必要だと感じています。

Engineering Officeの設置

エンジニア組織における人事としてやることは、主に、①どうやって良い人を採用するのか(採用部門)、②どうやって在籍しているエンジニアの価値を最大化するのか(組織開発・人材開発部門)、の2点に集約されます。過去は採用専門部隊と組織開発・人材開発部隊を分けて運用していたのですが、以下の問題がありました。

1. 採用部門としては、採用した人がどのような活躍をしているのか、情報を取りにいかないとわからない(自然と入ってこない)

2. 組織開発・人材開発部門としては、どのような採用が走っているのか把握しきれてないので、人材配置を最適化できない

これらは結局のところ、採用部門と組織開発・人材開発部門でどう情報の透明性を上げるのか、という課題に集約されます。でも、何も無いところから情報の透明性を上げるってめちゃくちゃ難しいです。今まで情報の透明性が無かったからこの状態になっているわけで、文化としてやっていきましょう、の一言ですぐに変わる問題ではないです。文化として根付かせるためにはそれなりに発信し続けないといけないし、情報共有されていなかったら、共有しましょう警察を発動させなければいけません。そのコストを払うぐらいだったら、自然と透明性が上がるような仕組みづくりをしよう、となるのは自然な流れです。そこで、採用部門も組織開発・人材開発部門も一つの部署にすることで、人事情報の流動性を上げるようにしました。その一つの組織のハコとして、Engineering Officeを設置しました。

Engineering Officeには、EMだったメンバー、エンジニア組織を人・組織面から支援していたメンバー、人事に興味のあったエンジニアメンバー、採用を専任にやっていたメンバーなどが在籍することになりました。意識したのは、それぞれが何を担当しているかをわかりやすくすること、そしてみんなでフォローしあえるようにすることです。Engineering Officeは組織を裏で支えるインフラのような役割で、誰かがいないから出来ません、というのは許されません。なので、誰かが欠けてもすぐに別の人で対応出来るように、運用が必要な業務には2人以上人員をアサインするようにしました。

また、Engineering Officeには元のEMとしての業務も内包しています。その中で地味に工数を使うのが異動周りです。アカツキゲームスは複数のタイトルの運用・新規開発を行っていて、人員を増やさなければいけなくなった、減らさなければいけなくなった、チーム異動を希望している人がいる、などが頻繁に発生します。さらに、新卒の配属、採用などの要素も複雑に絡んできます。これらの情報を整合させて漏れなくやっていくためには、全てのプロダクト・プロジェクトの人事情報をEngineering Officeに集約させるようにしました。人事情報を集めるためにやったことは、3つあります。

人事情報を集めるためにやったこと1つ目は、各プロダクト・プロジェクトのTeam Leadとの定例です。Team Leadは普段からチームの状態・チームのメンバーの状態を把握しているので、Team Leadから直接ヒアリングの場を持つことが最適です。そこで上がってきた、各メンバーのモチベーションだったり、プロダクト状況・プロジェクト状況により、人員配置を検討する材料にします。増員が必要なときで他チームからの異動が難しい場合は、採用も行うように進めます。

人事情報を集めるためにやったこと2つ目は、最低半年に1回、全エンジニアと1on1するというものです。普段の業務の話はTeam Leadや他のメンバーと十分しているので、キャリア観のような中期的な話をすることを目的としています。その情報から、Engineering Officeで出来る行動をしていきます。例えば、「もうちょっと今の仕事が落ち着いたらXXのプロジェクトで働いてみたい」という声が上がったときに、半年後にそのメンバーが異動出来るようになるためにはどうすれば良いんだろうというコミュニケーションをTeam Leadと話し始めたり、そのための採用を始めるなどです。

人事情報を集めるためにやったこと3つ目は、Engineering Officeとして集めてきた情報をNotionで一元管理するというものです。せっかく上記のように集めてきた情報も、それぞれの担当者の手元で管理しているようでは情報が回遊していかないので、Engineering Officeのメンバーであれば誰でも情報が見えるようにNotionに集約しました。

上記のように、エンジニア組織の人事業務を組織的に行える状態を作ってきましたが、まだまだ課題があります。今は人事情報を積極的に取りに行くことで次のアクションを決めているわけですが、増員に対しては急に出来る話ではないのでどうしても後手に回りやすいです。2~3年後にどのようなプロダクトが立ち上がるのか、それに向けて他のプロダクトがどうなるのかを予測して、どのぐらいのレベルの人材を、何人ぐらい増員が必要かを検討し、早めに採用を進めるアクションにつなげられるようにしていきたいです。

プロジェクトマネジメント職の立ち上げ

EMを無くす前は、各プロダクトの開発チームにEMが入り、スクラムマスターとして振る舞ったり、他セクションとの調整などを行ってきました。その役割に対して、より専門性も求めながら、人員の増強も必要となってきたので、プロジェクトマネジメント職を立ち上げました*1。

プロジェクトマネジメント職を作って良かったことは、専門性を社内で認識してもらえたことです。進捗管理だけでなく、本質的な課題解決に踏み込むこと、そして自動化や業務の簡単化により業務効率を上げることに対して組織全体としてポジティブになりました。1年前と比較して、今社内にいるプロジェクトマネージャーのような人がもっと欲しいという声が明確に聞こえてくるようになりました。これまで役割が言語化されていなかったときは、業務の間に落ちたボールを拾ってくれる人ぐらいの認識だったのが、言語化することで、業務の間に橋をかけてプロジェクトを前に進めてくれる人になったのはとても大きな進歩だと感じています。

また、プロジェクトマネジメントの一定水準のスキルはどのリーダーも持つべきだと考えています。その方が全体的に前に進める力も増しますし、プロジェクトマネージャー自身も改善行動を動きやすくなります。そのため、次期リーダー候補の方がプロジェクトマネジメントを学ぶ目的で異動するのを積極的に組織として受け入れますよ、と社内で伝えています。実際にその目的で一時的に異動してくるメンバーも出てきています。時間はかかるでしょうが、リーダーの基本知識としてプロジェクトマネジメントが必須となる未来が来ると良いなと思っています。

プロジェクトマネジメント職の立ち上げ事態はうまくいったのですが、今後のタイトルの増加に対して全然人員が足りていない状況です。いろんなセクションの課題解決をしながら、毎週開催される新規イベントのためにミスなくデプロイ業務を行える体制をつくるのは少人数ではどうしても難しいです。ちょっとでも興味が出た方は、是非こちらからご応募ください。

EMという役割はいらないのか？

じゃあEMという役割っていらないのか、でいうと僕はそうは思っていないです。もっと小規模なフェーズだったり、技術も人事もプロジェクトマネジメントも全部出来る人がいるのだとしたら、その役割はあっても良いと思います。アカツキゲームスの場合は、なんとなくいろんなことをやる存在としてEMというポジションをおいていましたが、何をする人なんだっけを改めて言語化してみたら、上記の3つの役割に分解するのが妥当であるという結論に行き着きました。

皆さんのエンジニア組織運営の参考になれば幸いです。

明日はぐんそうさんが、「新卒2年目、リーダーへの挑戦」というテーマでエントリがあるそうです。どんなリーダーシップを発揮しているのか楽しみですね！

*1:昨年の記事を見てプロセスマネジメントじゃないの？と思った方がいるかもしれませんが、やっぱり大きな領域を将来的に任せられるようにしたいということでプロジェクトマネジメントという名前になりました