現時点でのDevinをフラットに評価する

ツール導入前の課題

• エンジニアの採用難易度の上昇

  • バックエンドは主にScalaで構築されており、近年は Scala エンジニアの採用難易度が年々上昇している。たとえ簡易なタスクしか遂行できなかったとしてもリソース不足は一定解消され、採用課題を根本から解決するサービスではないかと期待していた。

• AI時代の開発体験へのキャッチアップが不十分

  • まずは社内にAIエンジニアを迎え入れ、現在の技術水準やツールの品質を把握するところから始めたいと考えていた。

どのような状態を目指していたか

必要に応じてリソースを柔軟に増減できる状態を目指していた。仕様検討・設計フェーズは少数精鋭で集中的に進め、要件が固まり実装フェーズに入ったらDevinを積極的に活用し、短期間で実装からリリースまで完了できる組織に少しでも近づけられればと期待していた。

改善したかった課題はどれくらい解決されたか

新規プロダクトの開発においては一定の成果が出たと感じている。特にプロダクションコードを元にテストコードを作成するタスクは高確率で機能する。 ただし全体的に見るとエンジニアのリソース不足を補うほどのアウトプットの上昇は見られなかった。一部のエンジニアは継続的に1日1PR以上の活用度合いを示していたが、大多数のエンジニアはDevinを継続して利用することができていなかった。CursorやRooCodeなどと比べると、小回りが効きづらく、レスポンスが遅いという点に原因があるのではないかと考えている。

一方で、AI時代の開発を体験するという意味においては想定以上の効果を感じている。AIを活用することで非エンジニアとエンジニアの接続がしやすくなり、またその境界が薄れていくという体験は面白く、今後の開発プロセスを設計するうえで大いに役立つと感じた。

どのような成果が得られたか

導入当時は予測できていなかった、以下のユースケースにおいて効果を感じている。

• QA主導のホットフィックスフロー

  1. QAが不具合を発見
  2. Devinにタスク依頼 → 修正 PR 作成 → Vercelに自動デプロイ
  3. QAが確認
  4. エンジニアが最終レビュー

• アクセシビリティ改善の推進

  • デザイナーがDevinと対話しながら軽微なUI修正を行う

• オンボーディングパートナー

  • Ask DevinとDevin Wikiによる新規参入エンジニアのオンボーディングコストの削減

• タスク適性の見極めが難しい
  • 仕様が曖昧なタスクを渡すと、$10〜$20 相当のACUを消費してもPRが1本も出ないケースが頻発。
• 介入タイミングの迷い
  • 完全自律にこだわると品質が上がらず、かといって逐次口出しすると“ただの高価な補助ツール”と化してしまう。

• 非エンジニアがエンジニアリング領域に踏み出すためのツールとしては一級品。プロセス、体制の構築をセットで検討できるのであれば導入をおすすめできる
• 粒度の細かいタスクから試す（仕様が明確なバグ修正や UI 微調整が最適）
• “x 分停滞したら人が介入”など運用ルールを決める

より多くのステークホルダーにDevinを活用してもらえるようになれば、全体の効果はさらに高まると考えている。たとえば、カスタマーサポートからの仕様に関する問い合わせに対し、Devinを一次対応の窓口として活用することも有効な手段の一つなのではないかと思う。