© LY Corporation © LY Corporation AIエージェントで変わる 開発プロセス レビューボトルネックからの脱却 

© LY Corporation Internal Use Only 曾⽥ 知也 / Soda Tomoya ローカルメディア開発本部開発1部開発1チーム 2 業務内容 - スクラムマスター - 新マップアプリのBE開発 © LY Corporation 

© LY Corporation こんな経験ありませんか？ 

© LY Corporation チームメンバーがうっすら感じていた課題 

© LY Corporation © LY Corporation ウェビナーやハンズオンで学んだ知識は知っている AIエージェントで実装〜PR作成まで可能なSkillを作ることができる でも... チーム内に提案するタイミングがない 個⼈で導⼊すると、アウトプットに偏りが出る Vibe Codingの是⾮もチームで決めるべき話 結果として、ナレッジが「⾃分だけの知識」として眠ってしまう ソリューションは個⼈の中で眠っていた AIエージェントでPRレビューもできるSkillを作ることができる Vibe CodingでAIに実装を⼀任できる 

© LY Corporation © LY Corporation 「表⽴ってVibe Codingをしてもよいのか？」 うやむやにせず、チームで正⾯から議論することにした 転機① ―レトロスペクティブ(KPT)で議論をはじめた 「チーム内でのVibe Codingの定義を決めたい」 Vibe Codingに関する議論を交わした レトロスペクティブは、スクラムという開発の進め方にあるイベントの一つです。 チームで仕事の進め方を振り返り、次はもっと良くする工夫を決める時間です。 「コーディングルールを守らせたうえでPRを作成するSkillを作ることができそう」 

© LY Corporation © LY Corporation Vibe Codingの定義のうち「コードの詳細に気を配らない」は避けるべきだが… 開発速度を優先するために、特定の条件に合えばOKにした 社内利⽤に限定した機能 読み取りのみの処理 リスクが低い機能 リファインメントでVibe Coding OKの対象チケットを⾒定める 作業チケットに「Vibe Coding OK」の⽬印をつける デザインもAIに⼀任（デザイナー・POから合意済み） 合意① ― Vibe Codingの適⽤範囲を決める Vibe Coding⽤のSkillを設計する作業チケットを作り、準備時間を確保する 

新たな問題 ― 今度はレビューがボトルネックになった © LY Corporation 

© LY Corporation © LY Corporation 転機② ―レトロスペクティブ(KPT)でレビューの議論をはじめた 「Vibe Codingの定義は『コードの詳細に気を配らない』はず・・・」 「レビュアーがコードの詳細に気を配るのって変じゃない？」 「特定のルールに則ったレビューをさせるSkillを作ることができそう」 Vibe Codingのレビューに関する議論を交わした 

© LY Corporation © LY Corporation レビュアーがコードの詳細に気を配るのはやめて、AIに委ねる コーディングルールや致命的なリスクがないかの観点をレビュー⽤のSKILL.mdに記載 合意② ― Vibe Codingで作られたPRレビューはAIに委ねる レビュアーは1名にして、レビュー⽤のSkillを使うことにした 

© LY Corporation © LY Corporation Vibe Coding⽤ Skill 作業チケットから要件を読み取り、実装からPR作成まで⾏うSkill 作業チケットに書く要件の粒度もチーム内で認識を合わせた Vibe Coding レビュー⽤ Skill コーディングルールや致命的なリスクがないかの観点でレビューができる 共通のSkillを使う ハンズオンで学んだ知識が、チームの課題に出会って実践に移された 個⼈の中で眠っていたナレッジが⽬を覚ました 

© LY Corporation © LY Corporation 作業チケットに書く要件の粒度の例 

© LY Corporation © LY Corporation Vibe Coding レビュー⽤ Skillの例 

© LY Corporation © LY Corporation FEで1つの画⾯を追加する⼯数の削減例 ⼯程 Before After デザイン作成 デザイナー (Figma) 1⼈⽇ AIに⼀任 PR作成 ⼈⼒ 1⼈⽇ Skill利⽤ 0.5⼈⽇ レビュー 2名(⼈⼒レビュー) 1時間 1名(Skill利⽤) 10分 合計 約2⼈⽇ 約0.5⼈⽇ Vibe Codingが許された画⾯開発に係る⼯数のBefore → After 

© LY Corporation なぜ、この取り組みはうまくいったのか？ 

© LY Corporation © LY Corporation 従来の開発スキルとの違い 従来の開発スキル AIスキル 実践の単位 個⼈の作業 チームの環境 例 コーディング、デバッ グ CLAUDE.md管理、Skill管理、Vibe Codingの 是⾮ 導⼊⽅法 個⼈で即実践できる チームの合意が必要 正解 ある まだ定義しづらい AIスキルの導⼊は「チーム」単位で進める必要のあるケースが多い ⼤規模組織であるほど導⼊が難しい 

AIスキル導⼊のためにチームメンバー全員で話し合いを⾏なった © LY Corporation 

© LY Corporation © LY Corporation SKILL.mdの内容は、ゼロから作ったわけではない 新メンバーのオンボーディング⽤に既にあったコーディング規約を移植 無限ループや想定外の操作が発⽣しないかなどの観点について、 全員で話し合った内容をルールとして⽂⾔追加した → 既存の資産を活かすことで、導⼊のハードルを下げた 導⼊のハードルを下げる⼯夫 

© LY Corporation AIをどこまで信 ⽤するかのライン決めを定期的に行う 

© LY Corporation © LY Corporation スプリントのサイクルが、AIナレッジ実践を⽀えている イベント 役割 レトロスペクティブ(KPT) 課題を表⾯化し、ソリューションの合意を得る場 リファインメント AIを信⽤するライン引きの⾒直しを⾏う場 特別な会議を設定する必要がない ― 既にある仕組みを活⽤ 考えるきっかけが定期的に訪れる スクラムイベントが対話の場を⽣む 

© LY Corporation © LY Corporation ステップ 問い KPT 1 その問題があることに同意できるか？ Problem 2 AIスキルが問題に効くと同意できるか？ Try 3 実施のハードルを越えることに同意できるか？ Try レトロ(KPT)の中でステップを踏んでチームに対して提案を⾏う チームに対しては⼀⽅的な提案ではなく、共感を起点にした対話が必要 

© LY Corporation © LY Corporation 1. AIスキルは「チーム」で導⼊する 2. 対話の場をフル活⽤する チームに対して一方的ではなく、スクラムであればレトロスペクティブを通じて課題とソ リューションを共有し、納得を得たうえで導入を推進する。 3. AIを信用するラインを定期的に見直し、レビューボトルネックを解消する 完璧を求めず、リスクの低い箇所からAIにレビューを委ねることで、開発プロセ スの停滞の原因になる「レビュー待ち」を減らす。 まとめ 個人の知識に留めず、チーム合意を得ることで、誰もが迷わずAIエージェントを使える 環境を整える。 

© LY Corporation © LY Corporation ご清聴ありがとうございました