プロダクト開発部でTUNAGの開発をしているhisaです。
私たちの開発チームでは、プロダクトをより良く育てていくために、日々の開発の進め方やチームの体制について、試行錯誤を重ねてきました。
ただ、新機能の開発や日常的な対応を優先する中で、「手を入れたいのに後回しになってしまう」タスクが少しずつ積み上がっていく感覚もありました。
そうした状況を見直し、開発の質とスピードのバランスを取り戻す一手として、私たちはDevinの導入に踏み切りました。
この記事では、Devinをチームに迎えてからの変化や、活用における工夫についてご紹介します。
Devin導入の背景
プロダクトを継続的に成長させていくためには、機能開発だけでなく、基盤の見直しや細かな改善対応といったタスクにも継続的に取り組んでいく必要があります。 たとえば、
- プロダクト全体のリアーキテクチャ
- ライブラリアップデート（影響範囲の調査含む）
- 社内やお客様から上がった改善アイテム
こうしたタスクは、いずれもプロダクトの健全性やユーザー体験に関わる重要なテーマですが、どうしても日々の開発サイクルの中では優先度が上がりにくく、着手のタイミングを逃してしまいがちです。
私たちは、これらのタスクを「後回しにしない」ためだけでなく、チーム全体としての開発力を底上げし、より本質的な課題に集中できる体制をつくる一手としてDevinを導入しました。
Devinを使いこなすための5つのTips
1. タスクは10〜15分で完了する粒度に分割する
長時間タスクをそのまま渡すと
- 作業の途中で認識がズレてしまう
- 関連ファイルの参照漏れや飛躍した実装が起きる
- 要件を誤解したまま進行してしまう
といったリスクが高くなります。 そのため、タスクは「遅くとも15分以内に終わる」ことを目安に分割しています。
2. 実装方針は必ずテキストですり合わせる
Devinは仕様を聞かずに実装を始めることがあります。 実践しているのは、PRではなく、テキストベースで方針のすり合わせを行うこと。
Issue〇〇の対応をして欲しいです。 実装前に実装方針をIssueのコメントに記載してください。 ---> 実装方針をコメントに記載しました。 Buttonコンポーネントはすでに〇〇で実装されています。修正お願いします。 ---> 修正案をコメントに追加しました。 実装提案確認しました。 実装のボリュームが大きくなってきたので、Issueを小分けにしていただけますか？ ---> ご提案いただいた通り、以下の3つのIssueを作成します。 では1の実装からお願いします。
といった流れを踏んでから作業を任せています。
3. DevinにIssueを書かせる
Issueなどがない場合、いきなり作業させるのではなく、まずIssueを書かせる運用にしています。
- 背景
- ゴール
- 作業内容
上記を自分で整理させ、そのIssueをそのまま着手させることで実装精度が安定しました。
4. 「やらないこと」を明確にする
Devinは善意で
- リファクタリング
- 不要なテストの追加
- エラーハンドリングの強化
など、依頼していない作業をすることがあります。 例えば「今回はテストは追加しないで」「リファクタリングは不要」など、やらないこともセットで指示 するようにしています。
5. 作業ログは逐次出力させる
作業中に「何も言わずに進めてしまう」ことがよくあります。
常に「今、何をやっているか説明して」「進捗を逐次共有して」とお願いすることで、進捗の見える化と、早期の異常検知ができています。
Devinを活用したタスク例
リアーキテクチャ
現状整理・リファクタ方針作成・Issue分割・実装・テスト
ライブラリアップデート
Release Note読解・プロダクト内の利用箇所特定・影響レポートの作成
改善アイテム
社内やお客様から上がっていた改善アイテムの実装
Devinが特に得意だったタスク
振り返ってみると、下記のように インプットとアウトプットのイメージが明確なタスクは、特に安定して対応できるようになってきました。
- API実装
- バリデーション追加
- ロジック単体の改善
- 設定・スクリプト系の作業
一方で、デザインやUI実装など、Figmaを読む前提のタスクは現状ではそこまで得意ではありません。 BoltなどはFigmaを読み取り対応していますが、Devinも今後は対応するのではないかと期待しています。
よくあった失敗と改善
| 課題 | 原因 | 改善策 |
|---|---|---|
| 勝手に設計変更 | 方針すり合わせ不足 | 事前にテキストで確認し、ナレッジ化 |
| 実装精度の低下 | タスクが重すぎた | 10〜15分単位に分割 |
| 同じ質問を繰り返す | コンテキストの欠落 or 曖昧な依頼 | 前提・背景・制約条件を毎回セットで共有し、必要なら「ナレッジとして記憶させる」 |
| 余計な作業を実施 | やらないことを指示していない | やらないことも明示する |
Devinに実際に渡したIssue例
# Issue: ラジオボタンのキーボード操作に対応 ## 内容 現在のラジオボタンがキーボードで正しくフォーカスされない。アクセシビリティ改善のため、Tabキー操作での移動＆選択に対応したい ## やること - components/RadioGroup/index.tsx を修正 - role=radiogroup、aria-checked などの属性を適切に付与 - Tab / Shift+Tab / Enterキー で操作可能にする ## 補足 - スクリーンリーダーでの読み上げ確認は不要（別Issueで予定） ## やらないこと - ラジオボタンのデザイン変更 - フォームロジックの修正
Devin導入の効果
着手のハードルが高かったタスクにも手が伸びるように
「気になっていたけれど後回しになっていた」タスクが少しずつ片付いていくようになりました。
- 小規模な改善Issue
- ライブラリのアップデートと影響調査
- デッドコードの整理や命名統一 など
Devinを活用することで、こうしたタスクに手が届きやすくなり、コードベースの健全性向上にもつながっています。
重ための開発にも踏み込みやすくなった
- プロダクト全体のリアーキテクチャ方針の策定・実装
- モジュール単位での構成見直し
- レガシーな一括バッチの分解・再構成
Devinにまず「現状把握」→「方針案の提示」→「タスクへの分割」までを任せることで、全体像がつかみやすくなり、チームとして動き出すための一歩が軽くなりました。
PR作成数が約1.5倍に増加
定常的な改善タスクをDevinに任せられるようになったことで、メンバーはより注力すべき領域に集中しやすくなりました。 単純なPR数の増加だけでなく、「対応が早くなった」という声もあり、チーム全体のリズムが良くなってきた感覚があります。
「まずDevinに任せてみる」が自然な選択肢に
- 「ちょっと時間かかりそうなタスク」を見つけたら「まずDevinに投げてみる」が自然なフローに
- Slack上でも「このIssueDevin向きかも？」というやり取りが増加
文化として根付いたと感じられるのは、大きな成果のひとつでした。
まとめ
Devinは、すべてを自動で解決してくれる存在ではありません。 ですが、タスクの粒度を整え、進め方を丁寧に伝えることで、着実に動いてくれる「チームの一員」になり得ます。
導入したことで、これまで着手しにくかったタスクにも少しずつ向き合えるようになり、
さらに大きな変化としては、人が「人にしかできないこと」に集中する時間が増えてきたことがあります。
たとえば、プロダクトの方向性を考える、設計を詰める、チームで議論するといった創造的な時間です。
そうした本質的な領域に、より多くのリソースを割けるようになったことはチームにとって大きな前進でした。
AIに任せるところは任せて、人は人としての強みを発揮する。 Devinは、そのバランスを取り戻すための、ちょうど良いきっかけになってくれています。
