エンジニアの関口です。先日、社内でAI-DLCのワークショップを開催しました。 先月、AWSのAI-DLCに参加した際、「社内でもやってみたい」と感じ、今回の開催につながりました。
https://aws.amazon.com/jp/blogs/news/yayoi-ai-dlc/
この記事では、当日の流れや、個人・チームで試して得た気づきに加えて、アンケートの集計結果をもとにしたレポートを紹介します。
AI-DLCとは
AI-DLC（AI-Driven Development Life Cycle）は、AWSが提唱するAIを中心に据えた開発ライフサイクルです。 AIが計画や成果物の作成を進め、人間はレビューと意思決定に集中することで、開発のスピードと品質の両立を目指します。
詳しくはAWSの解説記事を参照してください。
https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/
開催の目的
AI-DLCの実践を体験し、日々の開発に持ち帰るきっかけを作ることが目的です。 あわせて、個人ワークとチームワークの両方で使い所を見つけ、チーム内の共通言語を増やしていく狙いがありました。
当日の流れ
当日は、午前と午後で内容を分けて進めました。
- 午前（座学 + 個人ワーク）
- AI-DLCの概要と進め方を座学で共有
- ECサイトを題材に、AI-DLCを個人で実践
- 午後（チームワーク）
- 各プロダクトの課題を持ち寄り、チームでAI-DLCを実践
午前：個人ワーク
個人ワークでは、ECサイトを題材にAI-DLCを実践しました。想像以上に集中して取り組めて、 各自が「どう使うと良さそうか」を手を動かしながら掴めたのが大きな収穫でした。
具体的にやったこと
- 座学でAI-DLCの概要と進め方を共有
- ECサイトを題材に、ユーザーストーリー作成からタスク分割までを体験
- ドメインモデリングと実装を進め、HTMLモックまで作成
午後：チームワーク
午後は各プロダクトのチームが持ち寄った課題やテーマを元にAI-DLCを実践しました。 すでにチームビルディングが進んでいたこともあり、スムーズに議論と実装が進みました。
チームで得られた学び
ドメインを深く理解している前提があると、AIの出力精度も上がると感じました。 モデルの良し悪し以前に、ドメイン知識の有無が成果物の質に大きく影響します。 チームにカスタマーサクセスなど実際にお客様の声を知るメンバーが参加すると、実装の質やゴールの明確さが高まり、AIの出力も良くなるのではないかという学びがありました。
アンケート結果と参加者の声
アンケートの定量・定性の結果を整理しました。内容は全体傾向のサマリです。
アンケート分析（定量）
全体
実際にゴールまで行けたチームもおり、個人ワークでも動くものをワーク内で作れたことから、 全体の満足度が高かったと感じています。
午前（個人ワーク）
- ツールの操作に一部「難しい」傾向があり、回答者は技術職以外に偏っていた
- 業務活用のイメージは大半が持てていた一方で、ドキュメント駆動でのレビュー工数や チームでの共通認識づくりに課題感があるという声もあった
午後（チームワーク）
- サポートメンバーの対応に良い評価が集まった
- 活用度は午前よりやや低い結果
アンケート分析（定性）
回答が多い項目をグルーピングして整理しました。
午前：業務に活用する上での課題
- 既存コードの変更への応用
- プロンプト作成（テンプレートの改変）
- コード品質と保守性（レビューやドメイン知識への懸念を含む）
既存コードへの適用は影響範囲が大きくなりやすく、プロセスと判断基準の整理が必要だと感じました。 また、プロンプトはテンプレートを前提にしつつ、現場ごとの調整余地を残す設計が大切です。
午前：良かった点・印象に残った点
- ほぼポジティブな内容で、ワークショップとして完成度が高い
- 待ち時間が長く手持ち無沙汰になる場面があり、並行稼働の体験を入れても良かった
内容自体は評価が高かった一方で、進行の組み方次第で体験価値をさらに上げられる余地があると感じました。
午後：業務に活用する上での課題
- チームへどのように、どこまで導入するか
- 生成物のレビュー負荷
- 事前の標準化・明文化
- 技術職以外での活用
チーム運用に載せる際は、標準化とレビュー負荷の整理がボトルネックになりやすいと受け止めています。 職種やスキルが異なる参加を前提にすると、前提知識の差を埋める設計がより重要になります。
午後：良かった点・印象に残った点
- 技術職以外の参加者が開発プロセスを体験できた
- モブワークでの意思決定が速い
体験型の進行が、職種を越えた共通理解の形成に効果的でした。
午後：改善してほしい点
- PBI作成までのステップが多く、後工程へ進むのに時間がかかった
- AIよりもモブワーク体験を強調した方が良かったという声があった
- 午前参加者と午後参加者の情報格差が出た
- 1dayで実施する、あるいは複数日に分ける案が出た
- 職種やスキルに応じた超入門講座があると理解が深まりそう
時間配分と目的の明確化が鍵で、どの体験を優先するかを事前に言語化しておく必要があると感じました。
アンケート分析まとめ（総評）
参加者の満足度とフィードバックから、ワークショップとしては成功と言えそうです。 特にドキュメント駆動でAIと対話していく体験はインパクトが大きく、継続したいという声が多くありました。
午前は狙いどおり、Cursorの使い方とドキュメント駆動の体験につながりました。 一方で午後は、モブワークや意思決定の体験よりもツールやフローの体験に寄ってしまいました。 狙いと少しずれた点があったため、次回に向けて改善していきます。
ワークショップの改善点
改善点としては、まずCursorの習熟度の差を埋める事前教材の用意が必要です。 その上で、複数人での意思決定の速さを体験できるように進行を設計し、途中で終わらず最後までやりきれる構成に調整したいと考えています。 時間の取り方は、1dayでまとめて実施するか、複数日に分けてデプロイまでを目指すか、目的に合わせて再検討していきます。
AI駆動開発の浸透に向けて
- プロンプト作成の基礎やテンプレート活用のコンテンツ提供
- 既存コード変更への応用プロセスの整理（影響範囲が大きい領域の検討が必要）
- ドキュメンテーションルールの標準化で生成物の精度を上げる
- レビュー負荷削減のためのQA方針の再設計と自動化
- 職種やスキルに応じた基礎講座で活用ハードルを下げる
浸透に向けては、学習コンテンツと運用ルールの両輪で整備することが重要だと考えています。
サポートメンバーの声
午前（個人ワーク）のサポートで感じたこと
- 個人ワークでは、まず小さく試すことで迷いなく進められる実感がありました。
- 細かいエディタの操作の説明は必要でしたが、AIを普段から使っている参加者が多く、事前の共有事項が少なくてももくもくと進めていた印象がありました。
- 皆が黙々と進めていたので、裏でAIを使ってバグ取りを進められました。
- 非エンジニアも多く参加してもらいましたが、皆さんのITリテラシーが高く、想定よりもサポート不要だったのが印象的でした
午後（チームワーク）のサポートで感じたこと
- 役割分担と判断基準の共有が進行のスムーズさに直結することを再確認しました。
- チームのワークでは、もう少し議論が起きると想定していました。
- 実際は、チームビルディングが進んでいるチームほど入り口がスムーズでした。
- 実際の議論を見ていても、成熟したチームでは阿吽の呼吸で意思決定が進み、そのような場面を多く見ました。
- サポートメンバーを担うハードルは低かったです。「人間が考え込まず AI に案を考えてもらう」「結果が合わなければ捨ててやり直す」など、AI-DLC の習慣を伝えるだけで良いと感じました。技術的なことを教えるワークではないためです。
- チームでわいわい進めてくれていたので、合間に軽食を取る余裕がありました。
- グループワークが進むにつれ、チームでの意思決定にAIを使用するフローに適応していくのを実感しました
まとめ
今回のワークショップでは、個人とチームの両方でAI-DLCの使い所を確認できました。 特に「小さく試して学ぶ」「チームで判断基準を揃える」といった工夫が効果的でした。 引き続き、日々の開発で実践を重ねながら運用を整えていきます。
www.yayoi-kk.co.jp
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp
