Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.

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

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

More Decks by UPSIDER, Inc. Tech&Product div.

Transcript

  1. Agenda 1. Mobile Group の置かれている状況 2. どこに AI を使っているか 3.

    AI 前の Flutter 開発 / AI 後の世界 4. AI 前の分析 / AI 後の世界 5. AI 前の CI/CD / AI 後の世界 6. まとめ
  2. • Mobile といいつつ、複数の app に加え backend, infra の開発、分析など多岐に渡る ◦ UPSIDER

    ◦ PRESIDENT CARD ◦ 今後は White label apps も展開 • Mobile を中⼼とした⼀貫した体験を設計‧展開する group という前提がある
  3. • Before ◦ Generator で API クライアントを生成するも、 enum など生成結果が Dart

    から使いづらく、 アプリ側で再定義が必要だった • After ◦ OAS から必要な型と通信コードを推測し、 skill として定義して生成する流れに変更 ◦ Small start で小さい API 群から段階移行、skill も都度調整 ◦ 再定義作業から解放、人が読みやすい形で出力できる ◦ OAS が不十分だとクラス名などに影響が出るため、設計に時間をかける必要がある OpenAPI Generator
  4. • 例えば、secrets / API key の埋め込み、log への機微情報、deep link / URL

    scheme の取り扱 い、権限境界など • How ◦ Claude Code で security 観点の observation を走らせる ◦ 見つけたものは修正させずにまず task 化 ▪ 観点 / 該当箇所 / 想定リスクを残す ◦ 人が優先度・修正方針を判断したうえで対応 ▪ PR などで都度行うと diff が混在し正常な判断ができない可能性がある • AI で気づき、人が判断する Security risk
  5. • Before ◦ Backend ▪ Team の知見が溜まっており、各々が実装とレビューを回せていた ◦ Infrastructure ▪

    前提知識・運用知見が必要で、 infra team に実装自体を任せることも多かった • After ◦ Backend ▪ Team がレビューできるところまで育っているので、 AI に多くを任せられる ◦ Infrastructure ▪ AI と実装することで自 team で実装を完結できる。 専門家のレビューが引き続き最重要
  6. • AI は 100 の prompt には 100 以上で返すが、1 の

    prompt には 100 は返してくれない • 知見が浅い領域を AI で完結させるのは危険。team の状況を冷静に見極める
  7. • Before ◦ QA のテストケース設計は実装者が実施し、レビューを実施していた ◦ 目が滑りやすく、足りていない部分に実施中に気づくこともしばしばあった • After ◦

    Ticket, PR などを参照しながら markdown 形式でテストケースを起こす skill を作成 ◦ 人はそれを見てレビューを実施し、仕様とのずれを判断する ◦ マージすると workflow は Qase にそれらを sync し、人が実施可能な状態にする
  8. • Before ◦ 分析は BigQuery、クエリは人間が手動で記述 ◦ クエリ最適化が不十分で、不要なデータ取得によりコストが増大 ◦ 負荷が高いため、分析が後回しになりがち •

    After ◦ Rule に基づき AI がクエリを自動生成する形式へ移行 ◦ 特にクエリ最適化に効果を発揮(コストとパフォーマンスの両面) ◦ エンジニアが「数字を見ながら次に何を作るかを決める」側に注力できるように
  9. • Before ◦ Workflow は手動作成 + 人のレビュー • After ◦

    Workflow の記述は AI に任せる + AI レビュー + 人のレビュー ◦ ただし、Workflow 特有のセキュリティ上の問題点は Before/After ともに) 多い ▪ privileged token の流出経路 ▪ untrusted input(issue / PR タイトルなど)の不適切な使用 ▪ third-party action のバージョン固定なし ◦ zizmor で静的解析を実施し、危険なパターンを検出。 Workflow
  10. • 背景 ◦ リリース前に全変更内容を報告・sync する運用 ◦ 「なぜ・何をして・どんな risk があるか」を必ず説明する必要がある •

    Before ◦ 変更内容をリリース前に洗い出し、メンバー全員で記述 + レビューしていた ◦ リリース前は開発や QA 準備もあるのでとにかく大変 • After ◦ Why は人間が書く。ただし Action 側で Why が足りているかをチェックさせる ◦ What / Risk は AI がコードから推測 → 人がチェックしてマージ ◦ リリース前に PR の description から辿って書き起こす Claude Code Action