Cursor導入の効果とチームの変化

ogp

はじめに
Cursor導入の検証と評価
Cursor導入前後の比較
- Four Keysの比較分析
- チームの変化
さいごに

はじめに

こんにちは、enechainでソフトウェアエンジニアをしている小沢です。

enechainでは、昨今トレンドとなっているAIエージェントの活用に積極的に取り組んでおり、CursorやCopilot Agentの導入、Devinの検証などを行っています。私たちが所属するeScanチームでも、2025年1月から「Cursor」を活用して開発をしています。

本記事では、Cursor導入の効果と、チームに起こった変化についてご紹介します。

Cursor導入の検証と評価

ここでは、我々が実施したCursorの検証と評価の方法についてご説明します。

検証と評価方法

検証では、新規機能の開発を含めて一定期間Cursorを活用し、あらかじめ設定した評価項目に基づき、導入前との比較をすることにしました。

特に新規機能開発においては、開発規模が小さいと実務レベルでの効果を判断しにくいため、マイルストーンとして計画されていた比較的規模の大きい機能も検証対象に含めました。

評価項目については以下のとおりです。以前から取得しているFour KeysとGitHubから取得できるメトリクスをベースとしました。

評価項目

Four Keys
- デプロイ頻度
- 変更のリードタイム

新規機能開発を用いた検証

次に、検証対象とした新規機能開発の概要と特徴についてご紹介します。今回対象とした機能は、外部システムからファイルを取得し、そのファイルを解析・加工したのちBigQueryへ登録するというものです。以下がシステム概略図です。

system-overview

本機能に関する特徴は以下の通りです。

データ規模: 大量データ処理（最大22億レコード/日）
不確実性の高い実装項目: 社内で実装実績のないGCP API(KMS、SecretManager)の利用とXML解析、社内で利用実績のない外部システムとの連携

今回は上記のような特徴があり、機能開発全般において不確実性の高い実装項目がある状態であったため、まずは技術検証し、その後設計に落とし込む流れとしました。

技術検証フェーズ

技術検証フェーズでは、チームメンバーで検証項目を分担しました。私は「外部システム連携」を担当し、サンドボックス環境で動くプログラムをCursorを使ってゼロから実装しました。

外部システムの仕様と実装要件をCursorに渡すことで、初期コードは一瞬で生成されました。

技術検証フェーズではコードのクオリティにこだわる必要はないため、特別な工夫もなく、実装はすべてCursorに任せて1日で検証を終えました。人力でゼロから開発していたら2,3日はかかっていたのではないかと思います。技術検証フェーズにおいて、Cursorが非常に有用であることを確認出来ました。

実装フェーズ

すべての技術検証を終えた後、設計を経て、実装作業へ移りました。しかし、実装フェーズでは以下のような課題が発生しました。

コンテキスト切り替え時のテスト実行漏れ
既存設計方針との乖離
型チェック・Linter実行の不安定性

ルールファイルの導入

上記のような課題を解決するにあたり、静的解析を確実に実行させたり、実装を統一させるためには、ルールファイルを導入するのが効果的です。

実装フェーズの初期段階ではルールファイルが存在しなかったため、上記のような問題に加え、実装者によって異なる設計になってしまったりと非効率な部分がありました。

そこで、プロジェクト固有のルールをまとめたルールファイルを作成し、Cursorに認識させることで、静的解析の実行やテスト実行といった開発フローと設計・実装の統一が進みました。

その結果、実装フェーズにおいてもCursorの効果をしっかりと感じることができました。

Cursor導入前後の比較

Cursorを導入してから一定期間が経過したため、Cursor導入前後でFour Keysの指標やチームにどのような変化があったかご紹介します。

なお、Cursor導入直前にチーム編成の変更があり、シニアエンジニアが1名減っていました。今回の数値比較では、何もしなければシニアエンジニア1人分パフォーマンスが低下する状態だった点に留意しながら比較していきます。

Four Keysの比較分析

Cursor導入前後のFour Keysとは以下の通りです。

指標項目	Cursor導入前(2024年10~12月)	Cursor導入後(2025年2~4月)	変化
デプロイ頻度	31	29	同水準維持
変更リードタイム(時間)	87.37	88.51	同水準維持

Cursor導入の効果として、デプロイ頻度と変更リードタイムが、シニアエンジニアが抜ける前と同水準の値を維持することを期待していました。結果として同水準を維持できているため、期待した効果が得られていることがわかりました。

次に、チームの変化についてご紹介します。

チームの変化

私のチームは、開発時のほとんどをCursorで行うようになり、それ以外には、Devinを使ってライブラリのアップデートや簡単なタスクの実行をさせたりしています。また、Cursorを通じてAIエージェントに対する苦手意識がなくなり、AIに関する会話が増えたことで、以下のようにナレッジの共有や学習意欲の向上にも役立っています。

AI活用ノウハウの共有: MCPの活用方法や効果的なプロンプトなどの共有
学習意欲の向上: 新技術への関心が高まり、自主学習が活発化

上記以外にも、CursorやDevinの利用だけで満足しないよう、チームとして今後のAI活用についてディスカッションもしました。以下はディスカッションであがった今後の取り組みの一部です。

DevinSearchによる問い合わせ対応効率化: 運用負荷軽減への取り組み
GitHub Projectを活用したプロジェクト管理改善: AIと相性の良い管理手法の導入

future-initiatives

特に「GitHub Projectを活用したプロジェクト管理改善」は、MCPの登場で様々なリソースにアクセスしやすくなったことで熱量が高まっています。弊社では、プロジェクト管理には基本的にNotionを使っていますが、GitHubのほうがAIとの親和性は高いと感じています。そのため、プロジェクトやドキュメントなどをGitHubに集約し、開発体験や生産性の向上につながるか検証していく予定です。

その他にも、開発体験向上や生産性向上につながる取り組みを実施していきます。