Androidチームでチーム内勉強会を始めました

TL;DR

Androidチームで技術力向上とナレッジ共有を目的とした勉強会を開始した
これまでに「データ分析（BigQuery/Redash）」と「AI活用（Cursor）」の2回を開催
第1回はユーザー行動分析のためのデータ基盤の構造とクエリ作成方法を学習
第2回は各メンバーの「Cursorの推し機能・使い方」を共有
勉強会を通してチームの課題（アーキテクチャ統一など）が明確になり、解決に向けた動き（.cursor/rules導入など）が生まれた
はじめに
こんにちは。Androidチームの藤井(Yosuke Fujii)です。 Androidチームでは去年の12月から、主にチーム内でのナレッジ共有を目的に勉強会を開催しています。今回は、チームで始めたこの勉強会の取り組みと、そこで共有された内容（特に盛り上がったCursor活用術など）についてご紹介します。
勉強会を始めた動機

チーム内での開発効率化や、障害調査能力の底上げが主な動機です。これまでも各メンバーが高いパフォーマンスを発揮していましたが、特定の分野において知見が属人化している部分があったため、チーム全体でノウハウを標準化することを目指しました。現在までに以下の2つのテーマで開催しました。
ユーザー行動調査のナレッジ共有: 複雑なデータ分析や調査手法について、特定のメンバーに知見が集中しがちだったため、全員が同じレベルでBigQueryやRedashを活用できるようにする。
AIツール活用知見の共有: 各メンバーが個別にCursorを活用してはいたものの、具体的な使い方の共有までは行えていなかったため、お互いの知見を持ち寄ってチーム全体の生産性をさらに高める。
第1回：BigQueryとRedash勉強会（振り返り）

まず第1回は、ユーザーの行動ログやサーバーデータをどう調査するかをテーマに行いました。
BigQuery: Firebase Analytics等のログ用。モバイルからの送信データがメインで、ネストされたフィールドは UNNEST 関数で解除する必要があることなどを学びました。
Redash: 本番DB（リードレプリカ）への参照用。MySQL形式でクエリを投げ、具体的なレコード調査やプロジェクトごとのデータ確認に利用します。この回での大きな学びは、「データの在り処さえ分かれば、AI（Gemini等）にスキーマを伝えることでクエリは生成できる」 という点です。複雑なSQL構文を暗記するよりも、どのデータがどこにあるかを知ることが重要だという共通認識ができました。
第2回：Cursor Tips共有会
続く第2回では、「Cursor」をテーマに、各メンバーが普段どのようにAIを活用しているかを持ち寄りました。「意外とみんな似たような使い方をしているのでは？」という予想もありましたが、話してみると人によってアプローチが異なり面白い発見がありました。ここでは、チーム内で共有された具体的な活用事例をいくつか紹介します。
1. Plan Modeと対話型スタイル

メンバーによってAIへの指示の出し方が大きく分かれました。
Plan Modeを活用するスタイル: いきなりコードを書かせるのではなく、まずは Plan Mode で修正プラン（Markdown形式のToDoリスト）を出力させます。そのプランを見て人間が理解・確認してから実行に移すことで、意図しない修正を防ぎつつ、自分が理解できないコードが生成されるのを防いでいます。
対話型（Chat）で進めるスタイル: 事前にプランを作らず、チャットで会話をしながら少しずつタスクを進めるスタイルです。自分のアイデアをAIに見せてフィードバックをもらったり、理解しながら進めることで記憶に残しやすくしています。
直接指示を出すスタイル: やりたい実装のイメージが明確に頭の中にある場合、Plan Modeは使わず直接指示を出してスピーディに実装を行います。
2. スクリーンショットをプロンプトに活用
「良い指示（プロンプト）が文章で思いつかない」という悩みに対し、画面のスクリーンショットを撮り、赤枠で修正箇所を囲ってCursorに読み込ませるという方法を共有しました。これには他のメンバーからも「画面の文字まで読み取ってくれるのか」「便利そうだ」と驚きの声が上がりました。
3. デバッグログの埋め込みと削除
バグ調査やトラブル対応で特に便利だと話題になったのが「ログの埋め込み」です。「この周辺の処理フローを知りたいからログを出して」と依頼し、調査が終わったら「さっき追加したログを消して」と指示するだけで、面倒なログ出力作業が一瞬で完了します。デバッガーで追いきれない事象に対し、大量のファイルにログを仕込んで原因を特定した事例もありました。
4. 高品質なユニットテストの生成
実装をお願いしたチャットの流れで「ユニットテストもお願いします」と依頼するだけで、文脈（Context）を理解したテストコードを生成してくれます。 Mockの定義やテスト用JSONデータの準備など、人間がやると手間がかかる作業をAIが肩代わりしてくれるため、非常に効率的です。ただし、生成されたテストが正しいかは人間がチェックする必要があります。
5. Figma連携とGit操作
Figma連携: 新規画面作成時にFigma連携を試した事例では、アコーディオン等のコンポーネント連携も含めて「かなりいい感じ」に作ってくれたという報告がありました。ただ、1ファイルにまとめて出力されるため分割が必要などの課題もありました。
Git操作: diff の確認や、修正内容に基づいたコミットメッセージの提案、タグの検索などにもCursorを活用している事例が共有されました。
今後の展望：Rules機能による標準化

この共有会での議論をきっかけに、「アプリ全体の構成や新規画面の作り方を Rules（.cursor/rules）で定義できないか？」という話になりました。現状、Figma連携などで画面を作ると、独自のコンポーネント分割やパラメータの渡し方がチームのアーキテクチャと異なる場合があります。そこで、以下のようなルールを自然言語で定義することを検討しています。
ViewModelやScreenの構成ルール
関数のパラメータの渡し方（プレビュー可能性の確保など）
ディレクトリ構成これらをルール化しておくことで、AIにコード生成させる際にチームのアーキテクチャを遵守させ、レビューコストを下げることを目指しています。
おわりに

勉強会を始めてみて、メンバーそれぞれが異なるアプローチで開発していることが分かり、非常に刺激になりました。ただ知識を共有するだけでなく、こうした勉強会で得た知見を実際の開発プロセス（今回はRulesの導入など）にフィードバックし、チーム全体の生産性を高めていきたいと思います。今後も月1回程度の頻度で、持ち寄り形式の勉強会を継続していく予定です。