「手を動かしたい」派の私が「EMもけっこうおもしろい」と思うようになった理由　“プロダクトの成長”から見てわかる、2つの役割のシームレスさ

このセッションの想定読者

k-murakami0609氏：それでは「エンジニアとしてチーム改善してたらEMになってた話」をします。

まず想定読者としては、EMに対してモチベーションが上がらない人向けの発表になっています。私の前に発表した方々は、EMという職種に関して少なからず目指していた方々です。（その方々とは）逆に、自分のスキルセットを無視した場合、私はエンジニアとして活躍したいと思っているので、少しだけ毛色が違う発表になると思っています。

わざわざEMのエンジニアセミナーに来ている方でこの条件に当てはまる人はいないかもしれないと思いつつも、このテーマで発表します。

自己紹介

自己紹介です。はてなidはk-murakami0609で、村上と呼ばれています。2019年にはてなに入社して、ずっとノベルチームに所属しています。2022年からEMっぽい仕事をしていて、2023年7月頃に正式にEMに任命されました。

具体的に何をやっているかは後ほど詳細を話しますが、普通に機能開発も行っているし、1on1だったり評価だったり、いわゆるピープルマネジメントっぽいこともやっています。

続いて、簡単に何をやっているチームかを紹介します。ノベルチームは「カクヨム」「魔法のiらんど」という小説投稿サイトを運営しています。特にカクヨムではKADOKAWAさんと共同開発ということで、KADOKAWAさんからはドメイン知識、はてなからは技術や他のサービスで培ったUGCの知識などを持ち寄って開発しています。

カクヨムは日々PV数が伸びています。2022年時点で月間のPVが約5億のサイトになっています。また、最近では星野源さんのラジオでカクヨムの小説が紹介されていたり（して）、「サービスがどんどん使われているな」という実感があります。

続いて、私がどれだけ手を動かしたい人間なのかというのが一番わかりやすいのが転職の履歴だと思うので、（スライドに）書いてみました。

大半は手を動かしたいという理由で転職しています。この流れでいうと、私ははてなから転職することになっているんですが、今のところ、EMというロールが「けっこうおもしろいな」という気持ちになっています。

今日話すこととしては、私がEMをやっている理由を3本立てで紹介します。

また、今日の発表の前提として、はてなのEMロールについて紹介します。私の理解ではただのロールで、エンジニアとの上下関係もないし、特にEMだからといって給料が上がるわけでもありません。

一方で評価されやすいポジションだとは思っています。これは、テックリードに意思決定や技術の難しいところが舞い込んでくるので（一般的に）評価されやすいという構図と、あまり変わっておりません。

EMを「けっこうおもしろな」と思うようになったわけ

では続いて、EMに満足している話をします。まず私の志向としてですが、「良いプロダクトを安く早く、お客さんに届けて（お客さんに）喜んでほしい」というところを大事にしています。また、無駄を無くすことがすごく好きです。理由としては、明白な無駄を取り除くことはプラスに働くことが多いからという理由と、改善の理由として説得力があり、効果が実感しやすかったり、タスクが容易だったというのもあります。

こういった志向からどういったアクションをすることが多いかというと、開発上の無駄を削ってユーザーの価値の向上につながる部分に時間を費やすとか。（作業において）どこから着手するかというと、コスパが良く、自分の得意分野だったり、干渉しやすい部分から着手していきます。

そして具体的にどのあたりから着手するかというと、私はエンジニアなので、得意領域であるシステム領域からスタートすることが多いです。例えばCIを速くしてみたり、Lintを整備してみたりというのがあります。ただ、特にはてなに関しては元からある程度揃っているので、コスパが良いものがだんだん減っていくんですよね。そうすると次に何をするかというと、チームスコープで改善できるものはないかを探し始めます。

例えばレビューが高速に回る仕組みを考えてみたりとか、定常作業の負荷軽減をしてみたり、ドキュメンテーションがもっと良いかたちにならないかを考えてみたりします。こういったチームの課題ってけっこういろいろあると思うんですが、私は同じチームに3年間ぐらいいて、気になるところはだんだん駆逐していった状態に現状はなっています。

そうなってくると、次に「じゃあ良いプロダクトを生み出すためにインパクトの大きい改善ってどこだろう」と考えていくと、「個々の成長を促したり、支援していくといいよね」的な考えに至りました。

例えば成長を考慮してタスクを振ってみたり、日々の1on1や仕事や雑談を通じて得意・不得意や好き嫌いを見つけてみたり、評価を通じて成長を支援してみたり。こんなところが挙げられます。

こうして見てみると、やっていることだけに注目するといろんなことをやっていそうなんですが、根本の部分としては、プロダクトを成長させるための改善の延長しかやっていないということに気づきます。

この気づきがあってから、「自分にとってEMロールってどういうものなんだろう」と考えた時に、裁量が大きくてジェネラリストである自分には、とてもEMはマッチして、良いポジションだなと考えるようになりました。

抵抗のあったピープルマネジメントに対しての意識が変わったきっかけ

次にピープルマネジメントについて話します。と言っても、ピープルマネジメントには最初は抵抗がありました。（そこから）意識が変わるようになったきっかけを紹介します。

1つは、同僚が「チームの性質は所属する個人の性質による」と言語化してくれたということがあります。

「良いチームが良いプロダクトを生み出す」ということはなんとなく自分でも実感としてはあったんですが、「じゃあ、良いチームとは何か」を考えた時に、十数名規模のチームであれば、メンバー個人の影響が大きいんだろうなと考えるようになったので、ピープルマネジメントに興味が芽生えてきました。また、過去の失敗を通じて、人が育たないとプロダクトが育っていかないことを理解しました。

これから、私の過去の失敗について紹介します。以前、「立ち上げから4ヶ月ほどでプロトタイプを作ってほしい」という（要件の）プロジェクトに入りました。自分ととても多忙な先輩と、今回作りたいものとスキルセットが違うエンジニア2名の4名構成になりました。

4ヶ月ということを考えると、自分が1人でやり切ったほうがいいと判断をして、8割、9割を自分で作る選択をしました。結果として、4ヶ月で作りきるということは実現できました。その後、私はプロトタイプが終わった段階で別のチームに異動して、そこでも1年間ほど開発を行って、また元のチームに戻ってきました。

（戻ってきてからチームが）1年間でやったことを見てみると、いなくなった期間で追加されている機能がけっこう少なくて、ビックリするぐらい開発速度が落ちていることに驚愕しました。

当時、私は「この人たち、なんでこんなに仕事をしていないんだろう」と思っていたんですけども、その後に転職をして何年か落ち着いて当時のことを振り返ってみると、自分がメンバーを育ててこなかったり、必要な知識が共有できていなかったので開発速度が落ちて、プロダクトの成長が着いてこなかったんだろうと考えるようになりました。

言葉にしてみれば「そりゃそうだろう」という感じですが、私の実感として、プロダクトの成長には人の成長が必要なんだとわかることができました。私はプロダクトの成長が一番の楽しみなので、人の成長も自分の関心のスコープに入れたほうがいいんだろうなと、この頃から考えるようになりました。

そういったきっかけもあって、今は、ピープルマネジメントもただチーム改善をする手段の1つではないと気づくことができました。

エンジニアとEMの両立にはメリットがある

続いて、エンジニアとEMの両立について話します。EMに関して私が以前思っていたことなんですが、「マネージャーはコードを書いてはいけないとか、書かないように（して、）メンバーを教育するのが正しい。マネージャーはピープルマネジメントをするもの」といった考えが（自分の中に）ありました。

しかし、私は別に状況によってはコードを書いてもいいなと思っていて、EMとエンジニアを両立することはメリットがあると考えています。

わかりやすい例でいくと、最近あったのは「このタスクをAさんに渡したいけど、一部分は難しい」とか、「一部分は興味なさそう」という時に私が巻き取って、タスクをアレンジすることで、プロダクトの進捗と個々の成長を両立させられるということがまぁまぁあります。これはただの一例ですが、EMとエンジニアの両方の立場を担っているからこそできる判断や行動がさまざまあると実感しています。

一方で、実際のところはどうなのかという話なんですが、忙しくはあるロールに就いています。ですが、現代的なチーム開発ではチームの規模がピザ2枚ルールに収まるようになっているので、このぐらいの規模であればなんとかなっています。ただ、もっと見る範囲が増えた場合には、手を動かすことを少しずつ手放していく必要があるんだろうなとも思っています。

また、今のチームに関しては、テックリードを別のエンジニアにお願いできていて、テクノロジーマネジメント方面は強く分業できているので、それもうまくいっている要因かなと思っています。

エンジニアかEMかはどちらでも良い

まとめとして、エンジニアかEMかを迷っている人がいたら、私はどちらでも良いんじゃないかなと思っています。むしろエンジニアは「EMとは」と考え始めると職種間に落ちるボールがあると思っていて、「ある一面においてはこの2つの職種はつながっている」と考えたほうが、チームを構築する上では良いことなのかなと思うようになっています。

また、EMもエンジニアもやっていることは違うように見えますが、チームの改善という視点で見たら案外シームレスかなと思っています。

今日の発表を聞いて「EMになろう」と思う人だったり、逆に「エンジニアのままでいいや」と決断する人が増えたらいいなと思っています。

ご清聴ありがとうございました。