©ADWAYS DEEE Inc. 1 ユーザーストーリー x AI 2025.11.12 Omagari Tomohisa 僕・私が考える最強の開発生産性を紹介します！【D-Plus Tokyo#19】 

©ADWAYS DEEE Inc. 2 自己紹介 大曲 智久（オオマガリ トモヒサ） - ADWAYS DEEE 取締役CTO - テクノロジー、プロダクト 2 エンジニア採用ページ　https://adways-deee.net/recruitment-engineers セミナー発表 https://speakerdeck.com/oomatomo ・AIを活用した化学反応的なスピード開発 TDD × ペアプロ × AI ・【日経×ケップル×アドウェイズ】未来の事業戦略を見据えたシステム改善の最適解を探る ・D-plus | プロダクト開発の貢献をアピールするための目標設計や認知活動 ・2024XP祭り｜多様性のあるプロダクトチームを目指した共創の3年間の変化 エンジニアブログで書いた記事 https://blog.engineer.adways.net/ ・CTOとしてAI導入での開発組織変化を振り返る ・20周年を迎えたサービスでビジネスドメインと向き合いモダナイゼーションを推進 ・エンジニアの事業貢献のために、開発生産性っぽいものを定量化した話 

Delight Mission 喜び つくろう。 「よかった」が めぐる世界を。 Value Exciting わくわく こなすより、 夢中になろう。 Value Eager 熱心 傍観者より、 冒険者になろう。 Value Exceed 超える 前例にならうより、 前例になろう。 Mission & Value めぐる世界を。 小さな変化の積み重ねが革新に繋がる ADWAYS DEEEが世界を変える つくろう。 「よかった」が 

©ADWAYS DEEE Inc. 4 ADWAYS DEEEの紹介 - 広告システムを作っております 4 ※　Adways IR資料（2023年12月期 決算説明会） 

©ADWAYS DEEE Inc. 5 ADWAYS DEEEの紹介 - 広告システムを作っております - 認知メインの広告（ディスプレイ広告）ではなく 体験メインの広告（アフィリエイト、リワード）を扱っている 5 

©ADWAYS DEEE Inc. 6 伝えたいこと - ユーザーストーリー（要件定義）フェーズを 早くするためにどうあるべきか？ - コーディングの高速化でどうあるべきか - まだ、組織全体では要件定義がボトルネックにはなっていない - 1人開発で模索した工夫を 組織に展開しようと思っているプラクティスを紹介します - PdMxエンジニアの関係性はどうあるべきか？ - 我々のプロダクトチームの定義ではデリバリーフェーズでは PdMがユーザーストーリーを書くがAIの変化ではどうあるべきか - SDDを細かく話さない、実装の細かい話はしない 

7 アジェンダ ©ADWAYS DEEE Inc. 

©ADWAYS DEEE Inc. 8 アジェンダ - プロダクトチームでの開発スタイル - ユーザーストーリーとは何か - AI活用で良かった部分 8 

9 プロダクトチームでの開発スタイル ©ADWAYS DEEE Inc. 

©ADWAYS DEEE Inc. プロダクトチームでの開発スタイル プロダクト開発では 多様性のあるチームがデフォルトと なっている プロダクトの価値を決めるために ３つの分野・ロールを大事にしている ３つのアウトプットが プロダクトの価値を決める 10 

©ADWAYS DEEE Inc. プロダクトのフェーズでチームの共創のあり方は変わる プロダクトチームでの開発スタイル 11 

©ADWAYS DEEE Inc. ユーザーストーリーを通した開発プロセス デリバリーフェーズで行っている内容は ※　Tanzu Labs（旧 Pivotal Labs）のリーンXPを元に構築されています。　 　　https://medium.com/product-run/791ed131b10f プロダクトチームでの開発スタイル 12 

©ADWAYS DEEE Inc. 13 13 ストーリーの粒度は、2~3日で実装できる規模が多い - 「XX バリデーション処理を実行する」「XX Cookieに保存する」..etc - エンジニアと議論して、テストしやすい受け入れ基準の決めたりする（受け入れテストをPdMが行う） - エラーケースや非機能要件はエンジニアがリードしてPdMに提案する（=全ての要件をPdMが決めない） ストーリーの優先度もPdMがベースを考える - フロー図などを用いて何から着手するかを決める ストーリーのフロー図 WHY As ペルソナは I want 〜したい So that そうすることで、〜からだ Acceptance Criteria Given 〜の場合 When 〜の時 Then 〜なる ストーリーの形式 ※　https://blog.engineer.adways.net/entry/2024/06/21/120000 プロダクトチームでの開発スタイル 

©ADWAYS DEEE Inc. 理想的な関係： ディスカバリーからデリバリーまで 常に共創できる状態を目指す 受発注な関係： これが全てにおいて悪ではないが、多様性 のチームが常に一つのことで集中し続ける メリットは大きい プロダクトチームでの開発スタイル 14 

15 プロダクトチームでの開発スタイル 

©ADWAYS DEEE Inc. テスト駆動開発： テストリストを作成し、 それを満たす最小のコードを書く ※　https://substack.com/@vicwu/note/c-45235322 　　https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck ペアプロをする中で リストがあるため、それのみの実装に集中できる ユーザーストーリーのWHYを満たす実装になって いるか議論する プロダクトチームでの開発スタイル 16 

©ADWAYS DEEE Inc. なぜ、メインのペアプロ（5~6時間）でやっているかは、話すと長いので割愛 言えるのは「ユーザーストーリー x TDD x ペアプロ x 心理的安全性 x ゆとり」 によって開発生産性が高くなるもので、ペアプロ単体で開発生産性が高いわけではない うまく使い分けが必要 - 各チームは、最低2トラック（2人 x 2ペア）できるようにする - 理想はエンジニア5名 - 1日の長い時間（5〜6時間）でペアプロをやる - 45分~1時間作業したら10~15分休憩 - Discord + Tuple - トラックごとのボイスチャンネルとTupleでお互いの画面操作可能 - 常時コミュニケーションを意識する - 今何をしているのか、何をしようとしているのか、口に出しながら進める プロダクトチームでの開発スタイル 17 

©ADWAYS DEEE Inc. 18 18 サービスブループリント ..etc ※開発の流れのイメージに近いもの ※4月の発表内容時 AIを活用した化学反応的なスピード開発 TDD × ペアプロ × AI プロダクトチームでの開発スタイル 

©ADWAYS DEEE Inc. 19 19 現在のユーザーストーリーは 粒度に正解は無く、チームで価値に対して合意をするためのツール 結果として 価値をアップデートしていくもので価値を意識した上でTDDでリストを作っていく中で、 ユーザーストーリーのアップデートをしたりする （ペアプロと一緒でコラボレーションのためのものである） →細かい仕様書では無いためAIに直接指示を出すためのものではない 開発をする中でストーリーを変更することもある ※4月の発表内容時 AIを活用した化学反応的なスピード開発 TDD × ペアプロ × AI プロダクトチームでの開発スタイル 

©ADWAYS DEEE Inc. 20 20 AIエージェント向けプロンプト （Devin..etc） 目的 XXXを作成したい 制約 XXの形式はXXXである XXXのみ有効にするため、 専用のリポジトリを作成して欲しい 完了の条件 XXで使える関数を実装する XXのテストコードも実装してください 補足 XXは自由に使えるよう変数を渡せるようにして ユーザーストーリーとは 別でAIエージェント向け指示を作る必要あり （コードの意図など） そのままリリースできそうな 成果物が一気にできる可能性も高い ※4月の発表内容時 AIを活用した化学反応的なスピード開発 TDD × ペアプロ × AI プロダクトチームでの開発スタイル 

©ADWAYS DEEE Inc. 21 ユーザーストーリーとは何か 

©ADWAYS DEEE Inc. 22 22 ※　https://www.atlassian.com/ja/agile/project-management/user-stories 　　https://www.atlassian.com/ja/agile/project-management/epics-stories-themes ユーザーストーリーとは何か ユーザーストーリーは、 ソフトウェアの機能をエンドユーザーや顧客の観点から、堅苦しくない一般的な言葉で説明します。 ユーザーストーリーの目的は、作業によって特定の価値を顧客に提供する方法を示すことです。 「顧客」は、従来のように外部のエンドユーザーを指すとは限りません。内部の利用者やチームの同僚を指す場合もあります。 

©ADWAYS DEEE Inc. 23 23 ※　アジャイルな見積りと計画づくり-価値あるソフトウェアを育てる概念と技法 従来の手法でマネジメントされているプロジェクトで は、ガントチャートやWBS (Work Breakdown Structure)で作業を管理する。そうすると、作業が チームの進捗の測定基準になる。作業を基準に計画を 立てるという手法にはいくつも問題がある。 顧客にとっての価値の単位はフィーチャだ。 計画づくりでは、作業ではなくフィーチャを単位にす べきなのである。 ※フィーチャー＝ユーザーストーリーの認識である ユーザーストーリーとは何か 

©ADWAYS DEEE Inc. 24 24 ユーザーストーリーは 価値を示す最小の粒度である WHY As ペルソナは I want 〜したい So that そうすることで、〜からだ Acceptance Criteria Given 〜の場合 When 〜の時 Then 〜なる ※　https://blog.engineer.adways.net/entry/2024/06/21/120000 ユーザーストーリーとは何か 

©ADWAYS DEEE Inc. 25 AI活用で良かった部分 

©ADWAYS DEEE Inc. 26 AI活用で良かった部分 26 Spec-Driven / AI-DLC スタイル　誕生　 7月にkiroリリースされたすげー、cc-sdd v.2.0.0リリースされたよ〜 

©ADWAYS DEEE Inc. 27 27 サービスブループリント ..etc ※開発の流れのイメージに近いもの ユーザーストーリーがあれば 爆速開発ができた コンテキストの準備は変わらず必要 AI活用で良かった部分 

©ADWAYS DEEE Inc. 28 28 サービスブループリント ..etc ※開発の流れのイメージに近いもの では、 次はユーザーストーリーを爆速で作れるか？ AI活用で良かった部分 

©ADWAYS DEEE Inc. 29 29 開発したケース - Kiroを使って一からDiscord Bot v1を作成 - Claude Codeで ユーザーストーリーをベースにDiscord Bot v2を作成 既存のフロントエンドをBot用に新規機能を追加 - 過去のユーザーストーリーを再開発 トラッキングのモダナイズをcc-sddで作る AI活用で良かった部分 

©ADWAYS DEEE Inc. 30 30 AI活用で良かった部分 ソリューション決定から ユーザーストーリー作成までに何かしらのアウトプットがある イベントストリーミング、サービスブループリント、 ユーザーストーリーマッピング..etc ※　Labs流 アプリケーションモダナイゼーション 

©ADWAYS DEEE Inc. 31 31 AI活用で良かった部分 ChatGPTのプロジェクトでユーザーストーリーのガイドラインを 読み込ませると叩きとしては十分な品質である（以下は簡単な例） 

©ADWAYS DEEE Inc. 32 32 AI活用で良かった部分 エラーケースの提案もそれっぽいものがある （組み合わせは人判断だが、チューニングのしがいがある） 

©ADWAYS DEEE Inc. 33 33 AI活用で良かった部分 タイプ 今まで ユーザーストーリー 正常系（ハッピーパス） ・イベントストーミングの内容から 　PdMが作成する ユーザーストーリー エラー系 ・PdMが正常系からストーリー作成 　（ビジネス上のエラーケース） ・エンジニアから提案し、ストーリー作成 　（アーキテクチャ上のエラーケース） タスク 非機能系 ・エンジニアが品質担保のために 　タスクを考える 　（負荷テスト、結合テスト 　セキュリティチェック..etc） 

©ADWAYS DEEE Inc. 34 34 AI活用で良かった部分 タイプ 今まで これから ユーザーストーリー 正常系（ハッピーパス） ・イベントストーミングの内容から 　PdMが作成する ・イベントストーミングの内容から 　AIで自動生成するが、細かくPdMが確認する 　（価値の確認になるため） ユーザーストーリー エラー系 ・PdMが正常系からストーリー作成 　（ビジネス上のエラーケース） ・エンジニアから提案し、ストーリー作成 　（アーキテクチャ上のエラーケース） ・AIで正常系からエラー系を 　提案してもらいPdM・エンジニアが承認する タスク 非機能系 ・エンジニアが品質担保のために 　タスクを考える 　（負荷テスト、結合テスト 　セキュリティチェック..etc） ・大きな仕組み化は人判断のまま 　（レガシーシステムなため、 　本番での並行稼働の仕組みを構築する..etc） 

©ADWAYS DEEE Inc. 35 35 AI活用で良かった部分 プロセス 今まで ユーザー ストーリーの粒度 ・最小の価値の単位 ・開発工数は2~3日程度 　工数が大きい場合は分割する ユーザー ストーリーの作成 ・PdMがユーザーストーリー 　ライティングを行う 　週に4個くらい作って適宜受け入れ作業 ・たまにエンジニアが手伝う ペアプロのあり方 ・ユーザーストーリーをベースに 　エンジニアがペアプロを行う 

©ADWAYS DEEE Inc. 36 36 AI活用で良かった部分 プロセス 今まで これから ユーザー ストーリーの粒度 ・最小の価値の単位 ・開発工数は2~3日程度 　工数が大きい場合は分割する ・最小の価値（これは保つべし） ・開発工数は、あまり意識しない 　AIのおかげで数時間が多くなる 　（ただ工数が大きい場合は分割する） ユーザー ストーリーの作成 ・PdMがユーザーストーリー 　ライティングを行う 　週に4個くらい作って適宜受け入れ作業 ・たまにエンジニアが手伝う ・PdMがAIで量産する（週に20個=5倍） ・全体の整合性やエラーケースの提案などは 　AIがチェックするようにコンテキストを管理する 　（PdM自身やエンジニアで管理する） ペアプロのあり方 ・ユーザーストーリーをベースに 　エンジニアがペアプロを行う ・要件が未定かつ実装工数が小さい場合は 　PdM or デザイナー x エンジニアのペアプロ 　（プロトタイプ作成でも似たことをやっている） ・エンジニアがペアプロで爆速開発 

©ADWAYS DEEE Inc. 37 まとめ 

©ADWAYS DEEE Inc. 38 まとめ 38 - ユーザーストーリー（要件定義）フェーズを早くするためにどうあるべきか？ - 正常系はAIのフォローはあると思うが、 今までのイベントストーミングをベースに人がメインで作成する （価値の軸となるため） - エラー系は、AIにチェック・提案してもらう前提でエージェント管理した方が より精度やスピードは速くなる - PdMxエンジニアの関係性はどうあるべきか？ - 爆速のユーザーストーリー作成をエンジニアと共に行う方が良い - PdMが1人実装できる範囲まではまだ遠い プロトタイプならば良いが、既存システムの改修がメイン作業なので 多様性のあるペアプロが良い 

©ADWAYS DEEE Inc. 39 おわり