『なんか忙しい』を放置しない。妨害リスト×生成AIで、リファインメント準備を改善した実践

このスライドはスクラムフェス金沢2026での発表に使われたものです。
https://confengine.com/conferences/scrum-fest-kanazawa-2026/proposal/50039/ai

Transcript

1. © DMM © DMM CONFIDENTIAL Scrum Fest Kanazawa 2026 / 20min Talk 「なんか忙しい」を 放置しない。 妨害リスト × ⽣成AIで、 リファインメント準備を改善した実践 NaTo（なとー） / DMM.com 2026.06.20
2. INTRO ⾃⼰紹介 名取 優太 （なとー） 合同会社DMM.com データ基盤開発部 CDPチーム アクティベーションチーム スクラムマスター 今⽇の前提 今⽇は、開発チームではなく 運⽤チーム4⼈での改善の話をします。 ※AIで全部解決した話ではありません。 Scrum Fest Kanazawa 2026 2
3. © DMM
4. SETUP 今⽇の話 妨害リストという、 知っていたはずの型があります。 今⽇はそれが、初めてチームの 改善ループとして動き出した話をします。 きっかけは、運⽤チームで何度も出ていた 「忙しくなる時がつらい」という感覚でした。 AIは 主役ではない ループを ⼩さく速く回す道具 Scrum Fest Kanazawa 2026 4
5. Scrum Fest Kanazawa 2026 このチームの背景 チームの改善を試していたが、うまくいっている感じがしなかった 4人の運用チーム GA/GTMの運用及び 活用方針を定め、 データ活用を支える。開 発チームではない。 この体制では2年目 型はあった スクラム採用中。 レトロで意見は 良く出る 心理的安全性も高い 目的意識はあった AIや自動化を スクラムイベントに 組み込みたい気持ちは あった。 でも手探りだった 何から始めるか。 何を妨害と見るか。 どうすれば解決か あまりピンとこない 今回の話でうまくいったのは気合いではなく、「扱う妨害」を具体的にできたから BACKGROUND 5
6. PROBLEM レトロスペクティブでこんなことがありました でも 「なんか忙しい」 という感覚は 消えなかった Scrum Fest Kanazawa 2026 6 「急な依頼が多いとDoneできないよね」 「⾒積もりが⽢くてDoneできなかったね」 TRYで対応を考えてみた。 その次の週はうまくいった気がする…… キャパシティの把握、情報共有の仕⽅など、 できることは⾊々やってみた たぶんリファインメントがいけてなさそう。でもどこが？
7. Scrum Fest Kanazawa 2026 実際、いろいろやってみた やってみたこと そのときの狙い 残った違和感 キャパシティを見えるようにした 受けられる量を判断しやすくする 緊急の依頼 /対応・見積もりミスで崩れる 書き方のルールを見直した 依頼や背景を追いやすくする 人によってまちまち・認知負荷が高い リファインメント前に整理した 準備不足を減らす 手作業に依存する 会議メモを Meetで残した 決定事項を拾う チケット化は別作業 自動化できそうな所を探した 作業を軽くする 後回し／本質的でない自動化になる どれも点の対処で終わっていた → 妨害リストがあまり機能してなさそう TRIED 7
8. CONCEPT 妨害リストとは スクラムマスターの責務の⼀つ として、スクラムチームの進捗 を妨げる障害物を取り除くこと があります。 ここでは、その障害物を チームで扱える形にしたもの を妨害リストと呼びます。 ⼤事なのは「書く」ことではなく、 「ループを回す」こと。 観察 妨害として 定める ⼩さく試す 次の妨害が ⾒える このループが回ることで、改善が続いていく。 Scrum Fest Kanazawa 2026 8 ハズなのだけど ……うまくいってなかった
9. Scrum Fest Kanazawa 2026 9 点の対処 • 困っていることは書き出せる • TRYも出る • その場では少し良くなる • 数カ月後にまた同じような話をして いた 結果 • 次どうする、まで至らなかった • 根本的解決を目指せていなかった • 議論がそこまで深くなかった 困りごとの置き場ではなく、改善実験を生む仕組みにしたかった。 妨害リストにはなっていた。でも、ループにはなっていなかった。 TURNING POINT 困りごとや目的意識は共通している。でも、進め方がうまくいってなかった
10. そんなある日 ある日、メンバーが「仕組みを作ってみました」と出してくれた。 会議メモや文字起こしから、 チケット候補を作って、 PBIとして起票する仕組み ※ 詳しいフローは後で説明します。ここで大事なのは、ツール名ではありません。 「これ、作ってみました」 ⇩ 動くものが出てきた 困りごとと目的意識が共有されていた から、「ここを軽くできる」が 見やすくなっていたのでは？ 優秀なメンバーがたまたま作った話ではなく、 共有された違和感 から実験が生まれた瞬間だった Scrum Fest Kanazawa 2026 EXPERIMENT 10
11. ここで初めて、 ループが動いた AIすごい、ではなく。何かが変わった瞬間の話。
12. 仕組みが出てきて、妨害の輪郭が見えた この仕組みを見て、ようやく分かったことがあった。 重かったのは、単に「リファインメント」ではなかった 情報を 集める → 整理・転記 する → ドラフトに する 「忙しい」という感覚が、 「リファインメント前後の整理・転記・ドラフト化が重い」 という妨害として見えるようになった。 ここで、妨害リストが改善実験を生む仕組みになった。 Scrum Fest Kanazawa 2026 INSIGHT 12
13. FLOW 実際のフロー Google Meet 録画 → Geminiが 会議メモを⽣成 スプレッドシート 会議メモを転記 GAS 出⼒を解析し タイトル‧why‧ DoD‧whatへ Jira タイマー/⼿動で ⾃動起票 PO 確認‧修正 14時開始のMTGが終わり、16時のリファインメント準備にはPBIチケットが並ぶように 「これって違くない？」から議論を始められるようになった。 ドラフトの⽣成は⾃動。最終的な判断はPOが直接修正。 Scrum Fest Kanazawa 2026 13
14. DETAIL 仕組み：Meet→Gemini→GAS→Jira Google Meet → Gemini → GAS → Jira の⾃動連携 【TICKET_START】 【TITLE】タイトル【/TITLE】 h4. 目的・背景(why) ... h4. 受け入れ条件(DoD) ... h4. やること(what) ... 【TICKET_END】 Geminiが形式つきで出⼒ GASが解析 「チケット候補」シートに分割表 ⽰ タイマーまたは⼿動でJiraに起票 ⾃動で実⾏ Scrum Fest Kanazawa 2026 14
15. OUTPUT 実際の出⼒イメージ 【要リファインメント】 ◦◦の優先順位整理と期限調整を行い、△△が円滑に管理できている状態になる h4. 目的・背景(why) 〇〇はXXという状況にある。△△を控え、混乱を避けるために 優先順位を整理し、スケジュールを明確にする必要がある。 h4. 受け入れ条件(DoD) ・ 優先順位が確定している ・ 完了期限および優先順位ごとの期限が調整済みである h4. やること(what) ・ 優先順位を整理する ・ 完了期限について担当者と調整を行う Scrum Fest Kanazawa 2026 15
16. AIが作る。人間が判断する 前のフローで出てくるチケットは「完成品」ではなく、リファインメントで叩くためのドラフトです。 ドラフトを渡す AIが先に作る 整理・転記・ドラフト化 ・会議録を要約する ・決定事項とタスクを抽出する ・内容をドラフト化する ・過去情報を参照して補完する 人間が最後に判断する 価値・優先度・合意形成 ・どの妨害を優先するか決める ・ドラフトを判断する ・チケットの価値と優先度を決める ・チームに説明して修正/SBI化する AIに任せたのは判断ではなく、 判断に入る前の「整理・転記・ドラフト化」。 Scrum Fest Kanazawa 2026 SUPPORT 16
17. RESULT 何が変わったのか チケット化まで 2〜3⽇ 当⽇⼣⽅ （1時間後） 書き起こし作業 30〜60分 確認‧修正 10〜15分 数字だけじゃない変化があった： Scrum Fest Kanazawa 2026 17 - リファインメントで話せることが変わった - 書いてあることが変わるとメンバーの動き⽅も変わった 14時開始のMTGが終わり、16時のリファインメント準備にはPBIのタネが並んでいた
18. RESULT リファインメントで話せることが変わった 何を書くか これで合ってるか PBIに why‧DoD‧what が⼊った状態で議論を始められた - 「受け⼊れ基準、ここ違う気がする」という会話が事前に起きる - リファインメントで「なぜ作るか」「どうやって作るか」を話す時間が増えた Scrum Fest Kanazawa 2026 18 本来重要な、価値を確かめる対話と判断に時間を使えるようになった
19. Scrum Fest Kanazawa 2026 19 「何を書くか」から「これで合ってるか」へ Before：会議で話した人にしか背景がわからない タイトル ◦◦の問い合わせフローを整備する →整備してどうなるの？何が利用者に嬉しいん だっけ？ why （空欄） →なぜやるのかが書いてないことが多い DoD 利用者が迷わず使えるようになること →このチケットでどういう利点ができている状態な のかが欲しい After：読めばひとりで着手できる タイトル ◦◦に関する問い合わせをAIで自動化し、初期回 答が出せるようになり、質問者の削減に貢献する why 対応が属人化していて休暇時にブロックされてい ることを防ぐ DoD 初期回答がAIで回答できており、知見をもとに回 答ができている 書いてあることが変わるとメンバーの動き方も変わった BEFORE/AFTER
20. Scrum Fest Kanazawa 2026 20 「何を書くか」から「これで合ってるか」へ Before：会議で話した人にしか背景がわからない what バナー修正、周知、ガイド作る、リリース → 担当者に聞かないと始められない状態 　 書く人によって粒度がまちまち After：読めばひとりで着手できる what ①フロー確認 気になるポイントを書く ②パターン定義 　　AIを活用してできそうな案を書く ③動作チェック・テスト・レビュー ④リリース・周知文作成/周知 → 「これで合ってる？」から議論できる 書いてあることが変わるとメンバーの動き方も変わった BEFORE/AFTER
21. Scrum Fest Kanazawa 2026 21 メイン担当でない人も、思い出す時間を減らして発言できるようになった。 思い出す時間が減った すぐドラフトがある。 「何が決まったっけ」が減る。 属人性が下がった 会議を欠席したメンバーでも 背景を追いやすい。 書いてあることがわかりやすいので、作業時も詰まったりすることが減った。 書いてあることが変わるとメンバーの動き方も変わった RESULT 作業中でも見通しがわかりやすくなった。 Doneできないことではなく、判断できない PBIを作っていたのが問題だった
22. NEXT でも、これで終わりじゃなかった 会議の⽂字起こしだけでは、背景が⾜りない。 • 「なんでそう決めたの？」がドラフトに⼊らない • MTGで会話した⼈たちは知っている「暗黙知」が抜けている 判断できないPBIになり、リファインメントで補⾜説明が必要になる 次の問い：何を⼀緒に渡せばいい？ Scrum Fest Kanazawa 2026 22
23. NEXT 次の実験：会議録だけでなく、⽂脈を渡す 前提となる リポジトリ‧定義 関連する 過去チケット 過去の決定の経緯 会議録だけだと「何を話したか」は残る。 でも「なぜそう決めたか」は抜けやすい。 会議録 + 周辺情報を “⽂脈パック” としてAIに渡す実験を始めています ねらい：背景込みの why / DoD / what ドラフトを作り、 リファインメントを判断の時間に寄せる Scrum Fest Kanazawa 2026 23
24. Scrum Fest Kanazawa 2026 24 「改善が終わった」ではなく、「次に試したい」が出てくるようになった。 ドラフトに背景が薄い 文脈パックを渡す実験 問い合わせを負荷なしで早く対応したい NotebookLMへ問い合わせ対応を任せる NotebookLMを見ずに問い合わせする AIが自動で一次回答を作る仕組みを作る AIで回答したものの精度がまちまち skillsでガードレールを作る・テストする 動くものがあることで、次の妨害が見えるようになってきた。 CULTURE 次の問題から、次の改善が⽣まれた
25. Scrum Fest Kanazawa 2026 25 前までのTRYと、何が違ったのか 違いは、AIを使ったことではなく、次の妨害が見えるところまで回せたこと。 前までのTRY 症状への対処だった ・「忙しい」「準備が重い」をそのまま軽くしようとした ・効果はあったが、何を検査するかが曖昧だった ・数カ月後に、また同じ話が戻ってきた 今回の実験 妨害を具体化し、動くものにした ・「整理・転記・ドラフト化が重い」に絞った ・ドラフトが出て、会話が変わった ・「背景が足りない」という次の妨害が見えた BRIDGE 点を、次の実験につながるループに変えたことで大きく変わった
26. Scrum Fest Kanazawa 2026 26 難しくない。まずは負荷が発生している場所を探す。 1 「なんか忙しい」ことを妨害として名前をつける 2 負荷が発生している作業を探す 3 AIに渡せる入力情報を 1つ決める 4 対応させるドラフトを AIに出させる 5 人間が判断する場所を決めてから動かす 6 実際に動かしてみて、レビューする 7 足りないものを次の妨害として扱う AIが作って終わり、ではなく、人間が判断できるドラフトを作らせる。 REPRODUCE このステップで、忙しいを放置せず改善ループを始動させる
27. Scrum Fest Kanazawa 2026 27 「準備作業が重い」 1時間後にドラフト 「ドラフトに背景が足りない」 文脈パックを渡してみる 完成ではなく、次を見つけられる状態になった。 やめたら消える。続けることが型になる。 一つ解消するたびに、次が見えてくる LOOP
28. TAKEAWAY まとめ 妨害リストは、書いただけでは機能しない。 「なんか忙しい」 を観察し 具体的な妨害 として定め ⼩さく試して 次の妨害が⾒える ところまで回す そこまで回って、初めてチームの改善ループになる。 AIは、そのループを速く回すための道具である。 Scrum Fest Kanazawa 2026 28
29. ありがとうございました 「なんか忙しい」を放置しない。 妨害を⾒つけ、⾔語化し、⼩さく試し、次の課題を⾒つける。 このサイクルが、チームを少しずつ変えていきました。
30. CONTACT ご質問‧感想 X（Twitter） @NaTodsm06 話しかけてもらえると 嬉しいテーマ • 妨害リストの運⽤ • リファインメントのやり⽅ • 仕組み化‧フローの改善 • AIとスクラム Scrum Fest Kanazawa 2026 30