はじめに

こんにちは！先日AWSさん主催の複数社合同ワークショップ「AI-DLC Unicorn Gym」に参加してきました。大阪での開催は今回が初めてとのことで、貴重な機会に参加させていただきました。

このワークショップはめちゃくちゃハードで、めちゃくちゃ学びが多いものでした。1日目と2日目は、ほぼ終日AIと対話し続けていた影響か、寝てる間もAIと格闘している夢を見て、二夜連続でうなされました(笑)
最終的には、笑顔でAIに「キロちゃん、かわいいね👻」と話しかけるくらいには仲良くなることができました！

私は普段、業務効率化のためのプロダクト開発に携わっていますが、そこでのAIは「必要に応じて作業を支援してもらう」という使い方が中心でした。一方で今回のワークショップでは、AIを単なるツールではなく、プロダクト開発のパートナーとして一緒に進める体験ができ、AIとの協働について大きな学びを得ることができました。

この記事では、3日間のワークショップで体験したこと、感じたこと、そして実業務への活用可能性についてまとめます。

3日間の流れ

ここではAI-DLCそのものの詳細な説明は割愛します(ぜひ別の記事も読んでください！)が、具体的な3日間のスケジュールは以下の通りです。

イベントの構成

日程	内容
Day 1 午前	座学 + ハンズオン（ECサイト構築でAI-DLCの流れを体験）
Day 1 午後〜	ワークショップ（自チームのテーマで実践）
Day 2	ワークショップ続き
Day 3	ワークショップ続き + 成果発表

事前課題として、「実業務に活かせるテーマ」を各チームで設定してくることが求められていました。私たちのチームでは、今後重要になると考えている課題として、「アプリケーション開発者自身が必要なITインフラを申請し、即時に環境を払い出せるセルフサービス型のIDP（Internal Developer Platform）を構築する」というテーマに取り組みました。

このテーマは、実はすでに私たちのスクラムチームで少しずつ取り組んでいるものであり、個人的には、今回、「AI-DLCで進めることで、どれだけ効率化できるのか」を検証する目的もありました。

1日目：モニターの下のキロちゃんと一緒にスタート！

2日目：オレンジーズ

ずっと付き添って支援してくださったAWS佐山さん🦄

AI-DLCワークフローで体験したこと

Inceptionフェーズ（価値の定義）

AI-DLCのワークフローは大きく Inception → Construction → Operations の3フェーズに分かれます。

Inceptionフェーズでは以下を順に進めました：

Requirements Analysis — AIが質問を生成し、チームで回答。スコープ・制約・成功基準を明確化
User Stories — ペルソナ定義、エピック分解、ストーリー作成
Workflow Planning — 実行計画の策定
Application Design — 技術選定、コンポーネント設計、外部連携の整理
Units Generation — 実装単位への分解、並行開発戦略の策定

1日目はWorkflow Planningまで進みました。

2日目はApplication Designから入ったのですが、AIの質問に答えていくうちに細かいこだわりや、「いまここでそれは考えなくてもいいのでは？」という問いに時間がかかるようになりました。

「このテーマって、今回のワークショップで何を達成したいんだっけ？」「この場で、何にこだわるべきなんだっけ？」と、チームで目的を整理し直しました。

結局、AI-DLCを使って新規のアプリケーションを作るところに不安はなかったけど、既存のアプリケーションへの機能追加や、アプリ保守という観点での修正のサイクルをまわそうとすると、どんなリスクがあるのか？ も学びたいと思い、「MVPでいこう、いけるところまでAI-DLCのサイクルを何度も回そう」という方針が決まり、そこからMVPのスコープを絞り込んで、一気に前に進めることができました。

Constructionフェーズ（実装）

MVPのスコープが決まったら、実装はめちゃくちゃ速かったです。

契約（APIインターフェース・DBスキーマ）を先に決め、チームで並行開発。AIと協働してコードを生成していきました。

今回作ったのは、開発者が自分でITインフラ環境を申請できるWebアプリです。プロジェクト名・構築フェーズ・コンテナ構成（コンテナ台数・メモリ・スレッド数）、ストレージを入力して送信すると、自動でプロビジョニングが走る仕組みです。

申請フォーム・確認画面・申請一覧・ステータス管理まで、実質1.5日で動くプロトタイプになりました。

普段のスクラム開発なら、開発者2名体制で2〜3スプリント（4〜6週間）かかるような規模感のものです。

この3日間での学び

このワークショップで得た学びをまとめると：

「開発チームにAIを迎える」とはどういうことか、体で理解できた
→ AIはコードを書くだけじゃなく、上流から一緒に考えてくれる仲間だと感じた。ただし、勝手に色々と進めてしまうことがあり、適宜、軌道修正が必要。
ビジネスオーナーも含めた全員で、モブ形式でInceptionを進めることの効果
→ AIの問いに全員で向き合うことで、「なぜこれを作るのか」がチームの共通認識になった
POとして、受け入れ条件づくりが楽になった
→ 日頃はゼロから自分で書いているが、AIの提案をレビューするのは、負荷がまるで違う

そして、一番の学びは、

AIと協働するには、人間のスキルがもっと必要になる

このワークショップで思い知ったのは、AIが作ったものを「正しい」「妥当だ」と判断できるテクニカルスキルが人間側に必要だということです。

AIが出してきた提案が正しいかどうか判断するには、アーキテクチャの知識、インフラの理解、コードの品質判断力が必要で、さらに、ビジネス要件を深く理解した上で「この設計はビジネス価値に合致しているか」を判断する力も必要です。

「AIを使えばこれからの仕事は楽になれる」と思っていたのですが、むしろ「より高度なエンジニアにならないといけないのかーー！！！」と感じた瞬間でもありました。

PPDVとの相性

ちょうどこのイベントの直前に、PPDV（Professional Product Discovery & Validation）の研修を受けていました。

PPDVは、Scrum.orgが提唱するアプローチで、プロダクトの価値に対する仮説を立て、検証のためのエビデンスを集め、投資の意思決定を促進するというものです。「このプロダクトは本当に作る価値があるのか？」を、勘や「経験上こうしよう」ではなく、エビデンスで判断するための手法です。

AI-DLCと組み合わせると、このサイクルが格段に速く回ると感じました：

仮説を立てる → AI-DLCのInceptionフェーズで、ビジネス価値・ユーザーストーリー・受け入れ基準が構造化される。これ自体が「何に価値があると仮定しているか」の明文化になる
エビデンスを集める → Constructionで高速にプロトタイプを作り、実際に動くものを見せながらステークホルダーと議論できる。「これに投資すべきか？」の判断材料が短期間で揃う
意思決定を促進する → 仮説が外れていれば早めに方向転換できる。合っていれば自信を持って投資判断ができる

従来なら「仮説を検証するためのプロトタイプを作るのに数週間かかる」ところが、AI-DLCなら1〜2日で動くものが手に入る。仮説検証のコストが劇的に下がることで、「とりあえず作ってみてから考える」ではなく「エビデンスに基づいて投資判断する」が実現できると感じました。

今後やってみたいこと

既存のアプリにAI-DLCを後から適用する

今回は新規アプリをゼロから作る体験でしたが、実業務では一からアプリを立ち上げることはほとんどなく、既存アプリへの機能追加や保守がほとんどです。すでに動いているアプリにAI-DLCのサイクルを後から組み込むと、どんなリスクや課題があるのかが一番気になっているテーマです。

独自フレームワークへのコーディング支援

私たちのチームでは、独自のアプリケーション開発フレームワークのインフラを企画・設計・構築して提供しています。実際に私が携わっているプロダクト開発もこのフレームワークを利用しています。このフレームワークは、社内情報なので詳しくは書けませんが、本当にもうめちゃくちゃすごいんです。このフレームワークを使って開発しているお客様に対して、AIを使ったコーディング支援をサービスとして提供できないか、そういう可能性も検討してみたいと思っています。

セキュリティを担保した開発支援の仕組みづくり

独自フレームワークは技術情報の塊でもあります。それらを社外に流出させず、高セキュリティな状態でAIの開発支援を受けられるような仕組みを作れないか、セキュリティ部門とも連携しながら、実現方法を探っていきたいです。

おわりに

AWS AI-DLC Unicorn Gymは、「AIと一緒に開発する」の意味を考え直す機会でした。

AIが出す提案の正しさを判断し続けるのは人間の仕事です。でも、AIが構造化してくれた問いに答え、設計を一緒に練り上げ、実装を加速してもらうという協働のスタイルは、確実に開発の在り方を変えると思います。

今回のワークショップで得た知見とノウハウは必ず現場に適用・展開したいと思っています。やるぞー！やるぞー！やるぞー！