「AIと一緒に開発する」を本格始動して 1ヶ月の振り返り

「カミナシ レポート」の開発・運用をしている furuya です。最近我が家では成長してきた子どもたちのことを考えて寝室含めて部屋の配置換えを検討しており、そのパズルに頭を悩ませています。それはさておき今回は「カミナシ レポート」の開発において AI Agent を主軸にした開発スタイルを取り入れたお話です。

背景

近年の AI Agent の進化は目覚ましいですね。日々情報がアップデートされる中、カミナシのエンジニアリング組織としてもこの流れについていかなければならない、ということで各チームいろんなことにトライしており、組織的にもそれが推奨されています。もちろん、前提として以前から GitHub Copilot や Claude Code などの Coding Agent を開発に取り入れています。そんな中で個人的に感じた課題と同時期に得た学びがカチッとはまる出来事がありました。

課題

以前の開発スタイルはこうでした。

• 1週間スプリントのスクラム
• PdM、デザイナー含めて PBI をリファインメントする
  • ここでおおよその実装方針の合意やフロントエンド・バックエンドそれぞれでチケットを作成し、ストーリーポイントを見積もる
• ストーリーポイントをもとに1スプリントで捌くチケットを決め、おおよそ1チケット1担当者で分担して開発を進める
  • フロントエンドは xx さん、バックエンドは yy さんといった具合
  • それぞれが自分の進め方（AI Agent の使い方含めて）で進める
    • Copilot Instruction 等チームで共有すべきコンテキストは随時整備している

2025年12月頃、しばらく私が重めのインフラ構築をやっており久しぶりに開発に戻ってきました。今までの進め方自体に大きな問題はなかったのですが、あらためて1人で開発を進めているときに以下の課題・違和感を覚えました。

• リファインメントの段階では見えていなかった詳細な要件が、実装フェーズに入ってから顕在化することがある
  • Slack 上で非同期で PdM やデザイナーに確認するだけではありつつ、待ちやラリーが発生するため結局同期で話すことも
• Agent が出してきたコードをレビューしきれない
  • 一度に多く出てくると目が滑るのと、個人的にはフロントエンドの引き出しが少ないのでセルフレビューに不安が残る
• Agent によってコード生成は早くなったが、レビュー依頼を出したあとアンコントローラブルになる・待ちが発生する
  • スプリントゴールに紐づくアイテムの場合はもちろんみんな優先して見てくれるものの、それぞれタスクを持っているのもありいつ終わるかは明確ではない

AI-DLC という考え方との出会い

ちょうど同じ頃、AWS re:Invent 2025 への参加をきっかけに AI 周りの解像度が高くなった中、AI Builders Day というイベントで AI-DLC という手法に出会いました。

speakerdeck.com

詳細は上記 AWS 金森さんの資料などをご覧いただければと思うのですが、この話を聞いた瞬間に「チームでやってみたい！」と思いました。先程の課題は AI-DLC の考え方を適用することで解決できるのでは？と感じたからです。もちろんいきなりスクラムをやめるまでいくと混乱しそうなので、「AI Agent 主体で進める」「ペア・モブプロで進める」というあたりだけでも取り込むことで以下の効果が期待できるのではないか、と思いました。

• AI による観点が加わることで要件のヌケモレに気づきやすくなる
  • 要件を人間 + AI で決め、そのままドキュメント（requirements.md）に落とし込むため
• 熟練者のレビュー観点・引き出しを盗める
  • みんなで AI Agent の出したコードをその場でレビューすることのメリット
• PR作成からマージOKのリードタイムが短くなる
  • みんなでレビューするので、待たなくてよさそう

チームに持ち込む

AI-DLC の解像度はあまり高くないままではありましたが、上記の課題感およびこんな手法があってね、という話をチームに持っていき、やってみよう、ということになりました。チームとしてもメンバーの入れ替わりや長期離脱の予定があるなど変化の激しいタイミングであり、生産性を落とさないため & AI への投資ということで意見が一致しました。

やってみた

本来の AI-DLC のやり方、というよりはスクラムの形を保ったままとりあえずやってみるということで、どちらかというと仕様駆動開発として AWS の AI-DLC workflow を使う、というほうがイメージに近そうです。

github.com

Agent には主に kiro（kiro-cli）を使っています。スタートアップ向けのクレジットをいただいたので、使わないと損だなと個人的に思っているからです。workflow 自体はいわばプロンプトでありどの Agent にも組み込めるため、 Claude Code でやってみるターンもあってもいいかもしれません。

まずはペア or モブで進め、スクラムの形は変えない、というところからスタートします。ここから少し長いですが、4スプリント分のゴール設定・結果・振り返りについて共有します。

1週目

ちょうど直近大きめの開発アイテムがあったため「リファインメント + ちょっと実装まで進んでいる」をゴールにしてトライしました。

結果として、リリース順序やデータベースの変更等も考慮して Phase を4つに分割し、それぞれの設計までできました。また Phase 1 の実装は PR の作成まで完了しました。以下振り返りです（以降同様のフォーマットです）。

• Phase ごとにわけて「設計だけやる」はイマイチかも
  • 設計を進めるには前の実装が終わっていることが前提で、かつ設計のみ進めた場合前の Phase の実装がまだないので Agent が混乱する
• 開発体験としてはポジティブ、workflow に則って設計開発進めること自体はよさそう
  • PR の粒度や Design Doc の渡し方など改善ポイントが見えてきた
• このアイテムに関してはいったんこの進め方で最後までやってみる
  • が、見積もりをしないのでいつ終わりそうか、みたいなのが言いづらくなる懸念も
  • もちろんダメそうだったらすぐ止めるということも合意する

2週目

前週とは別のアイテムを対応する必要があり、そちらで引き続き workflow に則って実施しました。

設計 & 実装は1日で完了（フロントエンド、バックエンドともに）し、2日目にガッツリレビューをするという流れで難なく完了まで持っていけました。

• 1日ガツっと実装して次の日別れてレビューなどに回すのはアリかも
  • やっぱりずっとやり続けるのはちょっとしんどい
    • 真の AI-DLC を実践してるところは永久にペアプロしてるらしいけど…
  • GitHub Copilot が PR でいっぱい指摘くれるので修正する時間や、次のアイテムの下準備の時間が必要

3週目

1週目で分割したアイテムの続きに取り組みました。また、新たなトライとして以下を検証しました。

• Figma MCP サーバーを使ってフロントエンドの実装を楽にできるか検証する
• フロントエンドとバックエンドのリポジトリが別れているが、いい感じにまとめて設計実装できないか試行錯誤する
  • 最終的にモノレポがいいのであればそれも視野に入れる

トライ多めだったので実装は思ったところまでは進みませんでしたが、その分収穫がありました。

• Figma MCP サーバーを使って実装してもらうとデザイナーが作ったものがそのまま反映できてよい（それはそう）
  • Figma に情報がある場合はデザイナーと一緒にフロントエンド実装できるとよさそう
  • なんならデザイナーがドライバーになって進めてもらった（実装できるデザイナー！）
• 設計をフロントエンド・バックエンド両方いっぺんにやると設計のターンが長くなりがち
  • デザイナーと一緒にモブしたいのは、UXにまつわる要件の整理とフロントエンドの実装タイミングなのでうまいことできないか考える（待ち時間の削減）

4週目

引き続き Phase 3 の実装を進めます。この週は kiro の steering の整備をしました。steering は Claude Code でいうところの Claude.md のようなもので、チームで共有すべき永続化したい知識をまとめたドキュメントです。

あと一歩のところでゴール未達となりましたが「1週間でこれくらいまで進めることができる」というラインをまたひとつ得ることができました。

• steering を整えることでセルフレビュー観点の質が向上した
  • 開発側でも活用できるように引き続き育てていく

1ヶ月を振り返って

やり方についてはポジティブ

もちろん課題・伸びしろはいくつもあるのですが、それをよくしていけばなんだかよさそうである、というのがメンバーの総意です。

最初に狙っていた効果は？

• AI による観点が加わることで要件のヌケモレに気づきやすくなる

これは実際救われたケースがあります。重複するのですが、UX観点ではやはり AI による視点 + デザイナーと一緒に作業することで効率よく体験を決定できました。

• デキる人のレビュー観点・引き出しを盗める
• PR作成からマージOKのリードタイムが短くなる

その場でのレビューも行うもののやはりガッツリレビューするのは落ち着いて次の日にやる、といったスタイルが今のところチームにあっていそうです。もちろん会話する中での気づきもあったりその場でコードやテストを Agent に直してもらったりすることもあるので、この点については中長期的に見ていくものになりそうです。

生産性あがったの？

AI-DLC が狙うのは生産性を数倍に引き上げるというものですが、今回はその一部を取り入れてみた、というものになったのと今までのスタイルと単純な比較ができないので正直なところ不明です。ただ、チーム外から見た感覚だと「思ったより早く進んでいる」「ケイパビリティが上がったように見える」とのことで、ちゃんといい方向で効果が出ていそうです。おそらく以下のようなことだと推測しています。

• 明確に仕様駆動開発に寄せることで AI Agent の使い方を統一でき、効率があがった
  • 今までだと、コンテキストとしてのコーディング規約などは整備していたものの、実際に実装するときは各自 Agent に要件のプロンプトを渡してどちらかというと Vibe Coding チックに進めていた
• ペア・モブでも捌くチケット量は変わっていなさそう（か、少し増えた）
  • 1つめの要因のこともあり、2人で進めても今までの2人分くらいがきちんとできている = 人によるばらつきが減って安定して速度を出せていそう
• ペア・モブの時間だけで今までのチケットを捌けているので、それ以外の時間でやれることが増えた
  • 逆にレビューDayはレビューと修正に集中できるので、時折やってくる他チームからのレビューなどにも応えやすくなった = ケイパビリティが上がったように見えていそう

これから

AI-DLC という考え方に出会い、一部ながらもチームに取り入れて1ヶ月取り組んでみました。実際どれくらい効果があったのか定量的には判断しがたいのですが、AI Agent を主体にした新しいスタイルを採用したことで安定して開発速度をキープできていそうであり、これはチームの状況が変わったとしても価値を提供し続けることができる基盤が整ったと言えそうです。

まだ課題・伸びしろはあるのでこれらを良くしていきたいですし、あるいはこれを突き詰めていけばひょっとすると「真の AI-DLC にしないとダメだ！」といってスクラムをやめる日が来るかもしれません。大事なのは振り返って改善することと、まだまだ AI に投資していくことだと思うので、自分たちのペースで取り組んでいきたいです。