AI-DLCワークショップに参加したふりかえり
会社で、AWSさんの開催するAI-DLCというワークショップに参加しました。
個人的に体験が良かったので、実施したことを感想をまとめておきます。
AL-DLCとは？
AI-Driven Development Life Cycleの略で、AI駆動開発ライフサイクルを意味します。 以下の3つのフェーズに分かれて、開発をしていきます。ワークショップでは、3つのフェーズのうち、Inceptionフェーズ、Constructionフェーズを体験しました。
-
Inception フェーズ AIが質問を通じて、ビジネス意図を詳細な要件、ストーリー、ユニットに変換するフェーズ
-
Construction フェーズ AIの問いに答えながら、技術的決定とアーキテクチャを決定するフェーズ
-
Operation フェーズ Infrastructure as Code とデプロイメントを管理するフェーズ
個人的には、一言で言うとAIをセレモニーの中心に据えて、AIの問いに対して、集まった人間がレスポンスを返していき、具体的なアーティファクトを作っていくアプローチであると感じました。
より正確な内容は、以下の記事を確認するのが良いと思います。
ワークショップの事前準備
ワークショップの事前準備として、チームで取り組むテーマの剪定をしました。
事前にチームで、「ワークショップを通じての学びを最大化する」というゴールで合意は取れていたので、それが満たせるように、テーマに以下の条件を設定しました。
-
チームメンバーの持っている情報のみで解決できるテーマであること 誰かのお伺いを立てる必要のない。チームメンバーだけで解決まで辿りつけないと、Inceptionフェーズで止まってしまう懸念があったため、チームメンバーのみで解決できる可能性が高いテーマを選択しました。
-
3日間でプロダクション品質まで、持ち込める大きさのテーマであること.
現在関わっているプロダクトは、本番リリースに別チームの協力が必要になります。
自チームのみでプロダクション品質まで持ち込んでリリースが実施できるように、プロダクトの直接的な機能開発ではなく、周辺のツール開発をテーマとしました。
また、AI-DLCの事前の情報収集として、ちょうどよくCompassで以下のイベントが立っていたので、参加してどのような体験になるのかを想像していました。
２つのセッションで、以下のようなことを考えていました。
-
生成AIがソフトウェア開発の中心にある前提だと、スクラムというサイクルは長すぎる。
わたしのスクラムチームは、スプリント期間が2週間ですが、少なくとも2週間サイクルは長すぎると思いました。移行期間という意味だと、1週間くらいがちょうど良い？ -
セレモニー設定は工夫が必要そう. ボルトが不定期の開発機関であるというところから、チームの構成メンバーの兼務が多いと、不定期スプリントはとても予定が抑えにくそうには思いました。
懸念はありつつ、少なくともエッセンスは取り入れるべき、何か面白そうに思いました。
ワークショップの成果物と、ふりかえり
ワークショップの成果物について
ワークショップがどのような進行であったか？は、問題もありそうなので、記載しません。インクリメントとしては、3日間を通して、チームに引き渡しができるくらいの完成度になりました。ただ、運用フェーズでどうなっているのか？などの部分はチームで決めきれないことはある。どうしても改善したい部分はあるが、全体感を考慮すると一旦、優先度を下げる部分などは存在しました。
ふりかえり
今回のAI-DLCワークショップでの体験や気づきを整理します。
1. モブのチーム構成と多様な観点
AI駆動開発ライフサイクルでは、AIがプロセスの中心に立ち、人間がその問いに答えながら要件定義（インセプション）や設計（コンストラクション）を進めます。この時、モブの構成が非常に重要になります。
-
問題領域に知見がある人を揃える（インサイトの確保）:
インセプションフェーズ中、AIの問いかけに答えられないと作業が停止し、調査が発生してしまいます。人間の脳内や暗黙知、文脈にある情報はAI単体では調べられないため、モブの中に問題領域のドメイン知識（知見）を持った人がいることが重要に思いました。 -
多様な「考える帽子」による観点の注入:
AIの出力した成果物のレビューや問いかけに対応する際、メンバーが多様な視点（考えの幅）を持っていると、さまざまな観点を設計に注入できます。観点の深さだけでなく、幅広さがあること自体がインクリメントの品質を向上させます。 -
モブワークに慣れた人間の存在:
チームの中にモブプログラミングやモブワークの進め方に慣れた人間がいることで、AIとのやり取りを円滑に整理・進行する潤滑油となります。また、設計プロセスの「チームによる違い」を理解し、やり方を受け入れる柔軟さも求められます。
2. 同期・非同期の設計と「モブの密度」
AIが実装（コンストラクション）やコード生成を行っている時間は、人間側に応答待ち（アイドル時間）が発生します。この時間の段取りが必要に思いました。
-
応答待ち時間（非同期時間）の段取り:
AIの応答待ちの時間に、誰が何をして、誰が何もしないか（あえてやらないことを許容するか）という設計があらかじめ必要です。 -
「モブの密度」と役割分担のトレードオフ:
ワークショップでは「AIドライブ役」と「テスト検証役」に分業しがちでした。しかし、待ち時間を埋めるために安易に分散するより、モブの密度を保って全員で議論を同期し、モブレビューを行う方がプロセスが円滑になります。 -
「ユニット・オブ・ワーク」によるタスクの切り方:
AIに依頼するタスク粒度が大きいと、待ち時間が長引いてモブの集中力が切れます。タスク（ユニット・オブ・ワーク）を細かく分割し、応答待ち時間を最小化することが、モブの集中と密度を維持する鍵になります。
3. 受け入れ
- AIが作ったものを受け入れる難しさ（限界と合意形成）:
AIが一度に生成するコード量が多く、かつ受け入れ基準を人間側が把握しきれないと、レビューが破綻します。ここでもタスクを適切なサイズ（ユニット・オブ・ワーク）に分割して受け入れる設計が求められます。
今後につながる良い体験をさせてもらいました。
仕事にも活かせる部分は積極的に取り入れていきたいと思いました。