ディスカバリーと デリバリーを繋ぐ ユーザーストーリーのAI化 / Connecting Discovery and Delivery: AI-driven User Story Generation

AI Engineering Summit Tokyo 2026

Transcript

1. ディスカバリーと デリバリーを繋ぐ ユーザーストーリーのAI化 Delight Exciting Eager Exceed AI Engineering Summit Tokyo 2026 2026/06/08 大曲 智久
2. Delight Exciting Eager Exceed Copyright © ADWAYS DEEE Inc. All Rights Reserved. ©ADWAYS DEEE Inc. 大曲 智久（オオマガリ トモヒサ） - ADWAYS DEEE 取締役CTO - テクノロジー、プロダクト エンジニア採用ページ 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周年を迎えたサービスでビジネスドメインと向き合いモダナイゼーションを推進 ・エンジニアの事業貢献のために、開発生産性っぽいものを定量化した話 2
3. 3 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 伝えたいこと - ユーザーストーリーの役割は、どう変わってきたか？ - かつては実装単位で細かく大量に作っていた - AIでの実装高速化でユーザーストーリーに変化が訪れた - どんなストーリーが残り、何が変わったかを話します - AIで作るストーリーの品質を、どう守ろうとしたか？ - 実装側はテスト・lint・CIで守られている - 同じ「ハーネス」の発想を要件側に持ち込めるか試した - 何に挑戦し、どこで失敗したかを話します
4. 5 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ADWAYS DEEEの紹介 - 広告システムを作っております ※ Adways IR資料（2023年12月期 決算説明会）
5. 6 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ADWAYS DEEEの紹介 - 広告システムを作っております - 認知メインの広告（ディスプレイ広告）ではなく 体験メインの広告（アフィリエイト、リワード）を扱っている
6. 7 Copyright © ADWAYS DEEE Inc. All Rights Reserved. - プロダクトチームでの開発スタイル - ユーザーストーリーの役割の進化 - ハーネスへの挑戦と失敗 目次
7. Delight Exciting Eager Exceed Copyright © ADWAYS DEEE Inc. All Rights Reserved. プロダクトチームでの開発スタイル
8. 9 Copyright © ADWAYS DEEE Inc. All Rights Reserved. プロダクト開発では 多様性のあるチームがデフォルトとな っている プロダクトの価値を決めるために ３つの分野・ロールを大事にしている ３つのアウトプットが プロダクトの価値を決める
9. 10 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ユーザーストーリーを通した開発プロセス デリバリーフェーズで行っている内容は
10. 11 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 11 11 ※ https://www.atlassian.com/ja/agile/project-management/user-stories https://www.atlassian.com/ja/agile/project-management/epics-stories-themes ユーザーストーリーとは何か ユーザーストーリーは、 ソフトウェアの機能をエンドユーザーや顧客の観点から、堅苦しくない一般的な言葉で説明します。 ユーザーストーリーの目的は、作業によって特定の価値を顧客に提供する方法を示すことです。 「顧客」は、従来のように外部のエンドユーザーを指すとは限りません。内部の利用者やチームの同僚を指す場合もあります。
11. 12 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ※ アジャイルな見積りと計画づくり-価値あるソフトウェアを育てる概念と技法 従来の手法でマネジメントされているプロジェクトで は、ガントチャートやWBS (Work Breakdown Structure)で作業を管理する。そうすると、作業がチ ームの進捗の測定基準になる。作業を基準に計画を立 てるという手法にはいくつも問題がある。 顧客にとっての価値の単位はフィーチャだ。 計画づくりでは、作業ではなくフィーチャを単位にす べきなのである。 ※フィーチャー＝ユーザーストーリーの認識である ユーザーストーリーとは何か
12. 13 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ユーザーストーリーを作成するタイミング ソリューションの決定＝大枠の作るものを決める イベントストーミング=ビジネスドメインのイベントを洗い出して軸を作る ユーザーストーリー作成＝軸を元にユーザーストーリーとして落とし込んでいく 開発＝ユーザーストーリーを一つ一つ作り上げることでインクリメントしていく
13. 14 Copyright © ADWAYS DEEE Inc. All Rights Reserved. イベントストーミングをプロダクトチームやドメインエキスパートで一緒に行う 認識のズレやユビキタス言語のチェックを行なったりする ※ Labs流 アプリケーションモダナイゼーション https://medium.com/product-run/labs%E6%B5%81- %E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%A 2%E3%83%80%E3%83%8A%E3%82%A4%E3%82%BC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3- 946a4c963be0
14. 15 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 2024年頃 ストーリーの粒度は、2~3日で実装できる規模が多い - 「XX バリデーション処理を実行する」「XX Cookieに保存する」..etc - ペルソナにサービス名も使うこともある（バックエンドのユーザーストーリーなどで使う） - エンジニアと議論して、テストしやすい受け入れ基準を決めたりする（受け入れテストをPdMが行う） - エラーケースや非機能要件はエンジニアがリードしてPdMに提案する（=全ての要件をPdMが決めない） ストーリーの優先度はPdMがベースを考える - フロー図などを用いて何から着手するかを決める ストーリーのフロー図 WHY As ペルソナ（システム）は I want 〜したい So that そうすることで、〜からだ Acceptance Criteria Given 〜の場合 When 〜の時 Then 〜なる ストーリーの形式
15. 16 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ユーザーストーリーは 粒度に正解は無く、チームで価値に対して合意をするためのツール 結果として 価値をアップデートしていくもので価値を意識した上で開発していく中で、 ユーザーストーリーのアップデートをしたりする 開発をする中でストーリーを変更することもある プロダクトチームでの開発スタイル
16. 17 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 2024年ごろのスタイルまとめ - ソリューション決定後に 要件の詳細決めとしてユーザーストーリーを活用 - チームの価値に対する 同意のためのコミュニケーションとしても利用
17. Delight Exciting Eager Exceed Copyright © ADWAYS DEEE Inc. All Rights Reserved. ユーザーストーリーの役割の進化
18. 19 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 現在のスタイル ユーザーストーリーを リポジトリに入れ込む 要件詳細を詰めるため のストーリーは、エラ ーでのストーリーを書 くWHYのループがある SDDとしてOpenSpec を使っている
19. 20 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ユーザーストーリーの比較 - 過去（左）：1ストーリー=1シナリオ - 現在（右）：1ストーリー=複数シナリオ - 抽象度が上がり、受入基準が2〜4つに増えている
20. 21 Copyright © ADWAYS DEEE Inc. All Rights Reserved. いい感じに作れてそうだなと思っていた この発表のために、ストーリーを別角度で分析した
21. 22 Copyright © ADWAYS DEEE Inc. All Rights Reserved. https://www.oreilly.co.jp//books/9784814400737/ 過去のストーリーをドメインの種類ごとに分類
22. 23 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 現在のストーリーをドメインの種類ごとに分類 ・全体で見ると思ったよりも比率に変化なし 開発のプロジェクトごとで中核の比率が異なる ・旧ストーリーはトラッキングがメインなので 比率は非常に大きくなっている。（15% → 80%） ・商品の一覧表示のストーリーとかは補完扱い 中核に該当するストーリー数がアウトカムを出し続けているかの 指標にもなりそう
23. 24 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ストーリーで変わるもの変わらないもの 項目 過去（2024年） 現在（2026年） ユーザーストーリーの 粒度 ・最小の価値の単位 ・開発工数は2~3日程度 ・受け入れ基準は1個が多い ・最小の価値の単位 ・開発工数は2~3日程度（結果的にここは維持） ・抽象度が上がり、受け入れ基準が2~4個が当たり前化
24. 25 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ストーリーで変わるもの変わらないもの 項目 過去（2024年） 現在（2026年） ユーザーストーリーの 粒度 ・最小の価値の単位 ・開発工数は2~3日程度 ・受け入れ基準は1個が多い ・最小の価値の単位 ・開発工数は2~3日程度（結果的にここは維持） ・抽象度が上がり、受け入れ基準が2~4個が当たり前化 ユーザーストーリーの 作成スタイル ・PdMがユーザーストーリーライティング を行う 週に4個くらい作って適宜受け入れ作業 ・たまにエンジニアが手伝う ・PdMがユーザーストーリーライティングを行う ・エンジニアがユーザーストーリーを作成してその まま開発も増えている
25. 26 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ストーリーで変わるもの変わらないもの 項目 過去（2024年） 現在（2026年） ユーザーストーリーの 粒度 ・最小の価値の単位 ・開発工数は2~3日程度 ・受け入れ基準は1個が多い ・最小の価値の単位 ・開発工数は2~3日程度（結果的にここは維持） ・抽象度が上がり、受け入れ基準が2~4個が当たり前化 ユーザーストーリーの 作成スタイル ・PdMがユーザーストーリーライティング を行う 週に4個くらい作って適宜受け入れ作業 ・たまにエンジニアが手伝う ・PdMがユーザーストーリーライティングを行う ・エンジニアがユーザーストーリーを作成してその まま開発も増えている ストーリーの分類 ・中核=25％、一般=15％、補完=60% ・全体比率は大きな変化なし おそらくこれは変わっていくべきもの ・PJによって中核が多いものも増えている 中核=80%など
26. 27 Copyright © ADWAYS DEEE Inc. All Rights Reserved. - 実装の高速化で 1つのストーリーの抽象度が上がった - ユーザーストーリー化していくものは 事業の中核を担うドメインである ここに注力してユーザーストーリーを作れるか大事
27. Delight Exciting Eager Exceed Copyright © ADWAYS DEEE Inc. All Rights Reserved. ハーネスへの挑戦と失敗
28. 29 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 背景 - 作成したストーリーを元に派生したストーリーの増産はしやすい （正常系からエラーケースや細かい詳細を詰めたストーリー） 必要に応じたエラーケースの提案もモデルの精度向上で質が上がった - その一方で 要件の矛盾や複数システム（レガシーとモダン）での結合部でのズレや 古き良き歴史の特殊仕様との向き合いでバグの温床になりがち （10年・20年のシステム）
29. 30 Copyright © ADWAYS DEEE Inc. All Rights Reserved. WHYのループでのGuide+Sensor Lint自作も含めて ガッツリ作り込んでみた流れ
30. 31 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ツール紹介（Alloy / Z3 / TLA+） 観点 Alloy Z3（SMT） TLA+ 一言で 関係の反例探索器 算術の確定ゲート 時相・並行の振る舞い検証器 ハーネス上の役割 Guide（設計時・反例探索） Sensor（CI・事後） ※未導入 得意領域 関係・推移閉包（到達可能性）・ 状態の反例・越境整合 算術・カウント・集合等号 ・一意性・floor 端数 時相論理・並行/分散プロトコル・安全性 /活性 仕様の検証対象で 活用できそうな例 （汎用） ・権限ロールから「不正な状態」の確認 ・状態遷移図の到達性・デッドロック検出 ・参照整合（孤立した外部キーが無い） ・カテゴリ木/依存グラフに循環が無い ・在庫数が負にならない ・割引後の金額 ≧ 0／料金の上限・下限 ・ポイント計算の floor 端数の保存則 ・採番 ID の衝突なし（一意性） ・並行処理で「二重確定／二重決済」が防止 ・リトライ（at-least-once）の冪等性 ・分散ロックのデッドロック非発生 ・リーダー選出/合意の安全性 世間一般の活用事 例（実例） ・Mondex IC カード（電子マネー）の検証 ・ファイルシステム/セキュリティプロトコ ルのモデル化 ・記号実行ファザー SAGE で Windows/Office のセキュリティバグを発見 ・スマートコントラクト検査（Mythril 等） ・AWS が S3 / DynamoDB の分散プロトコルを 本番前に検証しバグ発見 ・Azure Cosmos DB / MongoDB の設計検証 良いなと思ったツールは複数あった。DDDではAlloyでの活用事例が多い。それ以外はあまり見られない。。
31. 32 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ツール紹介（Alloy / Z3 / TLA+） Alloyのコード 注文ステータスがアクティブな時にしか出荷ステータスにできない 仕様NG 仕様OK
32. 33 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 挑戦と失敗（Alloy / Z3） Good - リサーチエージェントは痒いところに手が届いた - Storyのレビュースキルもわかりやすい評価してくれる - Alloyやz3で既存仕様を書き起こすことで要件のズレを 発見できた More - ユビキタスのズレとかはskillsで賄えそう - AlloyやZ3のメンテナンスやAIが言うがままになる 細かいロジックになるとコード理解が追いつかない メンテナンス問題（チームで任せるのが難しそう） - Z3は細かくは不要でAlloyのみで良いかも 計算周りは実コードでもあるので賄えがちな部分でもあ るため（テストデータを充実させるとかに力を入れる方 が良いかも）
33. 34 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 挑戦と失敗（Alloy / Z3） 悩みポイント - メンテナンスができる自信がない テックリードと一緒に全体設計を振り返る際に 定期的な棚卸しとしてあるのはイメージが付く - 調査用として作ってチェックするのは良いかも - コンテキストの重要なロジックをコード化（Alloy）して 管理するのは良さそうな気がする サービス全体だと抽象が高くてコンテキスト近い意味合い Bounded Contextで事業の中核に近いロジックが集約 バグや設計漏れを検知できたけど、 メンテナンスの課題がある中でどこまで書くべきか？ 灰色は不要なコード化で 赤色が価値ありそうなコード化 システム規模によるので都度判断
34. 35 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 挑戦と失敗（Alloy / Z3） ユーザーストーリーが作るべきものの軸となる 軸をベースにAIは上手く網羅してくれる Alloyなどでユーザーストーリーの外側や 既存のロジックとの矛盾を行うイメージである 既存やレガシーとの謎仕様との向き合いにおいて Alloyに落とし込む価値は非常に高い Claudeのultracodeが当たり前となり サクッとカバーできる未来もあるかもしれない
35. 36 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 要件定義のコード化よりも効いたのは「AIに対しての自由な環境提供」 - ユーザーストーリーを軸にテスト環境にデプロイし、 テストDBにアクセスしてシステム結合テストをやってくれる APMで変なエラーが出ていないかNewRelicのMCPでチェック 実際に動かしてからのFBの方が価値も高い - 振る舞いチェックをやり続ける環境構築が重要 テスト・本番でAWSアカウントを分ける SSM Session ManageでのDBへの接続 APMをフルでテスト環境でも実装できるプラン選択 AWSのSSO ログインでの短命トークンのプロファイル利用
36. 37 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ユーザーストーリー作成と開発を一緒にしていることもあったが。。。。 - もうサクッと作った方が良いと ユーザーストーリーを作らずに作ることも あった - 振り返るとチームとしてのWHYのコミニケ ーションが減っていた 作れるから良いがコードレビューでは HOWのコミニケーションになりがち チーム全員（エンジニア４名）でコードレ ビューをやらないのでよりWHYが埋もれが ち。。。。
37. 38 Copyright © ADWAYS DEEE Inc. All Rights Reserved. - リサーチやコンテキストを整備する能力は Skillやモデル自体の能力で非常に違和感なく作れる - 人すらも気付けない矛盾点をチェックするために 要件定義用のコード化実装での価値を感じられた ドキュメントのみ限界がある - 要件定義フェーズになると受け入れを行うテスト環境の整備や チームとのコミニケーションにも影響がある
38. Delight Exciting Eager Exceed Copyright © ADWAYS DEEE Inc. All Rights Reserved. まとめ
39. 40 Copyright © ADWAYS DEEE Inc. All Rights Reserved. まとめ - ユーザーストーリーの役割は、どう変わってきたか？ - 実装の高速化で抽象度が上がった - プロジェクトにもよるが事業の中核ドメインの率が高くなっている - チームとしてこの中核ドメインのユーザーストーリーを増やし WHYのコミニケーションが取れるのかが肝 - AIで作るストーリーの品質を、どう守ろうとしたか？ - ユーザーストーリー作成にもlint（docs-lint, story-lint)や スキル（story..etc）、要件のコード化（Alloy, Z3）を試した - 要件のコード化で、潜在的なバグチェックができており、 コンテキストごとの事業の中核ロジックを管理したいがチームでの運用 が悩ましい - 振る舞いハーネスとして受け入れ作業ができるテスト環境をAIに提供す ることの恩恵が高かった
40. We're hiring ご清聴ありがとうございました 新しい価値を作り出す • Engineering Manager • AI Ops Manager（今後オープン予定） • ML Engineer（今後オープン予定） を募集しております https://adways-deee.net/recruitment-engineers ぜひ Ask the Speaker / 懇親会でお話しましょう
41. Delight Exciting Eager Exceed Copyright © ADWAYS DEEE Inc. All Rights Reserved. 終わり