はじめに
こんにちは！先日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が構造化してくれた問いに答え、設計を一緒に練り上げ、実装を加速してもらうという協働のスタイルは、確実に開発の在り方を変えると思います。
今回のワークショップで得た知見とノウハウは必ず現場に適用・展開したいと思っています。やるぞー！やるぞー！やるぞー！