Interviews/

西野 裕貴 / サーバーサイド

自己紹介をお願いします
LINE開発1室 Bot Platformチームの西野裕貴です。高等専門学校で情報技術を学び、卒業後に大学に編入し、2020年にサーバーサイドエンジニアとして新卒入社しました。

LINEに興味を持ったきっかけは、高専の時の先生がLINEに勤めていたことです。働きやすい環境だというエピソードを聞いていて、それがとても印象に残っていたんです。当時のIT系の技術職はあくせく働くようなイメージを個人的に持っていたのですが、LINEはそうではなく、エンジニアの意見が尊重され、最新の技術も取り入れられる環境だという話を聞き興味を持ちました。

また、大規模なデータを処理する仕組みに興味があったので、就職でも大きなサービスを手掛けるIT系を考えていました。実は就活らしい就活はしていないのですが、インターンなどでいくつかの企業を見ていく中で、やはりLINEが良いなと思ったんです。メッセンジャーを軸として様々なサービスを展開するLINEは大量のデータを処理することから、自分のやりたいことにも近いと思ったんですね。加えて、最先端の技術を様々に取り入れられる環境であることも大きな魅力だったので、入社を決めました。

入社後はサーバーサイドエンジニアとして、LINE公式アカウントが使用する「Messaging API」の開発や、そのバックエンドの開発にも携わっています。その他にも、サービス自体の信頼性を上げるサーバーサイドのシステム開発や、リクエスト処理の仕組みの開発も行っています。
業務内容や具体的な流れを教えてください
自分が所属するチームは、LINE公式アカウントやその関連のサーバーサイド開発を担当する部署になります。バックエンドシステムの信頼性やパフォーマンス、機能性の向上を目的に構成されているバックエンドタスクフォースにも所属しています。

チームのサーバーサイドエンジニアとしての業務は、主に3つあります。新規APIなどの開発業務、アプリケーションなどの改善業務、そしてAPI利用者からの問い合わせ対応です。

順番にお話しすると1つ目の新規開発業務は、 LINE公式アカウントの利用者である企業向けの機能や、そのCMSなどをプランニングするチームからの提案や、APIユーザーからの問い合わせなどをきっかけに新規機能開発が決まっていきます。例えば、 LINEの新機能をLINE公式アカウントからも利用可能にする企画や、現在ご利用されている企業の阻害課題などを解決する企画などがよく提案されますね。

開発側からの提案で開発が始まる機能もあります。例えば、Messaging APIに2021年6月に追加された LINE公式アカウントのトーク画面で表示される「リッチメニュー」を切り替えられる「リッチメニューエイリアス」。これは、開発側から提案して実装が実現したものでもあります。

新規開発は企画担当者とも連携し、チーム内で仕様の相談をしながら進めていきます。必要があれば情報セキュリティの部署とも相談を行います。例えば、外部に初めて露出する情報がある時や、個人情報の取り扱いに関連する仕様が発生する時などですね。 実装が完了したら、GithubでPull Requestレビューを依頼し、approveが得られたら動作検証用のbeta版をリリースします。加えて、社内のQAチームに依頼して品質確認も行っていきます。機能に関する社内共有用のドキュメントの執筆も依頼し、必要に応じて技術的に正しい記載になっているかどうかのレビューも行います。

QAの完了後、正式なリリースとなります。リリースの際にはテクニカルライティングの専門チームとも連携し、関連ドキュメントや開発者向けニュースの掲載などを行ってもらいます。例として挙げたリッチメニューの切り替え機能も開発者向けニュースが公開されているので、興味のある方は見てみてください。

ここまでで新規開発自体は完了となりますが、その後も有志により開発が行われているline-bot-sdk開発などを行う場合もあります。

2つ目の改善業務は、アプリケーションに関するものや、それに限らず何か発生している問題の解決などを行う業務です。改善点を発見する起点は様々で、週次のプラットフォーム安定性検証の会議で見つかったり、日常のモニタリングで見られるエラーログやアラート発生状況の見直しを元にアプリケーションの改善点を探すこともあります。

Messaging APIのユーザーからの問い合わせや要望から業務が発生することもあります。例えば、ある特定の機能についてユーザーが使いたいコマンドが使えないという要望があった場合に、改修して使えるようにするなどですね。

流れとしては、開発者向けプロダクトを公開しているLINE DevelopersというWebサイト上で公開している開発者向けプロダクトについて、社内外のユーザーからの問い合わせに対応するチームとのミーティング等で内容が共有され、改修を検討します。自分のチーム内で完結する改修の場合は、チャットやミーティング、Pull Requestなどで相談しながら改修していきます。とはいえ、私の所属するチームは担当しているコンポーネントが多いことから、自分自身、まだまだ触っていないコンポーネントも多いのが現状です。わからない部分はチームメイトに相談したり、質問したりしながら進めていっています。

自分のチームで完結しない、つまり他チームとの協力が必要な改修の場合もあります。例えば、改修範囲がサービスで使用しているサーバーやCMSまで及ぶ場合などですね。時には、発生した問題の原因が、サーバアプリケーションで利用しているOSSライブラリに存在する場合もあります。そういう場合は、必要に応じてOSSライブラリの内部実装を調査したり、バグがあった場合はIssueを立てたり、Pull Requestを送るなどの活動をします。それらが結果的に、OSSライブラリへの貢献となるようなこともありますね。

最後が、社内のAPI利用者からの問い合わせなどを起点に始まる業務です。これはコンポーネントについての調査依頼から始まる場合もあります。

対応としては、LINE社内のデータプラットフォーム「Information Universe」のログなどで調査したり、スクリプトを書いてデータ取得や調査などを行っていきます。既存のプログラムを改善する場合はレスポンスタイムやアクセス数、ストレージへのアクセス数などを考慮します。新規に実装する場合は、関連する機能がどれくらい利用されているかのデータを参照し、その機能がどれくらい利用されそうなのかを推測したりします。それらの結果を踏まえ、問い合わせなどに回答したところで業務が完了になります。
仕事を進める上で、意識していることはありますか
「データドリブンであること」、「ユーザー視点で設計すること」、そして「楽しんで取り組むこと」の3つがあります。

1つ目の「データドリブンであること」は、プログラムの実装やレビューする際に意識することですね。出来る限りログやデータを元に議論をしたり、実装することを心がけています。既存実装の改善の場合はレスポンスタイムやアクセス数、ストレージへのアクセス数などを考慮します。新規実装の場合は、関連する機能がどれくらい利用されているかを確認して新規機能がどれくらい利用されるか推定したりします。

2つ目の「ユーザー視点で設計すること」は、実際にAPIなどの機能を使う際にどういった仕様だと便利か、ユーザーの気持ちを考えながら設計と実装を行うようにしています。これはAPIユーザーなどに限った話ではなく、社内に対しても同じ意識で動いています。例えば社内共有用のドキュメントも、理解しにくいと作業する人が困ってしまうので、相手目線に立ち、読みやすく書くようにしています。

3つ目の「楽しんで取り組むこと」は、例えば自分が今まで触ったことがないような技術を使ったり書き方をしたりするなど、自分なりの挑戦をしたり新たな学びを得ようとするような動きを心がけています。その方が経験を積めますし、自分自身も楽しく取り組めますからね。
おもしろいことや難しいことなど、働く中でこれまでに得た感触を教えてください
特にやりがいを感じるのは、技術的な好奇心が満たされる瞬間です。LINEではたとえばApache KafkaやHadoopなど、これまで自分が今まで触ってこなかったライブラリ、ソフトに触って開発を行えているので、とても楽しいです。多様な強みや経験を持ったエンジニアたちが書いたドキュメントも色々と見れるのでとても有意義な勉強ができる環境だなと感じています。

反対に、自分に課題を感じる面もあります。冒頭でお伝えしたように、大規模データの処理に興味を持って入社しましたが、業務を経験していくうちに、たくさんのリクエストを処理することの難しさも見えてきて、入社前には想定できなかった課題点を発見するようになってきました。「なるほど」と理解を深めると同時に、まだまだ頑張らねばならないなとも思います。LINEには技術書を経費で読める制度もあるため、そういった制度も利用しながら勉強を重ねる日々ですね。

必要な素養はいくつかあると思いますが、API設計の業務においては自分で勉強しておく必要があると思います。APIはリリース後、ユーザーに実際に使われていく機能なので、リリース後のことまで想定しながら作る必要があります。リリースした後で修正が発生しないようにするためには、ある程度の知識は必要だと思います。

API設計に限らず全体的に必要となるものとしては、コミュニケーション能力ですね。自分は入社当初から、新型コロナウイルス感染症の影響でリモート環境で業務がスタートしました。相手の状況がわからないオンライン環境で話し掛けることは最初は不安もありましたが、それでも業務のためには話し掛けにいける能力は必要だと思います。これは所属するチームに限った話ではなく、企画やQAのチームなど、社内の様々な関連部署も含めた話ですね。オンラインだと尚更ではありますが、これはオフライン環境だとしても同じく必要な能力だと思います。
LINEに入社して良かったと感じることはなんですか
日本国内のコミュニケーション基盤でもあるLINEで、大量のデータを処理する技術経験を積めるのは大きなメリットを感じます。影響力が大きいことは時にプレッシャーでもありますが、それはやりがいの裏返しでもあります。自分がリリースした機能が使われ始めると、やっぱりすごく嬉しいんですよね。リリースした直後は、データを見て「ちゃんと使われてるな」と確めたりしてしまいます。LINE公式アカウントを見て、実際に使っていただいているのを実感することもあります。

スキル面でも成長を感じます。例えば、最初にPull Requestを出した時にはコメントの数が50~60件も付いてしまったんです。その時はリクエストの出し方やコードの書き方などに関する指摘もいただいていたので、それらを改善することで、現在はコメントの数も減りました。本来必要な、コード自体へのアドバイスを中心にいただけるようになっていったのは成長だと思います。

これはLINEの強みでもありますが、コードレビューが盛んな文化があり、時にはプロジェクトに直接関係ない、上位役職のエンジニアがボランティア的にレビューしてくれることもあります。そこから得られる学びは大きくて、知らなかったものを吸収できることもあるので感謝しています。「LINEっていいな」と思うポイントでもありますね。

知識面でも成長を感じています。例えば入社当初は、触ったことがない技術の話題がミーティングで出てくることもありました。時には内容が理解しきれないままミーティングが終わってしまうこともありましたが、後から調べて勉強するうちに知識もつき、現在はそういうこともなくなりました。本を読んだり社内のWikiで調べたり、あるいは気になるコンポーネントを「これって何をしているものなんだろう?」と見にいったりするうちに、自然と知識が身についていった感じですね。業務に関係あるコードは見ようと思えば見に行ける環境なので、自分が担当する範囲以外の部分から学べることも多いなと思います。

実際に開発する中で、手詰まりが起きることもあります。そういう時には、今お話ししたように自分で調べて勉強することはもちろんですが、それでもわからない場合にはチームの皆が助けてくれるんです。ウィークリーやデイリーのスクラムで聞いてみたり、コードに落とし込んでPull Request上で「悩んでるんですけど、どう思いますか?」と相談したりすることで、大体のことが解決できています。自主学習だけではどうしても限界があるので、先輩や同僚のエンジニアからたくさんの学びが得られるのはとても良い環境だなと思いますね。
最後にメッセージを
自分自身、入社前から興味が幅広い方で、「色んなことをやってみたい」と思っていました。LINEはまさに様々な技術に触れられる環境なので、業務に携わってく中で自然と多方面に強くなっていける環境だと思います。

あとは、筋が通ったものであれば、エンジニアの意見がちゃんと尊重されるのもとても良い風土だなと思います。「言われた通りに作らなければならない」というような場面も、全く無いんです。業務内容のくだりでお話ししたように、むしろ「あった方がよいのでは」とエンジニアが考えた機能を自分から提案でき、実際にリリースすることもあるくらいですからね。

LINEのバックエンドはコンポーネントが多くて、色々なアプリケーションが動いていることも大きな特徴だと思います。必要性があれば、自分が使ってみたい技術を導入できるチャンスもあるので、そういうところもエンジニアにとって魅力的だなと思います。

とはいえ、実際に入社してみないとわからないところもあると思います。自分が入社したのは恩師の影響もありましたが、面接の過程まで含めて「LINEが自分に向いている」と思えたから入社を決めたという経緯がありました。もし少しでも興味をお持ちいただいているのなら、まずはエントリーしてみるのも良いのではないかと思いますね。