イベントストーミングと Kiroの仕様駆動開発で実現する要件の認識合わせプロセス

© 2026, Amazon Web Services, Inc. or its affiliates. All
rights reserved. Amazon Confidential and Trademark. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential and Trademark. 宇賀神みずき @syobochim J J U G C C C S P R I N G 2 0 2 6 Delivery Consultant – App Dev アマゾンウェブサービスジャパン合同会社イベントストーミングと Kiroの仕様駆動開発で実現する要件の認識合わせプロセス

rights reserved. Amazon Conﬁdential and Trademark. Who am I ? 2 AWS Japan Delivery Consultant アプリケーション開発のご⽀援を担当 AWS Japan YouTube チャンネルで「ドメイン駆動設計のススメ」を定期配信著書「いちばんやさしいGit&GitHubの教本」しょぼちむ宇賀神みずき @syobochim

rights reserved. Amazon Conﬁdential and Trademark. ターゲットとゴールこんな⽅に向けて 🎯 • 業務システムの開発に関わる開発リード・エンジニア • AIの実装で開発が速くなった気がするが、全体的な時間はそこまで減ってないと悩んでる⽅ • 上流の⼯程での⽣成 AI の活⽤に悩んでる⽅持ち帰っていただきたいこと 🎁✨ • AI 時代のボトルネックは「何を作るか」の認識合わせに移った • 「AI に任せる」ではなく「AI と⼀緒に設計する」という気持ち 3

rights reserved. Amazon Conﬁdential and Trademark. ⽣成AIを使った開発は、もう特別なものではないコードを書く・直す・読むのあらゆる場⾯で⽣成AIを使うのが当たり前に「作るところ」はどんどん速くなっているでも、業務システムの開発で難しいのはその⼿前の何を作るべきかの認識合わせ 🧠 🤝 🧠 ✨ 4

rights reserved. Amazon Conﬁdential and Trademark. ２つの認識あわせの境界⼈と⼈⾔葉の意味が違う⾒えている業務範囲が違う欲しいもののイメージが違う⼈とAI 曖昧な指⽰をそれっぽく補完する出⼒は綺麗で、⼀⾒良さそう 5

rights reserved. Amazon Conﬁdential and Trademark. ちなみに厳密な認識合わせが必要ない場合⼩さな修正少しずつ微修正しながら進む • IDEのコード補完 • すでに実装が明確なものを数ファイルだけ書かせる • ⼈による完全なコントロールスパイクゴールを⾒つけるために⾊んなアイデアを素早く試す • Vibe Coding • 作ったものは後から捨てる • 品質をほぼすべてAIに任せる 6

rights reserved. Amazon Conﬁdential and Trademark. 業務システムは、認識ズレが起きやすい • 業務ルールには、ドキュメント化されていない暗黙知が多い • ビジネス⽤語は独特で、開発者が意味を取り違えやすい • 既存プロセスや制約が、システム仕様の前提になる複雑な業務ロジックでは、関係者間の合意が品質を左右する • 関係者ごとに「実現したい姿」のイメージが少しずつ違う • 関係者ごとに「正しい姿」のイメージが違うことがある • 複雑な業務ロジックでは、⼩さな認識ズレが⼤きな⼿戻りにつながる 8

rights reserved. Amazon Conﬁdential and Trademark. Event Storming: ビジネスを分析・発⾒する • 業務を可視化・理解するためのプラクティスの⼀つ • ⾊分けされた意味のある付箋を使い、業務プロセスを時系列で可視化する • 3 つのレベル: • Big Picture: ビジネス全体を俯瞰する • Process Modeling: 業務フローを詳細化する • Design Level: 実装のための設計を検討する • ⽬的: 開発者とビジネスサイドが業務の共通理解をつくる 9

rights reserved. Amazon Conﬁdential and Trademark. Event Storming: ビジネスを分析・発⾒する • 業務を可視化・理解するためのプラクティスの⼀つ • ⾊分けされた付箋を使って業務プロセスを時系列で可視化する • 3 つのレベル: • Big Picture: ビジネス全体を俯瞰する • Process Modeling: 業務フローを詳細化する • Design Level: 実装のための設計を検討する • ⽬的: 開発者とビジネスサイドが業務の共通理解をつくる Big Picture から Design Level まで実施していたが、とても時間がかかった（業務プロセスの整理に、5時間 x 週2回で2-3ヶ⽉ほど）⽣成AIの活⽤で実装速度が上がってきたがゆえに「何を作るか」を揃える時間が⽬⽴つ

rights reserved. Amazon Conﬁdential and Trademark. Event Storming: ビジネスを分析・発⾒する • 業務を可視化・理解するためのプラクティスの⼀つ • ⾊分けされた付箋を使って業務プロセスを時系列で可視化する • 3 つのレベル: • Big Picture: ビジネス全体を俯瞰する • Process Modeling: 業務フローを詳細化する • Design Level: 実装のための設計を検討する • ⽬的: 開発者とビジネスサイドが業務の共通理解をつくる Big Picture から Design Level まで実施していたが、とても時間がかかった（業務プロセスの整理に、5時間 x 週2回で2-3ヶ⽉ほど）⽣成AIの活⽤で実装速度が上がってきたがゆえに「何を作るか」を揃える時間が⽬⽴つ Event Storming を業務理解と課題の認識を揃える場として切り替え Design Level はほぼやらず、Process Modeling にフォーカス

rights reserved. Amazon Conﬁdential and Trademark. 業務理解と課題認識に絞った最低限のものに利⽤する付箋の種類も⼤幅に削り（8 種類 → 4 種類）「業務プロセスを理解し、課題を⾒つける」ための情報に集中する省略したことで削った情報の整理は別の場所で回収（後述） 12 オレンジドメインイベント（起きた出来事）薄⻩⾊アクター（誰が関わるか、誰の判断か）紫ポリシー（イベントに反応する業務ルール）⾚ホットスポット（疑問・課題・未決事項）疑問・課題や⾔葉の整理は特に強く意識して実施

rights reserved. Amazon Conﬁdential and Trademark. 業務知識を Product Backlog Item にまとめてみるが... PBI: 図書の予約 User Story: 利⽤者として、貸出中の図書を予約したい。なぜなら、返却されたら優先的に借りられるようにしたいから。 • 貸出中の図書を借りたい利⽤者は、窓⼝や電話で問い合わせる必要がある。 • 予約状況が分かりにくく、返却後の連絡も⼿作業になっている。やりたいこと / 受け⼊れ条件: • 貸出中の図書に対して予約できる • 返却されたら次の利⽤者に通知する • 予約は申し込み順に処理する • 予約数には上限を設ける • ⾃分の予約を確認・キャンセルできる 13 純粋な⾃然⾔語では、テスト可能な仕様としてはまだ粗い⼈間もAIもこの要件で同じものをイメージできる︖ 期限は何⽇︖ 予約上限は図書館ごと︖ 区単位︖ 予約は⽇付指定できる︖

rights reserved. Amazon Conﬁdential and Trademark. 思い切って省⼒化することで速度は倍に🚀、しかし課題も...😢 Good 👍✨ • 要件を整理する時間が短縮できた（時間あたり1.5倍〜2倍くらいの業務プロセス） • イベントストーミング中の「開発者のためだけの時間（＝ビジネスサイドが持て余す時間）」が減った Bad 👎💥 • 詳細を詰めないことでビジネスサイドと開発者による認識の違いが発⽣（開発者間でもイメージに差が） • 仕様が曖昧なままでも、⽣成AIがなんとなくそれっぽく作ってしまう →何度か⼤きな⼿戻りに。⼈と⼈、そして⼈とAI の認識の精度を⾼める必要あり 14

rights reserved. Amazon Conﬁdential and Trademark. 16 The AI IDE for prototype to production

rights reserved. Amazon Conﬁdential and Trademark. Kiro : AWS が提供するエージェント型統合開発環境 • IDE と CLI の両⽅で利⽤可能 • IDEでは⽤途に合わせて Vibe / Spec の２つのモードを提供 Vibe モード対話しながら進めるプロトタイプや補助ドキュメント⽣成向き短距離の実装や探索で使いやすい Spec モード仕様駆動開発（Spec Driven Development: SDD）仕様を起点に進める明確な仕様を定義してから段階的に進める ☝ 17

rights reserved. Amazon Conﬁdential and Trademark. Spec モードの 3 つのドキュメント: 各段階を⼈間がレビューする • ドキュメントを順番に⽣成していき、各段階で⼈間が意思決定とレビューをするプロセス • AI が⼀気にコードを書くのではなく、認識のズレを早期に検知し、調整できる requirements.md 要件定義 EARS形式 / WHEN-THEN design.md 設計アーキテクチャ / ドメインモデル tasks.md 実装タスク作業単位へ分解 ☝ 18

rights reserved. Amazon Conﬁdential and Trademark. DEMO

rights reserved. Amazon Conﬁdential and Trademark. デモ動画

rights reserved. Amazon Conﬁdential and Trademark. requirements.md の構成 # Requirements Document 年間予算の⽉次配分（Annual Budget Monthly Allocation） ## Introduction: はじめに本ドキュメントは「年間予算の⽉次配分と再調整」業務に関するシステム要件を定義する。期初に決定した年間予算を⽉別に配分し、期中に発⽣する配分変更要望に応じて、⽉締め済み⽉を保護しつつ年間合計を維持したまま未締め⽉の中で再配分する機能を提供する。 ## Glossary: ⽤語集 - 年度: 4⽉始まり翌年3⽉終わりの12ヶ⽉（YYYY形式、例: 2026年度 = 2026/4 〜 2027/3） - ⽉別予算配分: 年度×部署×費⽬の組み合わせに対して定義される、12ヶ⽉分の⽉次予算（円） ## Requirements ### 要件1: ⽉別予算配分の参照ユーザーストーリー: 担当者として、⾃部署の年度×費⽬ごとの⽉別予算配分を⼀覧で確認したい。それにより、現状の配分と⽉締め状況を把握できる。 #### 受⼊基準 1. THE システム SHALL 年度×部署×費⽬の組み合わせごとに、4⽉〜翌年3⽉の12ヶ⽉分の⽉次予算を⼀覧表⽰する 2. THE システム SHALL 各⽉について、⽉次予算額・⽉締めフラグ（ロック状態）・直前保存時の値（変更前値）を表⽰する ... 21 ⚠ 読まなくていいよ︕

rights reserved. Amazon Conﬁdential and Trademark. requirements.md の構成 # Requirements Document 年間予算の⽉次配分（Annual Budget Monthly Allocation） ## Introduction: はじめに本ドキュメントは「年間予算の⽉次配分と再調整」業務に関するシステム要件を定義する。期初に決定した年間予算を⽉別に配分し、期中に発⽣する配分変更要望に応じて、⽉締め済み⽉を保護しつつ年間合計を維持したまま未締め⽉の中で再配分する機能を提供する。 ## Glossary: ⽤語集 - 年度: 4⽉始まり翌年3⽉終わりの12ヶ⽉（YYYY形式、例: 2026年度 = 2026/4 〜 2027/3） - ⽉別予算配分: 年度×部署×費⽬の組み合わせに対して定義される、12ヶ⽉分の⽉次予算（円） ## Requirements ### 要件1: ⽉別予算配分の参照ユーザーストーリー: 担当者として、⾃部署の年度×費⽬ごとの⽉別予算配分を⼀覧で確認したい。それにより、現状の配分と⽉締め状況を把握できる。 #### 受⼊基準 1. THE システム SHALL 年度×部署×費⽬の組み合わせごとに、4⽉〜翌年3⽉の12ヶ⽉分の⽉次予算を⼀覧表⽰する 2. THE システム SHALL 各⽉について、⽉次予算額・⽉締めフラグ（ロック状態）・直前保存時の値（変更前値）を表⽰する ... 22 はじめに: 業務プロセスや要件の概要⽤語集要件と受け⼊れ条件

rights reserved. Amazon Conﬁdential and Trademark. 要件と受け⼊れ条件が AI にも⼈間にも伝わる形に整理される PBIの⾃然⾔語をそのまま AI への実装の指⽰にせず、条件と結果が⾒える、構造化された、テスト可能な仕様として整理させる EARS : Easy Approach to Requirements Syntax 23 PBI（完全な⾃然⾔語） Requirements（EARS形式）読みやすい会話しやすい（いい意味でも悪い意味でも）解釈の余⽩がある⽂脈で補完できるが曖昧さがある構造化された⽂章状態・制約・通知先などを明⽰例: WHEN 条件 THEN 期待する結果

rights reserved. Amazon Conﬁdential and Trademark. EARS形式によって条件と結果が明確になる →明⽰されると誤解や曖昧さに気づける 24 やりたいこと / 受け⼊れ条件: • 貸出中の図書に対して予約できる • 返却されたら次の利⽤者に通知する • 予約は申し込み順に処理する • 予約数には上限を設ける • ⾃分の予約を確認・キャンセルできる受け⼊れ条件: WHEN 利⽤者が貸出中の図書を選択して予約を申し込んだ THEN システムは予約待ちリストの末尾に予約を登録する IF 利⽤者の予約数が区全体の上限に達している THEN システムは予約を拒否し、上限に達していることを表⽰する WHEN 通知後、取り置き期限である7⽇を過ぎた THEN システムは現在の予約を期限切れとして扱い、次の予約者に通知するこれってあってる︖ と⾔う議論につながる

rights reserved. Amazon Conﬁdential and Trademark. Event Storming の内容を Kiro に渡す 25 ⼈間ビジネスサイドが Event Storming を説明⽬的・業務フローを合わせる⼈間⽤語・プロセスを補⾜質問を繰り返して⽤語・前提などを確認 Kiro Requirements を作成業務内容を構造化⼈間 + Kiro 読み合わせで⼀⾏ずつ確認し、違和感があれば Kiro に伝えて修正 ※ ☝ なるべく聞き漏らさずに⼊⼒しまくる︕現場の⼈が話している⾔葉の中にこそ重要な概念がある。

rights reserved. Amazon Conﬁdential and Trademark. Kiroへのインプットで気をつけていること 1/2 Event Storming で理解した業務プロセスや⽤語の知識を⽂字で⼊⼒ • 画⾯キャプチャで試していたこともあったが、体感的に⽂字の⽅が正しく理解を⼊⼒できた • 最初に⽣成される requirements.md の精度が認識合わせの速度を⾼める業務プロセスを⼊⼒する前に、⼈の役割と⽬的を最初に伝える • 業務プロセスの説明だけだと、ユーザーストーリーが表⾯的になる • ⽬的を理解させることで、より精度が⾼まっている（気がする）ユーザーとして、出荷検査の結果を登録し承認に回付したい。それにより、製品を出荷できる。検査担当者として、起案した出荷検査結果について境界域測定値の有無と、過去6か⽉の同型品ロットの不適合実績を添えた状態で品質保証責任者に承認を回付したい。それにより、品質保証責任者が「市場流出リスクと納期遵守のバランス」を判断するために必要な情報が揃った状態で承認プロセスを進められ、出荷予定⽇前々⽇17:00の判定確定リードタイムを守れる。 26

rights reserved. Amazon Conﬁdential and Trademark. Kiroへのインプットで気をつけていること 2/2 業務フローを跨った⽤語集を読み込ませることで、コンテキストを理解させる • requirements.md は業務フロー単位で作っている • requirements.md で得た業務知識を保存し、 Kiro への⼊⼒の最初に読み込ませることで業務間での不整合を⼩さくする • 業務知識の整理は Kiro の Agent Hook 機能により省⼒化できる (Agnet Hook: ファイルの更新やイベントなどを検知してプロンプトを動かせる) requirements.md requirements.md requirements.md glossary.md 各要件のインプットでありアウトプットでもある 27

rights reserved. Amazon Conﬁdential and Trademark. しかし、Requirementsの⽂字だけでは成果物が想像しにくいことも... 特に、画⾯、操作感、状態遷移は⽂字だけでのイメージが難しい 28 WHEN 利⽤者が予約⼀覧を表⽰した THEN システムは図書名、著者、予約順位、受取館、状態、期限、操作ボタンを表⽰する WHEN 利⽤者が予約詳細を表⽰した THEN システムは書影、所蔵館、予約⽇時、通知⽅法、受取期限、注意事項を表⽰する WHEN 利⽤者が貸出中の図書を予約した THEN システムは予約状態を「予約中」にし、予約順位を付与する WHEN 取り置き期限を過ぎた THEN システムは状態を「期限切れ」にし、次の予約者へ繰り上げる画⾯: 状態遷移:

rights reserved. Amazon Conﬁdential and Trademark. 確認⽤の補助成果物を作って更にイメージを合わせる Requirementsで整理した要件から画⾯モック、状態遷移図、業務フロー図などを⽣成し⼈間同⼠の認識合わせを促進するための補助成果物を作っている（Vibe モード） 30 requirements.md 画⾯モック状態遷移図業務フロー図 👀 ビジネス側・開発者で画⾯やフローを確認違和感の修正は必ず requirements.md から

rights reserved. Amazon Conﬁdential and Trademark. 例: Requirements から画⾯モックを作るテキストでは「これで良さそう」と思っていても、画⾯モックを⾒ると違和感が⾒つかることが多い開発者側が勝⼿に「これは必要だろう」と思っているケースも割とある 31 過去の予約は⾒せなくていい前に何⼈待っているかが欲しい Point☝✅ HTML を 1 ファイルだけで作成させるあくまでも捨てるもの。作り込まない。出⼒スピード重視でコミュニケーションを促すビジネスサイドが持ち帰って他の⼈に⾒せやすい最終デザインではないことを必ず前置き細かいデザインにフォーカスして本質的な議論から脱線しないようにする

rights reserved. Amazon Conﬁdential and Trademark. 悩んで進まない時は、完成イメージの⾊んなパターンを出してみる Vibeモードで⾊んな画⾯モックのパターンを出し、「これだ︕」と思えるものがないかを探索する納得できたものを requirements.md に反映し、同じような画⾯モックが出るかを再確認次のフェーズへのインプットになる requirements.md に情報を反映する 32

rights reserved. Amazon Conﬁdential and Trademark. レビューでの⼤きな⼿戻り減＋開発速度Up Good 👍✨ 仕様の曖昧さを実装前に⾒つけやすくなった画⾯モックや状態遷移図で、開発イメージのずれを早期に確認できた Still important ⚠👀 ドメインモデルや責任分担の妥当性は⼈間が判断する⾮機能要件・運⽤・例外ケースなどは意識して確認する必要がある AI の出⼒はあくまでも叩き台、正解は⼈間同⼠で合意していく →AIで速くなるほど、開発者の設計レビュー⼒が重要になる 33

rights reserved. Amazon Conﬁdential and Trademark. 35

rights reserved. Amazon Conﬁdential and Trademark. 誰がリードするかを分け、必要に応じて巻き込むことで効率化 Event Storming では Design Level での会話を省いたが、 Requirements の確認によって業務ルールを合意できているから実装に近い設計判断は開発者中⼼でも進めやすくなる 36 requirements.md ビジネス＋開発者(共同) 業務ルールを条件と結果で明⽰状態・制約・通知先を確認全員で読み合わせて合意 design.md 開発者がリード (必要に応じてビジネス側に確認) ドメインモデル・責務を整理アーキテクチャ⽅針を検討 AIの提案をベースにレビュー Event Storming ビジネス＋開発者(共同) 業務プロセスを可視化課題・例外・⾔葉を揃える

rights reserved. Amazon Conﬁdential and Trademark. 役割分担: ⼈間が判断し、AI が形にする⼈間が判断・合意することビジネスの優先順位ドメイン知識の正確性業務ルール・例外の妥当性ステークホルダー間の合意形成設計・⾮機能の最終判断 AI に⽀援させること要件の構造化設計ドキュメントの⽣成実装タスクの分解確認⽤成果物の⽣成コード・テストの作成ドキュメントと実装の連動⼈間間で合意した業務理解を AI によって仕様・設計・実装の叩き台にする 37

rights reserved. Amazon Conﬁdential and Trademark. ユーザーストーリーと受け⼊れ条件をビジネスレビューの確認軸にするビジネスサイドとのレビュー会ではユーザーストーリーと受け⼊れ条件を⾒せながら機能を確認する確認ポイントの例: • 合意した条件を満たしていること • 業務ルールとして改めて違和感がないこと • 機能を使って業務をスムーズに実⾏できること 39

rights reserved. Amazon Conﬁdential and Trademark. 動くものを業務フロー全体と突き合わせて⾒直すレビューでは機能単位の確認に注⼒しがちかつ、Requirements だけをみていると業務プロセス全体の漏れに気づきにくい Event Storming の全体像があるから、動くものを「業務の流れ」に戻して確認できる💡✨ 特にハッピーパスは確認しやすいが、例外・分岐・⼿作業の考慮は漏れやすい実例: 「良さそう︕👍」と思っていたが、２割の業務プロセスの漏れを発⾒結果として、以降の計画に「例外・その他」を考慮する期間を追加 40

rights reserved. Amazon Conﬁdential and Trademark. 開発チームの時間のかけ⽅の変化前後で変わらないこと • 作るものをどんどん定義する必要があるので、認識合わせの時間は多く必要（⾜りなくなってきた）前後で変わったこと • Biz レビューの時間が増えた → 同じ期間の中で作れるものが増えて、レビュー対象が増えた • Dev レビューの時間が減った 42 Event Storming 25% Biz + Dev Bizレビュー 5% Biz + Dev 開発・レビュー 70% Dev 開発 2割レビュー 8割 Event Storming + Spec 25% Biz + Dev 開発・レビュー 65% Dev 開発 4割レビュー 6割 Bizレビュー 10% Biz + Dev 仕様駆動開発後仕様駆動開発前

rights reserved. Amazon Conﬁdential and Trademark. 開発者のレビュー負荷が減った Before : Event Storming + PBI + Vibe を使った要件の整理 • PBIを読んで意図を解釈し、「この基準は何︖」「どう制限する︖」などを質問する • ⽣成 AI が出してくる成果物が微妙にズレており、それを確認・調整するのに時間がかかる • ビジネス側の指摘も曖昧で、確認と微調整が頻発 After : Event Storming + SDD + 補助成果物を使った要件の整理 • Requirements を基準に条件と結果が構造化された要件(BDDとしても利⽤可)を確認する • 完成イメージを合意できているため、蛇⾜や誤りが少なく、求められていることが明確 • ⽣成 AI の実装・テストも、Requirements ベースの⽅が要件を満たせる精度が⾼い • 条件・例外・期待結果に沿ってレビューする: レビュー基準が明確おまけ : それ以外の⼯夫 • Checkstyle, formatter で静的解析＋フォーマットの指摘を考慮しないよう環境を整える • 共通的に考慮が必要なレビュー観点は、レビュー⽤のプロンプトにまとめて⽣成 AI に事前レビューさせる 43

rights reserved. Amazon Conﬁdential and Trademark. 認識合わせには時間の投資が必要 Event Storming と Spec を使った認識の合意は「軽い」プラクティスではない • ビジネスサイドの強いコミットが⼤前提 • ドメインエキスパート、業務担当、意思決定者が同じ場に座る • この時間を確保できないと、認識合わせは成⽴しないただし、効果も⼤きい • 業務理解と課題認識が揃った状態で開発に⼊れる • 投資する場所が「実装」から「認識合わせ」に前倒しされた • 単なるコストではなく、開発を速く進めるための投資 44

rights reserved. Amazon Conﬁdential and Trademark. AI時代の開発では、認識合わせの設計が重要になる⽣成 AI によって、実装は速くなったしかし、業務システムでは「何を作るか」の認識のズレが⼤きな⼿戻りにつながる • Event Storming: ⼈間同⼠の業務理解と課題の認識を揃える • Kiro Spec: 業務ルールを⼈間にも AI にも扱いやすい形に構造化する • 確認⽤成果物:完成イメージのズレを早期に⾒つける AI に判断を任せるのではなく、⼈間が合意した業務理解を AI が仕様・設計・実装の叩き台にする 👩🤝🤖🧡✨ 後で⼿戻る時間から、先に認識を揃える時間にシフトする💰✨ 明⽇からのプロジェクトで活かせる何かが⾒つかっていたら嬉しいです︕🙌

イベントストーミングと Kiroの仕様駆動開発で実現する 要件の認識合わせプロセス

イベントストーミングと Kiroの仕様駆動開発で実現する 要件の認識合わせプロセス

More Decks by syobochim

Other Decks in Technology

Featured

Transcript

イベントストーミングとKiroの仕様駆動開発で実現する要件の認識合わせプロセス

イベントストーミングと Kiroの仕様駆動開発で実現する要件の認識合わせプロセス