アプリケーション開発において、Devin をどう活用するか？

参考になった

レビュー投稿日の情報になります

株式会社FLINTERS / 吉田奈々

メンバー / バックエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 51名〜100名

最終更新日2026/03/23投稿日2026/03/27

利用プラン	ツールの利用規模	ツールの利用開始時期	事業形態
Team プラン	10名以下	2025年10月	B to B

導入の背景・解決したかった問題

レビュワーの負担増
- 半年でプロジェクトメンバーが大幅に増え、ドメイン知識を知っているメンバーが少ない状態でした。
- コードレビューをするメンバーに偏りがある状態を解消したいと考えました。
  - 初回コードレビューを Devin に任せ、Devin に指摘された部分を解消した状態でレビュー依頼をするようフローを変更しました。
ドメイン知識の習得に時間がかかる
- Notion / DocBase などドメイン知識や仕様書がバラバラになっている状態でした。
- Devin と GitHub を連携し、コードを読ませてアプリの構成を把握するようにしました。

レビュワーの負担増
- レビュワーにレビューを依頼する前に、Devin にレビューをさせることによって自分では気づかないポイントが明確になり、修正が減ったなと感じました。
- チケット対応者 / レビュワー間のやり取りが減少し、レビュワーの負担が減ったかなと感じています。
ドメイン知識の習得に時間がかかる
- コード上 / GitHub リポジトリ上の仕様については、まず Devin で確認したうえで、該当するコードを自分で読むようにした結果、コードベースや GitHub リポジトリの中で、どこにどの機能が実装されているのかを把握するまでの時間が短縮され、理解がスムーズになりました。
- 作業時間に余裕が生まれたことで、より詳細な設計の検討やコードの書き方に時間を割けるようになりました。その結果、セキュリティ上の懸念や、既存システムに影響を与えないかといった観点についても、より細かく確認できるようになりました。

レビュワーの負担軽減
- 事前にコードの仕様確認や自己レビューを行うことで、基本的な指摘事項が減り、レビュワーの確認工数を削減することができました。
詳細設計の精度向上
- コード理解や仕様確認にかかる時間を短縮できたことで、詳細設計の検討により多くの時間を割けるようになりました。その結果、セキュリティ上の懸念や既存システムへの影響などについても、より細かい観点で確認できるようになりました。

会社側ですでに導入推進が進められていたため、特に説得は不要でした。そのため、どう使いこなすかということを考えました。

このように、あらかじめ作業内容に応じた Playbook を作成しておくことで、レビューの観点や生成されるレビューコメントの品質を一定に保つことができます。

新しい機能や既存のシステム構造を理解する際に、Devin を使ってコードの説明や処理の流れを整理しています。具体的には、

現在関わっているプロダクトではコスト削減の取り組みを行っており、その中で Devin を利用して簡単な調査用スクリプトを作成しています。例えば以下のような用途です。

このようなスクリプトを作成することで、調査作業の自動化や効率化を行い、どのリソースのコストを削減すべきか判断するための時間を確保しています。

プロジェクトや組織に関する知識を保存し、Devin が参照できるようにする機能です。
コードベースやプロジェクトの背景、開発ルールなどを Knowledge としてまとめておくことで、Devin がそれらを理解したうえで作業を行えるようになります。
Knowledge には、以下のような情報を整理しておくことができます。
- リポジトリのディレクトリ構成
- API の役割やデータフロー
- データベース設計
- プロジェクト固有の用語

システムの構造やドメイン知識を Knowledge に整理しておくことで、コード理解やレビューの精度を高めることができます。