---
title: Human "N" the Loop の外側　設計と実践と、その思想
tags: 
author: [蜜葉](https://docswell.com/user/mitsuba_yu)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/9E2RNYY5JR.jpg?width=480
description: 昨今、AI に開発を任せる手法が次々と生まれました。クライアントワークが中心となる KAG では、人が in にいるか、on にいるか、out にいるかは、案件の性質やチームによって変わります。ただ、どれを選んでも、AI がより良く、より速くしたのは開発のループです。開発が速くなっても、顧客のビジネスや業務を理解していなければ、価値のあるものは作れません。これまでの技術力はベースとして求められながらも、価値を実現するためには、業務の理解度や解像度をどう上げるかが問われるようになっています。  仕事の質は解像度に依存する。自分たちの仕事を解像度高く見られなければ、相手の仕事も解像度高くは見られない。そう考えて、まず自分たちが最も理解しているはずの AI 駆動開発のフローから、解像度を上げることを始めました。1チームの8ヶ月を蒸留して KAG Spec-Driven Scrum を作り、その過程で生まれたふりかえりの型を全社21チームに広げています。  今回はそんな開発のループの外側にあるであろう、チームを越えて全社で互いに解像度を上げていく組織としての取り組みの設計と、そこから得られた実践知を交えて、KAG の現在地としてお話しします。
published: November 04, 26
canonical: https://docswell.com/s/mitsuba_yu/K3JVNL-2026-11-04-193127
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/9E2RNYY5JR.jpg)

2026.11.04 / #LoopEngineering
ALGOMATIC × kubell × KDDI アジャイル開発センター 合同イベント
AI駆動開発のループに人はどう関わるか ― 開発フローに落とし込んだ3社の現在地 ―
Human "N" the Loop の外側
設計と実践と、その思想
- 1チームの8ヶ月を蒸留した KAG Spec-Driven Scrum の裏側と、ふりかえりの型を21チームに広げて見えた KAG の現在地 -
YUKI IZUMOTO / KDDIアジャイル開発センター


# Page. 2

![Page Image](https://bcdn.docswell.com/page/D7YDPGG67M.jpg)

Profile
• Yuki Izumoto a.k.a. 蜜葉
• @mitsuba_yu
• Microsoft MVP for Developer Technologies (16th)
• Designer / Developer / Photographer
• スクラムマスター / サブマネージャー / CTO室 at KAG <- here !!
– デザイン事務所、モバイルアプリ開発会社を経て、新卒で1年だけ ISP へ
– 合同会社silkyfeel を設立し、デザインから実装・納品まで一貫して担う
– 内製化支援と、社内外の組織文化づくりに比重を置きたくて、2024年より KAG へ
• 洋酒と、カメラと、ものづくりが好き
• https://c-mitsuba.hatenablog.com
02
/
51


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VEN65G81E8.jpg)

What’s KAG?
約10年間“アジャイル開発“に徹底的にこだわり続けてきた
DX専業のエンジニア集団
re-INNOVATE YOUR BUSINESS “Be Agile, Update Culture”
KDDI Agile Development Center Corporation
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/Y79LYWKYJ3.jpg)

KDDIにおけるアジャイル開発の歩み
2013
法人向けクラウドサービス
KDDI Business IDにて
初のアジャイル開発導入
2016
2018
2020
職種比率
アジャイル開発センター発足
開発案件拡大
（様々な部門でAgile開始）
オフショア / ニアショア
共創ビジネス創出へDX
エンジニア…72%
デザイナ… 10%
その他…18%
300人+
5人
2015
領域拡大（Personal）
auでんき
au HOME（IoT）
2017
顧客視点強化
UI/UX取り組み強化・加速
2019
KDDI DIGITAL GATE
Scrum Inc. Japan設立
2022
KDDIアジャイル開発センター
株式会社設立
72%
KDDI Agile Development Center Corporation
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/G78X6NRKED.jpg)

全国14の地域+海外に拠点を展開中
札幌オフィス
国内どこからでも働けます！
SAPPORO
OFFICE
秋田オフィス
AKITA OFFICE
山口オフィス
YAMAGUCHI
福岡オフィス OFFICE
舞鶴オフィス
金沢オフィス
MAIZURU
OFFICE
KANAZAWA
OFFICE
FUKUOKA
OFFICE
仙台オフィス
那覇オフィス
SENDAI
OFFICE
NAHA OFFICE
Vietlink
ホーチミン本社
東京本社
HO CHI MINH
MAIN OFFICE
TOKYO MAIN
OFFICE
広島オフィス
高松オフィス
大阪オフィス
HIROSHIMA
OFFICE
TAKAMATSU
OFFICE
OSAKA
OFFICE
名古屋オフィス 三島オフィス
NAGOYA OFFICE
MISHIMA
OFFICE


# Page. 6

![Page Image](https://bcdn.docswell.com/page/L7L89PKPJR.jpg)

スクラム開発の体制
プロダクトオーナー、スクラムマスター、開発者、PoLのワンチーム
ステークホルダー（クライアント）
スクラムチーム（KAG & クライアント）
ステークホルダーの
スクラムマスター（SM）
要求ヒアリング
スクラムプロセスの実践を促進し、
チームパフォーマンスを向上させ、
ゴールを達成させます。
社内関係者
プロダクトオーナー
事業責任者、営業部門
ユーザーからの
（PO）
フィードバック
プロダクトの価値の最大化
開発者（エンジニア、デザイナー）
スプリントゴールに向け、
プロダクトを開発（HOW）し
品質、計画の適応に責任を持ちます。
（WHAT/WHY）に対し
全責任を負い、バックログの
優先順位付けを行います。
社外関係者
PoL
POを広く支援しプロジェクトの
円滑な進行をサポートします
顧客、パートナー
KDDI Agile Development Center Corporation
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4EM6Z4227W.jpg)

コミュニティ活動・情報発信
社内外からの実践知で広い視野をもったメンバーが多数在籍しています。
イベント登壇・コミュニティ運営
技術ブログの発信
KAGメンバーが執筆に関わっている書籍
KDDI Agile Development Center Corporation
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/PERP6WM579.jpg)

アジャイルマインド（行動指針）
アジャイル開発センター憲章
機敏であること [AGILITY] が私たちの最大の価値であり、存在意義そのもので
す。
AGILITY
コアバリュー
BUSINESS
カルチャー
BEHAVIOR
課題は技術で解決する
スピードを優先し組織の壁を超える
アウトプットよりアウトカム
技術を磨いてチームに貢献する
小さく早く失敗する
データに基づき改善する
とことん自動化する
知識を共有し成果を発信する
お客様の体験価値を最大化する
行動指針
TECHNOLOGY
楽しくやる
KDDI Agile Development Center Corporation
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/P7X3MPVXEX.jpg)

KAG の強み
デザイン
×
スクラム
×
AI 駆動
×
人間力
「アジャイル開発、サービスデザイン、AI駆動開発、
そしてお客様に寄り添う『人間力』。
それらを掛け合わせて、課題の入り口から一緒に走ります」
副社長 COO 小林 毅（KAG 公式 note より）
KAG 公式 note（2026.08.07）
KDDI Agile Development Center Corporation
09
/
51


# Page. 10

![Page Image](https://bcdn.docswell.com/page/37KYGDQ9ED.jpg)

AGENDA
/ きょう話すこと
01
プロセスの振り返りを型にして、全社に広げる
02
分析して、蒸留する（KAG Spec-Driven Scrum と TIPS）
03
ふりかえりの背景と狙い
04
ネクストアクション：人と同じように、AI にもチームを越えたふりかえりを
05
まとめ：開発のループの外側で、人にフォーカスしたい
きょうの主張
Human [in | on | out of] the Loop は、開発の中の話
その外側の取り組みを組織で設計し、チームの経験を実践知にして返す話をします
10
/
51


# Page. 11

![Page Image](https://bcdn.docswell.com/page/LJ39NRP9J5.jpg)

LEARNING OUTCOMES
/ きょうのお持ち帰り
イベント概要
「チームの特性に合う手法を開発フローに組み込み、
地上戦略として持続的な最適化を実現すること」
多種多様なチームの実践知を、組織として扱い、
個に還元していくプラクティスの1つと、その狙いを知る
11
/
51


# Page. 12

![Page Image](https://bcdn.docswell.com/page/8JDGWYL8JG.jpg)

01
CHAPTER 01 / 05
RETRO TO KIT
プロセスの振り返りを
型にして、全社に広げる
01
プロセスの振り返りを型にして、全社に広げる
02
分析して、蒸留する
（KAG Spec-Driven Scrum と TIPS）
03
ふりかえりの背景と狙い
04
ネクストアクション：人と同じように、
AI にもチームを越えたふりかえりを
05
まとめ：開発のループの外側で、
人にフォーカスしたい
自分たちの開発の振り返りを12の観点にして、21チームへ


# Page. 13

![Page Image](https://bcdn.docswell.com/page/VEP3962W78.jpg)

W H AT W E D I D
/ やったこと
1章：ふりかえりテンプレートを作って、展開する
2章：分析して、蒸留する
設計
案件をベースに設計した
ふりかえりワークショップ
ワークショップを
全社に展開する
結果を
横断分析する
蒸留・昇華する
行動
自分たちのチームの
プロセス振り返りの知見から、
12の観点のテンプレートにした
CTO室として、21チームに
21チームの付箋を
書いてもらった。付箋 1,595枚
横断分析した
還元する実践知
型は自チームの8ヶ月から、
TIPS は21チームの付箋から
作った
初学者への型
AI駆動開発 TIPS
KAG Spec-Driven Scrum
困りごとや改善の工夫を、
1枚に1つ。102枚
スクラムチームで
仕様駆動開発を回す型
13
/
51


# Page. 14

![Page Image](https://bcdn.docswell.com/page/27V4M3D9EQ.jpg)

DEV FLOW
/ あるチームの開発の流れ
全体で8ヶ月、うち立ち上げに1ヶ月、実装が7ヶ月
PBI を /specify に渡して始める
質問は grill-me で上限なしにやり切る
1 PBI ＝ 1 spec ＝ 1 ブランチ ＝ 1 PR
最初から最後までひとつなぎにして、
後から追跡できるようにする
2ヶ月目にはかなり慣れてきて、
チームでプロセス整理を行った
しゃけ.tech #1 の資料より
14
/
51


# Page. 15

![Page Image](https://bcdn.docswell.com/page/5JG1G3Y47L.jpg)

PROCESS RETROSPECTIVE
/ あるチームの AI 駆動開発プロセスの振り返り
立ち上げ時にチームで整理した開発プロセス ＝ 合意形成
3ヶ月経ったチームで整理した開発プロセス ＝
より複雑になりつつ、個々人の工夫をチームに適応
15
/
51


# Page. 16

![Page Image](https://bcdn.docswell.com/page/47QDX5MREP.jpg)

RETRO KIT
/ 振り返りを型にする：12の観点
01
1 機能を実装するまでのプロセス
07
使っている MCP・プラグイン
02
仕様駆動に入る前のアーキテクチャ選定や準備としてやったこと
08
最終的にマージされるファイル群
03
テスト、品質面の話
09
Spec Kit 利用時に追加されるファイル群
04
気が向いた時、思い出したときに時々見直しているもの、
見直したいこと
10
開発方針サマリー（ワーキングアグリーメントみたいなもの）
05
バグ（バグチケット）修正の時は
どういうアプローチで修正している？
11
SDD でチームプレイをするときに気にしていること
06
プロセスの中で適用している Function コマンド・スキル
12
懸念、もし最初からやり直せるならこうやる、
もし次回やるならこうやる
16
/
51


# Page. 17

![Page Image](https://bcdn.docswell.com/page/KE4Z69VQJ1.jpg)

ROLLOUT
/ 全社展開：その型で、21チームにふりかえってもらった
依頼の流れ
CTO室
依頼
各部長
依頼
各チーム
21チーム
1,595枚
ふりかえりの型で書いたチーム
集まった付箋
FigJam のボード「AI駆動開発パターンを集める」に、チームごとの区画を用意した。期限は8月末
自分のチームの区画を「作成例」として先に書いた
趣旨：各チームの AI 駆動開発を可視化し、社内のノウハウを集め、チームのプロセスを見直すきっかけにする
17
/
51


# Page. 18

![Page Image](https://bcdn.docswell.com/page/L71RVK3L7G.jpg)

THE BOARD
/ その振り返りを、他のチームにも展開した
FigJam のボード「AI駆動開発パターンを集める」に、
チームごとの区画を用意した
自分のチームの区画を「作成例」として、
先に書いた
同じ観点で、各チームが自分たちの開発を書いた
見学者が質問を書ける区画も置いた
ボードの全景。区画の見出し（チーム名）は伏せている
18
/
51


# Page. 19

![Page Image](https://bcdn.docswell.com/page/G7W1LDPQJ2.jpg)

IN THEIR OWN WORDS
/ 付箋に書かれていた本音
「AIを使った分だけ速くなっているか自信がない」
「設計の穴に気づく勘が最近は全然働かない」
アンケートから機能案を作るチーム
同じチーム
「ルール化していても、Claudeが見落とすことはある。
ルール化しているからと安心しない方がいい」
「どうせ皆AI使ってそうだから頑張って目で見てます
(文章長すぎて諦めがち)」
rules を15本育てているチーム
PR を全員で承認しているチーム
「人間の品質担保がPRレビュー時に集中して
かなり面倒だった」
見学者「理解という視点で対策をしているか、
意図的に理解を捨てているか」
→「意図的に捨てている」
PO がいないリライトのチーム
コードはレビューしない前提の移行チーム
ふりかえりのふりかえり
案件のふりかえりとは別に、この型でふりかえること自体に学びがあった
19
/
51


# Page. 20

![Page Image](https://bcdn.docswell.com/page/4JZPMGK373.jpg)

02
CHAPTER 02 / 05
ANALYZE AND DISTILL
分析して、
蒸留する
01
プロセスの振り返りを型にして、全社に広げる
02
分析して、蒸留する
（KAG Spec-Driven Scrum と TIPS）
03
ふりかえりの背景と狙い
04
ネクストアクション：人と同じように、
AI にもチームを越えたふりかえりを
05
まとめ：開発のループの外側で、
人にフォーカスしたい
CTO室として結果を分析し、
TIPS と KAG Spec-Driven Scrum に昇華する


# Page. 21

![Page Image](https://bcdn.docswell.com/page/YE6MNYQZJV.jpg)

A N A LY S I S
/ 結果を分析する：横断分析
AI にどこまで任せているかで、20チームを3つの段階に分けた
AI に任せていること
A. ツール補助
人が見ているところ
6チーム
レビューや調べものなど、
いつもの作業の一部を手伝う
作るものも、決める人も、AI を使う前と同じ
レビューとテストは人が全部見る
12チーム
PBI ごとに仕様と計画を書き、
実装のほとんどを書く
仕様を承認し、PR をレビューし、
動くかを確かめる
複数の AI が役割を分けて、
いくつもの作業を続けて進める
設計とテストの中身を決め、動くかを確かめる
コードは読まない
B. PBI単位の SDD
C. エージェント編成の自走
2チーム
B の中でうまく回っているチームは、
作る前に手を打っていた
どの段階がよいかではなく、
プロダクトの状況と目的で決まっていた
受け入れの条件を、作る前にテストとして書いておく
A：若手の育成が目的／大きな古いシステムで、最後の責任を人が持つ
QA のテスト設計を最初から仕様に入れて、バグが半分に
C：仕様書がしっかりした移行／作り直しやすい試作
大きい PBI は、作る前に人が分ける
段階を上げること自体は、目的になっていない
21
/
51


# Page. 22

![Page Image](https://bcdn.docswell.com/page/GE5Z5GR974.jpg)

TWO OUTPUTS
/ 2つのアウトプット
最初の試み
21チームの共通項から型を作ろうとした → 最大公約数は、どこでも言われている一般論になった。だから、2つに分けた
1チームの8ヶ月
spec 426本
AI の質問 1,281問・バグ 53件
21チームの付箋
12の観点で書いた
1,595枚
逆算する
KAG Spec-Driven Scrum
自分たちのプロダクトから、
PBI に何が足りなかったかをたどり、
次はこう進める、という型にした
スクラムチームで仕様駆動開発を回す型
集合知にする
どのチームにも共通すること、
そのチームならではの工夫を、
困りごとから探せる形に集めた
AI駆動開発 TIPS
困りごとや改善の工夫を、1枚に1つ。102枚
型は自分たちのプロダクトから逆算し、TIPS は21チームの付箋を集合知にした
22
/
51


# Page. 23

![Page Image](https://bcdn.docswell.com/page/972RNYD5ER.jpg)

OUTPUT 1
/ アウトプット1：KAG Spec-Driven Scrum
スクラムチームで仕様駆動開発を回す型。PBI 1つごとに、spec・ブランチ・PR を1つずつ作る 1 PBI = 1 spec = 1 ブランチ = 1 PR
逆算する
1チームの8ヶ月の記録を、
バグ・AI の質問・コード・変更の
4つの入り口からさかのぼった
STARTER KIT
KAG 仕様駆動開発スターターキットとして、社内に公開している
意図：AI駆動開発の初学者でも、チームでスクラムに乗った AI駆動開発ができるように
書く
止める
道具
始める
PBI のテンプレートと記入例
受け入れ条件のひな形
constitution のひな形
3つのゲート
（着手・差し戻し・分割）
既存を変えるときの影響チェック
Claude Code のスキル5本
PR の重さを測るツールなど3本
立ち上げの手順（スプリント0）
最初に積むバックログの定型項目
段階導入（レベル1〜3）
23
/
51


# Page. 24

![Page Image](https://bcdn.docswell.com/page/DJYDPG26JM.jpg)

OUTPUT 2
/ アウトプット2：困りごとや改善の TIPS
21チームの付箋
12の観点で書いた 1,595枚
横断分析
困りごとや改善の TIPS
段階・人が判断する場所・
テスト・ルールの育て方
1枚に1つの工夫。102枚
21チームの実践を、1枚に1つの工夫として
フロントのバグはブラウザで見るまで直したと言わない
切り出した。困りごと、やったこと、
フェーズ 開発期・バグ修正
やったチームを載せ、フェーズと対象で引ける
困りごと AIが「直した」と言うが直っていない
やったこと 再現をブラウザで見るまで直したと言わない、をrulesに
スキルや rules の実物はボードにないので、
詳しく知りたいときは書いた人に聞きに行く
対象 品質
隔週でルールとスキルを掃除する
フェーズ 開発期
対象 ドキュメントと知識
困りごと rulesとスキルが増えて古くなる
やったこと 隔週のお掃除スキルで整理している
PUBLISHED INSIDE KAG
社内に、横断分析と TIPS として公開している
意図：各チームの AI駆動開発を可視化し、社内のノウハウを集め、チームがプロセスを見直すきっかけにする
21チームの一覧／比較の軸（道具・人が判断する場所・テスト・ルール・文書・計測・PO）／深掘り7本／困りごとや改善の TIPS 102枚／聞きに行く先
24
/
51


# Page. 25

![Page Image](https://bcdn.docswell.com/page/V7N65GW178.jpg)

MORE
/ 詳しくはこちら
S c r u m F e s t S e n d a i 2 0 2 6 の資料
「学びを奪うのは、AIじゃない。その賢さに頼りきることだ」
入社2年目エンジニアとスクラムマスター はじめての仕様駆動開発、そのプロセスと実践知
https://www.docswell.com/s/mitsuba_yu/K1Q4QL-2026-07-11-110020
しゃけ. t e c h # 1 の資料
8ヶ月の仕様駆動開発をリバースエンジニアリングして、Spec-Driven Scrumを定義した話
https://www.docswell.com/s/mitsuba_yu/5MQ3YN-2026-09-01-195422
n o t e（K A G C T O室）
AI駆動開発をこれから始めるスクラムチームへ。仕様駆動開発スターターキット『KAG Spec-Driven Scrum(仮)』のご紹介
https://note.com/yuki_izumoto/n/n07dc9472e709
社内向け：スターターキット、AI駆動開発パターン 横断分析、困りごとや改善の TIPS（statichtml）
25
/
51


# Page. 26

![Page Image](https://bcdn.docswell.com/page/YJ9LYWXYE3.jpg)

03
CHAPTER 03 / 05
PHILOSOPHY
ふりかえりの背景と狙い
01
プロセスの振り返りを型にして、全社に広げる
02
分析して、蒸留する
（KAG Spec-Driven Scrum と TIPS）
03
ふりかえりの背景と狙い
04
ネクストアクション：人と同じように、
AI にもチームを越えたふりかえりを
05
まとめ：開発のループの外側で、
人にフォーカスしたい
ビジネスと人を知る力を、組織で育てる


# Page. 27

![Page Image](https://bcdn.docswell.com/page/GJ8X6N2K7D.jpg)

TRUST LOOP
/ 価値を高め、信頼を積むループ
前提：KAG は内製化支援として、お客様に伴走するビジネス
作って渡すのではなく、お客様が自分で作り、育てられるようになるまで、一緒に走る
ビジネスと顧客の解像度を上げる
業務と現場を知り、何が価値になるかを言える
使ってもらい、価値を確かめる
お客様の声と使われ方を重ね、
あるべき姿を問い直す
聞く・伝える力が育ち、
お客様と一緒に決められる
領域が広げられる
解像度をもとに、課題に仮説を立てる
なぜ困っているのか、
何を変えればよいかを共に考え、提案する
身につけた技術力で、
仮説をプロダクトにする
エンジニアとしてプロダクトのあるべき姿を求め、
使われるものとして形にする
27
/
51


# Page. 28

![Page Image](https://bcdn.docswell.com/page/LJL89P2PER.jpg)

CUSTOMER
/ 解像度の大切さを知り、顧客の解像度を上げることに向き合う
成果物としてのプロダクト
見えるもの
価値を感じてもらうための道具
水面
お客様の業務はもちろん、
価値観や物事の捉え方も
ちゃんと知っていく姿勢
解像度
内製化支援としての、
人へのアプローチ
×
「どうしたいですか？」
「なにがほしいですか？」
「あるべき形ってなんですか？」
とだけ聞いて作ると、
水面の上しか見えない
自立する未来
プロダクトの面倒をみる責務は、
いつか手を離れる
プロダクトの形は、事業の変化で
いつか変わるかもしれない
でも、水面の下で一緒に
向き合った経験は、
人に残り、
次の開発に活きる
お客様を知っていく姿勢が、競争力になる
KAG の仕事は、プロダクトを形にしながら、水面の下を大きくする経験をつくること
28
/
51


# Page. 29

![Page Image](https://bcdn.docswell.com/page/47M6Z482JW.jpg)

WHY NOW
/ なぜ、いま解像度なのか
AI で、いくらでも作れる
解像度が
低いと
開発の道中の判断と、
AI への指示
何が要るかが、ぼんやりしている
解像度が
高いと
開発の道中の判断と、
AI への指示
無邪気に、
いっぱい作れてしまう
作るプロダクトが揺らぎ、
多いほど、評価が大変になる
本当に必要だった
ものを作る
何が要るかが、見えている
高めた解像度に経験を加えて実践知とし、AI を使って、求めていた結果をつくる
29
/
51


# Page. 30

![Page Image](https://bcdn.docswell.com/page/P7RP6W55J9.jpg)

T O M AT O PA S TA
/ トマトのパスタが食べたい、と言われたら
「トマトのパスタが食べたい」
フレッシュ
生のトマトをカットして、
バジル
？
濃厚
セミドライトマト、
ボロネーゼ
提供する側が
× 片方しか知らない
言われたとおり、トマトのパスタを出す
✓ 両方を知っている → 問いを立てられる
「フレッシュと濃厚、どちらの気分ですか？」と聞ける
知らないものは、選択肢として提示できず、問いも立てられない
30
/
51


# Page. 31

![Page Image](https://bcdn.docswell.com/page/PJX3MPKX7X.jpg)

BREADTH AND DEPTH
/ 解像度の、広さと深さ
「トマトのパスタが食べたい」
広さ：いろんな種類を知っている
ポモドーロ
アラビアータ
アマトリチャーナ
ボロネーゼ
プッタネスカ
トマトクリーム
フレッシュトマト
香味野菜と挽き肉を、じっくり炒める
深さ：ひとつを語れる
赤ワインとトマトで、時間をかけて煮込む
平たい麺に、ソースがよく絡む
ボロネーゼなら、ここまで伝えられる
広さで問いを立て、深さで価値詳細を説明する
31
/
51


# Page. 32

![Page Image](https://bcdn.docswell.com/page/3JKYGD597D.jpg)

LEAD
/ リードというプレイ
1
聞き出す
2
価値を説明する
本当に欲しいものは何か
それぞれの価値の、
説明責任を果たす
広さ：いろんな種類を知っている
深さ：ひとつを語れる
3
よい方を薦める
よいと思う方を、
理由をつけてサジェストする
意思と、選んだ先の未来を添える
4
一緒に決める
決めたあとも、一緒に走る
知見を持ち寄って、みんなで未来を決める
トマトのパスタなら
どんなトマトのパスタが浮かびますか？
ポモドーロは軽やか、
ボロネーゼは煮込んだ肉の旨みとコク
ボロネーゼなら重めの赤ワイン、
フレッシュトマトなら白ワインでも
開発なら
業務のどこで困っているかを聞く
○ 聞き出す前に、まず信頼関係から
作り込む案と、小さく試す案の、
それぞれの価値を話す
いまの状況なら、小さく試す方を薦める
納得して決めたから、
自分たちのプロダクト
として育てていける
× 「どうしたいですか？」とだけ聞いて作るのは、リードを手放すこと
選択肢を広げて、問いを立てて、それぞれの価値説明をして、１つを選んだ時に想定できる未来を伝えて、一緒に決める
人間力は組織ではなく一人ひとりが定義していくもので、私はこのリードの考え方を、人間力の１つと定義している
32
/
51


# Page. 33

![Page Image](https://bcdn.docswell.com/page/LE39NRK9E5.jpg)

IN REALITY
/ 実際は、もっと複雑
トマトのパスタ
人
食べる人は1人
選択肢
メニューにある
言葉
時間
トマトのパスタ
欲しいものを言える
実際の内製化支援
関わる人が多い
？
？
……
一皿で終わる
？
まだ見えていない
何に困っているかを、言葉にしきれていない
未来に走りながら、変わり続ける
でも顧客だけが知っている情報、言語化できない課題感があり、
僕たちはそのほとんどを最初は把握しきれないことが多い
33
/
51


# Page. 34

![Page Image](https://bcdn.docswell.com/page/8EDGWY38EG.jpg)

C AT C H U P
/ 追いつくまでの速さ
解像度
この差を縮めたい
お客様の課題の解像度
揃う。ここから、ワンチームで
不確定な未来を一緒に模索できる
出発点の差
当たり前だけど、
課題については、
お客様のほうが
先を行っている
組織の実践知も使う
どこから手を付ければよいか
プラクティスが、用意されている
まず、自分の知識や
経験との差分を探る
一人の経験だけ
できる人には当たり前でも、初めての人は、
どこから手を付けていいか分からない
時間
最初は、お客様のほうが先を行っている。その差を一人の経験だけで埋めようとすると、時間がかかる
組織の実践知で知見の広さと深さを補えば、早く追いつき、そのぶん早く一緒に未来を決められる
そしてそれは、お客様からの信頼につながる
34
/
51


# Page. 35

![Page Image](https://bcdn.docswell.com/page/V7P3964WJ8.jpg)

THE CLAIM
/ 業務を知る練習として、まずは自分の業務の解像度から
リードの手順
ふりかえりで
実際のワーク（12の観点のふりかえり）
1
聞き出す
自分たちの課題に気づく
12の観点で、
自分たちの開発プロセスを付箋に書き出す
2
価値を説明する
改善案それぞれの
価値を考える
一人ひとりの工夫を並べて、
チームに効くものを見極める
3
よい方を薦める
やることをチームに提案する
「もし最初からやり直すなら」
「次回やるなら」を書く
4
一緒に決める
チームで決めて、試す
チームで合意して、
開発方針サマリーとプロセスに取り込む
日々の改善やふりかえりは自分への提案と同義。だから、自分の業務がリードの練習になる
35
/
51


# Page. 36

![Page Image](https://bcdn.docswell.com/page/2JV4M3X97Q.jpg)

OUTSIDE THE LOOP
/ Human "N" the Loop の外側を設計し、実践する
設計する
経験を積む
成果にする
還元する
顧客へ
組織的な取り組みを
設計する
チームに、解像度を
上げる経験を
積んでもらう
結果を、組織の
成果として形にする
再利用可能な知見、
導入可能な知見として、
チームに返す
顧客とのビジネスの
向上につなげる
自分たちのふりかえりを、
12の観点の
テンプレートにした
21チームが自分たちの
開発をふりかえった
（付箋 1,595枚）
付箋を横断分析し、
KAG Spec-Driven Scrum と
TIPS 102枚にまとめた
社内に公開し、
全社会で紹介した
自身の価値貢献の在り方を
話せるようになる
（お客様をリードする力も、
その1つ）
Human [in | on | out of] the Loop は、あくまで AI を使った開発の話にすぎない。
KAG では、ほぼ全てのプロジェクトがスクラムをベースとしながらも、多種多様なプロジェクトが並列で稼働しており、
採用フレームワークやアーキテクチャはチームに任せているのが事実。
開発やスクラムの外側の取り組みを設計し、
チームの経験を組織の実践知へ昇華し、チームへのカイゼンとして返し、
お客様の価値につなげることこそ、AI 時代の持続的な組織最適化だと信じています。
36
/
51


# Page. 37

![Page Image](https://bcdn.docswell.com/page/5EG1G3V4JL.jpg)

04
CHAPTER 04 / 05
NEXT ACTION
人と同じように、AI にも
チームを越えたふりかえりを
01
プロセスの振り返りを型にして、全社に広げる
02
分析して、蒸留する
（KAG Spec-Driven Scrum と TIPS）
03
ふりかえりの背景と狙い
04
ネクストアクション：人と同じように、
AI にもチームを越えたふりかえりを
05
まとめ：開発のループの外側で、
人にフォーカスしたい
プロジェクトとチームの営みから見えた
ハーネスの育ち方を、組織の知見にする


# Page. 38

![Page Image](https://bcdn.docswell.com/page/4JQDX56R7P.jpg)

THE IDEA
/ 発想の元
AI の使い方や TIPS を増やすのと同時に、要るもの
そのプロダクトで、いつ、どんな設計を、どんな意図でやったか
自分たちのハーネスの育ち方を、事実と時系列でふりかえりたい
いつ、何を、なぜ変えたかは、リポジトリとコミットに残っている
まとめれば、他所のハーネスの取り組みが、他のチームの参考になる
案件固有のものか、どこのプロジェクトでも使えるものか
38
/
51


# Page. 39

![Page Image](https://bcdn.docswell.com/page/K74Z694QE1.jpg)

HARNESS MAP
/ ハーネス改善履歴マップ：ハーネスの育ち方を時系列で見る
ハーネス エージェントの決まりと道具と検査（CLAUDE.md・AGENTS.md・.claude、規約・テスト戦略、lint の設定、
hook、PR の検査、関わる ADR）
リポジトリとコミットから、
ハーネスに触れた PR を時系列に並べる
1チームの6週間で、ハーネスに触れた PR 67件
種類は機械で分け、
転機とランクは AI が理由つきでつける
自分たちのチームで進めながら、
項目とテンプレート、
プロンプトを洗練させている最中
mise run sdd:harness-map で作り直せる
39
/
51


# Page. 40

![Page Image](https://bcdn.docswell.com/page/LJ1RVK4LJG.jpg)

MAP ITEMS
/ ハーネス改善履歴マップの項目
期間 1チームの 9/7〜10/22（6週間）。main の 91 コミットのうち、ハーネスに触れた PR 67件
1つの PR が触れた分類ごとに1枚のカードを作り、週 × 分類のマスに並べる。棒の数字はカードの枚数
工程の行と、観点の行
種類
ハーネス基盤
33
転機
6
仕様・設計
22
新設
42
開発・コード
37
仕組み化
19
テスト・検査
23
更新
68
リリース・運用
14
廃止
0
品質
29
セキュリティ
9
品質とセキュリティは、同じ PR を観点でまとめ直した行
仕組み化：レビューで繰り返し出た指摘を、lint や検査に移して、
機械が先に止めるようにした PR
1つの PR が複数の分類に触れるので、カードは PR の67件より多い。
工程の5行で129枚、種類の合計は転機の6枚を足した135枚
40
/
51


# Page. 41

![Page Image](https://bcdn.docswell.com/page/GJW1LDXQE2.jpg)

I M PA C T R A N K
/ 効果のランクは、AI が理由つきでつける
ランクは、機械で数えた手がかり（参照の広さ、後から直された回数、止める力）を材料に、AI が理由つきでつける
S
チームの進め方を変え、今も毎回効いている
→
ほかのチームや次の案件に
持っていく候補にする
5件
A
特定の誤りを機械で止める、
または毎日使う道具
→
毎日使われているので、
そのまま育てる
13件
B
決まりや道具を置いたが、
効く範囲が狭いか、守るかは人次第
→
機械で止める形にできないかを
見直す（仕組み化の候補）
22件
C
製品の変更に伴う文書の追記など、
ハーネスとしての効果は小さい
→
ハーネスの成果としては
数えすぎない
27件
いまは AI がつけたランクのまま。
これからは、ふりかえりで人が確かめて、仕組み化するものを決める
41
/
51


# Page. 42

![Page Image](https://bcdn.docswell.com/page/4EZPMG63J3.jpg)

TURNING POINTS
/ 流れが変わった6つの PR
09-09
09-17
09-18
09-24
09-28
10-15
S
S
A
S
S
B
リポジトリの土台と、
ADR・mise・hook の
決まりを置く
エージェント共通の
規範は docs/ を
正本にする
superpowers を
入れる
仕様駆動スクラム
（規範・skill・
計器）を始める
レビューで繰り返す
指摘を lint と
型検査に移す
着手ゲートのタグを
Ready にする
時系列で見ると、流れが変わった所が分かる
初めのころに S と A が多いのは、よいスタートを切れていた、と言えるかもしれない
42
/
51


# Page. 43

![Page Image](https://bcdn.docswell.com/page/Y76MNY2ZEV.jpg)

W H AT W E M AY S E E
/ マップで見えてきそうなこと
自分たちのふりかえりで
社内展開すれば
立ち上げで、何を最初に置くとよいか
「この頃に、
開発が安定しだした」
チームごとに最初の4週の S と A を並べ、スターターキットのスプリント0に返す
どんな指摘が、仕組み化されやすいか
同じ指摘を複数のチームが lint にしていれば、社内共通のルールにできる
段階によって、どの工程のハーネスが厚いか
「これまでにない、
新しいトピックが生まれた」
たとえば、自走のチームほどテスト・検査が厚い、など
ハーネスが太りすぎていないか
捨てていない決まりや、後から何度も直されている決まりが見えそう
点線の箱はマップを見て言えそうなこと。まだ1チームの6週間なので、分かりそうだ、という段階
自分たちのふりかえりで育ち方が見え、社内展開すれば、どこでも使える工夫が見える
43
/
51


# Page. 44

![Page Image](https://bcdn.docswell.com/page/G75Z5G29J4.jpg)

ROADMAP
/ これからの進め方
設計する
項目とテンプレート、
生成プロンプトを作る
いまここ（自チーム）
経験を積む
各チームが
自分たちのマップで
ふりかえる
いまここ（自チーム）
他チームへの展開はまだ
成果にする
還元する
顧客へ
まとめて
横断分析する
各チームの AI 自身が
TIPS を探して、
適用するための、
社内データソース
として公開する
顧客とのビジネスの
向上につなげる
これから
これから
行ったり来たりしながら、洗練させている最中
自分たちのチームで進めながら、項目とテンプレート、プロンプトを洗練させている最中。次は他のチームへの展開
44
/
51


# Page. 45

![Page Image](https://bcdn.docswell.com/page/9J2RNY457R.jpg)

05
CHAPTER 05 / 05
WRAP-UP
開発のループの外側で、
人にフォーカスしたい
01
プロセスの振り返りを型にして、全社に広げる
02
分析して、蒸留する
（KAG Spec-Driven Scrum と TIPS）
03
ふりかえりの背景と狙い
04
ネクストアクション：人と同じように、
AI にもチームを越えたふりかえりを
05
まとめ：開発のループの外側で、
人にフォーカスしたい
お持ち帰りを確かめ、取り組みをふりかえって、思想を伝える


# Page. 46

![Page Image](https://bcdn.docswell.com/page/DEYDPGM6EM.jpg)

LEARNING OUTCOMES
/ お持ち帰りの確認
多種多様なチームの実践知を、組織として扱い、
個に還元していくプラクティスの1つと、その狙いを知る
この話とつながる考え方
Community of Practice
InnerSource
チームの枠をこえて、実践を持ち寄って学び合う場
社内でも、成果物を共有して使い、育て合う
→ 21チームが同じ型でふりかえり、ボードで見せ合った
→ スターターキットや TIPS を社内に公開し、書いた人に聞きに行ける
パタン・ランゲージ
SECI モデル
イネーブリングチーム
ダブルループ学習
正統的周辺参加
状況・問題・解決に
暗黙知を組織の知にし、
ほかのチームがやり方を
やり方だけでなく、
初めての人は、周辺から
名前を付けて使う
また個人に戻す
身につけるのを助ける
前提を問い直す
参加して学ぶ
→ 困りごとや改善の TIPS
→ ふりかえりを社内で
→ CTO室の立ち位置
→ あるべき姿を問い直す
→ プラクティスを
まとめて、チームに返す
用意しておく
どの考え方も、まだふわっとしか理解できていなくて、まだまだ勉強中です
46
/
51


# Page. 47

![Page Image](https://bcdn.docswell.com/page/VJN65G31J8.jpg)

WHERE WE ARE
/ やったこと、わかったこと、つぎにやること
Y やったこと
12の観点の振り返りテンプレートで、
21チームがふりかえった（付箋 1,595枚）
W わかったこと
21チームの共通項からは
当たり前のことしか出てこなかった。
だから自分たちの1チームに絞り、
より深くふりかえって、型に昇華した
横断分析（第9版）と、
困りごとや改善の TIPS 102枚
「この型でふりかえること自体に
KAG Spec-Driven Scrum（v6.3）と
TIPS を社内に公開し、
TIPS は全社会で紹介した
T つぎにやること
いま、ハーネス改善履歴マップを
自分たちのチームで使いながら、
項目とテンプレート、生成プロンプトを
洗練させている
ハーネス改善履歴マップを
他のチームに展開する
学びがあった」と言ってもらえた。
ふりかえりを設計した側としては、
狙いどおりだった
各チーム分を横断分析して、
AI が改善に使う TIPS にする
ふりかえりを回すたびに、型と TIPS を更新し、メンバーの視座と業務の解像度を上げていく
47
/
51


# Page. 48

![Page Image](https://bcdn.docswell.com/page/YE9LYW9Y73.jpg)

OUTSIDE THE LOOP
/ Human "N" the Loop の外側を設計し、実践する
設計する
経験を積む
成果にする
還元する
顧客へ
組織的な取り組みを
設計する
チームに、解像度を
上げる経験を
積んでもらう
結果を、組織の
成果として形にする
再利用可能な知見、
導入可能な知見として、
チームに返す
顧客とのビジネスの
向上につなげる
自分たちのふりかえりを、
21チームが自分たちの
付箋を横断分析し、
12の観点の
開発をふりかえった
KAG Spec-Driven Scrum と
テンプレートにした
（付箋 1,595枚）
TIPS 102枚にまとめた
自身の価値貢献の在り方を
社内に公開し、
話せるようになる
全社会で紹介した
（お客様をリードする力も、
その1つ）
開発はチームを信頼して任せ、その外側はCTO室で設計し、実践している
48
/
51


# Page. 49

![Page Image](https://bcdn.docswell.com/page/GE8X6N9KJD.jpg)

PHILOSOPHY
AI で、いくらでも作れるようになったからこそ、
どこで、なにを作るかより、
だれと働くか。
だれとだったら、成し遂げられるか。
そのほうが大事だと、私は思っています。
言い換えれば、多くの作業が AI に代替される以上、
人と働く価値をシビアに見られる時代だとも思っています。
49
/
51


# Page. 50

![Page Image](https://bcdn.docswell.com/page/LEL89PWP7R.jpg)

PHILOSOPHY
AI が開発のループをどれだけ回しても、
一人ひとりの学び
技術を学び続ける姿勢と、お客様を知っていく姿勢が
変わらず大事です。
その2つの姿勢があるかないかで、
大きく差がついてしまう時代になりました。
学ぶかどうか、どんな人間力を育てるかは、人それぞれです。
解像度やリードは、あくまでその道の1つです。
開発のループの外側に、
問いと学び方を用意する
AI 時代は、ロールやチームを越えて、
視野とプレイの領域を広げていく必要がある。
ふりかえりの型も、TIPS も、ハーネス改善履歴マップも、
技術力と人間力を育てるための、問いと学び方です。
自分たちの改善
組織の強み
一人ひとりがその必要に気づけるように、
開発のループの外側に問いと学び方を設計しながら、
社内外を問わず「キミとだったら成し遂げられる」と言われる組織づくり
にチャレンジしています。
50
/
51


# Page. 51

![Page Image](https://bcdn.docswell.com/page/4JM6Z492EW.jpg)

採用も、お仕事のご相談も
募集中！