「キッズリー」のエンジニアが語る、Androidアプリにおけるリリース周りの舞台裏

Androidアプリにまつわる運用の話

Reyurnible氏（以下、Reyurnible）：「Androidアプリにまつわる運用の話」ということで、connpassの登壇者IDがRから始まるIDになってます。……こんな感じで大丈夫ですかね？（笑）。

じゃあ、始めていきたいと思います。はじめに、GitHubやQiitaのアカウントはRから始まる「Reyurnible」というアカウントでやっていて、社内とかだと通称「ほっしゃん」と呼ばれてます。

今の仕事なんですが、「キッズリー」という保育園向けのサービスを担当していて、主務はプロダクトのマネージャーと、エンジニアとしてはAndroidかサーバーを担当してます。今が新卒の2年目となっています。

今日の内容なんですが、ざっくりと自プロダクトのアプリの運用事例について。そして、エンジニアがPMから見たときにこれはやっておくとうれしい、みたいな話ができればいいかなと思っています。

トップバッターということもあるので、会場について少しだけ説明させてください。

今ここにいるRMPなんですけど、5月からこちらの目黒に移転してきました。とくにうちの会社は、ライフイベントに関する事業を扱う会社となってます。主なものでいくと、スタディサプリやゼクシィ、カーセンサーなどが、うちのプロダクトになります。

あと、Quipperという、海外に対して教育の事業を提供する会社がありまして、国内だとスタディサプリをQuipperが開発しており、RMPの内製開発チームと同じフロアで仕事をしています。

というところで、次にプロダクトについてです。今担当しているのが「キッズリー」というプロダクトで、保育者と保護者のコミュニケーション支援を行うサービスとなっています。アプリに関しては保護者と保育士に提供していて、園の方はWebサイトから利用していただく、みたいなかたちになっています。

コミュニケーションサービスだけでは事業として成り立たないので、他のサービスとして登降園の管理であったり、保育者の労働環境調査を行う保育者ケアであったりとか、あとは労務支援や、印刷サービスみたいなものもやっています。

そんなキッズリーというところで、Androidのアプリとしては保護者のアプリと、登降園管理というタブレットのアプリと、あとはキッズリープリントという印刷サービスのアプリが、3つ存在しています。

基本的にうちの会社は内製開発でやっているんですが、やはりアプリ数やサービス数が多くなってくるとどうしても手が回らない部分があります。そちらに関しては外部に委託して開発をしている部分もいくらかある、というかたちになっています。

Androidアプリにおけるリリースフロー

では、さっそく本題の話に入っていこうと思います。サービスのリリース周りの話ということで、主にAndroidのアプリのリリース周りの話をしたいと思います。

大まかなリリース作業の流れとしては、リリースブランチやプルリクを作成して、リリース用のAPKを作成したあとにストアにアップロードして、Firebase Remote Configなどを使用したバージョンの通知設定をしたり、というかたちになります。

それぞれ作業の中なんですが、リリースのブランチやプルリクの作成は、バージョンコード上げたりリリースのブランチを切ったり、あとはgitのpr-releaseとか使ってプルリクエストを作ったりして、リリースノートにプルリクを書いたりしてます。このあたりは一般的なフローだと思います。

あとはgit-pr-releaseとか、一応載せておいてます。git-pr-releaseはブランチ間のサブのプルリクを列挙して、チェックボックス形式でチェックできるようにするものなんですが、導入当時はほかのiOSサーバーなどに合わせるために利用しています。ほかのサービスやリリースフローと合わせて、誰でもリリースができるようなフローにしておくというのは重要かなと思っています。

あとは、fastlaneでラップしたコマンドだけ作っておいてあげるとか、iOSのエンジニアでも親しみがあるようなコマンドにもしています。

Google Play App Signingについて

続いて、「リリース用のAPKの作成」です。パートナーもいたりするので、GithubのReleaseを作成して、そこの中にリリースビルドしたAPKファイルをアップロードするようにしています。このリリースビルドのAPKでGoogleのApp Signingを使っていて、ここは社内の事情とかもあるので後ほど言います。

GoogleのApp Signingなんですが、これが……、去年よりもうちょっと前かな？　GoogleのPlay Consoleに標準でついている鍵ファイルを管理する仕組みで、従来の鍵ファイルだと1つでアップロードと署名の両方をやっていたんですが、PlayStoreへのアップと、ストアでもう1回署名し直してユーザーが手に入れるというところで、2回に署名を分けるのがGoogle App Signingになります。

そもそも外部のパートナーさんにリリースのビルドまでしてもらうのに、アップロードのキーだけ別にできることが魅力で導入しました。あとはセキュリティ対策として署名のファイルを使ったりしているので、そこが重要でした。

Google App Signingなんですが、流れとしては先ほど言ったとおり、ストアへのアップロードと、アップロード用のキーをビルドして行うもの。アップロード後にもう1回GoogleのPlayStoreで署名し直すという作業。最後に、ユーザーには今までどおり、昔使っていた署名されたキーでアプリが配信されるというかたちになります。1度設定してしまえば開発者がリリース時に行う作業は変わらない、というものになります。

Google App Signingのメリットなんですが、もう使っている方はいいんですが、従来どおりの場合であれば署名の鍵ファイルが基本的に変えられなくて、紛失したら新しいアプリを新しいパッケージ名で公開したり。そもそもセキュリティリスクにつながったり、いろいろな問題があります。

Google App Signingの場合は、本署名の署名鍵ファイルはGoogle管理なので基本的に紛失する心配がないですし、アップロード用の署名の鍵ファイルは再発行や取り消しができます。なのでまだ導入されていない方は導入するといいかなと。

Google Play App Signingの導入と注意点

そこで導入なんですが、新しいアプリの場合は利用規約に同意するだけで自動で有効になります。既存のアプリの場合はアップロードキーと署名キーを分けるかどうかによって、自分でアップロードキーを作成する場合はキーストアからpem形式の証明書をエクスポートしておく必要があります。詳しいやり方はGoogleが書いてくれているので、そこを見ればできるというかたちになってます。

何個か注意点があって、1度有効化すると無効にできないというところと、署名情報を使用しているサービスとか……例えばFirebaseやGooglePlayServiceで署名鍵とアップロードキーが別だった場合は、2つの情報を登録してあげる必要があります。

あとは。ほかの同一署名アプリの連携をしている場合は、中でハッシュキーをチェックしている場合は、アップロードキーも同じでビルドして、その連携のチェックをしたりしなければいけません。この同一署名のところはセキュリティの本にたまに書いてあるので、そちら見ていただければと思います。

キッズリーだととくに本体アプリとプリントのアプリっていうので、ログインのアカウントマネージャーを共有していたりして、そこで鍵ファイルチェックしていたりするので、こちらで使用していたりします。

もし設定が不安だったら、既存のアプリをGoogle App Signingに追加する場合は、署名キーとアップロードキーを同じものにしておけばFirebase周りの設定はいじる必要もないですし、ビルド周りでなにかエラーが起きることもないかな、と思います。

まぁ、署名ファイルの紛失リスクだけがなくなると考えてもらえばいいのかなと思ってます。

残り、3・4はふつうの作業で、「ストアアップロード」ということで、Google Play Consoleから手でアップロードしていて、ここは会社のレギュレーションもあってAPIでのアップロードができなくて。今後改善していきたポイントの1つです。

最後は、アップロード通知用の設定で、うちだとFirebaseのRemoteConfigを使って……強制アップデートというほど効力は強くないんですが「新しいアプリのアップデートが出ました」ということを通知したりしています。

アプリのアナリティクス戦略

次にアナリティクスの話なんですが、うちのプロダクトの主なアナリティクスの方針が、基本的にはサーバー側のデータをもとに行っていて、データもDBのほうなんですが。アプリのアナリティクス戦略としては、基本サーバーにない情報を取るようにアナリティクスのイベントを設計しています。

とくにアプリ間の通信をしている部分があって……キッズリーだと保護者アプリと登降園管理タブレットでNearbyを使ったアプリ間の通信をしているところがあって、サーバー側にも情報がなかなか貯まっていかないので、不具合対応も含めてアプリ側で手厚くイベントを送ったりしています。

全体の設計は、今はこういうかたちになっています。Webサーバー側からのデータはdigdagやembulkを使ってTreasure Dataのデータベースに流していて、アプリ側からはFirebaseのアナリティクスに流したものをBigQueryに流して、それを最後全部Re:dashのほうで見るというかたちになってます。

先ほど言ったように、アプリ側のアラートは全部Re:dash側から、それぞれメールで配信するようになってます。

うちだとプロダクト数や、1つのサービスの中で同じIDを使ったもので複数のアプリがあるものがあるので、ここらへんでうまく……BigQueryも今は1つしか書いていないので、複数のものからRe:dashに連携したりしています。

Firebase Analyticsは最近見て「けっこう変わってるな」と思いました。昔に比べて見れる情報が増えていて、送っている細かいプロパティも見れるようになっているなと思いました。あとはイベント数や簡単な離脱率だけであればFirebaseでも見れて、ここらへんは利用の仕方次第でいくらでもやれるところがあるなというところです。

ただ、細かいユーザーIDや期間の検索をするならBigQueryが必要になりますが、それが簡単に連携できるところが特徴になります。FirebaseのプランをBlaze以上にしたらいろいろできるんですが、値段は従量制で安いので、小規模～中規模くらいのプロダクトだったら有料化してもぜんぜんお金はかからないかな、っていうところになります。

なぜRe:dash使うか、みたいなところです。Re:dashを一応説明しておくと、いろんなDBをソースにして、クエリ発行したりグラフのデータの可視化を行えるサービスです。サーバー側のデータを連携したいという要望があったり、うちではやっていないんですが、FirebaseでBlazeにしているとGCP上で簡単に、Image展開するだけでRe:dashを構築できます。アプリのエンジニアでも試しやすいのがいいのかな、と思っています。

以上で発表は終わります。ありがとうございました。