2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
提供:LINE株式会社
リンクをコピー
記事をブックマーク
松野徳大氏(以下、松野):それでは、渡邉さんのところで言うと、チームの構成とか開発規模とかコミュニケーションの言語はどういうようなものが多いのでしょうか?
渡邉直樹氏(以下、渡邉):チームの規模だと、5〜10人ぐらいのチームがたくさんあるみたいな感じですね。複数チームでBtoBのプラットフォームを開発していて、LINE公式アカウントは5チームとかで作っています。かつ、僕らの部署だけじゃなくて「開発4センター」以外にもbotのバックエンドみたいのを作っているチームもいて、たくさんのチームと協業して、トータルでいくと100人ぐらいになるのかな、みたいな感じですね。
広告も、開発を日本でしている部分もあるし、韓国側にも大きな開発拠点があって、そこにもたくさんのチームがあって、協力してやっている感じになります。
言語は、基本的に日本の中ではやっぱり日本語でコミュニケーションをとっていますが、さきほど言ったように、韓国にも大きな開発ブランチがあるので、コミュニケーションは韓国語と日本語でやる感じになっています。幸いなことに韓国語って日本語と文法がほぼ一緒なので、けっこう機械翻訳でもきれいに翻訳してくれます。なので、ふだんのコミュニケーションは、Slackとかだったら翻訳Botを入れてやっていたりとかしています。
会議のときは、実はLINEの社内に通訳のチームがいまして、その方たちに入ってもらうと、広告って専門用語がいっぱいあるんですけど、専属通訳なのでその専門用語をちゃんとわかった上で通訳してくれるという。非常にそのへんが強みというか、僕らとしては楽ですね。
一応社内でも外国語講座みたいなものがあって、最近ちょっとサボっているんですが、僕は韓国語講座を3年ぐらいずっと受けていて、ちょっとした韓国語だったら、しゃべれるという感じです。
タイと台湾にもけっこう大きなブランチがあって、LINEのサービスはけっこうタイ・台湾でも使われているので、LINE公式アカウントはタイや台湾でも会議するときがあります。
たぶんタイは、ほぼ英語でコミュニケーションをとっていると思います。台湾に関しては、専属の日本語通訳さんがやっぱりいてけっこう精度よく通訳してくれるので、通訳さんが入ったり、いないときは英語でコミュニケーションをとったり、みたいな感じですかね。
松野:佐藤さんのところはどういう感じになっていますか?
佐藤春旗氏(以下、佐藤):先ほどは「LINEアプリのサーバー側」とかなりざっくり言ったんですけど、そういう単位ですと、拠点はもう東京・福岡・韓国を含めてやっていますし、トータルでは100名を超えています。
一方で、それぞれの個別プロジェクトのチームは数名〜10名いかないぐらいの規模でやっているのが多いです。私が関わっている「LINEスタンプ」「LINE STORE」「ホームタブ」「ウォレットタブ」みたいなところだと、拠点は主に東京と福岡になっています。
ただ、チームの構成的にけっこう英語をしゃべる方が多いので、Face to Faceはもちろん相手によるけど、日本語か英語ということが多いですね。分量としては、ドキュメントだとかコードレビューを英語にしているというのもあって、あくまでもイメージとしては英語の分量がけっこう多いかなと思っています。
松野:なるほど、ありがとうございます。
松野:質問がいくつかきているので、そちらをここでお答えしていこうと思います。
一番質問が多いのが、「バックエンドの開発言語は何になりますか? 適材適所で言語が異なってくるのでしょうか?」というところで、これは非常に気になるところというか、一番基本のところかなという気がしますけれども、奥田さんのところは何を使っていますか?
奥田輔氏(以下、奥田):実際にHadoopやElasticsearchl、Kafkaを触られている方はご存じかもしれませんが、基本的にはJavaですね。そのあたりのOSSがJavaで成り立っているというのもあります。
あとは、ストリーム・プロセッシングはだいたいFlink on Kubernetesでやっています。なので、そのあたりもJavaが多いわけですが。ただ、FlinkはJava以外にもPythonやScalaなどをサポートしていますので、PoCだったりある程度の規模であれば、そういったもので作ってみて、どういった動きで、どのロジックが妥当なのかというのを検証したりします。
あとはやっぱり、種々のサーバー管理とか、あとはデータプラットフォームといっても、やっぱりなにかしらフロントエンドでいろいろやったりするツールが必要なので、そういったものは、Pythonがメインで使われているという印象ですね。
松野:なるほど。ありがとうございます。栗原さんのところはどうですか?
栗原:私のところでも変わらずというか、基本的にはJavaもしくはKotlinで書いているところが多いかなと思います。一部、Perlで書いてあるところもあるんですが、今後Java化していこうかなという感じになっています。今回サーバーサイドということなんですけれども、アプリ側で言うとSwift、もしくはJava、Kotlinという言語を使っている感じになっています。
松野:ありがとうございます。僕の実感としても「全社的にはJavaが8割ぐらいで、一部Kotlinで開発したりとか、Go、Scalaを使っているところもあるかな?」ぐらいの感じだと思います。
それでは次の質問。「ほかの部署やほかのブランチとの協業はどのように行われていますか?」「(協業すると)プロジェクトに関わる時間がかかりそうですが、どのように解決しますか?」というところなんですが。先ほど佐藤さんのところでは福岡と一緒にやっている話がありましたけど、どういったかたちで協業されているかとか、あとは「協業で起こる問題を解決するためにこういうことをやっているよ」みたいなところがあれば、ぜひお聞きかせ願いたいと思いますけれども。
佐藤:今ですと、ブランチの違いはあんまり意識していないことが多いかなとは思います。お互いのブランチにあるサーバーサイドのエンジニア同士という意味では、かなり密接に協業できていると思います。
心がけていることとしては、よくプロジェクトを始めるときに、だいたい関係するチームであるとか部署のみなさんを集めてキックオフをして、ラフにそこで何をしたいのかなどを今後どう進めていきたいのかを共有してから、いろいろなプロジェクトが始まることが多いと思います。
サーバーサイドエンジニア同士は、今だとweeklyでミーティングをしていたりして、そういう意味でも、同じチームとして同じプロダクトを扱うということは心がけていたりとか、積極的に共有しようと意識していますね。
松野:なるほど。海外のブランチと一緒に開発していることが多そうな渡邉さんは、どうでしょうか?
渡邉:僕らのところでも、そんなにブランチを強くは意識していなくて。通訳さんを呼ばないと、会議がやりづらいみたいなものはあるのですが、基本的にはチームがけっこう細かく分かれていて、ずっと協業して長い間やっているので、あんまりそのへんは負荷は感じないですね。
プロジェクトに関わる時間がすごくかかりそうというのは、おっしゃるとおりなんですけど、わりとそのへんはみんなこなれてきて、「何が最初に必要か?」みたいのがわかってきているので、会議する前に事前共有をしっかりやったりとか、あとはチャットベースでコミュニケーションを事前にしておいたりとか。あとは、先に「僕らはこう考えているよ」みたいのをざっと書いておいて、「先に共有しますね」みたいに渡しておくことをして、スピード感を失わないようにしていますね。
コミュニケーションは、本当に通訳さんと翻訳Botでなんとかなるし、なんとかならなければ、いざというときは片言の英語で誤魔化す、ゴリ押すみたいなときもあります。
松野:なるほど。ありがとうございます。あとは「開発をプライベートクラウドでやっているといっていましたが、AWSやGCPなどではなく、独自なものを使っているのでしょうか?」という質問が来ていますが、佐藤さんの部署ではどういうふうにしていますか?
佐藤:そうですね。LINEのサーバーサイドはかなり昔からあるので、社内のといいますか、LINEのデータセンターにある普通の物理的なマシンも使っているんですけど、社内で別の部署が開発してくれているプライベートクラウドの「Verda」があります。今だと基本的にはその「Verda」を使うことが多いですね。
AWSにあるEC2のようなコンピューティングノードの機能であるとか、ロードバランサの機能とか、最近だとKubernetesの機能をそのプライベートクラウドが提供してくれています。今だと、メインはやはりコンピューティングノード、実際にVMをもらってそれをサービスに使うということが一番多いんですけど、規模的にはサービスによりますが、数百台、場合によっては数千台という規模でプライベートクラウドを使っています。
松野:なるほど。プライベートクラウドでやっていて、逆にパブリッククラウドを使いたいなとか思うことはないんですか?
佐藤:そのあたりはチームによるのかなと思いますが、やっぱりプライベートクラウド「Verda」の開発者が社内にいるので、必要なら直接話をして機能開発を一緒にしたりします。特にKubernetesなんかは、もちろんパブリッククラウドを使うというのも魅力的な選択肢だと思うんですけど、いろいろとまだまだよくわからないところやおそらく技術的にチャレンジングなところもあって、そういったところに一緒にチャレンジできているのはおもしろいところかなと思っています。
松野:なるほど。LINEの規模だとサーバーの台数も非常に多いので、自社でプライベートクラウドにするメリットが非常に大きくなってくるのかな、と個人的には思っています。データプラットフォームとかもすべてプライベートクラウドに載っているのでしょうか?
奥田:そうですね。今現在は基本的に「Verda」。ただ、プライベートクラウド外、いわゆるオンプレ……今はもう完全にオンプレというような世界観で運用・構築したほうがいいレイヤがあるので、本当にサーバールームですね。ルームの中でどうラックを設計して、その中でネットワーク帯域とかを専用にもって、その中でHadoopとかKubernetesを動かしていくということを今現在やっていて。
ちょうど今年のプロジェクトがそれで、もともとはなにかほかのサービスと共用で、誰かがすごいクエリを回してサービスサイドに影響が出て、「何やってんだ?」みたいな感じになることがあったので、今年の大きな目標として、ちょうど僕のプロジェクトだったんですが、別のセンターに、今まで10Gのネットワークを25G、本当に2.5倍のネットワークでよりネットワークを贅潤に使えて、ほかのサービスとのアイソレーションも行えるような移行プロジェクトが、本当に先月ぐらいに完了しました。
ちょっと細かいところは残っていたりするんですが、やはりネットワークのアイソレーション、そういったデータセンターの設計が入ってくるところは、プライベートクラウドとは分離して使ったりはします。
ただ、それ以外の、例えばサーバー、サービスサイドとつなぐパイプラインとかは、プライベートクラウドを使ったりするような現状です。
松野:そうですね。やっぱりLINEぐらいの規模になってくると、自社でデータセンターを借りて、しっかりとやったほうがいい部分が出てくるのかなと思います。
まだいくつか質問がありますので。「韓国語、英語など、日本語以外のスキルは必須でしょうか? 読み書きなどは必須なのでしょうか?」。通訳がいるという話がありましたけれども、佐藤さんの部署とかだと英語は必須なのでしょうか?
佐藤:お答えすると、採用の時点で英語必須にはなっていなくて、英語、または日本語というのが、私のチームやその周辺のチームで多いケースですね。ただ、やはり実際に英語話者の人がチームにいたりとか、彼らにとっては逆に我々が日本語話者なので、お互いに勉強のやる気であるとか、文化的に理解するという姿勢は必須だと思っています。
先ほど渡邉さんも紹介されていたように、社内に言語教育のサポートもあるので、それが必須というわけではないのですが、積極的にそういったことに興味をもつことは期待したいかなと思っています。
松野:なるほど。栗原さんの部署はどうですか?
栗原由樹氏(以下、栗原):僕自身も、ほとんどというか中学生ぐらいの英語しか能力はないと思っていて。エンジニアとしてはあったほうがいいとはもちろん思うんですけれども、基本的には社内に、先ほど渡邉も話したとおり、通訳のチームがいますし、会社的にいろいろな国の人がいるので、社内に通訳のためのツールも各種揃っていたりするので、基本的に日本語だけでも、業務は行えると思います。ただ、しゃべれたほうがいろいろな面でやりやすくなるのは多少あるかなとは思います。
松野:なるほど。もちろん会話が必須じゃないという部署も非常に多いとは思っていて、少なくとも韓国語が必須の部署はそんなにないと思います。ただ、英語に関しては、やっぱり英語のドキュメントが読めないと仕事にならないってところはあるので、そこだけはどうしても必須になってくる面はあると思います。やっぱり外部のドキュメントは英語しかないのが多いので、そこはしょうがないかなというところですね。
「仕事で保守と先行開発の割合はどれぐらいでしょうか? それとも運用専門のチームが対応するかたちでしょうか?」というような質問が来てますけど、渡邉さんの部署とかはどうですか?
渡邉:これ難しい質問ですね。
松野:(笑)。
渡邉:僕らのところでやっているのは、先行開発も通常の運用もどっちもやっています。ただ、案件単位で、開発がある程度ステイして運用がメインになっていたりとか、あとはサービスの性質をあまり変えずに規模だけ大きくしてみたり。どっちかというと積み重ねて開発していくみたいなことをやるときに専門のチーム、例えばLINE Growth Technologyに移管することはありますが、まったく先行開発しないとかではないと思うので、どっちも1つのチームでやっていく感じになると思います。
松野:はい、そうですね。僕のほうでもそういうような認識です。
いよいよ時間が残り少なくなってきましたが、「ワーク・ライフ・バランスについて教えていただけませんか?」という質問が来てますけど(笑)。これもなかなかざっくりしていて難しいところでありますが、奥田さんのところはどういうふうに考えていますか?
奥田:今の僕のチーム、大きくて18人ぐらいいるんですけれども、やっぱりリモートワークになってけっこう最初のほうは、「締めがわからん」みたいな感じで。みんな帰ったら帰るんですけど、一応弊社定時が18時半ということになっているんですが、リモートワークでダラダラと残っちゃう人が多かったです。
最近はけっこう明示的に「翌日できることは翌日する」みたいな感じで。まぁそのマインドが正しいかどうかもあるんですが、やっぱり最近は若い人が増えてきて体力がある方も増えているのですが、オーバーワークはしないようにと。
かつ、たぶん日々そういった業務をやっていると、業務のことにフォーカスしすぎちゃうんですが、それ以外で勉強とかを各々でやっていってもらったほうがいいというところもあるので、そういった余暇の時間とかで、必ず勉強しろというわけじゃないんですけれども、そういったところも含めて、なるべく最近は退社を促す感じで、「そろそろ定時なので帰りましょう」みたいなことをチーム内で言って。わりとそれで「もう定時だから終わるか」みたいな感じで終わる。さっき言ったとおり、そうしないとずっとリモートワークでダラダラ続くので。
また休日出勤とかも、基本的には今はもうぜんぜんないような状態です。ただ、トラブルシューティング、先ほどの運用とかはあるので、そのあたりはどう構築していくかというのが、まだ課題感があったりする。ただ、一応オンコールローテーションということで、回して担当を決めて、それ以外の人は基本的にお休みをするとか、そういった方針をとっていたりはします。以上です。
松野:ありがとうございます。まだちょっと質問がいくつかあるのですが、そろそろお時間になってしまいました。締めのスライドに移って画面を共有したいと思いますが。残った質問については、別途可能なかぎりメールでお答えできればと思いますので、よろしくお願いします。
本日のセッションを通じてLINEのキャリアに興味をもっていただいた方は、「DIRECT APPLY」というかたちで、応募したいポジション、今日話を聞いて「この人と一緒に働いてみたいな」みたいのが明確になった場合には、採用ページから直接ご応募いただければと思います。
なにしろいろいろなサーバーサイドエンジニアのポジションがあって、今日のイベントで紹介しきれないところもありますので、そういった場合はサーバーサイドエンジニアの「OPEN POSITION」に応募いただければ、リクルーターが経歴を確認してマッチするポジションを「この方とカジュアル面談してみませんか?」とか、あるいは「ここに応募してみませんか?」というようなかたちで紹介しますので、応募していただければと思います。
あとはカジュアルインタビューというのもやっています。実際話してみないとよくわからないというところも多いと思いますし、今日みたいなイベントだとなかなか質問もしきれないところがあると思いますので、現場の社員と話してみたいという方は、カジュアルインタビューに応募していただければと思います。
本日はご清聴ありがとうございました。
一同:ありがとうございました。
LINE株式会社
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
職場であえて「不機嫌」を出したほうがいいタイプ NOと言えない人のための人間関係をラクにするヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
PR | 2024.11.22
「闇雲なAI導入」から脱却せよ Zoom・パーソル・THE GUILD幹部が語る、従業員と顧客体験を高めるAI戦略の要諦
2024.12.11
大企業への転職前に感じた、「なんか違うかも」の違和感の正体 「親が喜ぶ」「モテそう」ではない、自分の判断基準を持つカギ