現場でAIを使っても、チーム全体には活かせていない…」そんな課題を感じる若手エンジニアへ

はじめに

DeNAは経営レベルで「AIオールイン」を宣言しており、その方針は新卒エンジニア研修にも反映されています。 本記事では、スクラム開発にAIを導入した新卒チームが、どのように開発プロセスを変え、チーム全体の生産性と学びを高めたのかを紹介します。 特に以下のような課題を持つ方におすすめです。

• AIを使っても個人レベルの効率化で止まってしまい、チーム全体には落とし込めていない
• 「AI導入」と言いつつ、現場では結局人力判断に戻ってしまう
• 開発現場でのAI活用のリアル（失敗・成功両方）を知る機会がない
• AI活用を通じて“開発チームの働き方”がどう変わるか、イメージが湧かない

今後も、新卒研修を通じてAI活用に挑んだチームのレポートを順次公開していきます。 まずは、今回の挑戦に携わった私自身の経験や視点からお話ししたいと思います。

はじめまして、AIオールイン 入社(25卒)の、u-tanこと勝野侑馬です。
大会に出るくらいモルックが好きだったんですが、近所にモルック向きの公園がないため探してます。

福岡県で生まれ育った僕にはあまりにダンジョンな東京・渋谷で行われるDeNAのエンジニア研修。
この研修にはいくつかの研修パートがあり、そのうちの１つであるプロダクト開発研修ではいくつかのチームに分かれて、2ヶ月間スクラム開発を行います。

このプロダクト開発研修で開発するプロダクトは実際に社内で解決したい問題を起点に、企画の提案をするところから始まります。
答えの無い開発を進める中でステークホルダーの意見を素早く取り入れプロダクトをより良くするために、DeNAのエンジニア研修ではスクラムが採用されているようです。

さて、皆さんも記憶に新しいと思います南場代表による AIオールイン宣言 。
本記事はAIオールインを果たすべく、AIの力でスクラム開発そのものをハックしようと試みた、DeNA25卒研修・とあるチームの奮闘記です。

コトのはじまり

DeNAのエンジニア研修とスクラム

社外の方にも伝わるように前提から説明しますと、DeNAのプロダクト開発研修には"あるある"が存在します。それは「スクラムわからん現象」です。先輩曰く皆通る道だそうです。
開発経験のあるメンバーがほとんどなので、 「よくわからないルールに縛られるより、早くコードを書きたい」 という気持ちから、スクラムが形骸化してしまうと当然スクラムわからんはどんどん悪化するわけですが、我々のチームも例外ではなく、研修序盤はスクラムをほとんど意識せずに開発していました。 研修のレギュレーション的には、モルックでモルッカーリを踏み越えるくらい反則です。

しかし、心のどこかでは、メンバーみんなスクラム開発をしたいと思っていたはず。少なくとも、僕は思っていました。研修でスクラムを学ぶことには、きっと何か大きな意図があるはずだと。

そして、スクラム研修が始まってちょうど一ヶ月が経った頃のことです。 「スクラムやろうぜ！！」という提案が、各メンバーから次々と出てきました。 そのタイミングで、僕たちは真剣にスクラムと向き合うことにしたのです。

とある日のC班とスクラム

しかし、そこで新たな壁が立ちはだかります。コーディングAIエージェントの存在です。

ある日のプランニング中、事件が起きました。PBI（プロダクトバックログアイテム）やSBI（スプリントバックログアイテム）と呼ばれるいわば「タスク決め」について議論している最中、あるメンバーが隣で Cursor（AIコーディングツール） と対話していました。そして、私たちがタスクの分担を決めるより早く、担当予定だった機能を実装し終えてしまったのです。

これにはチーム一同、唖然としました。
「AIが一撃で終わらせる作業を、人間が時間をかけて計画する意味とは…？」
という、根源的な問いが生まれました。

私たちの生産性はAIによって爆発的に向上しましたが、そのスピードに「人間中心のルール」であるスクラムが追いついていませんでした。この非効率な状況こそが、私たちが乗り越えるべき壁でした。

文字起こしから始まる自動化への挑戦

ボトルネックは明らかでした。
開発スピードがAIによって加速しているのに、プランニングは旧態依然とした人間の会話に依存していることです。
ミーティング後、まずはその内容を咀嚼してまとめるところからプランニングが始まります。その後要素を抽出、分解、タスク化とプランニングの工程は続いていきます。
白紙の状態からこれらの工程を踏まえてプランニングを行っていたので、一人ではもちろん複数人で進める場合でもかなり時間を要しました。

ならば答えは一つ。プランニングもAIの力を借りればいいじゃないか。

どのように力を借りるか決めかねていたある時、ミーティングの文字起こしデータがふと目につきました。いつもなんとなく記録はしているものの、有効活用できていないこのデータ。

「もし、この文字起こしをAIに渡すだけで、面倒なプランニングがすべて自動で終わったら、最高なのでは？」

この仮説から、「ミーティングの文字起こしから、スクラムに必要なアレコレを"全部"自動化する」という壮大な目標を掲げ、 scrum-tools 開発は始まりました。

scrum-tools基礎編

研修中のサイドプロジェクトだったため、かけられる工数はごくわずかでした。チームの開発を妨げてプロダクトが完成しなかったら本末転倒なので、当然ながら一人での開発です。 一人での開発なので、テンションを上げるために「最小限の労力で、最大限の自動化」を勝手にモットーに掲げて、開発上の必須要件を絞り込みました。

• UIは作らず、使い慣れたGitHubのPullRequest(以降PR)画面をそのままUIとして使う。
• 文字起こしデータをテキストファイルで挿入できること。
• 自然言語処理のためにLLMを動かせること。

この要件から、「文字起こしファイルを特定のディレクトリに置いてPRを作成すると、それをトリガーにGitHub Actionsが起動し、Pythonスクリプト経由でVertex AI (Gemini API) がPBIやSBIを自動生成してPRにコメントする」 という、シンプルかつ強力なアーキテクチャを考案しました。

このようなアーキテクチャにすることで、人の作業は文字起こしファイルの取得と送信の処理のみで済みます。またGitHubの機能を適宜活用することで、開発コストを最小限に抑えることもできます。
このような考えのもと実際にツールを開発しました。

その状態で何度か検証しましたが、スクラムの進行と噛み合わなかったり、書き直しが必要なレベルの生成だったり、望んだ粒度ではなかったりと、絶妙に使いずらい状態でした。そのため、ワークフローの見直しと、プロンプトチューニングを何度か行いました。 また、このあたりのブラッシュアップには、スクラムマスターやプロダクトオーナーにも協力を仰ぎながら進めました。
また、整理する中で下にある図のようにスクラム開発を図示してみたり、どうすればスムーズに導入できるか話し合う中でスクラム開発の解像度が上がったのも個人的には大きな学びでした。
一枚目の図が開発直後のワークフローで、

二枚目の図が改善した最終盤のワークフローです。

1. まずPBIのたたき台を作り
2. たたき台をモブプロ的にメンバー全員で修正し、PBI内でSBIのタイトルだけ指定しておいて
3. PBI完成後にコマンドでSBIを生成する

当初描いた青写真には完全自動生成を想定していましたが、実際に運用してみると人の介入を想定した作りのほうが使い勝手がよかったです。
何でも任せるのではなく時と場合で責任範囲を調節してあげるというのは、今回の大事な学びの１つだと思います。

また、プロンプトについては時間の都合もあり完全にチューニングをやり切ることはできませんでしたが、最低限の調整は行いました。
例えばGitHub APIを利用して過去分のPBI・SBIを取得してコンテキストとして与えることで過去分との重複をできるだけ防ぐようにすることや、粒度を細かく指定しておくこと、日本語以外で回答することがあるため言語を指定しておくことなど、基本的な対応を行いました。

以下が実際の生成結果です。
(出力元の文字起こしは、実務とは何ら関係のない会話の文字起こしを利用しています)

scrum-tools応用編

１つ上手くいくと、他の業務にも応用したくなるのがエンジニアの性分です。
また、日々の業務で頻繁に発生する繰り返し作業は可能な限り効率化したい、という思いもありました。
前述の技術的な構成を見るとわかるように、プロンプトだけ差し替えれば要約系の作業はほとんどを自動化できると考えています。以下が具体的な応用事例です。

振り返り会を楽にする

まず着手したのがKPT（Keep, Problem, Try）の振り返りでした。
毎日班での振り返りの時間を取っていたのですが、ホワイトボードツールで付箋に各々書いて意見を言い合って一つにまとめるのは個人的に無駄が多いなと思っていました。
加えてホワイトボードツールを使うとデータが散らかりやすいため、スプリントレトロスペクティブ(スプリントで行う振り返り)の際に扱いにくいデータとして記録されてしまいます。
空き時間で実装を進めてみたものの、作った感触として時間工数的にはそれほど削減できないような気がしてました。
とはいえせっかく作った機能でもあるので、スクラムマスターに相談しツールを使った振り返り会──つまり「テキストで残さない、会話だけの振り返り会」──を実施してもらうことにしました。
最初こそメンバーの表情に戸惑いが見えたものの、 最終的には「振り返りが楽になった」「コミュニケーションが増えた」など喜びの声を聞くことが出来ました。
開発者目線だと前述したPBI・SBIの生成よりも、実装が簡単だった分費用対効果が高かったと感じています。散らかったデータの認知負荷やキーボードで入力するストレスからの開放を肌で感じることができ、音声入力の可能性を改めて実感しました。 メンバーの役に立てて嬉しく思います。

(実際の振り返り記録なので個人名が出てる部分などを隠してます)

ミーティングを効率よく理解する

せっかくなのでもう一つと思い実装したのがミーティングの可視化機能です。
共感マップ等のフレームワークで可視化するだけの簡単な機能でしたが、結果的にはほとんど使われませんでした。
周知が不十分だったことと、実装した頃にはユーザーヒアリングがほとんどなくなっていたのが理由だと考えています。
なかなかに出力が長いので、特に実用的かつ見栄えの良い部分のみご紹介します。

(出力元の文字起こしは、実務とは何ら関係のない会話の文字起こしを利用しています)

基本的な構造はどの機能も同じで、それぞれ決められたディレクトリに文字起こしのテキストファイルを配置してPRを作成するだけです。PR作成がトリガーとなり、ディレクトリ配下の変更を検知して任意のワークフローを実行するという流れです。
参考までに、以下のようなディレクトリ構成になっています。

AIが再定義した僕達のスクラム

このツールは、私たちのスクラム開発のあり方を劇的に変えました。

例えば毎日の振り返りです。
ホワイトボードツールを使ったやり方だと確かに意見は漏れなくまとめられますが、前述のように情報が散らばり、認知負荷がかかるなどの問題がありました。そのため、振り返ってみると、当時の振り返り会は地味に精神的負荷が高かったなと思います。
そのような振り返り会をこのツールを使うことで、無駄を省きつつチームとして最も意味のある状態にできたと感じています。

また、必要に応じて行われるプランニングやリファインメント。
これまでPOがまる一日以上かけて書き上げたものをみんなで数時間眺めて、あーでもない、こーでもないとなかなか決まらなかったプランニングが、ツールの生成したたたき台ベースでPBIを決定し、そこから生成されたSBIを運用する方法に変えることで１時間あれば終わるようになりました。
最長でプランニングに三日ほどかけたことがあったので効果はバツグンでした。
これにより、 今まで中だるみしていた議論からより顧客価値に向き合う本質的な議論に変わったと感じます。さらに、時間的工数の削減にもつながったため、実装に充てられる時間も増えました。
まとめると、このツールにより顧客価値のある生産性を大幅に向上させることができたと感じています。

また、このツールは文字起こしを起点として動作するため、結果的に音声でのコミュニケーションが増え、チーム内の心理的安全性が向上しました。その結果、チームとしてのまとまりが生まれる一因にもなったと考えています。

まとめと今後の話

本当は効率的なんだろうけど、なんだかめんどくさくて、よくわからなくて、一見非効率に見えるスクラムを僕達なりに効率よく導入するために知恵を絞って開発を始めたこのツール。結果としてチーム全体の意思決定を効率化し、顧客の本質と向き合う時間を最大化し、より意味のある開発をサポートしてくれたと感じています。
そして、いくつかの 面白い発見 もありました。

１つ目は、 入力インターフェースの重要性 です。
同じ内容でも、キーボードで延々と入力するより、話した（ミーティングした）内容をAIに処理してもらう方が、体感的な負荷が圧倒的に低いということです。振り返りが楽になったのはこのあたりが要因ではないかと考えています。 諸外国では音声入力が普及しているようなので、日本でも今後普及していくのではないかと考えています。

２つ目は、 AIドリブンなコミュニケーション です。
「AIに正しく理解させよう」と意識して話すと、自然と丁寧で分かりやすい言葉遣いになり、結果的に人間同士のコミュニケーションも円滑になる点です。
指示や意見の具体性が増し、意見の齟齬は起きづらいため常にコトが揃った状態を維持できるので何度も同じ会話をすることが減り、効率よく作業できました。

これらをまとめると、AIが人間の仕事を奪うのではなく、人間がより創造的な仕事に集中できるよう手助けしてくれる。今回の開発を通して、私たちはその可能性を強く実感しました。

全社としても、開発効率化の新たなアプローチとして知見を貯めることができたかなと思います。
今後も、面倒なことはAIオールインで解決する。そんなマインドセットを大切に、最高のDelightを届けられるよう、初期衝動を忘れず頑張ります。
ここから始まるDeNAでの旅路を精一杯面白がってやろうと思ってます。

(追記)
本記事の構成や推敲にも、LLMの力を活用させていただきました。 さようなら、非効率的な開発現場。ありがとう、すべてのLLM。