✨

Linear と Devinを活用したリファインメント手法の紹介

Shinya

2025/07/01に公開

 はじめに
こんにちは！J-CATの山田です。
ここ2~3週間、zennではClaude Codeの話題で持ちきりですね！もれなく弊社でも開発チーム全員がClaude Codeを使っています。（会社からMaxアカウント配布）
Claude Codeは実装の速度を劇的に加速してくれていますが、多くの会社では、他部署などとも連携しつつプロダクトを作り上げていく以上、実装に至るまでの要件の定義・整理・確認など実装以外の要素が欠かせません。
弊社では、開発にスクラムを採用しており、要件整理・確認と見積もりを行う重要なイベントであるリファインメントにおいて、Devinがいい感じに補助の役割を担ってくれているので、今回はその紹介になります。
ここにきてDevinの話かいっって感じですが、実装の爆速化ティップスの記事が多いので、ここらでその手前のプロセスの話も悪くなかろうということで書いています。
!この記事はAIを使いながら書きました

 要点まとめチケットの型を作って、それに忠実に従って記述する
チケットが完成次第、PO（プロダクトオーナー）がDevinラベルをつけてタスク整理・影響範囲確認してもらう
リファインメント時に確認しながら議論を進める

 スクラムにおけるリファインメントの課題
リファインメントでは、以下の様な課題がありました。

仕様確認漏れ・考慮漏れ
機能追加や変更における細かい確認観点が一部漏れる
結果として、実装時に確認が必要になったり、後から考慮漏れに気づき手戻りが発生したりと、開発生産性に影響が出る


影響範囲の把握の手間
コードのどの箇所に影響が出るのかの確認を、その領域を熟知している人間に頼ることになる場面がある
影響範囲の確認自体も多少の時間を費やしてしまうことがある


 Linear × Devin によるアプローチ
Linearには、Devinのインテグレーションが提供されており、これを使うことで、チケットの内容確認、既存コードの確認、変更案の提案を行なってくれます。（JIRAにもインテグレーションが提供されています）

 0. Devinの設定画面からLinear Integrationを有効にする（画面はすでに有効化済み）

 1. チケットの構造化
チケットは見積もり可能な状態まで分解することを徹底しています。また、チケットの型はDevinが登場する前から定型化しており、結果としてAIにとっても読み取りやすい型が作れていたなと思います。

ゴール
「誰が、何のために、何をしたいのか」を簡潔にまとめる


合格基準
このチケットを完了とするために達成していなければいけない条件
仕様の箇条書きと、Figmaリンクやスクショを記載


メモ
リファインメント中にPOや開発チームで出てきた質問とその答えのメモ
実装に入る際に、事前質問情報を確認しながら考慮事項を確認できる


タスク
どのリポジトリで何をするのか簡潔に記載
リファインメントでの見積もりから着手まで時間が空くことがあるので、着手時にやることをすぐに思い出せる様にするため


他部署連携事項
リリース前までに他のチームに連携する必要がある場合に記述
社内オペレーションの変更など、準備が必要なケース




実際のチケット例

 2. Devinによる事前分析
POがチケットを作り終えた段階で、対象チケットに「Devin」ラベルを付与するだけです。
Devin Integrationは、元々そのままタスクとしてDevinに実装を投げるために作成されている機能のため、Devinなりの理解や実行プランが記述されます。

タスク内容の確認（Devinなりの理解を言語化）
タスク遂行にあたって不明点があれば列挙してくれる


コード影響範囲の特定
変更対象となるファイルやモジュールの洗い出しをしてくれる


実装アプローチの提案
どのファイルにどんな変更を加えるか事前確認として書き出してくれる



実際にDevinが洗い出してくれた例（仕様・技術観点での確認）

 3. リファインメントでの活用
リファインメントは以下の流れで進行します。

チケット内容をPOから共有
チケットの背景・ゴールと、合格基準について


開発メンバーからの質疑（Devinのタスク確認欄をチェック）
仕様の背景・目的再確認や、仕様の細かい詰め、改善の提案など


見積もりのためのタスク分解（Devinの既存コード確認をチェック）
どのリポジトリでどの作業をするのか分解

タスクごとにポイント付け
他部署連携事項（あれば）

 導入効果
初めて間もないプロセスなので、定量的な成果として語るのは難しいですが、定性的な変化としては以下の様なものがありました。

確認漏れの減少・リファインメントの役割最大化
Devinによるチェックにより、細かい仕様観点の見落としが減った
結果として、リファインメントの本来の役割をより果たせるようになった


見積もり精度の向上
影響範囲が事前に明確になることで、見積もり時のタスク分解が楽になった


 まとめ
Linear × Devin の組み合わせにより、既存のリファインメントのプロセスをほとんど変えることなく質を向上させることができました。
これまでは、Devin Integrationの機能は実装時に使用していたのですが、少し見方を変えると実装前の段階でも活用できるというのはいい気づきでした。

 今後影響範囲の確認やタスク整理はAIが得意な分野なので、LinearのAPIを使ってClaudeでも同じようなことができる様にしたいなーとかを考えています。

 最後にJ-CAT株式会社では、AIとの新しい協働スタイルを模索・構築・改善するサイクルを日々回しています。これ以外にも、どんな取り組みがあるのか？などご興味を持っていただければ、是非、一度話を聞きに来てみてください！