数十名規模で Devin を1ヶ月トライして見えてきた点
昨今各社での開発におけるAIエージェントDevinの活用事例が出ていますが、グロービスでもトライアルを進めてきました。グロービスでは昨今エンジニアが150名を超えてきていますが、関心の高いメンバーを中心にトライアルを開始し、徐々に使う方が増え最終的には47名でのトライアルとなりました。
先日ちょうど1ヶ月が経過しまして、組織の中で活用いただいた皆さんにアンケートをとってみたので結果について共有したいと思います。本ナレッジが界隈の活用促進につながれば幸いです。
アンケート項目
アンケートとして以下の項目を聞いています。使えなくなるとどう感じるかといった感覚的な話から具体的にどの程度業務効率化につながっていそうかの定量面、加えて定性コメントについて聞いています。使っていく中でいまいちな点も結構見えていたところなのでいまいちな点についても聞いています。
- Devinが使えなくなるとどう感じますか?
- Devinで月何時間程度の業務効率化が実現できそうですか?
- Devinのおすすめの使い方について教えてください
- Devinのここがまだいまいちという点について教えてください
- 今後1年間を目処にチームでのDevinの活用度は何%増えそうですか?
定量面の結果について
定量面については以下の結果となりました。アンケートとしては40名から取得ができており、40名のデータだけでもDevinを使っての業務効率化が2人月分発生をしそうな状況が見えてきています。$500ドルからのスタートと思いつつ結局は50万円弱ほどかかりましたが、2人分以上(365時間)の業務効率化につながりそうであれば大きいですね。
- アンケート回答者:40名
- Devinでの業務効率化:合計で365時間/月、1人あたり平均9.1時間/月
- コスト: $3036 💸
Devinが使えなくなると残念か、という点には多くの方が残念と思いつつ、そうでない方も一定いて、この傾向の違いは特に参考になりました。やはり使い方が非常に肝になってくるツールな印象もあります。
職種別のデータとしては以下です。エンジニアだけでなくPOやQAのみなさんも活用をいただいたのがよかったですね、というのと傾向も参考になります。
職種 | 回答数 | 効率化時間平均 | 利用拡大想定 |
---|---|---|---|
PO | 3 | 2.0時間 | 43% |
QA | 7 | 6.3時間 | 27% |
エンジニア | 30 | 10.5時間 | 58% |
ちなみに来月は利用量がかなり増えそうな見込みがすでに立っており、Devinの上限を超えそうな状況に頭を抱えています。
定性面について(AIサマリー)
おすすめの使い方
おすすめの使い方についてアンケート結果をAIサマリー丸っとかけた結果について以下に共有したいと思います。最初はSlackから呼び出す使い方が多かったですが、レビューに組み込むであったりPOやQAのみなさんが使い始めてから活用事例としては多く出てきた印象があります。
1. コードレビュー・PR関連の活用
DevinはコードレビューやPR作成で特に役立つとの意見が多く見られました。
- 「コードレビューでは特に効果を発揮している印象です。小規模なリファクタはスムーズに行えるため、かなりありがたいですね…!」
- 「PRレビューでは非常に有用だと感じています。確認すべき観点を knowledge に蓄積することで、確認漏れや同じミスを防げると考えています。」
- 「コードレビューを代わりにしてくれる。」
- 「PRのセルフレビューの観点ヌケモレ・QAやチームメンバーと議論のベースとしたりしてみてます。」
PRの作成支援や説明生成にも活用されています。
- 「シンプルなプルリクエストを作る -> とくに開発中に既存実装を少し変えたい箇所が出てきた時などは、実装中の手を止めずに既存実装の修正ができてコンテキストスイッチが少なく済みます。」
- 「時間が無いとき(打ち合わせ等でコーディングができないとき)に、たたき台程度の PullRequest を作らせる。」
- 「簡単な修正とそのpull request作成」
2. Issue作成・情報整理
Issueの作成や情報整理にも活用されています。
- 「PdMなので、issueの作成がおすすめです。中身の確認はもちろん必要ですが、自分で手で作らずとも、たたきを作ってくれるので作ってくれたものを確認/修正するだけで良いので、手間が減りました。」
- 「POがissueを作る際には少し活用できてそうな雰囲気はあった。」
- 「Slack のスレッドを元に、取り決めた内容を Issue に起票する。」
- 「各チケットの情報収集や要約」
- 「Github等のissueから内容を抽出してもらう。また、直近で変更部分があるか、どこが変更されたか差分を抽出してもらう等。」
Issue分析や知識共有にも貢献。
- 「GitHub Issue の分析をさせる。」
- 「DevExチームなどで貯めた、flaky testsやより良いリファクタリングなどのknowledgeをDevinに集約し、レビューを担当してもらう。」
- 「hodai リポジトリは複数の開発チームが関わっているため、チーム間の knowledge 共有が Devin を通じて自然に行われる点は大きなメリットだと思います。」
3. 単純作業の自動化
繰り返し作業や大量の処理を任せる用途が多く見られました。
- 「基本的に『投げっぱなしでやってもらえる作業』という方向で使っています。」
- 「テストの間欠的な失敗を調査して修正してもらう。」
- 「エラーの調査をしてもらう。」
- 「単純作業を大量のファイルに対して処理してもらう。」
- 「プログラマーとして使う場合、単純な繰り返し作業などを依頼すると、自分の時間を使わずにチェックが進められる。」
- 「人間がするまでもない、細かい開発業務を裏で進めてPRを上げさせる。」
4. コーディング支援
コーディングタスクの支援にも一定の活用が見られましたが、まだ十分に使いこなせていないという声も。
- 「簡単なコーディングタスクの実装」
- 「コードを書く作業については、まだ十分に使いこなせていないです。」
- 「以下のような作業については、9割程度の精度で成果物が生成されました。」
- 「画像から view ファイルを作成する。」
- 「クエリから逆算して Model を作成する。」
- 「以下のような作業については、9割程度の精度で成果物が生成されました。」
- 「mtg中にDevinを動かしてコーディングしてもらう。」
- 「IDE開かずしてコーディングができる点。」
特定の用途では効果を発揮。
- 「似たような処理を教えてあげられる横展開のコーディング。」
- 「darklaunchの設定のプルリクを作ってもらう。」
5. 非エンジニアの業務支援
エンジニア以外の役割でも活用の可能性が指摘されています。
- 「PO,デザイナーが文言変更やデザイン変更(HTML,CSS)をエンジニアを介さずに対応する。」
- 「QAがコードベースから仕様を文字起こしする。」
- 「コードを書くよりもPOの方々のissue作成やデータ集計などの方が効率よく使用できている印象があります。」
具体的な作業例。
- 「・簡単な文言変更」
- 「・不要になったコードの削除(feature flag, one time job)」
6. 今後の活用の方向性
今後の活用についてもいくつかアイデアが挙がっています。
- 「これからやろうとしていること」
- 「社内向けプロダクトの開発(PO・エンジニア1人ずつだけと、Devinで完結させる)。」
- 「仕様確認bot。」
- 「開発がどんなテストをやっているのかを理解するのに使おうと考えてます。」
- 「テストコードの有効性もチェックできそう。」
Devinのここがいまいち(AIサマリー)
Devinのここがいまいちという点についてもAIサマリーについて共有します。全体的に使い方がいまいちな場合に逆に時間がかかってしまう、というケースが見られます。
1. 進捗の可視性とレスポンスの遅さ
- 「PRになるまで進捗が具体的に見えない」
- 「反応が遅い、指示=>修正のサイクルが長い」
- 「出力結果までに時間がかかる」
- 「前日のDevinとのスレッドに再度プロンプトを投げると、実行している旨のメッセージが表示された後、実行結果を待たずして自動でsleepしてしまった」
Devinの作業の進捗が見えにくく、レスポンスが遅いことが課題。特にPRの作成やコードの修正を依頼した際、どこまで進んでいるのかが分からず、結果を待たなければならない点がネックになっている。
2. 高度な実装の難しさ
- 「高難易度な実装は完全にお任せすることはできず、エンジニアによる伴走が必要そう」
- 「ちょっと複雑度が上がる実装だと、一発でサクッとできない」
- 「簡単なタスクでない限り、Devinだけで修正が完結しない」
- 「実装内容の精度が体感で70%ほど。結局ミスを探して手直しするので、最初から自分でやった方が早いと感じることが多い」
単純な作業は得意だが、複雑な実装や高難易度のコード修正では、エンジニアのフォローが必要になる。特に精度が100%ではないため、結果的に手直しの手間が発生することも。
3. ナレッジの蓄積・管理が必要
- 「Devinのknowledge機能にコンテキストを覚え込ませたり、リポジトリにドキュメントを寄せるなどしないと、ソースコードの修正を完結するのは難しい」
- 「knowledge の管理方法を決めておかないと、精度が低下する可能性がある」
- 「使用者が意図した挙動をしないケースが多い(ナレッジが蓄積されることで解消される可能性はありそう)」
Devinを有効活用するには、事前にナレッジを整備し、適切なプロンプト設計をする必要がある。しかし、その管理が負担になり、適切に設定できないと精度が落ちてしまう。
4. プロンプト設計の難しさ
- 「プロンプトを投げても、少しでも抽象的な要素があると正しく実装されない」
- 「良いプロンプトがないと生成もうまく行かない」
- 「意外と指示にないことを実行することがあり、プロンプトの工夫が必要」
- 「Issueの書き方が参考やテンプレートを細かく指定しないと期待通りにならず、余計な手間になる」
Devinに指示を出す際、適切なプロンプトを設計しないと、期待通りの結果が得られない。特に抽象的な指示では精度が低くなり、修正の手間が増える。
5. 外部ツールとの連携が制限される
- 「NotionやMiroの参照ができない」
- 「Slackの参照ができない」
- 「他アプリとの連携が制限され、認証情報の扱いが難しい」
Devinは現状、NotionやSlackなどの外部ツールと直接連携できないため、情報収集やタスク管理に制約がある。
6. ファイル・コードベースの大規模処理が苦手
- 「ファイルの行数や参照範囲の量が大きくなると達成できなくなる」
- 「PR単位と編集するファイルの数を予め指定しないと、レビューに忙殺される」
- 「repoがないとかちょくちょくウソをつく」
大きなプロジェクトや複雑なコードベースに対応する際、Devinの処理能力や正確性に課題がある。複数のファイルを跨ぐ修正や、大規模なリファクタリングは向いていない。
7. PR管理の不安定さ
- 「Devinが作ったPRの概要欄を変更しても、元に戻してくる」
- 「指示をしていないのにPR内のレビューコメントに反応し、不要なcommitを積んでしまう」
- 「他プロダクトのリポジトリに誤ってpushすることがあり、制御が大変」
PR管理において、意図しない変更が加えられたり、予期しない挙動をすることがあるため、エンジニアによる最終チェックが不可欠。
最後に
Devinは上手い活用ができれば上手く行きますし、そうでないと結局自分でやった方が早い、という風になりがちです。受動的に活用できるレビュー領域やKnowledgeをいかに活用していくのかが組織活用においては肝かなという風に感じています。
加えて、Devinでしか実現できないことは何かを考え、昨今いろいろと生成AIが出てきている中での棲み分けも論点として上がってくるものと思います。
グロービスは引き続きDevin含めて生成AIを積極活用しつつ、プロダクト開発に向き合って行きたいと思います。そんな環境で社会価値の高いプロダクトを作って行きたいエンジニアのみなさん大募集中です!
Devinのリファラルリンクも置いておきます。100ACUsもらえるらしいので始めるならこちらからぜひ。
Discussion
記事の本筋と少し外れてしまうのですが、AIによるサマリ部分を明記していただいているのが非常に好印象でした!
Devinの導入は悩ましいところだったので、詳細なレポートとても助かります!ありがとうございます!