Devin話題ですよね！弊社でもつい先日から契約開始しました！
既に社内でガンガン利用されてる他社様での事例を拝見していると、難しいタスクになると中々うまくいかないようなお話も耳にしつつ、その会社独自で活用パターンを見つけられてるように感じました。
なので、活用パターンを丁寧に調べてからチームに渡すのではなく、クイックに展開した上で社内メンバーにDevinを活用してもらって、会社独自の利用パターンを探るのが良いなという考えに至りました。
早く使ってもらいたいと思いつつ、導入しました！使ってください！だと使い方のハードルがあったり、セキュリティやコスト面での懸念があったので、最低限担保したいことを整理した上で社内向けにクイックスタートガイドを作ってみました！
CTOである自分自身が決裁者としてなぜDevinを導入したのかという背景や、活用して行く上でのステップについて社内用に整理したものをアレンジして記事にしてみました。
これからDevin導入を検討されてる企業の方や、Devinの社内ガイドラインを作ろうとしている方の参考になれば幸いです🙏
Devin導入の目的
Devinは月額500ドルという絶妙な金額設定であるため、とりあえず使ってみようというモチベーションだけでは会社として継続投資することが難しい場合もあるかもしれません。
これは若干厳しい視点かもしれませんが、弊社は資金が潤沢にあるスタートアップではないので1つ1つの投資を大事にしていきたいと考えています。弊社で掲げている目的は以下です。
＜目的＞
「Devinにより一人一人がどこまで並列に近い状態で開発を進めれるかの仮説検証をしたい」
これまでは物理的な制約として、一人が同時に同じタスクをやることは不可能だったと思いますが、Devinの活用により、並列にタスクを進めることを実現できる可能性を秘めています。
一人一人が並列に近い状態で開発を進めることが出来れば、将来的に少人数チームを作っていけるかもしれません。人数が増えれば増えるほどコミュニケーションパスが増加します。コミュニケーションパスは人数の二乗に比例して大きくなってしまうためチーム人数に応じて課題が生じやすくなります。
これは極端な話ですが、仮に2025年におけるAプロダクトの開発は1チーム6名体制でやっていたと仮定して、2026年におけるAプロダクトの開発を1チーム5名 + Devinという体制でやっていければ、資金・コミュニケーションの双方の側面において大きなメリットがあります。
もちろん、2025年2月時点でDevinは完璧な存在ではなく皆さんのサポートが必要です。公式ドキュメントにはジュニアレベルのエンジニアという記載があるように時にミスを犯しますし、皆さん一人一人のサポートも必要です。現在の精度では複雑なタスクを一発のプロンプトでこなせるほどのクオリティではないです。
ただ、Devinの精度はDevinだけの問題ではなく、プロジェクトごとのローカル開発における複雑性・Devinのナレッジやプレイブックという機能のカスタマイズなど、多くの変数が存在するため、現時点でのクオリティだけで判断するのは難しいということも感じています。
そのような複雑性の高い状況だからこそ、チーム全員でフル活用していきたいですし、Devinのクオリティが低くても諦めずに試行錯誤してほしいという話を社内で共有しました。
ちなみに、弊社ではエンジニア全メンバーにCursorかGithub Copilotも配布してます。なので、Devinはあくまで開発チームのアウトカムを最大化させる手段の仮説検証だと捉えています。
社内ガイドラインの概要
このドキュメントは皆さんにDevinを使っていただく上で知っておいてほしい情報を整理し、会社としてのガイドラインや段階的に踏んでほしいステップについて整理したものです。
ガイドラインの構成としては以下のようなドキュメントになっています。
- Devinの概要 & 利用方法
- 利用までのステップ
- 活用ガイドライン
- お願いしたいこと
- FAQ
Devinの概要 & 利用方法
（社内向けには説明しましたが、言うまでもないので割愛しますmm）
利用までのステップ
チームメンバーがなるべく利用しやすいように、ステップを整理してまとめてみたものです。公式ドキュメントが非常に充実しているため、そのまま引用した上で必ず読んでくださいねという案内をしています。
1. 必須ガイダンスを読んでいただく
✅When to Use Devin
✅Instructing Devin Effectively
✅Good vs. Bad Instructions
2. 1〜3ファイルで完了する非常に小さなタスクをDevinに依頼する
まずDevin活用の感覚を掴んでもらうために、小さな変更から依頼しましょう。例えば以下のようなタスクです。
- 文言の修正
- 命名の変更
- CI・CDの追加・修正
- ユニットテストの追加・修正
3. 必須ガイダンスの内容を基に徐々に依頼するタスクを大きくする
必須ガイダンスの内容を踏まえた上で、少しずつタスクのサイズを大きくしていきましょう。
ポイントは徐々に依頼するタスクを大きくすると言う点です！
皆さんが初心者エンジニアだった頃を思い出してください。いきなり大規模なリファクタリングや、複雑なデータモデルの設計タスクを依頼されたら発狂しますよね！？
同じようにDevinに対しても徐々にタスクのサイズを広げてみてください
活用ガイドライン
-
あくまで自分の作業PRと同じように扱うこと
- 言い換えると自分がレビューできるタスクであり、誰かにレビューしてもらうために申し送りできるタスクと言えます。
- 自分がレビューできないタスクをDevinに投げてしまうと誰がクオリティ担保するの！？という話になってしまうので、それは避けるようにしましょう
-
ACU（Agent Compute Unit）を消費しすぎないようなタスクを渡すこと
- Devinは月額課金制ではありつつ、月間で利用可能なACUと呼ばれる作業単位が割り当てられます。
- 月額500ドルでは、このACUが月間で250ACUという制限があるため、利用しすぎた場合追加での課金が必要になります。
- 追加は1ACUで2$ほどなのでそこまで大きくはないですが、追加の課金額はなるべく抑えたく、利用する際は気をつけていただけるとありがたいです🙏
-
秘匿情報は渡さない
- このページに書いてあるように秘匿情報をうまく管理する仕組みもあるようですが、他社の事例を調べていると、この秘匿情報を勝手にGithubへpushするような挙動もあったようなのでまだリスクが高いと考えています。
- また、ログインID・パスワードのようなものをDevinのローカルマシンの中で動いてるブラウザのCookieに保持する機能もあるようですが、漏洩リスクがあるので使わないでください🙇♂️
- もしどうしても秘匿情報が絡むタスクをやってほしいという場合は事前に相談してください
-
ナレッジ機能の活用方針について
-
前提スタンス
-
Devin関係なくナレッジ管理の視点から見たときにストックする情報の置き場所は増やしたくないです。ただ、最初の方針としては雑でも良いのでナレッジに追加する方針で良いかなと思っています。
-
開発チームに新しいメンバーが入った時、オンボーディングプロセスの中で、全ての情報が形式知化しているわけではなく、皆さんの脳内に情報があるはずです。Devinのナレッジは皆さんの記憶と近いような扱いをしていただくと良いかなと考えています。
-
とはいえ、実際のオンボーディングプロセスの中で、形式知化しないといけない情報が出てきた場合はチームのWikiにまとめて、チームメンバー全員が見やすい場所にストックされますよね。最終的にはDevinとメンバーが見る情報が同じであることが望ましいとは思います。
-
-
特にどのような情報を追加すべきか
- エンジニアとして常識的なレベルでありチームで形式知化するものでもないが、Devinがうまく動いてくれない時
- Githubのリポジトリには存在しないものの、NotionやSlackにある情報で他タスクと共有したい情報
-
いつ追加するか
- セッションが終わったタイミングでDevinからレコメンドしてくれるタイミングがあるのでその時に追加することが可能です。（もちろんそれ以外でも追加することは可能です）
- セッションが終わったタイミングでDevinからレコメンドしてくれるタイミングがあるのでその時に追加することが可能です。（もちろんそれ以外でも追加することは可能です）
-
-
CIはなるべくローカルで実行させ何度もremoteへpushさせないようにする
- 何もプロンプトで指定しないと、めちゃくちゃ細かくリモートにpushされてしまう事象を発見しました。
- またremoteへのpush頻度が多いと、都度CIの待機時間が発生してしまう問題やActionsの費用が増える問題があります。そのためなるべくローカルでCIを実行するようにしてください
-
特定リポジトリにおける初回実行時について
- マシンのスナップショットを作成していただけると、次回セッションのオーバーヘッドが多少少なくなります。
- 例えばDev Containersの設定をしておくとセッションが立ち上がる度に同じ環境で開発することが可能です。
- Devin’s Workspaceの一番右側からスナップショットを作成できます。
-
長時間タスクが終わらなかった場合について
- Devinにタスクを依頼したにも関わらず、長時間（3〜5時間）かけても終わらなかった場合は諦めてゼロベースで始めるか、Devinのもしくは方向性を変えるプロンプトを示しましょう
お願いしたいこと
正社員、業務委託関わらず全員ガンガン活用していきましょう！！
その上で以下の3点だけお願いです 🙏
- 良いナレッジはslackチャンネルやエンジニア全体MTGにて、チーム全体で共有しましょう！
- 社外に向けてもガンガン発信していきましょう！
- セキュリティリスクを感じた際はすぐにCTOに連絡してください。
FAQ
- CursorとDevinの棲み分けイメージは？
- 既に多くの方が言及されている通り、Cursorは自分の出来ることを増やすイメージで、Devinは自分の出来る作業を増やすイメージに近いと思います。
- 会話履歴ってどの単位で保持される？
- 会話履歴はスレッドで独立してるものです。ただナレッジという機能があり、リポジトリ単位や組織単位で情報を保持できる機能があります。
- Devin が稼働しない間はACU は消費される？
- Devinは～0.1ACU活動しないと自動的にスリープする仕様のようです。
- IDEからも使える？
- Beta版とありますが、CursorでもVSCodeでも使えるようです！
- .envファイルってDevinに渡す必要がある？
- Devinが必要だと判断した場合自動で作成します。ただ、項目の追加・編集が必要な場合は別途お願いします。
今後の活用にむけて
以上、社内で作ったガイドラインでした。
このガイドラインでは言及していませんが、今後活用していくにあたって例えば以下のような論点があったりします。
- 実際にROIをどこまで計測するのか？
- タスクの大きさから人間がやった場合にかかる時間を換算して、Devin経由でマージされたPRの数を計測する
- メンバー1人1人の活用をどこまで促すか。
- まずは任意でやりつつ勝ちパターンが見えてきたらチームの活動に組み込む
- DevinとCursorの共通ナレッジをどのように管理するか、Notionの情報をどのようにDevinに組み込むか
様々な論点はありつつ、まずは実際にメンバーがプロダクト開発の現場でPDCAを回しながら、弊社なりのベストプラクティスを探っていけたらと思います。
導入検討されてる人や、社内ガイドラインの参考になれば幸いです🙏
Discussion