イベント参加: 御社のDevin、何してる？ 各社の事例に学ぶ！組織の一員としての付き合い方 #devin_findy
2025年5月12日に開催された、「御社のDevin、何してる？ 各社の事例に学ぶ！組織の一員としての付き合い方」というイベントに参加しました。
プレゼンテーションを聞いて、個人的に気づき・学びになったことをメモ。具体的な内容やリアルタイムの雰囲気はハッシュタグをご参照ください。
https://x.com/hashtag/devin_findy?src=hashtag_click&f=live
気づき・学び
セッション1:「Why Devin? 期待感を持って踏み出した一歩、そして直面した課題たち」/ コクヨ株式会社 伊藤 のぞみさん
※資料は非公開
Devinに任せた方が速いのに、「自分の方が速い」と意地を張って、Devinを使わない問題。Devinだけじゃなく、Cursorでも、自分も同じ感情になってついつい自分でコード書いてしまうことが多いので、あるよなーって共感した。
「これまでやってきたやり方の方が正しい」と錯覚してしまうバイアスがよく働いてしまう。そのバイアスから強制的に覚めるための仕組みが必要。発表内容を聞きながら、どんな仕組みがあるといいのかなと想像を巡らしていた。
チケット・タスク管理システムにタスクを登録する際に、「このタスクは Devin にやらせよう」という印をつけるといいかもしれない。タスクの本文用テンプレートに「Devinにやらせるべきか否か」のチェックボックスをあらかじめ用意しておくといいかもしれない。
そんなことを考えていたら、Devin公式のJira連携機能があるということに気づいた。JiraのIssueに Devin というラベルを付与すると、Devin がIssueの分析を行い、必要であればJira上からDevinに作業の依頼もできてしまう機能。（今度試してみよう。）
脱線しました。なんにせよ、毎日次々と新しいAI活用の方法論が登場する中で、「食わず嫌いせず、まずは使ってみる」という精神が重要になっていると考えている。実際に触って試さないと本当に便利なのか・どこにまだ課題があるのかわからないし、試したことで人にもAIにもナレッジが溜まっていく。
だから、これまでの成功体験に引っ張られるバイアスから逃れる仕組みを、試行錯誤しながら実現していくことが重要。セッションのタイトルにもあるように、まず「一歩踏み出してみる」ことの価値が上がってきているなぁって思った。
セッション2: 「Devinにファーストレビューをさせ、コードレビューを効率化するには」/ 株式会社グロービス 大沼 和也さん(@technuma)
※資料はまだ公開されていません m(__)m
DevinをAIコードレビュワーとして機能させようとした後に、Devin上でのKnowledge管理の難しさ（バージョン管理ができない、など）から、Roo Codeにレビュワーを移行した話。
ちょうど今、Copilot Reviewを試しに使いはじめたところだったので、CodeRabbitなども含めた「レビュー専用AIツール」と比較して、こういう汎用的なツールをレビュワーとして使うのは実際のところどうなのか、というのがセッションを聞いていて気になった。
Roo Codeがレビューに使えるナレッジを蓄積するために、過去に不具合が発生したPull RequestをRoo Codeに入力し、分析させ、再発防止策を検討させ、それをルールファイルに出力させる、という学習のサイクルを回している事例が紹介されていて、とても興味深かった。そのルールを使ってRoo Codeにコードレビューをしてもらうことで、将来の不具合の再発を予防できる、というのが狙い。
ルールファイルをはじめとしたドキュメントの作成は、人間にとってはとても面倒くさいと感じるもの。特に不具合の影響がそこまで大きくなかった場合は、「まあいっか」と不具合の再発防止策が講じられないことも、自分の過去の経験上もよくあった話。
不具合の発生から学び、より良い開発プロセスの実現に繋げていくという役割の一部をAIに任せる。人間が面倒くさがるけど、網羅的に凡事徹底することが本当は必要で、大きな価値に転換しうる取り組み。それらがAIによって本当に凡事徹底されていくのは、AIがその真価を発揮しうる一つの重要なユースケースなんだと思った。
セッション3: 「データと事例で振り返るDevin導入の"リアル"」/ 株式会社ログラス r.kagayaさん(@ry0_kaga)
徹底的にCursor や Devinを使い倒しているなぁ、とすごく感心し、自分たちもやらなきゃと刺激を受けるセッションだった。
自分もここ数日は一時的にコードをいじる仕事が減っていて、うまくDevinやCursorを使って試行錯誤する機会が減っているのだけれど、まだまだ自分自身の活用促進のためにやれることあるということに気づけた。出退勤の前にDevinに複数のタスクをお願いしてから移動し始める、というのは実際にこれからやってみようと思う（今日イベントが終わって帰宅する前にさっそくやってみた）
Devinが作成した Pull Requestの「マージ率」をトラッキングする取り組みをされていて、その指標の発想はこれまでなかったのでとても参考になった。ドキュメントの自動生成に取り組み始めたタイミングでマージ率が上昇するなど、特定の取り組み前後で数値に変化があったり、大体マージ率は50%くらいと想像よりも低かったり、細かい点でも色々示唆が得られる内容だった。
最後の方で、ちょうど自分も気になっていた「AI用ナレッジのダブルメンテ問題」について触れられていたのも嬉しかった。複数のAIツールを併用している場合に、どこにAI用のナレッジを置くかが問題になる。AIツールによって、どのようにナレッジをかいたドキュメントを蓄積するかの仕様が異なっている。解決策案として「DevinにCursor Ruleを参照させる」方法を試してみたが、あまりうまくいかなかったことについて、セッションの中で言及されていた。実際に自分も試そうとしていた方法なので、「先に試してくださってありがとうございます」という感謝と、「ダメなのかー」というがっかりした気持ちになった。
対案として、Cursor Rules が更新されたときに、Devin APIを呼び出してナレッジを操作することが可能かもしれない、と言及もされていて、Devin APIの可能性を感じることもできた。Devinを開発プロセス・ワークフローにAPI呼び出して組み込むことで、Devinを意識せずともDevinを使って開発生産性が向上している状態が作れるといいなと考え始めていたので、自分もやれる時に実験してみようと思った。
Q&Aタイム
DevinやCursorの出力をレビューする際に、人間の書いたコードをレビューするときと比べて、レビュー基準が甘くなってしまう問題に言及されていたのが面白かった。そうすることで、品質の悪いコードがマージされた実績ができ、それを次のAIツールのセッションが真似をして、品質低下・技術負債化の負のスパイラルが発生するリスクがある。
自分もついつい同じことをやりそうになる or やってしまうことがあるので、気をつけないとなぁと共感・反省した。おそらく甘くなってるのは自分だけではないので、AIが「割れ窓製造機」になってしまわないような仕組みが必要にな理想だ。
AIがレビューすることで、人間のそういった感情的なバグみたいなのを回避できるかもしれない。でも、まだAIによるレビューがそこまで品質は高くないのかもしれない？いつかは進化するだろうから、今のうちにコードレビューのクオリティもAIによって改善する仕組みを検討しておきたいな。
終わりに
自分たちのチームよりも、AI活用が進んでいる各社の話を聞き、各社が今直面している課題やどう乗り越えようとしているかについて、たくさん知ることができる、とても良いイベントでした。
先人の知恵は借りて、これを自分たちのチームの開発生産性向上に繋げていきたい。明日からすぐ試してみたいアイデアもいくつか湧いてきて、参加してよかったです。
Member discussion