
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
Androidアプリにまつわる運用の話(全1記事)
リンクをコピー
記事をブックマーク
Reyurnible氏(以下、Reyurnible):「Androidアプリにまつわる運用の話」ということで、connpassの登壇者IDがRから始まるIDになってます。……こんな感じで大丈夫ですかね?(笑)。
じゃあ、始めていきたいと思います。はじめに、GitHubやQiitaのアカウントはRから始まる「Reyurnible」というアカウントでやっていて、社内とかだと通称「ほっしゃん」と呼ばれてます。
今の仕事なんですが、「キッズリー」という保育園向けのサービスを担当していて、主務はプロダクトのマネージャーと、エンジニアとしてはAndroidかサーバーを担当してます。今が新卒の2年目となっています。
今日の内容なんですが、ざっくりと自プロダクトのアプリの運用事例について。そして、エンジニアがPMから見たときにこれはやっておくとうれしい、みたいな話ができればいいかなと思っています。
トップバッターということもあるので、会場について少しだけ説明させてください。
今ここにいるRMPなんですけど、5月からこちらの目黒に移転してきました。とくにうちの会社は、ライフイベントに関する事業を扱う会社となってます。主なものでいくと、スタディサプリやゼクシィ、カーセンサーなどが、うちのプロダクトになります。
あと、Quipperという、海外に対して教育の事業を提供する会社がありまして、国内だとスタディサプリをQuipperが開発しており、RMPの内製開発チームと同じフロアで仕事をしています。
というところで、次にプロダクトについてです。今担当しているのが「キッズリー」というプロダクトで、保育者と保護者のコミュニケーション支援を行うサービスとなっています。アプリに関しては保護者と保育士に提供していて、園の方はWebサイトから利用していただく、みたいなかたちになっています。
コミュニケーションサービスだけでは事業として成り立たないので、他のサービスとして登降園の管理であったり、保育者の労働環境調査を行う保育者ケアであったりとか、あとは労務支援や、印刷サービスみたいなものもやっています。
そんなキッズリーというところで、Androidのアプリとしては保護者のアプリと、登降園管理というタブレットのアプリと、あとはキッズリープリントという印刷サービスのアプリが、3つ存在しています。
基本的にうちの会社は内製開発でやっているんですが、やはりアプリ数やサービス数が多くなってくるとどうしても手が回らない部分があります。そちらに関しては外部に委託して開発をしている部分もいくらかある、というかたちになっています。
では、さっそく本題の話に入っていこうと思います。サービスのリリース周りの話ということで、主にAndroidのアプリのリリース周りの話をしたいと思います。
大まかなリリース作業の流れとしては、リリースブランチやプルリクを作成して、リリース用のAPKを作成したあとにストアにアップロードして、Firebase Remote Configなどを使用したバージョンの通知設定をしたり、というかたちになります。
それぞれ作業の中なんですが、リリースのブランチやプルリクの作成は、バージョンコード上げたりリリースのブランチを切ったり、あとはgitのpr-releaseとか使ってプルリクエストを作ったりして、リリースノートにプルリクを書いたりしてます。このあたりは一般的なフローだと思います。
あとはgit-pr-releaseとか、一応載せておいてます。git-pr-releaseはブランチ間のサブのプルリクを列挙して、チェックボックス形式でチェックできるようにするものなんですが、導入当時はほかのiOSサーバーなどに合わせるために利用しています。ほかのサービスやリリースフローと合わせて、誰でもリリースができるようなフローにしておくというのは重要かなと思っています。
あとは、fastlaneでラップしたコマンドだけ作っておいてあげるとか、iOSのエンジニアでも親しみがあるようなコマンドにもしています。
続いて、「リリース用の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管理なので基本的に紛失する心配がないですし、アップロード用の署名の鍵ファイルは再発行や取り消しができます。なのでまだ導入されていない方は導入するといいかなと。
そこで導入なんですが、新しいアプリの場合は利用規約に同意するだけで自動で有効になります。既存のアプリの場合はアップロードキーと署名キーを分けるかどうかによって、自分でアップロードキーを作成する場合はキーストアから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を構築できます。アプリのエンジニアでも試しやすいのがいいのかな、と思っています。
以上で発表は終わります。ありがとうございました。
関連タグ:
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
2025.02.05
エンジニアとして成功するための秘訣とは? ひろゆき氏が語る、自由な働き方を叶えるアプリ開発とキャリア戦略
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
PR | 2025.02.04
能登半島地震で自宅は全壊、「これでどうやってDXするねん」 被災したサイボウズ社員と支援者らが語る災害支援のノウハウ
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10
片付けパパ対談【特別編】 整理術×行動術×メモ術で、仕事も人生も自在にデザイン!
2024.12.16 - 2024.12.16