Slide 1

Slide 1 text

技術本部 Eight Engineering Unit Events&Solutions Devグループ ⻫藤 実 Nagoya Tech Talk #2 AI開発の落とし⽳ 〜 ⾺には乗ってみよAIには添うてみよ 〜

Slide 2

Slide 2 text

と感じたことはありませんか? 弊社でも⽣産性倍増! を期待して導⼊したものの、 現実はそう⽢くなかった話と 今後の可能性についての話をしたいと思います。 概要 AI開発ツールを導⼊したけど、 チームに浸透しない 使ってるはずなのに、 思ったほど⽣産性が増えない

Slide 3

Slide 3 text

個⼈事業主、エイチームを経て、 2020年Sansan株式会社に中途⼊社。 Events&Solutions Devグループでチームリーダーをしています。 楽しく開発できる環境づくりと事業に最⼤限の貢献ができる エンジニアを⽬指しています。 Rails歴10年以上ですが、現在はNestjsを使った開発にも 取り組んでいます。 AI⼤⾂として複数チームのAI利⽤推進にも取り組んでいました。 趣味:⽝の散歩 > ランニング >>>>> SF6 ⻫藤 実 Sansan株式会社 技術本部 Eight Engineering Unit Events&Solutions Devグループ

Slide 4

Slide 4 text

いざAI導⼊ 2025年1⽉頃。 バイブコーディングでAI開発がより現実味を感じるようになって、 チームへの本格的なAI開発導⼊を開始。 AIが開発を肩代わりすることで⽣産性の向上を⼤いに期待した。 チーム構成 - 正社員A: ベテラン - 正社員B: ベテラン、ただしチームに⼊って1年未満 - 正社員C: 中堅、ただしチームに⼊って1年未満 - 正社員D: 新卒 - 業務委託A: ベテラン - 業務委託B: 中堅、ただしチームに⼊って2年未満 - 業務委託C: 若⼿ 環境 Ruby on Rails, TypeScript, AWS Devin Claude Cursor

Slide 5

Slide 5 text

AI利⽤状況の計測 まずAIによる効果を測るためにGithub PR情報をベースに集計を実施。 Devinような⾃律的にPRが作成できるものはauthorで判別できるが、 cursorやclaude codeの場合はそれが難しいので⼿動で対応。 その後、Github ActionsでCo-authorの内容を 条件にPRにラベルを付与し、ラベルを元に集計。 集計項⽬はPR数、サイクルタイム、修正⾏数など。 # cursorの場合 git config --global alias.cursor "commit --trailer 'Co-authored- by: Cursor ' -m" git cursor 'コミットメッセージ'

Slide 6

Slide 6 text

導⼊開始

Slide 7

Slide 7 text

使い⽅が わからない 落とし⽳1: メンバーがAIを使わない・躊躇する 使わなくて もできる 使わない ほうが早い 原因1 原因2 原因3

Slide 8

Slide 8 text

どうしたか 使い⽅がわからない - チーム全員で各ツールの セッティングから実施 - 毎週チーム内でAI知⾒ 共有会を実施 使わなくてもできる - AIの可能性を探るために 無理にでも使ってもらう - ツール毎に担当を 決め、そのツールを 深掘りしてもらう 使わないほうが早い ≒ 精度が悪い - ユビキタス⾔語の整理 - コンテキストの整備、 統⼀化

Slide 9

Slide 9 text

結果

Slide 10

Slide 10 text

チームへの推進を進めて半年後...

Slide 11

Slide 11 text

落とし⽳2: 使われるが成果がでない PR数やサイクルタイムなどに変化が⾒られない...

Slide 12

Slide 12 text

AIにより実装コストは下がっているがレビューに時間がかかる 考察 実装 他者のレビュー セルフレビュー AIが作ったものはハルシネーションの検証だったり、 設計思想や運⽤ルールに即しているかをチェックする必要があるため、 通常よりレビューに時間がかかる 実装 他者のレビュー セルフレビュー

Slide 13

Slide 13 text

⾃律型エージェントによるタスクの並列対応はエンジニアへの負担が⼤きい 考察 実装 セルフレビュー 実装 実装 実装 レビュー レビュー … Devin Devin

Slide 14

Slide 14 text

AIが作っても正しく動くどうかは⼈が⾒る必要がある となるとエンジニア⾃⾝のスキルがないと結局開発の時間は⼤きくは変わらない 考察 ◎ ○ 実装 他者のレビュー セルフレビュー 実装 他者のレビュー セルフレビュー 想定通りの実装を してくれた! こうすれば実現できるんだ。 学びになった! 実装 他者のレビュー セルフレビュー

Slide 15

Slide 15 text

逆にスキルがないのに開発スピードが上がっている場合は注意が必要 実装エンジニアが、AIが作った実装を理解できていない可能性がある ある若⼿の⼀⾔:「成⻑している実感がないんです...」 あるベテランの⼀⾔:「書いてあることは理解できるが、独⼒だと0から書けない」 考察 × 他者のレビューも疲弊、成⻑がないためずっと続く 実装内容は なんとなく 把握した。 動いてるしOK! 実装 他者のレビュー セルフレビュー 実装 他者のレビュー セルフ レビュー AIの利⽤禁⽌や モブプロを 検討中

Slide 16

Slide 16 text

実際に経験の⻑いエンジニアは開発速度が上がっている傾向にあり、 経験の短いエンジニア、ジョインしたばかりのエンジニアには⼤きな変化は あまりみられなかった チーム構成 - 正社員A: ベテラン - 正社員B: ベテラン、ただしチームに⼊って1年未満 - 正社員C: 中堅、ただしチームに⼊って1年未満 - 正社員D: 新卒 - 業務委託A: ベテラン - 業務委託B: 中堅、ただしチームに⼊って2年未満 - 業務委託C: 若⼿ 考察

Slide 17

Slide 17 text

AI開発は即効果が出るものではない。ベテランばかりのチームではない限り普通。 知⾒のない領域ではベテラン、若⼿に問わずAIに頼り切るのは危険なので、 レビューにはきちんと時間をかけるべき。 AIの価値は⼈の成⻑を加速させる所にある。 効果が出るには時間がかかるので、 使い所を⾒極めて早めに寄り添うのが吉。 まとめ

Slide 18

Slide 18 text

現在やっていること よりAI駆動開発へのシフトへ - 実装以外へのAI活⽤でさらなる⽣産性の向上を⽬指して - ⼈間はレビューのみを⾏う - タスクの粒度を細かくすることでAIの暴⾛を防ぐ - ⼯数算出もAIにおまかせ - 別チームで4ヶ⽉以上かかる開発を半分以下で終了させた実績あり > 他チームに展開しても必ずしもうまくいっているわけではないので使い所は⾒極め - 実際に新プロジェクトで進⾏中

Slide 19

Slide 19 text

宣伝: Sansanは中部⽀店があるんだわ - 名古屋で働きたいと思っているエンジニアに とってもおすすめだがや😊 - 本社出張も気軽にできるんよ🚅 - ただいま中部⽀店採⽤強化中だがや🔥

Slide 20

Slide 20 text

宣伝: イベント告知 https://eight-event.8card.net/eightexpo/ai-pax/

Slide 21

Slide 21 text

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/

Slide 22

Slide 22 text

No content