アプリケーション開発において、Devin をどう活用するか?
株式会社FLINTERS / 吉田奈々
メンバー / バックエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 51名〜100名
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
Team プラン | 10名以下 | 2025年10月 | B to B |
| 利用プラン | Team プラン |
|---|---|
| ツールの利用規模 | 10名以下 |
| ツールの利用開始時期 | 2025年10月 |
| 事業形態 | B to B |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
レビュワーの負担増
- 半年でプロジェクトメンバーが大幅に増え、ドメイン知識を知っているメンバーが少ない状態でした。
- コードレビューをするメンバーに偏りがある状態を解消したいと考えました。
- 初回コードレビューを Devin に任せ、Devin に指摘された部分を解消した状態でレビュー依頼をするようフローを変更しました。
ドメイン知識の習得に時間がかかる
- Notion / DocBase などドメイン知識や仕様書がバラバラになっている状態でした。
- Devin と GitHub を連携し、コードを読ませてアプリの構成を把握するようにしました。
どのような状態を目指していたか
- レビュワーの負担を減らし、他のタスクに集中できる環境を作る
- ドメイン知識の早期習得を目指す
導入の成果
改善したかった課題はどれくらい解決されたか
レビュワーの負担増
- レビュワーにレビューを依頼する前に、Devin にレビューをさせることによって自分では気づかないポイントが明確になり、修正が減ったなと感じました。
- チケット対応者 / レビュワー 間のやり取りが減少し、レビュワーの負担が減ったかなと感じています。
ドメイン知識の習得に時間がかかる
- コード上 / GitHub リポジトリ上の仕様については、まず Devin で確認したうえで、該当するコードを自分で読むようにした結果、コードベースや GitHub リポジトリの中で、どこにどの機能が実装されているのかを把握するまでの時間が短縮され、理解がスムーズになりました。
- 作業時間に余裕が生まれたことで、より詳細な設計の検討やコードの書き方に時間を割けるようになりました。その結果、セキュリティ上の懸念や、既存システムに影響を与えないかといった観点についても、より細かく確認できるようになりました。
どのような成果が得られたか
レビュワーの負担軽減
- 事前にコードの仕様確認や自己レビューを行うことで、基本的な指摘事項が減り、レビュワーの確認工数を削減することができました。
詳細設計の精度向上
- コード理解や仕様確認にかかる時間を短縮できたことで、詳細設計の検討により多くの時間を割けるようになりました。その結果、セキュリティ上の懸念や既存システムへの影響などについても、より細かい観点で確認できるようになりました。
導入に向けた社内への説明
上長・チームへの説明
会社側ですでに導入推進が進められていたため、特に説得は不要でした。 そのため、どう使いこなすかということを考えました。
活用方法
プルリクエスト(PR)の一次レビュー / Playbook の作成
- コードレビューを効率的に行うために、レビュー手順を Playbook として定義し、コマンドで呼び出せるようにしています。
- Playbook 内では、以下のような観点をもとにレビューが行われるよう設定しています。
- プルリクエスト情報の取得
- PR のタイトル、説明、差分など、レビューに必要な情報を取得する
- どの範囲のコード変更を確認するのかを明確にする
- コードの品質確認
- 提出されたコードが正しく動作するか
- 可読性や保守性に問題がないか
- ベストプラクティスの確認
- 言語やフレームワークのベストプラクティスに従っているか
- 非推奨の機能が使用されていないか
- レビューコメントの構成
- 指摘事項をどのような形式でコメントするか
- 開発者が修正しやすいように、具体的かつ建設的なコメントになるようにする
- プルリクエスト情報の取得
このように、あらかじめ作業内容に応じた Playbook を作成しておくことで、レビューの観点や生成されるレビューコメントの品質を一定に保つことができます。
ドメイン知識の習得 / コードの説明
新しい機能や既存のシステム構造を理解する際に、Devin を使って コードの説明や処理の流れを整理しています。 具体的には、
- 特定の機能が どのファイル・どのクラス・どの関数で実装されているか
- 処理の全体の流れや依存関係
- 実装の意図や設計方針 などを整理することで、ドメイン知識の習得を効率化しています。
簡単なスクリプトの作成
現在関わっているプロダクトでは コスト削減の取り組みを行っており、その中で Devin を利用して 簡単な調査用スクリプトを作成しています。 例えば以下のような用途です。
- AWS リソースの利用状況を確認するスクリプト
- EC2 インスタンスの利用状況を取得するスクリプト
- コスト削減候補となるリソースを調査するスクリプト
このようなスクリプトを作成することで、調査作業の自動化や効率化を行い、どのリソースのコストを削減すべきか判断するための時間を確保しています。
よく使う機能
- Playbook
- 特定の作業を実行するための手順やルールをまとめておく機能です。
- よく行う作業の内容や手順をあらかじめ定義しておくことで、コマンドから簡単に呼び出して実行できます。
- 繰り返し行う作業を Playbook として整理しています。
- 例:ログやエラーの調査など
- Knowledge
プロジェクトや組織に関する知識を保存し、Devin が参照できるようにする機能です。
コードベースやプロジェクトの背景、開発ルールなどを Knowledge としてまとめておくことで、Devin がそれらを理解したうえで作業を行えるようになります。
Knowledge には、以下のような情報を整理しておくことができます。
- リポジトリのディレクトリ構成
- API の役割やデータフロー
- データベース設計
- プロジェクト固有の用語
システムの構造やドメイン知識を Knowledge に整理しておくことで、コード理解やレビューの精度を高めることができます。
ツールの良い点
- 作業の標準化がやりやすい
- Playbook を利用することで、よく行う作業の手順をあらかじめ定義しておくことができます。
- 作業品質のばらつきを減らせる
- 作業の抜け漏れを防げる
- レビュー観点を統一できる といったメリットがあります。
- Playbook を利用することで、よく行う作業の手順をあらかじめ定義しておくことができます。
ツールの課題点
- 出力内容の正確性は常に確認が必要
- Devin が生成する内容は必ずしも正しいとは限らないため、コードレビュー内容 / 調査結果などは人間が確認する必要がある部分もありそうだな、と考えています。(こういう AI ツールあるあるだとは思いますが・・・)
株式会社FLINTERS / 吉田奈々
メンバー / バックエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 51名〜100名
よく見られているレビュー
株式会社FLINTERS / 吉田奈々
メンバー / バックエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 51名〜100名


