AIエージェント「Cursor」で変わる開発マネジメントの実践論

サムネイル

1. はじめに

こんにちは。DMM.comでプラットフォーム開発本部の副本部長をしている石垣です。

プラットフォーム開発本部では、AX戦略を進めています。

developersblog.dmm.com

developersblog.dmm.com

今回は、私が実践している「Cursor」術について紹介します。 CursorとはAIを搭載したコードエディタですが、コードを書くだけでなく、ドキュメント管理やワークフローツールとしても活用できます。

開発組織を束ねる立場のマネージャーや部長、ソフトウェア開発のPM/PdMという方に、本記事が役立つTipsになればと思います。

Cursor

2. AIコーディングのその先へ。開発プロセス全体にAIを導入する

ソフトウェア開発におけるAI活用というと、AI-assisted codingやVibe Codingと言われるコードを協働しながら書いていく「開発フェーズ」の効率化をイメージされる方が多いのではないでしょうか。

しかし、AI活用のポテンシャルはそうした部分的な取り組みに留まらず、もっと広義です。開発のBMLループや継続的な改善(メンテナンス、リファクタリング)だけではなく、マネジメントラインが担う組織開発やプロジェクト管理、ルーティン作業、バグトリアージまで含みます。 つまり、BPR(Business Process Re-engineering) と呼ばれる業務プロセス全体を見渡してAIを取り入れていく必要があります。

BPRは「業務の洗い出し→抜本的な再設計→定着」という3つのステップで進めていきます。 実際、リードタイム全体を計測してみると開発工数はそこまでかかっていないことが多いです。開発フェーズのProcess Time以外にも、企画やプラン構築までの作業やミーティングコストやそれぞれの待ち時間もあり、プロジェクトによっては開発フェーズ以外に多く時間がかかっていることもあります。

leadtime

それぞれ単一プロセスにかかっている工数も無視できず、認識合わせのためのドキュメント作成や会議のための準備、管理のための管理といったコストも発生します。

2.1 プロセスを"AI"に置き換えるのではなく、"AI"前提のプロセスに作り変える

そのため、AIを導入するにあたって、まずは業務プロセスの洗い出しからスタートして課題を抽出します。 ここで大事なのは、業務プロセスをAIに置き換えるのではなく、AI前提の業務プロセスに置き換えることです。 よくある間違いは、既存の業務プロセスにそのままAIを当てはめようとしてしまうことです。このやり方では、かえって大きな工数が発生します。

現在、私が所属するプラットフォーム開発本部は約200名のエンジニアで構成され、DMMのプラットフォームを支える基盤(ID基盤や決済基盤等)を提供しています。 つまり、毎月約200人月の工数をかけてソフトウェア開発を進めています。しかし、これまで職能ごとの業務プロセスを体系的に把握できていませんでした。そこで、BPR(Business Process Re-engineering)の視点から、職務や業務プロセスを洗い出すことにしました。この分析では、完全な正確性よりも、AI活用の可能性を見出すことを重視しました。そのため、必要最小限の精緻さで、クリティカルな課題の抽出に焦点を当てています。

業務プロセス 引用 : https://developersblog.dmm.com/entry/2025/04/18/110000

2.2 開発フェーズ以外の課題がたくさんある

想定通り開発フェーズだけではなく、開発マネージャーが担当している部分に人力作業が多く存在していることがわかりました。そこにAI活用を導入していくことで、組織全体の生産性を大きくブーストさせられるという結果になりました。

業務プロセスの課題

3. マネジメントの知見蓄積とワークフロー化

ここからは、「Cursor」を活用した業務プロセス管理の具体的な方法について説明していきます。 まずはフォルダー構成です。

ワークフロー

ベースとなる構成としては、とにかく雑多な情報やリンク集を「repo/」配下に置きます。 そこから、体系的な知識として形式知になりそうなものを「doc/」配下に作成していきます。 その後、必要があればCursorのRulesを作っていってワークフロー化していきます。

ワークフロー化の例として、毎月・毎週実施する定期的な計算や出力作業を自動化することが挙げられます。仕事上、部門の組織デザイン、工数管理や人材関連費、ライセンスの予実計算、市場動向を計算する業務が多いため、そういった分析・修正業務はワークフロー化しています。 PdM/PMであれば要件定義から自動でロードマップやJIRAのチケット作成をしたり、立場によって様々なケースが考えられます。 形式知となる「doc/」配下には、自分自身の考え方や運営方法をまとめたり、公開されている資料を格納しています。例えば、プロジェクトマネジメント観点でいえばスクラムガイドにすぐアクセスできるようにしたり、それぞれの領域で参考になる論文やレポートを格納しています。

3.1 ワークフロー化を避けるべきケース

ワークフロー化が適さないケースとして、チームの暗黙知や集合知に基づいて運営されている場合が挙げられます。 例えば、以下のケースはワークフロー化に適していません。

  • ストーリーポイントや詳細な見積もりなど、チームの経験や知見に基づく判断が必要な数値の算出
  • 1on1ミーティングなど、ピープルマネジメントに関わる重要な対話の場

これらの場面では、細かな会話のニュアンスや、チームメンバー間の相互理解が重要です。特に組織をマネジメントする立場としては、こうした人と人との直接的なコミュニケーションを通じて、チームの共通理解を深めていくことが不可欠です。そのため、これらの領域をAIに委ねるのは避けるべきです。

4. エンジニアが開発に集中してもらうためにできること

本記事では、開発組織をマネジメントするうえで、エンジニアに聞かずに把握するにはどうすれば良いかについて焦点を当てていきます。 エンジニアには本来の開発業務に集中してほしいというのは、どのマネージャーも共通の願いでしょう。しかし、現実には、マネージャーやPMがエンジニアリング領域についての理解が不足しているがゆえに、エンジニアに対して頻繁に質問や確認をする傾向があります。これにより、エンジニアは開発作業の中断を余儀なくされ、コンテキストスイッチのコストが発生してしまいます。

この課題に対して、AIエージェントを活用することで、エンジニアへの不要な問い合わせを減らすことができます。さらに、マネージャー自身がAIエージェントを通じてエンジニアリングの理解を深めることで、より効果的なマネジメントが可能になります。つまり、AIエージェントは、エンジニアの生産性向上と、マネージャーのエンジニアリング理解の深化という、両方の課題を同時に解決する鍵となるのです。

4.1 類推見積もりによる超概算見積もり

エンジニアに頼まずに企画を通したり工数を算出したりする際に「ざっくりでいいから見積もりがほしい!」という場面は多くあります。そんなとき、AIに既存コードを読み込ませ、類似機能の実装時間から「類推見積もり」を行うことができます。 AIは過去の実装パターンや複雑さを分析し、新機能の工数を予測します。これにより、企画段階での意思決定や優先順位付けがスムーズになります。特に技術的な詳細を深く理解していないPMでも、エンジニアに頼らず概算の見積もりを得られる点が大きなメリットです。これによって、企画の初期段階から現実的なスケジュール感を持った提案が可能になり、プロジェクト全体の見通しが立てやすくなります。 例えば、Cursorで「このAPIを作るのに2人月かかりました。新しく〇〇の要件を組んだ〇〇APIを作りたいのですが類推見積もりから、超概算見積もりを出してください」と指示します。すると改修にあたっての影響範囲・再利用できるモジュールを調べてくれたうえで超概算見積もりを出してくれます。 これにより設計フェーズに下ろすまでのエンジニアの工数が減らせそうです。

類推見積もり

4.2 コードベースからの仕様自動抽出

開発組織をマネジメントするうえで、技術的な理解は必須ですが、すべての技術的な詳細を把握することは困難です。 AIを活用することで、この障壁を下げることができます。 ビジネスサイドから求められる既存システムの仕様をエンジニアに都度確認するのではなく、AIを使ってコードベースから直接仕様を抽出できます。AIにコードを解析させることで、APIの仕様、データベースのスキーマ、ビジネスロジックなどを文書化できます。 これにより、エンジニアの作業を中断させることなく、必要な情報を迅速に取得できます。また、ドキュメントが古くなっている場合でも、最新のコードから正確な情報を得られるため、コミュニケーションの齟齬を減らすことができます。 特に複雑なレガシーシステムや、ドキュメントが不足しているプロジェクトでは、この方法が非常に効果的です。AIはコードの構造を解析し、人間が理解しやすい形で仕様をまとめてくれます。これによって、ビジネスサイドとの会議前にシステムの振る舞いを正確に把握でき、より建設的な議論が可能になります。

簡単な利用ケースで言えば、mermaid.jsでシーケンス図を作成したいという場合に、Cursorに指示を出すとシーケンス図を出力してくれます。

シーケンス図

また、弊社では「Devin」を利用しているのですがDevin wikiを活用することで、もっと詳細に仕様を抽出できるため活用しています。

4.3 投資工数を分析し、開発業務に集中できているか確認

DMMでは、「誰が / どのプロジェクトに / どのぐらいの工数をかけているか」を勤怠とともにプロジェクトコードと紐づけて、BigQueryとLookerを使いビジュアライズしています。

スライド 引用 : https://speakerdeck.com/i35_267/is-development-productivity-profitable?slide=41

主に見ている点としては、以下の区分で開発業務を分解して、正しい開発業務に工数を投資できているかということです。

  1. 新規開発 : 新しい価値を0からソフトウェア資産を作る
  2. エンハンス開発 : 既存システムの拡張・変更
  3. 保守開発 : 資産価値や耐久年数を維持・伸ばす(振る舞いを大きく変えずに内部品質を整え、現状を維持するリファクタリング・バージョンアップ等)
  4. 運用 : 障害対応、問い合わせ対応、ルーティンワーク等
  5. 管理業務、その他 : 会議、採用等の管理業務

これらの区分の先月比の変化をCursorで分析しています。 ビジュアライズされたグラフだと変化は見えやすいのですが、詳しい数値分析は対話形式で深堀りできるCursorのほうが適しています。 工数分析

5. まとめ:AIを活用した開発組織マネジメント

今回は、簡単に開発組織をマネジメントするうえで必要な作業をエンジニアの工数を削減するという意味合いでご紹介しました。

それ以外にも以下の活用をしています。

  • 書類選考のスクリーニング
  • 要件定義・要求定義のたたき台作成
  • NotebookMLで会議やノウハウを格納し、報告書を読み上げるだけのMTGをなくす
  • サービスのモンキーテストをPlaywrightで自動化

DMM.comではエンジニアを随時募集しています。カジュアル面談も行っていますので、気軽に話したい方はぜひお申し込みください。 pitta.me