LINEのサブスクリプションサービス開発プロセス　「LINEスタンプ プレミアム」の事例を共有

クライアント開発チームマネージャーの視点から

竹下秀則氏：今日は「実録 LINEスタンプ プレミアム開発の現場」というテーマでお話しいたします。LINE Fukuoka開発室の竹下秀則と言います。よろしくお願いします。

まず自己紹介をさせてください。現在、私はLINE FukuokaにてLINEのメッセンジャーのクライアント開発チームのエンジニアリングマネージャーを担当させていただいています。

最近、私自身は手を動かすことは少なくなってきたんですが、iOSエンジニアとして開発に携わっています。インターネットでは@taketinという名前でいろいろ活動していますので、もしよろしければフォローしていただければと思います。

最近ハマっているのは、サウナとピザを焼くのとリングフィットアドベンチャーです。最近水風呂用のビニールバスタブを購入したので、家サウナ活動が非常に捗っています。

2番目の写真はサウナの聖地、上野の北欧というところなんですけど。出張したときに行くことができました。九州には熊本に湯らっくすというサウナの聖地がありますので、みなさん旅行できるようになったらぜひ行ってみてください。

今日のアジェンダですが、クライアント開発チームマネージャーの視点から主に4つお話したいと考えています。まずは、地方ブランチであるLINE Fukuokaの簡単な歴史ですね。そしてどのようにLINEの新機能の開発を行っているか。

次にLINEの新機能の開発フローとクライアントの開発プロセスについて。そしてサブスクリプションサービスを開発することによって得た知見ですね。主に支払いなどに関するナレッジを共有できたらいいなと思っています。

最後に我々が持っている課題についてご紹介したいと思います。あまり実装よりの話ではないんですけれども、「福岡でこういうことをやってるんだ」という感じで聞いていただければと思います。

LINE Fukuokaの歴史と開発した新機能

では、さっそくLINE Fukuokaの簡単な歴史と、どのように新機能開発を行っているかから始めたいと思います。改めてLINEの福岡ブランチについてお話ししますと、実は会社自体の歴史は古くて、前身のNAVERの系列会社であるNHST Japan株式会社福岡センターが2009年に立ち上がっていました。

LINEのリリースは2011年の6月なんですが、みなさまご存知のようにその後急速にユーザー数が拡大して、LINEに関するさまざまな業務を手掛ける国内第二の拠点として、既存のNAVERの拠点をベースに2013年にLINE社の100パーセント子会社であるLINE Fukuokaを設立しました。開発組織は翌2014年に立ち上がりました。

当初はエンジニア数は数えるほどで、LINEのファミリーアプリと呼ばれるLINEバイトなどのアプリの開発を東京と分担して行うところからスタートしました。私もこの頃入社しました。

現在は、エンジニアだけでも100人弱の組織になりました。LINE Fukuokaで開発運用しているサービスは8個ほどになります。

2015年からShopチームと呼ばれる開発チームが福岡にできました。LINEのメッセンジャーアプリはご存知のようにさまざまな機能が入ってまして、各機能ごとに担当チームが東京、福岡、韓国、台湾に存在しています。

その中でもShopパートはスタンプやテーマ、絵文字などを販売、使用する部分を担当するパートになります。もともと東京で開発を一手に引き受けていたものが、業務の拡大にともなって福岡にもチームを作ったという経緯になります。

当初は福岡ではサーバ開発のみを東京と分担して行っていたんですが、2017年に福岡でクライアントサイドの開発を引き継ぐことになり、Shop Clientチームが誕生しました。私もここでプレイングマネージャー的な立ち位置で参加することになりました。

メンバーの国籍は、日本、韓国、中国、台湾、ドイツなど、非常に多様です。コミュニケーションは基本的に日本語、英語が入り混じって行われています。希望者は英語や日本語のレッスンを会社負担で受講することができます。

当初はiOS、Android合わせて4人ほどのチームだったんですが、徐々に規模が拡大して現在は13名のチームとなりました。最近はほぼすべてのShop周辺の開発を福岡で完結できるようになっています。

今までに我々が開発してリリースした新商品はこのような感じです。2018年にLINE絵文字ですね。2019年にカスタムスタンプ、そしてLINEスタンプ プレミアム。そして今年、まだリリースされたばかりなんですが、メッセージスタンプをリリースしております。

今のところだいたい年に2つほど大きい新機能、新商品を開発していっているという感じです。みなさんこれらをご利用いただいていると非常に嬉しいです。今日はこの中からLINEスタンプ プレミアムについて触れていきます。

LINEスタンプ プレミアムの新機能開発の進め方

ここまでざっと福岡ブランチの歴史とLINE Clientチームの発足から現在までをご紹介しました。次にどのようにLINE上での機能開発、またプロジェクト進行が行われているかについてお話しします。

まずは、我々Shopチームが新機能開発プロジェクトをどのように進めているか、LINEスタンプ プレミアムを例にご紹介します。LINEスタンプ プレミアムは2019年の7月にリリースされました。

料金体系としては月額240円、年割2,400円。そして学生割引があって、半額の月額120円でご利用いただけます。このサービスはリリース後一定期間が経過したクリエイターズスタンプが使い放題のサービスになっていまして、現在300万種類以上のスタンプが利用可能となっています。

実際のプロジェクトの進行ですが、まずは企画チームが仕様の検討を開始します。その企画の実現可否についてある程度エンジニアと話しておきます。ここで技術的に不明瞭な部分がある場合は、検証のためのプロトタイプの実装を行って進めていきます。

今回我々は、iOS、AndroidのIn App Purchaseの部分の仕様についていろいろ試すことがあったために、サーバと連携して支払い部分のテストだけできるプロトタイプを先に実装して進行しました。

仕様がある程度固まったところで、キックオフミーティングを行います。ここでは各拠点の担当者でリモート会議を行います。言語は日本語がメインで、会社の専属の英語通訳の方がいらっしゃるので、その方に入っていただきます。

ここでは、プランナー、エンジニア、データサイエンティスト、UI/UXデザイナー、QAの方など、プロジェクトに関わっていく職種全員の方が集められて、プロジェクトマネージャーがプロジェクトの目的やロードマップの説明を行います。ちなみに弊社ではプロジェクトマネジメントを専門に扱う部署があります。

今回LINEスタンプ プレミアムでは仕様検討の結果、このような感じの対応箇所が見えてきました。

まず左のチャットルーム、スタンプの送受信の部分ですね。そして、入力された文字に対して適したスタンプをサジェストするオートサジェスト機能というものがあります。これは画像の真ん中のスタンプがたくさん並んでいる部分です。あとはスタンプキーボードですね。スタンプを選ぶところの周辺。

そして、真ん中の画像は商品の詳細ページですね。ここではボタンのハンドリングなどいろいろと対応するところがありました。

右側の画像は設定ページですね。今回、実際の購入に進むLPはWebビューのほうで実装されているんですが、その先の購入部分のロジックも当然対応が必要でした。

工数の見積もりと進捗の管理

次に、実際に担当にアサインされたメンバーで工数を見積もっていきます。我々一人ひとりも最初からこのLINEのアプリに関わっているわけではないので、従来の実装に対して十分な知識を持っているわけではないんですね。ですので、できるだけ無理のない見積もりが取れるように、アジャイル開発のプランニングポーカーという手法を用いて、できる限り複数のメンバーで見積もるようにしています。

ここではプランニングポーカーの詳細は省きますが、タスクに対して相対的なポイントを参加者全員で出し合ってタスクボリュームを見積もるという手法です。もしご興味あればお調べいただければと思います。

このプランニングポーカーの手法を用いることで、開発担当者だけでは知り得ない実装のはまりどころや仕様で見落としているポイントなどを発見することができて、より正確な見積もりを出すことができていると感じています。最終的に担当者の熟練度やスキルなどを加味して妥当な工数を算出します。

弊社ではバグトラッキングシステムとしてJIRAを利用しているんですが、この見積もりをJIRAのガントチャートにプロットして進捗を管理していきます。このあたりはいつも私がやる仕事になりますね。

実際に開発が始まって、やはりスペックが不明瞭な部分や、検討が抜けていて仕様の変更が必要になる場面もあります。そういった場合はプロジェクトマネージャーに報告して、その結果工数が延びる場合はスケジュールが見直されます。無理なく変更が行われます。

我々は今のところガッツリとしたスクラム開発を取り入れているわけではないんですが、ある程度開発が進行したら毎週の定例会議で開発中の画面をみんなで確認したり、スプリントレビュー的なことを行って、成果物がみんなの想像どおりかどうかのチェックを行っていきます。

規模の大きな機能の開発ではテストも念入りに行う必要があるので、通常ではリリース前に2週間のQA期間を用意しているんですが、比較的大規模なプロジェクトではその前にさらに2週間のPre-QAと呼ばれている期間を設けています。主にPre-QAでは基本的な機能に問題がないか確認するサニティーチェックを中心にテストを進めていきます。

無事社内のQAをパスすると、iOSはAppleのレビューに進みまして、その後ビジネス側と調整した日にリリースとなります。基本的にiOS、Android同時にリリースできるのがベストなんですが、やはりAppleのレビュー次第では別々のリリースということもあります。

Feature Flagを使ったブランチ戦略

次にクライアントサイドの開発プロセスについてご紹介します。先ほども触れたように、現在LINEのクライアントアプリはグローバル4拠点にて協力して開発されていて、iOS、Android合わせて総勢200人ほどのエンジニアが関わっています。

我々の現在のリポジトリの様子がこちらになります。言語の比率で言うとこのような感じで、iOSはObjective-CからSwift、AndroidはJavaからKotlinへの書き換えが進んでいることがおわかりいただけるかと思います。

総コード行数なんですが、リポジトリに入っているコードの行数で、おもしろいことにiOS、Androidともに約200万行ほどということです。ちょっと今回調べてみて驚きました。

コミットはiOSが175,000コミットほど、Androidが194,000コミットほど。9年ほど開発が続いていますので単純に割ると、1日平均70～80ほどのコミットが行われているということになります。

次に、どのようなブランチ戦略で開発を進行しているかをご説明します。もともとgit-flowやGitHub Flowなどで運用していた時期もあったみたいなんですが、現在はこのようなかたちで落ち着いています。

まずMasterが1本ありまして、新規開発はここにコミットされていきます。開発期間の長い大きいプロジェクトはFeature Flagというコンパイラフラグを使ってMaster上で開発します。

どのようなものかと言うと、例えばもしFeatureブランチで大きいプロジェクトを運用した場合は、とくに開発者が多いアプリではこのような状況になりがちですね。複数プロジェクトが走るという感じですね。

そうすると、とくに大きいプロジェクトほどライフタイムも長いので、Masterとの解離を避けるためにけっこうバカにならないマージコストが発生します。ですが、このFeature Flagを使うと随時Masterに修正をマージできますので安心して進めることができます。

そのほかにも、例えばQAのときに大きな問題があったとき、このフラグをオフにするだけで機能全体をないことにできるので、リリースを延ばさなくてもよい。リリースタイミングをコントロールしやすいといったメリットがあります。

またそのほかにも開発中のコードがほかのエンジニアの目につきますので、それが自然とコードレビューにつながるなどといった利点があります。

もちろん良い点ばかりでもなくて、コードをフラグで分岐させるので、可読性が落ちる部分があるといった問題もあります。

このあたりの詳しいところは弊社エンジニアの発表資料がありますので、ぜひこちらもご参照いただければと思います。それから、Android用のみになるんですが、我々が活用しているFeature FlagをOSSでもご提供していますので、よろしければご参照ください。

2週間のQA期間

話を戻します。QAが始まるとreleaseブランチを作成します。release/バージョン番号といった感じですね。QA期間中に見つかったバグは、このブランチでどんどんfixされていきます。

QA期間中にもMasterでは開発が進行しますので、releaseブランチとの乖離が起きないように毎日CIでオートマージを行っています。

ここでコンフリクトが見つかると、開発者が全員参加しているLINEグループに通知が来ます。そしてそのコンフリクトを作ったであろう担当者にメンションが来る仕組みになっています。これが来るとドキッとします。

そして無事解決できるとこんな感じになります。

このようなデベロッパーエクスペリエンスの向上を主目的にした開発チームも専任で存在していて、日々改善を行っています。

また、そのほかにもGitHubのコードオーナーの機能を試したりもしています。コードオーナー機能というのは、このように設定ファイルにフォルダごと、またはファイルごとのオーナーをチームまたは個人として設定できる機能です。

関連箇所を修正したプルリクエストを作成した場合に、自動的にこのオーナーがレビュアーとして設定される仕組みになっています。例えば、「ほかのチームに勝手に自分たちのチームのコードが変更されていた、よくわからない」みたいなことを少しでも防ぐ助けになっているかなと思っています。

これが個人ではなくチームがアサインされた場合は結局放置されてしまう場合も多くて、現状ものすごく有効に機能しているとは言い難い点もあります。

また話を戻しますと、releaseブランチのQA期間が終了するとリリースになります。我々はこの機能開発期間とQA期間をそれぞれ2週間のサイクルで回しています。このサイクルをリリーストレインと呼んでいまして、リリースを定期的に行うことを決めておくことで、例えば機能のリスケジュールなども比較的心理的抵抗を少なく行うことができると感じています。

更新日時と請求日時について

それでは、次に今回サブスクリプションサービス開発から得た知見をご紹介したいと思います。

今回我々はiOS、Android、WebのそれぞれでLINEスタンプ プレミアムを提供しました。こういったサブスクリプション機能をマルチプラットフォーム展開するにあたって、考慮しなければならないことなどをお話しします。

まずは更新日時と請求日時にまつわるお話ですね。iOS、Androidともに定期購入期間についてはいくつかの選択肢があって、iOSは1週間、1ヶ月、2ヶ月、3ヶ月、6ヶ月、1年。そしてAndroidに関しても同様ですが、2ヶ月という期間がないといったような感じです。

Webのストアに関してはもちろん縛りというものはないので、自分たちで決めることができるんですけれども、iOS、Androidを同じにしておいたほうが無難だと思われます。

更新のタイミングなんですけども、iOS、Androidともに、基本的に最初に購入した日の翌月の同日に更新されています。11月30日購入であれば翌月同日の12月30日、さらに翌月の1月30日、2月は少ないので2月28日といった感じです。Webの実装もこれに倣いました。

そして、実際の請求タイミングは1ヶ月後の翌日の午前中としました。ここでユーザーの購読タイミングによっては、例えば有効期限が11月30日で請求が12月1日になる。そして翌月の12月30日更新で、そうすると請求がその翌日になるので12月31日になるといったことが起こり得るんですね。

このように同月に2度請求が発生するパターンというのがあり得ます。ユーザーが登録しているカードの請求の締め日にもよるんですが、月によっては2ヶ月分の請求が来てしまうということになるわけです。これはクレームにもつながりかねないので、しっかりユーザーに注意を促しておくことが必要かと思います。

LINEスタンプ プレミアムでは当初この件についてカスタマーサポートに問い合わせがあったので、毎月しっかり契約期間を明示してLINEのオフィシャルアカウントから通知するようにしました。今のところはこれでクレームなどは起きていないようです。

プラットフォームの違いによる問題

次に、支払いを行っているプラットフォームと利用しているプラットフォームが異なっているというケースについてお話します。

これはどういうことかと言うと、例えばこのようなケースが起こり得ます。iOS、Android間で機種変更してLINEアカウントも移行したけども、元のプラットフォームでサブスクリプションの解約を忘れていたときですね。

サービス側でできることとしては、どのプラットフォームで購入しているかの情報と現在利用しているプラットフォームを突き合わせて、相違がある場合は注意を促すということは可能です。もちろん、このままの状態でも支払いいただいていることには変わりないので、サービス側としては問題ないんですけれども、ユーザーに教えてあげたほうが親切という感じですね。

LINEスタンプ プレミアムではこういったケースではアラート表示してユーザーに告知するようにしています。スライド上では英語になっていますが、ちゃんと日本語で表示されます。これがクロスプラットフォームの問題でした。

次に、iOS固有の知っておいたほうが良いこととして、サブスクリプショングループの概念があります。サブスクリプショングループは、商品内容が同じ、つまり重複購入があり得ないサブスクリプション商品の定義範囲のことです。

例えば、通常グレードと価格が高く内容が優れているプレミアムグレードの商品を作成する場合、サブスクリプショングループは同一で定義する必要があります。なぜならば、2つが同時に購入されることはあり得ないからです。

逆に、まったくコンテンツ内容が違うもの。例えば、なんらかの番組をストリーミング配信するアプリで複数のチャンネルを提供する場合など、同時に複数のサブスクリプション購入が行われる可能性がある商品の場合。これは別のサブスクリプショングループで登録する必要があります。こんな感じですね。

間違ってこういう分け方をして開発を進めると、最終的にAppleの審査でリジェクト対象になりますので気をつけて設計をしていただいたほうがよいと思います。

iOSとAndroidで仕様が違う部分で知っておいたほうが良いのが、アップグレード、ダウングレード、クロスグレードの概念になります。この図は、先ほどまでの図に1年のプランを追加したものになります。

アップグレード、ダウングレードは字の通り価格が高いがより内容が優れているもの、または価格が低いが内容は限定されているもの。クロスグレードに関しては、内容は同じだが購読期間が違うので価格が違うものになります。

この新しいプラン価格、および開始の適用タイミングがプラットフォームによって違います。iOSはアップグレード、ダウングレード、クロスグレードによって新しいプラン価格、および開始の適用タイミングが固定されているんですが、Androidに関しては比例配分モードという概念があって、コード上でパラメータにてどのモードにするかを指定することができます。

こういったプラットフォーム間の差異も考慮してサービス構築を行う必要があります。詳細はぜひ各プラットフォームのドキュメントを参考にされてください。

今後の課題

最後に、そんな我々の今後の課題についてお話したいと思います。現在、我々は組織図的には職能型組織として分かれていて、プラン、デザイン、エンジニア、QAといった部署を横串で横断するタスクフォースという形式でメンバーを集めてShopの開発を行っています。

ですが、組織をまたぐとお互いの状況が見えづらかったり、人的リソースを効率的に運用できているのか疑問に感じることもままあります。

そこで、弊社にはLean & Agile Teamという全社を横断してアジャイル開発を効果的にプロジェクトに導入するための支援を行う専門の組織があるのですが、そのチームの助けを借りてプロジェクトチームの開発手法としてスクラムを取り入れようとしています。

Lean & Agile Teamの仕事、そして弊社がどのようにアジャイル化に取り組んでいるかについては、昨年行われた弊社のイベントで発表された資料をご参考いただければと思います。

DX（Developer Experience）の改善についてですね。最初にお話した通り、LINEのクライアントは数百万行のコードからなる非常に巨大なアプリです。例えば、クリーンビルドするのに10分以上時間がかかったりしています。また、まだまだ依存関係が非常に複雑で、レガシーなコードも残っています。

できるだけ開発においてビルドに割く時間を減らせるように、iOS、Androidともにモジュール化を進めています。iOSはフレームワークに分けて、Androidはライブラリモジュール化するといった感じですね。

また、こういった大規模なリファクタリングをするためにはそれなりにまとまった時間が必要ですので、当然ビジネスサイドにも理解を得る必要があります。弊社はこういったところは非常に話を聞いてくれる組織なので相談しやすい。理解があるので助かっています。

このあたりのより突っ込んだ話は……さっきからほかのスライドばっかり紹介してますが（笑）。弊社エンジニアによるDevDayの発表資料および最近リリースされたLINE Engineering Blogのエントリーもぜひご覧いただければと思います。

以上、4つのアジェンダについて話してきました。

我々は、福岡でLINEを一緒に盛り上げてくれる仲間を探しています。もしLINEスタンプの新商品開発や技術的課題の解決に興味を持っていただけたら、ぜひお声掛けいただければと思います。みなさんご存知かと思いますが、福岡はご飯はおいしいですし、家賃も安くて広いところに住めます。

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