LINEのエンジニアリングマネージャーが語る、優れたEMの条件と求められること

エンジニアリングマネージャーの1日

御代田亮平氏（以下、御代田）：よろしくお願いします。

「エンジニアリングマネージャーの1日」と題して、御代田がお話しさせていただきます。弊社のイベントによく来ていただいた方もいるかと思いますが、よく出てくる人です。

（会場笑）

Twitterをまだフォローしていない方は「@LINE_DEV」を、それからgithub.com/lineで、オープンソースを公開していますので、フォローしてください！

「エンジニアリングマネージャーの1日」というタイトルですが、エンジニアのマネージャーポジションも募集しているので、応募いただければなと思っています。

ちなみに、マネジメントをやってらっしゃる方はいらっしゃいますか？

（会場挙手）

お一人、お二人……。過去にやってらっしゃった方は？

（会場挙手）

なるほど、わかりました。ぜひご検討いただければと思います。

ちなみに現場のエンジニアの方々にも、「LINEのマネージャーはこんなことを考えてるんだな。こういうことを考えている人の下なら安心して働けるだろうな」と感じていただくためにこのセッションを設けています。

自己紹介です。

僕は生まれてこの方数年周期で京都と横浜を往復しています。大学院の時から理化学研究所で働いていて、その後新卒でGoogleに入り、Twitterで4、5年働きました。LINEに来て3年ほどになります。そういう意味で僕はUターン組です。というのは去年の8月ぐらいまで新宿オフィスで働いていて、京都オフィスに引っ越してやってまいりました。

開発者向けAPI、SDK製品のPMをやったり、最近では京都オフィスの主にサーバー寄りのエンジニアリングマネージャーをやったりしています。

京都オフィスのエンジニアリングの概要を説明させていただいて、その後にエンジニアリングマネージャーの役割も紹介しようと思います。そして最後に「求める人物像」もお話ししようと思います。

京都のオフィスのチーム構成的にこのような感じになっています。

クライアントチームがいたり、サーバーチームがいたり、フロントエンジニアがいたり、Clovaチームがいたり……。あとは大学と共同研究をしているチームなんかもあったりします。

何を作っているかですが、例えば先ほどでてきたSDKをやっていたり、Fintechまわりのプロダクトをやっていたり、JSのライブラリだってあるし、CMSのツールもやっていたり、インフラまわりやNLPなど、この辺も後で担当者が実際に話をすると思います。

他にはアカデミアやリサーチなどを行っています。それからこの「？？」の部分。これはまだ決まっていないプロダクトという意味でもそうですし、今後弊社にジョインしてくれる方が考え出してくれるだろうということで「？？」にしています。

TECH STACKSをざっと挙げてみました。

細かいところは各セッションで出てくると思います。

LINE KYOTOは全体的にどういう感じなのかというと、これも繰り返しになりますが、まだ少人数です。

「Initaitive」「Public speech」を会社として奨励しています。それから仕事はエンジニアリングのみです。

エンジニアのマネージャーという観点でみると、僕自身、パブリックな場所でスピーチする機会をOKRに入れていただいたりしています。というのは、やはり外で話をするには自分で体系立ててテクノロジーを理解する必要があり、それをまとめるのはシニアなエンジニアにとって重要な作業なので、そういう意味で奨励しています。

それから公用語が英語だったり日本語だったり。毎週金曜はオールハンズをやったり、バーベキューやったり、Lunch ＆ Learnをやっています。

これはおそらくLINE全体で言えることですが、1つのオフィスですべて完結するプロダクトはあまりありません。京都もまさにそうです。LINE KYOTOは現在エンジニアのみ所属しており、海外出身者も多数いる状況です。

一方で、東京のオフィスや、とくにビジネスサイドの方には日本語のみの方も多いので、日本語能力を必要とするようなプロダクトは京都にはあまり合いません。

あえてそれをやると、エンジニアとしての本来やりたいことに時間が費やせないようになってしまう可能性があります。そういうこともあり、LINE KYOTOはエンジニアだけで解決するようなプロダクトを優先的に手掛けています。

これは弊社だけでなくいろいろな企業もそうだと思いますが、ヘッドクォーターから離れたところに研究所があったりしますよね。そういったイメージで捉えてください。

というのも、ヘッドクォーターに近いところでは緊急でやらなきゃいけないことや、来期のロードマップを大幅に変更しなければいけないぐらい緊急で差し込みのビジネス的な要件が入ってくることがあったりします。そうすると、本来エンジニア的にやりたいことがなんだかんだ後回しになってしまったりするので、そういったことは京都になるべく寄せようとしています。

それからエンジニアドリブンにはいいところも悪いところもあります。良いところで言うと自分たちでオーナーシップが持てることです。なんでも好きにやれることはいいことですし、技術的な追及もできる。一方、悪いところとしては、事業との調整や他拠点の折衝や協業は必ず会社として生じます。

エンジニアリングマネージャー、プロダクトマネージャーとしてどういうことをやっているかというと、こういった弱点部分をカバーするのが重要な仕事です。

エンジニアリングマネージャーの1日

ここから、本題のエンジニアリングマネージャーの1日の話に移っていきます。

今週のある日の1日を取ってみました。この日だけ見ると、だいぶブラック感が出てしまうんですけど……。

（会場笑）

子どもを保育園に送ったり、1 on 1をやったり、SDKチームのスタンドアップに加わったり……。VCはビデオカンファレンスですね。東京やソウルのチームとミーティングをやったり。他には「Catch up w/ QA Team」とありますが、これは弊社の場合、エンジニアリングマネージャーと言ってもただ単にヒューマンマネージャーじゃなくて、必ずプロダクトのオーナーというかたちで、技術に関わらせるようにしています。

そのため、僕も本来テックリードだけでいいかもしれないミーティングにも参加していたりします。それから面接をやったり、英語の勉強をしています。

エンジニアリングマネージャーとテックリードの違い

よく、エンジニアリングマネージャー以外にもテックリードやプロダクトマネージャーという職種がありますが、正直被るところも多いと思います。

大きい規模の会社であればそれほど被ることはないかもしれませんが、とくに小規模、中規模の会社さんでは兼任することもあるかと思います。ただ、どれも共通のタスクとして、ロードマップのプランニングやリソースのプランニングは必ず生じる仕事だと思います。

ちなみに、現在4、5人のチームのテックリードをされている方はいらっしゃいますか？

（会場挙手）

あまりいない。エンジニアのキャリアパスとしてみなさんテックリードを目指すと思いますが、テックリードとエンジニアリングマネージャーの違いって何なのかをご説明します。

「。」で終わっているものと「、」で終わっているもの。

テックリードは技術をビルドするのが仕事です。エンジニアリングマネージャーは技術をビルドするチームをビルドする仕事なんですね。

例えば、テックリードはコードレビューやアーキテクチャの設計を非常に楽しむというか、そこに価値を見出す人はこちらの仕事が合っていると思います。

一方でエンジニアリングマネージャーは、チームが「WOWな技術」を作り出してプロジェクトが発展していく。それが築かれていくことを楽しむ人は、おそらくエンジニアリングマネージャーが合っていると思います。そういう意味で、実は後者の立場はPMの立場にもわりと近いですね。

それから、テックリードのEMにとってKPIは何かというと、テックリードはコードレベルのテクニカルな成功が一番大きいKPIだと思います。

一方でエンジニアリングマネージャーのKPIは何かというと、チームやメンバーがそれぞれにアウトプットしてきた成果物のそのものの成功や、メンバー自身のキャリアの成功が非常に大きなKPIになってくると思います。

3つの数字で考える

PMとEMの仕事を比較する際、僕はよくこの3つの数値を出します。

PMの仕事もEMの仕事も、コアの3つの数字に関しての考え方は一緒です。1つ目「開発者が開発に注げる時間」、これを最大化することが目標です。

それから「無駄にならないコードの量」。例えばコードを1,000行書いたら、その多くが無駄になってしまうようなロードマップの引き方やリソースの配分をしていたら、それはPMやEMとしていい仕事をしていないということになります。それをなるべく減らすための努力を裏で支えたり、リリースした機能が実際のユーザーや他のサーバーのサービスに使われるかどうかの勘所ですね。そういうところを最大化するのもロードマップを作る上で重要な仕事だと思ってます。

例えば、開発に注ぐ時間を増やしてあげるためにどうしているかというと、例えばコンシューマ向けのある新機能をサポートするバックエンドチームのEMだとしたら、よくあるのは、新機能が法務的要件をクリアしているか法務から問い合わせがあったりします。そういったことは、エンジニアのマネージャーが資料を作ったり説明をしたりしてカバーしています。

ただこの辺はライトな話で、例えばサービスAがライブラリBに依存していて、Bの変更がAにとってBreaking Changeであるが、AとBとのテックリード間の話し合いでまとまらず、にっちもさっちも行かなくなる。それで2クォーター、3クォーター経っても何も進化がない状況だと、AとBのテックリードに僕から話をしたり、お互いのEM同士でコンフリクトを解消して、現場のエンジニアのみなさんがコードに専念できるような環境を作っています。

他にも、そもそも使える技術や依存ライブラリを一緒に考えたり、静的解析ツールなんかを使ったり、どう見てもより戻りが起こりそうなリクエストを影でプッシュバックしたりしています。

それからよくあるのが、既に開発した機能で十分足りることを「こういう機能を開発してほしい」とリクエストがあったら、そのリクエストを元に事細かく説明して納得していただいたりしています。

優れたEMとは？

最後に、優れたEMとは何か？　今言った仕事以外でもEMの仕事はあるので、どんなことが必要なのかを説明します。

先ほどの3つの掛け算以外に、EMの非常に重要な仕事として「リソースの確保」があります。これはエンジニアリソースですね。それからチームやメンバーの個々の成長も大きな仕事です。

リソースの確保という意味では、当然エンジニアリングリソースもさることながら、エンジニア以外のリソースの確保にも奔走しています。それこそ今週あったのは、例えばUXデザイナーやデベロッパーのリソースを確保できないかいろいろ交渉したり、必要があればジョブをオープンして募集したりといったことをやっています。

それから、チームやメンバーの成長について。むしろこれが1番重要な仕事かもしれません、これについてもう少し細かく説明しようと思います。

ちなみにチームやメンバーの成長はリソースの確保と似たようなところもあります。というのは、例えばリソースの確保といったときに、当然各人がやりたい領域にうまいことアサインしてあげるのが僕らの大切な仕事だと思うので、そういう意味ではメンバーのみなさんから見たらこの2つは似たような仕事だったりします。

ゴールを理解させる

先ほども言ったようにEMの目標に立ち戻ってみると、「技術をビルドする、チームをビルドする」のが仕事です。ただ、強いチームを作りたいじゃないですか。みなさんも『サカつく』とか『パワプロ』でもやったと思います。

弱小チームだとやりたくなくなるじゃないですか。なので、じゃあ「強いチームってなんだろう」と考えると、強いチームはゴールを理解しているんですね。ゴールを理解すると何がいいかというと、ゴールを理解すると自発的に進んでいきます。

だいたい強いチームというのは、ゴールをしっかり理解して、メンバー同士がお互い競争しながら、支え合いながら進む環境になっています。おそらくエンジニアリングマネージャーの持っている1つの仕事としては、ゴールを各人に理解させるのが重要です。

ゴールにもいろいろなステージがあると思っていて、まずはパーソナルなゴールがあると思います。これがそもそもない人は、いろいろ問題があるので考えなおさなければいけません。

その後、個人の上にはチームという概念があります。まずはチームのゴールを理解してもらう。そしてチームで携わっているプロジェクトのゴールがあって、会社や所属する大きい組織のゴールがあると思います。ですので、まずはこういったゴールを理解してほしいと考えています。

それからPMやEMって必ずプロジェクトのWikiの最初に、バックグラウンドなどを書くと思います。そういうかたちで、なぜこんな機能を作るのかを理解してもらうために、いろいろなことをやっています。

なので、時にそれが足りなかったら1 on 1などでフォローアップしています。チームとしてどういうゴールがあるか、さらに言うと同じチーム内の他のメンバーがどういうゴールを持っているかを理解してもらうのが非常に重要です。

先ほどお話しした「毎週金曜にオールハンズで飲み会をやっている」とか、たまにバーベキューをやっているのは、ただ肉を食べたいだけじゃなく、チーム内の、もしくはチーム外のソーシャルな結びつきをつくることで、同じチームや隣のチームのあの人がどんなゴールを持っているのかを理解してもらうためにやっています。

こういったことをしっかり理解すれば、きっとみんな自発的にすごいものを作ってくれるだろうという期待のもとでチームを作っています。

メンバーの成長を考える

メンバー自身の成長についてどんなことを考えているかというと、当然チームとしてのアウトプットはメンバーの成長に大きく依存するわけで、会社としてゴールを達成するということは、メンバーの成長以外のなにものでもなかったりします。

さらに言うと、そもそもメンバーの人生が掛かっているので、一番頭を悩ませる問題です。

そのために、一人ひとりのエンジニアが、ジュニアのエンジニアからシニアになってほしいと考えています。シニアであるとは何かというのはわれわれエンジニアリングマネージャーも理解しなければいけなくて、そういった意味で、いろいろなプロジェクトを経験することで、どういった人が優秀なエンジニアなのかを理解してもらうために、みんなに経験を積んでもらっています。

「シニア」を念のためググってみたらこんなものが出てきたんですけど……。

（会場笑）

たぶんこういうことではなくてですね。

シニアであるというのは、1つ目に挙げている「コードレベルでの高い技術力、技術のキャッチアップ・選定力」というのは、おそらくどんな方でも「これがシニアであることだ」と思うと思います。

当然これは非常に重要ですが、これだけではありません。シニアなエンジニアというのは、例えば何かの技術を作るときにも、自分がそのプロジェクトに永遠と関わるわけではなくて、新しいメンバーも入ってくるかもしれないので、ドキュメントなども含めた高いメンテナンス性を自分のプロジェクトの中で発揮できるかを考えています。つまり、最終的な成果物への責任感が、シニアのエンジニアは違うのではないかと思っています。

もうちょっとくだけて言うと、高い目標をセットして半分闇で泣きながらでもがんばれる力というか、がんばれる感を身に付けてもらうことも、われわれの仕事です。

求める人材像

それからエンジニアのキャリアパスのサポートのためには、どこにやる気のスイッチがあるのかを見極めて、適切なプロジェクトにアサインしています。先ほども言ったように、当然メンバーのキャリアパスがIC（Individual Contributor）なら、つまりずっとエンジニアをやっていきたい方ならば、シニアになるために何が欠けているのかを見極めて、このステージをサポートしていたりします。

ときには、エンジニアを一生やらなくてもいいわけで、それ以外のキャリアパスも勧めてみたりしています。先ほど上がっていたようなプロダクトマネージャーやエンジニアリングマネージャーをやりたいと言ったら、それをサポートしてあげたりしています。

まとめです。

オーナーシップを取ることはリスクを取ることだと思います。そのうえで、技術や自分自身、さらに言うと周りのメンバーを成長させたい、させることができる人を求めています。

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

（会場拍手）