LINEのサービスを支える社内システム改善の裏側　プロジェクトマネジメントにおける知見と工夫

LINE Creators Market審査ツール改善の舞台裏

金原まり子氏（以下、金原）：みなさん、こんばんは。金原まり子と申します。

LINE Growth Technology株式会社の福岡開発室でプロジェクトマネージャーをしております。エンジニア出身です。

本日お話ししたいことは、まずLINE Growth Technology（以下：GT）の紹介をさせていただき、その後PMとして関わっているLINE Creators Marketのサービス改善案件についてどのように関わってきたのか、実際の業務風景を紹介しながらシェアできればと思います。私は途中から参加した案件なのですが、代表して最初の立ち上げから共有していきたいと思います。

最後に、PMとしてユーザーとエンジニアの間に立つにあたって何を気をつけているのか。これがよかったということもご紹介できればと思っています。

まずはGTの紹介です。

GTは2018年6月設立のLINEの開発子会社です。Growth開発と呼んでいる、既存のサービスの成長に特化した開発を行っています。

LINEというと、コミュニケーションアプリといった、一般ユーザー向けの開発を思い浮かべるかと思います。LINEとLINE Fukuokaの開発室はそういったサービスの開発を行いまして、GTはリリース後のサービスを成長させるための開発にフォーカスをしています。LINEのエンジニアは「0→1」とサービスを立ち上げる開発をメインに担うエンジニアで、GTのエンジニアは「1→10」「10→100」とサービスを成長させるための開発をするエンジニアとイメージしていただければわかりやすいかなと思います。

CMK審査ツールとはなにか？

金原：それでは、実際にどうやっているか、LINE Creators Marketのサービス改善についてシェアしたいと思います。

まず、LINE Creators Marketがどういうものかといいますと、クリエイターがオリジナルのLINEスタンプやアニメーションスタンプ、カスタムスタンプ、LINE絵文字、LINE着せかえを世界中のLINEユーザーに販売することができるサービスです。CMK審査ツールはそのサービスを裏側で支えているツールです。クリエイターが作成したLINEスタンプ・絵文字などの審査を行う社内運営ツールで、LINE FukuokaのReview&Sales室、略してR&S室が運営しております。

このLINE Creators Marketのサービス改善案件について、現状を把握したところから、優先度を決め、実着手になるまでの流れをご説明します。

どこの企業でもあるあるだと思いますが、営利企業ですと、お客様向けのシステムが優先されて、どうしても社内運営ツールの優先度は低くなってしまいます。CMK審査ツールも、2年前の2017年5月頃に現場から要望を出して改修したのが最後でした。

今回、ツールを利用している現場と、LINEのサービスの運営業務改善を推進している部署とGT（Growth開発専門）で、審査ツールにフォーカスをして、専任のエンジニアを割り当てて改修することになりました。

実際に動くものを作り、フィードバックを開発に反映する

金原：4月よりこのプロジェクトが始まりまして、まずは15個の課題を洗い出しました。例えば、ツールのポップアップで表示されるのが社員番号だけだったのですが、それだと現場としてはわかりづらいので社員名を表示するという小さな改修から、2ヶ月もかかる大きな改修まで、さまざまなものがありました。課題は可視化しやすいようにチケット化しました。その後、現場と各課題の優先順位を決定しました。

LINE Creators MarketはLINE Fukuokaの開発室が開発をしていますので、そこにGTが加わるかたちで、開発環境の構築などの開発に着手していきました。

6月頃からCMK審査ツールの開発が始まりました。最初は簡単な課題の改善で、スモールスタートでした。既存の開発チームとの初めての試みだったので、簡単な課題を1つやってみて、まずは開発環境に慣れるのが急務でした。

開発して動く状態になったら、運営側と品質保証のテストをしていただくQA室にデモをしました。ここは工夫したところなのですが、実際に使っていただく現場にQAの視点からフィードバックをもらって、それを開発に反映しました。Demo&Feedbackについては、次のスライドで詳しくお話しします。

フィードバックを反映したあと、ソースレビューをLINE Fukuokaの開発メンバーに依頼します。もともと存在していた開発フローに沿ってソースレビューを受けました。これは、ほかの開発業務があるLINE Fukuokaのエンジニアの負担にならないようにする工夫です。

ソースレビュー・QA前にフィードバックをもらうことで、影響を最小限に

金原：それでは、Demo&Feedbackについて詳しく共有します。

目的は、実際に運営側に動作を見てもらい、意図どおりに動くか、使いにくい点がないかを確認し、より使いやすいツールになるようブラッシュアップをすることです。先週もちょうど実施したのですが、運営側から2名、QAから2名、Global Operation室（GO室）から1名、GTからは4名参加して、約1時間のミーティングを行いました。ミーティングではエンジニアがデモを行なっています。

実施するタイミングなのですが、ソースレビュー・QAを行う前に実施しています。このタイミングで行うことで、GT側での修正だけになり、影響を最小限にすることができました。

実際にこれをやってみてどうだったかというと、ひと言で言うと好評でした。運営側からは具体的にイメージが湧くようになり新たな改善アイデアが出てきましたし、改修したエンジニアからもアイデアが出てくるようになりました。例えば「ステータスの表示の文言をほかと合わせましょう」など、全員でより良いものにしていくよい機会になりました。

すべての情報をオープンにして議論する大切さ

金原：続いて、サービス改善、ユーザーとエンジニアの間に立つことにおいて、PMとして私が心がけていることについて共有したいと思います。

「Open Communication Vertical Decision-making（オープンな議論とリーダーによる決断）」。これはLINE STYLEというLINEの企業文化を表したもののなかから持ってきたものです。

私はこの「ユーザーにもエンジニアにもオープンに議論を行う」、とくにエンジニアにはすべての情報をオープンにして、運営側のユーザーには議論に入ってもらうことを心懸けております。

「リーダーによる決断」という部分ですが、サービス改善を行う上でリーダーは1人には絞れないので、どういった決断をして、どんな結果になったかを誰にでもわかりやすいように明確にするようにしております。

Growth開発やサービス改善は長く続く道です。フィードバックを受けながら一緒に歩いていけるよう、PMとしてこれからも精進していきたいと思っています。

最後になりますが、私が実際にPMとしてやってよかったことを共有していきます。

まず、一人ひとりが思っていることを伝える場を作りたいと思いまして、振り返りミーティングを実施しました。リリースごとに、終わったあとにその改修に関わったすべての人を呼んで、一人ひとりに「ここがよかった」「ここを改善したい」ということを書いてもらって、発表してもらいました。

くさいことを言いますが、人間は感情がある生き物です。みなさん思いの丈を持っています。その思いの丈をぶつける場にもなりまして、チームがより良いものになりました。

次に、良さそうなことは取り入れてみるというスタンスでいつも取り組んでいます。その流れで取り入れたことはランチミーティングです。これはLINE Fukuokaのほかのチームがやっていて好評だったので取り入れました。

会議室を借りまして、東京と福岡をテレビ会議でつなげて、みんなでお弁当を食べるというものです。1ヶ月に1回実施しました。参加は自由で、どこかお店に行くわけでもなく、それぞれ自分のお昼ごはんを持ってきて食べるという気楽さで好評でした。毎回参加率が8割を超えていて、みんなでチームビルディングができたと思います。

以上、みなさんのヒントになれば幸いです。ご清聴ありがとうございました。

（会場拍手）

LINE NEWSのサービス改善システム開発の舞台裏

司会者：ありがとうございました。では、続いてのセッションにまいります。平井さん、よろしくお願いいたします。

平井伴哉氏（以下、平井）：みなさんこんばんは。LINE Growth Technologyでサーバサイドのエンジニアをしている平井と申します。よろしくお願いします。

自己紹介ですが、私は今年の6月にGTに入社しまして、サーバサイドエンジニアです。

福岡開発室に所属しています。今回はシステム開発事例の紹介をさせていただいます。

本日お話しすることは、LINE NEWSのサービス改善システムのご紹介ということで、「どのような課題を解決するために必要だったのか？」「どんなアプローチで開発を行ったか？」。そして最後にメインの機能だけになりますが、実際のシステムの画面をご覧いただきながらご紹介できたらと考えています。

まず、LINE NEWSのどの部分の運営業務の改善を行うのかをお話しします。

LINE NEWSをご覧いただいている方もいらっしゃるかと思うのですが、LINE NEWSの記事は新聞や雑誌など、さまざまなメディア様から記事を提供していただいています。

また、このメディアのLINE公式アカウントと友だちになりますと、LINEのトークに記事が定期的に送られてきます。LINE Fukuokaの運営チームは、記事が送られる前に、レギュレーション違反、例えば誤字脱字がないか、差別的な内容が書かれていないかなど、そういったことを毎日チェックしています。

運営業務における4つの課題

平井：このLINE NEWSの運営業務がどのような課題を抱えていたか、運営フローを交えて説明します。

こちらの図の左側が運営業務のフローで、右側が実際に使っているツールです。

大きく4つの課題がありました。1つ目が、Excelをメインに利用して運営を管理していた点です。とりあえずExcelを使ってなにか管理することはあるあるな話かなと思います。ですが、Excel自体は表計算用のソフトなので、こういった運営業務の管理はなかなか向いていないのかなと思っています。

LINE NEWSの運営業務で使っているExcelにもすごくたくさんの情報が載っていました。メディアやカレンダー、担当の振り分けといった情報も載っていまして、実際にモニタリングしてチェックした結果の管理もすべてExcelでやっている状況でした。

このように、すごくたくさんの多くの情報が載っています。Excelはあくまで表計算ソフトなので、大量の情報を持ちつつ運営業務を管理するという用途には向いていません。その結果、作業ミスが発生したり、作業記録も残らないといった状況になっていました。目がチカチカして見たくない。そんなExcelになっています。

2番目に、多数のツールの使用による煩雑な作業ということで、Excel以外にもさまざまな管理ツールを使って業務を行っています。実際の記事の確認は分単位で担当者が作業をしています。なので、複数のツールを切り替えながら記事の確認作業を進めることは、作業者の負担になっているのが現状でした。

3番目に、メンテナンスされない管理ツールたち、ということで、すべてではありませんが内製で作っているツールもいくつか存在しています。これらのツールはメンテナンスする人が決まっていなかったり、作成者が不在だったりと、メンテナンスが誰もできない状態になっていました。そのため、例えばブラウザがアップデートしたら急に使えなくなってしまうといった危険が潜んでいる状況になっていました。

最後に、単純にメディア数が増加したことによって、こういったExcelを使った現体制の運営は、限界に近づいていました。

そこで、こういった課題を解決するために、新しくサービス改善システムを導入することになりました。これがシステム導入後の運用フローです。

この図に小さく「LNDC」と小さく書いてあるのですが、これはシステムの略称になります。ほとんどの作業をシステム上でできるので、非常にシンプルな作業になっています。

手作業で行っていた作業を自動化したり、各情報の管理を全部システムでできるようにしたため、現場責任者や実際に作業をする担当者の負担を減らすことができました。もちろん、このシステムは私たちが作っているので、もし不具合があれば対応できる体制になっています。

このようなシステムを導入することによって、作業品質を改善でき、運営品質も向上させることができました。

要件定義において工夫したこと

平井：実際にこのようなシステムを作ったのですが、開発にあたってどのようなアプローチを行ったのかをお話しします。

開発の体制はこの図のようになっています。

東京側にLINE NEWSの本体であるサービス開発部門と企画者がいます。そして福岡には、私たちGTと、LINEのサービスの運営業務改善を推進している部署があります。

開発はPM1名とテックリード1名、エンジニア3名の計5人で行い、今回のシステムはだいたい4ヶ月程でリリースしました。

要件定義はLINEのサービスの運営業務改善を推進している部署に大枠を作ってもらいました。その情報に加えて実際の運営チームがやっている作業を見せてもらい、それらの情報をもとに動きの入った画面のモックを作り込んで実際に触ってもらい、レビュー＆ブラッシュアップして仕様を確定しました。

そこでもらったフィードバックとしては、記事の確認作業が、私たちは1回だけだろうと思って作っていたのですが、実際はごく稀に複数回チェックする場合があるといったフィードバックをいただきました。なので、実際に動く状態のモックを使って、イメージしやすい状態でフィードバックをもらうことはすごく大切なことだな思いました。

それに加えて今回すごくやりやすいと感じたのは、運営チームの方が要望をただ言うだけでなく、開発が難しい、工数がかかりすぎてしまう場合は、「一覧にこんな情報を載せてくれれば運営で回避できますよ」といった代替案も提案してくれました。そういった情報を積極的にいただくことができたので、開発もスムーズに進んで、システムとしてもすごくいいものができたかなと思っています。

開発において意識したこと

平井：開発スタイルとしては、チケット駆動開発ということで、課題をどんどん上げて、それを1つずつ潰していくってスタイルで行いました。

また、毎日のミーティングも行っています。

意識していたポイントとしては、先ほどお話したように、とにかく動くものを使ってフィードバックをいただきました。

あとは、いきなり100パーセントのものを作るんじゃなくて、重点課題から優先的に取り組みました。これは、スモールスタートで開発サイクルを速くする意図で行っています。

また、もともとあった運営フローに沿ってシステムを作るということはしませんでした。エンジニアたちだけで集まって、他に自動化できるところがないか洗い出しています。あとは無駄な機能は極力省きたいということで、「あったら便利かな？」という機能は極力省いています。今回でいうと配信カレンダーという機能がありまして、カレンダーをつくるとなると、週間と当日をつくりたくなりがちなんですが、色々話していくうちに「週間カレンダー、実際いらないよね？」という話になり、省くことにしました。スマートでシンプルなシステムの方がユーザーとしては使いやすいはずなので、そのようなかたちで開発は進んでいました。

ツールはSlackやJira、Confluenceなどを使っています。