© 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の仕様駆動開発で実現する 要件の認識合わせプロセス 

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

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

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

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

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

© 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. ⼈と⼈の間の認識を合わせる: Event Storming 

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

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

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

© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential 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 にフォーカス 

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

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

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

© 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. ⼈と⼈、⼈とAIの認識を合わせる: Kiro 仕様駆動開発 

© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential and Trademark. 16 The AI IDE for prototype to production 

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

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

© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential and Trademark. DEMO 

© 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. 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 ⚠ 読まなくていいよ︕ 

© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential 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 はじめに: 業務プロセスや要件の概要 ⽤語集 要件と受け⼊れ条件 

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

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

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

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

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

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

© 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. ⼈と⼈の認識を合わせる: Vibe モードで認識合わせを加速 

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

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

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

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

© 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. 全体ワークフロー 

© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential and Trademark. 35 

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

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

© 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. Event Storming と Spec を 最後の確認にも使う 

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

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

© 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. 現場での過ごし⽅ 

© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential 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 仕様駆動開発後 仕様駆動開発前 

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

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

© 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. まとめ 

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

© 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential and Trademark. Thank you! © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon Confidential and Trademark. しょぼちむ @syobochim