KAGAIWeek_仕様駆動開発で開発スピードが爆速になった！その結果生まれたバックログ管理の課題と対策

Transcript

1. 仕様駆動開発で開発スピードが爆速になった！ その結果生まれたバックログ管理の課題と対策 KDDI DIGITAL GATE 兼 KDDIアジャイル開発センター 開発戦略本部開発９部　中島智弘 KAG AI Week: Final Night Offline Meetup!
3. 今から話すこと Learning Outcome ・仕様駆動開発、AI駆動開発によって生まれたPMの負荷・課題が分かる ・課題に対してどう向き合うかを考えるきっかけになる（≠答えが分かる、対策が分かる） ・AI技術の進歩で開発プロセスは変わり続ける Target Audience ・PjM/PdM/SM/PO/POリードをしている人 ・スクラムというフレームワークの中で働いている人 ・AI駆動開発になんらかの課題を抱えている人 今日話さないこと／やらないこと ・プロダクト価値との向き合い方、お金の生み出し方 ・あっと驚くAIのデモ、誰でもできるAIの使い方
4. Agenda ・私の仕事について ・Before:仕様駆動開発がくる前の私の仕事の進め方 ・After:仕様駆動開発によって起きたチームの変化と課題 ・課題に対してどう向き合ったか ・チームで合意したWorking Agreement
5. 私の仕事について ・社内外のプロジェクト立ち上げ支援 ・リサーチ〜アイデア創出〜プロト開発を通した仮説検証 ・1日単位Sprint　スクラムによるアジャイル開発
6. 仕様駆動開発がくる前の私の仕事の進め方 短期の展示会、イベント ・お客様の例 「自分の業務について来月までにAIで何かやりたい」 「でも何をやりたいか決まってない」 仕事の姿勢 ・「宵越しのタスクは持たない」 ・プロダクトバックログは1日に収まるサイズ ・常にリリース可能な状態を維持 　・どこで終わってもフィードバック可能　 　・バックログは細かく分割！！！
7. 仕様駆動開発がやってきた レビューにて... ある日は進捗なし、次の日もなし、、、 さらに次の日はWaiting(レビュー待ち)３個 ・これとこれとこれ一気にやっちゃいました 分割すればするほど開発がやりにくそう ・でも、どうせ次のバックログ作りますよね？
8. developerにどんな変化があったのか？ 仕様駆動開発により… ・実装が早くなった ・設計・開発・テストはAIが全部やってくれる ・AIにこれまでの経緯とやりたいことを伝えなければいけない ・人間が言語化するのに時間がかかる、合っているかを確認するのに時間がかかる その結果、 ・設計・テストが合っているか？に時間をかけなければいけない ・1回の設計〜テストまでの時間は長くなった ・1回が1日で収まらなくなった
9. 現状のイメージをゴルフに例える 細かく刻んでゴールを目指す アイアンだけでうち続ける Before After 時間はかかるが、飛距離が出るドライバーが登場 細かく刻む必要がなくなった わざわざ途中の目標でパター使う必要ない コンテキストインプットに時間がかかる でも、ゴルフボールは 自律的にゴールを目指してくれる
10. KDDI Agile Development Center Corporation 社外秘X コミュニティで繰り広げられる 「AIでソフトウェア開発は もっとアジャイルになっていく！」 「AIが生産性を高めていく！」 というスローガン
11. KDDI Agile Development Center Corporation 社外秘X 世の中に 仕様駆動開発の 開発プロセスの 事例がない
12. KDDI Agile Development Center Corporation 社外秘X まじでこれ皆 どうしてんの？？
13. 唯一見つけた事例 へいしゃ！！！ すごいちかい！！ これ of これ！！！
14. KDDI Agile Development Center Corporation 社外秘X バックログの、 スライスが難しい 見積が難しい え、どうしよう
15. 課題に対してどう向き合ったか 自分でも週末cc-sddで個人開発やってみて理解する そもそもSpec-Driven Development（仕様駆動開発）とは - AIに「構造化された仕様書」を渡して開発を進める手法 - 仕様をMarkdownで記述し、リポジトリで管理 - AIが仕様を読み取り、設計・実装・テストを生成 代表的なツール・フレームワーク - Kiro（AWS）、SpecKit、cc-sdd など
16. Vibe Codingと仕様駆動開発の違い Vibe Coding 仕様駆動開発 入力 プロンプト 曖昧で雰囲気でOK 構造化された仕様書 ブレ 大きい （意図とずれやすい） 小さい （仕様に沿った結果） 追跡性 困難 仕様書が残る 実装の追跡ができる
17. 仕様駆動開発の流れ ①Specを作る ②requirements.md (要件定義書)ができる ③design.md (設計書)ができる ④tasks.md (タスク分解)ができる ⑤プログラムコードが生まれる
18. requirements.md(要件定義書 )はEARSという記法で記されている EARS（Easy Approach to Requirements Syntax） ・Rolls-RoyceのエンジニアAlistair Mavinが2009年に提案 ・要件記述のための構文テンプレート ・自然言語の曖昧さを排除 ・航空宇宙・自動車業界を中心に広く採用
19. requirements.mdの例 # Requirements Document ## Introduction ユーザーは現在地または任意の都市の天気情報をリアルタイムで確認でき、週間予報や気象アラートも受け取れるアプリケーションを構 築する。 ## Requirements ### Requirement 1: 現在の天気表示 **User Story:** ユーザーとして、現在の天気情報を確認したい。それにより外出の準備を適切に行える。 #### Acceptance Criteria 1. WHEN ユーザーがアプリを開いたとき THEN the system SHALL 現在の気温・湿度・風速を表示する 2. WHEN ユーザーが都市名で検索したとき THEN the system SHALL 該当都市の現在の天気情報を 2秒以内に返す 3. IF 位置情報サービスが利用できない場合 THEN the system SHALL 都市名の手動入力フォームを表示する 4. WHILE 天気データを取得中 the system SHALL ローディングインジケーターを表示する ### Requirement 2: 週間天気予報 **User Story:** ユーザーとして、7日間の天気予報を確認したい。それにより週間の予定を計画できる。 #### Acceptance Criteria 1. WHEN ユーザーが「週間予報」タブをクリックしたとき THEN the system SHALL 7日間の日別予報（最高気温・最低気温・天気アイコ 複数のRequirementからなる 1つのRequirement＝１つのユーザーストーリーと複数の受入条件
20. スクラムのプロダクトバックログアイテムと requirements.md似てる？ # Requirements Document ## Introduction 本仕様は、AWSにTerraformでデプロイする天気予報 Webアプリケーションを定義する。 ユーザーは現在地または任意の都市の天気情報をリアルタイムで確認でき、 週間予報や気象アラートも受け取れるアプリケーションを構築する。 ## Requirements ### Requirement 1: 現在の天気表示 **User Story:** ユーザーとして、現在の天気情報を確認したい。それにより外出の準備を適切に行える。 #### Acceptance Criteria 1. WHEN ユーザーがアプリを開いたとき THEN the system SHALL 現在の気温・湿度・風速を表示する 2. WHEN ユーザーが都市名で検索したとき THEN the system SHALL 該当都市の現在の天気情報を 2秒以内に返す 3. IF 位置情報サービスが利用できない場合 THEN the system SHALL 都市名の手動入力フォームを表示する 4. WHILE 天気データを取得中 the system SHALL ローディングインジケーターを表示する ### Requirement 2: 週間天気予報 **User Story:** ユーザーとして、7日間の天気予報を確認したい。それにより週間の予定を計画できる。 #### Acceptance Criteria 1. WHEN ユーザーが「週間予報」タブをクリックしたとき THEN the system SHALL 7日間の日別予報（最高気温・最低気温・天気アイコ ン・降水確率）を表示する 2. WHEN ユーザーが特定の日付をタップしたとき THEN the system SHALL その日の時間帯別詳細予報を展開表示する 3. IF 週間予報データの取得に失敗した場合 THEN the system SHALL キャッシュされた最新データを表示し、「最終更新 : [時刻]」を明示 する requirements.md ユーザーストーリー 「xx(ユーザー)としてxx(機能)したい。 xx(提供価値)だから。」 受入条件 ・xxができること。 ・xxができること。 ・xxができること。 プロダクトバックログアイテム 複数のRequirementからなる 1つのRequirement＝１つのユーザー ストーリーと複数の受入条件 Requirementはバラバラにできない １つのユーザーストーリーと 複数の受入条件 他のPBIと依存関係はない
21. プロダクトバックログアイテムってどうしたらいいの？ requrementsと同じ？？いや、 Specに近い？？ ユーザーストーリー 「xx(ユーザー)としてxx(機能)したい。 xx(提供価値)だから。」 受入条件 ・xxができること。 ・xxができること。 ・xxができること。 ①Specを作る ②requirements.md (仕様書)ができる ③design.md (設計書)ができる ④tasks.md (タスクリスト)ができる ⑤プログラムコードが生まれる ⑥動作確認 ？ プロダクトバックログアイテム
22. (Kiroで採用している )「AI DLCは新しい用語と習慣を導入します」 スクラムじゃないらしい AI 駆動の高度に協調的なアプローチを反映してAI-DLC は新しい用語と習慣を導入します。従来の「スプリント」は「ボルト ( bolts )」に 置き換えられます。これは、週単位ではなく時間や日単位で測定される、より短く集中的な作業サイクルです。エピックは作業単位 ( Units of Work) に置き換えられます。 この用語の変更は、この手法がスピードと継続的デリバリーを重視していることを強調していま す。同様に、他の一般的なアジャイルの用語も AI 中心のワークフローに合わせて再定義され、この手法のソフトウェア開発における革新 的なアプローチをより適切に表現する用語体系が作られています。 https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/
24. KDDI Agile Development Center Corporation 社外秘X スクラムにそのまま 当てはめようとすると訳分からん！！
25. 解決したい課題に立ち戻る 細かく刻んでゴールを目指す アイアンだけでうち続ける Before After 飛距離が飛ぶドライバーが出てきた 時間はかかる。でも 細かく刻む必要がなくなった わざわざ途中の目標でパター使う必要ない 今までの仕事の姿勢 ・「宵越しのタスクは持たない」 ・プロダクトバックログは 1日に収まるサイズ ・常にリリース可能な状態を維持 　・どこで終わっても良いように細かく分割！！ 飛距離が出るんだから、 直近の旗（仮説検証ポイント）に辿り着ければいい！！！
26. チームで話して生まれた Working Agreement PodはDaily Sprintをベースとし、「宵越しのタスクを持たない」ことを大切にしてきた。 しかし、AIコーディングの普及により状況が変わった。 • 短期での実装速度は上がった一方、人間が期待する結果になるよう修正するコストが大きくなっている • 1日単位のスプリントを回そうとすると、検証する必要がないのに顧客説明のためにバックログを細分化し、 不要な修正作業が発生するという不整合が起きた • 顧客の期待値醸成は大切だが、それよりも「検証したい仮説を検証するためのアクション」に注力すべきである 私たちの選択 • リリース可能な状態は 1週間単位 を目指す • 1週間おきに到達ゴールを TrelloのEpicとしてPOLが記載する。チームはその達成にコミットする • 到達ゴールにはシンプルな検証に必要な受け入れ条件を記載する • AIと協働する中でより良い方法が見つかった場合は、受け入れ条件を POLと一緒に見直す • 手段は柔軟に、目的（仮説検証）は見失わない Daily Sprintを辞めてWeekly Goalだけ計画を立てることにした 一個一個のバックログの正確性より検証したい仮説に集中できるようになった PMは顧客やステークホルダーと対話する時間が増えた
27. KDDI Agile Development Center Corporation 社外秘X 続・ポエム
28. requirements.mdはEARSという記法で記されている EARS（Easy Approach to Requirements Syntax） ・Rolls-RoyceのエンジニアAlistair Mavinが2009年に提案 ・要件記述のための構文テンプレート ・自然言語の曖昧さを排除 ・航空宇宙・自動車業界を中心に広く採用 EARSは、人間が人間に誤解なく伝える為に作られたフォーマット。 アジャイルソフトウェア開発宣言「プロセスやツールよりも個人と対話を」 人間はコンテキストを持つ。だから、人間とは対話すればよかった。 AIはコンテキストを持っていない状態で始まる。(2025年現在) だから、AIと対話する為には誤解なく伝えられるEARSが向いていた？
29. 今後は仕様駆動開発一択なのか？ 今後も仕様駆動開発一択？ AIが人間並にもっともっとコンテキストを保持するようになれば、 AIとの「対話」だけで相互理解できる日がくるのでは またDaily Sprintに戻る日がくる気がしている　いや、もっと早くなるかも （個人の意見） EARSは、人間が人間に誤解なく伝える為に作られたフォーマット アジャイルソフトウェア開発宣言「プロセスやツールよりも個人と対話を」 人間はコンテキストを持つ。 だから、人間とは対話すればよかった。 AIはコンテキストを持っていない状態で始まる。(2025年現在) だから、AIと対話する為には誤解なく伝えられるEARSが向いていた？
30. まとめ ・AI技術の変化で開発プロセスは変わった 　・変化に対応するためにDaily Sprintを採用していた 　・仕様駆動開発で開発スピードの飛距離が伸び、1日で区切りにくくなった 　・自分で仕様駆動開発触った 　　・EARSというフォーマットに触れた 　　・スクラムとAI DLCは別のフレームワーク 　・原点に帰って課題を整理した 　　・Daily Sprintを辞める決断をした　 　　・今の所いい感じ？でもこれが正しいかどうかはまだ分からない ・皆さんの環境ではどうしてます？懇親会で教えてください！
31. Be a Change Leader. アジャイルに力を与え
 共に成長し続ける社会を創る