20260819_AIが行き詰まりを消したとき、学びはどこへ行くのか
-- Views
August 19, 26
スライド概要
PBLPUB2026(https://pblpub.org/)で発表した資料になります。
Insurtechラボで作成しているスライドです
関連スライド
チームリーダーおすすめの勉強法
Insurtechラボ
18.6K
各ページのテキスト
AIが行き詰まりを消したとき、 学びはどこへ行くのか ―実務の中でPBLを考える思考実験 2026年8月19日 PBL Pub 2026
自己紹介 小泉 岳人 X（Twitter）：@koitake_ 金融系SIerでマネージャーをしています。 趣味：コントラバス スクリーンショット・写真撮影・SNS共有 大歓迎！ #pbl_pub #pbl_pub 2
本日の背景 ⚫ 今年になってAI駆動開発を実施している ⚫ アジャイル開発でやっているがうまくいっていない ⚫ 学習がポイントと感じていて悩んでいる ⚫ PBLが解決の糸口にならないか？と思った #pbl_pub #pbl_pub 3
AI開発のコンテキスト ⚫ アジャイル開発を支援 お客様・開発会社の間に入り、アジャイル推進をサポート ⚫ 約20名の混成チーム 複数組織・会社で、アジャイル・AIを実践しながら開発 ⚫ 新規開発を有識者のプラットフォームチームが支援 AIハーネス、アーキテクチャ、インフラを整備 我々の組織のメンバー お客様が発注した別会社/組織のメンバー お客様 （PO) PO Dev Dev Dev #pbl_pub #pbl_pub Dev Dev プラットフォームチーム Dev ScM デザイ ナー Dev Dev Dev Dev Dev (ScM) 開発チーム(ストリームアラインド) Dev ScM 4
発生している課題 AIで増やしたかったのは、コード量ではなく「価値を生み出せる速度」。 そのためには、作る速度と同時に、理解し判断する力を高める必要がある。 2 実際の状況 1 目指したかった開発 1 AIで形にする(理解負債が増える) 1 AIで形にする(理解負債が増える) 2 動くもの・実例で理解/学びが進む 2 人の理解より成果物が先に増える 3 理解負債が返済される 3 理解負債が積みあがる 4 学びをAI/ルール/設計に戻す 4 判断・責任が曖昧になりAI依存が進む 5 開発進むほど速く・良くなる 5 後半で手戻り・停滞が増える 人とAIがともに成長する開発 AIに判断を預ける開発 AIで「作る」ことは速くなった。だが、人の理解が追いつかなければ、判断できないものが高速に 積み上がる。目指したかったのは、作るたびに理解と判断力も蓄積され、進むほどよくなる状態 #pbl_pub #pbl_pub 5
発生している課題 現在案件序盤ではあるが、どんどんと問題が増えているよう感じる コードスメルの量 実施されないE2E 網羅しているが、信頼しきれないテストコード でも、開発自体 は進む・・・ 触りやすさを優先して分解されるバックログ 説明できない #pbl_pub #pbl_pub 6
なぜ、分からないまま進むのか 問題の背景は個人の問題だけでなく、構造的な問題がある 1 スキル不足 AIなしでは基礎スキルが不足 (案件の中で学びが遅い) 2 文化・契約 受委託が複雑な中で、 「分からない」を出せない 3 Agile運営不足 問題発見を素早くできるのが Agileの良い所だが、「問題」 に気づきにくい お客様 会社1 会社2 再委託 再委託 なぜか進む 問題はありません ワンチーム AIにより、分からなくても開発は進む だからこそ、分からなさを意図的に表出しないといけない #pbl_pub #pbl_pub ※ 本案件独自事象でもなく、同じような課題が見込まれるジュニアメンバーを 多く入れてのAI×アジャイルの受託開発は今後増加していく見込み 7
AIが『行き詰まり』を消したとき、学びはどう起こすのか AI以前 分からないと止まる 分から ない 止まる 試す 学ぶ AI時代 分からなくても、進める 進む 分から ない 行き詰って、止まり試すことで 学びになっていた AIに依頼 進む AIが「行き詰まり」を超えるこ とで、分からないが表にでない 意図的に止まらないと学びづらい でも、実案件では『止まる』ことにも壁がある 1 進捗圧力 学習より「まず 進める」が勝ち やすい 2 表明の難しさ 成果物を出す中で 「分からない」と 言いづらい 3 AI熱に浮かされる 周りの「AI使っ て〇〇」の話に 目的を奪われる 学習を自然発生に任せず、進め方として設計する必要がある #pbl_pub #pbl_pub 8
AI時代ほど、スクラムマスターの「学習を設計する力」が重要になる スクラムマスターが設計する「学びのサイクル」 1 気づく 2 問う 3 広げる 4 残す 品質や状況を 見える化する 「分からない」を 問いで表出させる チームを越えて 学びを交換する 学びをストックする 運営を設計する 進んでいるように見えて も。品質や理解の不確か さにチーム自身が気づけ るようにする 本人たちも認知できてい ない「分からない」を見 つけ、意図的に立ち止ま るきっかけにする 自分達だけでは気づけな い前提や疑問に出会い、 視野と学びを広げられる 学びや判断基準を CLAUDE.mdやSkillに反 映する等、個人の経験で 終わらせず、組織の知識 として積み上げていく スクラムマスターの役割は、答えを教えることではなく、 「気づく・問う・広げる・残す」が自然に起きる場と仕組み を設計すること #pbl_pub #pbl_pub 9
思考実験：PBLとして、学び方を仕切り直してみては？ 考えるために、立ち止まれるようあえてPBL(Project Based Learning)として2週間だ け、学習を強く意識した運営に切り替えてみたい 通常業務のまま PBLとして仕切り直す ⚫進捗が優先される ⚫問いが出にくい ⚫空気や役割が固定される ⚫AIで進むため、立ち止まりにくい ⚫「分からない」を出すことの意味 を変えられる ⚫「立ち止まり」を意図的に作れる ⚫固定した役割や関係性を崩せる ⚫学習そのものを実験できる ⚫評価や見える化をしやすい #pbl_pub #pbl_pub 10
思考実験：具体的なPBL運営（1/2） 2週間限定で、推進よりも学びを中心とした形でPBL期間として試行してはどうか？ ＜概要＞ 内容 9月の2週間、実案件の管理者機能を題材に、2～3名の混成チームでPBLを実施。曖昧な状態から目 的・要件・Backlogを考え、「分からない」に気づき、チームを越えて学びながら、より良い開発方法 へ自ら改善できる状態を目指す。 ＜主な観点/通常業務との変化＞ 観点 通常業務 PBL運営 ① Backlogの渡し方 POが具体化したBacklogをも とに実装 粗いBacklogから、目的・業務ルール・要件を 開発者自身で考える ② 「分からない」の 価値観 分からないことがなく、順調 に進む状態を良しとする 「分からない」が出ることを良しとし、問い・ 怪しい前提・AI任せの判断を毎日共有する ③ 視野の広げ方 担当機能を中心に進め、必要 に応じて全体整合を見る 3チームで並行開発・比較・統合し、DBやAPI など全体課題に気づく ④ 学び方の見える化 進捗・品質・成果物を中心に 確認 品質指標＋ルーブリックで、問い・仮説・説 明・越境などのふるまいを毎日振り返る ⑤ 期間と成果物の扱 い 作ったものを本番・次工程へ つなげる 2週間限定。成果物は原則再作成前提とし、失 敗・比較・学習を優先する #pbl_pub #pbl_pub 11
思考実験：具体的なPBL運営（2/2） 2週間後のゴールイメージ 2週間で上記に近づけるように観察していく #pbl_pub #pbl_pub 12
参考：観察/評価する指標のイメージ(仮) 前頁のゴールイメージをはかる観察内容・指標のイメージ 目指す状態 観察したい行動・状態 定量指標の候補 分からない点を自発的に表明する／ 1日あたりの問い・不明点数／メンバー ①「分かってい 説明できない前提を問いにする／AI 発の問い比率／「説明できない」と表明 ません」が言え に任せた判断を共有する／「問題な した件数／AI判断を確認対象にした件数 る し」で終わらず不確実性を探す ／問いが解消・更新された割合 コードスメル数・増減率／重複率・複雑 品質指標の変化にメンバー自身が気 ② 品質の変化に 度・Coverage等の推移／レビュー指摘 づく／原因仮説を出す／改善行動を 数／手戻り件数／メンバー発の改善提案 気づき、自ら改 決める／実施後に効果を見る／ScM 善する 数／改善提案→実施率／品質悪化検知→ や有識者に言われる前に動く 改善開始までの時間 AIの誤り・不足をパターンとして認 AI誤解・再作業の件数／AIハーネス改善 ③ AI時代の開発 識する／CLAUDE.md・Skill等の改 提案数／CLAUDE.md・Skill等への反映 善を提案する／AIへの指示・レ 数／他メンバーが再利用した改善数／同 を自分たちで良 くする ビュー方法を改善する／改善後の効 種のAI誤りの再発率／AI生成物への修正 果を確認する 回数の推移 他社・他チーム・ScMへ質問する／ 越境した質問・相談数／他チームへの支 ④ 会社・役割を 設計や進め方へ反対意見を出す／助 援数／他チームから得た知識を反映した けを求める・助ける／他チームの意 件数／ScMへのフィードバック数／発言 越えて意見でき る 見を取り込む／ScMへフィードバッ 者の偏り／会社・役割を跨いだ対話の組 クする 合せ数 #pbl_pub #pbl_pub 13
参考：ルーブリックのイメージ ゴールに向かう上でメンバーが意識するふるまい(ルーブリック) <チーム/個人向けルーブリック> 観点 Lv1：自分からやって Lv2：チームの成果に Lv3：周囲に広げる みる つなげる 「目的からすると、 「隣の機能も同じ前 作る前に「これって この仕様いらなくな 提では？」とPOや他 い？」と話し、 誰が何のために使 チームとBacklogを Backlogや範囲を変 う？」と確認する 見直す える 分から 「ここ説明できませ 「この前提、怪しく 「他チームも同じと ないを ん」「AIの答えに自 ない？」を流さず、 ころ分かってないか 見つけ、 信ないです」と声に チームで調べて設計 も」と問いを広げ、 伝える 出す を変える 早めに共有する 「このままマージす 「似た機能ない？」 「隣とDBの持ち方が 全体へ ると困りそう」と3 の影響 「先に決めることな 違う」と気づき、相 チームでDB・API・ を見る い？」と他Backlog 手と確認して設計を 共通ルールを整理す や依存を見る 直す る 目的か ら考え る チー ム・役 割を越 えて協 働 「それ、うちでもハ 会社や役割を越えて 「ここ分からないの マったので一緒に見 「その設計、大丈 で助けてください」 ます？」と他チーム 夫？」と意見し、互 と抱えず相談する を助ける いの知見を取り込む AIの回 答を問 い直す 「AIが毎回ここを誤 AIに「なぜ？」「前 「A案とB案ならどっ 解する」と気づき、 提は？」「他の案 ち？」と比較し、理 CLAUDE.mdやSkill は？」と問い返す 由を持って決める を直して共有する 品質・ 進め方 を改善 「この作り方が原因 「これ効いたから他 「コードスメル増え かも」と仮説を置い でも試そう」と共有 てない？」など違和 て改善し、変化を確 し、品質・AI活用・ 感を声に出す 認する 進め方へ広げる その他 上記以外の良いふるまいを適宜言語化して共有 #pbl_pub #pbl_pub <スクラムマスター向けルーブリック> 観点 Lv1：自分からやっ てみる Lv2：チームの変化 につなげる Lv3：学習を続けら れる状態へ 結果を見て、「発言 「考える時間がない は増えたが質問は増 のかも」と考え、全 えていない」と仮説 員1分考えてから話 を更新し、支援を変 すなど試す える 「なぜこの設計？」 「AIに任せた判断は ScMが聞かなくても、 問いに 「その前提本当？」 よって対 「まだ説明できない どこ？」と問い、 話を促す ところは？」と問い チームで確認対象を 「ここまだ分からな を投げる 決める いよね」と問い合う ScMがつながなくて 「隣のチームにも聞 対話・越 「別の人から説明し も、「あっちにも確 境が起き いてみよう」と他 る場をつ てみませんか？」と チーム・他社への相 認しよう」「一緒に 見ます？」と自ら越 対話を広げる くる 談を促す 境する 品質悪化を見て、 「原因は？何を試 メンバー自身が、 チームの 「この数字、どう見 す？」と問い、改善 「悪くなってきたか 改善を支 えます？」とチーム 案と確認方法をチー ら一度直そう」と改 える へ返す ムで決める 善を始める 事実を観 「主体性がない」で 察し、仮 はなく、「15分間A 説を立て さんしか話していな る い」と事実で捉える その他 上記以外の良いふるまいを適宜言語化して共有 14
まとめ：AI時代は学びの設計が今以上に必要 1 AIで「止まって学ぶ」が起きにくくなった • • 2 だから、学びを設計する役割が重要になる • • 3 AIで成果物は前に進みやすかった 一方で、「分からないと止まる」が減り、理解不足が見えにくくなった 学びを自然発生に任せず、場を設計する役割が求められる（≒スクラムマスター） 気づく・問う・広げる・残す、が起きる運営を意図的に作る必要がある その実験として、PBLとして仕切り直してみる？ • 実案件をPBLとして捉え直し、「分からない」を起点に学ぶ場を作る ※AIのフォースは強く、明示的な場の切り替えが必要か？？ AIを止めるのではなく、人とAIがともに 成長していく運営を模索中 #pbl_pub #pbl_pub 15