食べログカンパニー 開発本部 飲食店プロダクト開発部 羽澤と申します。
先日、アマゾンウェブサービスジャパン合同会社が開催している、「AWS AI-DLC Unicorn Gym ワークショップ」を受講する機会をいただきました。 元々カカクコムではAI EXCELLENCEをバリューとして掲げ、AIを活用した開発に取り組んでいましたが、課題感もあったため期待して参加させていただきました。
本記事では、私が所属しているチームにおけるAI活用の状況と課題感、AWS AI-DLC Unicorn Gym ワークショップの紹介、そして今後の開発プロセスにどう活かしていくかの展望という形で筆を取りたいと思います。
あのプレスリリースから半年
年度が変わった直後の4月2日、当社においてAIエディタ「Cursor」を全エンジニアに導入するというプレスリリースを発表しました。
カカクコム、AIエディタ「Cursor」を全エンジニアに導入
このプレスリリースを発表する前からAI活用は行われており、Github Copilot, Dify, PR-Agent など、いくつかのAIツールを利用し、役立てていました。 しかし Cursor を初めて使った時の衝撃は、それまでとは比較にならないほど大きく、「AI活用」という言葉の印象や、今後の展望がガラッと変わったのを覚えています。 その後もプレスリリースこそ出していませんが、現在では Devin や Claude Code も導入されており、Cursor とは異なる活用がされている状況です。 また、非エンジニア職の方も Cursor や Devin を利用し始めており、1年前では考えられないほどAI活用が進んでいます。
しかし！！！
あれから半年以上が過ぎ、Cursor に衝撃を受けた時に想像した未来へ向かっているかというと・・・順風満帆とは言えないというのが正直な感想です。 AI活用が進んでいること自体は本当ですし、有効に活用できてはいるものの、もっとポテンシャルがあると感じています。 色々と試していますが、概ね以下のような壁を感じています。
- AIって言っても新人エンジニアとあまり変わらないのでは・・？
- AIはしれっと嘘つくよな・・・
AI自体の進歩で改善したと感じることもありますが、自分たちの工夫でこの特性を抑え込みながら活用しているのが現状です。
これまでのAI活用
私が担当しているチームでの、今の状況をまとめます。
- 既存機能の調査等において、補助的に利用している
- 精度はマチマチなので、最終チェックは人間が実施している状況
- 詳細設計から実装・ユニットテストはほぼAIに任せている
- 要件や業務ルール、テーブル定義などをインプットにして詳細設計をさせる。
- AIに実装指示レベルの詳細設計書を作らせることで品質を担保している。
- コードレビューなどはAIによるものを併用している
- 完全にAIレビューに移行しているわけではなく、人間によるレビューも実施した上でAIによるレビューを行なっている。
- 単純作業、例えばライブラリのバージョンアップなどのコード修正はAIが行なっている。
- 要件定義の壁打ちに利用し始めている
このような形です。 様々なことに活用し、AIを利用することが当たり前にはなっていますが、4月に感じた輝かしい未来はまだまだ遠いようです。
開発効率1.x倍の壁 - 我々はなぜ変わらなければならなかったのか？
AI活用における課題
詳細設計から実装・テストの工程でAIを活用することにより、一定の成果は出ています。 今はまだ効果計測としては出来ていないのですが、今まで通り自分たちで実装することを前提とした見積もりよりも小さい工数で仕上げることができています。 ただ、目指しているのはもっと大きな改革です。4月のプレスリリースにてCTOから発信した内容を引用します。
私たちはプロダクト開発を圧倒的に速くし、事業成長やユーザーの皆さまに価値を届けるスピードをさらに上げていきます。
我々が目指しているのは圧倒的な速度、つまり要件定義を含めた開発全体を数倍の速度に引き上げることを目指しています。 そのためにはもっと根本から変えていく必要があると感じていました。 その上で、現状のAI活用に対する課題感は以下の通りでした。
AIに対するマイクロマネジメント
前述の通り、新人と仕事をしているような感覚で接する必要がありました。 実際AIによる実装を試し始めた際、必要な修正箇所が一部漏れていたりなど、レビューもしくは実装指示を手厚くする必要があるという認識を持ちました。 そこから色々な試行錯誤の末、実装指示を厚くすることで品質の良い成果物を出してもらえていますが、AIに対してマイクロマネジメントをしているような状況になっています。 トータルでは工数削減になっているものの、もっと自律的に動いてほしい、最低限の情報提供や指示で品質の高いものを出してもらいたいという課題がありました。
要件定義に対するAI活用の壁
要件定義フェーズでもAI活用を始めていますが、有効活用できていませんでした。 要件定義で時間がかかるのは業務フローの洗い出しや検討なので、議論のパートナーとして壁打ち相手に使ったり、一般的に考えられる業務パターンを提案してもらっています。 しかし本当に重要なのは、食べログならではの複雑な業務ルールや仕様を洗い出すことであり、現状は人間がやらざるを得ないという課題があります。 また設計フェーズのためにそれらをまとめ、AIにインプットする必要もあり、大きな手間がかかっています。
そろばんから電卓になっただけでは足りない！
これらの取り組みによって、開発効率が全く向上していないわけではありません。 精緻な計測や比較は難しいですが、見積もりに対しての実績、つまり設計から実装ユニットテストまでで言えば、案件によっては1.2倍から1.5倍程度の効果が出ていると感じます。 しかし、本来AIが持つポテンシャルはこんなものではないはずです。数倍以上の劇的な変化を起こせるのではないか。そのためには既存の開発プロセスにAIを組み込んで多少効率化するだけでなく、プロセスそのものをAI中心の考え方へ変革する必要がある、と考えるようになりました。
ワークショップでの実践と学び：AWS AI-DLCで手に入れたいくつかの武器
そのような課題感を持っていた中で、アマゾンウェブサービスジャパン合同会社が提供する「AI-DLC (AI-Driven Development Life Cycle) Unicorn Gym」というワークショップに参加する機会を得ました。 AI-DLCは、AIを開発の主役と捉え、企画から設計、実装、テストに至るまでの全てのライフサイクルをAIと共に進めるという考え方です。この機会を頂いた際に、強い期待を抱いたことを覚えています。
結論から言うと、期待以上に得たものがあったワークショップでした。
ワークショップは3日間にわたって行われました。 開始から半日ほどは、講師陣に用意していただいたサンプル案件を元に、AI-DLCを体験してみる時間でした。 その後、残った2.5日間を利用して実際に食べログの開発案件を進めてみるという流れのワークショップでした。 うまくいけば3日間で案件を1つリリース可能ということになりますね。
AI-DLCの概要と、我々の3日間を紹介します。
AI-DLCの概要
AI-DLCは「AI駆動開発ライフサイクル（AI-Driven Development Life Cycle）」の略です。 開発プロセスの一部をAIに任せるだけではなく、開発プロセスそのものを「AI主体」に変えることで、生産性を向上させるためのものとなります。 我々のAI活用では、人間がAIに指示を出す、それこそ新しい人を迎え入れた直後と同じことをしていました。 しかしながらAI-DLCのプロセスは、人間がAIに指示を出すのではなく、AIが作業計画を提案し、人間がそれを確認・承認するという逆転の発想で進められます。 プロセスは3つのフェーズに分かれています。
「AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築」より引用
1つ目のフェーズ: Inceptionフェーズと呼ばれ、「何を作るか」を決定し、それを具体的な作業単位に分割するフェーズと理解しました。
2つ目のフェーズ: Constructionフェーズと呼ばれ、Inceptionフェーズにて分割された作業単位ごとに、設計と実装を進めるフェーズと理解しました。
3つ目のフェーズ: Operationフェーズと呼ばれ、Constructionフェーズにて実装したプログラムをデプロイ、保守運用を行なっていくフェーズのようです。今回のワークショップでは体験しませんでした。
今回のワークショップでは、InceptionフェーズとConstructionフェーズを体験しました。 前述の通りAIが作業計画を提案し、人間が承認します。計画の実行もAIが行いますので、人間は提案に対する意思決定に集中できます。 チームメンバーが一ヶ所に集まり密なコミュニケーションを取りながら意思決定を進めること、またAIのスピーディーな提案速度により、非常に速い速度で開発が進むことを実感できました。
具体的にワークショップの様子をお届けします。
1日目：座学。そして案件を開始
まずはサンプルの案件を元に、AI-DLCを体験しました。 プロンプトも頂いたものを利用して流れを把握するのが、午前中から午後イチにかけて行なったことです。 この時DDDを用いて設計しましたが、巨大なコードベースを持ち、DDDでないアーキテクチャの食べログでは難しいかも・・という印象を受けました。 一旦ここで全体の流れや、利用するプロンプトを把握します。
午後からは実際の案件に取り掛かります。 Inceptionフェーズなので、ユーザーストーリーを出していくところから始めました。 我々のチームがどのような案件に取り組んだか紹介したいところですが・・・まだ紹介できないのが残念です。
ユーザーストーリーを検討するためのステップと、それに必要なQuestionをAIに提示させ、人間が答えていくという作業を進めます。これは企画・デザイナー・エンジニアで話し合いながら進めました。 我々のチームでは異常系のユースケースを出しきろうと頑張った結果、この日はInceptionフェーズを終えることが出来ず、明日に持ち越しとなってしまいました。 これについて講師の方から、異常系よりもメインとなるユーザーストーリーを先に決めて進めてしまった方が良いとアドバイス頂きました。
講師陣からお菓子の差し入れもいただき、和やかな雰囲気でワークショップを進行することができました。
2日目：InceptionフェーズからConstructionフェーズへ
Inceptionフェーズの続きから始めました。 できるだけ早くConstructionフェーズに移行したかったため、前日の反省を活かし、代表的なユーザーストーリーをまとめることに集中した結果、午前中にInceptionフェーズを完了させることができました。 ここでAI-DLCの良さが発揮されます。ユーザーストーリーを検討するためのステップとそれに必要なQuestion＆Anserを成果物として出しているので、やり直しが簡単にできるのです。カオスになってしまったユーザーストーリーとユースケースは一旦捨て、残していたステップをやり直させるだけで済みます。AIはスクラップ＆ビルドがやりやすいという話はありましたが、それをうまく利用したやり方でとても良いと感じました。
午後からConstructionフェーズへと進みましたが、ここからはエンジニアメインのターンでした。 サンプル案件ではDDDを用いて設計したのですが、前述の通り食べログの設計に合うとは思えなかったため、コードを調査させ、その結果をもとに設計をしてもらうという方針に変えました。 プロンプトの例も教えていただき、すんなりと進めることができました。
前述の通りConstructionフェーズはエンジニア主体でしたが、UIやエラー処理などで企画やデザイナーと会話することもあり、チーム全体で進めていきました。 ちなみに・・・会話しながら進めると集中する時間が長くなるため、2日目の夕方くらいから疲れが見え始めます。
3日目：Constructionフェーズ大詰め
3日目はConstructionフェーズを進め、できる限り動くものを作ろうとガンガン進めました。 今回は外部連携のある案件を行なったため、インフラ関連の整備も必要であり3日で終わらせることはできませんでした。それでもMockを駆使しつつ、動くものを作ることで最終的にデモをしながら成果発表できました。
3日目は2日目よりも会話が少なくなり、黙々と作業する日でした。 集中する時間がさらに増えたため、午後は疲労感も強くなり、終わった後の疲労困憊っぷりは近年稀に見るレベルでした。 とはいえ、これは使える！という感覚があり、さあ明日からどうしようかという気持ちで終えることができました。
ワークショップを通じて得ることが出来た新しい武器
ワークショップでは、すぐに活かしたくなるような学びがいくつかありました。それを紹介します。
AI主体の開発プロセス
このワークショップを通じて得た最大の武器は、当然ではあるものの「AI主体の開発プロセス」です。これまでは人間がAIに作業を「依頼」していましたが、AIに「段取りから提案させる」という全く逆の発想を知ることができました。 これには2点の良さがあると感じました。
- 人間が必要だと思う情報を全てインプットするのではなく、AIが自ら疑問点を挙げてくることに答える。これにより、AIが必要とする最低限まで成果物を減らすことが可能。
- 人間の考える時間が大きく減る。何が必要か？を考えてまとめる時間がなくなり、とりあえずAIに提案させてみることで一歩を踏み出すのが早くなる。
前者は無駄な成果物を減らすことができ、後者は無駄に考えて進まないということが減ります。
各フェーズの中でもステップごとに成果物を残す
例えばInceptionフェーズでは、ユーザーストーリーの作成→ユニットに分割 という流れで作業していきますが、成果物はもっと細かく残します。これは2日目の紹介の中でもお伝えしたことですね。 ユーザーストーリーを作るための計画を立て、それを人間が承認することで計画通りに進めるのですが、計画の時点で成果物を残します。 こうすることで、後のステップでうまくいかなかった場合、計画を少し修正してやり直すということが簡単に出来ます。
Constructionフェーズに移る際のインプットが、「ユニット」という作業単位であること
前述の通り、食べログではDDDでの設計が難しいという課題があります。もしConstructionフェーズへのインプットがDDDによる設計書だった場合、食べログへの導入ハードルは非常に高くなっていたはずです。しかしながらユニットという作業単位であれば、設計手法やアーキテクチャの影響を全く受けないため、非常に汎用的だと思いました。 あまり目立ちませんが、これはAI-DLCの考え方の中で最も巧妙な点ではないかと感じています。
食べログの開発現場を『AIネイティブ』に変える 一歩目
ワークショップで得た知見を元に、早速私たちのチームで、新しい開発プロセスの導入を始めました。
これまでの開発プロセスと課題
これまでは普通のウォーターフォール型の開発をしていました。 企画担当者にて要求定義から要件定義、機能設計までを行い、それを受け取ってエンジニアが設計開発を行う流れでした。 上流工程には必要に応じてエンジニアやデザイナーが協力します。
至って普通のやり方ではありますが、エンジニアに声がかかった時には過剰な成果物が作られていたり、逆に必要な情報はないといったすれ違いが起こることがありました。 そこからすり合わせを始めるため、無駄に時間がかかってしまうことが多くなっていました。早くエンジニアに声をかけてもらうことで解消していたものの、忙しいときなどは対応できないこともありました。
AI-DLCの導入と期待する効果
AI-DLCを参考にし、以下のようなプロセスを適用しました。
Inceptionフェーズ
- 企画は課題感とやりたいことが決まった段階でテキストにする。これは少ない時だと1行から2行で済むような少ない文章量となる。
- 上記のテキスト及び、修正対象のプログラム（Githubのリポジトリ）をAIに渡し、開発計画と人間がサポートすべきところをQuestionとして挙げさせる。
- この時、AIはある程度の実装調査を行った上で、開発計画やQuestionを挙げてくる。
- Questionを企画・エンジニアそれぞれで分担し回答する。
- 回答をAIに渡し、その上で再度開発計画の見直しとQuestionの有無を確認する。
- Questionが無くなり、計画も良いものが出てきたら、ユニットに分割してConstructionフェーズに移行する。
Constructionフェーズ
- ユニット単位でAIに設計・開発してもらう
- レビュー及びテストは人間が実施する
期待する効果
このプロセスによって期待している効果は以下の通りです。
- AIが必要な情報を提示してくれるため、情報収集や資料作成が最低限で済む。
- チームメンバー全員がQuestionへの回答に取り組むため、知識が共有される。しかも短い時間で行われるため負担にならない。
- 人間が考える時間を減らすこと、要件定義から実装までの複数のステップをAIが一気に行うことで、開発プロセスが簡略化されること。
- AIと共に開発を進めていく習慣をつけることで、人間の作る成果物がよりAIを前提したものに変わっていくこと。それにより案件をこなすごとに『AIネイティブ』な開発プロセスへの昇華が進むことを目指しています。
実際の効果
この新しいプロセスを導入してまだ日は浅いですが、すでにいくつかの明確な効果が現れています。
これまで作成に多大な時間を費やしていた重厚な成果物は、驚くほど簡素なものになりました。 もちろん案件の規模にもよりますが、これまでであれば簡素な情報だけで進められたはずの案件でも重厚な成果物を作ることがあったため、大きな変化となりました。 またQuestionへの回答をチーム全員で行なっていることで、知識の共有が促進されています。今までは全員で要件を見ることは工数の面から避けていましたが、AIがポイントを絞ってQuestionを挙げているため、小さな工数で知識共有が可能になったと評判です。
最も大きな変化は、企画担当者とエンジニアが並行作業可能になったことです。 これまでは、企画担当者の要件まとめ等が終わってからエンジニアにバトンタッチという直列的な進め方だったものが、前段でAIが論点やQuestionを洗い出してくれることにより、企画とエンジニアの作業を並行して進められるようになりました。 期待していた「プロセスごと変えたい」ということができてきています。
今後の展望：開発プロセスを数倍にするための取り組み計画
この一歩目の成功を足がかりに、私たちは開発プロセス全体の変革をさらに加速させていきたいと考えています。
短期計画（半年以内）：リードタイム半減で、より困難な課題へ
我々のチームが扱う案件の8割に、この新しいプロセスを適用することを目指します。 これにより、対象案件の開発リードタイムを50%削減、つまりリリース速度を倍にすることが目標です。 そしてこのプロセス改革によって創出されたエンジニアリングリソースを、適用が難しい残りの2割の案件で活用したいです。例えば大規模な改修が必要な案件や、技術的負債の返済、アーキテクチャの改善といった、より本質的な課題に集中できる体制を構築します。
中長期計画（半年後〜）：AIとの協業による人間の役割の進化と、次なる挑戦
長期的には、エンジニアと企画担当者の役割そのものを再定義していきたいと考えています。 AIによって単純な作業や情報収集から解放された我々は、より上流の戦略策定や、「どの課題を解くべきか」というビジネスの根幹に関わる問いに対して、より多くの時間を使うことができるようになります。 これにより、個々の案件を高速化するだけでなく、組織全体のリリース数を数倍に引き上げることを目指します。
現在はまだ初期段階に過ぎませんが、新しいプロセスに慣れ、改善して洗練していくことで、複数のチームを跨ぐような大規模案件でも同様のプロセスを適用したいと考えています。 かなり難しいことだとは思いますが、AIの進化は目覚ましく、できないことではないと考えています。
この記事が、AIと共に開発の未来を模索する、皆さんの新たな一歩に繋がれば幸いです。 気になる方はぜひ AWS AI-DLC を学んでみてください。そしてもしチャンスがあれば Unicorn gym も受講してみてください。
