dxd2024-生成AIに振り回された3か月間の成功と失敗/dxd2024-link-and-motivation

Developers eXperience Day2024（主催：日本CTO協会様）

リンクアンドモチベーション登壇資料（2024/07/17）

『生成AIに振り回された3か月間の成功と失敗』

#dxd2024 #B #リンモチ
=============================================
【イベント情報】
■イベントページ
https://cto-a.org/dxd2024

【株式会社リンクアンドモチベーション】
■お問い合わせ
　engineer_pr@lmi.ne.jp
■テックブログ
　https://link-and-motivation.hatenablog.com/
=============================================

Transcript

1. 生成AIに振り回された3か月間の成功と失敗 Developer Productivity Unit / イネーブリンググループ 鵜木 義秀
2. @nokki_y 株式会社リンクアンドモチベーション イネーブリンググループ 鵜木義秀（うのきよしひで） #Vue.js #TypeScrip #Design #Vue.js_Japan_User_Group 自己紹介
3. 会社紹介
4. プロダクト紹介
5. モチベーションクラウド
6. 3ヶ月前はAIに対して斜に構えていた おれ、プロンプトエンジニアじゃないし。 おれはアプリケーションエンジニアだし。 それAIじゃなくても良くない？ AI使わなくてもユーザー価値のある アプリ作れるし。
7. お酒の勢いで登壇テーマを生成AIに決めた 登壇テーマ迷ってるんですよねぇ。 いや、でもAIとか全然わからないですよ。 最近良く困ってるライブラリのアップデートを AIで解決した事例とかいいじゃん！ OpenDevinが流行ってるらしいよ！
8. お酒の勢いで登壇テーマを生成AIに決めた 「わからないからやらない」は 「やらない理由にならないでしょ！」 そもそも、エンジニアはできないことを できるようにするのが楽しいんじゃん！ たしかに・・・。 ここでやらないと一生やらなそうだ・・・。 やります！
9. 実は同じ境遇の同期と一緒にやった
10. 「生成AIはもっともっと人間らしく扱うと良いかも」
11. 01 事例_1 OpenDevinを使い「ライブラリアップデート工数の削減」に取り組んでみた 02 事例_2 Difyを使い「ESLintのIgnore解消工数の削減」に取り組んでみた 03 まとめ 成果と学び、これから取り組むこと
12. 01 事例_1 「ライブラリアップデート工数の削減」に取り組んでみた
13. OpenDevinは自律的なAIアシスタント LLM 指示 途中経過・完了結果 入力 出力 OpenDevin 情報を拡張 コード取得・修正 ・テスト実行 コード情報 ・テスト実行結果 Source Code < / > Chat の入力内容に応じて、自律的に処理する
14. OpenDevinは自律的なAIアシスタント 画像出典: © OpenDevin, MITライセンス リンク: OpenDevin GitHubリポジトリ
15. ライブラリアップデート時に必要なコードの修正をさせたかった BEFORE After AI 工数削減 use Devin 01 アップデート情報の確認 02 コードの修正 対象ライブラリの更新 API変更に伴うリファクタリング 依存関係に応じた周辺ライブラリの更新 03 動作の確認 手動テストの実行と動作確認 自動テストの実行と動作確認 01 アップデート情報の確認 02 コードの修正 対象ライブラリの更新 API変更に伴うリファクタリング 依存関係に応じた周辺ライブラリの更新 03 動作の確認 手動テストの実行と動作確認 自動テストの実行と動作確認
16. 結果は失敗 失敗：成功率 5%以下 After 01 アップデート情報の確認 02 コードの修正 対象ライブラリの更新 API変更に伴うリファクタリング 依存関係に応じた周辺ライブラリの更新 03 動作の確認 手動テストの実行と動作確認 自動テストの実行と動作確認
17. 失敗：成功率 5%以下 ## タスクi S npmライブラリのアップデート ## 目的i S 対象のnpmライブラリを最新のバージョンに更新し、
 APIの変更に伴うソースコードのリファクタリングを行って
 既存のコードベースと互換性があることを確認すること。 ## 対象ライブラリi S ライブラリ名: [ライブラリ名] ## ライブラリのリリースノート: ``` ### [ライブラリ名] リリースノート #### バージョン 1.x.x - [変更内容] ``` ## 指示: 1. 現在のライブラリバージョンの確認: 2. ライブラリの更新: 3. API変更の確認とリファクタリング: 4. 互換性チェック: Prompt 結果は失敗
18. ライブラリ APIの変更情報 マイグレーション手順 アプリケーションコード コーディングルール 技術スタック レイヤー構造 依存ルール アプリケーションコードに関する情報が不足していた
19. アプリケーションコードに関する情報が不足していた ライブラリのアップデート作業よろしく！ ライブラリのアップデート情報はこれだよ！ ここがコーディングルールに従ってないです。 依存関係を考えるとここの修正も必要です。 コードを見た感じこのあたりを 修正すればいいのかな。やってみよう！ ・・・　これでどうでしょう？ そんなの聞いてないんだけど・・・
20. 仮説_1 （アプリケーションコードに関する情報も含めて） 作業内容を具体的に指示することが重要かもしれない
21. 01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 After this...
22. アプリケーションコードに関する情報を具体的にして再挑戦 After 01 アップデート情報の確認 02 コードの修正 対象ライブラリの更新 API変更に伴うリファクタリング 依存関係に応じた周辺ライブラリの更新 03 動作の確認 手動テストの実行と動作確認 自動テストの実行と動作確認 失敗：成功率 ほとんど変わらない
23. アプリケーションコードに関する情報が不足していた 思ってたのと違うぞ。 アプリケーションコードに関する情報はこちら！ 改めて修正お願い！ 指示にあったアプリケーションコードの情報と 異なるコードが有るぞ？ちょっと考えて修正してみるか。 ・・・　これでどうでしょう？
24. 01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 After this... 検証失敗
25. 01 事例_1 作業内容を具体的に指示することが重要かもしれない 工数の削減対象をESLintのIgnore解消に変更
26. 01 事例_1 作業内容を具体的に指示することが重要かもしれない 工数の削減対象をESLintのIgnore解消に変更 利用ツールをOpenDevinからDifyに変更
27. 自律性を活かしにくい状況になった ライブラリのアップデート 対象のライブラリによって 作業手順が異なる 不確実性が大きいため 自律性が活かしやすい ESLintのIgnore解消 ルールが異なっても 作業手順は大体同じ 不確実性が小さいため 自律性が活かしにくい
28. 02 事例_2 「ESLintのIgnore解消工数の削減」に取り組んでみた
29. DifyはLLMアプリをGUIで開発できるプラットフォーム Source Code < / > 修正 ・テスト実行 コード情報 ・テスト実行結果 Assign Review ・Merge Source Code Edit Server Dify Workflow Github Repository Commit ・Pull Request作成 コード取得・修正 ・テスト実行 コード情報 ・テスト実行結果 LLM 入力 出力
30. Workflowの構成
31. 対象プロジェクトのチェックアウトとターゲットファイルの取得 対象プロジェクトのチェックアウト ターゲットファイルの取得
32. Ignoreの削除とESLintの実行と確認 対象プロジェクトのチェックアウト ターゲットファイルの取得 Ignoreの削除 ESLintの実行(Auto Fix Mode)と確認
33. LLMによるファイルの修正と更新、そしてPull Request作成 対象プロジェクトのチェックアウト ターゲットファイルの取得 Ignoreの削除 ESLintの実行(Auto Fix Mode)と確認 LLMによるファイルの修正と更新 Pull Request作成
34. コードレビュー以外の作業を委譲させたい BEFORE After AI 工数削減 use Dify 01 Ignoreコメントの削除 02 修正箇所の確認 ESLintの実行 エラー内容の確認 03 コードの修正 04 Pull requestの作成 動作の確認 Commit・Pull Requestの作成 05 コードレビュー 01 Ignoreコメントの削除 02 修正箇所の確認 ESLintの実行 エラー内容の確認 03 コードの修正 04 Pull requestの作成 動作の確認 Commit・Pull Requestの作成 05 コードレビュー
35. BEFORE After 01 Ignoreコメントの削除 02 修正箇所の確認 ESLintの実行 エラー内容の確認 03 コードの修正 04 Pull requestの作成 動作の確認 Commit・Pull Requestの作成 05 コードレビュー 運用が実現的な成功率になった 5分程度の時間で1PRが作成可能に 成功：成功率 50%以上
36. 01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 After this... 検証完了
37. Dify 20分に1PR × エンジニア数 5分に1PRすると1時間12PR 新たな問題：レビューコスト
38. Dify 20分に1PR × エンジニア数 新たな問題：レビューコスト エンジニアのレビュー工数が 1PRあたり10-20分程度 必要な状況になっていた。 5分に1PRすると1時間12PR
39. この時なにが起きていたか「AIを信用できない」 レビュー時に行われていたこと ローカル環境での動作確認 レビュワーの心情 「AIによる修正はどこか不安になるため、慎重にレビューしたい」
40. 「AIによる修正はどこか不安になる」を更に掘り下げる 1_ 人間には期待値があるが、AIには期待値がない 例えば「◦◦さんが修正したなら、おそらくこの辺は大丈夫であろう」 といった期待値が人間に対してはあるが、AIに対してはない。 2_ AIは実装者として責任を取ることができない 実装車となるAIが責任を取ることができない分、レビュアーとしての 責任感いつも以上にが強くなる。
41. 01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 対人間以上に信頼度を高めるための工夫が必要かもしれない 検証完了
42. 02 事例_2 対人間以上に信頼度を高めるための工夫が必要かもしれない 作業プロセスが間違っていないことを証明する 十分にテストが実施されていることを証明する
43. ただ、、 「対人間以上に信頼度を高めるための工夫が必要かもしれない」については、 本日の登壇までに機能リリースして、効果を検証するに至りませんでした。 そのため、この先の内容はソリューションの仮説になります。 この検証結果は追って、弊社のテックブログで公開したいと考えています。
44. 作業プロセスが間違っていないことを証明して信頼度を高める
45. 作業プロセスが間違っていないことを証明して信頼度を高める 「正しい作業プロセスに基づいて修正されたかどうか」 を明記することで、信頼度を高める。
46. 十分にテストが実施されていることを証明して信頼度を高める インスタントテストとは その場限りのテストコード。 つまり、そのときLLMが修正した関数の品質を担保するためだけに 使用するテスト。 その場限りのテストコードの作成とそのテストにより担保される 観点をコメントさせる仕組み。
47. 十分にテストが実施されていることを証明して信頼度を高める 「正しいテスト観点に基づいて修正されたかどうか」 を証明することで、信頼度を高める。
48. 01 事例_1 作業内容を具体的に指示することが重要かもしれない 02 事例_2 対人間以上に信頼度を高めるための工夫が必要かもしれない 検証完了 検証中
49. 03 まとめ 成果と学び、これから取り組むこと
50. 本日までに得られた成果 削減された工数 1ファイルあたりの修正工数: 20分 5分 1ファイルあたりのレビュー工数: 20分 取り組み中 開発者体験の変化 能動的に修正 受動的にPull Requestを確認するのみ
51. 今回の取組だけを見ればインパクトはわずか 今回の経験を転用して、以下のような改善を自動化していく TypeScriptへの移行 Unitテストカバレッジの向上 リアーキテクチャに伴う横断的なリファクタリング ライブラリのアップデート ただし重要なのはこれから
52. 今後の展開を見据えて更に検証したいこと 1_ 膨大な量のトークンを入力できるモデルの検証や活用 例えばアプリケーションコードの情報をより多く入力することで 生成AIが対応できる範囲を広げていきたい。 2_ 自社データの活用 まずはコードレビューの結果を蓄積し活用していきたい。
53. 今後の展開を見据えて更に検証したいこと TypeScriptへの移行 Unitテストカバレッジの向上 リアーキテクチャに伴う横断的なリファクタリング ライブラリのアップデート
54. 今後の展開を見据えて更に検証したいこと TypeScriptへの移行 Unitテストカバレッジの向上 リアーキテクチャに伴う横断的なリファクタリング ライブラリのアップデート 膨大な工数が必要になるため 実現可能性を感じていなかった
55. 今回、AIの積極的に活用したことで AIを知り、これまで解消できていなかった課題を 解消できる可能性が生まれた。
56. 3ヶ月前はAIに対して斜に構えていた おれ、プロンプトエンジニアじゃないし。 おれはアプリケーションエンジニアだし。 それAIじゃなくても良くない？ AI使わなくてもユーザー価値のある アプリ作れるし。
57. 新しい技術が登場した時 触ってみて初めて分かることありますよね？ AI触ってますか？ そこには新しい発見やエンジニアとしての 楽しみがあるかもしれません。
58. Vue Fes Japan 2024 Otemachi PLACE HALL & CONFERENCE
 2024.10.19 SAT