バイブコーディング、仕様駆動、その先へ - 「不確実性に対する検査‧適応のサイクル」を設計する

by Koichiro Matsuoka

Embed

Start on current slide

Slide 1

Slide 1 text

バイブコーディング、仕様駆動、その先へ不確実性に対する検査・適応のサイクルを設計する松岡幸一郎 / ログラススクフェス新潟 2026/5/9(ver1.1) 1

Slide 2

Slide 2 text

自己紹介 2

Slide 3

Slide 3 text

仕様駆動の、その先へバイブコーディング → 仕様駆動 → ? バイブコーディング: AIに感覚で指示し、すぐ動くものを作る短期は速いが、長期では品質・保守性に課題仕様駆動開発 (Spec Kit / Kiro 等): 仕様を先に固めてから実装する「事前に決めきる＝ウォーターフォール回帰」のリスクが指摘されている実装前に全部は決めきれない・大量ドキュメントだとレビュー観点も漏れるでは、仕様駆動の先に何があるのか？ AI時代の開発プロセスは、どう進化していけばいいのか？ 3

Slide 4

Slide 4 text

今日伝えたいこと結論は不確実性と向き合い、開発の各プロセスで検査と適応のサイクルを設計するとなりました。今日はこの結論に至った経緯と、具体的な手順をご紹介します。 4

Slide 5

Slide 5 text

アジェンダ全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 5

Slide 6

Slide 6 text

まず、時代背景からおさらいします。 6

Slide 7

Slide 7 text

1. 開発の各プロセスで検査と適応のサイクルを設計：コーディング速度X倍の現実コーディング速度は爆増。でも、開発全体の生産性は本当に上がってる？「速くなった実感はある」「でも全体で見ると…？」開発プロセス全体を見てみましょう 7

Slide 8

Slide 8 text

1. 開発の各プロセスで検査と適応のサイクルを設計：コーディング速度≠生産性コーディング2倍でも、全体では約10%の改善仮にコーディングが全体の約20%とすると、2倍になっても全体は約10%の改善にとどまる（数値に深い意味はありません）さらに、運用まで見据える必要がある開発プロセス全体の効率を考える必要がある 8

Slide 9

Slide 9 text

1. 開発の各プロセスで検査と適応のサイクルを設計：バイブコーディングから仕様駆動開発へ仕様駆動開発（SDD: Spec-Driven Development）の登場バイブコーディング: AIに感覚で指示してすぐ動くものを作れる要件と実装の乖離：細かい微調整・手直しを重ねて結局時間がかかる保守性の低下：長期の修正・拡張が困難品質の不確かさ：テストやセキュリティの検証が抜け落ちやすい短期は速い／長期では開発生産性は上がらない仕様駆動開発（SDD）がカウンターとして登場先にドキュメントで仕様を作り、開発プロセスの前半で品質検討 AI以前から言われていたシフトレフトに通じる考え方 9

Slide 10

Slide 10 text

ログラスにおける取り組み 10

Slide 11

Slide 11 text

1. 開発の各プロセスで検査と適応のサイクルを設計：取り組みの変遷① シフトレフトの実践コードレビュー → テスト設計 → 要件定義の前倒しへ社内のAIコーディングエージェントの取り組み、最初はコードレビュースキル、PR起点のテスト設計スキルから始めた QAがレビュー時点で「そもそもこの機能ってなんで？」と質問していることに気づく気づき: 背景情報がテキストになってないと QA も AI も判断できない機能の要求・要件・仕様をAIに質問されながら作るスキルを - 自前の軽量SDDスキルを展開 AI生産性改善の流れは、順当に「シフトレフト」して行った 11

Slide 12

Slide 12 text

1. 開発の各プロセスで検査と適応のサイクルを設計：取り組みの変遷② 仕様駆動設計の限界実装前に品質を上げ切るのは難しい実践して見えた限界: テキストレビューの限界：大量ドキュメントだと観点漏れに気づきにくい事前に決めきれない：実装しないと見えない設計課題がある横断的観点の漏れ：テスト戦略・非機能・全体整合中規模開発への対応: 単一ドキュメントだと粒度・記述量が破綻する 12

Slide 13

Slide 13 text

1. 開発の各プロセスで検査と適応のサイクルを設計：前倒しすればいいわけではない不確実性は最初に潰しきれない。だから検査と適応のサイクルが必要プロダクト開発には多様な不確実性がある: ニーズ：そもそも欲しいのか・課題は大きいかソリューション：その機能で本当に価値が出るのか技術：実際に作れるか・パフォーマンスは耐えられるかビジネス：収益が成り立つかどれも最初に全部潰しきれない。　だから各プロセスで検査と適応のサイクルを設計することが必要 13

Slide 14

Slide 14 text

1. 開発の各プロセスで検査と適応のサイクルを設計：大切なことこれは、アジャイルの基礎に立ち返るという話でもある「不確実性と向き合い、検査と適応のサイクルを回す」は、もともとアジャイルの基礎 AIの力で、このサイクルを高速に回せるようになった AIに実装の詳細を任せ、人間は価値や不確実性と向き合う仕事に集中。　これは今後のAI開発時代の中心になってくる。 14

Slide 15

Slide 15 text

では、どのように取り組むのか？ 15

Slide 16

Slide 16 text

1. 開発の各プロセスで検査と適応のサイクルを設計：具体的に何をするのかエピックとPBIに分け、プロセスごとに対応する不確実性と検証・適応を定義する ① エピックとPBI(プロダクトバックログアイテム)に分割して整理するエピックで大枠の要件・解決策を定義、PBIで実装可能な単位に詳細化 ② プロセスごとに「向き合う不確実性」と「実施する検証」を設計する要件定義／設計／実装／運用… 各プロセスで検査と適応のサイクルを定義セクション2 で詳細を説明していきます ※「エピック」は「プロジェクト」、「PBI」は「開発チケット」など言い換えてもらってOKです 16

Slide 17

Slide 17 text

1. 開発の各プロセスで検査と適応のサイクルを設計：ホリスティックテスティングループ全体で「不確実性と向き合う」ログラスでは最近シフトレフトではなくホリスティックテスティングという言葉を使っている Janet Gregory / Lisa Crispin（"Agile Testing"シリーズ共著者）が提唱引用元: https://janetgregory.ca/testing-from-a-holistic-point-of-view/ → ホリスティックテスティングについて詳細は深掘りしないが、「開発の無限ループ全体に品質を織り込む」という考え方が共通している 17

Slide 18

Slide 18 text

アジェンダ全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 18

Slide 19

Slide 19 text

2. エピックとPBIへの分割、プロセスごとの設計：単一ドキュメントの限界中規模以上の開発では、単一ドキュメントだと粒度・記述量が破綻する仕様駆動設計のツール（Kiro / GitHub Spec Kit など）は、 1つの開発に対して、要件・設計・タスクのドキュメントを作成してから実装ただし、これは小規模の単発機能向きのフォーマット中規模以上のプロジェクトに当てはめると、すぐに限界が来る：粒度の不一致：要件やプロジェクト方針、仕様やテストの詳細などが同じ階層に混在記述量の爆発：1ファイルが膨大になり、AIにもレビュアーにも読み切れない解決策：エピックとPBIに分割する 19

Slide 20

Slide 20 text

2. エピックとPBIへの分割、プロセスごとの設計：エピックとPBIに分ける定義すべきことと作成すべきファイルを整理する前スライドの2つの問題（粒度・記述量）を、エピックとPBIへの分割で整理: 粒度の不一致 → 関心の分離: エピックは「何を／なぜ作るか」、PBIは「どう作るか」。記述量の爆発 → 情報の細分化: PBI単位に分けることで以下のことから品質を上げやすくなる AIがコンテキストウインドウに載せる情報を絞れる人間もレビューで品質を上げやすくなる階層単位向き合う不確実性記述するものエピックプロジェクト／機能群 What / Why （何を／なぜ作るか）要求・要件・大まかな仕様・大まかな技術設計・プロジェクト計画・テスト計画 PBI バックログアイテム How（どう実装するか）受入基準・細かい技術設計・PBI単位のテスト 20

Slide 21

Slide 21 text

2. エピックとPBIへの分割、プロセスごとの設計：プロセスごとに不確実性は違うエピック／PBIを、さらに「プロセス」で分けるエピックとPBIに分けたら、それぞれの中を細かいプロセスに分割するプロセスごとに向き合う不確実性の質が違うからプロセス単位で「向き合う不確実性 × 検査と適応の方法」を設計する 21

Slide 22

Slide 22 text

2. エピックとPBIへの分割、プロセスごとの設計：エピックレベルのプロセス例プロセス定義の例を紹介次の2ページにプロセス定義の一例を記載します。チームの開発スタイルに応じて再定義してくださいプロセスごとの取り組みの詳細はセクション3で紹介します 22

Slide 23

Slide 23 text

2. エピックとPBIへの分割、プロセスごとの設計：エピックレベルのプロセス例エピックにおけるのプロセス # プロセス向き合う不確実性アプローチ 1 要件定義ユーザーの課題を解決できる要件になっているか PRD作成支援/レビューのスキル作成・要求/要件ID を付与・DDDのドメインモデリング 2 大枠の技術設計機能・非機能要件を満たせる設計になっているかテーブル/サービス/非同期の大枠設計共通観点でのレビュー用スキル作成 3 PBI分割エピックを過不足なくPBIに分解できているか分割とエピック/PBI 漏れチェック・SP見積もりのスキル作成 4 リスク分析全プロセスのどこに不確実性があるか（向き合う対象の棚卸しそのもの）不確実性の棚卸し（テンプレ型化・後続計画に反映・継続的に見直し） 5 プロジェクト計画リリース順序とリスクが整合した計画が組めるかリリース計画・依存関係・優先度・リスク順序の整合立案後、継続的に見直し 6 テスト計画適切なタイミングでテストを実施できる計画かテスト戦略・統合/受入/リグレッション/UAT のタイミング設計 23

Slide 24

Slide 24 text

2. エピックとPBIへの分割、プロセスごとの設計：PBIレベルのプロセス例 PBIにおけるプロセス # プロセス向き合う不確実性アプローチ 7 PBI詳細化 (受入基準・技術設計) 受入基準・技術詳細を明確化できるか各PBIで受入基準・技術設計・単体/結合テストを詳細化。エピックへ逆算更新それぞれの作成支援とレビューをスキル化 8 実装設計通りに実装できるか・モデルから逸脱しないかアーキテクチャ・コーディングルール定義コーディングルールドキュメント整備・コードレビュースキル作成 9 テスト受入基準を満たしている確証が得られるかテストコード実装・AI操作によるテスト・受入基準達成確認プロセスは行ったり来たり: 一直線で完成するのではなく、各段階の発見を上流にフィードバックする前提テスト工程はさらに細分化可能（単体／結合／受入／UAT／リグレッション等）。本資料では深掘りしない 24

Slide 25

Slide 25 text

アジェンダ全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 25

Slide 26

Slide 26 text

3. 開発プロセスごとのアプローチプロセスごとにアプローチを紹介全般エピック要件定義技術設計 PBI分割リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化実装テスト 26

Slide 27

Slide 27 text

3. 開発プロセスごとのアプローチ：[全般] スキルとは何かスキルを作るのが開発プロセス改善のキモここから各プロセスにスキルを作っていくことをお勧めしていくその前に「スキル」とは何かを整理スキルを作る＝ AIに渡す観点・テンプレ・手順を形式知にし、AIが再現可能にすること開発プロセスをAI化していく上で起点になるものであるこれは要件定義だけでなく、技術設計・PBI分割・実装…各プロセスでも同様 27

Slide 28

Slide 28 text

3. 開発プロセスごとのアプローチ：[全般] スキルは「作成支援」と「レビュー」に分ける作成支援とレビューは分けるとよい作成支援スキル: アウトプット（PRD・設計書・PBI 等）を作るための観点・テンプレレビュースキル: アウトプットをレビューするための観点ただし同じような観点ドキュメントを共通で読み込むのはなぜ分けるのか：レビューを独立したほうがクオリティを上げやすい「作成に必要なコンテキスト量>>レビューに必要なコンテキスト量」なためレビューだけで改善点がなくなるまで何度も実行できるためこれは2026年5月時点の話で、モデルの性能が上がれば変わる可能性あり 28

Slide 29

Slide 29 text

3. 開発プロセスごとのアプローチ：[全般] Question-First：AIに質問させて論点を洗い出すドキュメントレビューはAIに質問させる形にすると効果的大量のドキュメントを見て改善点を出すのは難しい AIに質問させる = 論点を洗い出す重要な論点が最初に出ると、検討が進めやすい Claude Code は AskUserQuestion ツールで選択式回答選択肢に推奨度＋理由を書かせると、「こう思うけどどう？」と議論しやすい勝手に聞いてくれない場合: 「現時点で検討すべき重要なことを優先して質問して」と指定 29

Slide 30

Slide 30 text

3. 開発プロセスごとのアプローチ：[全般] トレーサビリティは品質向上のポイント IDで繋ぐと、AIに「網羅性」と「影響範囲」を機械的に検証させられる要求 → 要件 → 仕様 → 設計 → PBI → テストなどを IDで紐付けるこのトレーサビリティは品質向上のために重要なぜ重要か：網羅性とスコープの整合: 要件実装の双方向で、抜け漏れ・余剰をAIが検知できる影響範囲の把握: 要件変更時に、どの設計・PBI・テストが影響を受けるか追える欠陥からの逆引き: 問題発生時に原要件まで遡って根本原因にたどり着けるこれも要件定義だけでなく、以降の全プロセスでも共通のポイント 30

Slide 31

Slide 31 text

3. 開発プロセスごとのアプローチプロセスごとにアプローチを紹介全般エピック要件定義技術設計 PBI分割リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化実装テスト 31

Slide 32

Slide 32 text

3. 開発プロセスごとのアプローチ：[1.要件定義] エピック単位でPRDを書く PRD「フォーマット定義」「ID付与」「レビュー観点」などをスキル化 ① フォーマット定義 × Question-First（AIに質問させて論点を洗い出す）な作成支援スキル要求 / 要件 / 大まかな仕様 / 完了条件のフォーマットを定義 AIが既存ドキュメントを読み込み、不明点や意思決定すべきことを質問しながら埋める ② ID付与によるトレーサビリティ検証要求ID／要件ID／仕様IDなどを振り、対応を明確化過不足や矛盾がないかを機械的に検証 ③ 毎回見るべきレビュー観点をスキルにすることで標準化フォーマット、そこに書くべきことを満たしているか用語の統一多機能との横串観点　など 32

Slide 33

Slide 33 text

3. 開発プロセスごとのアプローチ：[1.要件定義] DDD（ドメイン駆動設計） DDDのアプローチはAI時代にも役立つ DDD(ドメイン駆動設計): プロダクト開発で大きな価値を生むための手法目的: 機能性（役に立つものを作る）× 保守性（長期間作り続けられる） DDDの2つのアプローチは、AI時代にそれぞれ活用できる：モデリング: 作るものを整理し、AIに渡す「共通言語」になる実装パターン: 実装のガードレールとしてAIの出力を制約する次ページで、取り組みやすいDDDのモデリングを紹介 33

Slide 34

Slide 34 text

3. 開発プロセスごとのアプローチ：[1.要件定義] sudoモデリングハードルが低く効果が出しやすい4つの図図やること S: システム関連図システムに関わるアクター・外部システムとの関連を明示 U: ユースケース図ユーザーごとに「どんな操作をするか」を描く D: ドメインモデル図概念と概念の関係を抽象的に描き、共通言語を作る O: オブジェクト図具体例で理解を深め、モデルの矛盾・漏れを検証これは「どんな時にもやると良い最低限の4つ」業務フロー図／状態遷移図／シーケンス図などは併用するとよいモデリングのポイント：抽象と具体を行き来し、仮説を回し続ける: 具体例が出せない＝ドメイン理解が足りないサイン 34

Slide 35

Slide 35 text

詳細は別資料に https://speakerdeck.com/littlehands/dddxshi-yang-qu-dong-dehui-sugao-pin-zhi-kai-fa-nopurosesushe-ji 35

Slide 36

Slide 36 text

3. 開発プロセスごとのアプローチ：[1.要件定義] draw.io × AI を実現するスキル AIがdraw.ioファイルを直接操作できるスキルを作成 claude-drawio-skill: https://github.com/little-hands/claude-drawio-skill 「この処理をシーケンス図で整理して」などと指示するだけで .drawio ファイルが完成 Claude Code のスキルとして動作し、プロジェクトに導入するだけで使える公式のスキルもあり：https://github.com/jgraph/drawio-mcp/tree/main/skill-cli モデリングだけでなく、仕様設計・技術設計など幅広く活用できる 36

Slide 37

Slide 37 text

3. 開発プロセスごとのアプローチ：[1.要件定義] draw.io × AI で壁打ち「具体例を出して」と聞くだけで、オブジェクト図（具体例）を生成 37

Slide 38

Slide 38 text

3. 開発プロセスごとのアプローチ：[1.要件定義] draw.io × AI draw.ioをAIに読ませて壁打ち：1人では出ない観点を引き出す「この図の懸念点は？」と聞くと、検討すべきポイントを提示 1人では見落としがちな観点を、AIが補完してくれる 38

Slide 39

Slide 39 text

3. 開発プロセスごとのアプローチ全般エピック要件定義技術設計 PBI分割リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化実装テスト 39

Slide 40

Slide 40 text

3. 開発プロセスごとのアプローチ：[2.技術設計] プロジェクト段階の大枠前提が変わるとPBIに大きく波及する箇所を早く潰すドメインモデリング・テーブル設計・利用する外部サービス等の大枠を設計。意思決定によってPBIのラインナップが大きく変わりうるものはここである程度決める 40

Slide 41

Slide 41 text

3. 開発プロセスごとのアプローチ：[2.技術設計] 二次元の図で検証するテキストだけでやりきらず、AIと一緒に「図」で検証する技術設計はテキストだけだとレビューが辛い draw.ioなどを使って二次元の図にする：直感的に把握できる: 依存関係・データフローが一目で分かるちょうどいい抽象度で考えられる図を扱うスキル化（claude-drawio-skill など）は前述のとおり、技術設計でも同じ枠組みで使える 41

Slide 42

Slide 42 text

3. 開発プロセスごとのアプローチ：[2.技術設計] 二次元の図で検証する（例）クラス設計の例 SDDライブラリだとテキストで出力されるが、図で確認すると精度も効率も向上x 42

Slide 43

Slide 43 text

3. 開発プロセスごとのアプローチ全般エピック要件定義技術設計 PBI分割リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化実装テスト 43

Slide 44

Slide 44 text

3. 開発プロセスごとのアプローチ：[3.PBI分割] 分割 → 受入基準埋め → 漏れチェックエピックから PBIへの分割をAIにやらせるエピックドキュメントを起点にPBIに分割各PBIに受入基準・概要・関連ドキュメントなど記載 ID付与して漏れチェックと見積もり（次ページ）を実施依存関係も定義すると、後の計画で便利受入基準は後でPBI単位でリファインメントする前提の粒度のものこの機械的な作業はAIの得意分野 44

Slide 45

Slide 45 text

3. 開発プロセスごとのアプローチ：[3.PBI分割] ストーリーポイントで見積もる見積もりは「期間」ではなく「規模・複雑度・不確実性を加味した相対値」いわゆるストーリーポイント基準となる PBI を決めて、他PBIを比較フィボナッチ数列（1, 2, 3, 5, 8, 13…）を使うのが一般的基準はSP2のものと3のものあたりを決めるのがおすすめかかる日数・時間は条件によってばらつくが、ストーリーポイントは基準を定めればある程度揃うので、AIが算出しやすい分割や見積もり時に不明な点はAIに随時質問させるこれはもともとの見積もりの効果の一つ 45

Slide 46

Slide 46 text

3. 開発プロセスごとのアプローチ全般エピック要件定義技術設計 PBI分割リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化実装テスト 46

Slide 47

Slide 47 text

3. 開発プロセスごとのアプローチ：[4.リスク分析] テンプレートとスキルで型化、結果を計画に反映不確実性を網羅・型化し、後続のプロジェクト計画に反映する「リスクを分析して」という指示だけでもある程度やってくれる普段やっていなくても、AIに考えさせるだけでも意外と発見がある観点を固定化したかったらスキル化結果を後続のプロジェクト計画に反映: 高リスク項目 → 早期検証を計画中リスク項目 → モニタリング項目として計画に組み込み継続的に状況アップデート 47

Slide 48

Slide 48 text

3. 開発プロセスごとのアプローチ：[5.プロジェクト計画] 計画の叩きをAIに作らせる地道で大事な作業の叩きをAIに、人間は最終判断に集中地味だけど大事な作業の叩きをAIに作らせる依存関係を考慮した計画作りリスクを考慮した順序検討（プロトタイピング・先行実装・PoCをどこに置くか）人間が向き合いにくい現実とも向き合わせてくれるデータが溜まってくると：「過去プロジェクトの傾向では、このスケジュールは無理そう」と指摘させられる最後の確認とスケジュールの意思決定は人間。でも叩きと現実の指摘があるだけで、判断のスピードと質が一段上がる 48

Slide 49

Slide 49 text

3. 開発プロセスごとのアプローチ：[6.テスト計画] テストレベル × 種別 × 実施手段で計画するテストレベル・テスト種別を含めて広く計画する AIに任せたままだとユニットテストに閉じがち以下のような観点で幅広く計画するテストレベル: 単体／結合／システム／受入／UAT テスト種別: 機能／非機能（性能・セキュリティ等）／回帰／探索的時期: PBI受入は実装直後／統合は機能群完成時／UAT はリリース前 QAの方の知見スキル化すると再現性が高まる 49

Slide 50

Slide 50 text

3. 開発プロセスごとのアプローチ全般エピック要件定義技術設計 PBI分割リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化実装テスト 50

Slide 51

Slide 51 text

3. 開発プロセスごとのアプローチ：[7.PBI詳細化] 要件・設計・タスクを詳細化各PBIで受入基準・技術設計・テスト設計を詳細化仕様駆動ツール（Spec Kit / Kiro 等）でドキュメントを作る感覚エピックドキュメント／他のPBIとの整合性をAIにチェックさせるこの段階で発見があればエピックドキュメントを逆算更新不明点は Question-First でAIに質問させながら詰める（前述） PBI単位でのレビュー観点をスキル化すると◎ 51

Slide 52

Slide 52 text

3. 開発プロセスごとのアプローチ：[7.PBI詳細化] Specification by Example（SBE）具体例を書くと、コーナーケースが勝手に炙り出される実例による仕様(SbE: Specification by Example) 抽象的な仕様: 「ユーザーは検索結果を並べ替えることができる」 → 解釈が分かれる・コーナーケースが見えない実例（Given/When/Then）: Given: 商品A（1000円）、商品B（500円）が存在 When: 「価格: 安い順」で並べ替え Then: 商品B → 商品A の順で表示具体例を書こうとすると、自然にコーナーケースが洗い出される具体例はAIが実施するテストケースにもそのまま使える sudoモデリングや実例マッピングが効果的（エピック・PBI両段階で実施可能） ※ SBEや実例マッピングの詳細説明は割愛 52

Slide 53

Slide 53 text

3. 開発プロセスごとのアプローチ全般エピック要件定義技術設計 PBI分割リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化実装テスト 53

Slide 54

Slide 54 text

3. 開発プロセスごとのアプローチ：[8.実装] ruleドキュメント＋クオリティゲートガードレールで縛り、決定論的検証で品質を担保コーディングルールの定義がとても大切アーキテクチャレベル：オニオン／クリーンアーキテクチャなど各レイヤーの詳細：DDDの実装パターン・実装原則など CLAUDE.md / .claude/rules/ などコーディングエージェントの仕組みを活用 AIレビューと静的解析を使い分ける：静的解析でカバーできる範囲は決定論的にチェック AI判断は静的解析で届かない領域に絞る（決定論のほうが確実性が高い） 54

Slide 55

Slide 55 text

3. 開発プロセスごとのアプローチ全般エピック要件定義技術設計 PBI分割リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化実装テスト 55

Slide 56

Slide 56 text

3. 開発プロセスごとのアプローチ：[9.テスト] テスト実行手段の3種類自動テスト × 手動テスト × AIによるテスト実行手段特徴使いどころ ① スクリプトによる自動テスト決定論的・繰り返し単体・結合・主要パス ② 手動テスト人間の判断が必要 UX・探索的テスト ③ AIによる自動テスト自然言語で指示・画面操作受入テスト何も指示しないと ① のみになりがち適切に使い分けるのが重要 ③ は新しい手段として意識的に扱う画面確認までAIに任せられると、人間は最終確認だけに集中できる AIにテストレポート（キャプチャ・動画付き）を書かせる → 人間がレビューしやすい形に 56

Slide 57

Slide 57 text

3. 開発プロセスごとのアプローチ：次のセクションへの橋渡し観点は分かった。でも、全プロセス一気にはできないここまでで、プロセスごとのアプローチを見てきたでも、全プロセスを一気にスキル化するのは現実的じゃないこれも結局は「検査と適応のサイクル」を、どのプロセスから設計し始めるかの選択次のセクションで「どのように着手していくか」を紹介する 57

Slide 58

Slide 58 text

アジェンダ全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 58

Slide 59

Slide 59 text

4. AI活用フェーズの可視化と目標設定：AI活用の4つのフェーズまずは現在地を測る — そのための物差しが「4つのフェーズ」優先順位を決めるには、まず各プロセスの現在地（成熟度）を測る必要があるそのための物差しとして、AI活用度を4つのフェーズに分けて整理するフェーズ内容 1. 個人利用 Claude Code 等のコーディングエージェントをそれぞれが個別に使う 2. スキル共通化チームで特定プロセス用のスキルを定義し、手順や知見を共通化する（点としてのスキル） 3. プロセス再定義・スキルによる連結 AI前提で開発プロセスを再定義し、各プロセスについてスキルを定義。前のスキルのアウトプットが次のスキルのインプットになるよう設計（点のスキルが繋がって線になる） 4. AIによる自律的開発各プロセスにおいてAIが自律的に判断する割合を増やしていく参考: ELEKS「AI SDLC Maturity Model」（https://eleks.com/blog/ai-sdlc-maturity-model/) 　　をベースにカスタマイズ 59

Slide 60

Slide 60 text

4. AI活用フェーズの可視化と目標設定：マトリクスの活用フロー（3つの手順）現状記入 → 課題感記入 → 目標と取り組み記入以下の手順で現状を認識して、取り組む課題を設定する改善余地がないところをAI化しても意味がないので、優先して改善したいところは課題ベースで定義する手順やること ① 現状の活用フェーズ（1〜4）をプロセスごとに記入（自チームの可視化） ② 現状の各プロセスの課題感が強いところを記入（優先度を明確化） ③ 一定期間（四半期/半年）における、プロセスごとの目標フェーズと具体的な取り組みを記入 60

Slide 61

Slide 61 text

4. AI活用フェーズの可視化と目標設定：プロセス × Phaseのマトリクス実際の目標設定例 # プロセス現状優先して改善したい点次の四半期で目指すPhase やること 1 要件定義 Phase 1 テンプレが未整備、レビューが属人化 Phase 2 PRD作成支援・要件IDトレースのスキル化 2 技術設計 Phase 1 Phase 1 3 PBI分割 Phase 1 Phase 1 4 リスク分析 Phase 0 リスク分析未着手 Phase 2 リスク管理スキル作成 5 プロジェクト計画 Phase 0 Phase 2 6 テスト計画 Phase 0 標準化・底上げしたい Phase 1 テスト戦略テンプレ・タイミング設計のスキル化マトリクスを埋める行為そのものが「現状の検査 → 次の打ち手の適応」のサイクル 61

Slide 62

Slide 62 text

アジェンダ全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 62

Slide 63

Slide 63 text

5. まとめ：今日のまとめ不確実性と向き合い、プロセスごとに検査と適応のサイクルを設計する「不確実性と向き合い、検査と適応のサイクルを回す」はもともとアジャイルの基礎 AIの力でこのサイクルを高速に回せるようになった AIに実装の詳細を任せ、人間は価値や不確実性と向き合う仕事に集中できるのが理想形！よいプロダクト開発をしていきましょう 63

Slide 64

Slide 64 text

5. まとめ：Q&A / 参考リンクご質問があればお気軽にどうぞ！ X（匿名質問OK）: https://x.com/little_hand_s 過去の勉強会動画（sudoモデリング詳細）: https://www.youtube.com/watch? v=HgtCKlOzRiQ 書籍: 「ドメイン駆動設計モデリング/実装ガイド」: https://littlehands.booth.pm/items/1835632 「ドメイン駆動設計サンプルコード&FAQ」: https://littlehands.booth.pm/items/3363104 一緒にモデリングする勉強会: https://little-hand-s.notion.site/DDD- 22429f7110574439a4c3e126c20fa9a2 64

Slide 65

Slide 65 text

ご清聴ありがとうございました松岡幸一郎 X(Twitter): @little_hand_s 65