こんにちは、Energy Marketing Devチームの細木です。
前回の記事では、Devinの導入から実践的なタスク実行までお話ししました。Devin’s Machineの設定、クラスの細分化、Cursorとの使い分けなど、実際に取り組んだ改善策により、開発効率が向上したことをお伝えしました。
今回は前回の取り組みをすることで見えてきた更なる課題を解決するために、Devinをより効果的に活用するための今後試してみたいことをお話しします。
前回の取り組みで見えてきた課題
前回の記事でお話しした改善により、Devinの活用は格段に向上しました。しかし、実際に運用していく中で、さらなる改善が必要な領域が見えてきました：
1. CI失敗の根本原因分析の限界
- DevinはCI失敗を検知することはできるが、失敗の中身まで見てくれていない
- そのため現在は手動でCIパイプラインを確認し、必要な部分をコピペしてDevinに渡している
- 手間がかかるもの問題だがCI失敗でDevinの作業が中断してしまう
- 特に複雑なエラーの場合、原因特定に時間がかかる
2. クラス設計の一貫性の課題
- クラスの細分化は進めているが、各クラスの役割が暗黙的
- クラス設計やコードの文脈をDevinが把握しきれずスレッドごとに同じような指摘を繰り返している
3. コードの品質ばらつきとレビューの負担
- AIエージェントが生成するコードの品質にばらつきがある
- リファクタリング時の安全性が不十分で、変更の影響範囲を把握しにくい
これらの課題を解決するために以下の3つの方法を検討しています。
1. Buildkite MCPの導入
前回の課題から見えた問題
前回の記事でお話しした通り、Devin’s Machineの設定により「テストをしないでpushされることが激減」し、「CIでの単純なテスト失敗による差し戻しが大幅に削減」されました。
しかし、CI環境特有のテスト失敗やタスクで修正したファイル以外のテストの失敗はDevinローカルのテストだけではカバーできず、以下の手作業が依然として発生しています：
- CIパイプラインを自分で確認
- 必要な部分をコピペしてDevinに渡す
- 手動での情報収集と伝達
Buildkite MCP導入の狙い
Buildkite の公式が公開しているMCPサーバーを導入することでそれらの課題を解決できないかと考えています。
2. クラスの役割明確化・ドキュメント化
前回の取り組みの延長
前回の記事でお話しした「クラスの細分化・責務の明確化」は、例えば以下のような方針で進めています：
- Validators配下のクラス: booleanを返すバリデーションメソッドのみを実行
- サービスクラス: メソッドの引数は対応したパラメータークラスを受け取る
この取り組みにより「各クラスの役割が明確になり、レビューの負担を軽減」する効果を実感していますが、まだ暗黙的な部分が多く以下のような課題が残っています。
- 各クラスの役割や責務が暗黙的に実装のみでカバー
- 新規メンバーがコードベースを理解するのに時間がかかる
- AIエージェントが「この処理はどこに書くべきか」を理解できていない
改善計画
前回の取り組みを発展させる形で、以下のようなファイルをリポジトリに追加することを検討しています
- クラス設計・コーディングルールのドキュメント化
- AI用であるが人間のオンボーディングにも使えるようなものをイメージ
- プロジェクト全体のクラス設計（どういったクラス群に分かれているか、ディレクトリ構成など）
- 各クラス個別の設計（そのクラスの役割、責務、決まったインターフェースがあればそのフォーマットなど）
- 共通ベースクラスの定義
- （実装上可能であれば）クラス群が共通で継承するベースクラスを定義して振る舞いを固定する
- 前回の「Validators配下のクラス」「サービスクラス」などのパターンをより堅牢に
期待される効果
これらの取り組みにより期待している効果
- レビューの範囲・回数の削減
- クラス設計が明文化されることで、レビュー時の参照ファイル数が削減
- AIエージェントの実装精度向上により、レビューの回数も削減
- 人間のオンボーディング効率化
- 新規メンバーがコードベースを理解する時間の短縮
- クラス設計の全体像を把握しやすく
- システムとしてきれいになる
- 一貫性のあるクラス設計により、コードベース全体の品質向上
- 保守性と拡張性の向上
3. 型の導入
前回の取り組みとの連携
前回の記事でお話しした「クラスの細分化・責務の明確化」と「Cursorとの連携ワークフロー設計」により、開発効率は大幅に向上しました。
しかし、コードの品質ばらつきとレビューの負担という課題が残っており爆発的な生産性向上には至っていません。
- AIエージェントが生成するコードの品質にばらつきがある
- レビューの負担が大きく、特に型エラーや実行時エラーの確認に時間がかかる
- リファクタリング時の安全性が不十分で、変更の影響範囲を把握しにくい
型導入による解決アプローチ
これらの課題を解決するためのアイディアとして、型の導入を検討しています
型導入により期待される効果：
- コード品質の向上
- 型チェックにより実行時エラーの事前発見
- AIエージェントが生成するコードの一貫性向上
- より予測可能なコード生成
- レビュー負担の軽減
- 型エラーの自動検出により、レビュー時の型チェック作業を削減
- 変更の影響範囲が型レベルで明確化
- より本質的なレビューに集中可能
- リファクタリングの安全性向上
- 型定義により変更の影響範囲を把握しやすく
- リファクタリング時の安全性向上
- より大胆な改善が可能に
- 前回の取り組みとの連携
- 型定義によりクラスの責任範囲が明確化
- インターフェースの標準化
- AIエージェントの実装精度向上
期待される効果
課題解決への貢献：
- コード品質のばらつき解消: 型チェックにより一貫性のあるコード生成
- レビュー負担の軽減: 型エラーの自動検出によりレビュー効率向上
- リファクタリングの安全性向上: 変更の影響範囲を型レベルで把握可能
- 前回の取り組みとの相乗効果: クラス設計の明確化とAIエージェントの精度向上
おわりに
残念ながら（？）ここ最近は開発案件がパツパツに入ってしまっておりこれらの施策を試せていませんが、なるべく早いタイミングで導入し、より楽に案件を回せるようになればと思っています。
今現在対応している開発案件もDevinやCursorはフルに使っている状況で、もしAIエージェントがなかったらと思うとぞっとします。
Source link
コメント