こんにちは、SmartHRで労務基本機能の開発をしている田中です。
私たちのチームでは、2025年の後半からスクラムイベントの準備・運営にAIを取り入れる取り組みを進めてきました。主に使っているのはNotion AIです。Slack・GitHub・Jira・Notionの情報を横断的に探索させ、各イベントの「叩き台」を生成させています。
この記事では、レトロスペクティブ・プロダクトバックログリファインメント（Product Backlog Refinement、PBR）・スプリントプランニング・スプリントレビューの4つのイベントでのAI活用を紹介します。試した結果やめたデイリースクラムでの事例も含めて、チームのリアルな実践をお伝えします。
レトロスペクティブ：AIにスプリントをふりかえってもらう
はじめに、レトロスペクティブでの活用を紹介します。
AI導入前のレトロスペクティブ
私たちのチームではGKPT（Good、Keep、Problem、Try）によるレトロスペクティブを行っています。 当時、私たちのチームではFigJamなどのツールでGood/Keep/Problem/Tryを付箋で記入していました。視認性は高かったものの、議事録として検索できず、AIに読み込ませることにも適していませんでした。「今後AI活用を進めるなら、管理しやすいNotionでふりかえりをやってみよう」という話がレトロスペクティブであがり、移行を決めました。
Notionでのレトロスペクティブに切り替えた後
現在、私たちのチームではNotion AIにスプリント全体のレトロスペクティブ議事録を自動生成させています。AIがSlack・GitHub・Notionの情報をもとに、以下の内容をすべて出力します。
- スプリント概要（チケット完了状況）
- メンバー全員への褒め（具体的な行動ベース）
- Good/Keep/Problem/Tryの提案
- 学び・気づき（技術的・チーム運営）
- 外部からの依頼・サポート
- スクラムマスターからの総括コメント
この出力はあくまでも叩き台です。レトロスペクティブの冒頭でAIの出力を読んだ後、メンバーがGood/Keep/Problem/Tryに自分の意見を追記し、AI提案と人の観点の両方をもとに議論を進めていきます。AIの提案には「AI提案:」というプレフィックスをつけて、人間が書いたものと区別できるようにしています。
AIが出力する項目のうち「メンバーへの褒め」は、具体的な行動ベースで書かれます。「バリデーションテストを着実に進め品質担保に貢献」「モジュラモノリスに関する勉強会の準備を進め、チーム全体の技術力向上を推進しました」といった内容です。AIの出力を「正解」として受け取るのではなく、「あ、そういえばこんなこともあったな」と記憶を呼び起こすトリガーとして活用しているのがポイントです。
AI出力の注意点
レトロスペクティブでのAI活用には、対象期間外の情報が混入するリスクがあります。これに対しては、プロンプト内で「対象スプリントの期間を厳密に検証すること」というルールを設定して対処しています。 また、誰が関わった事象かの取り違いが起きることもあり、そのときは議事録上で「対応者が別人だった」などと訂正コメントを残しています。 プロンプト自体もレトロスペクティブで継続的に改善しています。
PBR：観点出しと受け入れ条件のチェック
PBRでは、AIを活用して観点出しや受け入れ条件の品質チェックを事前に行っています。もともと文章ベースで進める作業が多いため、AIとの親和性が高いと感じています。
AI導入前のPBR
以前は、チームで作成した「PBR観点チェック」のドキュメントを、PBRの場でチケットごとに同期的に確認する運用をしていました。しかし、確認すべき観点は大項目だけでも10以上、細かい観点まで含めると100項目近くに及びます。これらをPBRの時間内に人力で網羅的にチェックするのは負担が大きく、抜け漏れも発生しがちでした。
AIによる観点出しに切り替えた後
現在は、AIにJiraチケットの情報を読ませて、観点出しや受け入れ条件の品質チェックを事前に行っています。AIの出力結果をあらかじめPBR議事録に反映しておくことで、メンバーが内容を確認した状態で当日の議論に入ることができ、議論時間の短縮にもつながっています。
たとえばCSVによる取り込みの実装時には、「ヘッダーの許容ルール（大文字小文字、全角半角、前後スペース、改行、BOM）はどこまで許容するか？」といった観点をAIが提案しました。以前は観点チェックドキュメントを見ながらでないと出せなかった内容も、自動で洗い出されるようになっています。
以下は、実際にPBRで使用しているプロンプトの抜粋です。チケットごとに観点出しと受け入れ条件の品質チェックを行います。
このページに記載されている各チケットセクションについて、 以下の作業を行ってください： 【ステップ1】チケット情報の取得 - スプレッドシートから該当チケットの説明・受入条件を取得 【ステップ2】PBR観点に基づく分析 - 「PBR観点チェック」をもとに、以下の観点を最低1回ずつ走査： • UI • データ操作 • 履歴 • バリデーション • 非機能要件 • 既存機能・他プロダクト影響 • サポート・ドキュメント • ステークホルダー • PBI分割・依存 • 実装・テスト • 大量データ 【ステップ3】受け入れ条件の品質チェック 取得した受入条件に対して、以下の観点でチェックする。 ■ 4つの必須要素が含まれているか ① Doneの具体像（観測可能・検証可能か） ② ビジネスルール・制約（暗黙知になっていないか） ③ 例外・エラーケース（現実的に発生しうる異常系が明記されているか） ④ 非機能要件（ユーザー価値に直結するものに限定されているか） ■ アンチパターン検出 * 仕様書や設計書のコピペになっていないか * 技術タスク・実装手順の分解になっていないか * 曖昧な表現が残っていないか（例：「適切に」「正しく」「問題なく」）
このプロンプトにより、AIはチケットごとに「抜けている観点」「リスク」「確認事項」「受け入れ条件の修正案」を出力します。
スプリントプランニング：サブタスクの洗い出し
スプリントプランニングでは、Notion AIにチケット情報を読ませてサブタスクの洗い出しを行っています。AIはチケットの内容をもとに必要なサブタスクを洗い出すだけでなく、チケットの特性に応じた作業工程を提案してくれます。たとえば調査系のチケットであれば、調査そのものだけでなく、調査後のドキュメント作成や後続チケットの起票もサブタスクとして提案されます。実装系のチケットであれば、テストコードの追加やレビュー依頼が含まれます。人が考えると「調査する」で終わりがちなところを、AIが前後の工程まで含めて洗い出してくれるのがポイントです。
サブタスクと合わせて、チケットの内容をもとに実装するうえでの疑問点も出力してもらっています。AIが疑問点を事前に出してくれるので、プランニング中にチケットを見ながら思い出す場面が減り、議論の効率が向上しています。
メンバーからは、サブタスクの粒度が安定してやりやすくなったという声がある一方で、「スプリントプランニングは元々文章がメインだったのであまり変わっていない」という正直な声もあります。劇的な変化というよりは、「地味だけど確実に底上げしてくれる」存在としてチームに受け入れられています。
スプリントレビュー：3つのプロンプトで準備を効率化する
スプリントレビューでは、ステークホルダーへの共有資料の準備にAIを活用しています。
AI導入前のスプリントレビュー準備
スプリントレビューの準備では、私たちのチームでプロダクトゴールの進捗をJiraで手動管理し、スプリント概要の共有資料はプロダクトオーナー（Product Owner、PO）が都度整理していました。
プロンプトによる自動生成に切り替えた後
現在、私たちのチームでは、スプリントレビュー議事録のNotionテンプレート内に3つのプロンプトを保存し、それぞれを使って「プロダクトゴール達成状況」「スプリント概要の共有」「プロダクトを取り巻く状況と今後の見通し」という議事録の項目をAIに自動生成させています。
プロダクトゴール達成状況を生成するプロンプト
このプロンプトは、Jiraのチケットを入力に、達成度イメージ・進んでいる点・残っている点・今後のフォーカスを出力します。ポイントベースで進捗を示す方法に改善し、より客観的な状況把握ができるようになりました。
スプリント概要の共有を生成するプロンプト
このプロンプトは、「このスプリントで提供したい価値」「価値の観点からのテーマ整理（3〜5個）」「前進させたい状態像」を、未来志向・意図ベースで自動生成します。各価値テーマが「なぜそれをやるか」の観点で生成されるのが特徴で、たとえば「CSV一括取り込みの品質を先行して担保する」のように、単なる作業報告ではなく「意図」と「狙い」にフォーカスした概要が出力されます。
プロダクトを取り巻く状況と今後の見通しを生成するプロンプト
このプロンプトは、プロダクトゴールの達成状況やスプリントの実績を踏まえて、チーム周辺の状況変化・近〜中期の見通し・リスク評価の変化を出力します。リスク評価では「解消されたリスク」「顕在化したリスク」「新たに注視すべき点」の3軸で整理され、たとえば「UI実装が完了し、技術的な不確実性が解消された」のように、スプリントの成果がリスク認識にどう影響したかを具体的に言語化します。
プロンプト設計の工夫
スプリントレビュー用のプロンプトには、いくつかの設計方針を設けています。
- 「平易な日本語で書く」
- ステークホルダーにも伝わる表現にする
- 「確信度が低い内容には要確認と明記」
- AIが自信のない情報を断定しないようにする
- 「実績ベースで書く」
- 推測や願望ではなく、達成したこと・できなかったことに基づく
生成された叩き台をもとに、まず読む時間を設けてからディスカッションに入る運用にしています。
試してやめたこと：デイリースクラム
すべてのスクラムイベントでAIがうまくいくわけではありません。私たちはデイリースクラムでもNotion AIを試しましたが、1スプリントの試行後に中止しました。
AIを取り入れたきっかけは、レトロスペクティブで、他チームが既にAIで状況を自動出力していた事例が話題に上がったことです。「うちのチームでも試してみよう」と提案し、次スプリントからNotion AIでデイリースクラムの進捗状況を自動生成する運用を試行しました。
しかし、2週間後のレトロスペクティブでメンバーから「テキストベースの出力だとタスク状況が把握しづらい」という指摘がありました。以前のFigJam運用ではタスクの全体像をビジュアルで一目で把握できていたのに対し、Notion上のAI出力では進捗のビジュアライズが弱く、同じ体験が得られなかったのです。結果として、FigJamに戻すことになりました。
この経験から得た学びは、スクラムイベントごとにAI活用の向き・不向きがあることです。テキストベースの出力はレトロスペクティブやPBRのように文章で議論するイベントには向きますが、デイリースクラムのようにタスクの全体像を一目で把握したいイベントには不向きでした。
AIをスクラムに取り入れた所感
ここからは、半年間の実践を通じて感じた効果や温度感をまとめます。
チームの温度感
チーム内でのAI活用に対する温度感は、総じてポジティブです。メンバーからは「完璧じゃなくても、叩き台を出してくれるだけでありがたい」という声があり、「変な回答を出してくるのはありつつも、調整しながらやっていけばいい」というのがチームの共通認識です。 対象期間外の情報混入や対応者の取り違いといった課題はあるものの、チーム全体としては「AIが出してくれている価値のほうが大きい」という結論に至っています。
感じている改善効果
定量的なBefore/Afterのデータはまだ計測できていませんが、定性的に実感している改善効果があります。
- 情報の網羅性が上がった
- メンバー個人の記憶頼りだったふりかえりが、AIによるSlack・GitHub・Notion・Jiraの横断探索に変わり、抜け漏れが減った
- 議論の立ち上がりが早くなった
- ゼロベースで考えるのではなく、AIの叩き台を起点に議論を発展させられるようになった
- 属人化リスクが軽減された
- スプリントレビューの準備がPO個人の仕事だったのが、AIプロンプトの実行で誰でも叩き台を作れるようになった。プロンプトもNotionに保存されており、ナレッジとして蓄積・改善が可能
- 全員の貢献が言語化される文化
- AIが毎回全メンバーの行動を具体的に褒めるセクションを生成することで、人間だけでは見逃しがちな小さな貢献（お問い合わせ対応、ドキュメント整備等）も拾い上げられるようになった
おわりに
この記事では、スクラムイベントの準備・運営にAIを取り入れた実践を紹介しました。AIの出力を「叩き台」として活用し、議論のスタート地点にするという姿勢が、無理なく続けるためのポイントです。一方で、デイリースクラムの事例のように向き・不向きを見極めることも大切です。
今後はプロダクト要求仕様（Product Requirements Document、PRD）からのチケット化など、より上流の工程への拡大も検討しています。まずは1つのイベントから、みなさんのチームでもAI活用を試してはいかがでしょうか。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
