AI駆動で進める依存ライブラリ更新 ─ Vue プロジェクトの品質向上と開発スピード改善の実践録

Vue Fes Japan 2025での登壇資料です
詳しくは以下URLから
https://vuefes.jp/2025/speaker/sayn0

Transcript

1. /78 AI駆動で進める依存ライブラリ更新 Vue プロジェクトの品質向上と開発スピード改善の実践録 Vue Fes Japan 2025 2025/10/25(Sat)
2. /78 sayn0 フロントエンドエンジニア / エン株式会社（旧エン‧ジャパン株 式会社） 新卒1期⽣として、2023年に⼊社. React（Next.js）をメインにフロントエンドの開発‧運⽤をしてきた. 今では、学⽣時代にプログラミングに興味を持つきっかけとなったVue.jsメインで 開発‧運⽤に取り組んでいる. 外部勉強会への参加が趣味.（2年間で100イベント以上参加） sayn0s @sayn0de 自己紹介 2/78
3. /78 プロジェクト開始の背景 あるサービスがVue.jsベースでライブラリ更新が数年できてなく、そのEOL対応をしてほしい 加えて、25卒ルーキーのOJT（新卒研修）も担当してほしい という要望があり. 3/78
4. /78 思い出深いVue.jsでチャレンジ！ かなりVue.jsは久しぶり.でも、昔から好きな技術で思い出深い. 「 」という前向きな気持ち やってみるかー！ 4/78
5. /78 AIとの付き合い⽅も変化してきた 今ならAI活⽤すればマイグレーション体験も変わるかも 🤔⾯⽩そう！ AI技術の進化と私のざっくりとした体験 2023年 2023年後半 2024年 ChatGPT 対話型AIの登場で会話ベースの 問題解決に感動 GitHub Copilot Cursor AI補完に感動 AIフレンドリーなコード設計を 考え始める 2025年 AIエディタの誕⽣. ドキュメント（1次情報）の学習機能でハ ルシネーション対策も少しずつ可能に 開発の可能性がさらに広がる Claude Code ⾃律型AIエージェントの登場 ⼈間とAIの協働のあり⽅を再考 5/78
6. /78 一方でこんな不安も… （⼼の声） 「OJTって具体的に何をすれば…？」 「Vue.js、2020年くらいからキャッチアップできてない…」 「マネジメント経験ゼロで⼤丈夫かな？」 :e 「（v2の記憶で⽌まってる …) 😇」 6/78
7. /78 プロジェクト開始と発表内容 ライブラリ更新プロジェクト(以下PJ)は、ワクワクと多くの不安を抱えたまま開始. 本セッションでは、PJを通じて得た経験と、不安をどう解消していったかについて、 現場エンジニア⽬線の思考(現状の最適解)を整理して共有する. 移⾏⽅針の意思決定とその判断の過程 AI活⽤により楽になったこと、ぶつかった壁 PJを通して学んだAIとの向き合い⽅ ※この発表は私個⼈の意⾒であり、組織の⾒解ではないことをご理解ください。 7/78
8. /78 本セッションの想定視聴者 • AI駆動でライブラリ更新を検討している⽅ • AI時代の⾒積もりやリスク管理について考えていきたい⽅ • AI時代の育成に悩んでいる⽅ 8/78
9. /78 話さないこと（以下は知識がある前提でお話します） • スクラム開発⼿法の詳細（Jiraでチケット管理） • AIツールの詳細（Claude Codeの機能など） • 各ライブラリの詳細（Vue,jsエコシステム周り） 9/78
10. /78 前提の話：チーム体制と組織でのAI利用ツール 10/78
11. /78 • 基本は以下2名 ◦ 新卒3年⽬：プロジェクトリード ◦ 新卒1年⽬：AIネイティブ世代エンジニア（情報収集や課題解決の⼿段とし て、ごく⾃然にAIを使いこなす） • インフラ/バックエンドエンジニアとは随時連携 チーム体制 11/78
12. /78 AI利用ツール 制約‧環境： コーディング関係：Cursor / Claude Code / GitHub Copilotなど好きなツールを⼀つ チーム内では、Claude Code Max($100プラン)を利⽤ 12/78
13. /78 依存ライブラリ更新 Vue プロジェクトの品質向上と開発スピード改善の実践録 13/78
14. /78 はじめに 努⼒のベクトルを揃えるためにも、まずはミッションの設定を⾏った. 14/78
15. /78 ミッション サービスの⾒た⽬や振る舞いを変えずに、 EOLを回避すること 15/78
16. /78 サブミッション 25卒ルーキーの育成（新卒研修も込み） 16/78
17. /78 AI駆動で進める 依存ライブラリ更新 Vue プロジェクトの品質向上と開発スピード改善の実践録 17/78
18. /78 AI駆動によって追加したサブミッション チームや個⼈の成⻑戦略を並⾏して進め、より充実した成果を得る ① ② AI駆動でライブラリ更新する際の知⾒を形式化する スケジュール予測と不確実性に全⼒で向き合う 18/78
19. /78 AI駆動でライブラリ更新する際の知見を形式化する ① ① • AI活⽤を積極的に試し、結果をログとして記録 • 知⾒をまとめ、他プロジェクトへの横展開を⽬指す • 組織全体の効率化に貢献する実践事例の構築(AI駆動でのライブラリ更新のノウハウがないため) 19/78
20. /78 スケジュール予測と不確実性に全力で向き合う ② • 『エンジニアリング組織論への招待』4.2「スケジュール予測と不確実性」をベースに向き合う • 困難を伴うVue2→Vue3移⾏プロセスを通じて、不確実性への対応とスケジュールマネジメント⼒を向上 • AI時代の品質とスピードの関係について考える 20/78
21. /78 全体の移行の流れについて 21/78
22. /78 実装 レビュー テスト 従来のライブラリ更新 調査と⾒積もり => 移⾏⽅針 22/78
23. /78 AI活用前提：熊とワルツを──「わからない」に隠された意味 わからないことについて、わかっている（または知りえる）ことは何か。 • リスク管理の本質は「わからない」を認めるところから • 未知の列挙(AI活⽤可) → 実験(AI活⽤可) → リスク可視化(AI利⽤可) 23/78
24. /78 AIとの向き合うスタンス ① • わからないを前提に、わからないことを疑う • わからないこと起点でAIで代替できることはないか • AIがあるからこそできることはないか（これまでは後回しにしてたこと） • 抽象度⾼いものをAIで具体化すること（暗黙知→形式知）で不確実性の削減は可能か 24/78
25. /78 調査と⾒積もり(+AI) => 移⾏⽅針(+AI) 実装 (+AI) レビュー (+AI) テスト (+AI) AI時代のライブラリ更新 25/78
26. /78 サービスや技術的状況を AI補助ありで調査 26/78
27. /78 買収コード×EOL×内製化の荒地 状況：昨年買収したサービスの管理画⾯（80画⾯、40コンポーネント以上）の内製化 保守：数年以上停⽌状態 — 内部知⾒が少なく、外部依存が多い 技術スタック：Rails + Vue.js(v2.5）+ JavaScript(jQuery) + Pug + Webpacker(v3) + Sass + ElementUI 依存問題：EOL（サポート終了）ライブラリが多数、脆弱性警告が頻発 技術負債：巨⼤CJSファイル、巨⼤SFC、リンターフォーマッター設定なし AIでの調査により、概要レベルなら瞬時に正しく把握することができる 27/78
28. /78 詳細調査と見積もり 28/78
29. /78 スケジュール予測と不確実性 理想⼯期：⼯数⼈⽉/⼈数 制約スラック プロジェクトバッファ 実⼯期 納期 理想⼯期：総作業時間を⼈数で割ったもの 制約スラック：作業同⼠の依存関係による無駄 プロジェクトバッファ：⾒積もりの不確実性を吸収するための期間 29/78
30. /78 スケジュールマネジメントのコツ • 制約スラックを削減する • ⾒積もりの予測可能性を上げる • プロジェクトバッファの消費を可視化し改善する 30/78
31. /78 制約スラックを削減する① 制約スラック（作業同⼠の依存関係による無駄）を削減する →作業のブロック要素になりうるものを洗い出し、待ち状態をできるだけ作らないように対応する ルーキーの 育成 スクラム開発に 慣れてもらう 慎重な調査と 移行方針 各ツールの整備 ・FigJam ・Confluence ・Jira ・Slack Vue.jsを中心と した技術習得度 の考慮 がっつりAI 使えそう 一部AI 使えそう AI使うイメー ジなし 31/78
32. /78 制約スラックを削減する② • 制約スラックは2種類 • リソース制約 ◦ 「この作業は〇〇にしかできない」といういわゆる属⼈化作業で⽣まれる制約 ◦ 良し悪しの判断能⼒と意思決定ができるスキルが必要だと思うが、ルーキーでもAIの補助が あればいい線まで素早くできるようになる(逆に迷いがないのもよいという視点) • 依存制約 ◦ 作業と作業の間にある依存関係、つまり、2つの作業が同時並⾏で作業できないことで⽣まれ る制約 ◦ できるだけ⽣まれないようにタスク管理のマネジメント能⼒が必要 ① AIの活⽤⽅法とそのスキルを考慮して(リソース制約)、チケットの幅をコントロールする(依存制約) ルーキーの成⻑とともに、リソース制約なしで考えられるチーム作りを⽬指して 32/78
33. /78 制約スラックを削減する③ • 慎重な調査 ◦ AI利⽤をベースとして任せられる調査を渡す(Deep Researchとかも活⽤の上) ◦ 調査ドキュメントをレビューする • 移⾏⽅針 ◦ 知識がないと良し悪しが判断できないため最初は属⼈化してしまうが、とりあえず⼿を動か すで任せてみるのも⼿. 任せる幅をコントロールする. • 技術習得 ◦ AIの学習モード利⽤や、依存しているライブラリの⼩さなプレイグラウンドを作成など、AI実 ⾏時間の待ち時間などで勉強 • 各ツールの整備 ◦ 最初はリードエンジニアが主導し、拡張性については検討していってもらう • スクラム開発に早く慣れる ◦ チケット作成を始め、任せる範囲を少しずつ譲渡（フィードバックの繰り返し） 33/78
34. /78 見積もりの予測可能性を上げる① ⾒積もりの予測可能性を上げる →要望時でざっくりと理想⼯期を告げられるが厳密ではない場合がある. どのくらい時間がかかりそうか、できるだけ早くかつ、正確に伝えることが重要. 理想工期に対し てざっくりとした 見積もりを出す ことで、その ギャップを共有し たい 既存コード分析 がっつりAI 使えそう 一部AI 使えそう AI使うイメー ジなし その他発生しう るコア・リスク 34/78
35. /78 見積もりの予測可能性を上げる② • 理想⼯期と⾒積もりのギャップを埋める ◦ AIで既存コードの分析をしてドキュメント化を⾏う ◦ 例. Tsumiki(AI駆動開発⽀援フレームワーク)のような定型化されたClaude Codeカスタムコマンド活⽤ ▪ 詳しくは https://github.com/classmethod/tsumiki （⼀度動かしてみるのがおすすめ） ▪ rev-xxx（リバースエンジニアリングコマンド）が個⼈的には特によい(改変も可) ▪ 実装済みの機能から逆算してタスク構造、依存関係、実装詳細を抽出し、⼯数まで出してくれる ▪ 出⼒される⼯数はAIによる⽣産性向上を加味してない ▪ ⼀部タスクを消化することで把握できるベロシティ、他タスクのバッファにも反映していく • その他発⽣しうる下記コア‧リスク(熊とワルツを 第13章)がないか洗い出しておく ◦ スケジュールの⽋陥 ◦ 要求の増⼤ ◦ ⼈員の離脱 ◦ 仕様の崩壊 ◦ ⽣産性の低迷 35/78
36. /78 プロジェクトバッファの予測を可視化し改善する① プロジェクトバッファ（⾒積もりの不確実性を吸収するための期間）の予測を可視化し改善 →わからないことを後回しにせず、丁寧に向き合う がっつりAI 使えそう 一部AI 使えそう AI使うイメー ジなし チケットごとの見 積もり精度を上 げたい 既存コード分析 36/78
37. /78 プロジェクトバッファの予測を可視化し改善する② ‧チケットごとの⾒積もり精度を向上させたい  ‧Claude Codeカスタムコマンド(create-jira-ticket.md) でチケット⽣成する運⽤にした(対話形式型コマンド) 37/78
38. /78 プロジェクトバッファの予測を可視化し改善する③ ⽣成されたチケットに対して • リファインメント(プロダクトバックログを定期的 に⾒直し、詳細化‧整理する作業)での認識合わせ （AIに実⾏させても問題ないか） • 受け⼊れ条件と、注意点‧懸念点（技術的リスク、 破壊的変更、テスト戦略）は注意深く精査 38/78 簡易的なチケット例：
39. /78 移行方針 39/78
40. /78 調査と見積もりをもとに 段階的に小さくやる 40/78
41. /78 開発者として感じる課題感 41/78
42. /78 質的指標での課題感 ‧リンターフォーマッターなし（ESLint導⼊後、デフォルト設定で1,260件エラー、814件警告） ‧CommonJSコードのグローバル関数が174箇所で利⽤ ‧1,000⾏以上コードかつ循環的複雑度も100前後のファイルが多数 ‧Webpackerの内部依存ライブラリとNodeのVersionが⾮互換で、そもそも⽴ち上がらない ‧ほとんどのライブラリがEOLバージョン ‧node-sass（Dart Sass移⾏後警告が多数） ‧利⽤されていない画⾯やコンポーネントが多数 ‧コメントアウトされているコード739⾏ 移⾏前 42/78
43. /78 開発環境指標での課題感 移⾏前 本番ビルド時間  136秒 開発ビルド時間  3〜4分 HMR反映時間  15〜20秒(再読込必要) JSバンドルサイズ 3.41MB(Gzipped) 開発サーバー起動  30〜45秒 計測環境：開発⽤マシン M2 Macbook Pro, 16GB RAM 計測ツール：バンドルアナライザー、timeコマンドでの3回平均など 43/78
44. /78 やること・やらないことを決める 44/78
45. /78 やること・やらないこと やること： コードをクリーンに、開発基盤を整える Vue 2.7へのアップグレードとComposition API全 ⾯採⽤ WebpackerからViteへのビルドシステム移⾏ CommonJSからES Modulesへの移⾏ Sass deprecation警告の解消 ESLintエラー‧警告の完全解消 既知バグの修正とコードクリーンアップ Docker環境の最適化 やらないこと： 状況的に今ではない...⾟いやつは断念 ユニットテスト(育成と書きにくさから断念) TypeScript化(RailsのAPIの型など連携が必要 で⼯数⾼いと判断したため断念) pugからHTML(親しみないだけなので優先度 低いと判断したため断念) jQuery剥がす(依存している数が多いため断 念) ※ ()を理由として⼀時的に対象外とし、まずは安全にEOL回避 を優先 45/78
46. /78 やることに対して移行ガイドを作成 46/78
47. /78 移行ガイドを作ることで誰(AI)が やっても同じ状態になることを目指す 47/78
48. /78 移行ガイドをもとにAI主導での実装 48/78
49. /78 移行ガイドに互換レイヤ・ルールの明文化 • 移⾏ガイド⼿順書に、「互換契約」を明⽰(意図せず⾒た⽬、振る舞いを変えないため) • コードベースのルール‧前提‧特殊な互換性を明⽂化 // 移行ガイド.md の例 • [移行固有のプラクティス] useRouterはVue Router v3互換レイヤーとして実装（.valueアクセス禁止） • [UI/コンポーネント規約] Boolean型のpropsにはdefault: falseの一律付与禁止 • [アーキテクチャ依存] 全てのAPIアクセスは共通関数(utils)を経由すること 明確な「互換契約」を設けることで、AIによる⾃動コード変換の精度が向上し、 ⼈間のレビュー⼯数も削減. 契約違反はESLintでも検知できる⽅向性で進めた 49/78
50. /78 半自動化パイプライン - 全体像 ⼩さく進める‧記録する‧改善する 1. 影響調査 a. CHANGELOG/diff/grep b. AI要約 c. リスク抽出 2. チケット内容(./jira-tickets/{PJ名}-{チケット番号}-{チケットタイトル}.md)をもとにAIによるコード変換 a. ⼩単位適⽤(ペアプロなどで⼩さく始める) i. 限定的なスコープで変換を実⾏し、早期にフィードバックを得る b. 少しずつ適⽤範囲を拡⼤できるよう最適化 i. 検証済みパターンを徐々に広範囲へ適⽤、スケーリング ii. バグなどによる注意パターンがあれば随時適⽤ 3. ログ資産化(AIによる実装時はセットで) a. 変更サマリ.md(変更⽅針、変更した意図などを記載) 50/78
51. /78 バグ発生に繋がったコード変換3事例 51/78
52. /78 ケース1｜Pugテンプレ×setup未定義の識別失敗 現象‧問題コード // Pugテンプレート <template lang="pug"> .user-info h2 {{userName}} p ユーザー情報を表示 button(@click=" updateUser") 更新 // setup script <script setup> import { ref } from 'vue' // userName や updateUser が定義されていない const userId = ref(1) // 型チェックでエラーにならない問題 症状と原因 技術的背景： • Pugテンプレートで通常の型チェックが効かない • Vue Language Server とPugパーサーの相性問 題っぽい 症状： • Vue2,7でのComposition API移⾏後、 template参照変数がsetup内で未定義 • 開発時は検出されず、実⾏時エラー HTML記法では同じケースでコンパイルエラーになるが Pugでは気づかないまま本番環境で問題発⽣のリスク 52/78
53. /78 ケース1の学び | Pugテンプレの型安全対策 問題のPugテンプレート <template lang=”pug”> div {{ missingVar }} button(@click="undefinedMethod") </template> <script setup> // 未定義 </script> 修正後のPugテンプレート + setup <template lang=”pug”> div {{ definedVar }} button(@click="definedMethod") </template> <script setup> const definedVar = 'Hello' const definedMethod = () => {} </script> • ESLintルール追加：未定義識別⼦を検知するESLintルール（vue/no-undef-properties） ◦ プロジェクトの設計(mixins/プラグイン/ヘルパーの使い⽅)次第で誤検知率に影響出るので慎重に 追加する必要あり • 知⾒：Pugでは、リントチェックで"機械の⽬"を先に⽤意することが重要 ◦ Pugだったらどうなるか、これまでのあたりまえを疑う 53/78
54. /78 バグ発⽣コード例 間違い // Vue Router 4のAPIスタイルで誤って記述 params.token = router.currentRoute.value.query.token ; 正しい // Vue Router 3のAPIスタイル(valueなし) params.token = router.currentRoute.query.token; ケース2 | Vue Router バグ分析 「APIの互換性を確保するには、使⽤するRouterの バージョンを正確に把握すること」 「バグの内容」 • 前提：Vue 2.7のComposition API変換時に⾃作 useRouter(getCurrentInstance().proxy.$routerを ⼀時的に利⽤)を使⽤する必要あった • その指⽰があいまいにしていたため、AIによる コード変換時に⼀部Vue Router 4のAPI（.valueで のアクセス）と混同し、バグ発⽣ 54/78
55. /78 ケース2の学び | バージョン互換を規約として反映する 55/78 • Vueのエコシステム周りはとにかく移⾏ガイ ドが充実している ◦ ちゃんと読む ◦ 移⾏固有のプラクティスを反映 ▪ 移⾏ガイド、チケットにも注意点と して記述する ▪ AIレビューに学習させる https://router.vuejs.org/guide/migration/
56. /78 ケース3｜vue/require-prop-typesの警告修正で 　　　　 気付いた型間違いの流れ // 正しい: とりあえずString型が正しい props: { isActive:{ type: String, default:’’, } } // 問題: default: false一律付与 props: { isActive:{ type: Boolean, default:false, } } 1. 変更サマリ.mdの変換⽅針をレビュー時した際に、「 default: false⼀律付与」という記載に違和感 2. レビュイーにすべてデフォルトfalseで問題ないかどうかのチェック依頼 3. 2の依頼確認によると、そもそもStringだった(型が違う)ことが判明 4. 命名規則の慣習的に isXXXXの場合、Booleanを使⽤するという思い込みもあり、型が違うことは⾒逃し 5. 命名だけの雰囲気規則では AIも意図を汲み取ろうとし、ミスが発⽣する... 56/78
57. /78 ケース3の学び | 命名と型の徹底ルール化で AIと人の誤解を減らす • 命名規約の徹底 — isXXXXはBooleanのみに使⽤ • 型の導⼊時 — AIによる型変換する場合は、利⽤⽤途をコードから抽出させる（推測させない） ◦ (...そもそもTypeScriptでコンパイルエラー検出したい） • AI修正ログ明⽰ — Before/After⽐較で変更意図の記録をしておく 57/78
58. /78 次に、レビュー 58/78
59. /78 AIレビューの段階導入（フェーズ0〜3） 0. 観察フェーズ：デフォルト設定で導⼊(@claudeやGitHub Copilotに現状コードのレビューをしてもらう) 1. ⼿直しフェーズ：プロンプトで特にチェックしてほしい点を加えてレビュー 2. 低リスクパッチフェーズ：定型的な修正は、GitHub上コメント内で@claudeすることで修正 3. 安全テンプレ⾃動化フェーズ：バグリスクのパターンも⾒つけ次第追加しレビュー適⽤ 59/78
60. /78 AIレビューの導入効果と課題 良かった点 差分要約‧テスト観点の時短 PRの説明⽂やテスト観点のサジェスト、コード変更の要約が⼈ 間の1/3の時間で作成可能に 統⼀的レビュー基準の適⽤ レビュアー間の基準ブレを軽減、ルーキーでも⼀定⽔準の検出精 度を実現 繰り返しパターンの⾃動化 型定義の不⾜、命名規則違反、同様のバグパターンなどを⾼精度 で⾃動検出 教育‧知識共有の促進 レビュー時の解説が詳細で、チーム全体の技術知識向上に寄与 改善点 プロジェクト固有の理解が不⼀致 プロジェクト固有の規約やRouter互換レイヤーなど、⼀般的で ない前提の理解が困難 フレームワーク最適化の⾒落とし Vue特有のリアクティブ処理やライフサイクルの最適な使い⽅に ついて誤った提案も 過度な改善提案 コンテキストが不⾜した際に過剰なリファクタリング提案、実際 の変更範囲を超えた修正案 古いバージョンだとハルシネーション多発 AIの学習量が少ないため(Webpakcerあたり苦戦...)か、推測での レビューが多くなり、ハルシネーションが発⽣する 60/78
61. /78 最後に、テスト 61/78
62. /78 AI×QAのプラクティス組み込み • 仕様↔テスト照合 ◦ AIによる仕様書作成(Tsumikiのrev-xxxなど)とテスト⼀覧(QAエンジニアが主導で作成 したドキュメント共有)のギャップを⾃動検出‧可視化 • ギャップ検出⼿法 ◦ 仕様書の要件とテストケースのカバレッジをAIが意味的に照合 • 抽出‧分類 ◦ 未テスト要件、過剰テスト、ドキュメント不⾜領域を⾃動分類 62/78
63. /78 ざっくりと結果 63/78
64. /78 Vue 2.7移行の総合改善成果 Composition API化 Vue 2.5.22 → 2.7.16、全120ファイル(100%)移⾏ コード記述量30%減、2週間で完了（想定の1/3期間） ES Modules化 Utils.js（649箇所）、Auth.js/AuthAdmin.jsなど100%移⾏ 依存関係の明確化、Tree Shaking対応、IDE⽀援向上 Sass Modernization legacy-js-api、slash-div、mixed-declsを100%解消 ビルド速度向上、名前空間管理改善、保守性向上 ESLintエラー解消 エラー1,260→0件、警告814→0件 AI⽀援で2週間完了（従来の1/4の期間） Docker環境最適化 webpacker → viteサービスへ移⾏、Node.js更新 開発体験向上、リソース効率化、ビルド⾼速化 バグ修正とクリーンアップ 既知バグ4→0件、コメントアウト739⾏削除 コードベース健全化、技術的負債解消 コードがクリーンになり、可読性の向上を強く実感. AIのミスリードも削減されることが期待できる. 64/78
65. /78 Webpacker から Vite への移行効果 Before (Webpacker) 本番ビルド時間 136秒 開発ビルド時間 3〜4分 HMR反映時間 15〜20秒 (再読込必要) JSバンドルサイズ 3.41MB (Gzipped) 開発サーバー起動 30〜45秒 計測環境：開発⽤マシン M2 Macbook Pro, 16GB RAM 計測ツール：バンドルアナライザー、timeコマンドでの3回平均など After (Vite) 本番ビルド時間 12秒 91.2% 開発ビルド時間 5〜10秒 95%以上 HMR反映時間 < 1秒(即時反映) 95%以上 JSバンドルサイズ 916.27KB (Gzipped) 73.1% 開発サーバー起動 5〜10秒 80%以上 開発者コメント：「HMRの即時反映により体感速度が劇的に改善。 開発サイクルの短縮により、⽣産性が⼤幅に向上した」 数値改善も⼤事だが、開発者の『これなら続けられる』という実感が最⼤の成果. 特に、HMR⾼速化は⽇々のストレスを⼤幅に軽減した 65/78
66. /78 おまけ 66/78
67. /78 AI駆動で育成も経験して感じた話 67/78
68. /78 AI時代の育成について：AIネイティブ世代の特徴 前提条件として AI ネイティブ世代の特徴を以下整理 • AI 駆動が前提 ◦ 具体例: 調査タスクが数分〜数時間で完了 ◦ 従来世代との違い:従来は 1 ⽇弱かかっていた • 創造性が豊か ◦ 具体例: ゴールから逆算して⾃由に発想 ◦ 従来世代との違い:既存の⽅法論に縛られない • AI 前提の傾向 ◦ 具体例: 「まず AI に聞く」が⼿段 ◦ 従来世代との違い:⾃分で考える前に AI に依存する場合がある • ブラックボックス化 ◦ 具体例: 技術の内部理解が浅い場合がある ◦ 従来世代との違い: 動けば OK という傾向になりやすいかも(1⾏1⾏チェックが怠る) 68/78
69. /78 AI時代の育成について：学び① ①従来の育成⼿法は通⽤しない • 課題認識: ◦ Well-Known/Well-Defined なタスクは、AIに任せるスタンス ◦ 簡単なタスクによる「経験を積む」機会が消失 ◦ タスクを振るだけでは成⻑につながらない • 実践したアプローチ: ◦ 創造性を伸ばす⽅向へシフト - AI にできないことに注⼒ ◦ ゴールから逆算する⼒を養成 - タスクをどう作り上げるかを考えてもらう ◦ 双⽅向の学び - ⾃分も学ぶ姿勢で相乗効果を追求 69/78
70. /78 AI時代の育成について：学び② ②AI 活⽤と思考⼒のバランスが重要 • 発⾒した課題: ◦ AI が解決してくれる経験の積み重ねで、AI がベストな⼿段として固定化 ◦ ⼈間が詳細を把握しないまま問題が解決される懸念 ◦ 「思考停⽌で AI に認知と解決をセット」で任せる危険性 • 育成⽅針: ◦ ⼈間の認知プロセスを重視 - エラー整理は AI、判断は⼈間 ▪ 状況によっては、参考にしたソース(1次情報かどうか)の提⽰を依頼 ◦ AI を OJT のように扱う ▪ 丁寧に教える姿勢、抽象的なコメントにプラスしてAIで具体を補う ◦ なぜ難しいと判断したかを共有 ▪ ペアプロで思考プロセス(AIとの会話履歴含めて)を確認する 70/78
71. /78 AI時代の育成について：学び③ ③サポートと⾃主性のバランス設計が難しい • 実践内容: ◦ つまづきポイントの事前予測とサポート設計 ◦ リファインメント時の認識合わせ + チケットの詳細誘導⽂ ◦ 進⾏スピードと育成のトレードオフを常に意識 • 学び: ◦ ⼿厚いサポートは⾃主性を阻害する可能性 ◦ 理想よりも現実的な⽬線合わせが重要 ◦ ⾃由と制限のバランスは対話で調整 71/78
72. /78 AI駆動でよりよいAIとの 向き合い方を継続するために 72/78
73. /78 チーム内で取り組んだ意思決定プロセス • 朝会の冒頭5分でAIトピック意⾒交換 ◦ 隔⽇でAIニュースのキャッチアップした情報の意⾒交換を⾏い、⼩さな改善を議論し、作業フ ローを更新する(できるだけ刺激を⼊れて楽しむ) • 不定期開催で、AI利⽤⽅針の検討の⾒直しを⾏う ◦ FigJam(オンラインボードツール)内でやりたいことを記載し、議論したうえで以下分類する ▪ 議論したいこと(投票形式で票が多いものを採⽤) ▪ 今回やらないこと ▪ アクション(チケット化し、優先度決めて随時対応) • 実験→記録→反映サイクル(とにかく⼿を動かす) ◦ AIとの協働で得た知⾒を継続的にルールやプロンプトへ反映 73/78
74. /78 AI駆動で進めるライブラリ更新 やってみた感想 74/78
75. /78 AI駆動ライブラリ更新の所感 • スピードは爆速になるとは限らない • AIは⼈間のようにコードの意図を読み取ろうとする、エスパーではない • AIのためのガードレールを正しく引くことが⼤事(スキルで魅了していきたい) • AI駆動だとタスク消化も早い分、移⾏⽅針などの整理がボトルネックになる傾向があるため、素早く 判断する知識と能⼒が求められる • やったことのログはドキュメントに残すことが重要 ◦ ログは捨てる前提（レビューは雑でもよい）か、運⽤前提か、で管理⽅法を分別するのがよい ◦ ログが捨てる前提の場合は、あとでバグ発⾒したときになぜ間違えたかの理解に使い、再学習 サイクルとして利⽤するのがよい • タスク切る前にAIの⼒を借りて⼩さな環境で⼿を動かして検証し、不確実性を低減するのがよい 75/78
76. /78 まとめ 買収×EOL×内製化の荒地でも、AI＋機械ゲート＋⼩刻み戦で"⽐較的安全に移⾏できる" Vue固有の痛みは⼿順化すれば武器になる。記録し、学びをルールに反映 AIは"暗黙知を形式知にしてくれる相棒"、決める責任は⼈間。わからないにひたすら向き合う 学びを型‧Lint‧プロンプトに反映する継続的改善サイクルが最⼤の武器になりうる 機械チェックでの仕組み化が最も安全（そうしていきたい） 76/78
77. /78 参考書籍 • エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング • 熊とワルツを リスクを愉しむプロジェクト管理 • ⽣成AI時代の価値のつくりかた 実践者のマインド、スキル、データ、ユースケース • コード×AI ‒ソフトウェア開発者のための⽣成AI実践⼊⾨ 77/78
78. /78 ご清聴ありがとうございました 78/78