タイミーにおける Devin 導入レビュー - 自律性の高さを活かした業務生産性改善アイデア集

参考になった

レビュー投稿日の情報になります

株式会社タイミー / bary822

バックエンドエンジニア / 従業員規模: 1,001〜5,000名

最終更新日2026/04/01投稿日2026/04/08

利用プラン

ツールの利用規模

ツールの利用開始時期

事業形態

Team

51名〜100名

2025年2月

B to B

B to C

利用プラン	Team
ツールの利用規模	51名〜100名
ツールの利用開始時期	2025年2月
事業形態	B to B B to C

アーキテクチャ

アーキテクチャの意図・工夫

「導入の成果」で説明する Flaky Test 自動修正システムの全体図です。

GitHub Actions で実行されたCI(テスト)データを Datadog に送信し、Flaky Test 発生時に Datadog Workflow Automation を通じて API 呼び出しにて Devin セッションを起動。修正 Pull Request 作成までを自動化しています。

開発者は特に意識せずとも自動作成される Pull Request をレビュー、マージしていくだけで CI の信頼性を維持できるシステムになっていることがポイントです。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

巨大な Rails モノリスであるため、開発はパッケージ／ドメイン単位で分担されており、担当外の領域に変更が及ぶと、仕様把握・影響範囲の洗い出しに時間がかかっていました。

また、慢性的に人手不足だったためコーディング、コードレビュー、運用など様々なレイヤーで「やりたいけど工数の問題で優先度が上げづらい」タスクが積み上がっていました。

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

特定の課題を解決すると言うよりは、まず導入して開発者が自由に使い倒すことで、業務生産性に役立つ利用方法を探索したい、という狙いがありました。

比較検討したサービス

Cursor
Claude Code
GitHub Copilot

導入の成果

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

仕様把握や影響範囲の洗い出しに関しては、当初想定していた以上の効果がありました。特に複数レポジトリ横断で調査を行えるため、例えば API サーバーとモバイルアプリのレポジトリを横断して調査して、エンドユーザーにどのような影響(画面の見た目や挙動)があるかまで把握できるようになりました。また、日常の小さなタスクに関しても Slack などで話題に上がった時に「一旦タスクだけ作って時間がある時にやる」のではなく、そのまま Devin を呼び出して対応してもらうという選択肢が取れるようになったことで、気軽に対応できるようになりました。

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

導入当初にある程度予想していた活用方法を超えて、様々な分野で開発活動への組み込みが行われました。

特に次の領域で大きな成果が見られました。

プロダクトの精通していないドメインやレポジトリを横断した調査、実装

コードオーナー外のパッケージ(ドメインごとに分割されたコードベースのまとまり)を横断した調査、実装を行いやすくなりました。巨大なコードベースの中で「どこから読めばいいか」を探す時間が短縮され、オンボーディングや緊急対応時の初動が速くなったほか、ドメイン知識が分散している状況でも、調査結果をそのまま実装に落とし込みやすくなりました。
Slack から気軽に小さいタスクを実行

Slack での会話の流れからそのままタスクを依頼できることで、コンテキストスイッチのコストが下がり、「そこまで時間がかからないけど優先度が上がらずに着手できないタスク」を積み残しにしにくくなりました。例としては、エッジケースなユーザー問い合わせ対応や組織構造の変化に伴う Terraform への構成反映など、対話しながら進められる作業が定着しやすい形になりました。依頼のハードルが下がることで、属人的だった小さな改善がチーム全体に広がりやすくなった、という効果も出てきています。
Flaky Test 自動修正システム

Datadog に蓄積された CI のテストログからFlaky Testを検知したタイミングで Devin にそのコンテキストを渡すことで、人手が空くまで放置されがちだったFlaky Testの切り分け・PR作成を自動化できました。開発者はレビューと修正の妥当性判断に集中できるため、修正コストを最小化しつつ CI の信頼性維持を実現できています。詳細は弊社テックブログ記事を参照。
一次情報をハイライトしたレポート出力

何らかのメトリクスやログを観察、集計して洞察を得るような取り組みにおいて、それらミクロな一次情報を初手で人間が見るのではなく、まずはAIにレポートを作成してもらい、気になった部分を人間が深堀りするというアプローチが根づきつつあります。例えば Datadog に集約されたインフラメトリクスから特定の期間内における重要な変化をAIがレポートにまとめて、それをベースに効率的に課題の洗い出しや改善アイデアを出すといった活動が行われるようになりました。
タイミーのデザインシステムに則った簡単プロトタイプ作成

デザインガイドライン + 実装コードを横断参照し、リアルなプロトタイプを生成します。例えば、「管理画面のホーム画面を新しいデザインで作成して」と Devin に依頼するだけでプロトタイプを作成し、20分後にはプロトタイプが GitHub Pages にホスティングされています。

導入に向けた社内への説明

上長・チームへの説明

まず導入してどのような課題解決に役立てられるか考えてみよう、という方針だったため、どちらかというとトップダウンで導入が決まりました。費用対効果は一旦気にせずにまとまった予算を割いて一定期間運用し、その効果があったかどうかを後から判断するという流れで進んでいました。

特定のツールに限定することで課題解決の探索可能性(AIツールでどのような課題をどうやって解決できるか)を狭めたくなかったため、結果的に Devin を含め比較検討したサービスは全て導入しました。

活用方法

よく使う機能

Sessions/Ask

これが最もよく使う機能です。特定の機能の仕様や振る舞いを調査、あるいは実装することが主なユースケースです。他のAIエージェントツールと比較すると、特に意識せずともレポジトリ横断でタスクを実行できることに優位性があると感じています。
Knowledge

ユビキタス言語の遵守や commit/Pull Request の書き方のお作法など、イチ開発者として守ってほしいルールや知っておいてほしい前提知識をまとめています。また、特定の作業(例えば Flaky Test 修正)を行う時の手順やルールを明文化しています。
Schedules

特定の期間内に起こった出来事やメトリクス・ログの変化をレポートとして Slack に出力するプロンプトをスケジューリングしています。
DeepWiki

社内外のよく使うレポジトリを登録しておき、機能実装やバグ修正時の調査に役立てています。あいまいな指示で高い精度の回答が得られるので助かっています。