みんなでDevin開発の現在地

はじめに

弊社ではカスタマーサポート、ロジスティクス、メディアなど開発部署以外のメンバーがDevinを活用してプロダクト開発を行っている点が特徴です。
この記事では実施している開発フロー、実績と現時点での限界と課題、過去の課題を説明します。

Devinを用いた開発フロー

開発フローはシンプルで、以下の手順に沿って進めています。
各工程を説明します。

1. PRDの作成

各部署のメンバーがPRD(Product Requirements Document)^[1]を作成します。
PRD作成はDevinのAsk Devinという機能を使用して行っています。

PRD作成までの簡易的な流れは以下のとおりです。

1. Ask Devinのチャット画面を開く
2. 指定のプロンプトを送ってPRD作成を開始
3. URLやスクショを共有しながら背景情報を提供
4. Ask Devinの質問に答えてPRDを段階的に構築
5. 受け入れ条件まで確認して最終版を生成

出力されるPRDのサンプル

1. 背景

廃止済みの旧サービスに関連するページ・導線・パンくずがプロダクト内に残っており、ユーザー混乱・SEOリスク・運用負荷が発生している。

2. 現状の課題

旧サービス向けのリンクやページが残存している

パンくずやナビゲーションに一貫性がない

旧URLがインデックスされ続ける可能性によるSEOリスク

管理画面の構造が旧仕様前提のままで保守しにくい

3. 目的

不要な機能・導線の整理によるプロダクト構造の健全化

必要な企画ページのみを残し、URL体系を再設計

一覧ページと詳細ページの構造に再整理し、保守性と将来拡張性を高める

4. 対象ユーザー

一般ユーザー（迷わず目的のページにたどり着ける）

運用・開発チーム（複雑化した構造を減らし保守性を確保したい）

5. 提供価値

適切に整理された導線と分かりやすいナビゲーション

サイト構造の一貫性向上

不要機能削除による保守コストの削減

旧URLの残存によるSEO悪影響の抑制

6. 対応方針（What）
   (1) 不要ページの削除

旧サービス配下のカテゴリ・ブランド・特集ページなど、運用不要な一連のページを削除

(2) 新しい構造の作成

企画一覧ページ /campaigns

企画詳細ページ /campaigns/{id}
※旧サービス配下の詳細ページは原則廃止し、新構造へ統合

(3) リダイレクト対応

/old-feature/* → /campaigns へ統合

旧詳細ページ /old-feature/.../{id} → /campaigns/{id} へ301リダイレクト
（IDが引き継げる範囲のみ）

(4) 内部リンクと文言の更新

旧サービスに関する文言・パンくず・UI内リンクを全て最新構造に合わせて更新

管理画面URLも現行体系に揃える

7. 受け入れ条件（Definition of Done）

旧サービス関連の導線・ページがすべて削除済み

/campaigns および /campaigns/{id} が正常に表示される

リダイレクトが正しく機能し、404が発生しない

パンくず・ナビゲーション・内部リンクが新構造に統一されている

SEO上問題となる旧URLの残存がない

2. Devinに依頼

1.で作成したPRDをGitHub Issueとして起票し、SlackからDevinへ実装依頼を送ります。

3. 動作確認

dev環境へのdeployもDevinが実施し、依頼者がdev環境での動作確認を実施します。
ここで期待する動作にならない場合は追加の指示をDevinに送ります。

4. PRレビュー

Devinが実装したPRのレビューを行います。ここからはエンジニアが担当します。
ここで修正が必要な場合もレビュワーがDevinにプロンプトを投げて修正します。
修正が多い、根本的な設計方針が適切でない場合はDevinで対応できる範囲外としてPRをcloseします。
CodeRabbitを入れており、botのレビューコメントは自動でDevinが対応します。

5. リリース

レビューを担当したエンジニアがリリースします。

実績

2025年6月19日のDevin導入開始から2025年11月19日までの実績は下記になります。
※アカウント名はマスクしています。

Avg Cost of Merge

マージされたPRが作成されたセッションの平均コストです。
平均$19.74です。エンジニアに依頼していたものをDevinが大部分肩代わりしてくれていると考えると安いと思います。が一概には言えません。

Merged PRs co-authored by Devin all time

Devinがco-authoredになったマージ済みプルリクエストの合計は137件でした。
5ヶ月で137件なので 137 ÷ (20 * 5) = 1.37/日 は多いように思います。
また27Contributorsのうち8割が開発部署以外のメンバーが作成したPRです。

作成されたPRのマージ率

クローズされているPRは複雑な改修や大きな改修、期待する振る舞いを詳細化できていなかったことにより、期待する動作にならなかったものが多いです。

効果

改修が進むようになった

最大の効果は、エンジニアの工数がボトルネックとなって停滞していた改修が進むようになった点です。また欲しい物が明確に分かっている(ここが難しくもある)方が指示だしすることで調整もとてもスムーズです。

実際に実装できた事例を下記に列挙します。

• 文字列の置き換え
• 既存のドメインモデルにシンプルなロジックの追加や変更
• ビジネスロジックの少ないシンプルなCRUDを実施するAPIの実装
• デザイン仕様が存在しない管理画面のUI変更
• 互換性の必要ない機能の削除

社内のステークホルダーのシステム理解が進んだ

副次的な効果ですが、Devinを介してPRD作成+実装+動作確認を行なってもらうことで要件の詳細化、開発のフロー、処理への理解が進み、人間を介した開発でもコミュニケーションがより円滑になりました。

現時点での限界と課題

大規模・複雑な開発はやはり難しい

一定規模を超える開発では、期待どおりの成果が得られないケースが多くあります。
トライしたが期待通りにならなかった事例を下記に列挙します。

• memoryやCPU負荷の改善
• 複数のAPIを組み合わせて実現する機能
• 既存機能のテーブル設計を含む根本的な改修

Devinに最も適したタスクは初級エンジニアレベルの難易度で、十分な指示があればインターンでも解決できるレベルのタスクが進められている^[2]ため、大規模または複雑な開発を進める場合はいかにタスクを平易で検証可能な形で分割できるかが重要になってくると考えています。

しかし一方で、タスクを分解できるということは、実装におけるシステム的な問題を理解できていることに繋がり、システムを理解することが必要になります。そのため、エンジニアの完全な代替としてのDevin活用は、まだ一定の距離があると感じています。

過去の課題

dev環境の破壊

dev環境はGitHub Actionsを通してdev用のbranchでpushされたイベントを検知してdeployを行なっていました。会社で共通の環境を使用していることもありDevinの実装した変更がdev環境とコンフリクトを起こした際に、force pushしてdev環境を壊してしまうことがありました。

こちらはDevinで制御するのではなく、GitHub側の設定でDevinからのforce pushを制限しました。その結果、ナレッジに記載している手順でdev環境へ反映してくれるようになりました。

ヒューマンエラーと同様に、望ましくない行動をシステム側で防ぐという方針が有効であると考えています。

検証までが大変だった

dev環境に都度上げていたので、デプロイ待ちと出力が期待通りではなかった場合に修正してまたdev環境にデプロイする必要がありました。時間がかかるのでlocal環境を各メンバー構築して素早く検証できるようにしました。みんなエンジニアにどんどん近づいています！

脚注

1. https://www.atlassian.com/agile/product-management/requirements

2. https://docs.devin.ai/get-started/devin-intro#what-are-devin’s-strengths