NotebookLMを使って少人数デイリースクラムのふりかえりをしてみる
はじめに
現在（2025年5月）、2名という最小チームでのデイリースクラムをしています。実施の内容がある程度固まってきたので、NotebookLMを使って洞察を得ながら、デイリースクラムのやり方のふりかえりをしてみました。
良いところ、改善の必要がありそうなところをプラス「＋」デルタ「▼」で記載します。
書いている人とチームの前提情報
-
書いている人
- スクラム開発の経験があり、その時のデイリースクラムとの比較をしての感想な気がする。
- EM（開発マネージャー）
-
チーム
- EMとテックリードのチーム
- チームのミッション
- 担当プロダクトの開発プロセスの改善とプロダクト品質の向上
- 技術負債の解消
デイリースクラムの実施方法とツールについて
デイリースクラムの実施方法と、利用しているツールについて以下に記載します。
現状の実施方法とツール
-
時間枠は30分くらい
-
毎日10時〜10時30分の30分間
- 他のMTGと被ったら時間を調整する
- 結果、時間帯は午前中になることも、午後になることもある
- 他のMTGと被ったら時間を調整する
-
オンライン｜オフライン
- 東京vs大阪になるので、オンラインでの実施
- ツールはMicrosoft Teams
-
タスク管理ツールについて
- Notion DBで大きなタスクを管理（上長への報告用）
- スプリントで取り組んでいるタスクはGitHub Projectsで管理
- デイリースクラムではこれらのタスクの確認と棚卸しをしている。
スクラムガイドからの洞察
NotebookLMで作成したアジャイル開発｜スクラムの文献を読み込ませたNotebookを使用しました。そこから、スクラムガイドとのデイリースクラムの差異について洞察を得ました。結果のGistにアップロードしています。
#file-notebooklm-clip01-md
スクラムガイドでは、デイリースクラムの時間は15分以内と定められています。しかし、私たちは30分としているのは、その理由からだと感じています。
- 現状【2025年5月】の作業状況だと、コミュニケーションモードとして、コラボレーションモードでのコミュニケーションが必要な状況である程度のオーバーヘッドが許容される。
- 本来のデイリースクラムとしての活動は、前半15分。残り15分でその他の情報共有やタスク個別の成果物の確認を行なっている。
デイリースクラムのタイムボックス
現在のタイムボックス
私たちのデイリースクラムは、大まかに以下のような流れで進行しています：
-
GitHub Projectsのタスク確認 【10-15分】
- 前日から進捗のあったタスクの共有
- ブロックされている課題の特定と解決策の議論
- 本日取り組むタスクの優先順位付け
-
その他の情報共有 【10-15分】
- 他チームとの調整事項
- 上位マネジメントからの要求事項
- キャリア・スキル開発に関する話
-
個別タスクの状況確認 【5-10分】
- タスクの成果物の確認
- タスクの進め方の相談
タイムボックスに対するNotebookLMの洞察
タイムボックスに対してのアドバイスをNotebookLMにお願いしてみました。
#file-notebooklm-clip02-md
NotebookLMの回答で以下の部分は取り入れるべきかなと判断しました。
「その他の情報共有」（他チーム調整、マネジメント要求、キャリア・スキル開発） [User Query] は、別の短い同期ミーティングや非同期コミュニケーション（チャット、共有ドキュメントなど）に移せないか検討しましょう。これにより、デイリースクラムの焦点を「スプリントゴールの達成」 に絞ることができます。
GitHub Projects上でのステータス更新は、デイリースクラムの前に完了しておく、ミーティング中はボードを素早く確認し、課題や変更点に絞って話す、といった運用を試してみてください。
Notion DBへの報告に必要な情報は、Daily Scrumとは別の時間や担当者を決めて収集・更新するなど、報告プロセス自体を最適化することも考えられます。
チームサイズに対するNotebookLMの洞察
現在のチームは、最小人数である2名構成です。
このチームサイズについて、NotebookLMに質問をして洞察をもらいました。
#file-notebooklm-clip03-md
スクラムガイド2011にチームに関する記載があり、そこからの洞察になるかと思いますが、興味深い内容であるため、以下に引用します。
- 相互作用が少なくなる
- 生産性の向上につながらない
- チームの規模が小さいと、スキル不足が原因で、スプリントで出荷判断可能なインクリメントを届けられない可能性がある
デイリースクラムのふりかえり
以下、デイリースクラムのふりかえりになります。
「＋」良いと思っているところ
- 「＋」チームのミッションに向けての検査と適応の場にはなっていると感じている。
- 「＋」途中から1on1の要素も含む【その他の共有事項がそのような役割を持つ】。
- 「＋」簡易的なレビューの要素も含んでいる。
- 「＋」前職のデイリースクラムに比べると少人数、メンバーがシニアレベルということもあり、共有内容の情報が揃っている。
「▼」改善の必要がありそうなところ
- 「▼」タスクの粒度が大きいのか？デイリーでprogressのタスクが多くなっている。
- 「▼」スプリントゴール忘れることがある。
- 「▼」チームメンバーを増やしたい。【チームサイズが小さいことは、プロダクト全体への影響力が限定的になると感じている】
今後やっていくこと
- チームメンバーを増やす働きかけをする。
- キャリアに関する話す場を別で設ける。
- スプリントゴールを意識できるような、仕組みを検討する。
- デイリースクラムで会話するアジェンダを用意する。
- 他のチームにどのような働きかけをするか？をチームメンバーを議論する。
最後に
以前、1人で考えていた時に比べると、NotebookLMが議論相手として役立ちました。
ふりかえりについて、以前まとめたりしましたが、以下の記事を書いていたときと比べるとAI活用でふりかえりの観点注入が以前よりもできるようになったと感じます。
振り返り KPTの実施されないTryについて考える | Monotalk