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

by Tomohisa Omagari

Embed

Start on current slide

Slide 1

Slide 1 text

ディスカバリーとデリバリーを繋ぐユーザーストーリーのAI化 Delight Exciting Eager Exceed AI Engineering Summit Tokyo 2026 2026/06/08 大曲智久

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

3 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 伝えたいこと - ユーザーストーリーの役割は、どう変わってきたか？ - かつては実装単位で細かく大量に作っていた - AIでの実装高速化でユーザーストーリーに変化が訪れた - どんなストーリーが残り、何が変わったかを話します - AIで作るストーリーの品質を、どう守ろうとしたか？ - 実装側はテスト・lint・CIで守られている - 同じ「ハーネス」の発想を要件側に持ち込めるか試した - 何に挑戦し、どこで失敗したかを話します

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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 ユーザーストーリーとは何かユーザーストーリーは、ソフトウェアの機能をエンドユーザーや顧客の観点から、堅苦しくない一般的な言葉で説明します。ユーザーストーリーの目的は、作業によって特定の価値を顧客に提供する方法を示すことです。「顧客」は、従来のように外部のエンドユーザーを指すとは限りません。内部の利用者やチームの同僚を指す場合もあります。

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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 〜なるストーリーの形式

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

23 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 現在のストーリーをドメインの種類ごとに分類・全体で見ると思ったよりも比率に変化なし開発のプロジェクトごとで中核の比率が異なる・旧ストーリーはトラッキングがメインなので比率は非常に大きくなっている。（15% → 80%）・商品の一覧表示のストーリーとかは補完扱い中核に該当するストーリー数がアウトカムを出し続けているかの指標にもなりそう

Slide 23

Slide 23 text

Slide 24

Slide 24 text

25 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ストーリーで変わるもの変わらないもの項目過去（2024年）現在（2026年）ユーザーストーリーの粒度・最小の価値の単位・開発工数は2~3日程度・受け入れ基準は1個が多い・最小の価値の単位・開発工数は2~3日程度（結果的にここは維持）・抽象度が上がり、受け入れ基準が2~4個が当たり前化ユーザーストーリーの作成スタイル・PdMがユーザーストーリーライティングを行う週に4個くらい作って適宜受け入れ作業・たまにエンジニアが手伝う・PdMがユーザーストーリーライティングを行う・エンジニアがユーザーストーリーを作成してそのまま開発も増えている

Slide 25

Slide 25 text

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%など

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

29 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 背景 - 作成したストーリーを元に派生したストーリーの増産はしやすい（正常系からエラーケースや細かい詳細を詰めたストーリー）必要に応じたエラーケースの提案もモデルの精度向上で質が上がった - その一方で要件の矛盾や複数システム（レガシーとモダン）での結合部でのズレや古き良き歴史の特殊仕様との向き合いでバグの温床になりがち（10年・20年のシステム）

Slide 29

Slide 29 text

Slide 30

Slide 30 text

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での活用事例が多い。それ以外はあまり見られない。。

Slide 31

Slide 31 text

Slide 32

Slide 32 text

33 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 挑戦と失敗（Alloy / Z3） Good - リサーチエージェントは痒いところに手が届いた - Storyのレビュースキルもわかりやすい評価してくれる - Alloyやz3で既存仕様を書き起こすことで要件のズレを発見できた More - ユビキタスのズレとかはskillsで賄えそう - AlloyやZ3のメンテナンスやAIが言うがままになる細かいロジックになるとコード理解が追いつかないメンテナンス問題（チームで任せるのが難しそう） - Z3は細かくは不要でAlloyのみで良いかも計算周りは実コードでもあるので賄えがちな部分でもあるため（テストデータを充実させるとかに力を入れる方が良いかも）

Slide 33

Slide 33 text

34 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 挑戦と失敗（Alloy / Z3）悩みポイント - メンテナンスができる自信がないテックリードと一緒に全体設計を振り返る際に定期的な棚卸しとしてあるのはイメージが付く - 調査用として作ってチェックするのは良いかも - コンテキストの重要なロジックをコード化（Alloy）して管理するのは良さそうな気がするサービス全体だと抽象が高くてコンテキスト近い意味合い Bounded Contextで事業の中核に近いロジックが集約バグや設計漏れを検知できたけど、メンテナンスの課題がある中でどこまで書くべきか？灰色は不要なコード化で赤色が価値ありそうなコード化システム規模によるので都度判断

Slide 34

Slide 34 text

35 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 挑戦と失敗（Alloy / Z3）ユーザーストーリーが作るべきものの軸となる軸をベースにAIは上手く網羅してくれる Alloyなどでユーザーストーリーの外側や既存のロジックとの矛盾を行うイメージである既存やレガシーとの謎仕様との向き合いにおいて Alloyに落とし込む価値は非常に高い Claudeのultracodeが当たり前となりサクッとカバーできる未来もあるかもしれない

Slide 35

Slide 35 text

36 Copyright © ADWAYS DEEE Inc. All Rights Reserved. 要件定義のコード化よりも効いたのは「AIに対しての自由な環境提供」 - ユーザーストーリーを軸にテスト環境にデプロイし、テストDBにアクセスしてシステム結合テストをやってくれる APMで変なエラーが出ていないかNewRelicのMCPでチェック実際に動かしてからのFBの方が価値も高い - 振る舞いチェックをやり続ける環境構築が重要テスト・本番でAWSアカウントを分ける SSM Session ManageでのDBへの接続 APMをフルでテスト環境でも実装できるプラン選択 AWSのSSO ログインでの短命トークンのプロファイル利用

Slide 36

Slide 36 text

37 Copyright © ADWAYS DEEE Inc. All Rights Reserved. ユーザーストーリー作成と開発を一緒にしていることもあったが。。。。 - もうサクッと作った方が良いとユーザーストーリーを作らずに作ることもあった - 振り返るとチームとしてのWHYのコミニケーションが減っていた作れるから良いがコードレビューでは HOWのコミニケーションになりがちチーム全員（エンジニア４名）でコードレビューをやらないのでよりWHYが埋もれがち。。。。

Slide 37

Slide 37 text

38 Copyright © ADWAYS DEEE Inc. All Rights Reserved. - リサーチやコンテキストを整備する能力は Skillやモデル自体の能力で非常に違和感なく作れる - 人すらも気付けない矛盾点をチェックするために要件定義用のコード化実装での価値を感じられたドキュメントのみ限界がある - 要件定義フェーズになると受け入れを行うテスト環境の整備やチームとのコミニケーションにも影響がある

Slide 38

Slide 38 text

Slide 39

Slide 39 text

40 Copyright © ADWAYS DEEE Inc. All Rights Reserved. まとめ - ユーザーストーリーの役割は、どう変わってきたか？ - 実装の高速化で抽象度が上がった - プロジェクトにもよるが事業の中核ドメインの率が高くなっている - チームとしてこの中核ドメインのユーザーストーリーを増やし WHYのコミニケーションが取れるのかが肝 - AIで作るストーリーの品質を、どう守ろうとしたか？ - ユーザーストーリー作成にもlint（docs-lint, story-lint)やスキル（story..etc）、要件のコード化（Alloy, Z3）を試した - 要件のコード化で、潜在的なバグチェックができており、コンテキストごとの事業の中核ロジックを管理したいがチームでの運用が悩ましい - 振る舞いハーネスとして受け入れ作業ができるテスト環境をAIに提供することの恩恵が高かった

Slide 40

Slide 40 text

We're hiring ご清聴ありがとうございました新しい価値を作り出す ● Engineering Manager ● AI Ops Manager（今後オープン予定） ● ML Engineer（今後オープン予定）を募集しております https://adways-deee.net/recruitment-engineers ぜひ Ask the Speaker / 懇親会でお話しましょう