新卒エンジニアチームが陥ったAI活用のバッドパターン

はじめに

生成AIが急激に進化している昨今、生成AIを活用した開発プロセスを模索している方や、経験の少ないメンバーでのチーム開発をはじめようとしている方も多いのではないでしょうか。

私たちは、新卒エンジニア研修で「Gemini」や「Cursor」などの生成AIツールを積極的に活用し、AI時代の新たなソフトウェア開発スタイルを探ることに挑戦しました。

本稿では、そんな私たちが実際に経験した失敗と、そこから見出した改善策から、生成AIとの付き合い方について具体例とともにご紹介します。

チーム開発におけるAI活用の試み

開発に着手した私たちは、「Sprint1で『実際に触ることができる』成果物を作り、スプリントレビューでフィードバックをもらう」ことを目標にしました。

今になって振り返れば、私たちは「スプリントレビューには触ってもらえる成果物を持っていくべきだ」というベストプラクティスに固執していたように思います。その結果、自分たちの状況を冷静に俯瞰する視点を欠いたまま、いくつもの意思決定を進めてしまっていました。

DeNAの新卒エンジニアのバックグラウンドは実に多様です。私たちのチームでも、Web開発の経験値や設計・アーキテクチャに関する知識などにメンバー間の差がありました。

そうしたなかで最大のアウトプットを出すために、私たちはCursorのCoding Agent機能（以下、Agent）を頼りました。技術理解が多少浅くても、自然言語を使ってある程度動くものを作り続けられるAgentは、「できたての新卒エンジニアチームが最速で成果物を出す」ことに対して最適と思われるツールでした。

このアプローチが、私たちのチームに大きな課題をもたらすことになります。

AI駆動型開発で直面した具体的な課題

Agentに頼ってSprint1の成果を最大化しようとした私たちですが、その過程でいくつかの深刻な問題に直面しました。

キャッチアップ不足による効率の低下

Sprint1でに成果物の最大化を優先した結果、私たちは使用技術のキャッチアップを疎かにしてしまいました。

前述の通り、使用している技術や設計について不慣れなメンバーがいたにも関わらず、チームとして十分な学習時間を取らずに開発を進めてしまったのです。

当初はAgentがコードを生成してくれるため、個々の技術的な理解が浅くても「それなりに動くもの」はできていきました。

しかし、これは一時的な効率化に過ぎませんでした。チーム内で技術的な共通認識が不足していたため、後に設計に関する議論やコードの認識合わせに膨大な時間を要し、中長期的な効率に大きな悪影響をもたらしました。

すべてのツケをレビューで支払わなければならない状態

使用技術への理解が浅いままAgentにコードを生成させた結果、以下のような事象により、プルリクエスト（PR）のレビュープロセスが形骸化するという問題が発生しました。

PR作成者がAI生成コードの意図を説明できない

Agentが書いたコードについて、「なぜその実装になったのか、どのような意図があるのか」をPR作成者自身が理解しきれておらず、コードにオーナーシップを持てていない状況でした。
レビューの指摘事項が増え、細部まで確認する必要がある

nullチェックの不足によりpanicするリスクのあるコードなどがいくつか混入しており、レビュワーはPRに含まれるコードの品質や正当性を一から判断しなければならず、レビューにかかるコストが増大していきました。

また、レビュワーを務めることができるメンバーが限られていたことも、負担増加の大きな原因となりました。
レビューの長期化

上記のレビュワーへの負担集中により、レビューが滞りがちになりました。これにより、開発フロー全体の中でレビューがボトルネックになる状況が発生しました。

設計思想やアーキテクチャの遵守の難しさ

私たちのチームは、原則としてクリーンアーキテクチャを採用していました。しかし、設計思想のドキュメント化とチーム内での共有が十分でなかったため、Agentに与えるコンテキストも曖昧になってしまいました。

Agentは一般的なプラクティスに基づいたコードを生成しますが、特定のプロジェクトの設計思想やルールを完全に理解しているわけではありません。 そのため、私たち人間がAgentの生成物を適切に修正・調整しなければ、アーキテクチャの一貫性はすぐに損なわれてしまいます。

この問題は、修正工数の肥大化を招きました。アーキテクチャが崩れたコードは、修正しようとすると他の部分への影響が大きく、工数の見積りが困難になっていきます。

AIに任せきりにしたことで、かえって後から修正するコストが増大していく結果となりました。

失敗から得られた教訓

前述の失敗から、チーム開発で大切にすべきことと、生成AIとの付き合い方を考え、主に以下の3つを大切にすべきだと結論しました。

キャッチアップ時間を確保する

特にチーム内の経験や知識に差がある場合、開発の初期段階で技術的なキャッチアップを行う時間を十分に確保する重要性を痛感しました。

特に以下の3点は、心構えとして重視すべきだと感じました。

技術的な認識を共通化して、成果物の質を担保する

チーム開発において、メンバー全員が使用技術に関する最低限の知識を持ち、共通の認識を持つことは、成果物の質を担保するうえで極めて大切なことだと学びました。
キャッチアップは「必要な投資」だと認識する

初期段階でキャッチアップのための時間を明示的に設けることは、後の開発をスムーズに進めるための投資だと捉え、ある程度のコストを掛ける価値があると感じました。
モブプログラミング・ペアプログラミングの活用

不慣れな技術については、知見のあるメンバーがモブプログラミングやペアプログラミングを通じて、実装しながら知識を共有し、理解レベルを揃えることが効果的でした。

人間が担う役割を意識する

AIがコードを生成する時代だからこそ、人間が担うべき役割を意識し、それを全うしようとする意識を持つことが大切だと感じました。

この「役割」の具体例として、以下の2つが挙げられます。

生成AIが出力したコードを適切に評価・修正する役割

Agentがどれだけ優れたコードを生成したとしても、その生成物に対する責任は人間が負うべきです。そのためには、生成物を適切に評価し、必要に応じて修正・改善できる能力が不可欠です。

言語、ライブラリ、フレームワーク、そしてアーキテクチャに対する基礎知識をきちんと身につけ、AIの出力が正しいか、プロジェクトの要件に合致しているかを判断し続けることが求められていると感じました。
設計に関する意思決定を行い、それを言語化する役割

プロジェクトの大局的な設計思想を策定し、それをチームに浸透させる役割は、AIには担えません。

設計思想を言語化し、ドキュメント化してチームに伝える能力、そしてそれをもとにAIに適切なコンテキストを与え、軌道修正を行うための思考力が求められているように感じました。

生成AIやツールの強みと弱みを認識し、使い分ける

「生成AIは銀の弾丸ではない」ということは、各所で色々な方が様々な言葉で発信されているとおりです。

私たちはこのことを身をもって体感し、何を任せ、何を任せるべきでないかを考え、以下のようにまとめました。

生成AIが力を発揮するシーン
- 明確なバグの原因特定と修正
  
  エラーログなどからバグの原因が明確に推測でき、かつ修正の影響範囲が限定的な場合、ある程度自律的に調査と修正まで実施できる力があるようです。
- 小規模モジュールにおけるビジネスロジックの実装
  
  入出力が明確で、テストケースとして定義できるような小さいモジュールの開発では、強力なツールとしてAgentを利用できます。
  特にビジネスロジックのイメージができていて言語化までできているなら、実装をそのまま任せることも可能なレベルだと思います。
- 定型的なコード生成や既存コードの改善提案
  
  既に存在するコードのスタイル調整、コメント追加、簡単なリファクタリングなど、定型的でルールが明確なタスクについても、ある程度自律的、かつコードベースの検索などを利用して網羅的なタスク実施が可能です。
人間がタスクを実施した方が良いシーン
- プロジェクトの設計
  
  アーキテクチャの設計や、その設計に至る思想の確立は人間が担うべきだと考えます。
  このようなタスクは、単なるコーディングスキルでは解決できない、ビジネス要件や将来性を見据えた高度な意思決定を含むため、まだまだ人間に分があるように思います。
- 生成AIが出力したコードの最終的な検証と品質保証
  
  Agentなどのツールが生成したコードはあくまでも提案であり、その最終的な品質を確認・保証し、責任を持つのは人間である、ということを私たちは痛感しました。Agentの出力を鵜呑みにせず、常に人間による検証を行う姿勢は、簡単にその手綱を手放せるからこそ意識し続けなければならないと思います。
- 定型的なコード生成や既存コードの改善提案
  
  既に存在するコードのスタイル調整、コメント追加、簡単なリファクタリングなど、定型的でルールが明確なタスクではAgentが活躍します。