Skip to main content
戦略的ユースケースとは、ビジネス価値の高い大規模プロジェクトであり、それを分離可能で反復的なサブタスクに細分化できるものを指します。各スライスは 1 つの Devin の作業単位となるため、単純明快で（人間のエンジニアリング時間で 90 分未満）、かつインクリメンタルである必要があります。
要約 — Devin のユースケース要件:
  1. 大量の反復的なサブタスク（スライス）があること
  2. ジュニアエンジニアレベルの難易度のサブタスクであること
  3. サブタスク同士が分離されており、段階的（インクリメンタル）に実行できること
  4. 客観的に検証できるループ（仕組み）を持つサブタスクであること
  5. （推奨）他プロジェクトへの依存関係が最小限であること

​
必要な特性

Devin を戦略的に活用する際の最適なユースケースは、狭く深く ではなく、浅く広い ものです。 複雑でまったく新しい機能（たとえ繰り返しであっても）は、大規模な運用において十分な信頼性を確保できない可能性が高いです。
狭く深い vs 浅く広い の比較
横断的な単純変更（例: SonarQube の指摘事項）について大きなバックログがあると、それを横展開した際に非常に大きな ROI を生み出します。 水平方向の変更の図
スライスが単純であればあるほど、プロジェクト全体の信頼性は高くなります。

​
スライスのユースケース [重要]

マイグレーション、リファクタリング、モダナイゼーション、そしてテクニカルデットのバックログは、スライスに非常に適したユースケースです。たとえば、コードマイグレーションを例に考えてみましょう。 マイグレーションを互いに独立したスライスに分割し、それぞれのタスクを個別の Devin セッションで対応します。 Slicing use cases illustration

​
検証

スライスは、プロジェクト内の最小の独立した単位（ファイル、ノートブック、またはモジュール）であり、次の条件を満たす必要があります:
  1. 人間によるエンジニアリング作業が 90 分未満であること
  2. コード変更を検証する手段があること（テスト、ビルド、CI チェック、またはカスタム検証スクリプト）
各 Devin は、自分がタスクを正常に完了したかどうかを客観的に判断できなければなりません。検証を完了するまでは、詳細なスタックトレースやエラーログを使って反復を続ける必要があります。
各スライスは、依存関係や連携が必要なプラットフォームを過度に増やさないようにします。Devin が取り組む対象をコード変更に絞り込みましょう。 Backwards compatibility diagram 各スライスは 互いに独立して かつ 段階的 でなければなりません。Devin の並列性を活用し、移行は 1 スライスずつ順番に 完了させます。人間によるレビューの後、各 PR を順次 master にマージします。 Parallel execution visualization Devin のユースケース全体のモデル: Overall model diagram Devin は個々のスライス単位で可能な限り高い信頼性を持たなければなりません。そうすることで、何千ものスライスを並列実行しても、スケール時の高い信頼性を維持できます。誤り率がわずかでも、大規模にスケールしたときには多くの誤った変更を生むおそれがあります。

​
顧客にご用意いただきたいもの

  • 各スライスの各ステップに関する明確な説明（エンドツーエンドのプロセスを詳細にまとめたドキュメントや動画が特に有効です）
  • コード変更のビフォー／アフターの複数の例（入力／出力ペア）
  • 各スライスで必要となるすべての依存関係に対して Devin に付与されたアクセス権

​
例

継続的なテクニカルデット対応タスク（例: PR レビューや QA テスト）も、スライスに分割できるのであれば、有力なユースケースになります。
マイグレーション、モダナイゼーション、リファクタリングは、段階的に進められる場合、Devin にとって強力なユースケースです。リポジトリ全体を同時に新しいシステムへ移行する必要があり、スライスごとに順次進めることができないマイグレーションは推奨されません。
参考資料: Nubank Migration Case Study