挑戦を楽しめ––LINEの開発組織が大切にしている価値観

世界各地に2,500名のエンジニアが所属

池邉智洋氏（以下、池邉）：デベロッパープロダクトの話はいかがでしたか？　機能も増えていますし、開発自体も以前に比べてかなりしやすくなっていますので、ぜひ触ってみていただきたと思います。

ここから、エンジニアリングのカルチャーについてお話ししたいと思います。我々LINEのエンジニアが日々どんなことを思い、どういったカルチャーの下で活動しているのか、そこをご紹介したいと思います。

その上で、「このカルチャー、いいね」とか「一緒に働くと楽しそうだな」みたいな気持ちになられましたら、「WORK AS LINER」というブースがありますので、そちらへお立ち寄りいただければいいなと思っております。

さて、私たちLINEグループの開発拠点はここ日本だけではありません。

日本だけでなく、アジアを中心に10拠点あります。日本だけでも、東京以外に京都と福岡に拠点があります。海外では、韓国、台湾、タイ、ベトナム、中国と、さまざまな都市でLINEのエンジニアが日々開発を行っています。

LINEグループ全体では、現在2,500名規模のエンジニアが所属しています。日本には、先ほど申し上げた3拠点で700名以上のエンジニアが日々サービスを開発しています。また、この700名のエンジニアは全員が日本人というわけではなく、20ヶ国以上からエンジニアが集まってきていて、日本においてもグローバルなメンバーで開発をしています。

世界中の拠点で同じように働けるように

こちらは各国にあるLINEのオフィスの写真です。

我々は国をまたいで同じものを開発することも多いので、オンラインのチャットやテレビ会議など、オンラインのコミュニケーションツールにはもちろん対応していますが、やはりface to faceで顔を突き合わせて話したほうが早かったり、そのほうが気持ちが伝わる局面もあるので、出張も頻繁に行っています。

LINEはエンジニアの会社のわりに、かなり出張が多いほうじゃないかと思います。出張って、先ほど言ったとおり、効果は大きいんですよ。でも、海外は飛行機に乗って移動したり、時差もあったりします。日本でも新幹線に乗って1〜2時間ぐらいはかかるので、疲れると言えば疲れる行為です。

ただでさえ疲れてしまうのに、オフィスに着いてからさらに疲れてしまうことが極力ないように、LINEは出張時にオフィスに着いたあとはすぐに本来の業務に取りかかれます。そういったファシリティ面の整備に非常に力を入れています。

写真をご覧いただければ、各国と言いつつもテイストは統一されているというか、どこのオフィスに行っても「ああ、LINEのオフィスに来たな」という感じになるように作れられています。

これ、実は社内にスペースデザインチームという、空間デザインやオフィスづくりをする専属チームがいて、彼らが各国で統一した雰囲気のオフィスを作っています。

これはITの会社では珍しいのではないでしょうか。建築やインテリアデザインを本職にした方が社員として所属していて、本日のDEV DAYでも、さまざまな装飾やデザインもすべて社内のスペースデザインチームがやっています。なので、働く環境を整えることに関しては、本気で投資をしています。

また、デザインという見た目だけの話ではなく、システム面にも力を入れています。例えば無線LANのシステムも、各国どこに行っても自分が普段働いているオフィスと同じ環境で仕事がすぐに始められる仕組みを作っています。

こういった社内システムは規模が大きく力を入れているので、興味のある方は社内システムに関するセッションを見ていただければと思います。

LINEが大切にしている価値観をまとめた「LINE Style」

さて、オフィスなどのハード面の統一もグローバルで一緒に仕事をしていくためには大事なんですが、もう1つ、やっぱり人間ですので、多拠点のチームでも同じ目標に向かって走っていくためには、心構えというか「こういった気持ちで仕事をしよう」ということが大事です。LINEには仕事を進める上での価値基準をまとめたものがあります。これを「LINE Style」と呼んで公開もしています。

全部で11個あるんですが、こちらの詳しい内容はコーポレートサイトで公開していますので、そちらも見ていただけるといいのかなと思っております。

このLINE Styleについて、これはエンジニアに限った話ではありませんが、LINE Styleをエンジニアの日々の仕事に当てはめるとどういうことになるのかをお話ししたいなと思います。

この3つ、「Users Rule」「Always Data-driven」「Perfect Details」。「ユーザー本位ですよ」「常にデータを見ましょう」「細かいところを突き詰めよう」という話です。

我々が作っているサービスは誰のためのものかというと、やはりユーザーさんのため、ユーザーの便利になることが一番大事です。LINEの価値観ではそれがすべてです。なので、ユーザーは何を求めているのか、何が必要なのかを徹底的に考えます。

そして、すでに動いているものであればデータを見ますし、分析しますし、場合によってはユーザーさんを呼んでインタビューなども行いますし、徹底してユーザーさんに向き合いたいと思っています。また、データの活用という意味では、A/Bテストや結果の分析もやっています。

ご存じのとおり、インターネットサービスは非常に競争が激しい分野です。そこでユーザーさんに選択してもらうためには、細かい部分までこだわった、ほんの少しの差の積み重ねがユーザーさんに選択していただくための差になると思っているので、細かいところまで徹底的にこだわっていく。それがLINEの考え方です。

また、開発チームの仕事の仕方やチームのあり方についてもLINE Styleは有効だと思っています。

「Work Intensely and Be Focused」。一生懸命がんばってやりつつも、何がやるべき仕事なのか、それはやらなくていい仕事ではないか、それを常に問い続けていくことが大事だと思います。

エンジニアの仕事は何のためにやっているかというと、例えば今やっている仕事が手作業だったりすごく大変な仕事もあると思いますが、それを本当に必要だからやっているのか、決まっていることだから、過去から続いているから目的もなく一生懸命やっているのか。そういったことは常に自問自答していくことが大事だと思います。

例えば「自動化してなくせないの？」とか「そもそもこの仕事をやる必要はあるのか？」とか、そういったことを考えながら効率良く仕事をしていく。そこは非常に大事なことだと思います。

「Open Communication」と「Vertical Decision-making」。これは日本語で「オープンな議論とリーダーによる決断」と言っています。

開発メンバーは、基本的にチームで行動しますよね。チームの中で、社歴が浅い人、年齢が若い人はいろいろいると思いますが、そういったことによって発言の重さや取り扱われ方が変わることはありません。開発メンバーの発言はすべて等しく尊重されますし、多くの可能性をみんなで議論します。

ただ、最終的に1つの「これだ」というゴールを設定する。それはリーダーがやるべきだと思います。その決断をしていく役割がLINEの開発リーダーの仕事です。そういったチームを構成して、我々はやっています。

LINEのコードはすべてオープンに

さて、今までお話ししたLINE Styleは、どちらかというと心構え的なお話でした。ここからは、実際のエンジニアの日々の仕事の進め方もいくつかご紹介します。

我々は「Autonomous Team」というキーワードをよく使います。Autonomousは「自律的な」という意味ですかね。上から言われたからやるチームであってほしいとはあまり思っていません。自分たちでやりたいこと・やるべきことを探してやっていく。それが理想的なチームではないかと思っています。

我々は本当にものすごい数のプロジェクトをやっているので、例えば「あるプロジェクトのあのプロダクトのこういうところに参加したい」だとか「ちょっと意見を聞きたい」とか、そういうことがよくあります。

これは「OPERA」というツールなんですが、各プロジェクトでどのエンジニアがどのぐらい仕事をしているかを可視化しているツールです。可視化していると何がいいかというと、もちろん工数管理みたいな話もありますが、例えば「あのプロジェクトのここを開発した人、誰だろう？」といったことがわかるんですね。

そうすると、そこに対して気軽にメールを送って「ちょっと話そうよ」だとか「ここ、もうちょっとこうしたほうがいいんじゃない？」とか、そういったことが可能になります。それをやることによってエンジニアたちは自分のより興味のあるところに近づいていける。そういったことをサポートするツールとしての役割があります。

また、GitHubを使われている方も多いんじゃないかと思います。当然弊社も使っているんですが、権限管理ってありますよね。基本的に、LINEはすべてのコードを全エンジニアにオープンにしています。

なので、LINEの各サービスのコードも見ようと思えば見れますし、「ここの挙動はどうなっているんだろう？」とか、見ようと思えばみれますし、その上で「ここはもっとこうできるんじゃないか」だとか、ほかの人に見てもらって意見をもらうといったことを、非常にオープンにできるようにしたいと思っています。

同じ失敗をしないための、失敗データベース

次はコードレビューです。LINEでは、開発においてコードレビューを全体のプロセスの中で非常に重要視しています。あるコードを実装したら、必ず一緒に仕事をしている同僚にレビューをお願いする。また、新しくジョインしたメンバーについては、とくにメンターがついて細かくレビューをして、チーム内で意識の統一、品質の統一を図っています。

LINE全体のコードの行数は数えたことはありませんが、おそらく膨大な量になると思います。それでもレビューを通っていないコードは1行も、1文字もプロダクションの環境に存在しないということは、自信を持って言えることかなと思います。

人にコードを見てもらうのはなかなか緊張する面もあると思いますが、ある程度のいい緊張感を持ってお互いに切磋琢磨するのは、エンジニアが成長の上で大事なことだと思っていますし、その積み重ねがチームとしての強さにつながると思っています。

最後にOutages Retrospective。ありがたいことに、LINEは今では非常に多くのお客様に使っていただいています。ある種、メッセージングのインフラ的な役割を果たしていると思っています。

そんな立場ですので、当然、障害等を起こすと多くの方にご迷惑がかかります。障害は起こさないのが当然です。ですが、人間がやっていることですので起きるときは起きるというか、障害はなかなか避けられない部分ではあります。その場合、すばやく対応を行うのはもちろんですが、LINEでより重視しているのは、対応後、いかにそれを糧にして次につなげていくか。その対応により重きを置いています。

まず、障害が直ったとします。「直りました。よかったね」ではぜんぜんダメだと思っていて、まずは障害の原因・対策をレポートに記載しています。これは、全プロジェクトで過去にOutageが起きた履歴が、エンジニアであれば誰でも簡単に見れるようになっていて、同じ失敗をしない、失敗データベースがちゃんと作られています。

このレポートを書くときに1つだけ気にしていることは、障害を起こした個人や特定のチームについて、ことさらに名指しで書くとか……そういったことをしてもなにか良くなることがあるかというと、おそらくほとんどありません。

その代わりに、改めてチームで集まって、次に同じことが起きないためにどうすればいいのか。人為的なものであれば「自動化してしまえばいいんじゃないか」とか。あとは「このぐらい冗長化していくと、障害が起きても問題が起きなくなるのではないか」とか、そういった根本的な解決を徹底的に目指していく。そういった振り返りの活動に非常に重きを置いています。

挑戦を楽しむ

さて、ここまで、LINE Styleや開発文化についてお話ししてきたわけですが、LINE Styleは先ほど11個と言いましたが、最後にこんな項目があります。私はこれが最後にふさわしい言葉だと思っています。それが「Enjoy the Challenges!」です。

エンジニアの仕事って、すごく大変だと思うんですよね。障害を起こしてはいけないとか、「それ無理ゲーじゃない？」みたいなことも日々多いと思います。でも、基本的にそういった困難に挑戦することはエンジニアにとって苦しいばかりではなく、楽しくやるべきだと思います。なので、挑戦を楽しむこと。これはLINE全体にとって大事な文化だと思っています。

今日はDEV DAYですが、こちらで得た情報などでみなさんが楽しく開発をしていく手助けになればいいなと思います。それでは、2日目もぜひ楽しんでいってください。ありがとうございました。

（会場拍手）