この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
2023/4/11に実施されたイベント、DevelopersIO Day Oneの中でメインセッション1つ目「事例で学ぶ!! 東急様のLINE施策と技術課題へのアプローチ」のレポート記事です。
弊社が日比谷にオフィスを移転して始めてのオフラインイベントとなったDevelopersIO Day One、その当日の雰囲気を少しでも感じていただけると幸いです。イベント全体の概要などは以下のConnpassにまとまっているので、よければこちらもご確認ください。
セッション概要
3年前からクラスメソッドが支援してきた東急様LINEプロジェクトは半歩先をいくLINE活用を行い、友だち登録者数は計80万人を超える事業に成長してきました。これまでに直面してきた様々な課題に対して、技術視点でのアプローチを中心に、運用やビジネス視点、LINE活用まで広げた解決方法をご紹介します。
登壇者
- パネラー
- 東急株式会社 井上様
- 東急テックソリューションズ株式会社 石井様
- 安東貞義（あんでぃ）
- JungHyeonjae(ヒョンジェ)
- 日吉杏太
- コーディネーター
(左から、あんでぃ、ヒョンジェ、日吉、石井様、井上様)
セッション
gaoryu
これから事例を紹介していくんですけれども、それぞれお客様側としての話は井上様、運用周りの話は石井様から、クラスメソッド側として技術面の話はヒョンジェさんから、全体的な話は安東さん、日吉さんからお願いしたいと思っております。それではさっそく始めさせていただきます。
最初のところなんですが、始まりをご紹介したいと思います。東急株式会社様とクラスメソッドは新規顧客獲得と既存顧客のロイヤリティ向上を目的として2020年1月にスタートしました。最初は東急さんから新たな顧客接点を早く安く作りたいという話でしたが、いきなりですが井上さんからで大丈夫ですか？
東急様×LINE事業のはじまり
井上様
はい、東急は色々事業やっていて会員数として250万人いるんですが、より新規顧客の獲得を獲得するため、2019年頃からデジタルアセットを使えないか模索していました。あの、どこの会社でもあるとも思うんですが、安く早くでお願いしたいというのが社内でもありまして、その際に何とかアサインしてもらったのが石井さんでした。じゃあアサインはしてもらったがどうしようというところでした。
gaoryu
安く早くという話もありましたが、最初にクラスメソッドとしてお声がかかった時安東さんはどのように考えていましたか？
あんでぃ
どう考えたかというと、そうですね。ちょうどその時はコロナ禍でバタバタ状態で始まりましたね。安く早くを実現するためとにかく足りないものだけ作るという方針でした。LINEの管理画面はそのまま使ったり、石井さん側でもPowershellでバッチを作ってもらったりなど、お互い作りながらでなんとかやってました。
すごい簡単なLINEの活用イメージですが、ユーザさんがポイントカードの登録とかお気に入り店舗の登録などの体験があって、その際にユーザさんのIDが取れるので、LINEの管理画面を使ってLINEユーザIDを使ってアプローチしていくということを最初行いました。
もう少しLINE公式アカウント周りの解像度を上げたイメージがこちらです。会員情報をファイルでもらってカード会員情報を溜め込んで行って、突合処理を行なって問題なければLINEユーザIDを公式アカウントに渡して、スタッフさんがLINEを通じてメッセージを配信していくなんてことをやってました。またユーザの登録情報に応じてLINE公式アカウントによる訴求の方法を変えたりなんかも実現していました。
事業に合わせたアーキテクチャの選択
gaoryu
ありがとうございます。じゃあもう少しビジネス的な部分をいくつか伺いましたが、もう少し技術的な説明もヒョンジェさんお願いできますか？
ヒョンジェ
はい、こちらが案件でのAWSのアーキテクチャ図になります。
詳細は省略してますが、CloudFrontとAPI Gatewayなどを使ったサーバレスなアーキテクチャで実現しています。コストメリットやトラフィックに耐えるための可用性を考慮してこの構成にしています。LINEプラットフォームはとてもユーザ数の多いプラットフォームなのです。サーバレスにすることでDynamoDBの読み取りやLambdaの実行などは従量課金となるサービスなので、夜間の使用されてない時間などのコスト削減が実現できます。またトラフィックに対してリソースもスケーリングするので、お客様がキャンペーンなどを実施した際の高負荷にも耐えれるような構成になっています。
またインフラに関して考える時間が減るので、工数的なコスト削減も実現できます。このようにリソース量などの変更が頻繁に行われるサービスではサーバレスが有効な手段だったかなと思っています。
gaoryu
ありがとうございます。すごいわかりやすくて良いですね！それではここからは、日吉さんからこれまでの取り組みについてかいつまんでご説明お願いします。
これまでの取り組み〜LINEでの体験提供・システム開発〜
日吉
そうですね、始まりの部分は冒頭ご説明いただいたので私の方からはどういうご支援をさせていただいたのか、これまでの取り組みについてご説明させていただきます。 最初はシンプルなカード登録からスタートしまして、ユーザ情報とカード情報が紐づいたデータ基盤ができて、そこからユーザさんの属性や購買履歴に応じてセグメント配信ができるようになりました。2021年9月にはまる得キャンペーンという機能をご支援させていただき、カード登録と組み合わせてキャンペーンへのエントリーと購入でポイントが付与されるというところをご支援させていただきました。
また弊社のパッケージであるCX Orderというサービスについても支援させていただきました。東急ストアさんの方で現在もご利用いただいております。
今ではLINE公式アカウントは10個数ほどあり、友だちの合計も98万人ともうすぐ100万人に迫っており、この規模にスケールするまでご利用いただいています。 また100周年記念キャンペーンをご支援した際、2ヶ月で5万件のエントリーをもらうこともできました。私自身は普段は沖縄にいるんですが、沖縄のホテルの宿泊の際に利用させてもらいました。もちろん、関係者だからといってキャンペーン当選の優先などはないので、残念ながら落選しておりました（笑)
これまでの取り組み〜TOKYU POINT CARD on LINE〜
日吉
2022年5月には東急ポイントカードオンラインをご支援させていただきました。デジタル会員証を発行してポイントを付与したり、ポイントを利用したりなどもできています。またこのカードには楽天アカウントを紐づけることができて、LINEと楽天の両方のポイントを付与することができるサービスになっております。カード連携者数も2022年5月ローンチ後に19万人、POSでスキャンされた人数も3月で11万人となり多くの方に利用いただいています。
ここで井上さんにご質問なんですけれども、これだけのユーザさんに利用されていますが、従業員の方や社内の方からの反響などはありましたか？
井上様
印象に残っているのは実際に研修センターの方にも見て動かしてもらったんですが、これだとアプリを出すだけで東急ポイントも楽天ポイントも紐づけるとダブルで貯まるんですよね。今までだと、どちらもカードを(物理的な)板として2度出す必要があり面倒だったんですよね。ここが短く改善され、お客様もレジの方のためにもなり、実際にレジの方からも「おお、これ便利ね！」と言ってもらえたのが記憶に残っていますね。
少なくともですが、会計ごとに1回のスキャンあたり3秒ほどかかります。さっき計算したんですが単純に累積していくとで3日と19時間ほど、時間が削減されることがわかっており、顧客を捌ける人数も増えているので効率面でも改善が起きたかと思います。
gaoryu
良い掛け合いが生まれて嬉しいです！ここからは運用面に関しては、石井さんからお話いただこうかと思います。
石井様
東急ストアさんですと現在月150本前後配信をしていますが、POSデータと連携することでパンをよく買う方などの情報をアプリ側と繋いで確認でき、繋がった情報を使ってセグメント配信が実現できています。なので1本あたりの配信に対するブロックされる割合も少なくお客様にも受け入れられているのかと感じています。あと2個目はLINEプロバイダーの仕組みを使うことで、公式アカウントは同じIDが使えます。東急ストアやエトモという百貨店の中で同じUUIDが使えるので、直近のキャンペーンですと両方のアカウントと友だちになってくれた方向けにキャンペーンの配信もできます。
gaoryu
石井さんありがとうございます！では次は再度技術的な情報に飢えてるかと思うので、技術的なアプローチに入ります。先に井上様から技術部分な部分についてご説明お願いします。
井上様
東急のサービスですと社内の中で繋がっているシステムがたくさんあるんですが、その中には検証環境があったりなかったりテストデータしかないなど、実はサービスによっては本番環境しかテスト場所が無いという問題がありました。検証環境があれば、そちらで試験もできるんですが本番環境しかないサービスですとぶっつけ本番になってしまうのでこちらどうしたものかと思っていました。そこでクラスメソッドさんからフィーチャーフラグの使用をご提案いただきました。
ヒョンジェ
まずフィーチャーフラグの説明なんですが、これは機能の公開をデプロイから切り離してON/OFFできるようなものになります。 フィーチャーフラグはONの場合は、機能が公開されます。この仕組みがなぜ嬉しいかというと公開範囲を限定できることにもあります。フラグを調整することで全体にリリースする前に先にQAチームだけに機能を使えるようにするなど細かい範囲に限定して機能公開が可能であり、OFFにするだけで切り戻しも簡単にできるので便利です。
今回は、フィーチャーフラグを実装する方法としてApp Config/CloudWatch Evidently/DynamoDBの選択肢がありました。CloudWatch Evidentlyはフロントから叩くものなので、バックエンド側でも使用したかったので今回は見送りとなりました。最終的にはDynamoDBを使いました。理由としてはコスト面でDynamoDBが1リクエストあたりの料金が安かったのと、速度面からレイテンシーがAppConfigだと1000msほどレスポンスにかかるところ、DynamoDBは数10msのレスポンスだったためです。
またローカルでのテストでもAppConfigの場合はLocalStack Proが必要になるため、DynamoDBの方が取り回しが良くて選定しました。フィーチャーフラグは公開後に問題なければ、フィーチャーフラグ自体を削除するリリースも行うようにし、必要なくなったタイミングで削除してコードを綺麗な状態に保つことも重要だと思います。
特に良かったのはやはり、メンバー限定で機能を公開できることで、外部システムとの連携のテストを特定のユーザだけに限定して使うことができ助かりました。 以前まではテストのためにもう一つの本番環境やもう一つのLINEチャンネルを作るなど、テストの際の手間もあったのですがそこも削減することができました。
gaoryu
特にこのフィーチャーフラグの話はインパクトあったと思いますが、お客様側としてお二人どうでしたか。
井上様
予想以上という感じでした。この仕組み自体は昨年の暮れぐらいにできたのですが現在進行中の案件の中でもさらに使っていく予定です。他にも検証環境がないなど似たような状態になっている外部システムがあるので、今後もかなり重宝していく機能かと思います。
gaoryu
ありがとうございます。石井さんはいかがですか？
石井様
LINEのUUIDでフィーチャーフラグを管理しているので、公開したい機能をユーザ単位で選べるんですよね。2人でフィーチャーフラグを実際に確認したらうまく機能制限などが実現できており感動しました！（細かい機能ではあるので）社内の他の方には、なんのこっちゃとなかなか伝わらない感じでしたが（笑) ただ今後の取り回しも考えるとかなり有用な機能だったかと思います。
gaoryu
今のように井上さん、石井さんの関係性がよいですね。お客様側の技術の理解度が高く、助けられていた気がしますが安東さんいかがでしたでしょうか。
あんでぃ
さっきもでたんですが、最初はPowerShell使ったりなど何でも使ってどうにかするという状況でした。色々最初お客様側でMVPを作って見せてもらったり、CM側でも管理画面を作っていくなど協力しながら取り組んでいたので石井さんと井上さんのテックな部分にだいぶ助けていただいたかなと思います。
gaoryu
時間もぼちぼちなので、最後の質問になります。井上さんから今後の展望などお聞きして良いでしょうか？
井上様
クラスメソッドさんとも今後の仕事も進んでます。ポイントカードのアプリ化により機能的にはレジでかかる時間が3秒削減できたのは現場的にもお客様的にもメリットがあったので、今後こちらの提供先やサービスの拡張を進めていこうかと思っています。それ以外にもLINEのプラットフォームは全体で9000万人以上のアクセスがあるので、今後このユーザ規模を活用したいですね。また気軽にアプリを作れたりAPIが豊富なのもありますね。昨今だとクラスメソッドさんが最近たくさんブログを書いているChatGPTなどもLINEと積極的に活用し、東急全体の活動として伝播させれればと思っています。
gaoryu
未来が見える内容でクラスメソッドを今後ともよろしくお願いしますというところでした、改めまして登壇者の皆さんありがとうございました！
編集後記
「事例で学ぶ!! 東急様のLINE施策と技術課題へのアプローチ」のレポートでした。本格的なレポート記事は初めてでしたが、現場の雰囲気も感じていただけたら嬉しいです！
技術者としては、フィーチャーフラグをアプリユーザのUUIDと組み合わせるのはかなり面白い取り組みだと思ったのでぜひ参考にしたいと思ったので、事例と合わせて見ていただけると幸いです。
18
