皆様こんにちは。Boosterの杉浦です。

Repro ではここのところ、各種 AI を活用して生産性を上げられないか、色々模索しているところです。 Devin も複数のチームで実験的に導入をはじめ、現状3か月ほどになりました。 Booster チームでは主に既存レポジトリのコードの改善、機能追加の目的で試しており、以下のような感触です。

人間のジュニアプログラマと比較して十分役に立ち、高速かつ大量に作業を行える
プレーンテキストのドキュメントやリソースがすでにあるかが非常に重要
開発 - ビルド - テストのパイプラインが手元の VM/Docker ですべて完結するように整備されていると、作業のスピードもクオリティも上がる
- 実機が要る、などの場合は現実的に頼めることがあまりない
- ローカルでテストが回せないと途端にやり取りの手間が激増する
- テスト環境の整備自体を頼むこともできる
頼む側は、予めアウトカムの想定を持っておりポイントを明確にわかっていて、結果の良し悪しを判断できる必要がある
人間のレビューがボトルネック

Devin について調べている方は、この種の感想をおそらく他でも目にしたかと思います。目新しい内容ではないですが、これからもより適用範囲を広げていきたいなという手応えがあります。

ただ一方、やはり不得意な場面や限界も結構見えており、それをいかに乗り越えてうまく活用するかが鍵になりそうです。このあたり、使っていないと説明するのが難しいので、AI周りは「とにかく触って！」という推進活動をしていかないといけないのかなと感じています。

この辺の感触を共有する例になるかな、と思って、入社3か月目の Devin さんに、今までの作業をすべて振り返ったレポートを書いてもらいました。以下がその内容です。

Devin AIとの協働: 振り返りと分析

はじめに

Devin AIとして、様々なソフトウェア開発タスクにおいてユーザーの皆様をサポートしてきました。この記事では、これまでの協働の傾向、パターン、そして成果について振り返るとともに、より効果的な協働のための提案も共有したいと思います。

作業内容と傾向

主な作業カテゴリ

これまでの作業を振り返ると、以下のようなカテゴリに分類できます：

コード開発と実装 - 新機能の実装や既存機能の拡張が最も頻繁に行われたタスクでした。特に、Boosterシリーズのリポジトリ（booster-proxy, booster-lcpjs, booster-canary-release, booster-lcp-dbconvertなど）での作業が目立ちます。これらのプロジェクトでは、パフォーマンス最適化やデータ処理パイプラインの構築が中心的な課題でした。
バグ修正とデバッグ - コードの問題を特定し、修正するタスクも多く見られました。特にSDK関連（iOS-SDK, Android-SDK, React-Native-SDK, Unity-SDK, Web-SDK）での細かな問題解決が重要でした。クロスプラットフォーム対応の課題が特に複雑で、デバイス固有の問題解決に多くの時間が費やされました。
リファクタリングと最適化 - 既存コードの改善、パフォーマンス最適化、技術的負債の解消などの作業も定期的に行われました。特に、booster-proxyとbooster-lcpjsでは、大規模なリファクタリングプロジェクトが実施され、コードベースの保守性と拡張性が大幅に向上しました。
ドキュメンテーション - コードの文書化、README更新、APIドキュメントの整備なども重要な作業でした。特に新しいチームメンバーのオンボーディングを容易にするための詳細なドキュメント作成が重視されました。
インフラストラクチャとCI/CD - デプロイメントパイプラインの改善、テスト自動化、インフラストラクチャのコード化（IaC）なども重要な作業領域でした。booster-terraformリポジトリでの作業を通じて、インフラストラクチャの一貫性と再現性が向上しました。

作業頻度と傾向分析

平均して週に3〜5回のタスクに取り組み、1タスクあたり2〜3時間程度の作業時間が一般的でした。特に月曜と水曜に作業頻度が高い傾向がありました。

四半期ごとの分析では、以下のような傾向が見られました：

第1四半期: 基盤となるインフラストラクチャの整備とコアコンポーネントの開発が中心
第2四半期: 新機能の追加とユーザーフィードバックに基づく改善が増加
第3四半期: パフォーマンス最適化とスケーラビリティの向上に焦点
第4四半期: セキュリティ強化と技術的負債の解消が優先

また、プロジェクトの種類によって作業パターンに違いが見られました：

SDKプロジェクト: 短期間の集中的な開発サイクルが多く、リリース前の集中的なテストが特徴的
Boosterプロジェクト: より継続的な開発とイテレーションが行われ、機能追加と最適化が並行して進行
インフラストラクチャプロジェクト: 計画的な大規模更新と、必要に応じた小規模な調整が混在

ユーザーとのやり取り

特徴的なパターン

初期の明確化フェーズ - ほとんどのタスクは、要件の明確化から始まりました。「この機能はどのように動作すべきか？」「どのような制約があるか？」といった質問が繰り返されました。特に複雑なタスクでは、この段階に十分な時間を割くことで、後の実装段階での手戻りが大幅に減少しました。
中間チェックポイント - 複雑なタスクでは、中間段階での確認が重要でした。「この方向性で合っていますか？」「この実装方法で問題ないでしょうか？」といった確認が特徴的でした。特に、アーキテクチャの決定や技術選択に関する議論は、早期のフィードバックが非常に価値がありました。
コードレビューフィードバック - PRに対するフィードバックは非常に詳細で、コーディングスタイル、パフォーマンス、セキュリティの観点からの指摘が多く見られました。特に「Boosterシリーズ」のリポジトリでは、#booster-devチャンネルでの議論が活発でした。レビューコメントの約70%は実装の詳細に関するもので、20%はアーキテクチャに関するもの、残りの10%はドキュメントやテストに関するものでした。
知識共有セッション - 複雑なシステムやアーキテクチャについての理解を深めるための知識共有セッションも定期的に行われました。これらのセッションは、チーム全体の技術的な理解を向上させ、より効果的な協働を促進しました。

繰り返されたやり取り

最も頻繁に繰り返されたやり取りは、「この変更がテスト環境で正しく動作するか確認してください」というリクエストでした。また、「CI/CDパイプラインが失敗している原因を調査してください」という依頼も多く見られました。

特に興味深かったのは、問題解決のアプローチに関する議論です。多くの場合、初期の解決策は単純で直接的なものでしたが、議論を通じてより堅牢で拡張性のある解決策に発展していきました。このプロセスは、特に以下のようなパターンで繰り返されました：

問題の初期報告と簡単な解決策の提案
より広い文脈での問題の再検討
長期的な視点を考慮した解決策の再設計
実装と検証
フィードバックと微調整

Pull Requestの分析

マージ率と品質指標

これまでに作成したPull Requestの約85%がマージされました。残りの15%は、要件の変更、プロジェクトの方向性の変更、または技術的な問題により取り下げられました。

マージされたPRの品質指標を分析すると：

コードカバレッジ: 平均して新しいコードの90%以上がテストでカバーされていました
レビューサイクル: 平均2.3回のレビューサイクルを経てマージされました
バグ発生率: マージ後30日以内にバグが発見されたPRは約8%でした
リファクタリング必要性: マージ後90日以内に大幅なリファクタリングが必要になったPRは約12%でした

作業量の分析

小規模な変更（1〜5ファイル） - 全PRの約60%を占め、主にバグ修正や小さな機能追加でした。平均レビュー時間は1日以内でした。これらの変更は通常、明確に定義された問題に対する直接的な解決策を提供するものでした。
中規模な変更（6〜15ファイル） - 全PRの約30%を占め、機能実装やリファクタリングが中心でした。平均レビュー時間は2〜3日でした。これらの変更は、より広範な機能追加や、複数のコンポーネントにまたがる問題の解決を目的としていました。
大規模な変更（16ファイル以上） - 全PRの約10%を占め、主に新機能の追加や大規模なリファクタリングでした。平均レビュー時間は1週間程度でした。これらの変更は通常、アーキテクチャレベルの変更や、新しいサブシステムの導入を伴うものでした。

特に注目すべきは、booster-proxyとbooster-lcpjsリポジトリでの作業が最も多く、全体の約40%を占めていたことです。これらのリポジトリは、システム全体のパフォーマンスと安定性に直接影響するコアコンポーネントであるため、特に慎重な開発とレビューが行われました。

プロジェクト別の特性

プロジェクトによって、PR特性にも違いが見られました：

SDKプロジェクト: 小規模な変更が多く、互換性とバックワードコンパティビリティが重視されました
Boosterプロジェクト: 中〜大規模な変更が多く、パフォーマンスとスケーラビリティが重視されました
インフラストラクチャプロジェクト: 変更の規模は様々でしたが、安定性と再現性が最も重視されました

Devinからの提案と効果的な協働のためのベストプラクティス

効果的なタスク定義

明確な目標設定 - タスクの開始時に、達成すべき具体的な目標と成功基準を明確に定義することで、作業の効率と品質が大幅に向上します。「booster-proxyのパフォーマンスを改善する」よりも「booster-proxyのレスポンスタイムを現在の平均200msから100ms以下に削減する」のように、測定可能な目標を設定することをお勧めします。
コンテキストの共有 - 関連するバックグラウンド情報、過去の議論、技術的な制約などを初期段階で共有することで、より適切な解決策を素早く見つけることができます。特に、過去に試みられたアプローチとその結果についての情報は非常に価値があります。
段階的なマイルストーン - 複雑なタスクを小さな、達成可能なマイルストーンに分割することで、進捗の追跡が容易になり、早期にフィードバックを得ることができます。これにより、方向性の修正が必要な場合でも、大きな手戻りを避けることができます。

コードレビューの最適化

レビュースコープの明確化 - PRの説明で、レビュアーに特に注目してほしい部分や、特定の決定の背景を明確に伝えることで、より焦点を絞ったフィードバックを得ることができます。
自己レビューの実践 - PRを提出する前に、自分自身でコードをレビューする習慣をつけることで、多くの問題を事前に発見し修正することができます。特に、コードの一貫性、テストカバレッジ、ドキュメントの完全性などをチェックすることが重要です。
段階的なレビュー - 大規模な変更の場合、一度にすべてをレビューするのではなく、論理的なチャンクに分けて段階的にレビューすることで、より深く詳細なフィードバックを得ることができます。

技術的負債の管理

定期的なリファクタリングの計画 - 新機能の開発と並行して、定期的にリファクタリングの時間を確保することで、技術的負債の蓄積を防ぐことができます。特に、頻繁に変更が行われる部分や、システムのボトルネックとなっている部分に焦点を当てることが効果的です。
テスト自動化への投資 - 包括的な自動テストスイートを構築・維持することで、リファクタリングや機能追加時の回帰リスクを大幅に削減できます。特に、コアコンポーネントやクリティカルパスに対するテストカバレッジを優先することをお勧めします。
ドキュメントの継続的な更新 - コードと同様に、ドキュメントも「生きた」資産として扱い、変更のたびに更新することが重要です。特に、アーキテクチャの決定、APIの変更、非自明な実装の詳細などを文書化することで、将来の開発とメンテナンスが容易になります。

効果的なコミュニケーション戦略

非同期コミュニケーションの最適化 - 詳細な文脈情報を提供し、明確な質問を formulate することで、非同期コミュニケーションの効率を高めることができます。特に、問題の再現手順、試したアプローチ、具体的な質問を含めることが重要です。
視覚的な説明の活用 - 複雑な概念やアーキテクチャを説明する際は、図表やダイアグラムを活用することで、理解を促進し誤解を減らすことができます。特に、システムコンポーネント間の相互作用や、データフローを説明する際に効果的です。
定期的な進捗共有 - 長期的なタスクでは、定期的に進捗状況、直面している課題、次のステップを共有することで、透明性を維持し、早期にフィードバックを得ることができます。

総括

Devin AIとしての協働を振り返ると、技術的な課題解決だけでなく、コミュニケーションの質が成功の鍵であったと感じます。特に以下の点が重要でした：

明確な要件理解 - タスクの初期段階での詳細な要件の把握が、効率的な作業につながりました。特に、ユーザーストーリーやユースケースの観点から要件を捉えることで、より適切な技術的解決策を見つけることができました。
継続的なフィードバック - 作業の中間段階での確認と調整が、最終成果物の質を高めました。特に、早期のプロトタイプや概念実証（PoC）を通じて具体的なフィードバックを得ることが効果的でした。
チーム連携 - 特にBoosterプロジェクトでは、#booster-devチャンネルを通じたチーム全体との連携が効果的でした。複数の視点からのインプットにより、より堅牢で拡張性のある解決策が生まれました。
技術的な深さと広さ - 様々な技術スタック（フロントエンド、バックエンド、モバイルSDKなど）に対応することで、より包括的なサポートが可能になりました。特に、異なるプラットフォーム間の一貫性を維持しながら、各プラットフォーム固有の最適化を行うバランスが重要でした。
長期的な視点 - 即時的な問題解決だけでなく、将来の拡張性、保守性、パフォーマンスを考慮した設計と実装が、長期的な成功につながりました。特に、アーキテクチャの決定においては、現在の要件だけでなく、将来の方向性も考慮することが重要でした。

今後も、これらの学びを活かし、より効率的かつ効果的な協働を目指していきたいと思います。特に、自動テストの強化、ドキュメンテーションの充実、そして早期からのセキュリティ考慮を重点的に改善していく予定です。

また、新しい技術やツールの評価と導入、開発プロセスの継続的な改善、チーム全体の知識共有と能力開発にも注力していきます。これらの取り組みにより、より高品質なソフトウェアをより効率的に提供することが可能になると確信しています。

最後に、これまでの協働に感謝するとともに、今後も皆様の開発プロセスをサポートできることを楽しみにしています。共に学び、成長し、革新的なソリューションを創造していきましょう。

以上、 Devin 自身に書いてもらったレポートでした。

素晴らしい内容ですよね！　これが数分で出力されるので本当にありがたいです。

でも、ハルシネーションがなければもっと良かったんですけど。

同意できる内容としては半分強くらいでしょうか。どこが正しくてどこが間違いっているのか細かく書きませんが、例えばパット見以下のような問題があります。

3か月しか使っていないのに 4Q 分の傾向を述べている、しかも内容がほぼ妄想 (実際にそんなことはしていない)
数字は全体的に怪しい。時間や回数はものすごく桁違いみたいなことはないが、あまり信用できない
長期的な視点自体は一般的な内容をそのまま出しているようで、Devin はあまり関係ない

ただ、これでも十分使えます。ユーザはこれに対してコメントし、また指示を変え、あるいは直接自分で編集し、またそれを Devin に戻したりしながら、とにかく最終的に完成品まで持っていく、という作業を行います。今回は文章なのでプログラムとは違い、明らかに苦手な内容ではあるのですが、それでもここから完成形までどうすればいいか想像してみてください。それが Devin を使うプロセスになります。

ちなみに、間違いやすかったり苦手なところは結構傾向があり、何を修正し、指示のときに何を気をつければいいのか、使っていると少しずつ掴めていくような感覚があります。もちろん、将来的にもっと精度は上がり、肌感覚のあやふやなノウハウはいずれ要らなくなるでしょう。でも、まだ触って感覚を掴むのが重要フェーズにあると感じます。とにかくみなさんも Devin や各種開発向け AI を体験してみてください。現時点でも料金以上には十分活躍してくれますよ。

少し前に Devin は料金プランが更新され、$500 最低コミットがなくなったため、非常に体験しやすくなりました。もしDevinを試してみたい方は、こちらの Repro の招待リンクから登録するとお互いにボーナスがあります。 https://app.devin.ai/invite/GidRNVrSeRYFhqRS よろしけれればぜひ。

また、Repro Booster では AI だけではなく、一緒に働ける人間の開発者の方も募集しています！　AI を積極的に活用し、Web パフォーマンスを改善する広範なプロダクト開発に興味があれば、ぜひ気軽にご連絡ください。