AI駆動開発で生産性を追いかけたら、行き着いたのは品質とシフトレフトだった

AIを使い始めてからコーディング速度は上がりました。でも、「生産性が上がった」という実感はなかなか持てませんでした。

最初はPRレビューにAIを活用していました。コードの問題を指摘してもらい、品質を上げようとしていました。でも、PRの段階でレビューしても、手戻りはあまり減らなかったのです。

「おかしい。もっと手前に問題があるはずだ」

そこから上流を見るようになりました。受入基準が曖昧なまま実装が進んでいること、テスト設計が後回しになっていること。AIに任せるほど、「何を作るか」「どうなったら完了か」の明確さが重要だと気づきました。

行き着いたのは、シフトレフトでした。

でも、シフトレフトは「やった方がいいのはわかってる」けど難しいプラクティスです。スキルが必要で、時間もかかり、急いでいるときほど後回しになる。

そこで変わったのがAIの使い方です。受入基準のAIレビュー、Question-Firstで論点を洗い出す、テスト設計をSkillとして言語化する、コンテキスト情報をつなぐ…。AIは「コードを書く道具」ではなく、「シフトレフトのハードルを下げる道具」として機能し始めました。

これは、AIと行う「新しいシフトレフト」だと思っています。

本セッションでは、私がPRレビューから受入基準・テスト設計へと遡っていった試行錯誤と、各フェーズでのAI活用による品質向上の具体的な工夫をお伝えします。まだ途中経過ですが、同じように「AIを使っているのに生産性が上がらない」と感じている方のヒントになれば嬉しいです。

Transcript

1. AI駆動開発で生産性を追いかけたら、行き着いたのは 品質とシフトレフトだった AIと行う「新しいシフトレフト」 松岡 幸一郎 / ログラス スクフェス新潟 2026/5/9 1
2. 自己紹介 2
3. 「行き着いたのは品質とシフトレフトだった」 と、いうタイトルでプロポーザルを出したのですが ※ シフトレフトとは、テストや品質向上の活動を開発プロセスの 「左側」 （上流） に移動させる考え方 3
4. プロポーザルから2ヶ月、 「シフトレフト」という表現じゃないかも、となりました では、なにかというと… 4
5. 不確実性と向き合い、開発の各プロセスで検査と適応のサイクルを設計する という結論です！ 今日はこの結論に至った経緯と、具体的な手順をご紹介します。 5
6. アジェンダ 全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 6
7. まず、時代背景からおさらいします。 7
8. 1. 開発の各プロセスで検査と適応のサイクルを設計：コーディング速度X倍の現実 コーディング速度は爆増。でも、開発全体の生産性は本当に上がってる？ 「速くなった実感はある」 「でも全体で見ると…？」 開発プロセス全体を見てみましょう 8
9. 1. 開発の各プロセスで検査と適応のサイクルを設計：コーディング速度≠生産性 コーディング2倍でも、全体では約10%の改善 仮にコーディングが全体の約20%とすると、2倍になっても全体は約10%の改善にとどまる （数値に深い意味はありません） さらに、運用まで見据える必要がある 開発プロセス全体の効率を考える必要がある 9
10. 1. 開発の各プロセスで検査と適応のサイクルを設計：バイブコーディングから仕様駆動開発へ 仕様駆動開発（SDD: Spec-Driven Development）の登場 バイブコーディング: AIに感覚で指示してすぐ動くものを作れる 要件と実装の乖離：細かい微調整・手直しを重ねて結局時間がかかる 保守性の低下：長期の修正・拡張が困難 品質の不確かさ：テストやセキュリティの検証が抜け落ちやすい 短期は速い／長期では開発生産性は上がらない 仕様駆動開発（SDD） がカウンターとして登場 先にドキュメントで仕様を作り、開発プロセスの前半で品質検討 AI以前から言われていたシフトレフトに通じる考え方 10
11. ログラスにおける取り組み 11
12. 1. 開発の各プロセスで検査と適応のサイクルを設計：取り組みの変遷① シフトレフトの実践 コードレビュー → テスト設計 → 要件定義の前倒しへ 社内のAIコーディングエージェントの取り組み、 最初はコードレビュースキル、PR起点のテスト設計スキルから始めた QAがレビュー時点で「そもそもこの機能ってなんで？」と質問していることに気づく 気づき: 背景情報がテキストになってないと QA も AI も判断できない 機能の要求・要件・仕様をAIに質問されながら作るスキルを - 自前の軽量SDDスキルを展開 AI生産性改善の流れは、順当に「シフトレフト」して行った 12
13. 1. 開発の各プロセスで検査と適応のサイクルを設計：取り組みの変遷② 仕様駆動設計の限界 実装前に品質を上げ切るのは難しい 実践して見えた限界: テキストレビューの限界：大量ドキュメントだと観点漏れに気づきにくい 事前に決めきれない：実装しないと見えない設計課題がある 横断的観点の漏れ：テスト戦略・非機能・全体整合 中規模開発への対応: 単一ドキュメントだと粒度・記述量が破綻する 13
14. 1. 開発の各プロセスで検査と適応のサイクルを設計：前倒しすればいいわけではない 不確実性は最初に潰しきれない。だから検査と適応のサイクルが必要 プロダクト開発には多様な不確実性がある: ニーズ：そもそも欲しいのか・課題は大きいか ソリューション：その機能で本当に価値が出るのか 技術：実際に作れるか・パフォーマンスは耐えられるか ビジネス：収益が成り立つか どれも最初に全部潰しきれない。 　だから 各プロセスで検査と適応のサイクルを設計することが必要 14
15. 1. 開発の各プロセスで検査と適応のサイクルを設計：大切なこと これは、アジャイルの基礎に立ち返るという話でもある 「不確実性と向き合い、検査と適応のサイクルを回す」は、もともとアジャイルの基礎 AIの力で、このサイクルを高速に回せるようになった AIに実装の詳細を任せ、人間は価値や不確実性と向き合う仕事に集中。 　これは今後のAI開発時代の中心になってくる。 15
16. では、どのように取り組むのか？ 16
17. 1. 開発の各プロセスで検査と適応のサイクルを設計：具体的に何をするのか エピックとPBIに分け、 プロセスごとに対応する不確実性と検証・適応を定義する ① エピックとPBI(プロダクトバックログアイテム)に分割して整理する エピックで大枠の要件・解決策を定義、PBIで実装可能な単位に詳細化 ② プロセスごとに「向き合う不確実性」と「実施する検証」を設計する 要件定義／設計／実装／運用… 各プロセスで検査と適応のサイクルを定義 セクション2 で詳細を説明していきます ※「エピック」は「プロジェクト」 、 「PBI」は「開発チケット」など言い換えてもらってOKです 17
18. 1. 開発の各プロセスで検査と適応のサイクルを設計：ホリスティックテスティング ループ全体で「不確実性と向き合う」 ログラスでは最近 シフトレフトではなくホリスティックテスティング という言葉を使っている Janet Gregory / Lisa Crispin（"Agile Testing"シリーズ共著者）が提唱 引用元: https://janetgregory.ca/testing-from-a-holistic-point-of-view/ → ホリスティックテスティングについて詳細は深掘りしないが、 「開発の無限ループ全体に品質を織り込む」という考え方が共通している 18
19. アジェンダ 全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 19
20. 2. エピックとPBIへの分割、プロセスごとの設計：単一ドキュメントの限界 中規模以上の開発では、単一ドキュメントだと粒度・記述量が破綻する 仕様駆動設計のツール（Kiro / GitHub Spec Kit など）は、 1つの開発に対して、要件・設計・タスクのドキュメント を作成してから実装 ただし、これは小規模の単発機能向きのフォーマット 中規模以上のプロジェクトに当てはめると、すぐに限界が来る： 粒度の不一致：要件やプロジェクト方針、仕様やテストの詳細などが同じ階層に混在 記述量の爆発：1ファイルが膨大になり、AIにもレビュアーにも読み切れない 解決策：エピックとPBIに分割する 20
21. 2. エピックとPBIへの分割、プロセスごとの設計：エピックとPBIに分ける 定義すべきことと作成すべきファイルを整理する 前スライドの2つの問題（粒度・記述量）を、エピックとPBIへの分割で整理: 粒度の不一致 → 関心の分離: エピックは「何を／なぜ作るか」 、PBIは「どう作るか」 。 記述量の爆発 → 情報の細分化: PBI単位に分けることで以下のことから品質を上げやすくなる AIが コンテキストウインドウに載せる情報を絞れる 人間もレビューで品質を上げやすくなる 階層 単位 向き合う不確実性 記述するもの エピック プロジェクト／機能群 What / Why （何を／なぜ作るか） 要求・要件・大まかな仕様・大まかな技術設計 ・プロジェクト計画・テスト計画 PBI バックログアイテム How（どう実装するか） 受入基準・細かい技術設計・PBI単位のテスト 21
22. 2. エピックとPBIへの分割、プロセスごとの設計：プロセスごとに不確実性は違う エピック／PBIを、さらに「プロセス」で分ける エピックとPBIに分けたら、それぞれの中を細かいプロセスに分割する プロセスごとに 向き合う不確実性の質が違う から プロセス単位で「向き合う不確実性 × 検査と適応の方法」を設計する 22
23. 2. エピックとPBIへの分割、プロセスごとの設計：エピックレベルのプロセス例 プロセス定義の例を紹介 次の2ページにプロセス定義の一例を記載します。 チームの開発スタイルに応じて再定義してください プロセスごとの取り組みの詳細はセクション3で紹介します 23
24. 2. エピックとPBIへの分割、プロセスごとの設計：エピックレベルのプロセス例 エピックにおけるのプロセス # プロセス 向き合う不確実性 アプローチ 1 要件定義 ユーザーの課題を解決できる要件になって いるか PRD作成支援/レビューのスキル作成・要求/要件ID を付与・DDDのドメインモデリング 2 大枠の技術 設計 機能・非機能要件を満たせる設計になって いるか テーブル/サービス/非同期の大枠設計 共通観点でのレビュー用スキル作成 3 PBI分割 エピックを過不足なくPBIに分解できてい るか 分割とエピック/PBI 漏れチェック・SP見積もりの スキル作成 4 リスク分析 全プロセスのどこに不確実性があるか（向 き合う対象の棚卸しそのもの） 不確実性の棚卸し（テンプレ型化・後続計画に反 映・継続的に見直し） 5 プロジェク ト計画 リリース順序とリスクが整合した計画が組 めるか リリース計画・依存関係・優先度・リスク順序の 整合 立案後、継続的に見直し 6 テスト計画 適切なタイミングでテストを実施できる計 画か テスト戦略・統合/受入/リグレッション/UAT のタ イミング設計 24
25. 2. エピックとPBIへの分割、プロセスごとの設計：PBIレベルのプロセス例 PBIにおけるプロセス # プロセス 向き合う不確実性 アプローチ 7 PBI詳細化 (受入基準・技 術設計) 受入基準・技術詳細を明確化できる か 各PBIで受入基準・技術設計・単体/結合テストを詳細 化。エピックへ逆算更新 それぞれの作成支援とレビューをスキル化 8 実装 設計通りに実装できるか・モデルか ら逸脱しないか アーキテクチャ・コーディングルール定義 コーディングルールドキュメント整備・コードレビュ ースキル作成 9 テスト 受入基準を満たしている確証が得ら れるか テストコード実装・AI操作によるテスト・受入基準達 成確認 プロセスは行ったり来たり: 一直線で完成するのではなく、各段階の発見を上流にフィードバ ックする前提 テスト工程はさらに細分化可能（単体／結合／受入／UAT／リグレッション 等） 。本資料では 深掘りしない 25
26. アジェンダ 全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 26
27. 3. 開発プロセスごとのアプローチ プロセスごとにアプローチを紹介 全般 エピック 要件定義 技術設計 PBI分割 リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化 実装 テスト 27
28. 3. 開発プロセスごとのアプローチ：[全般] スキルとは何か スキルを作るのが開発プロセス改善のキモ ここから各プロセスにスキルを作っていくことをお勧めしていく その前に「スキル」とは何かを整理 スキルを作る ＝ AIに渡す 観点・テンプレ・手順 を形式知にし、AIが再現可能にすること 開発プロセスをAI化していく上で起点になるものである これは要件定義だけでなく、技術設計・PBI分割・実装…各プロセスでも同様 28
29. 3. 開発プロセスごとのアプローチ：[全般] スキルは「作成支援」と「レビュー」に分ける 作成支援とレビューは分けるとよい 作成支援スキル: アウトプット（PRD・設計書・PBI 等）を作るための観点・テンプレ レビュースキル: アウトプットをレビューするための観点 ただし同じような観点ドキュメントを共通で読み込むのは なぜ分けるのか： レビューを独立したほうがクオリティを上げやすい 「作成に必要なコンテキスト量>>レビューに必要なコンテキスト量」なため レビューだけで改善点がなくなるまで何度も実行できるため これは2026年5月時点の話で、モデルの性能が上がれば変わる可能性あり 29
30. 3. 開発プロセスごとのアプローチ：[全般] Question-First：AIに質問させて論点を洗い出す ドキュメントレビューはAIに質問させる形にすると効果的 大量のドキュメントを見て改善点を出すのは難しい AIに質問させる = 論点を洗い出す 重要な論点が最初に出ると、検討が進めやすい Claude Code は AskUserQuestion ツールで選択式回答 選択肢に推奨度＋理由を書かせると、 「こう思うけどどう？」と議論しやすい 勝手に聞いてくれない場合: 「現時点で検討すべき重要なことを優先して質問して」と指定 30
31. 3. 開発プロセスごとのアプローチ：[全般] トレーサビリティは品質向上のポイント IDで繋ぐと、AIに「網羅性」と「影響範囲」を機械的に検証させられる 要求 → 要件 → 仕様 → 設計 → PBI → テストなど を IDで紐付ける このトレーサビリティは品質向上のために重要 なぜ重要か： 網羅性とスコープの整合: 要件 実装の双方向で、抜け漏れ・余剰をAIが検知できる 影響範囲の把握: 要件変更時に、どの設計・PBI・テストが影響を受けるか追える 欠陥からの逆引き: 問題発生時に原要件まで遡って根本原因にたどり着ける これも要件定義だけでなく、以降の全プロセスでも共通 のポイント 31
32. 3. 開発プロセスごとのアプローチ プロセスごとにアプローチを紹介 全般 エピック 要件定義 技術設計 PBI分割 リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化 実装 テスト 32
33. 3. 開発プロセスごとのアプローチ：[1.要件定義] エピック単位でPRDを書く PRD「フォーマット定義」 「ID付与」 「レビュー観点」などをスキル化 ① フォーマット定義 × Question-First（AIに質問させて論点を洗い出す）な作成支援スキル 要求 / 要件 / 大まかな仕様 / 完了条件 のフォーマットを定義 AIが 既存ドキュメントを読み込み、不明点や意思決定すべきこと を質問しながら埋める ② ID付与によるトレーサビリティ検証 要求ID／要件ID／仕様IDなど を振り、対応を明確化 過不足や矛盾がないかを機械的に検証 ③ 毎回見るべきレビュー観点をスキルにすることで標準化 フォーマット、そこに書くべきことを満たしているか 用語の統一 多機能との横串観点　など 33
34. 3. 開発プロセスごとのアプローチ：[1.要件定義] DDD（ドメイン駆動設計） DDDのアプローチはAI時代にも役立つ DDD(ドメイン駆動設計): プロダクト開発で大きな価値を生むための手法 目的: 機能性（役に立つものを作る）× 保守性（長期間作り続けられる） DDDの2つのアプローチは、AI時代にそれぞれ活用できる： モデリング: 作るものを整理し、AIに渡す「共通言語」 になる 実装パターン: 実装の ガードレール としてAIの出力を制約する 次ページで、取り組みやすいDDDのモデリングを紹介 34
35. 3. 開発プロセスごとのアプローチ：[1.要件定義] sudoモデリング ハードルが低く効果が出しやすい4つの図 図 やること S: システム関連図 システムに関わるアクター・外部システムとの関連を明示 U: ユースケース図 ユーザーごとに「どんな操作をするか」を描く D: ドメインモデル図 概念と概念の関係を抽象的に描き、共通言語を作る O: オブジェクト図 具体例で理解を深め、モデルの矛盾・漏れを検証 これは「どんな時にもやると良い最低限の4つ」 業務フロー図／状態遷移図／シーケンス図 などは併用するとよい モデリングのポイント： 抽象と具体を行き来し、仮説を回し続ける: 具体例が出せない＝ドメイン理解が足りないサ イン 35
36. 詳細は別資料に https://speakerdeck.com/littlehands/dddxshi-yang-qu-dong-dehui-sugao-pin-zhi-kai-fa-nopurosesushe-ji 36
37. 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 モデリングだけでなく、仕様設計・技術設計など幅広く活用できる 37
38. 3. 開発プロセスごとのアプローチ：[1.要件定義] draw.io × AI で壁打ち 「具体例を出して」と聞くだけで、オブジェクト図（具体例）を生成 38
39. 3. 開発プロセスごとのアプローチ：[1.要件定義] draw.io × AI draw.ioをAIに読ませて壁打ち：1人では出ない観点を引き出す 「この図の懸念点は？」と聞くと、検討すべきポイントを提示 1人では見落としがちな観点を、AIが補完してくれる 39
40. 3. 開発プロセスごとのアプローチ 全般 エピック 要件定義 技術設計 PBI分割 リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化 実装 テスト 40
41. 3. 開発プロセスごとのアプローチ：[2.技術設計] プロジェクト段階の大枠 前提が変わるとPBIに大きく波及する箇所を早く潰す ドメインモデリング・テーブル設計・利用する外部サービス 等の大枠を設計。 意思決定によってPBIのラインナップが大きく変わりうるものはここである程度決める 41
42. 3. 開発プロセスごとのアプローチ：[2.技術設計] 二次元の図で検証する テキストだけでやりきらず、AIと一緒に「図」で検証する 技術設計はテキストだけだとレビューが辛い draw.ioなどを使って二次元の図にする： 直感的に把握できる: 依存関係・データフローが一目で分かる ちょうどいい抽象度で考えられる 図を扱うスキル化（claude-drawio-skill など）は前述のとおり、技術設計でも同じ枠組みで使 える 42
43. 3. 開発プロセスごとのアプローチ：[2.技術設計] 二次元の図で検証する（例） クラス設計の例 SDDライブラリだとテキストで出力されるが、図で確認すると精度も効率も向上x 43
44. 3. 開発プロセスごとのアプローチ 全般 エピック 要件定義 技術設計 PBI分割 リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化 実装 テスト 44
45. 3. 開発プロセスごとのアプローチ：[3.PBI分割] 分割 → 受入基準埋め → 漏れチェック エピックから PBIへの分割をAIにやらせる エピックドキュメントを起点にPBIに分割 各PBIに 受入基準・概要・関連ドキュメント など記載 ID付与して漏れチェック と 見積もり（次ページ）を実施 依存関係も定義すると、後の計画で便利 受入基準は後でPBI単位でリファインメントする前提の粒度のもの この機械的な作業はAIの得意分野 45
46. 3. 開発プロセスごとのアプローチ：[3.PBI分割] ストーリーポイントで見積もる 見積もりは「期間」ではなく「規模・複雑度・不確実性 を加味した相対値」 いわゆるストーリーポイント 基準となる PBI を決めて、他PBIを比較 フィボナッチ数列（1, 2, 3, 5, 8, 13…）を使うのが一般的 基準はSP2のものと3のものあたりを決めるのがおすすめ かかる日数・時間は条件によってばらつくが、 ストーリーポイントは基準を定めればある程度揃うので、AIが算出しやすい 分割や見積もり時に不明な点はAIに随時質問させる これはもともとの見積もりの効果の一つ 46
47. 3. 開発プロセスごとのアプローチ 全般 エピック 要件定義 技術設計 PBI分割 リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化 実装 テスト 47
48. 3. 開発プロセスごとのアプローチ：[4.リスク分析] テンプレートとスキルで型化、結果を計画に反映 不確実性を網羅・型化し、後続のプロジェクト計画に反映する 「リスクを分析して」という指示だけでもある程度やってくれる 普段やっていなくても、AIに考えさせるだけでも意外と発見がある 観点を固定化したかったらスキル化 結果を後続のプロジェクト計画に反映: 高リスク項目 → 早期検証を計画 中リスク項目 → モニタリング項目として計画に組み込み 継続的に状況アップデート 48
49. 3. 開発プロセスごとのアプローチ：[5.プロジェクト計画] 計画の叩きをAIに作らせる 地道で大事な作業の 叩き をAIに、人間は 最終判断 に集中 地味だけど大事な作業の叩きをAIに作らせる 依存関係を考慮した計画作り リスクを考慮した順序検討（プロトタイピング・先行実装・PoCをどこに置くか） 人間が 向き合いにくい現実 とも向き合わせてくれる データが溜まってくると： 「過去プロジェクトの傾向では、このスケジュールは無理そう」 と指摘させられる 最後の確認とスケジュールの意思決定は人間。 でも叩きと現実の指摘があるだけで、判断のスピードと質が一段上がる 49
50. 3. 開発プロセスごとのアプローチ：[6.テスト計画] テストレベル × 種別 × 実施手段で計画する テストレベル・テスト種別 を含めて広く計画する AIに任せたままだとユニットテストに閉じがち 以下のような観点で幅広く計画する テストレベル: 単体／結合／システム／受入／UAT テスト種別: 機能／非機能（性能・セキュリティ等）／回帰／探索的 時期: PBI受入は実装直後／統合は機能群完成時／UAT はリリース前 QAの方の知見スキル化すると再現性が高まる 50
51. 3. 開発プロセスごとのアプローチ 全般 エピック 要件定義 技術設計 PBI分割 リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化 実装 テスト 51
52. 3. 開発プロセスごとのアプローチ：[7.PBI詳細化] 要件・設計・タスクを詳細化 各PBIで受入基準・技術設計・テスト設計を詳細化 仕様駆動ツール（Spec Kit / Kiro 等）でドキュメントを作る感覚 エピックドキュメント／他のPBIとの整合性 をAIにチェックさせる この段階で発見があればエピックドキュメントを逆算更新 不明点は Question-First でAIに質問させながら詰める（前述） PBI単位での レビュー観点 をスキル化すると◎ 52
53. 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や実例マッピングの詳細説明は割愛 53
54. 3. 開発プロセスごとのアプローチ 全般 エピック 要件定義 技術設計 PBI分割 リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化 実装 テスト 54
55. 3. 開発プロセスごとのアプローチ：[8.実装] ruleドキュメント＋クオリティゲート ガードレールで縛り、決定論的検証で品質を担保 コーディングルールの定義 がとても大切 アーキテクチャレベル：オニオン／クリーンアーキテクチャ など 各レイヤーの詳細：DDDの実装パターン・実装原則 など CLAUDE.md / .claude/rules/ などコーディングエージェントの仕組みを活用 AIレビューと静的解析を使い分ける： 静的解析でカバーできる範囲は決定論的にチェック AI判断は静的解析で届かない領域に絞る（決定論のほうが確実性が高い） 55
56. 3. 開発プロセスごとのアプローチ 全般 エピック 要件定義 技術設計 PBI分割 リスク分析 / プロジェクト計画 / テスト計画 PBI PBI詳細化 実装 テスト 56
57. 3. 開発プロセスごとのアプローチ：[9.テスト] テスト実行手段の3種類 自動テスト × 手動テスト × AIによるテスト 実行手段 特徴 使いどころ ① スクリプトによる自動テスト 決定論的・繰り返し 単体・結合・主要パス ② 手動テスト 人間の判断が必要 UX・探索的テスト ③ AIによる自動テスト 自然言語で指示・画面操作 受入テスト 何も指示しないと ① のみになりがち 適切に使い分けるのが重要 ③ は新しい手段として意識的に扱う 画面確認までAIに任せられると、人間は最終確認だけに集中できる AIにテストレポート（キャプチャ・動画付き）を書かせる → 人間がレビューしやすい形に 57
58. 3. 開発プロセスごとのアプローチ：次のセクションへの橋渡し 観点は分かった。でも、全プロセス一気にはできない ここまでで、プロセスごとのアプローチを見てきた でも、全プロセスを一気にスキル化するのは現実的じゃない これも結局は 「検査と適応のサイクル」を、どのプロセスから設計し始めるか の選択 次のセクションで 「どのように着手していくか」 を紹介する 58
59. アジェンダ 全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 59
60. 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/) 　　をベースにカスタマイズ 60
61. 4. AI活用フェーズの可視化と目標設定：マトリクスの活用フロー（3つの手順） 現状記入 → 課題感記入 → 目標と取り組み記入 以下の手順で現状を認識して、取り組む課題を設定する 改善余地がないところをAI化しても意味がないので、優先して改善したいところは課題ベース で定義する 手順 やること ① 現状の活用フェーズ（1〜4） をプロセスごとに記入（自チームの可視化） ② 現状の各プロセスの課題感が強いところ を記入（優先度を明確化） ③ 一定期間（四半期/半年）における、プロセスごとの目標フェーズと具体的な取り組み を記入 61
62. 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 テスト戦略テンプレ・タイミン グ設計のスキル化 マトリクスを埋める行為そのものが 「現状の検査 → 次の打ち手の適応」 のサイクル 62
63. アジェンダ 全体の流れ 1. 開発の各プロセスで検査と適応のサイクルを設計 2. エピックとPBIへの分割、プロセスごとの設計 3. 開発プロセスごとのアプローチ 4. AI活用フェーズの可視化と目標設定 5. まとめ 63
64. 5. まとめ：今日のまとめ 不確実性と向き合い、プロセスごとに検査と適応のサイクルを設計する 「不確実性と向き合い、検査と適応のサイクルを回す」はもともと アジャイルの基礎 AIの力でこのサイクルを高速に回せるようになった AIに実装の詳細を任せ、人間は価値や不確実性と向き合う仕事に集中できるのが理想形！ よいプロダクト開発をしていきましょう 64
65. 5. まとめ：Q&A / 参考リンク ご質問があればお気軽にどうぞ！ X（匿名質問OK）: https://x.com/little_hand_s 過去の勉強会動画（sudoモデリング詳細）: https://www.youtube.com/watch? v=HgtCKlOzRiQ 書籍: 「ドメイン駆動設計 モデリング/実装ガイド」: https://little- hands.booth.pm/items/1835632 「ドメイン駆動設計 サンプルコード&FAQ」: https://little- hands.booth.pm/items/3363104 一緒にモデリングする勉強会: https://little-hand-s.notion.site/DDD- 22429f7110574439a4c3e126c20fa9a2 65
66. ご清聴ありがとうございました 廊下でもお話ししましょう 松岡 幸一郎 X(Twitter): @little_hand_s 66