生成AIで高い生産性を求められて、 悩み、乗り越えた話

GO TechTalk #34 データサイエンティストの生成AI活用で発表した資料です。

■ YouTube
https://www.youtube.com/watch?v=7t9fIeBU2MQ
■ connpass
https://jtx.connpass.com/event/370877/

1. GO TechTalk #34 データサイエンティストの生成AI活用 生成AIで高い生産性を求められて、 悩み、乗り越えた話 小南 果穂
2. 自己紹介 GO株式会社 AI技術開発部 AI1グループ / 小南 果穂 2019年に株式会社ナビタイムジャパンの研究開発部門に新卒入社。 道路交通情報の専門チームでカーナビ向け渋滞予測の精度向上に取り組むほか、 社内のアジャイル開発推進やテックブランディングにも関わる。 2025年2月にGO株式会社に入社し、タクシーアプリ『GO』のアルゴリズム開発に 従事。チーム内では二番目の新入りです。 旅行や移動が好きで、全国の鉄道路線のうち半分くらいは制覇しています。 @yudeco_ © GO Inc. 2
3. AIで圧倒的生産性向上！ © GO Inc. 3
4. ・・・・のはずが なぜかあまりはやくなってない！？ ということありませんか？ © GO Inc. 4
5. 生成AIを使っての開発が当たり前になった 高い生産性が求められるようになるになったが・・・・ レビューが 間に合わない 使いこなせて いない気がする 品質の担保が 難しい 取り残されて いるかも © GO Inc. 5
6. 高い生産性を求められている私の悩み 本日はこれら3つの課題についての対策をご紹介します！ 1. 2. 3. 生成されたコードの品質を担保しきれない レビューしきれない どんどん活用する人に対して差が開いてしまう © GO Inc. 6
7. 課題1 生成されたコードの品質を 担保しきれない © GO Inc. 7
8. 対策：テストを大量に拡充する 品質を担保するために人的検証を強化する選択肢もある しかし、 近年は生成AIで大量のテストを低コストに作成できるように なったため、テストによる担保のほうが効率が良いと判断 © GO Inc. 8
9. テストを大量に拡充する 方針 方針 機械的にテストカバレッジを上げるのではなく、 過去に障害があった箇所のテストケースを優先的に拡充 以下の複雑な結合テストが必要となった ▪ 複数ユースケースを横断するテスト ▪ 時間経過を考慮したテスト 複雑な結合テストを生成AIに生成してもらうには、 コンテキストが不足していた © GO Inc. 9
10. 結合テスト実装上の課題 ▪ タクシーアプリ『GO』のテストでは 入力を準備するのが難しい ▪ ▪ コンテキストが足りない 例 ▪ ユーザの乗降位置、タクシーの現在位置や時間 ▪ システムの状態（ユーザのリクエストの受信済み、ドライ バーへの配車依頼の送付済みなど） ソースコードでは不十分 ▪ どの入力が必要か・どのように入力すれば良いかの 情報が不足しており、正しく生成させることができなかった © GO Inc. 10
11. 結合テスト実装上の課題 以下を追加 ▪ ユースケース ▪ 入力を準備するための手順 ▪ ユーザの作り方 ▪ タクシーの作り方 ▪ システムの状態の変え方 ▪ 関連システム ▪ モックの作成方法 ▪ 既存のテストケース ▪ テストケースを作る際の作業 手順（右図） コンテキストが足りない タクシーの作り方の例 テストの実装フロー © GO Inc. 11
12. テストを大量に拡充する ▪ 結合テストの件数を増やせた ▪ ▪ ▪ 結果 約1ヶ月で 57件 → 180件（3.2倍） 過去に起こった影響の大きい障害ケースのシナリオを網羅できた 所感 ▪ 今まで難易度の高さから諦めていた結合テストを 入れられるようになった © GO Inc. 12
13. 課題2 レビューしきれない © GO Inc. 13
14. 対策：PRサマリー作成スキルの整備 背景 ▪ ▪ 変更内容 ▪ 具体例 ▪ レビュー観点 背景・変更 ・具体例・レビュー項目 の4章構成 ▪ SKILL.mdの他にテンプレートを作成 ▪ 各章についてサンプルを用意 文字量の制約 ▪ 背景：3~5行 ▪ 変更内容 5項目まで、各項目1行で 各セクションの記載内容 ▪ 変更内容は実装（クラス名・関数名）ではなく 仕様の観点で説明 ▪ レビュー観点は実装中に行った実装者との議論内 容を記載 複雑な変更が入る場合は図示する ▪ ロジックやステータス遷移など ▪ 図示ルールを設けて、品質が一定になるようにす る © GO Inc. 14
15. PRサマリー作成スキルの整備 図示ルール ▪ 図示には mermaid記法 を利用する ▪ 以下のルールで記述 ▪ ▪ ▪ ステップ・分岐を示す場合は flowchart（方向はLR）を基本にする 複数アクター間の時系列の相互作用を示したい場合は SequenceDiagram も使ってよい style で変更があったノード・エッジのみ色付けし、 他はデフォルトのままにする 新規分岐 追加された 判定 © GO Inc. 15
16. PRサマリー作成スキルの整備 • 結果 PRサマリがあることで全体像が分かるようになり、 レビューの時間が短くなった ◦ 重い変更だと30分かかっていたところが 10分程度で確認できるように • 今までできなかった理解の薄い機能のレビューが できるようになった • 生成AIの間違いに気が付きやすくなった © GO Inc. 16
17. 課題3 どんどん活用する人に対して 差が開いてしまう © GO Inc. 17
18. 対策：生成AI活用に関するふりかえり会を主催 目的 自分自身が生成AIに対して遅れを取っている自覚があったため、 チーム全体でふりかえり会を主催し、差が開かないようにした ふりかえり会について ▪ ツール：Confluenceのホワイトボード ▪ 頻度：週1回 30分 ▪ フレームワーク：Celebration Gridなどチャレンジを前向きに報告しやすい フレームワークを選択 ▪ アジェンダ 1. 2. 3. 4. ふりかえりのゴールの共有 取り組んだ内容の共有 フィードバック 次のアクションの決定 © GO Inc. 18
19. Celebration Gridとは 初回のふりかえり会で使用 ▪ 実験的な取り組みをポジティブに受け止められる ▪ 生成AIを利用した良い習慣を知るこができる ミス 実験 習慣 失敗 成功 成功した！ 学びもあった 失敗したが 学びがあった Management 3.0 Celebration Grid を参考に作成 © GO Inc. 19
20. 生成AI活用に関するふりかえり会を実施 ▪ ツールの悩みをすぐに相談できる ▪ ▪ ▪ ▪ 結果 社内標準の生成AIサンドボックスツール Docker Sandbox(sbx) の使い方で ハマっていたが、状況を共有することで解決に至った 複数ある分析用途のエージェントスキルについて、どのような場合に何を使うのが 良かったか教えてもらえた 他のメンバーの活用状況を共有してもらえる ▪ ▪ GrafanaのMCPはログ調査だけでなくパフォーマンス計測にも使えると知ることができた ConfluenceのMCPを活用して分析結果をまとめた事例を知ることができた 生成AIの改善タスクが半強制的に進捗確認がされる ▪ 開発に追われて後回しになっていた生成AIのコンテキスト整備（PRサマリー生成スキル）に ついて、進捗しフィードバックをもらえるようになった 私自身が遅れを取り戻せた © GO Inc. 20
21. まとめ © GO Inc. 21
22. まとめ 1. 生成されたコードの品質を担保しきれない → 大量のテストを作成 2. レビューしきれない → PRサマリー生成スキルの整備 3. どんどん活用する人と遅れを取る人で差が出てくる → ふりかえり会の主催 AIで圧倒的生産性向上を達成！！ © GO Inc. 22
23. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください © GO Inc.