開発者向けサービス、歴史の長いサービス、フロントエンド組織のDevOps　3つの立場のフロントエンジニアが語る、開発の難しさと魅力

自己紹介

金昌熙氏（以下、金）：続いてプラットフォーム開発事例というタイトルで、座談会形式でサービスの紹介などをさせてください。本日、モデレーターを務めます。金と申します。よろしくお願いします。ふだんは「LINE公式アカウント」のサービスの開発と、社内サービスである「Private npm」の開発に関わっています。今日話してもらうみなさんの紹介をこれからします。山本さんお願いしてもいいですか？

山本竜也氏（以下、山本）：UIT4室のDev6 Teamに所属している山本竜也と申します。よろしくお願いします。前職は精密機器メーカーで、フルスタック的な感じで、インフラからバックエンドからいろいろやるエンジニアをやっていました。

担当は「LINE公式アカウント」関連の「LIFF（LINE Front-end Framework）」と、LINE広告の「LINE Tag」というJavaScriptのSDK（Software Development Kit）みたいなものの開発を担当しています。プライベートは漢字違いの推し事を少々という感じです。よろしくお願いします。

金：よろしくお願いします。続いて、前川さんよろしくお願いします。

前川剛平氏（以下、前川）：前川と申します。入社して4ヶ月目くらいの人です。ファミリーサービスの方とも、これから話すプラットフォームの方ともちょっとだけ違う、DevOpsというチームに所属しています。主なお客さんはLINEのユーザーさんではなく、社内のエンジニアになるところもほかと違うところです。

そのため、ほかのフロントエンドのエンジニアとは違い、JavaScriptは触っていますが、VueやReactなどをガッツリ触ることはしていません。先ほどのアイコンにもあったとおり、KubernetesやElasticsearch、Prometheusなど、おおよそフロントエンドと関係ない技術スタックみたいなものにガッツリ関わっています。

基本的な業務を3つ挙げています。こうした3つのサービスの開発や運用、あとはこういったツールを使用していただいているみなさんに、アンケートとかヒアリングとかを行い、そのフィードバックをもとにツールを改善していくことをやっています。よろしくお願いします。

金：ありがとうございます。最後に、佐藤さんお願いします。

佐藤信吾氏（以下、佐藤）：佐藤と申します。LINEのフロントエンド開発センターのDev7というチームに所属しています。

担当としては、LIFFというWebアプリケーションの開発プラットフォームのJavaScript SDKの開発を主に担当しています。よろしくお願いします。

開発者向けのプロダクト開発で重要視しているポイント

金：ありがとうございます。それではさっそくですが、みなさんにお話を聞いていきたいと思います。先ほどのファミリーサービスとは一味違う、今回はプラットフォーム開発という括りでみなさんに集まってもらったのですが、具体的にふだんどんなものを開発しているのか、みなさんに聞いてみたいと思います。

先ほど自己紹介でもサクッと紹介はあったと思うんですけど、まず佐藤さん。ふだんどんなものを作っていますか？

佐藤：LIFFというものが、LINEのアプリ上で動作するWebアプリケーションを開発するためのプラットフォームなんですが、そのアプリケーション側から利用するSDK、JavaScriptのライブラリを主に開発しています。

金：SDKというと、やはり使うユーザー層は同じような開発者が多いんですか？

佐藤：そうですね。開発者向けのプロダクトです。

金：なるほど。開発者向けのプロダクトってけっこうめずらしいと思います。佐藤さんは今までいろいろなものを開発してきたと思いますが、開発者向けプロダクトならではの、作るうえで重要視しているポイントとかありますか？

佐藤：フロントエンドエンジニアが関わる仕事は、いわゆるコンシューマー向けのWebアプリケーションが主かなと思うんですけれど、そこのユーザーとはやはり違っていて。開発者が僕らのユーザーということになります。

そうなると、コンシューマー向けのプロダクトを作る時とは、考えなきゃいけないことがだいぶ違っていて。例えば、僕らはSDKのセマンティックバージョニングを尊重してリリースしていますが、一度リリースしたものって基本的には変えられない。修正できないんです。

コンシューマー向けの普通のアプリケーションであれば、上書きしてリリースすればいいと思うんですが、いわゆるコンシューマー向けサービスを作る時とは違うことを意識しなくてはいけなくて。

あと、開発者がユーザーとお話したんですけど、もちろん開発者向けのDXを考慮することは大事ですが、さらにその先にいる、開発者の方が作ったアプリケーションを使って、その先のエンドユーザーの方々にどんな価値を届けられるのか。僕らはそこを考えなければいけないので、けっこうおもしろいというか。難しいところでもありますが、おもしろいところかなと思います。

金：なるほど。ほかのファミリーサービスは何回もリリースして何度でもやり直せるのですが、開発者にとっては1つのバージョンがパブリッシュされると、それは変更されないというのはたぶん当たり前のことだと思っていて。そういった違いもあって、慎重にやらなければいけない開発でもあるんですね。

佐藤：そうですね。

SDK、JavaScriptのライブラリ開発に関わるメンバー

金：開発者だからこそ、開発者目線でプロダクト作りができるのは、すごくおもしろそうだなと思いました。と言っても、全社的に使うアプリケーションを作るためのプラットフォームということで、社内でも影響力がすごく大きそうですが。プロジェクトは、何人くらいのチームでやっていますか？

佐藤：直接関わるという意味だと、SDKの開発メンバーは僕を入れて現在4人ですね。一番協業度が高いのは、この（4人の）メンバーです。

LIFFはサーバーAPIのチームと、LINEのアプリ上で専用のLIFFブラウザーと呼ばれるブラウザーを使って開発されています。そこのチームの、いわゆるiOSとAndroidの開発者の方たちと協業することが多くて。あとQAの方とPMの方を入れると、だいたい14、15人ですかね。そのくらいがLIFFチームと言われているチームで、ふだんその方たちとの協業度が高いです。

さらにLINEミニアプリというプロダクトを担当するiチームも含めるともうちょっと多くなりますね。40、50くらいにはなります。

金：1つのプロダクトを作り上げるために40、50人がいる規模って、本当にすごいと思います。そのぶん、やはりみなさんですごく議論して、考え抜いたプロダクトを作っているんじゃないかなと簡単に想像できると思いました。

LINE Tagという長いプロダクトだからこその開発の難しさ

ありがとうございます。では山本さんにも聞いてみましょう。山本さんはふだんどんなものを作っていますか？

山本：僕は先ほどの自己紹介で話したLINE Tagの話をしたいと思っています。LINE Tagの話の前に、LINE広告の話をしたいです。LINEのアプリ内では、トークリストの画面など、いろいろな画面に広告を貼っています。

その広告にどれくらい効果があったか、コンバージョン計測をしたいんですけれど、その計測をするために使うのが、LINE TagというJavaScript SDKになります。

広告を踏むと、だいたい「こんな商品あるよ」とか、広告掲載者のサイトページが出てくるわけです。そのサイトページに貼り付けるスクリプトタグとか、読み込むJavaScriptのことをLINE Tagと呼んでいます。私はそのLINE Tagの開発を担当している感じです。

金：実際に開発して出てくる成果物は、埋め込んでもらうJavaScriptファイルということになるんですかね？

山本：そうですね。Googleアナリティクスなどを想像するとわかりやすいと思うんですけど、「こういうスクリプトタグをコピペして貼ってくださいね」みたいなものがあります。それで動的に読み込まれるJavaScriptが、私の成果物です。

そのJavaScriptはいろいろなイベント情報を取ってサーバーサイドに送るわけですが、それはサーバーサイドのチームがいるので。僕の担当は、そのイベントを取って送るところの範囲ですね。

金：やっていることだけを見ると、仕様は複雑かもしれないですがアウトプットとしては簡単なプロダクトのように見えるんですけれど。JavaScriptファイルを作る以外にも仕事があったりしますか？

山本：おっしゃるとおり、やっていること自体はすごくシンプルです。読み込んで、そのページのいろいろ情報を、言ってしまえば送るだけなので（笑）。おっしゃるとおり、JavaScriptはすごくシンプルです。

ですが、いくつかちょっと難しいところがあって。もちろん仕様が複雑というのもそうですが、まず1つが、ちょっと泥臭い話ですが、LINEも古い会社というか（笑）。インターネットの企業としてはまあまあ長い会社で、同じくLINE広告やLINE Tagも長いプロダクトなんですよね。

そのため、ドキュメントなどが整備しきれていなかったり、どうしてもイケてない部分みたいなのが出てきたり、お客さんに対応しきれないみたいなところがあるので。そういうものを協業者と一緒に組んで改善したり、ちゃんと把握して整備していかなくてはいけない活動が、けっこう難しい部分です。

先ほどの「デベロッパー向けなのでリリースしたら変えられない」みたいな話に近いと思いますが、LINE Tagも結局LINEが使うのではなくて、LINEのお客さま、広告掲載者さまが使うものなので。「あ、やばい！」みたいなことが起きても、いろいろと変えられたりはしないんですよね。

もし変更する場合も影響範囲がすごく大きいものなので、そのあたりはちょっと慎重にしなくちゃいけないところもあります。なのでそのあたりをちゃんと把握して整理するようなところがけっこう難しいです。そういう意味では、実装以外の面もかなり見ないといけないという感じです。

金：そのあたりの仕様などを整理するところも、エンジニアの領域なんですね。

山本：そうですね。「エディタをひたすら叩きたい！」みたいな人ももちろんいるとは思うんです（笑）。僕も叩きたいんですけど。

ですが、サービスを実際に使ってくれるお客さまが、ちゃんと快適に、不信感を持たずに（作業）できるようにするために、LINEにも企画の人や営業の方がいるので、そういう人たちがコミュニケーションしやすいような技術情報をちゃんと整理することも大事なことかなと思っています。

技術情報を整理してお客さまに届ける仕事も魅力の1つ

金：エンジニアの仕事としては、中には「わぁ、これすごく楽しそう」とは思わない人もいるかもしれないんですけど、そういうコミュニケーションも含めて、その仕事の一番の魅力って1つだけ挙げるとしたら、なんだと思いますか？

山本：1つだけ挙げるとしたら……。

金：たくさんありますか？

山本：たくさんあるんですけど（笑）。今の話のとおり、実際にコードを書く以外の仕事みたいなところはありますが、ちゃんとその技術を使って、情報を整理してお客さまに届けるような部分が、やはりLINE Tagだからできる魅力みたいな部分もあるのかなと思います。

コード以外の成果物で、ちゃんとお客さまに機能やサービスを届けられるのは、おもしろい部分だと思います。

金：手元で開発したものを出して終わりというわけじゃなくて、そのプロダクトそのものに自身が貢献できている実感が湧く感じですかね？

山本：そうですね。その成果物の関係者も、企画から、営業から、営業の先の顧客からと幅広いので。そのあたりも見とおしながら「この情報はちょっと怪しくない？」「ここ、なあなあな感じになってるけれど、ちゃんと整理してやったほうがいいよね」みたいなコミュニケーションとかが好きな人は、すごく楽しい立場なんじゃないかなと思っています。

金：なるほど。ある意味本当にユーザー層が広いと言うか、本当にいろいろな人からフィードバックをもらえるのが、大きな魅力なのかなと感じました。

ファミリーサービスって、今日参加されているみなさんがイメージしやすいと思うんですけど、それとは違い、プラットフォームの開発ってすごく堅そうで大変そうではあるけど、それなりの魅力もたくさんあるということがわかりました。わかりましたかね？（笑）。

山本：伝わっていると思うんですけどね（笑）。

フロントエンド組織のDevOpsの仕事とは

金：先ほどのファミリーサービス以外にも、このように関われるいろいろなプロダクトがあって、本当に幅が広いのがLINEのフロントエンドの仕事の魅力なんじゃないかなと思います。今度は前川さんにお話を聞いてみましょう。

前川さんは今日話していただいた方の中でも、仕事の内容としては非常に特殊と言いますか、一番変わっていると思います。フロントエンドのDevOpsというと、パッとどんな仕事なのかイメージが浮かばないと思うんですけど。ふだん、どんなチームで仕事していますか？

前川：チーム体制で言うと、LIFFとかだと、先ほど佐藤さんに話していただいた全体だと40、50人みたいなけっこう大規模なチームだったと思います。一方で、私たちのDevOpsチームで開発は2、3人しかいなくて、それに加えてマネージャーがいるような構成なので、基本的に、ごく少人数で回している構成なんです。

仕事の大きな流れとしては2種類あって、例えば自分たちで「ここが使いづらい」とか「ここはもっとこうしたいな」というものを起点として、新しい仕組みやプロダクトを提案する。

（また、）社内のほかのエンジニアから「こういうことをしたい」とか「ここが使いづらい」みたいな相談を受けたり、困っていることを自分たちで見つけて、それを解決しようとするところから仕事が始まる感じです。

今運用しているサービスについても、使いにくいとか、わかりにくい点は開発者からフィードバックがくるので、それをもとに少人数のメンバーの間で議論をして、実装方針を固めて、またフィードバックをもらってという繰り返しが基本の業務になります。

金：自分たちで使ってみて「こうしたほうがいいね」という議論を起こして、ちゃんと実装までアクションを起こせるのは非常におもしろい体制かなと思いますが、けっこう柔軟ですかね？　チーム内で自由にいろいろ試せる環境ですか？

前川：そうですね。自己紹介でもあったように、KubernetesとかPrometheusとかElasticsearchなど、フロントエンジニアの方がおおよそ触らないようなツールばかり触っていて。

どうしてこういったものを採用したかと言うと、例えば自分たちで「これ使ってみたら便利だったよ」とか「前職ではこう運用していて、こういうベストプラクティスがあるよ」みたいな情報を、みなさん持っていて。そういうところから自分たちで提案して採用しているというところがけっこう大きいです。

LINEはVerdaというAWSみたいなプライベートクラウドを運用しているんですが、採用が難しかったり、そこに直接プラットフォームとして載せることが難しそうなものだったら「自分たちでしょうがないから作ってしまえ」みたいなこともよくしています。

金：社内からの要望ももちろんあるけど、チームの中でも必要と感じたものは全部作っちゃおうという感じなんですか？

前川：車輪の再発明になってしまうので、便利なところはちゃんと使わせてもらうというところはけっこう文化としてありますね。

知見を周りに発信できるところもフロントエンド組織のDevOpsの存在意義

金：ありがとうございます。ここまで聞くと「通常の、世間で言うDevOpsの仕事と何が違うの？」とちょっと思っちゃうんですけど。フロントエンド組織のDevOpsということで、フロントエンドのDevOpsならではの特徴と言いますか、おもしろいことはありますか？

前川：フロントエンドでのDevOpsというところが肝というか、ちょっと特殊な事情があるというのと、あとはLINEのフロントエンド開発組織「UIT」全体の知見向上に役立つという2点があります。1つ目の特殊な事情というのは、先ほど話したプライベートクラウドの上で運用しているので、フロントエンドのエンジニア用に最適化されていない部分がやはりあるんです。

例えば、CDN（Content Delivery Network）1つを立てるにも難しい設定をして、バックエンドのエンジニアと協議しながら、どういうふうに運用していくのがいいかみたいなところまで議論しなきゃいけない。そういう意味では、AWSほどドキュメントが揃いまくっているわけではないし、当然ですが、いろいろな人がインターネット上に情報を載せてくれているわけでもないです。

なので、そういうところをフロントエンドのエンジニア用に最適化することをやらなきゃいけないというのが、まず1点あります。

もう1点です。当時私はフロントエンジニアではなかったので、このあたりの話は詳しくは知らないんですけど、昔のフロントエンドエンジニアって、HTMLとCSSとjQueryがいじれて、Webサイトだけが作れればいいみたいな感じの仕事内容だったのかなと予想しています。

それに加えて、現代の技術では例えばReactとかVueとかが出てきて、一時期、サーバーサイドレンダリングなどをするような動きがあったじゃないですか。そういうことをしようと思うと、バックエンドのNode.jsをどうやって最適化していくか、サーバー周りの処理をどうやって最適化して、高速なWebサイトを配信するかというような技術をちゃんと考えなくちゃいけなくなってくると思います。

そのあたりの知識がない時に、どういった知見が必要かみたいなことを、私たちのDevOpsチームで集約して、御用聞きではないですが相談にのってあげたり、「こういうふうに運用するとより効率的に運用できるよ」「トラブルとかも回避できるよ」みたいな感じの知見を周りに発信できるところが、フロントエンドとしてのDevOpsの存在意義なのかなと思っています。

金：なるほど。確かに会社の中でもフロントエンドエンジニアを対象にしていることであって、フロントエンドエンジニアの目線から考えて、便利に使えるものを作ることが目標になっていると思うので。得られる知見やノウハウも、日々拡大されているフロントエンドの領域をちゃんとカバーできるような知見が多そうで、すごくよさそうですね。ありがとうございます。

フロントエンド組織のDevOpsメンバーに向いている人

今日参加されている方の中にも似たような経験を持っている方もいると思いますが、一言で「ずばりこういう方がこの仕事に向いていそう」というのはありますか？

前川：これは本当にずばりで。小中規模のベンチャー企業だと、システムの裏側全体を担当することになっているような人はけっこういると思います。小中規模くらいのベンチャー企業の中に絶対1人はいると思いますが、そういう人はメッチャ向いていると思います。

あと、先ほど言ったようにプライベートクラウドを運用しているので、そのあたりはAWSとかなり似せて作られている部分があるんですね。例えば、みなさん知っているようにAWSはS3というストレージがありますが、それとほぼ完全互換のストレージサービスがあったりしていて。そういう意味では、AWSを駆使してサービスを構築していた経験がある人も向いているなと思います。

金：なるほど。なにより今も知見を自分たちで作っていっている途上にあると思っていて、そこを自由に試しながらいろいろ勉強になることもあると思うので、非常にやりがいのある仕事なんじゃないかなと私は思いました。ありがとうございます。

（後半に続く）