LINEのエンジニアが大切にする「オーナーシップ」
池邉智洋氏：ここからはLINEのエンジニアのカルチャーをご紹介したいと思います。
我々には大事にしているフレーズが3つあります。「Take Ownership」「Trust ＆ Respect」「Be Open」。この3つの言葉を大事にしてエンジニアの組織は作られています。
まず「Take Ownership」です。日本語で言うと、「自分ごととしてやってください」とか「オーナーシップを持ってやってください」という話なんですけど。
LINEのエンジニアとして求められているオーナーシップとはどういうことかというと、自分が担当するサービスについて当事者意識を持って取り組む。そこで開発者としての視点ももちろん大事ですし、それだけでなく、やっぱり1ユーザーとして自分が使うときに「この機能はちゃんと便利だろうか？」「UIは使いやすいか？」といった視点はとても大事です。
あとはやっぱり、決まったものを実装するだけではなくて、自分ごととして関係部署と議論をして、より良いサービスを作るべくプロジェクトを責任持ってリードしていくことが求められるかなと思います。
わりと企画はじまりのものもあれば、開発者はじまりの機能みたいなものもけっこうあります。例えば、そろそろクリスマスですがクリスマスになるとLINEの画面に雪が降ったり、春には桜が舞ったりします。ああいうものは、企画者が「雪を降らそうと思うんだけど」とかあまり言ってこないんです。遊びで作ってみたら「これはおもしろそうだね」という感じで、ああいったものはエンジニア発で出てきています。
LINEは日々使うツールなので、ああいった遊び心みたいなものも大事だろうという感じですね。
より質の高いサービスを提供するための「内製主義」
ここまででも少しずつ話をしていますが、「Principle of Self-sufficiency」、内製主義です。
わりと、いろいろなものを自分たちで作りたいというのがあるかなと思っています。先ほどお話ししたインフラのプライベートクラウドを自分たちで作ったり、オフィスのデザインを自分たちでやったり、あとは社内システムも大部分を自分たちで作っています。開発スタイルとしてはやはりOSSの活用と内製が基本的な方針になっています。
例えば、わりと珍しいなと思いますが、メールのシステムもスマホアプリがあって、これも内製だったりします。あとはRPCがLINE内部で多用されているんですけど、そこもArmeriaというミドルウェアをNettyなどのOSSを活用して開発して、さらにそれをオープンソースで公開するということもやっています。
あとは、私もあまり把握してないところですごいものを内製しようとしていることがたまにあって。最近はLINE LIVEで使っていたストーリーミングのサーバはこれまで外部のものを使っていたんですけど、1年以上かけて内製のものを作って切り替えようとしています。
そのほうが自分たちでコントロールできることが増えて、より質の高いサービスを提供できるかなということで、こういった感じの内製主義を大事にしています。
先日のLINE DEVEROPER DAYで、社内システムをどんな思想でどうやって作っているのかというセッションを担当役員の者がやったんですけど、その担当役員も私と出身母体が一緒で、M＆Aで来た人物です。統合されたとき、社内システムがあまりイケてないという話があってですね（笑）。その改善案をずっと出していたら、いつの間にか「君、担当役員ね」みたいな話になりました。
Take Ownershipというか、言い出しっぺの法則というか、自律的にちゃんと自分で「手を挙げたからには最後までやってくださいね」みたいなところもあるかなと思います。
これはその時に使ったスライドなのですが、社内サービスの提供を通じて働きやすさNo.1の企業を目指してインフラを提供したい、というメッセージをお話ししました。
LINEは社会インフラと呼ばれるようなサービスを提供している企業です。なので、社員がちゃんと高いパフォーマンスで働ける環境を作ることが大事だと思っています。社員もユーザーの一部として考えて、外に向けて出すものと同じクオリティのものを中にも出していくということを非常に意識しています。
LINEのカルチャーの根底にある「信頼と尊重」
次が「Trust ＆ Respect」です。日本語でいうと「信頼と尊重」ですね。
これまで申し上げてきたとおり、とくに生まれた国であるとか母国語、これまで働いてきた環境がぜんぜん違う仲間と一緒に気持ちよく働くためには、やはり信頼と尊重が一番大切です。
技術的なところで言うと、みなさんもやられていると思いますが、LINEのすべてのプロダクトはコードレビューをしています。必ずコードレビューが通らないとプロダクション環境には入れさせないというか、入らないようになっています。
そういったコードレビューの品質を高めていくためには、時には厳しい指摘やフィードバックが、けっこうあります。そういったフィードバックもそれまでの信頼と尊重の下でないと成り立たないですし、お互いに若干の緊張感を持つ状態が健全な状態であって、そのことがよりチームを強くするのではないかなと思っています。
その3つの要素について、我々はこういうプロセスなのかなと思っています。
一番向こうから、「Trust ＆ Respect」がやっぱり一番大事なことで、その上で「Self-directed Work」、自律的に方向性を決めてやっていく。その上で、「Positive Peer Pressure」というかたちで、互いに心地いいというか、ある程度の緊張感でプレッシャーをお互いに掛け合うことによって、より品質も高まってきますし、チームとしても強くなっていく。そして、お互いを高め合い認め合う。それがいいカルチャーなのではないかと考えています。
「Trust ＆ Respect」が大事なこととしては、LINEは非常に多くの方に使っていただいていて、ユーザーさんに目に見えるかたちの障害になるかどうかにかかわらず、日々細かい障害はどうしても起きてしまいます。なので、そういった場合の対応も非常に大事な仕事の1つで、そこにはやはりTrust＆Respectの考え方が大事だと思っています。
当然、障害が起きたらすばやく対応を行いますし、一刻も早く復旧を行います。この場合、我々は対応よりもその後に重きを置こうと思っていて。障害の原因や対策を記したレポートを書くようにしていますし、チームで集まって「同じことが起きないためにどうしようか？」と話し合っています。例えば人為的なものであれば「そもそも人間なので間違えますよね」ということで、自動化ができないかを考えたり、同じことが起きてもユーザーさんへの影響がないように作ることは可能なので、そういったアーキテクチャに変更するとか。そういったことを議論して、徹底的に根本的な解決を目指そうとしています。
この振り返りのときに必ず大事にしているのは、言ってしまえば、やらかした人がいたりするんですよ。ただ、「この人がやらかしたよね」ということを未来永劫残していくことにはあまり意味はありません。
個人攻撃であったりあるチームがダメだみたいな話はドキュメントには書かずに、もちろん口頭では「〇〇さんの作業だったね」みたいな話はありますが、それを長い間残す必要はないと考えています。
オープンな文化を醸成していく
最後に「Be Open」。「オープンにやろうぜ」みたいな感じですかね。エンジニア同士のオープンな関係性もそうですし、GitHub Enterpriseを使っているのですが、そのリポジトリや権限管理は基本的にしないという方針になっていて、社員であれば誰でも見られるようになっています。当然LINEのメッセンジャーのコードもめちゃめちゃ多くて大変ですが、見ようとすれば見ることができます。
見て「ふーん」という話ではなくて、使っていて何か問題を見つけた場合に探し出してプルリクエストを送ってもいいですし、LINEを通して外部のオープンソースのソフトウェアにコントリビュートすることを会社としては推進しています。そういったオープンな文化を醸成していく。
（スライドを指して）この人は、先ほどお話に出た社内システム担当の役員です。
これは社員情報のページなのですが、社員が8,000人以上いるので、なかなか顔と名前が一致しないということがあります。あとはふらっとメールが来ても「誰？」みたいなことがあります。名前とメールアドレスがあっても誰だかあまりよくわからないので、どういうプロジェクトに参加しているのかを調べたり、LINEやSlackで直接連絡できるようになっていて、座席なども辿れるようになっています。そういった社員のアクティビティをよりオープンにして、それによってコミュニケーションがスムーズ進むようにしています。
今お見せしたのが人ベースなんですけど、こっちはプロジェクトベースのものです。
グラフの向こう側にはプロジェクト名が表示されています。まだ世に出ていないプロジェクトがあったりするのでマスクしてありますが、プロジェクトごとにどのぐらいの人が関わっているのかが可視化されています。
これは簡単に言うと工数管理ツールなんですが、ただの工数管理ツールだとあまりおもしろくないので、もう少しおもしろい使い方としては、「このプロジェクトをやっているのはあの人か。このプロジェクトに一言物申したい」というときに、ここからさらに先ほどの人の画面に行けるようになっています。
そしてさらに、これが座席表です。
昔は座席表はExcelでぽちぽちやって更新して、それを総務の方に共有するみたいなよくある構成だったのですが、それをがんばってWeb化して、席替えをしたら自動で更新・通知を送るというシステムに変えました。
なので、あるプロジェクトが気になったりしたら、直接担当者のところに行って話を聞いてみる、といったことが非常に気楽にできるような仕組みになっています。
実際、LINEですとミドルウェアを作っているメンバーがけっこういます。例えばストレージレイヤを作っていたり、いろいろなプロダクトから共通で使われるコンポーネントを作っているメンバーがけっこういます。そういうメンバーが、「このプロダクトのライブラリのこの挙動はおかしいんじゃないか」といった話が実際にけっこうあって。
そういうときに、社員名簿だけで調べるよりもは、「この人はこういうことをやっている人でこういう分野に明るそうだから、こういうことを聞こう」といったことができる。わりとこのあたりは便利に使われているかなと思います。
チャレンジを楽しむ
ここまでは、いわゆるエンジニアに限った話でしたが、チームとして見た場合、プロジェクト全体ではいろいろな職種の人がいます。なので、エンジニアだけではなくLINE社全体での共通意識として設定しているものがあります。それがこちらの「LINE Style」です。11個あって、詳細は弊社のホームページにも上がっています。
この中でエンジニアがよく使うのは、01番の「Users Rule」、ユーザーが一番偉いというか、「ユーザーのためにものを作っていきましょう」ですね。あるいは03番の「Perfect Details」とか。「神は細部に宿る」みたいな言葉もありますが、細かいところまでちゃんと作っていこうじゃないか、みたいなこととか、データをちゃんと見ていこうとか。
こういったことが11個ぐらい設定されていて、LINE社全体としてこれらを念頭に置いて事業を運営しています。
11個あるのですが、最後に一番大事なことが書いてあります。「Enjoy the Challenges!」です。
エンジニアの仕事ってなかなか大変なことも多いんですね。いろいろ大変なことが起きたなと個人的に思っていて、障害を起こしてはいけないとか。いろいろなことが日々起こります。
でも、そういった困難は、エンジニアにとっては大変というだけでなくて、楽しくやるべきことだと思っているので、エンジニアのみなさんで困難を、チャレンジを楽しんで一緒に挑戦していくことができたら、世の中が良くなると思っています。
私のセッションは以上とさせていただきます。本日はどうもありがとうございました。
（会場拍手）
