Slide 1

Slide 1 text

©KAKEHASHI inc. プロダクトを育てるように 生成AIによる開発プロセスを育てよう 2026年04月09日 もっち(松本 明紘) 【AI駆動開発】AI自走環境構築・運用スペシャル #1

Slide 2

Slide 2 text

株式会社 カケハシ(2023年2月〜現在) ● 新規プロダクト、AI在庫管理 ● バックエンドに軸足を置くテックリード もっち(X: @mottyzzz) 松本 明紘 自己紹介

Slide 3

Slide 3 text

生成AIにより開発スピードは劇的に変化した ● 生成AIによるコード生成が日常になった ● 以前なら数日かかっていたことが、数時間で形になる コードレビューが 速度的にも心理的にもボトルネック

Slide 4

Slide 4 text

コードレビューによって担保してきたもの 4 ● 定性的なコードの”良さ” ● 知識共有によるメンタルモデルの獲得・理解 コードレビューによって コードをチームのものにしてきた

Slide 5

Slide 5 text

アプローチ 5 ● 生成AIの自律性をより高めて、 価値提供のリードタイムを短くすること ● 生成AIによるコードレビュー品質を これまで以上に高めること ● 知識共有、メンタルモデル醸成の場を コードレビュー以外にプロセスとして設計すること

Slide 6

Slide 6 text

AI-人間の関係モデル 6 https://x.com/takuro_n/status/1917762108672074046?s=20 ここを目標として進める

Slide 7

Slide 7 text

進め方 7 ● ツールも考え方もまだまだ変化が多い ○ 実際、本日紹介する取り組みも1か月後には変わってる可能性 ● HOTLを目指すにしても 最初から開発の全てがそうなることはない ● 変化に適応するために、 チームとして開発プロセスを明確に育てていく ● 個人情報を扱うような本番環境の操作などは 本取り組みのスコープ外

Slide 8

Slide 8 text

プロダクトを育てるように 生成AIによる開発プロセスを育てよう

Slide 9

Slide 9 text

大事にしてきたもの 9 ● プロダクト ● チーム データ分析やふりかえりによって、 フィードバックループを回すことで進化させてきた

Slide 10

Slide 10 text

大事にしてきたもの 10 ● プロダクト ● チーム ● 生成AIによる開発プロセス プロダクトやチームの進化の中に暗黙的に入ってい た開発プロセスのカイゼンを、明確に育てる対象と することで適応を進める

Slide 11

Slide 11 text

生成AIによる開発の流れの中にも下記を適用する 11 ● 検証可能な小さなユーザーストーリー、そしてタスク ○ 生成AI自身が自身の結果を検証しながら進める ○ 人間が生成AIの結果を検証可能な状態にしておく ● ふりかえりによるフィードバックループ

Slide 12

Slide 12 text

前提 12 ● スクラム ● ユーザーストーリーを中心とした開発 ○ 直接利用者に影響のない開発だとしても、 開発チームをユーザーとして実施 ● 本日紹介する取り組みで活用しているツール ○ Jira ○ Claude Code

Slide 13

Slide 13 text

ユーザーストーリー、タスクの構造 13 プロダクト ロードマップ フェーズ (エピック) ユーザー ストーリー 設計 タスク フェーズ (エピック) ユーザー ストーリー 実装 タスク ユーザー ストーリー ユーザー ストーリー 設計 タスク 実装 タスク タスク タスク タスク タスク ・・・ ・・・ ・・・ PR PR PR PR PR PR PR PR

Slide 14

Slide 14 text

ユーザーストーリー、タスクの構造 14 プロダクト ロードマップ フェーズ (エピック) ユーザー ストーリー 設計 タスク フェーズ (エピック) ユーザー ストーリー 実装 タスク ユーザー ストーリー ユーザー ストーリー 設計 タスク 実装 タスク タスク タスク タスク タスク ・・・ ・・・ ・・・ PR PR PR PR PR PR PR PR

Slide 15

Slide 15 text

小さいユーザーストーリー、タスク 15 ● リファインメントをモブで実施。 その中で、概要設計、タスク分割まで行う ● ユーザーストーリーやタスクを分割する過程で、 開発チーム内のメンタルモデルを作る ● 小さくすることで、必要な理解の負担を低減、 タスクの種類ごとのアプローチの選択をしやすくする

Slide 16

Slide 16 text

開発の進めかた 16 プロダクト ロードマップ フェーズ (エピック) ユーザー ストーリー 設計 タスク フェーズ (エピック) ユーザー ストーリー 実装 タスク ユーザー ストーリー ユーザー ストーリー 設計 タスク 実装 タスク タスク タスク タスク タスク ・・・ ・・・ ・・・ PR PR PR PR PR PR PR PR

Slide 17

Slide 17 text

実行計画の作成とタスク分割 17 ● 実行計画の作成 ○ Jiraのチケットに結果とQ&A履歴を記録 ○ 完了の定義と検証方法も合わせて記録 ● タスク分割 ○ PRが小さくなるようにタスクを分割する ○ 特に、設計(と呼んでいるもの)は、 生成AIが実行はほぼ行うが、人間による意思決定を入れるもの ■ OpenAPIスキーマ、DBスキーマの変更

Slide 18

Slide 18 text

実行計画 タスク 記録、検知、カイゼンのフィードバックループ 実行計画スキル (execution-plan) 実装スキル (implement) 小さな ユーザース トーリー (Jira) 実行計画 タスク (Jira) コード セルフレビュー スキル (implement、 refine-loop) ガイドライン 過去のプラ ン結果 ガイドライン レビュー ガイドライン 保存した 実行計画 Lint、単体テ スト、結合テ スト レビュー指摘 とその対応 方法 チームレビュー マージ (デプロイ) Pull Request レビュー指摘 とその対応 方法 完成 レビュー ガイドライン ヒューマン レビュー ポイント ガイドライン ふりかえり スキル (task-retrospective) 実行計画時 の不足情報

Slide 19

Slide 19 text

実行計画 タスク 現時点での人間の介入度合い 実行計画スキル (execution-plan) 実装スキル (implement) 小さな ユーザース トーリー (Jira) 実行計画 タスク (Jira) コード セルフレビュー スキル (implement、 refine-loop) ガイドライン 過去のプラ ン結果 ガイドライン レビュー ガイドライン 保存した 実行計画 Lint、単体テ スト、結合テ スト レビュー指摘 とその対応 方法 チームレビュー マージ (デプロイ) Pull Request レビュー指摘 とその対応 方法 完成 レビュー ガイドライン ヒューマン レビュー ポイント ガイドライン ふりかえり スキル (task-retrospective) 実行計画時 の不足情報 現時点: Q&Aに答える、結果の確認・修正 目標: 同じ(精度を上げて判断の頻度を下げ る) 現時点: ほぼ何もしない 目標: ほぼ何もしない 現時点: 人が最終決定を行う (レビュー効率自体は上がっている) 目標: 人がレビューすべきときだけ エスカレーション(その精度を上げる) 現時点: 人がやる 目標: 同じ 現時点: 人がカイゼンの起 票の意思決定 目標: 自動的にカイゼン も進む

Slide 20

Slide 20 text

それらを支えるスキル 20 スキル 説明 アウトプット refinement 大きめの開発スコープ定義から、ユーザーストーリーやタスク分 割を支援 Jiraのユーザーストーリー候補、タスク候補 execution-plan ユーザーストーリーから実行計画を立てて、小さなPRになるよ うにサブタスク分割 Jiraのユーザーストーリーに追記 ● 実行計画 ● 検証/テスト計画 ● 計画時のQ&A結果 implement 実装計画をもとに実装を進める。 人間がレビューすべきかをガイドラインに基づき判断する(実験 中) PR Jiraのチケットに計画時に不足していた情報を記録 refine-loop セルフレビュー、改善を複数回繰り返す (変更後の)PR code-review guideline-review コードのレビュー、ガイドラインに沿っているかのレビュー コードレビュー結果 review-respond レビューに対する対応を行う (変更後の)PR、レビュー指摘への返信 task-retrospective 実行計画、実装時の記録、レビュー結果から、ふりかえりを行い、 ガイドラインへの追加やLintの追加、不足していたテストの追加 などを洗い出しカイゼンの提案を行いチケットにする カイゼンのJiraチケット check-task PR、Jiraのチケットなどから次に何をすべきかの優先度を判断 してNext Actionを提案(HOTLへの準備) Next Action

Slide 21

Slide 21 text

ふりかえりによるフィードバックの例 21 ● 基本的には、作り込みの品質を上げるようにフィードバックさせている ● 計画時の検査・テスト観点の洗い出しの精度向上 ○ 境界条件を入れる観点自体はあったが、 現状の実装やQ&Aを通して境界条件を明確化するプロセスをスキルに追加 ● 運用後を見据えたオブザーバビリティの向上 ○ 計画時からログをどう出すかも洗い出せるようにスキルの追加 ● ガイドラインからルールへ ○ OpenAPIスキーマに記載しているAPI仕様の書くべき項目を ガイドラインから、カスタムLintにして厳格化

Slide 22

Slide 22 text

どれだけフィードバックループを回せるようにしたとしても 22 ● 生成AIは隣のコードを真似するため、”悪い”状態のも のがあると、それが指数関数的に増えていく ● 現状のコードが”良い”状態になっているのが前提

Slide 23

Slide 23 text

ガイドライン、ルール、その他の仕組み 23 ● ガイドライン ○ DBの設計方針 ○ APIの設計方針 ○ 共通ライブラリ化の方針 ○ エラーハンドリング ○ ログ出力 ○ レイヤー設計、モジュラーモノリスの分割基準 ○ リクエストコンテキスト設計 ○ ヒューマンレビューポイント ○ テスト方針 ○ GitHub Actionsの構造化設計 ○ ユビキタス言語 ● Lint ○ これまでよりも厳し目のルール設定 ○ 参照関係のチェック ○ ユビキタス言語チェック(チャレンジ中) ● 単体テスト、結合テスト ○ レイヤーごとにテストカバレッジ(C1)の指標化 ● スキーマ駆動をベースにした SDD ○ OpenAPIスキーマ+API仕様でコード生成 ● APIテスト ○ Gharkin記法で仕様の理解容易性向上 ● レビューガイドラインの観点 ○ ガイドラインを守っているか ○ テスト品質 ○ トランザクション、ロック ○ 境界条件 ○ OpenAPI仕様と実装の一致 ○ パフォーマンス ○ コードのわかりやすさ、コード品質 ○ SQL最適化 ○ TypeScript品質 ○ セキュリティ

Slide 24

Slide 24 text

すべての前提となっている徹底的な構造化 24 ● モジュラーモノリス×クリーンアーキテクチャ ● テスト容易性の向上 ● DBのテーブルごとにオーナーとなるモジュールを決め て、それ以外からの直接アクセスを禁止して変更の影 響範囲を最小化 ● モジュールごと、レイヤーごとのガイドライン、ルー ルを整備しやすくする

Slide 25

Slide 25 text

まとめ 25 ● フィードバックループを設計するによって 生成AIの開発プロセスを育てていく ● 生成AI自身にふりかえりに必要な情報の記録、 ふりかえりの実施、カイゼン提案までやってもらう ● 粒度を小さくすること、区切りを用意することで、 HIC→HITL→HOTLへの変化をしやすくする

Slide 26

Slide 26 text

ありがとうございました カケハシの技術に関連する情報を 発信しています! 𝕏 @kakehashi_dev 是非フォローもお願いします! 26

Slide 27

Slide 27 text

©KAKEHASHI inc. プロダクトを育てるように 生成AIによる開発プロセスを育てよう 2026年04月09日 もっち(松本 明紘) 【AI駆動開発】AI自走環境構築・運用スペシャル #1