はじめに
こんにちは、食べログシステム本部 アプリ開発部でAndroidアプリエンジニアをやっているhokutonikukyuです！
柴犬が大好きです🐕
入社から食べログを担当し、ちょうど丸２年経ちました。
普段は口コミ周りの開発を担当しています！
去年も参加したのですが、今年はTabelog Tech BlogにレポートとしてDay1~3まで連載することになりました！ 本記事はDroidKaigi2023のDay2のレポートです。
Day1の和田さんのレポートは以下から、こちらもぜひご覧下さい！
各社のブースも大盛況でした！ブースでスタンプを集めてノベルティーを貰えたり、両日共にコーヒーやお菓子、さらにお昼は今半のお弁当が配布されたりと今年は去年以上にパワーアップしたイベントになっていました💪
そして会場の各スペースが直近のAndroidStudioバージョンを表している生き物の名前になっており、入り口にはイラスト付きの案内が展示されていたりしました！（かわいい🤗）
目次
セッションについて
共有
Googleの荒木佑一さんによるセッションです。
タイトルの通り、共有関連についての内容でした！
まずはそもそもどのようなデータが共有可能なのかから始まりました。
AndroidではIntentがAPIレベル1から現在まで、ほぼ変わらず使用できます。
現在はShareCompatを使用して実装するのが良いらしく、そちらを使用してテキストや画像の送る側と受け取り側でのコードの書き方の紹介をしてくださいました。
続いては共有シート上で、対象のユーザーを指定する直接共有についての話でした。 対象のユーザーはショートカットで管理されており、どんなユーザーを表示するかをアプリ側から制御可能となっています。 ショートカットの作成タイミングは、チャットをするようなアプリの場合、メッセージの受け取りや表示時に行なうのが理想的であるというアドバイスもありました。
ショートカットの作成にはShortcutManagerCompat内のpushDynamicShortcutを使うと、更新時なども裏で上手く処理してくれるのでオススメという有力なお話も聞けました！
直接共有は、ソーシャル機能があるアプリでは積極的に導入してほしいとのことです。
そして最後は共有シート関連についての話です。 共有シートをカスタムで作ってるサービスが多いが、出来れば使わないで欲しいというお願いから始まり、周りから笑いが起きていました😆 カスタムするより管理も楽なので、個人的にとても共感出来ます（笑）
Googleの標準共有シートで出来ることをいくつか紹介してくれました。
- 初期Intentを指定することで、共有候補アプリの優先度を変更する
- 共有候補から自アプリを表示しないよう除外する
- 共有先が選択された際に検知して、計測などを行なう
- APIレベル34（Android14）からはカスタムアクションが追加可能に
標準共有シートでも多岐に渡るパターンで実装できるので使ってほしいということ、何か要望やフィードバックがあればぜひGoogleまでという話で締められました！
食べログでもカスタムした共有シートを使っている箇所はいくつか存在するため、今後このお話を元に標準共有シートを使っていく流れを作りたいと思いました。
様々なユースケースに利用できる "パスキー" の導入事例の紹介とUXの課題解説
ritouさんによるセッションです。
パスキーによる認証関連のお話で、既存の認証の問題点から説明がありました。
以下、個人的に気になった箇所を要約して書かせていただきます。
ユーザーが自分で設定しているパスワードでの認証は、他の複数サービスで使いまわされている可能性が非常に高く、もし流出してしまった際に他のサービスへの二次被害に繋がることもあります。
プラットフォームごとに用意されているパスワードマネジャーなどを使用することでそれを防ぐ手段は現時点でも存在しているが、サービス側からパスワードマネージャーの使用を強制できないとのことでした。 上記の問題などをパスキーを導入することで解決できるようです。
パスキーがどのようなものか自分は理解できていなかったのですが、スマホやPCの指紋や顔を使っての認証でログインを可能にすることでパスワードを登録する必要がなく、生体認証は自分のみが使用できるもので信頼性が高いというものです。 AppleIDやGoogleアカウント等で使用可能で、同じアカウントを紐づけた端末であれば、すぐに認証が使えるようになります。
最近ではクロスプラットフォームを実現するために、外部パスワードマネジャーである1Password等も注目されているそうです。
アカウント連携系はセキュリティーの観点から使いたがらないユーザーもいますが、パスキーはパスワードやアカウントを使うわけではなく安全性も高いので、これからの認証として個人でも情報を追っていきたいと思います！
突撃！隣のコードレビュー
DMMのSato Taichiさん、Okumuraさんによるセッションです。
エンジニアお馴染みのコードレビューに関する発表です。
DMMのいくつかのチームでのレビュー事例や個人単位の取り組みが紹介されました。 それぞれザッと気になった部分のみまとめてみました。
チームとしての取り組み
- DMMポイントクラブ
- 実装前に必ず設計レビュー
- 1回30分*2のレビュータイムを業務時間で設けている（1回目は口頭のみで実施）
結果的にレビューへのハードルは下がったが、PRが溜まることが多くなった。
- DMM TV
- 1PRは500行までに抑える
- PRに修正内容や影響範囲を記載
特定分野の修正で、レビュアー知識に偏りがあることが多い。 PRのスコープ範囲を狭めて、背景知識や経緯を記載することで解決したい。
- DMMブックス
- 1PRは200行までに抑える
- レビュアーはチーム全員、最低2人から承認をもらったらマージ
- 設計レビューを行なうことで実装レビュー時の認識ズレによる問題を減らす
少人数だから回っているが、人数が増えたら回るのか未知数。 動作確認が手動で、そちらにも工数がかかりがち。 シナリオテストを作成、品質を安定させる。
個人としての取り組み
レビュアーとしての工夫
- 認識を合わせる
- ちょっとした疑問でも聞く
- PR上でのやり取りが3往復以上になりそうな場合は対面レビューやモブプロを実施する
- コメントした背景や理由を具体的に記載する
- PRを記録やナレッジとして活用する
- 口頭で確認したこともPRにコメントを残す
- 修正コミットを入れるだけでなく、返信・Resolveされているか確認
- コメントを読んだ人が今後レビューされるときに役立つように詳細を書く
- スムーズなレビュー
- 自分のタスクよりコードレビューを優先する
- なるべくすぐ見る
- 指摘の優先度がわかりやすいように分類をつけている（MUSTやIMO、NITS(細かい指摘)）
- 心地よいコミュニケーション
- ゆるい感じの文体でコメントする
- 自分の好みを押し付けない
- 修正箇所以外にも、良い点もコメントする
- その他
- レビュアーが他の人にも説明できるくらい責任をもつ
- する側も自己学習の一環として捉える
レビューイとしての工夫
- 差分を小さくする
- テストは別で、など分けることで負担を減らす
- コミットを分けて見やすくする
- 読みやすいPRにする
- 意味のあるまとまりで依頼する
- PRにコメントで補足する
- 必要な情報を揃える
- 仕様や設計書のリンク添付
- 動作確認の動画を添付している
- その他
- コミットのリンクをつける
上記がDMMで実施されているコードレビューの取り組みでした。
アプリ開発部では、基本は固定のレビュアーが1人＋必要に応じて該当分野に詳しい、または担当しているエンジニアにも見てもらう形を取っています。
そして、内容によってはレビュー前に前提・経緯のインプット時間を設けたり、対応の規模によっては設計レビューやPRを複数に分けるようにしています。
現状はこの形式で滞りなく回っていると思いますが、レビュアーによる分野の理解度・正確性については課題感として上がっているため、隔週でコードレビュー・勉強会を実施して全体のレベルアップを目指したりもしています。
今回のこちらのセッションの内容を踏まえ、さらに良いレビュー形態を模索していきたいと思います！
Material 3 やめました
最後はYuki Anzaiさんによるセッションです。
昨年のDroidKaigi2022で、Material Design 3（以下、M3）に対応したという下記セッションをされてから１年で一体何が。
Jetpack Compose で Material Design 3
冒頭の挨拶から、タイトルをご自身でネタにし、「M3やめたいかー？！」「おー！」という謎の掛け声でアイスブレイクを挟みつつ始まりました！（笑）
M3では、色の管理がとても複雑になることやダイナミックカラーとのバッティング、ダークモード対応の中途半端さ、何よりカラーロールが多すぎるのが決め手となりやめることに。
M3のcomponentToken以外はそのまま使って独自のデザインシステムを作成することになったそう。
上記の影響でM3のコンポーネントが使えなくなったため、引数などはほぼ変えずにカラー反映部分を独自デザインシステムに対応したものをラップしたとのこと。
まとめとして、サービスのブランドカラーが決まっているとそもそもM3を導入するのは難しいということ、もし導入するのであればデザイナーさんと協力して独自デザインシステムを作成するという話で締められました。
個人的には、既にイメージが固まってるような既存のサービスをM3に置き換えるには適していないという印象です。 シンプルでカスタムレイアウトを使うことのないようなアプリには刺さるものだと思っています。
現時点では食べログで導入コスト以上のメリットを見出せないため、MaterialUI関連については引き続き課題となりそうです。 （そもそもカスタムレイアウトを減らすところから始めていきたい、、、）
今後食べログで取り組みたいこと
JetpackComposeはセッション数もそうですが、実際に導入しているサービス・企業も徐々に増えてきているなあという印象が強かったです。
食べログアプリではまだ導入までは至っていませんが、ちゃんと検討は進んでおり、今後画面単位での簡単な置き換えができそうな箇所から順次対応を進めていくような形になっていくかと思います。
個人・チーム内でもしっかりキャッチアップを行なっていきたいです。
まとめ
今年も素晴らしいセッションの数々、そしてブースで各社のエンジニアさんと交流できたりと、とても実りのあるイベントでした！✋
Androidエンジニア同士の交流の場や現在のトレンドや最新情報を知ったり、自身のエンジニアとしてのモチベーションを上げる一環としても、とても良いイベントです！
来年もぜひ参加したいです🐕
採用情報ページ
食べログは長寿サービスではありますが、まだまだやりたいことや実現したいことがたくさんある魅力的なプロジェクトです。
Androidエンジニアも募集していますので、興味を持っていただいた方はぜひ下記リンクよりご応募お待ちしております！
