Slide 1

Slide 1 text

品質を保ちながら、 プロダクトの核に迫るための取り組み Yoshihiro Tanaka

Slide 2

Slide 2 text

Yoshihiro Tanaka ● UPSIDER, Inc. ● Mobile Group / Engineering Manager ● 3 年くらい

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

Agenda 1. Mobile Group の置かれている状況 2. どこに AI を使っているか 3. AI 前の Flutter 開発 / AI 後の世界 4. AI 前の分析 / AI 後の世界 5. AI 前の CI/CD / AI 後の世界 6. まとめ

Slide 7

Slide 7 text

Mobile Group の置かれている状況

Slide 8

Slide 8 text

● Mobile といいつつ、複数の app に加え backend, infra の開発、分析など多岐に渡る ○ UPSIDER ○ PRESIDENT CARD ○ 今後は White label apps も展開 ● Mobile を中⼼とした⼀貫した体験を設計‧展開する group という前提がある

Slide 9

Slide 9 text

どこに AI を使っているか

Slide 10

Slide 10 text

デザイン 企画 開発 分析 QA

Slide 11

Slide 11 text

● 任せていいものと任せきってはいけないものを切り分ける ● 意図とのズレを再現させない・検出する仕組み作りに重点を置く 共通する考え⽅

Slide 12

Slide 12 text

AI 前の Flutter 開発 / AI 後の世界

Slide 13

Slide 13 text

● Before ○ Generator で API クライアントを生成するも、 enum など生成結果が Dart から使いづらく、 アプリ側で再定義が必要だった ● After ○ OAS から必要な型と通信コードを推測し、 skill として定義して生成する流れに変更 ○ Small start で小さい API 群から段階移行、skill も都度調整 ○ 再定義作業から解放、人が読みやすい形で出力できる ○ OAS が不十分だとクラス名などに影響が出るため、設計に時間をかける必要がある OpenAPI Generator

Slide 14

Slide 14 text

● 例えば、secrets / API key の埋め込み、log への機微情報、deep link / URL scheme の取り扱 い、権限境界など ● How ○ Claude Code で security 観点の observation を走らせる ○ 見つけたものは修正させずにまず task 化 ■ 観点 / 該当箇所 / 想定リスクを残す ○ 人が優先度・修正方針を判断したうえで対応 ■ PR などで都度行うと diff が混在し正常な判断ができない可能性がある ● AI で気づき、人が判断する Security risk

Slide 15

Slide 15 text

AI 前の backend,infra 開発 / AI 後の世界

Slide 16

Slide 16 text

● Before ○ Backend ■ Team の知見が溜まっており、各々が実装とレビューを回せていた ○ Infrastructure ■ 前提知識・運用知見が必要で、 infra team に実装自体を任せることも多かった ● After ○ Backend ■ Team がレビューできるところまで育っているので、 AI に多くを任せられる ○ Infrastructure ■ AI と実装することで自 team で実装を完結できる。 専門家のレビューが引き続き最重要

Slide 17

Slide 17 text

● AI は 100 の prompt には 100 以上で返すが、1 の prompt には 100 は返してくれない ● 知見が浅い領域を AI で完結させるのは危険。team の状況を冷静に見極める

Slide 18

Slide 18 text

AI 前の QA / AI 後の世界

Slide 19

Slide 19 text

● Before ○ QA のテストケース設計は実装者が実施し、レビューを実施していた ○ 目が滑りやすく、足りていない部分に実施中に気づくこともしばしばあった ● After ○ Ticket, PR などを参照しながら markdown 形式でテストケースを起こす skill を作成 ○ 人はそれを見てレビューを実施し、仕様とのずれを判断する ○ マージすると workflow は Qase にそれらを sync し、人が実施可能な状態にする

Slide 20

Slide 20 text

AI 前の分析 / AI 後の世界

Slide 21

Slide 21 text

● Before ○ 分析は BigQuery、クエリは人間が手動で記述 ○ クエリ最適化が不十分で、不要なデータ取得によりコストが増大 ○ 負荷が高いため、分析が後回しになりがち ● After ○ Rule に基づき AI がクエリを自動生成する形式へ移行 ○ 特にクエリ最適化に効果を発揮(コストとパフォーマンスの両面) ○ エンジニアが「数字を見ながら次に何を作るかを決める」側に注力できるように

Slide 22

Slide 22 text

AI 前の CI/CD / AI 後の世界

Slide 23

Slide 23 text

● Before ○ Workflow は手動作成 + 人のレビュー ● After ○ Workflow の記述は AI に任せる + AI レビュー + 人のレビュー ○ ただし、Workflow 特有のセキュリティ上の問題点は Before/After ともに) 多い ■ privileged token の流出経路 ■ untrusted input(issue / PR タイトルなど)の不適切な使用 ■ third-party action のバージョン固定なし ○ zizmor で静的解析を実施し、危険なパターンを検出。 Workflow

Slide 24

Slide 24 text

● 背景 ○ リリース前に全変更内容を報告・sync する運用 ○ 「なぜ・何をして・どんな risk があるか」を必ず説明する必要がある ● Before ○ 変更内容をリリース前に洗い出し、メンバー全員で記述 + レビューしていた ○ リリース前は開発や QA 準備もあるのでとにかく大変 ● After ○ Why は人間が書く。ただし Action 側で Why が足りているかをチェックさせる ○ What / Risk は AI がコードから推測 → 人がチェックしてマージ ○ リリース前に PR の description から辿って書き起こす Claude Code Action

Slide 25

Slide 25 text

まとめ

Slide 26

Slide 26 text

● クエリや risk 検知、分析など、AI に任せられる業務は多い ● 全体と今後を見据えて何をなぜ実施するのかといった判断は引き続き人に残る ● 得意、不得意な領域がそれぞれにあり、それらを判断しながら業務を効率化する

Slide 27

Slide 27 text

エンジニアは何を作るかを決める側 に近づく

Slide 28

Slide 28 text

We Are Hiring!

Slide 29

Slide 29 text

おわり