LINEサービス運用の裏側を明かす　AI連携やプラットフォームを利用したオペレーション構築の最適解

LINEサービスの運営改善の裏側

加藤敏之氏（以下、加藤）：みなさん、こんばんは。LINE Global Operation室の加藤と申します。本日は、LINEサービスにおける運営改善の裏側の話をさせていただきます。

みなさんには1つでも多くの気付きを持って帰っていただいて、組織の運営や、みなさんのスキルアップに繋げることができればと思っておりますので、よろしくお願いいたします。

それでは1つ目のセッションに入りたいと思います。

簡単に最初に自己紹介しまして、「LINEとLINE Fukuokaの概要」と「会社の成長に伴い出てきた問題点」について共有したいと思います。

LINE Fukuokaの社員約1,000人の半数以上が携わる運営業務

加藤：改めまして、私はLINE FukuokaのGlobal Operation室の室長の加藤と申します。

私は2014年にLINE Fukuokaに入社しました。同年の12月にLINE Payというサービスが始まっているんですけれども、その立ち上げの担当として、Customer Care、審査業務、不正監視を主に担当していました。

そして2018年の2月に、今所属しているGlobal Operation室を立ち上げました。ここでは運営業務の見直しを行って、品質生産性の向上を推進する活動を行っております。

まずLINEは、2011年3月の東日本大震災をきっかけに、モバイルメッセンジャーとして誕生いたしました。

その2年後に、LINE Fukuoka株式会社が設立されました。当初はアプリのQAやCustomer care業務などの運営から始まりました。それから監視や、審査、運営部門の業務の幅が広がり、開発・クリエイティブ・事業企画も揃うようになり、最終的にはアプリを運営するための組織がすべて揃っているという状況になりました。

設立から5年で社員数は1,000名を突破。その中の半数以上が運営業務をおこなっています。

これから「運営」という言葉がたくさん出てきます。Customer Care業務のお客様の対応や、コンテンツの監視業務、to B・to Cの審査業務やAIの教師データの整理業務、そういったオペレーションを総称して「運営」と言っています。

LINEの月間アクティブユーザー数は8,200万人です（2019年9月時点）。その中でDAU（デイリーアクティブユーザー）は約86パーセントを占めています。結構な人数の方に毎日使っていただいています。

売上収益は、LINEグループ全体で昨年（2018年）が2,072億円だったのが、前年比18.7パーセントの成長を見せています。

サービス数の遷移なんですが、直近はゲームなどを含めてだいたい年間20～30サービスくらいをリリースしています。

ちなみにこちら、昨年の11月から今年の10月までの一年間で、グローバルでリリースしたサービスの一部です。

LINE Fukuokaでは、4組織が運営改革をサポート

加藤：ここからが今日の本題というか、LINE Fukuokaの運営を改善、改革している組織の話です。

主にコーポレート領域における業務改善全体をディレクション・マネジメントしているIT支援室と、吸い上げた業務改善ニーズをシステムやツール開発を通じてサポートするLINEの開発子会社LINE Growth Technology、データ分析やデータ応用システムの開発を行うData Labs、そしてGolbal Operation室、この4つの組織がLINE Fukuokaの運営改革をサポートしています。

この中でも、私の所属しているGlobal Operation室が、LINE Fukuokaのすべての問い合わせの窓口を運用しています。社内の困りごとや業務改善したいという要望があれば、窓口にすべて集約されるようになっていて、そこの窓口を私が担当しています。

問い合わせ内容をIT支援室、LINE Growth Technologyとの週次の定例ミーティングで中身を確認し、内容によって対応部署を決めた上で、目的や課題感、緊急度などを踏まえて優先度をつけて対応しています。　

各部署の担当領域で説明すると、Global Operation室は「運営」業務を行っている部署のツールのディレクションや、RPA（ロボティック・プロセス・オートメーション）の導入などをやっています。

運営ツールの作成・開発に関しては、LINE Growth Technologyが対応することが多いです。IT支援室はコーポレート領域を中心とした業務効率化を推進していますが、あくまでもこれは建て付けであって、実際には一番適切な部署、一番早く対応できる部署が対応するという体制をとっています。

各サービスでバラバラになったツールやシステム、Global Operation室が横串で運用改善に着手

加藤：ここからが運営の課題感になりますが、これまでの説明の通り、人数とサービス数はものすごく増え続けています。結果、「運用ツールやシステムがサービスや部署ごとにバラバラ」という状況が発生しています。

私もツールが全部で何個あるか、正直わからないくらいです。なぜこういうことになってしまったかを説明したいと思います。

まず、社員の半数以上が運営と呼ばれる業務に携わっております。派遣の方や業務委託の方にも携わっていただいているので、おそらく国内有数の運営規模ではないかなと思っています。

ここからが課題の本質ですが、新しいサービスができるときは、LINEサービス企画者がサービスやアプリを考えて、開発者が開発をします。アプリの開発者が、我々が使う運用ツールも一緒に開発するんですよね。

運用ツールは、できあがった状態でサービスのリリース直前に「このツールを使ってください。よろしくお願いします」ということで我々のところに話がきます。

セキュリティ含め事前の各種チェックは通っているんだけど、運営側の目線で考えると「このツールでは厳しいな」と思うこともあります。でも、サービスのリリースは直前に迫っているので、「じゃあ一旦これでやりましょう」ということで走り始めます。

そうすると、本来であれば不要な運用が発生したり、新しいサービスごとに運用ツールが増加していくという課題が出てきます。

課題をまとめますと、やらなきゃいけないことは新規サービスの運用構築と既存運用の再設計・最適化です。

しかし、やはり目の前の業務量が膨大すぎて、なかなか対応できないということが続きました。それでも絶対誰かがやらなきゃいけないということで、昨年1月、Global Operation室を立ち上げて、組織を横串で見て変えていくという活動を始めました。

バックオフィス業務も急増　いかに人を増やさずに、対応できる定常業務量を増やすか

加藤：私のスライドはこれが最後です。運営以外のバックオフィスであったり、事務系業務の課題についてです。社員数が増え続け、サービス数が増加する中で事務系の業務も増えてきています。バックオフィスは、いつも必要最低限ギリギリの人数しか採用していないので、結構パツパツな状態が続いています。「人を増やさずに対応できる定常業務量を増やす」ことがずっと課題であるという状況です。

繰り返しの説明になりますが、運営側の課題を解決するためには、「新規サービスの運用構築と既存運用の再設計と最適化」が必要です。また、バックオフィス側の運営課題の解決のためには、「人を増やさずに対応できる定常業務量を増やす」が必要となってきます。

ではここからは、運営側の課題に対して、どういうアプローチをしてどうやって改善してきたかを、沼井が説明します。

多数の運用ツールを1つのプラットフォームに集約、およそ1ヶ月でオペレーションが可能に

沼井佑介氏（以下、沼井）：ありがとうございます。LINE FukuokaのGlobal Operation室に所属しております沼井と申します。本日はご参加いただきまして、ありがとうございます。

今、加藤から、LINE Fukuokaのオペレーションの現状と課題について説明がありましたが、課題解決のための施策がいくつかありまして、私からは「プラットフォーム」「AI」「RPA」の3つについて、ご紹介をさせていただければと思います。

先ほど加藤から、「LINEはいろんなサービスやツールがある」という話がありましたがだいたいどれくらいのツールがあると思いますか？

実は、私も正確に数えたことがないんですが、だいたい500個くらいの運用ツールが存在しています。一般的なツール開発の流れをみると、あるサービスができて、そのサービスで監視や審査などオペレーションが必要になった場合、いちからツールの設計、計画、API開発などを行います。だいたい3ヶ月か6ヶ月の期間がかかります。　

ということで今、私たちのほうで進めているのは、これだけたくさんのツールができているので、これらをプラットフォームという形で、1つにまとめるという取り組みです。

プラットフォームにすることで、いちからツールを開発する必要がなくなり、新しいサービスが発生したときは、だいたい1ヶ月くらいでオペレーションができるようになりました。

サービスごとに異なる操作感はプラットフォームで解決

沼井：もう少し具体的な話になります。LINEが提供しているサービスの中にはモニタリングが必要なものがあり、例えばLINEのタイムラインやLINE BLOG、ライブ配信ができるLINE LIVEといったサービスが挙げられます。

このようなサービスはユーザーが、全世界に向けて動画やテキストを公開できます。だからこそ、わいせつ画像や出会い目的など不適切な投稿・配信からユーザーを守ることも必要です。

そういった全世界へ公開されているものについては、オペレーション上で監視を行っています。モニタリング業務についてはすでにプラットフォームを構築をしています。モニタリングが必要なサービスは、すべてプラットフォームに連動して運用するという形です。

以前は、1個1個サービスがでる度に新しくツールを作っていたので、基準やツールの操作感などもバラバラでした。

例えば、5つのサービスをモニタリングしなければならないオペレーターが、全部設計が違うツールを使うということがあったんですが、こういったところをプラットフォームで解決できるようになりました。

今はモニタリング業務のみしか対応できていないのですが、今後は広告審査やメインサポート、DE（Data Explorer）構築がまで対応できるようにしていきたいと思っています。

投稿される画像は全世界で5,000万枚　AI連携により全体の5パーセントのみを目視

沼井：では引き続き、AIについてもご紹介させていただきます。ユーザーが投稿した画像から問題があるものを見つけて、これを非表示にする。これがモニタリングの1つのオペレーションです。ただ、LINEのグローバル全体で投稿される画像枚数は、1日でだいたい5,000万枚くらいあります。

ちょっと計算してみたんですけれども、5,000万枚をすべて人手でモニタリングした場合、25,000人くらいのリソースが必要になってきます。当然、コスト的にも難しいので、AIを連携して「この画像は問題がありそう」「わいせつそう」とAIが判定したものだけを、人手でモニタリングをさせています。

それによって、全体投稿の約5パーセントの画像のみオペレーションしている、というAIの活用事例です。

GoogleとかIBMなどAPIを提供している会社さんはいくつかありますが、LINEではすべて自社で開発しています。

精度についても、専門的なもので申し訳ないんですが、わいせつ画像の検知性能をPrecisionとRecallという2つの軸で他社APIと比べてそれほど遜色はありません。

AIについては、イメージ（画像）以外にもいくつか開発をしています。下のスライドを見ていただくと、一番左の下、包丁みたいなものが検知されているところが見えますでしょうか。日本ではあまりこういったものはないんですが、ヨーロッパですと動画配信でいきなりナイフを出すとアカウントを即停止させるんです。

ナイフや銃など危険性のあるものを物体検知して、検知されたものを人が確認して、即時停止するというAI活用をしています。

沼井：それ以外は、みなさまから見て一番右側の下、OCR（Optical Character Recognition/Reader／光学的文字認識）ですね。最近の出会い目的のユーザーは、直接リアルタイムでなにかを書いてもすぐ検知されるとわかっているので、画像にして送るパターンが増えてきています。そのような場面で活用しているのがOCRです。

こちらがモニタリングの状況ですが、スライドのこの青の部分、テキストだったら80パーセント、画像だったら95パーセントと書いていますが、この部分がAIの自動処理したものです。画像については5パーセントのみ人で監視していて、テキストは20パーセントとなっています。

オブジェクト検知も含め、現状ではこういった効率化を進めています。映像については、実はなかなか難しいところがあって、映像をスクリーンショットみたいに輪切りにして、それに対してAIのイメージフィルタをあてるという施策をやっているんですが。なかなか難しいところがあって、今後の課題です。

RPAはScratchで開発　タイトルや文面を読み取って担当者を自動で振り分け

沼井：最後になりますが、RPAについてです。今500個くらいツールがあって、プラットフォーム化ももちろん進めていますが、いろんな事情や状況からなかなかすぐにツールの改修ができない、コスト的に導入が難しいとなったときに、RPAを活用しております。

例えば、リスト確認や情報登録などの1つの条件がある程度明確であれば、RPAのロボットですべて自動操作してしまうといった活用イメージです。

弊社の業務バリエーションといいますか、ツールが500個あるということは、500個分の業務があるわけですよね。すべてにカスタマイズで対応していくよりも、スクラッチが速かろうということで、私のチームではすべてスクラッチで開発をしております。いくつか事例を紹介させてください。

障害発生時のエスカレーション対応の事例です。まず、外部からメールで障害の連絡が来ます。今までは人手でメールの内容を読み取って、「これは○○さんの対応」と分類分けをしていました。かつ弊社ではコミュニケーション手段としてSlackも使っているんですが、Slackでそれぞれの担当者に投げるというオペレーションをやっていました。

それをRPAによって、タイトルやメールの内容を読み取って、こういう内容の条件であれば、この人にSlackに自動的に流すといった効率化を実現させました。

言語等については、記載されている通りでPythonですね。環境については、Django、Celeryで、Redsを使ったりしているんですが、こういったところもいろんなものを組み合わせて、最適なものを開発しております。

どんな条件分岐で判断しているのか？　オペレーションの“職人芸”をRPAで分解

沼井：本日来ていただいたみなさんの中にもBPOやセンターの方もいらっしゃると思いますが、オペレーションが長年続いていくと職人芸になっていくんですね。

「どういう条件で作業していますか」というところもよくわからない。「こういう結果を出してくれたらたぶんこうだろう」という形で、オペレーションが走ることが多いと思います。

まず我々がRPAを導入するときには、フロー図を作ります。職人芸ではどういう条件分岐で作業や判断がなされているのかを分解して、結果内容によって自動処理しています。

最後のまとめになりますが、私たちGlobal Operationチームは運営課題解決に向けて、プラットフォームの展開やAIの連携、運用ツール最適化、今ご紹介したようなRPAでツールができないところを補完していく取り組みをしています。

ご清聴ありがとうございました。