「学びを奪うのは、AIじゃない。 その賢さに頼りきることだ」

Scrum Fest Sendai 2026 「学びを奪うのは、AIじゃない。 その賢さに頼りきることだ」 - 入社2年目エンジニアとスクラムマスター はじめての仕様駆動開発、そのプロセスと実践知 - KDDI アジャイル開発センター スクラムマスター：泉本 優輝 デベロッパー：吉川 裕馬

Outline 01 AIは学びを奪うのか 04 AIと共に学ぶ環境とは？ 02 何も知らない 2年目の、３つの不安 05 実現場で整理したSDDチーム組成のためのチー トシートと開発プロセスマップ 03 それでも、動き出せた はじめての仕様駆動開発 06 AI時代に目指したい クロスファンクショナルなチームの形 KDDI Agile Development Center Corporation 2

スピーカー: mitsuba KDDIアジャイル開発センター (KAG) 泉本 優輝 / 蜜葉 優 • スクラムマスター (主にお客様案件に従事) • サブマネージャー 兼 戦略企画部 CTO室 Yuki Izumoto / @mitsuba_yu Blog https://c-mitsuba.hatenablog.com/ 主な経歴 • 2024/8 〜 現在：KAG所属 • それ以前はフリーランス、起業等で活動 ★ Microsoft MVP for Developer Technologies (15th) 趣味・ライフスタイル • カメラと洋酒とものづくりが好き • 兵庫県神戸出身、滋賀県在住 スクフェス初参加！ KDDI Agile Development Center Corporation 3

• https://c-mitsuba.hatenablog.com/

スピーカー：Yuma ● 吉川裕馬（Yuma Yoshikawa） ● 出身：大阪府東大阪市 ● KDDIアジャイル開発センター (KAG)所属 ● Role：Developer 経歴 ● 2025年4月に新卒として KAGに入社 ● 2025年7月 ~ 2026年5月中旬：データプラットフォーム案件に配属 ● 2026年5月中旬 ~ ：建設会社向けのアプリプロダクトに配属 初出張！初参加！初登壇！ KDDI Agile Development Center Corporation 4 / 40

Learning Outcome : 今日のお持ち帰り 01  02  03  仕組みの導入 目指す チームビルディング 学びを楽しむ マインド作り ・チームの合意とプロダクトの背景 を整理する方法を知る ・AI時代に目指すチーム像の １つを知る ・メンバーの「分からない」を 発見として、楽しみと捉える ・合意と背景を、人にも AIにも 渡せる "仕組み "にする方法を知る ・クロスファンクショナルなチーム 作 りの手法を 1つ学べる ・自身の学びとして楽しむ ・チームの学びにつなげる ・AIを組み込んだ開発プロセスの 表現方法を知る KDDI Agile Development Center Corporation 5 / 40

1. AIは学びを奪うのか KDDI Agile Development Center Corporation 6

歴史的にも、新しいツールの登場時には同様の「学びが奪われる」論争があった    電卓 (1970年代) 検索エンジン (90〜00年代) Wikipedia (2000年代半ば) ▼ 懸念されたこと ▼ 懸念されたこと ▼ 懸念されたこと 暗算力の低下 記憶力低下（グーグル効果） 批判的思考力の低下 ▼ 変化・結果 ▼ 変化・結果 ▼ 変化・結果 数的感覚や応用力の重視へシフト 情報の分析・統合力の重視へシフト 情報の真偽を見極める力の重視へ 共通点から得る示唆 登場当初は常に強い危機感が起きるが、時間とともに 「ツールを前提とした上で、人間が新しく何を身につけるべきか」が再定義されていく。 KDDI Agile Development Center Corporation 7

AIは学びを奪うのか AIによる自動化と変化 技術学習の境界線 歴史が示す示唆 ● なんでも解が出る時代 ● どこまで学ぶべきか？ ● 繰り返される「学習喪失論」 AIを使えば、答えがすぐに 出力され、コードも自動生成される AIがコーディングを代替する中で、 エンジニアが身に付けるべき技術 の深さはどこにあるのか。 ● 試行錯誤の機会損失？ プロセスが省略されることで、開発 におけるトライアンドエラーの経験 が損なわれる懸念。 ・設計思想の理解で十分か？ ・アルゴリズムまで詳細に踏み込む べきか？ 新しい革新的技術が登場するたび、 同様の議論が巻き起こってきました。 過去の事例： ・電卓の登場時 ・検索エンジンの普及 ・Wikipediaの台頭 一方で、試行錯誤の対象が 「AIへの指示の出しかた」に シフトしているだけではないか？ KDDI Agile Development Center Corporation 8 / 40

2. 何も知らない2年目の、３つの不安 KDDI Agile Development Center Corporation 9

事実：どんな状況で、ジョインしたか チーム構成 案件のフェーズ ここから参加 SM (泉本) エンジニア 経験豊富 エンジニア テスト・品質好き つよつよ テックリード 着手 案件フェーズは半分超え リポジトリも成熟済みで、途中からの キャッチアップが必要だった 1SM 3DEV チーム 心境 「ちゃんと役立てるだろうか不安だ …」 KDDI Agile Development Center Corporation 10 / 40

事実：どんな状況で、ジョインしたか チーム構成 案件のフェーズ ここから参加 SM (泉本) エンジニア 経験豊富 エンジニア テスト・品質好き つよつよ テックリード （離脱予定） 吉川 (2年目) 着手 案件フェーズは半分超え リポジトリも成熟済みで、途中からの キャッチアップが必要だった 1SM 3DEV チーム 心境 「ちゃんと役立てるだろうか不安だ …」 KDDI Agile Development Center Corporation 11 / 40

事実：そもそも、どんな案件だったのか サービス要件 開発環境 プロダクト 開発スタイル 建設業で法令を遵守させるための 機材管理業務アプリ 仕様駆動開発（ SpecKit） & TDD & Mutation Test を採用 ユーザー 技術スタック 1. 2. フロントエンド： Vite (React) バックエンド ： .NET (C#) インフラ ： Azure 参画時のコード： プロダクト 12万行 / テスト 18万行 / 自動生成 20万 現場の管理監督者 機材を使用する施工者 KDDI Agile Development Center Corporation 12 / 40

不安：３つの「未知」に、囲まれていた ① 技術スタック ② 顧客ドメイン 業界知識、業務プロセス .NET(C#)・React・Azure 建設系・法令が絡む領域 今回であれば、労働安全衛生法 法令を守る緊張感 業務も背景もゼロからスタート 間違いが許されない領域では？ 前案件は AWS/Snowflake/Terraform 今回の技術は全て未知 KDDI Agile Development Center Corporation ③ プレッシャー 13 / 40

① 技術スタック “貯金” は、使えなかった 前案件：データ基盤の世界 今回：Web アプリの世界 AWS フロントエンド： React Snowflake バックエンド： .NET (C#) Terraform インフラ： Azure Azureは「AWSの知識で少し流用できるかも」と期待 … → でも案件の性質上と案件の進捗的に、インフラはほぼ触らず。 KDDI Agile Development Center Corporation 14 / 40

① 技術スタック “貯金” は、使えなかった 前案件：データ基盤の世界 今回：Web アプリの世界 AWS フロントエンド： React Snowflake バックエンド： .NET (C#) Terraform インフラ： Azure Azureは「AWSの知識で少し流用できるかも」と期待 … → でも案件の性質上と案件の進捗的に、インフラはほぼ触らず。 メインの .NET・React は ほぼ 0（大学でかじった程度） 正直、「何もわからん」 だった KDDI Agile Development Center Corporation 15 / 40

② ドメイン ＆ ③ プレッシャー 「建設の話なんて、まったく分からない。 その上、法令まで絡む … 実装するシステムや制約、ややこしそう」 ② 業務知識・ドメイン ③ プレッシャー 建設関係の業務は、完全に未知。何をどう作るのか、想 像もつかない。 法令が絡む。「守るべき制約でシステムがややこしくなる のでは」という重さ。 KDDI Agile Development Center Corporation 16 / 40

3. それでも、動き出せた はじめての仕様駆動開発 KDDI Agile Development Center Corporation 17

5日 KDDI Agile Development Center Corporation 18 / 40

5日 「何も知らない 2年目」が、 はじめての PRを出すまで。 KDDI Agile Development Center Corporation 19 / 40

最初の5日間で、起きたこと Day 1–2 Day 3–4 Day 5 環境の整備 モブプロで実戦 自立とPR • 現状出来ているアプリの説明 • システム構成のレクチャーを受 ける • 開発環境をセットアップ • モブプロで実チケットを実装 • １人で実装できるのでは？ • 先輩とSpecKitでの開発を間近 で経験 • はじめての PR作成へ • 指摘の観点・頻出エラーの 直し方を習得 • フロントコード量（ 5.2 万行） KDDI Agile Development Center Corporation • 作業範囲はフロントの変更のみ 20 / 40

なぜ動けたのか ①：仕様駆動開発（抽象 →詳細） 要求、抽象 設計、方針 詳細、実装方法 どんなものを作る か どう作るか 何をやるか spec.md plan.md tasks.md 段階的に降りていく仕様駆動開発があるから、業務知識、背景も技術も無くても “どんなものを作るかのイメージ ”（抽象） と “作業のイメージ ”（設計） が掴めた KDDI Agile Development Center Corporation 21 / 40

なぜ動けたのか ②：整えられていた環境 詰まっても、止まらない 「Claude に聞けば大体わかる」環境があった。 “わからない ” を埋める導線 全てをコードベースと Claude へ 1. まず Claude に聞いてみる リポジトリに プロダクトの背景、ドメインナレッジ、 実装のための参考資料（ Excel等）を多く格納 Azure や Azure DevOps、 ホワイトボードツールへの情報は API / MCP で回収 2. だめなら先輩に聞く 分からなかったものは、 Claude が答えられるように一緒に改善。 KDDI Agile Development Center Corporation 22 / 40

整えられていた環境とは ドメインの整理 開発資料の整理 技術の整理 業務や背景の知識が 整理されている （PO / SM / エンジニア） 画面遷移図など、必要な資料が まとまっている（ SM / エンジニア） 技術選定や開発規約、アーキテクチャ など実装に必要な知識の整理 （エンジニア） AIに渡す準備 使ってほしい情報を、あらかじめAIに渡しておく KDDI Agile Development Center Corporation 23

6日以降 とはいえ、5日目まではうまく行かせてもらったと感じた KDDI Agile Development Center Corporation 24 / 40

そして、わからないことを見つけた 作業範囲の広いPBIを任された時にAIの出すPlan.mdがわからなかった 機能実現するためのコードのイメージを持ち、 どう動くのか理解した上で開発する AIと対話するために ドメイン知識も、技術も要る。 KDDI Agile Development Center Corporation 25 / 40

そして、わからないことを見つけた 作業範囲の広いPBIを任された時にAIの出すPlan.mdがわからなかった 機能実現するためのコードのイメージを持ち、 どう動くのか理解した上で開発する AIと対話するために ドメイン知識も、技術も要る。 学びを奪っているのは、 AIに 「丸投げ」 をしていること AIと共に賢く なることが、人の学びになる KDDI Agile Development Center Corporation 26 / 40

AIと共に学ぶ環境とは？ だれがどういうふうにつくったの？ KDDI Agile Development Center Corporation 27

AIと共に学ぶ環境 全てをコードベースと Claude へ 実現するために リポジトリに、 プロダクトの背景・ドメインナレッジ・機能実 装のための参考資料（ Excel等） を多く格納 ● 全てをコードベースと AI に渡すこと ● AI が指摘したコードレビューが再発 しないよう、コードベースを育てること ● Azure や Azure DevOps、ホワイトボード ツールへの情報は API / MCP で回収 ● 日々増える要件を、コードベースと AI に反 映させ続けること ● Claude に聞いて分からなかったものを、 Claude が答えられるように一緒に改善 ● AIが分からなかったことを見つけた という楽しめるマインドを持つこと ● KDDI Agile Development Center Corporation 28 / 40

その環境は、だれがどういう思想で作り始めたのか 開発コンセプト（ワーキングアグ リーメント） ● ● ● AIに開発させるなら、 AIが開発できるようAIを育成することこそが 人の仕事 実装業務をAIに任せるため、案件やプロダ クトに関わる情報を可能な限りリポジトリに 入れることにした 良くないコードベースからは、よくないコード が生まれる。 リファクタは気づいた時にすぐにする アーキテクチャ ● 情報を集約するための、モノレポ ● クラスの責務を明確にするため、 リポジトリパターンをベースとした レイヤードアーキテクチャを採用 ● サービス層や型安全性など、自動生成でき る領域は可能な限り自動生成 ● AIが書くコードは、テストコードと機能実装の み KDDI Agile Development Center Corporation 29 / 40

5. 実現場で整理した SDDチーム組成のための チートシートと開発プロセスマップ KDDI Agile Development Center Corporation 30

仕様駆動開発/AI駆動開発を行うチームが整理すべきチートシート 開発プロセス 準備 & 方針 品質 & チームプレイ ツール & 構成 ✦ 実装の流れ ✦ 開発の準備 ✦ 品質向上と協調 ✦ 成果物と技術スタック • 1機能を実装するまでの プロセス • 仕様駆動に入る前の アーキテクチャ選定や準備 • テスト、品質面での アプローチ • プロセスの中で 適用している自作のSkills • チケットの 分割作業フロー • 開発方針・ワーキングアグリー メント • バグチケット対応時の アプローチ • 使ってるMCP・プラグイン • 他開発者の PRレビューフロー • SDDでチームプレイをする時 に気にしていること • 時々見直しているもの、 見直したいこと KDDI Agile Development Center Corporation • 仕様駆動開発で生成される中 間ファイル群 • 最終的にマージされる ファイル群 31 / 40

開発プロセスマップの型  特に大事な要素は、開発プロセスの整理 「完全にAIに任せられること」「人が注力すべきこと」「人と AIが交わるところ」 を主軸に置き、付箋を用いて各作業プロセスをマッピング・整理する  成果物・モノ モノとして 出力される 中間成果物 最終成果物  Spec Kit Spec Kit が用意している コマンドの実施  完全にAIに 任せる作業 自動化可能な タスク  人の作業 人間が主体と なって行う作業 KDDI Agile Development Center Corporation  人とAIの 協働作業 両者が交わる プロセス  意図・コメント プロセス背景や 補足情報 32 / 40

実際にチームで整理した SDD開発プロセスマップ 1. １機能を実装するまでのプロセス 2. 仕様駆動に入る前のアーキテクチャ選定や 準備としてやったこと 3. テスト、品質面の話 4. 気が向いた時、思い出したときに 時々見直しているもの、見直したいこと 5. バグ（バグチケット） 修正の時は どういうアプローチで修正してる？ 6. プロセスの中で適用しているFunction コマンド、Skillsは？ 7. 使ってるMCP・プラグイン 8. SpecKit利用時に追加されるファイル群 9. 最終的にマージされるファイル群 10. 開発方針サマリー （ワーキングアグリーメントみたいな もの） 11. SDDでチームプレイをするときに 気にしていること。 12. 懸念、もし最初からやりなおせるならこうやる、 もし次回やるならこうやる KDDI Agile Development Center Corporation 33 / 40

開発プロセスマップを作成する価値 チーム全体の知見をアップデートする仕組みとして、非常におすすめ 1. 構築と対話 2. ナレッジの共有 3. 多様な利用用途 試行錯誤が生み出す真の価値 挑戦する他チームへの道標 事業成長を加速する資産 ● 得意分野の持ち寄り 各プロフェッショナルの強みを活か して構築 ● 整理されたプロセスは、 他チームがSDDに挑む際の 学びの取っ掛かりに ● 出来上がったプロセスには、 社内だけにとどまらない 多様な価値 ● 最も重要なのは、 作成のプロセスで生まれる 対話と試行錯誤 ● 実践を通じて 「AIの周辺を整える重要性」 を明確に証明 ● 外部展開することで 強力な商材へ ● 実践的なナレッジが、 対外的な信頼と競争力へ ● プロセスを作るために、 あーだこーだと 議論を尽くした時間 KDDI Agile Development Center Corporation 34

6. AI時代に目指したい クロスファンクショナルなチームの形 KDDI Agile Development Center Corporation 35

AI時代に目指したいクロスファンクショナルなチームの形 I型・T型ではなく、一人ひとりの技術を個別の「レーダー」の形に喩える ① 個人の素のレーダー（形はバラバラ） Aさん Bさん Cさん Dさん ② チームの技術を個人の技術とする ＋ 個人の技術を AIに教える チームの技術 ＝ AIを介して拡張された “個人” の技術。 全員がAIを使って、これを自分のものとして使える。 KDDI Agile Development Center Corporation 36 / 40

AI時代に目指したいクロスファンクショナルなチームの形 I型・T型ではなく、一人ひとりの技術を個別の「レーダー」の形に喩える ① 個人の素のレーダー（形はバラバラ） Aさん Bさん Cさん Dさん ② チームの技術を個人の技術とする ＋ 個人の技術を AIに教える = AIで技術拡張 されたチーム チームの技術 ＝ AIを介して拡張された “個人” の技術。 全員がAIを使って、これを自分のものとして使える。 KDDI Agile Development Center Corporation 37 / 40

個人の技術を、再利用可能な技術に変える 3ステップ 1 2 3 個人の技術の結晶化 技術のAPI化 チームの技術で AI駆動開発 各メンバーが 自身の技術とドメイン知識を、リポ ジトリに落とし込む （テキスト化・資産化） 他のメンバーがAIを通して「再 利用可能な技術」として誰でも 呼び出せる形に整備 全メンバーの技術を 自分の技術として 開発を進める KDDI Agile Development Center Corporation 38 / 40

ただし ― 土台の技術力が、最外縁の “天井”を決める 「技術が足りないからできない」が消え、全員が “チームの最大出力 ”を前提に動ける 全員がジュニアなチーム ベース技術力の高いチーム チームの技術が小さい ＝ 実効技術も小さい チームの技術が大きい ＝ 実効技術も大きい ベースが小さければ、重ねても広がらない 基礎技術力の学習、習得は、これまでと変わらず重要 KDDI Agile Development Center Corporation 39 / 40

最後に、月曜日みんなにやってほしいこと。 ● 日々の 自身の 開発フロー、工夫、考え方、そういったものを 付箋に 並べて、 対話を通してチームのチートシートと 開発プロセスマップ を模索してほしい。 ● 模索の中で見つけた「分からない」は、自身とチームの学びにつながる宝物です。 ● その宝物と 、AIを使って、 宝物を見つけたワクワク感を持って、 AIをさらに学習させてほしい。 AIに教え込む過程もまた学びになる。 ● 教え込んだ AIを使って、拡張したチームこそ、 AI時代の 新しいクロスファンクショナルなチームの形の１つだと思っています。 KDDI Agile Development Center Corporation 40 / 40

Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る

APPENDIX KDDI Agile Development Center Corporation 42

努力で広げる → オンデマンドで注入する 現在 これから 人が頑張って隣を勉強し、 T型になる 他人の専門性を、 オンデマンドで注入する 隣接領域を個人が時間をかけて習得。学習コ ストが高く、技術獲得の速度が個人に依存す 必要な専門性をAI経由でその場で呼び出す。学 習を待たず、チーム最高水準の力で即実行でき る。 る。 KDDI Agile Development Center Corporation 43 / 40

AI時代のビジネス AI駆動開発の実態 説明責任の壁 顧客教育へのシフト 品質向上とオンボーディング 受託開発における限界 新しい価値提供の方向性 ● 同じ時間枠の中で、従来よりも質の 高い開発を実現できる領域。 ● ● ● メンバー入替時の理解・習熟度へ の影響は残るが、オンボーディン グ負荷は軽減可能。 AI活用で工数は確実に削減できる が、プロセスに説明責任を伴えな い課題。 もし顧客が（説明責任不要で）AI主 導の高速開発・納品を強く望む場 合の対応。 ● ● 機能の独立性に応じて人員を追加 すれば高速化できるが、スクラム人 数には上限がある。 結果として、現在の受託ビジネスモ デルでは安易な採用を見送る決断 に。 開発を代行するのではなく、顧客自 身が作れるように「伴走・教育」 す る方針。 ● 「納品物として、自社が品質とロ ジックを保証・許容できるか」という 本質論。 ● 受託開発の枠組みを超え、クライア ントの内製化・AI武装を支援するモ デルへ。 ● KDDI Agile Development Center Corporation 44 / 40

補足：実際に、 AIへ“渡している ”情報 この案件で、AIのために整えていた“文脈”の実体 仕様の「型」 規約・暗黙知 SpecKit の spec→plan→tasks を機能ごとに 蓄積（約290機能分） CLAUDE.md ／ プロジェクトメモリ（コード規 約・ドメイン知識など20本近く） ドメイン資料 画面・ UI 点検表マッピング等のExcel ／ ユーザース トーリーマップ（PDF） 画面遷移データ ／ Cacoo ワイヤーフレーム ／ 画面キャプチャ KDDI Agile Development Center Corporation 45 / 40

AI時代以前に語られたクロスファンクショナルなチーム  「I型」から「 T型」へ  パズルのように噛み合う  2つの大きなメリット 個人のスキルと課題 チーム全体でのスキルカバー 職能を超えたコラボレーション ● 専門特化の「I型」では、特定工程 がボトルネックになると全体が止ま る。 ● メンバーのT型の「横棒」が噛み合 い、チーム全体で必要スキルを 100%カバーする。 ● 職能間のバトンタッチによる「待ち 時間」が激減し、チームの開発速 度が向上。 ● 「T型」スキル＝深い専門性（縦棒） ＋専門外も手伝える幅広い基礎知 識（横棒）。 ● 全員が何でも屋になる必要はな い。「隣の人を少し手伝える横の 羽」を広げることが鍵。 ● 専門外への挑戦も、領域のプロが チーム内にいるため安心して学習 できる環境に。 KDDI Agile Development Center Corporation 46 / 40