アクティブユーザーを増やすには何をすべき？　AWSで始める“適切な”エンゲージメントの作り方

情シス担当がいないが、ちゃんとしたい

松田和樹氏（以下、松田）：4つ目ですね。「情シス担当がいないが、ちゃんとしたい」です。

これは表面化している企業としていない企業があるのですが、専任の情シス担当がいなくてなんとなくやっている企業って、スタートアップには本当に多いんですね。すべては挙げきれないのですが、そういったよくある課題をいくつかピックアップしてご紹介させていただければと思います。

1つ目は、社内のアカウント管理をどうしたらいいかみたいなお話ですね。

スタートアップなので、どんどん新しく人を採用するし、人が抜けることもあるかもしれませんね。そして、社員の入退社が増えると「アカウント管理をどうしたらいいか？」という課題が生まれるとか。あるいは、スタートアップでいろんなサービスを使っていて、知らない部署でどんどんSaaSが活用されているとか、そういうケースがあると思います。

そういったときに、どうしたらいいのかというフローです。まず最初に、すでに利用されているサービスの中に、ID基盤になるものがないかを考えていただきたいです。

だいたいのケースは、あると思うんですよね。スタートアップなので、自前でメールサーバを立てている会社って、あんまりないと思うんです。例えばGmailとかOffice 365とか、AWSのAmazon WorkMailを使われている企業もあると思います。なので、なにかしらのアカウントの基盤になるサービスがあるはずなので、まずはそれが使えないかを確認してください。

重要なのは、入退社のタイミングとかで「アカウントを作るのは誰なんだっけ？」とか「その権限設定を誰がやるんだっけ？」みたいなものを、機能的には網羅しているけれど、実は操作する人が限られているサービスがあると思うので、そういったところも注意していただくといいかなと思います。

そういったサービスをIDプロバイダとして活用していただいて、AWS自体のアカウントもSAML認証に対応しているので、そういったWebのアカウント経由でAWSにログインすることもできますし、外部のSaaSに連携していただいてもいいですし。あと、先ほどお話があったAWSのAmazon Cognitoも、OAuthとかに対応しています。そういったものを活用していくと、すでにあるものへ統一していくことができるので、まずはこちらを考えていただくのがいいかなと思います。

とはいえ、認証の仕組みや機能で、セキュリティ要件とかを満たせない場合があると思うんですね。そういう場合は、自前で構築していく必要があるかなと思います。例えば、AWSだとDirectory Service、Microsoft Active Directoryが構築できるサービスとかがあるので、お使いいただくといいかなと思います。

要件を満たせないわかりやすいものだと、Windowsの管理になっているWindowsワークロードや、あとはAWSのサービスとの統合みたいなものが挙げられるので、そういったところに対応するために、Directory Serviceはいいかなと思います。

また、Webのほかの外部サービスについては、AWS Single Sign-Onというサービスも提供しているので、そちら経由のSAML認証で、AWSのアカウントもそうですし、外部のSaaSサービスと連携することで一元管理ができるので。

話は戻るのですが、まずはすでにあるアカウント基盤でなんとかできないかを考えていただいて、どうしても厳しければ、Active DirectoryをAWSのサービスを使って構築していただくのがいいかなと思います。

特定のPCが必要な場合

松田：2つ目は、特定のPCが必要なケースですね。

例えば、経理の計算のサービスとかで、入社しているスタートアップに在籍している経理担当が、「『〇〇』というソフトウェアしか使えないんです。」「これをインストールしないといけないんです」とか、あると思うんですよね。特定のPCが必要ということがあると思います。あるいは、大企業との契約上、個人情報を取り扱える端末が必要になってしまうケースがあると思います。

そういった場合は、まずはAWSでAmazon WorkSpacesというサービスを提供しているので、こちらが使えないかを考えてください。

なぜかというと、当たり前ですが、通常は1つのPC端末を2人で使うとかは難しいと思うんですよね。なので、仮にその経理の人が最初は1人だったとして、2人に増えたら、端末を2台用意して2台にインストールしなきゃいけない。どんどん管理するものが増えていきます。

Amazon WorkSpacesをお使いいただいたら、基本的にはアカウントをどんどん増やしていただければ、同時に利用できる数が増えます。つなぐラップトップも、WindowsでもMacでもChromebookでもいいので、フレキシブルに増やすことができて、非常に便利。かつアカウントは、先ほどお話ししたActive Directory Serviceを使えるので、人数の増大とか要件の変更に対しても柔軟に対応できる。

先ほど「個人情報の取り扱いとか、そういうケースがありますよね」とお話ししたのですが、WorkSpacesはAWSのVPC内で展開されるので、ご自身でネットワークの設定を変更することができます。

なので、インターネットに出させることもできますし、インターネットに接続させないみたいなこともできて、柔軟なセキュリティポリシーができます。このあたりは、オンプレミスのご自身のラップトップよりもかなり柔軟に制御できるので、より先進的な仕組みでセキュリティを守ることができるかなと思います。まずこちらで対応できないかを検討していただいて、どうしても厳しければ、新しいラップトップを買うとかしていただくといいのかなと思います。

社内のIT資産をクラウドに移行したい

松田：最後ですね。「社内のIT資産をクラウドに移行したい」。

スタートアップなのでお持ちでない企業も多いと思うのですが、場合によっては、自分がスタートアップに入社したときに、「もう辞めてしまったが、前任の担当者が社内にActive Directoryを置いている」とか「ファイルサーバを置いている」とか「知らない間にIT資産がある」などがあると思うんですよね。そういったものを、クラウドの力でなんとかできないか？　といったときに、どうしたらいいのかという話です。

1個1個丁寧に対応していくのは難しいのですが、例えば「AWSのサービスで代替となるサービスは何か？」を、ここで紹介したいと思います。

1つ目は、Active Directory。こちらも（話の中に）何度か登場しているのですが、AWSでAWS Directory Serviceを提供しています。こちらをご利用いただくと、フルマネージドでWindowsと100パーセント互換のものが使えるので、Windowsのワークロードでも使えます。また、VPNとかDirect Connect経由でも使えて、本物のActive Directoryと同じように使うことができるので、非常にいいかと思います。

2つ目が、ファイルサーバですね。できれば持ちたくないのですが、例えば、どうしようもない要件とかで社内に置く必要があるときは、AWSでAmazon FSx for Windowsを提供しています。

こちらもフルマネージドなファイルサーバで、ネイティブのWindowsとの互換性があります。なので、DFSという最近のWindowsファイルサーバについている機能もフルに使えるようになっているので、移行は簡単かなと思います。

3つ目が、PCです。金額にもよるのですが、ハイスペックなPCを買うと資産になります。「減価償却をどうしよう？」とかはけっこう面倒くさいと思うのですが、こちらもWorkSpacesで代替可能かなと思います。

こちらもフルマネージドなサービスなのですが、重要なのは、クラウドサービスなので使った分だけお金を払っていただく。かつ、あとからスペックを変更することができます。

なので、例えばエンジニアやマーケティング担当者が、とある要件でPCのスペックを上げたいといったときに、「もうこれを買っちゃってるから、2年待って」とかがあると思うんですよね。（それも）もうなくて、すぐにスペックを上げて、なんならその業務が終わったらスペックを戻すこともできるので、そういった使い方もできるかなと思います。また、Linuxも選択可能です。

最後が、固定電話やPBXです。これを、実はAWSで提供しているんです。Amazon Chimeというビジネスチャットやビジネスオンラインミーティングのサービスがあるのですが、その中でBusiness CallingとVoice Connectorという機能がつい先日から提供されています。

これをご利用いただくと、Chime上から電話の発着信やSMSの送受信ができるようになるという、すごいサービスなんですね。ただ、ちょっと懸念点は、+1から始まるアメリカのの電話番号のみしかサポートしていないので、なかなか日本でお使いいただくのは難しいかなと思います。「ぜひ使いたい」という要望をいただければ、AWSはお客さまの要望をベースに機能を拡充してまいりますので、こういったフィードバックをお待ちしております。

参考資料は、こんな感じになっております。

アクティブユーザ増やしたい・チャーンアウト減らしたい

塚田：では、最後の5つ目のトピックです。

最後の5つ目は、アクティブユーザを増やすとかチャーンアウトを減らすとか。さっき機械学習の話もありましたが、最近はこういうご要望がけっこう多いのかなと思っております。

このフォーマットに乗せると、こんな感じで考えていまして。

アクティブユーザを増やす……よくグロースハックと言われる分野の話かなと思いますが、例えばプッシュ通知を送るとか。あと、送りっぱなしだけではダメなわけですよね。解析をちゃんとしなきゃいけないという話があります。

「本当にしたいことは何？」というと、効率的にちゃんとエンゲージメントを高めたいわけですよね。「この人は辞めてほしくない」「もっともっと増やしたい」「リピートユーザを増やす」とか。

思考フローとしては、いかに適切なことをやるかという話。あと、ちゃんと成果を迅速に振り返って（PDCAを）回していかなければいけません。KPIをちゃんと取ってPDCAを回していきましょうという話。あと、それをよりimprovementさせて、もっと適切なことをやる。「適切」が1個のキーワードかなというのが、このトピックです。

本題に入る前に、モバイルアプリがアンインストールされる理由です。Appiterateで調べられて出ているのですが、こんな感じですね。

7個目に「うざったい通知」。7個目といっても、これが一番高いのですが。うざったい通知を送ってしまうと、人がアプリケーションから離れていきます。裏返すと、「価値がある内容を、欲している人にちゃんと届けよう」という話になりますね。いらない情報をぜんぜん不適切な人に届けてもしょうがない、それは人を遠ざけてしまうだけだという話です。

これを、今回はAmazon Pinpointというサービスで解決しましょうという話をしたいと思います。

導入方法はあとで参考資料のところにも出るのですが、今はAWS AmplifyというライブラリやAWS SDKを導入していただければ、簡単にできますという話ですね。

今日はAWS Amplifyについては、たぶん入口の横でやっているワークショップとか、あとはテクニカルトラックの4つ目のセッションでも触れられるんじゃないかなと思うのですが、最近はそういうものがよく出てきています。

Amazon Pinpointとは何か

塚田：Amazon Pinpointはどういうサービスなのかを、図でユースケースベースで示していきたいと思います。

左側がユーザさんたちで、右側がエンジニアもしくはビジネスサイドの方ですね。マーケターやディレクターの方とか、もしくはスタートアップならCEOがそのままやっているかもしれませんが、彼らがどういう人に通知を送るかですね。

まず、モバイルアプリやJavaScriptのアプリ・WebアプリにSDKやAWS Amplifyで組み込んでいただくと、そのエンドポイントで、モバイルならDeviceTokenなりなんなりがSDKを通じてPinpointに送信されます。

そうすると送信されただけで、まず標準属性として、例えば地域やアプリのバージョンとか、そういうメタデータが自動的に取られるんですね。また、カスタムユーザ属性やカスタムイベントも取ることができます。

カスタムユーザ属性とはどういうものかというと、例えば「自分の好み」とか。僕はラーメンが好きなのですが、「ラーメン」とか。そういう話を、任意のタイミングで取ることができると。その情報が取れたら、それをもとにセグメンテーションができるわけですよね。「こういう集団に、こういう情報を送りたい」という話ができるようになります。

なので、右側の図でいくと、例えばセグメントCの場合です。「ロックが好きで、直近7日間アプリを起動していない人に戻ってきてほしい」というところで、これが「誰に」ですね。「｛username｝さん」みたいに、ちゃんとその人の情報を入れた適切な内容を、どうやって送るか？　モバイルプッシュで、いつ送るか？　今すぐ送信するのか？　そういうものを、この人たちが決めることができます。

送ると、すぐに高速配信されます。この速度の調整も可能なのですが、対象のセグメントに送られます。送られたあとに、迅速にダッシュボードで成果を確認することができる。これがやりたいことですね。

適切なターゲットに、適切なメッセージを、適切な方法で届ける

塚田：もう1回これを整理すると、「適切なターゲットに適切なメッセージを、適切な方法で届けよう」というのは、こういう軸で考えるべきでしょう。「誰に」「どうやって」「いつ」「何を」。

「誰に」とは、さっきの話です。Amazon Pinpointで提供しているものとして、属性をベースにしたセグメンテーションを直感的にすることもできるし。あとユニークなものは、セグメントを別途抽出する。例えば、ビッグデータ……Amazon Athenaで複雑なクエリで抽出したデータをインポートすることができますね。あと、Lambdaファンクションを使って、動的にカスタマイズみたいなこともできます。

「どうやって」。これは、経路のお話ですね。「どういうチャネルで届けるか」です。さっきモバイル通信の話を例に出したのですが、プッシュ通知は典型的な手段ですが、到達を保証しているものでもなかったりするし、「実は、メールのほうが効果があるんじゃないか？」みたいな調査もあったりします。

適切なメール、適切なプッシュ通知……「適切な経路はなにか？」です。これを考えていただきたくて。Pinpointは、例えば標準でモバイルプッシュ・メール・SMS・VoiceCallみたいなところをチャネルとして提供しているのですが、もしくはLambdaファンクションによるカスタムチャネルを使っていただくと、メールやプッシュとか、Web APIが叩けるものであれば、なんでも届けられます。

そして、「いつ」という話ですね。ちょっと巻いていきますが、「今すぐ送るのか」「日時を指定して送るのか」「定期的に送るのか」「繰り返しにするのか」とか。あと、現地時刻とか。深夜だったら遅らせるとか、そういうことを考慮するわけですね。

あと「何を」送るかは、その人に合ったメッセージ内容です。さっきの（メッセージ内）変数がありましたが、それを考慮しましょうという話ですね。「適切」というのが、1つのキーワードです。

通知後は迅速に結果を振り返る

塚田：「通知後は迅速に結果を振り返ろう」。

ダッシュボードも兼ね備えているのですが、これに1分でその最新情報が反映されるので、送ったあとにすぐにその成果を見て、次のアクションを打つことができます。

（スライドを指して）ダッシュボードで取れるものが、こんな感じですね。

プッシュ通知を送ったあとは（何ができるかと言うと）、オープンレートとかを自分で取るのは大変だと思うのですが、そういうものがPinpointで取れたり。

メールでもそうですね。バウンスやオープンの数・レートが取れたり。

SMSでも、そのあたりを取れたりします。ここまでが、「通知後は迅速に結果を振り返ろう」という話です。

必要であれば、もっと柔軟に分析する

塚田：最後は、「必要ならもっと柔軟に分析しよう」です。

Pinpointも十分なダッシュボードを備えているのですが、それはやっぱりプリセットなんですよね。便利ですがプリセットなので、「そこにはない項目を、もっと出したい」という要望は、生まれて当然かなと思います。そういうときに提供しているものが、右に伸びているEvent Streamですね。PinpointからEvent Streamをセットすると、Amazon Kinesisにデータを流すことができます。

今日の3つ目ぐらいに松田が紹介した、S3起点のログ活用の話があったのですが、そこでこういう図が出てきましたよね。

S3を起点にしていろいろなデータを活用するわけですが、この右下のKinesis Data Firehose。松田が「迷ったらFirehoseを活用しよう」と言っていたと思います。ここにつなげられるわけですよね。

こうすると、まずはPinpointで取っておいて、S3にもログを流しておいて、できることはPinpointでやっちゃう。そのあとにもっとカスタマイズしたくなったら、Streamを通じてS3にログを収集することができるようになります。

これについても、いろいろな情報や事例が出てきています。去年の「re:Invent 2018」とかでも、ディズニーやHuluの事例が出ていたりとか、日本でもたくさん出てきたりしているので、あとで資料が公開されたら、ぜひリンクを見ていただきたいと思います。

2019 春期講習まとめ

塚田：ということで、ちょっと時間をオーバーしちゃったのですが、まとめに入らせていただきますね。今日の「2019 春期講習」の45分でお届けしたのは、こんな内容でした。この5点ですね。

最初に申し上げたのですが、我々AWSのスタートアップチームは、日々多くの技術相談を受け付けています。なので、みなさんも何か迷うことがあったら、ぜひご相談いただきたいと思います。

あと、この（Start-upゼミ）シリーズはもう公開されていますので、それを見ていただいたりとか。また、今日みたいなカンファレンスや、あと「JAWS-UG（Japan AWS Users Group）」で、実際にもっと運用してみた知見をいろんな人が持ち寄っているので、ぜひそういうところで知識を広げていただきたいと思います。困ったことがあったら、お気軽に我々へお声がけいただけるとうれしいですね。

ということで、以上ですね。ご清聴、どうもありがとうございました。

（会場拍手）