“働きやすさNO.1”の実現をミッションとする、LINE社内IT部門のチャレンジ

LINEの社内システムが持つミッション

片野秀人氏：みなさんこんにちは。LINEの片野と言います。2日間という長いカンファレンスでしたが、本日は最後までご参加いただき、誠にありがとうございます。

まず最初に私の簡単な自己紹介からさせてください。私は2009年に入社して10年経っているんですけど、2013年から社内ITの部門を担当しています。また、サービス開発の領域もずっと担当しています。

とくに去年からGrowth開発という領域にコミットしていますので、いわゆる社内ITだとバックオフィスという意味合いが強いと思いますが、バックオフィスの領域とサービス開発、会社としてのフロントに近い部分の両方を担当しています。たぶん両方担当している役員は私だけなので、珍しい立場で仕事をしているかなと思います。

本日のアジェンダです。まず最初にLINEの社内システムというのはどんなものがあるのか。すべてをご紹介するのは難しいですが、概要について簡単にお話ししたいなと思います。そして、社内のシステム・社内の部門としてどんなミッションを持っているのか。また、最後にLINEとしてどんな課題があってその課題に対してどんな取り組みをしているのかを、なるべく具体的な例を挙げながらご紹介していきたいと思っています。

まずは会社の規模についてです。今日のオープニングセッションでも話があったと思いますが、今はLINEグループ全体として8,100人（注：2019年9月時点）を超える社員が在籍しています。そして社員の増え方の推移をグラフで表すと、こういったかたちになります。

どうでしょう。パッと見てずっと増え続けていると思っていただけるんじゃないかなと思いますが、毎年30パーセント近い成長率となっていますし、3年で社員が2倍になる。どのセグメントで切っても、3年で2倍の増え方をずっとしてきている会社になります。

このスピードで会社全体が成長し続けると何が起きるかというと、社内システムに関して言えば同じサービスを同じ品質で提供し続ける。これは当たり前のことだと思うんですけど、そういった当たり前のことも非常に難しい環境にあることを前提として知っていただければなと思います。

次に、ここはいろいろなセッションで触れていると思いますが、開発の拠点としてはアジアを中心に10拠点があります。開発以外の拠点も含めると実際にはもう少し多いところなんですが、この10拠点が社員数も多くて主要な拠点になります。社内システムという観点で言えば、時差が2時間の範囲に入っているんですね。

アジア中心なので深夜にメンテナンスをやっても地球の裏側からクレームが来ることがあまりないので、その点についてはまだ良いかなと思っていますが、やはりこれだけ拠点があれば、いろいろな国からの要望もあります。

また、メンテナンスのときに気にしていなかった時間にサービスのメンテナンスと被っていたり、そういったこともあるので、日本だけではなくて海外の拠点のことも気にしながら運用をしています。

主要な社内システムリスト

次に主要なシステムだけなんですが、少しリストアップをしてみました。開発に関連性の高いところで言えば、まずドキュメントの管理としては左上のwikiが中心になっています。wikiについてはアトラシアン社のConfluenceという製品を使っていて、Jiraも同じですね。アトラシアン社の製品で、チケット管理やバグ管理についてはJiraを使っています。

また、ここ数年、社内のいろいろなパートナーさんと一緒にプロジェクトを進めてサービスを開発することが非常に増えています。ドキュメントのリアルタイムな共有、コラボレーションが非常に重要になっているので、その分野に関してはクラウドストレージのboxを採用して、これは去年から運用しています。

あとは右上の開発系のツールに関してはお馴染みかなと思うんですが、ソースコードの管理についてはGitHubを使っていてEnterprise、オンプレミスのバージョンで運用をしています。CIについてはJenkinsが多かったんですけど、最近だとDroneを使っているようなプロジェクトも増えてきているかなというところになります。

あとは少し珍しいところで言うとOutSystemsという高速開発ツールですね。それを去年から採用していて、これはGUIベースでコンポーネントを配置するとコードが生成されてスクラッチ開発よりも開発期間が1/10になるというような謳い文句になっている開発プラットフォームになります。

「実際に1/10になるの？」と思ったんですが、けっこう本当に1/10に近い簡単さで、そこまでデザインにこだわらないような社内のものであれば、これで生成された簡易ツールでも十分に業務を効率化していけるので、そういった領域にはこういったものを使ったりしています。

全部触れていくと時間がなくなってしまうので、少し先に進ませていただきます。

wiki、BTS、GitHubの規模

次に、社内のシステムの規模ですね。それがわかる数値をいくつかご紹介します。

まずwikiについてですが、MAUにすると1万1,000人。これは社員数を超えている数になっているんですが、社外のパートナーさんと一緒にドキュメントを管理しながら一緒にプロジェクトを進めていくことが多いので、同じようにwikiも一緒に使っています。なので社員数を超えるような利用数になっています。

また、真ん中はwikiのページの数をカウントしてきたんですけど、120万ぺージ。これが多いと感じるか少ないと感じるかはあれなんですが、だいぶ多いなと思うんですね。10年以上ずっと蓄積しているので、大量の情報がここに集まる環境になっています。

次にJiraです。Jiraについては、もともとはバグ管理が中心だったので開発チームでの利用が中心だったんですが、最近のここ数年はチーム内でのタスク管理としてカンバン方式も多用されていますし、チーム内のタスクも見える化するところにも使われて社内でかなり浸透しています。これも9,200人以上ということで、利用率がかなり高くなっているかなと思います。

最後にGitHubについては、これこそ開発中心のツールですが、注目していただきたいのは真ん中と右の数字ですかね。この4万5,000はリポジトリの数なんですね。意味がわからない数字だと思うんですけど、リポジトリの数が4万5,000を超えていると。forkの数も含んでいます。

あとは右側の数字ですね。LINEの中で一番大きいリポジトリの数字を取ってきたんですが、1つのリポジトリの中で出されているPullRequestの数が1万5,000を超えているような規模感で開発を進めています。

目指すは「働きやすさNO.1」

次に社内システムのミッションについてお話をしたいと思います。まず、みなさん自社のシステムに満足されているのかをお聞きしたいんですけど、社内のシステムに不満がある方は手を挙げていただけますか？

（会場挙手）

あ、わりと挙がりますね（笑）。そうですね。私自身がどう感じていたかと言うと、やはり不満があったんですね。担当したのが2013年なのでそれより前の時期で言うと、やはり社内システムにはさっきのwikiみたいなもの1つを取ってもけっこうレスポンスが遅かったり、障害があって復旧が遅かったり、いつ復旧するのかもわからなかったりしました。個人的にすごく気持ち悪いなと思ったのは、なぜその障害が起きたのかもわからなかったんですね。

障害レポートが出るわけでもなかったので、そういったところがけっこう気持ち悪くて。いろいろと改善提案をしていたんですが、やはりなかなか良くならなかったんです。自分が開発をしていく上でこれが足りないと思うものがあったので、自分で「やりたい」と言って、社内IT部門を担当するようになったのが2013年になります。

では、LINEの社内ITの部門としてどんなミッションを持っているのか。まず始めにLINEでは、「WOW」という言葉を一番大切な価値基準として持っています。WOWは簡単に言うとユーザーを感動させるような体験のことです。LINEではこのWOWを追及してNO.1を目指し、チャレンジをし続けることを価値基準にしています。

そして私たち社内ITの部門は、社内サービスの提供を通じて、働きやすさNO.1の企業を目指す。より良い環境を提供し続けることをミッションに置いています。

先ほど社内サービスと言いましたけど、私たちは社内のシステムは社内向けのサービスであると捉えています。これは当たり前のことだと思うんですが、システムというのは作っただけでは何も価値を生むものではないです。ユーザーに届けて使ってもらう。そうすることで初めて価値を生むものだと思います。

そして何よりもユーザーに使い続けてもらうことが大事なので、使い続けてもらうためには継続的に改善を続ける。例えば足りない機能があれば追加機能をどんどんリリースしていく。そしてそれが社内のニーズを満たしたのかどうかということを調査してフィードバックを受けて、さらに良いものにしていく。こういった活動を継続的に続けていくということが何よりも大切なことだと思っています。

システムアカウントの統合

ではここから具体的な課題と取り組みについてのお話をしたいと思います。

今日はこの3つの取り組みについてお話をしたいと思います。1つ目がシステムアカウントの統合で、2つ目がオンボーディング、入社にまつわるところの話とユーザーサポートの話です。そして3つ目にWOWな社内システムについて、お話をしたいなと思います。

まず最初にシステムアカウントの統合についてです。これはおそらくどこの会社さんでもよくあることかなと思うんですが、IDとパスワードが複数ありました。システムごとに独立してしまっていて、ユーザーが「このシステムはこのIDとパスワードだ」と、使い分けをするような状態ですね。こういった問題が1つありました。

また、もう1つの問題としてシステムがいくつか独立していて、システムごとに社員の情報を持っていることになるので、例えば組織変更があったときにこのユーザーはAという組織に所属している。でもこのシステムでは、まだCという組織に所属していることになっていると、システムごとにユーザーの情報の不一致が起きる問題ですね。そういったことが起きていました。

そこについてどういった対応をしてきたかと言うと、まず1個目は認証です。LINEでは社内にSSOという認証基盤を自前で持っていて、ここで社内のインターナルサービスについても基本的にすべて認証していますし、クラウドのサービスに関してもSAMLと2段階認証に対応することでセキュアに認証をしている。こういったところを統合していったかたちになります。

この仕組みについては、OktaやOneLoginなど、他にもいろいろなサービスがあるので技術的には別に珍しいものではなくて、社内でやっていることで言うと、このSSOの認証のためのAPIを社内の開発ドキュメントに公開していて、社内のエンジニアが自分たちで作ったツールを社員に使ってほしい。そういうときに認証させたい、認証基盤と接続をしたいというときには、そういったドキュメントを見れば連携をすることができる環境を提供しています。

ユーザプロファイルの一元管理

次にユーザー情報、社員の情報の同期についてです。社員の情報については、マスタになっているのは一番左側の人事システムです。こちらにある情報が社員のマスタになっています。そして、その右側にある「IM」というのが、これはアイデンティティマネジメントというシステムですね。これが1個挟んであって、ここで人事システムに入ったデータを各システムに……いわゆるバッチで配布していく仕組みになっています。

ですので、何か社員の情報のプロファイルに変更があったときは、必ずこのマスタになっている人事システムにデータを反映して、各システムに配って同期する仕組みになっています。

ここでユーザープロファイルのうち、ディスプレイネームのところで1つ課題があって、その課題について少し掘り下げてお話ししたいと思います。ディスプレイネームというのはシステムで表示するユーザーの名前のことです。3年ぐらい前まではどういうふうに表示をしていたかと言うと、システムで表示しているのはリアルネーム、本名をそのまま表示していました。

何回もお話をしているように、LINEではグローバルにいろいろな人が仕事をしています。なので本名を表示すると何が起きるかというと、漢字だったり繫体字だったり、その国の母国語でリアルネームが入っているので、それがシステムに表示されていると、まず読めないですよね（笑）。私も日本語、漢字、英語までは読めますけど、繫体字などの字になるとやはり読めない。

読めないだけならまだいいんですけど、検索できないのが一番問題なんですね。これだけの人数がいて名前の検索ができない。BTSのチケットをこの人にアサインしたいんだけど検索ができない。なので名前をコピペするんですね。そういった不都合なことがありました。

そしてもう1個は、国ごとの文化の違いですね。例えば台湾ではイングリッシュネームを使っている人が多いです。仕事もイングリッシュネームを使っている人が多いです。

また、タイではニックネームを使うのが一般的です。これはおもしろいんですが、仕事もプライベートでもニックネーム。なので、本名がシステムに表示されても誰だかわからない。同僚であっても誰だかわからないということが起きていて、日本でもハンドルネームで仕事をしている人がいるので、同じように本名がわからないという人がいたりするんですが、とくに海外の拠点からは、ここについてはとても強いニーズがありました。

ディスプレイネームをカスタマイズして、社員検索を容易に

それに対してどう対応したかで言うと、先ほどUser Syncのところで紹介をしたアイデンティティマネジメント、IMのシステムのところでディスプレイネームを生成しています。どういったロジックで生成しているかというと、社内のポータルサイトで社員が自由にニックネームを登録できるようにしてあります。

そして、ニックネームを登録した人に関しては上のパターンですね。ニックネームを先頭に表示して、その後ろにリアルネームを付けるという表示の仕方をしています。そしてニックネームを登録していない人に関しては下のパターン、イングリッシュネームを先頭に表示してその後ろにリアルネームをくっつけてあげる。そういった対応をすることで、右側が実際の表示例になるんですが、必ずアルファベットで始まるようになっているんですね。

なぜこうやっているかというと、各システムで検索の仕組みというのが違うので、システムによっては前方一致でしかユーザーを検索できないシステムがあります。前方一致でしかできないということは、先頭に漢字が入っていたり繫体字が入ってたりすると、検索ができないんですね。なので先頭に必ずアルファベットが来るような工夫をしています。こうすることでアルファベットさえ読めていればユーザーの検索ができることを実現しています。

システムの統合については、こちらの3つのポリシーですね。1つのアカウント、1つのパスワード、そして1つのプロフィール。こういったかたちでシステムを1つにまとめておくポリシーを持つことで、ユーザーは社内のシステムであってもクラウドのシステムであっても、シームレスに意識することがなく使える環境を提供しています。