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

「AI NativeなFlutter開発の現在地〜業務導入の壁と、デザイン・テストへの応用〜」にてTanakaさんが登壇した資料です。
https://upsider.connpass.com/event/387477/

Transcript

1. 品質を保ちながら、 プロダクトの核に迫るための取り組み Yoshihiro Tanaka
2. Yoshihiro Tanaka • UPSIDER, Inc. • Mobile Group / Engineering Manager • 3 年くらい
6. Agenda 1. Mobile Group の置かれている状況 2. どこに AI を使っているか 3. AI 前の Flutter 開発 / AI 後の世界 4. AI 前の分析 / AI 後の世界 5. AI 前の CI/CD / AI 後の世界 6. まとめ
7. Mobile Group の置かれている状況
8. • Mobile といいつつ、複数の app に加え backend, infra の開発、分析など多岐に渡る ◦ UPSIDER ◦ PRESIDENT CARD ◦ 今後は White label apps も展開 • Mobile を中⼼とした⼀貫した体験を設計‧展開する group という前提がある
9. どこに AI を使っているか
10. デザイン 企画 開発 分析 QA
11. • 任せていいものと任せきってはいけないものを切り分ける • 意図とのズレを再現させない・検出する仕組み作りに重点を置く 共通する考え⽅
12. AI 前の Flutter 開発 / AI 後の世界
13. • Before ◦ Generator で API クライアントを生成するも、 enum など生成結果が Dart から使いづらく、 アプリ側で再定義が必要だった • After ◦ OAS から必要な型と通信コードを推測し、 skill として定義して生成する流れに変更 ◦ Small start で小さい API 群から段階移行、skill も都度調整 ◦ 再定義作業から解放、人が読みやすい形で出力できる ◦ OAS が不十分だとクラス名などに影響が出るため、設計に時間をかける必要がある OpenAPI Generator
14. • 例えば、secrets / API key の埋め込み、log への機微情報、deep link / URL scheme の取り扱 い、権限境界など • How ◦ Claude Code で security 観点の observation を走らせる ◦ 見つけたものは修正させずにまず task 化 ▪ 観点 / 該当箇所 / 想定リスクを残す ◦ 人が優先度・修正方針を判断したうえで対応 ▪ PR などで都度行うと diff が混在し正常な判断ができない可能性がある • AI で気づき、人が判断する Security risk
15. AI 前の backend,infra 開発 / AI 後の世界
16. • Before ◦ Backend ▪ Team の知見が溜まっており、各々が実装とレビューを回せていた ◦ Infrastructure ▪ 前提知識・運用知見が必要で、 infra team に実装自体を任せることも多かった • After ◦ Backend ▪ Team がレビューできるところまで育っているので、 AI に多くを任せられる ◦ Infrastructure ▪ AI と実装することで自 team で実装を完結できる。 専門家のレビューが引き続き最重要
17. • AI は 100 の prompt には 100 以上で返すが、1 の prompt には 100 は返してくれない • 知見が浅い領域を AI で完結させるのは危険。team の状況を冷静に見極める
18. AI 前の QA / AI 後の世界
19. • Before ◦ QA のテストケース設計は実装者が実施し、レビューを実施していた ◦ 目が滑りやすく、足りていない部分に実施中に気づくこともしばしばあった • After ◦ Ticket, PR などを参照しながら markdown 形式でテストケースを起こす skill を作成 ◦ 人はそれを見てレビューを実施し、仕様とのずれを判断する ◦ マージすると workflow は Qase にそれらを sync し、人が実施可能な状態にする
20. AI 前の分析 / AI 後の世界
21. • Before ◦ 分析は BigQuery、クエリは人間が手動で記述 ◦ クエリ最適化が不十分で、不要なデータ取得によりコストが増大 ◦ 負荷が高いため、分析が後回しになりがち • After ◦ Rule に基づき AI がクエリを自動生成する形式へ移行 ◦ 特にクエリ最適化に効果を発揮（コストとパフォーマンスの両面） ◦ エンジニアが「数字を見ながら次に何を作るかを決める」側に注力できるように
22. AI 前の CI/CD / AI 後の世界
23. • Before ◦ Workflow は手動作成 + 人のレビュー • After ◦ Workflow の記述は AI に任せる + AI レビュー + 人のレビュー ◦ ただし、Workflow 特有のセキュリティ上の問題点は Before/After ともに) 多い ▪ privileged token の流出経路 ▪ untrusted input（issue / PR タイトルなど）の不適切な使用 ▪ third-party action のバージョン固定なし ◦ zizmor で静的解析を実施し、危険なパターンを検出。 Workflow
24. • 背景 ◦ リリース前に全変更内容を報告・sync する運用 ◦ 「なぜ・何をして・どんな risk があるか」を必ず説明する必要がある • Before ◦ 変更内容をリリース前に洗い出し、メンバー全員で記述 + レビューしていた ◦ リリース前は開発や QA 準備もあるのでとにかく大変 • After ◦ Why は人間が書く。ただし Action 側で Why が足りているかをチェックさせる ◦ What / Risk は AI がコードから推測 → 人がチェックしてマージ ◦ リリース前に PR の description から辿って書き起こす Claude Code Action
25. まとめ
26. • クエリや risk 検知、分析など、AI に任せられる業務は多い • 全体と今後を見据えて何をなぜ実施するのかといった判断は引き続き人に残る • 得意、不得意な領域がそれぞれにあり、それらを判断しながら業務を効率化する
27. エンジニアは何を作るかを決める側 に近づく
28. We Are Hiring!
29. おわり