“おもしろそう”で“貢献できそう”と思ったらここにいた　LINEのエンジニアが今のキャリアパスを選んだ理由

3つのキャリアパス

清水大輔氏（以下、清水）：みなさん。本日はTech@LINEに参加していただきまして、ありがとうございます。

このセッションでは『LINEエンジニア、3つのキャリアパス』ということで、モデレーターである私と、LINEのエンジニアのそれぞれのキャリアパスで活躍する3名の方に参加してもらい、LINEの中でエンジニアは実際にどういうキャリアで働いているのかをイメージしてもらえればいいなと思っています。

簡単に私の自己紹介をします。LINEのフロントエンド開発センターUIT1室という、ちょっと長い名前なんですけれども、そういった組織で室長という立場で今LINEの中で働いています。

LINEの立ち上げの時期から関わっていて、主にWebのフロントエンドのJavaScript SDKであったり、開発者向けのプラットフォームみたいなところの開発に携わっていました。

Individual Contributor、Tech Lead、Engineering Manager

今日の3つのキャリアパスでは、ここに挙げているIndividual Contributorと呼ばれるものと、Tech Lead、それからEngineering Managerについて話をしていきたいと思います。

まずそれぞれ1つずつ説明しますと、Individual Contributorは、個人の技術力をより高めて、設計だったりとか、コーディング、レビューとかを通じてチームやプロダクトに貢献する役割です。

続いてのTech Leadですけれども、Individual Contributorと同じく技術的な側面でプロジェクトだったりチームを支えるところは似ているんですけれども、チームに対する技術的な貢献がより強くなってくるところが役割として違います。

最後にEngineering Managerですけれども、メンバーのメンタリングやキャリアパスを支援していきながら、チームのアウトプットを最大化する役割を担います。LINEでは、Engineering Managerは通常だいたい5人から、もうちょっと少ないと3人とか、多くても10名程度のエンジニアのチームをまとめてメンバーのピープルマネジメントを行うほかに、エンジニアのマネジメントになるので技術的なバックグラウンドをもっていることが求められています。

登壇者の自己紹介

では3名の方に登壇していただいて始めていきたいと思います。まず簡単にそれぞれ自己紹介していただきたいと思います。まずはIndividual Contributorの松永さんお願いします。

松永寛氏（以下、松永）：Individual Contributorとして紹介されました松永と申します。よろしくお願いします。簡単に自己紹介しますと、私はLINEのメッセンジャーのAndroidの開発をするチームに所属しておりまして、そこでいろいろなLINEのメッセンジャー内部で使われているような機能の開発をしています。

入社したあとに今のメッセンジャーのチームに入って、1回マネージャーをやったあとにフィンテックのほうの部署に異動して、そこでメンバーになって、もう1回メッセンジャーの本体のチームに帰ってきて、今はマネージャーではなくて一メンバーとしてプロダクトの開発に貢献しているようなかたちになります。本日はよろしくお願いします。

清水：よろしくお願いします。ありがとうございます。では続いて、Tech Leadの尾上さんよろしくお願いします。

尾上良範氏（以下、尾上）：Tech Leadとして紹介されました尾上と申します。よろしくお願いします。私はDeveloper Product 2チームに所属しています。担当するサービスとしてはLINEログインですとか、LINE Front-end Frameworkの主にサーバーサイドの開発をしています。

サーバーサイドだけではなくて、最近ではサービス全体のシステム設計とかアーキテクチャ設計のようなものも担当することが多いです。本日はよろしくお願いします。

清水：よろしくお願いします。では最後にEngineering Managerの昌熙さんお願いします。

金昌熙氏（以下、金）：金昌熙と申します。普段はLINE公式アカウントの管理画面とかを開発するフロントエンドの開発チームに所属しています。私のチームはメンバーが6人いて、小規模なチームなんですけれども、そこのマネージャーをやっています。本日はよろしくお願いします。

清水：よろしくお願いします。

清水：さっそくQ&Aのほうで1つ質問が来ているのでちょっと回答します。

先ほど松永さんの自己紹介の中であったと思うんですけれども、松永さんは1度Engineering ManagerをやってIndividual Contributorに戻ったり、そういった役割、キャリアは選び直すことは可能で、実績としても松永さんみたいな方がいる状況です。

今のキャリアパスを選んだ理由

清水：ではさっそくお題に沿って始めていきたいと思います。今日用意しているお題はこの5つです。これに沿って始めていきたいと思います。まず1つ目ですが、今のみなさんのそれぞれのキャリアパスを選んだ理由や背景って、いったいどういうところでしょうか、ということをまず聞いていきたいかなと思います。まず松永さん、こちらどうでしょうか？

松永：一応Individual Contributorとして紹介されたんですけれども、社内でIndividual Contributorという肩書きが正式にあるわけではなくて。私としてはLINEに入ったあとに、その時々でLINEのプロダクト、メッセンジャー開発が主なんですけれども、そのプロダクトに貢献するためにはどうやっていくのがいいかなを考えながら日々業務をしていった結果、今のような状況がある感じですね。

フィンテックに1回移ったときもフィンテックの部署がおもしろそうだったので1回異動して、また戻ってきているんですけれども。その時々で一番自分がおもしろそうだと思うこと、貢献できそうだと思うことをやっていったら今のところに自然と落ち着いた感じですね（笑）。

清水：ありがとうございます。では続いて尾上さん、このあたりどうでしょうか？

尾上：私もまったく同じところがあって、Tech Leadに任命されたことも、自分で名乗ったことも実はないんですね（笑）。社内の制度としてもはっきりと役割が決められているようなものでもないです。

私も松永さんと一緒で、それぞれのプロジェクトにおいて、なんとなく自分がシステム全体のアーキテクチャの設計とかの素案を出すようになっていって。もともとフロントエンドとかバックエンドの垣根にとらわれないでシステム全体の構成を考えるようなのが好きだったので、自分の好きなところと求められているところをやっていったら自然と今のような役割に落ち着いた感じです。

清水：なるほど。ありがとうございます。では最後、昌熙さんはどうでしょうか？

金：私もお2人と同じように現場で開発をすることをメインで今までやってきていて、将来漠然とEMになれたらいいなと思っていたのですが。

私がLINEにジョインしたときにLINE公式アカウントの大規模なリニューアルプロジェクトがちょうど走り出して、そこにアサインされたんですね。そのプロジェクトは海外の拠点とか日本のいろいろな拠点が関わっていましたが、各拠点をつないで開発とコミュニケーションを行うブリッジエンジニアという役割をやっていました。メインの仕事は開発の業務だったんですけど、同じチームにいるほかのメンバーたちも自然と同じようなプロジェクトに参加することになりました。

そのタイミングで組織変更があったんですけれども、そのメンバーの中で私が一番幅広くほかの拠点とかプランナーともやりとりしていたこともあって、自然な流れで同チームのマネージャーもやるようになった感じです。なので自然の流れですね。

清水：なるほど。みなさんのお話を聞いていると、流れと言うと元も子もない感じになってしまうんですが（笑）。たぶん目の前に与えられたプロダクトだったりミッションみたいなものをやっていくうちに、周りからそういう期待や役割を求められて、みなさん今のような立場になっているんじゃないかなという感じかなと思いました。

Q&A：英会話能力は必要ですか？

清水：ここで1つQ&Aです。日本以外の拠点と作業することは、日本語以外に英会話能力が必要になりますか？　というものなんですが。先ほど昌熙さんの中で海外拠点という話が出てきたんですけれども、このあたりはどうですかね？

金：LINE公式アカウントのプロジェクトはベトナム拠点と韓国拠点とけっこうやりとりをしていたんですけれども、基本的には業務上のコミュニケーションはSlack上でチャットでやる場合が多いので、テキストベースであれば英語を使ってもいいですし、翻訳botが入っているので自分の好きな言語でしゃべってもぜんぜんコミュニケーションは問題なかったです。

重要な会議がある場合はちゃんと会社で同時通訳を手配できるので、それで会議をしたりしていました。なので日本語だけでも正直まったく問題ないような開発を進められたんじゃないかなと思いますね。

清水：ありがとうございます。関わるプロダクトだったりサービス、そういったところで英語が必要になるレベルは若干違ってくるとは思うんですけれども、今、昌熙さんがおっしゃったように、社内に同時通訳の社員もいたりして、そういった方を介して会議をすることもけっこうあります。

必要かどうかと言われると必要だとは思うのですがサポートはありますし、入社してからも英会話を自分で学習するための会社からのサポートみたいなものもあったりはするので、入ってから伸ばしていくことでもキャッチアップしていける部分はあるのかなとは思います。

おもしろいところ、難しいところ

清水：では次の質問に移っていきたいと思います。次は2つまとめてセットにして聞きたいのですが、それぞれの現在のキャリアパスでおもしろいところと、逆にチャレンジングというか、難しいと感じている部分はどういったところでしょうか？　また松永さんからお願いできますか？

松永：おもしろいところとか楽しめるところは、わりと自由にできるかな、仕事をしていけるかなというところがあります。私は別にマネージャーというわけではないんですけれども、仕様の調整とかスケジュールの調整とか、わりと自分で自由に決められるようなところがあって。

いちいちマネージャーの許可がいらないというか。自分の都合のいいようにできるわけじゃないんですけれども、関係者ときちんと話をして調整してやっていくことができれば、特にマネージャーじゃなくてもそのへんの決定をしていくことができるので、比較的自分で自由に働いていくことができるかなとは思っています。

LINEのメッセンジャーの場合、歴史が長いので制約もあるんですけれども、OS独自の新しい機能に個人開発者として世の中に先駆けて触れることができたりする機会もあるので、そういうのはけっこうおもしろいかなと思います。

難しいところとしては、ある程度キャリアを積んでいくと、特に自分でどういった成果を出していくのかとか、そういったことを自分で指標を作っていきながら働いていかなきゃいけない点は難しいかなと思います。

私はメンバーからマネージャーになって、またメンバーに戻ったりとかしているんですけれども、率直に言うと、マネージャーになるためにはどういう制度があるとか、マネージャーからまたメンバーに移るためにはどういう制度があるかっていう制度が社内にきっちりと明文化されて存在するわけではないので、いろいろな人と話したりしながら、自分でなんとかしていく必要がある部分があるのは苦痛に感じる人もいるかも。私はそこまで苦痛ではないんですけれども、大変っちゃ大変なところかなとは思っています。

清水：なるほど。ありがとうございます。では続いてTech Leadの尾上さん、このあたりどうでしょうか？

尾上：まずおもしろいところから。わりとプロジェクト全体の視点でものごとを見たり考えたりするのでいろいろ複雑な制約条件が多いことが多いんですけれども、それを実装に落とし込んでいくのがパズルのようで楽しいところではありますね。

ほかの視点としては、技術の幅が広がるとか視野が広がるということがあると思いますね。例えばフロントエンド、バックエンドの垣根なくある程度全体を見て、全体の整合性を考えなければいけないので、そこらへんの技術の幅は広がると思います。

それから仕様の策定から運用まで一連の開発の流れというか、開発後のことも考えたり、開発前のことも考えたりしなければいけないので、そこらへんの視野も広がると思います。あとはおまけみたいなものなんですけれども、全体の構成を考える立場に、案を出す立場にあるので、自分の裁量でわりと新しい技術とか入れやすい立場かなとは思います。

難しいところなんですけれども、これは先ほどのIndividual Contributorの松永さんの話と一緒です。社内の制度でTech Leadはこういうことをしなさいというようなことはまったく決まっていないので、自分でそれぞれの場面に応じてなにをすべきか、なにをすべきでないのかを考えていかなければならないのが厳しいところなので、積極的に動ける人でないとなかなか苦痛に感じるところじゃないかなと思います。

それとシステム全体に関わる話を決めることが多いので、これはプレッシャーが大きいですね。なにか問題があるといろいろなチームに迷惑をかけてしまうので、そこのプレッシャーは大きいです。

それから各コンポーネントだと、コンポーネントのチームの中でレビューし合えるとかっていうのがわりと多いと思うんですけれども、全体の整合性を見る立場の人はプロジェクトに何人もいるわけではないので、そこらへんはわりと孤独な感じで、プレッシャーはやはり大きいところかなと思います。

これは人によってだいぶ違うと思うんですけれども、時期によってはコードを書けない日があって。UMLばかり書いているような日もあるので、人によってはそれがつらいと思うかなと思います。

清水：ありがとうございます。今、尾上さんの話を聞いていて思ったのは、けっこう表裏一体というか、いろいろなところに関わって責任が重い分やっぱりそれだけ自分で考えなきゃいけない、動かなきゃいけないっていう部分があって。そこを楽しめるか楽しめないかがわりと大きな違いなのかなと思いました。ありがとうございます。では最後、昌熙さんお願いします。

金：みなさんが持っているマネージャーについてのイメージを聞いてみると、やっぱり、開発業務に関わらなくなるからマネージャーになるのが嫌だとおっしゃる方もいたりするんですけれども、LINEのEngineering Managerというポジションは、そのイメージとは違って意外と開発業務をメインでやっています。

開発業務をやりながら幅広い案件に関わって、そこで技術選定をはじめとしたいろいろな役割をやるので、自分自身の技術面での成長にもちゃんとつながっているところがいいところかなと思います。

そしてマネージャーとしてメンバーそれぞれがやっている業務について成長を感じて、それでやりがいを感じてもらえるところ、やっぱりみんなで成長していくんだなっていうのが実感できるところがいいところかなと思いますね。

その一方でちょっとチャレンジングなところといえば、幅広い案件で企画段階から最初に入って、どのメンバーがどのスキルを使って120%の力を出してそのプロジェクトに貢献できるかを測る力が必要なので、そのスキルを測る以上に自分自身も技術的な判断ができていないといけなくて。

プロジェクトをやりながらもWeb標準の動向とか、新しいOS・フレームワークが出ましたとか、そういう動向にアンテナをずっと張り続ける必要があるところが、がんばっているというか、チャレンジングなところですね。

あと開発とマネジメントを、あれもやってこれもやって100%両立させるのはちょっと現実的ではなくて、私にはちょっと難しかったんですけど。メンバーたちにマネージャーとして付きっきりで完全にマネージャーとしてサポートするのがやっぱり現実的に難しいので。

私も普段は開発業務をメインでやりながら、とある時期になったとき、例えば普段の1on1とか、評価の時期、新規のプロジェクトが立ち上がるときとかにはマネジメントに集中する。スイッチングしながら両方がんばっている感じで成り立たせているのがチャレンジングですね。

清水：なるほど。ありがとうございます。Engineering Managerとしてピープルマネジメントみたいな部分と、エンジニアとして期待されるところだったりとか、自分自身のやりたいところっていうバランスは、おそらくいろいろ試行錯誤しながらやられているところかなと思います。

（次回へつづく）