LINEのマネージャーは“だいぶ推せる”　LINEのフロントエンドエンジニアになってよかったこと

サービスを横断したチームはあるのか

平山光太郎氏（以下、平山）：私は今LINE Fukuokaでフロントエンド組織の室長をしている平山と言います。先ほど福島から説明があったように、UIT2室という拠点もあるのですが、そこの室長もしていて、京都と福岡を主に見ているマネージャーです。今日はよろしくお願いいたします。

さっそくですが、今日は時間も限られているのでガンガンQ＆Aに答えていきたいと思います。

さっそく今日いただいた中で一番多いものからいきましょうか。一番多いのは「Front-end Dev1からDev10まで分かれていますが、それぞれの役割はサービスごとに分かれている状態なのでしょうか？　またサービスを横断したチームはあるのでしょうか？　それともサービス軸ではない理由で分かれているのでしょうか？　あとは1チーム何人ぐらいの体制でしょうか？」という質問です。では、これは福島さんに。

福島英児氏（以下、福島）：これは僕の部署説明のところで簡単にお話ししましたが、基本的には担当ごとにチーム分けをされています。けっこう大きめのプロジェクトやサービスの場合、例えばLINE NEWSであれば、Dev1、Dev3、Dev10の3つのチームが関わっていたりします。それ以外だと、例えば今日登壇いただいている花谷さんや昌熙さんは、それぞれマネージャーでチームを持っていますが、基本的には1つのチームの中にプロダクトを何個持っていたりするんですか？

平山：Dev9なので、たぶん事業部付な感じでしょうか。

花谷拓磨氏（以下、花谷）：そうですね。メインが事業部付で、みんなサブプロジェクトとしていろいろ抱えているという感じです。

福島：でも基本的には「LINEスキマニ」がメインのチームという感じですよね。

花谷：LINEスキマニとLINEバイトのHR事業にフォーカスしつつ、私であったらMeetupをやったり、他のメンバーで言うとB to DのSDKの開発に携わっているメンバーもいるので、社内で本業と副業があるようなかたちで。ちょっと他のプロジェクトの刺激を受けつつ、メインであるHR事業に還元していくかたちで仕事していますね。昌熙さんとかはどうでしょう？

金昌熙氏（以下、金）：そうですね。基本LINE公式アカウントに関連するものが多いのですが、それと連携して何か使われる、例えばお店の予約サービスやそれらとつながっているプロダクトがけっこう多いので、自然とみなさんに複数のプロダクトを担当してもらっている状況になっています。だいたい1つのサービスで小さくアサインしても、たいてい2人ぐらいはアサインする感じですね。

福島：そうですね。フロントエンドエンジニアが4、5人アサインされるプロダクトはそんなにいっぱいあるわけでもなくて、やはり2人ぐらいとか。1人、2人とかが多かったりもしますので、やはり1つのチームの中で複数持つパターンもあったりする感じですね。

チーム構成としては少ないチームで1チーム3人ぐらいですかね。大きいチームでたぶん8人。10人いっているチームはたぶんいないんじゃないかな。福岡はあるのかな？

平山：そうですね。福岡は1チームが10名のところはありますね。

福島：最大でそれぐらいという感じですね。

サーバー側のコードに触れる可能性はあるのか

平山：続いて2つ目いきますね。「サーバー側のコードに触れる可能性もあるのでしょうか？」。どうでしょう。プロダクトをやっているところで水牧さんなど、実際にどうですか？

水牧稜太氏（以下、水牧）：そうですね。実際に話をしたとおり、サーバー側のコードに触れることはいっぱいありますね。LINE証券だと我々の管理下にあるものは Node.js のサーバーなので、SSRしたいなとか、BFFしたいなというニーズをフロントエンド開発の中で感じたら開発しています。

平山：ありがとうございます。それはサーバーサイドレンダリングの文脈で触ることがけっこう多いイメージですかね。

水牧：そうですね。あとはAPIの最適化、フロントエンド側のニーズでキャッシュとかを導入したい場合に使用しています。

平山：なるほど。

水牧：フロントエンドの範疇であればサーバー側のコードであっても臆することなく我々で書くようなイメージですかね。

平山：ありがとうございます。LINEバイトでも、Webアプリケーションの範囲で、Expressを使ったサーバーサイドレンダリングするという感じですかね。

花谷：そうですね。LINEバイトとLINEスキマニともにサーバーサイドレンダリングを、そんなにまじめにやっているわけではないですが、必要に応じて部分部分で行っているので、Node.jsサーバーというかたちでは、関わることがけっこうあるのかなと思います。

それ以外でいうと、あとはLINEという会社は、バックエンドにけっこうJavaやKotlinが使われることが多くて、そこのコードの例えばAPIのインターフェイスなどは、レビューがフロントエンドに回ってくることもあるので、コードは書かないものの、サーバーのコードはこうなっているんだということを知る機会がけっこうあります。

平山：触れないほどの分業じゃないが、業務の中で触ることは意識的にやらないと難しい、と。

花谷：そうですね。

平山：なるほど。ありがとうございます。それでいくと吉澤さんはむしろサーバー管理が近かったりするんですか？

吉澤：そうですね。データベースを自分たちで設計したりとかもするので、先ほどまでのサーバーサイドレンダリングの文脈とはまた異なった、恐らくバックエンドと言われるようなことをやったりするケースはありますね。

しかし社内サーバなので、あくまでも社内サービスのため、基本的にそこまで性能をガリガリにチューニングしなければいけなかったり、データベースと直接やりとりしないでRedisなどでキャッシュを取って一時的に保存して速くしたりなど、そういったところはそこまでやらなくてもいいのですが、自分たちでサーバーサイドのコードを書くことにはなります。

コードをまったく書かないでPMのようなメンバーはいるか

平山：ありがとうございます。答えている間にさらに質問が増えていそうで、うれしい限りです。続いて「コードをまったく書かないでPM業をするようなメンバーはいますか？」。これはどうでしょう。

福島：PMは別組織にいるという感じですよね。フロントエンド向けのPMがいるというよりは事業部側にPMがいるので、フロントエンドの組織の中にはPMはいないということになります。

平山：そうですね。先ほど説明があったように、採用の段階で課題のコードを書く機会というのがどうしてもあるので、そこでコードを書く力は、ある程度試されるようにはなるかなとは思います。

メンバーへの学習コストなどはどうしているか

平山：では続いて、「フレームワークなど新しい技術を採用する際に、メンバーへの浸透や学習コストなどはどうされていますか？」。みなさん興味ありそうなところだと思うんですが、けっこうプロジェクトによっても違ったりするんでしょうか。じゃあ昌熙さんから聞いてみてもいいですか？

金：そうですね。技術選定を勝手に誰か1人が決めるというわけでもないので、基本的にみなさんいろいろ自分で勉強したり取り寄せた情報をもとに、「こういう新しいものが出ているからちょっと使ってみませんか？」みたいな感じで、そういう切り口で新しい技術を採用することが多いです。一方的に「これ採用したから、これをみなさん勉強してね」みたいな感じで時間を取って勉強したりする場面は、むしろあまりないのかなと思いますね。

なので、みなさんやはりフロントエンド技術への関心が高いから、自然にそれを楽しくて使っていると思うので、それに対して学習コストを大幅にかけているというような印象はあまりないかなと思います。

平山：ありがとうございます。「うちはこうやっているぞ！」みたいなチームはありますか？

水牧：新しいフレームワークを使うことのメンバーへの浸透は難しいなとは思っていますけど、その学習コスト自体はそこまで感じていないというのが正直なところかなと。良いフレームワークやライブラリは、だいたいやることは薄いのでそんなに学ぶことはなくて、READMEを読めばある程度はわかると思っています。Recoilだって使い方自体はシンプルなので、我々のチームでそんなに学習コストを意識することはなかったですね。

ただRecoilなどのグローバルなステート管理システムになると、使い所を誤ると負債になったりするので、そういうところはライブラリレベルというより、普通に使っていって、レビューなどで防ぐみたいな。

平山：そういったところだと学習コストを気にするというよりは、選定のところで、単一責任にすることで学習コストという意識を小さくしたりする点に重点を置いているイメージですかね。

水牧：そうですね。選定のところでは、先ほどのCSSのLinariaの話でも出しましたが、とにかく気軽に「Linariaを使いたいな」と思ったら誰かが言って、そしたらその人がメインで話し合って、メリットがありそうであれば入れるみたいな感じですね。

花谷：それで言うと、うちのチームはけっこういろいろな技術を自由に入れてみて試す。もちろんプロダクションとしてちゃんと信頼に当たるかどうかを本人の責任でやってもらいますが、そういったものは気軽に導入していって、「こうしたらいいんじゃないか」と積極的に意見交換もしているので。

学習コストやメンバーに浸透させるという、一方的に自分が広めるんだというよりも、お互いに議論をして「こういう技術を使ってみるといいんじゃないか」という結論に帰着することが多いので、そこは一方通行じゃなくて、双方向のコミュニケーションであることが、LINEではすごく多いのかなと思っていますね。

マネジメントをしながらメンバーの評価はどうしているか

平山：では一番上のいっぱい投票されている「マネジメントをしながらコードを書かれているケースもあると思いますが、メンバーの評価などはうまく行えていますか？」という質問。目が行き届いているか。これはマネージャー陣が答えていくのがいいですかね。続けてになってしまいますが、花谷さんはどうですか？　今チームは何名ぐらいでしょうか？

花谷：そうですね。今は私のチームは4人で、みんな新卒から入ってきたメンバーでやっているので、私が仕事している上でという前提にはなりますが、やはりマネージャーとして見る時と同じ開発をする同僚として見るは、メンバーを評価する時に意識的に分けています。

マネージャーであれば、例えば「チームリーダーの役割だからこういった仕事をしてほしい」という話をしますし、一方で一緒にコードを書くような機会があるからこそ、そこがちゃんとリードらしい立ち振る舞いができているかが見えるところもあって、そこは逆に多少手を動かすことがあるマネージャーだからこそ中を見れていることかなと思っていますね。

なのでマネージャーの役割だけをやっていると、他の同僚からの意見ではうまくやっているように見えても、実際にそうかどうかというのはわかりづらいかなと思いますが、一緒にコードを書く機会があると、そこは見えやすいかなと思っています。なのでだからこそ技術的なところは変に自分が持ち過ぎないところは意識して仕事しています。

平山：けっこうテックリードマネージャーというポジションに近い動きが、うちでは多い感じですかね。

花谷：そうですね。

平山：吉澤さん、水牧さんはマネージャーを見て「ちゃんと見てくれているな」という感じはあるんですか？

吉澤：私はここで4社目？　5社目？　忘れてしまいましたが、それなりに会社をジャンプしてここに来て、その中では、媚びを売っているわけではなくて、かなりマネージャーは良いと思っていますね。なんか「困ったからなんとかしてくれ」みたいな話をすると、いろいろと手を打ってくれますし、苦手なジャンルなどは代わりにやってくれますし、非常に助かっているといった感じがあります。

わりとというか、だいぶ推せる分類なのではないかなと個人的に思っています。

経営統合は現場レベルで影響や変化はあったか

平山：続いて「少し前にヤフーとの経営統合のニュースがありましたが、現場レベルでその影響や変化はありましたか？」。現場レベルでとなると、どうでしょう。けっこうMeetupなどでは見かける状態になってきていますよね。

福島：フロントエンドの組織で直接的にヤフーさんのチームと何かを一緒に開発するというケースはまだないので、そういった影響は特に何もなくて、むしろ情報共有をする機会がいろいろ増えたので、それこそ花谷さんのほうにいろいろセッティングしてもらってヤフーとの勉強会みたいなものをやっていて。あれはどれぐらいの頻度でやっているんでしたっけ？

花谷：隔月ですね。2ヶ月に1回テーマを決めて各社で。例えば直近でいうとデータビジュアライゼーションをテーマに、お互い解析基盤を持っているので、そこの共有を。その前はお互いのデザインシステムの話、みたいな感じでテーマに沿って意見交換をする機会はすごく増えたかなと。

福島：そうですね。そういったプラスのシナジーというか、そういった影響はもうあるのかなとは思います。ただ、直接の業務影響は今のところ出ていないのが現状ですね。

エンジニアの査定方針

平山：ちょっと残り時間も減ってきているので、一応事前にいただいた質問もけっこうあったので、一部表示しながらピックアップして説明していければなと思います。引き続きよろしくお願いいたします。

そうですね。いっぱいいただいているんですが、一番上のを簡単に触れておきますかね。「エンジニアの査定方針」。査定方針というか評価の話であっていますか？　長井さんから1回説明していただいていいですか？

長井綾子氏（以下、長井）：評価制度ですね。ではちょっと私のほうで話します。

評価制度は、弊社は年に2回評価のタイミングがありまして、上期と下期に分けてやっています。上期が4月から9月で下期が10月から3月となっていて、ここで年に2回の評価タイミングがあります。評価の種類なのですが、C-ReviewとP-Reviewの2つの評価を使っていまして、半年間の成果を、自分でセルフレポートというかたちで上げていただくものに対して、成果評価していくのがP-Reviewになります。

もう1つのC-ReviewはCo-workレビューのことなのですが、上司や同僚、お仕事で関わっている協業している人を自分で選んで「評価をしてください」と依頼して、というのをお互いし合います。そこで、同僚からの評価がアンケート形式みたいな感じで点数で戻ってくるものと、あとは匿名でコメントが戻ってくるようになります。

「この方の一緒に働いていてこういうところがすごいやりやすいです」というコメントと、「もっとこういうふうにしてくれたら協業がしやすくなります」というアドバイスのようなコメントが匿名で戻ってくるようになっていまして、この2つで評価をしています。

イメージとしては、半年間でこのセルフレポートのP-Reviewがもちろんメインになりますが、その際にC-Reviewを材料として、いつもマネージャーがずっと付きっきりでやっているわけではないので、ここの同僚からの評価も、評価の材料として使っているイメージで思っていただければと思います。制度としては、こんな感じです。

平山：評価において、「こういう人は評価されているよ！」みたいなのは特にありますか？　昌熙さん、福島さんあたりから聞けるとうれしいのかな。

金：そうですね。私から「こういう人が評価されるよ」というのは、たぶん技術的なスキルの高さはもちろん評価されると思うんです。

それ以上に、私としてはちょっと評価してあげたいなと思っているのは、自分が関わっているサービスにちゃんとオーナー意識を持っていて、自分がこのサービスを一緒に作っていっているメンバーだというのを意識して、ちゃんとそのサービスに対して建設的なフィードバックとか突っ込みを入れたりしているかを、自分が担当したサービスへの貢献度という面で評価しています。

平山：少し関連があるところだと、「社員の評価制度、配属先の決まり方、異動はどの程度の頻度であるのか」。評価のところは今ちょうど触れましたが、それ以外の配属先の決まり方や異動はどの程度みたいなところだとどうでしょう。花谷さんはけっこういろいろやられていたと思うんですけど。

花谷：そうですね。けっこうやりたいことが上がってきたりすると、新しい組織が出たりするので、そういったタイミングで異動が行われることはあるかなと思っています。例えば私で言うと、もともと所属していたチームが新しいかたちで再編されることになりました。それで、UIT内ですが別の組織に異動となりました。新しいチームができあがるところでだいたい何かしら動きがある。妥当な理由があっての異動が多いかなと思っています。

配属先に関しても、例えば今回新しくチームができた時も、もともと実はLINEバイトとLINEスキマニの開発を行っているメンバーはDev3チームやDev5チームに混在して散らばっていましたが、そこをHRというところで、開発を一本化したいという意味で新しくDev9チームが生まれました。なんかそういった事業上の利点とかやりたいことのコンセプトに応じて異動が行われるイメージをしていただければいいのかなと思います。

ただもちろん、本人の希望を一番尊重する会社ではありますので、チームは異動したくないというメンバーがいたら、混在したまま進むということもあるかなと思うので、チャレンジとして異動ができる。異動しなければならないというよりも（異動が）できるというようなイメージを持つのが一番いいのかなと思いました。

Reactのフロントエンドエンジニアとして関わりたい場合に必要な技術力

平山：「御社で、Reactのフロントエンドエンジニアとして関わりたい場合の、必要な技術力。また外国語が話せることはLINEでは採用の際に評価されるのかどうか」ですね。Reactでやっている証券の水牧さんはどうでしょうか？

水牧：そうですね。けっこう面接とかでもReactについての質問をしますが、そんなに難しいことは求めていないかなと思っていて。普通にステート管理など基本的なところを押さえていれば問題ないかなと思っていますね。

具体的には、Reactに限らずSPA全般に言えますが、「適切にレンダリングできているか」と、「適切に不要なリレンダリングを防げているか」の2つが大事になってくると思うので、そうしたことをReactの文脈でちゃんと整理できるかは気にしています。あとはコンポーネントの設計とか、Reactのビルド回りをちゃんと理解しているかなど、そのレベルの基本的なところを押さえていれば、特別なことはないかなという感じですね。

平山：基礎をしっかりみたいなところですよね。内部の原理とかもしっかり知っていてほしいみたいなものもありますか？

水牧：うちのチームは別にコミッターがいるとかそういうわけではないので、Reactがどう動いているかみたいなことに超詳しくないといけないといったことは全然ないですね。なので、逆にReactの内部の動きを知っていて「おい、どうなんだよ」みたいな感じの、とてもReactに強い方が入って来ていただければうれしいです。

外国語が話せることはLINEでの採用の際に評価されるか

平山：後半部分はちょっと僕のほうから補足します。「外国語が話せることはLINEでの採用の際に評価されるのかどうか」。採用の段階だと見ていないですね。英語も特に見ていないので、気にする必要はないかなと思います。

入ってからだと、やはり活躍の幅というところだとオプションにはなるので、プラスに働くことは多いと思います。ですが、日本語を第一言語として使っているので、日本語だけでもぜんぜんフィールドはいっぱいあります。その点は心配なくチャレンジしていただける環境ですかね。

フロントエンドエンジニア採用の際のコーディングテスト、課題テスト

平山：だいぶ時間が迫ってきましたが、最後に「フロントエンドエンジニアを採用の際のコーディングテスト、課題テストはどういったものになるのでしょうか？」。　ちょっと簡単に紹介しますね。先ほど水牧さんの話にもあったような、基礎というかしっかりとファンダメンタルのところを押さえているかというのを非常に重視したテストをしています。

課題提出、コーディングテストというところだと、そういった部分がしっかりとコードを書けるか、JavaScriptが僕たちの第一言語になると思うんですが、JavaScriptと仲良くなれているかは重視している内容になります。2つ目の「年収について業務や自身の成果に見合う報酬であると感じますか？」は、なかなか生々しいやつですが、どうですか（笑）。これは非常に答えづらいかもしれないんですが。

福島：評価をする側からすると、やはり成果に見合ったベースアップだったりインセンティブみたいなものはできる限り還元というか、結果としては上げたいなと思いつつ評価しているのはありますし、例えば報酬の原資みたいなのはある程度決まっているものなので、その中からなるだけ活躍した人、ちゃんと成果を出した人にはしっかりとメリハリを付けて報酬として提示してあげたいというのはあります。それが本人が見合っているか見合っていないかを感じているかどうかは、ちょっと僕からはわからないですけど（笑）。

（一同笑）

平山：僕も被評価者にもなるんですが、どうでしょうね。しっかりとやったことというのは受け止めてくれるし、それに対して答えようとしてくれるという意思は非常に感じているので、もちろんみなさん年収ないしインセンティブが多いに越したことはないと思っているので、その点は引き続き会社全体としてがんばっていければいいと感じていますね。

花谷：なんか曖昧な回答になってしまっている気がするので、せっかくだから簡単に話そうかと。まず前提としてLINEという会社はしっかりとお金を払う会社かなと私は思っています。本当に比較すると、いうわけじゃないと言いながら比較することになるんですけど、いわゆるメガベンチャーの中でもトップクラスの報酬を従業員には払っているかなと個人的には思います。

何かそこに関して、例えば海外を見据えてみたいな人でいうと、もちろん地域の金銭のレート差などもあってギャップを感じる方もいらっしゃるかもしれないですが、少なくとも国内においては、きちんと報酬を払うトップクラスのIT企業じゃないかなと思っています。なので、もちろんそこに関しては、納得感があるような報酬が支払われているんじゃないかなと思っています。

例えば海外を見据えてたり、自分で何かした場合と比較するとギャップがあるという方はゼロではないかもしれませんが、少なくとも組織において活躍に見合った報酬は基本的に支払われていると言っていいんじゃないかなと私は思っています。本当にメリハリが付いているも、上と下がしっかりとあるので、なぁなぁでお金が支払われるのではなくて、ちゃんと活躍に応じて支払われる組織になっているとは思っています。

平山：ありがとうございます。ちょっと最後駆け足な部分がありましたが、そろそろお時間なので最後に福島から締めのコメントをいただいて終わろうかと思います。

福島：はい。みなさん時間まで本日はありがとうございました。質問もいっぱいいただいて、本当に可能な限り答えたかったのですが、どうしても時間があるので、残念ながらすべてに応えることができなくて、本当に申し訳ありませんでした。今日の採用説明会を通して、具体的にこのサービスがどういったかたちでサービスをしているのかや、どういったコミュニケーションを取りながらやっているかを少しでもわかってもらえたら幸いです。

いきなり応募はしなくても、まずはカジュアル面談からで、もうちょっと話を聞いてみたいだったり、もし今日質問したんだけど答えてもらえなかったからもう一度深く聞きたいんだといったケースでもかまわないので、ぜひカジュアル面談などのカジュアルなところからコンタクトを取っていただけると嬉しいです。よりその場で質問に対してしっかりと答えたいと思いますので、ぜひともご連絡をいただけると助かります。

では以上になりますかね。本日は遅い時間までありがとうございました。登壇者のみなさまもお疲れさまでした。