おはようございます、こんにちは、こんばんは、tarokenです。

今日はデイリースクラムについて話そうと思います。
デイリースクラムに関する記事もnoteにいくつか上がっています。あまりHOWな話というより、個人的にこれまでチームを見てきて色々と思ったり個人的にスクラムマスターとして振り返ったり、思考したりして来たので、それを垂れ流ししようと思います。ですので綺麗なHOWが知りたい方は別の記事を見ていただいた方がいいと思います。

尊敬

デイリースクラム10時からにしていて、10時に遅れてくる、すごいギリギリにきて、デイリースクラムを始める。皆さんはどう思いますか？

「イライラする」「別にいいと思う」「自分も遅れることある」「いつもギリギリで困ったことがない」さまざまな意見があると思っています。この事象に対してある人が「イライラする」と言ったところで、個人の意見をベースにすると「イライラする人がいるので皆さん、ちゃんと時間に来てください」となります。それだと学校の先生みたいですし、そもそもスクラムマスターは支援する立場ですので、「来なさい」ということは行動原理から離れる行為だと思っています。

もう少し別の角度から見てみたいと思います。スクラムには大切で重要な5つの価値基準があります。

チーム全員で決めた10時という時間に遅れてくる、もしくは毎回10時ギリギリにくる、ということは、例えばいつも10時よりずいぶん前にきて、今日の作業について段取りやリスクを考えて、次のステップをどうしようかと考えているチームメンバーの行動を尊敬している結果なのか？チームで集中して一つのことについて（デイリースクラムであればスプリントゴールに近づくことができるのか）話をすることができる状態なのか？という問いが生まれます。企業などで働く人たちは成人した大人であることがほとんどだと思います。他の人が「時間に間に合うようにしなさい」と言ったところで、「なぜ時間に間に合うようにしなければならないのか？」という事を解決できるわけではありません。もちろんこの「なぜ」を他人に求めるところも間違っているような気がします。

一方で「もしかしたら朝苦手なメンバーがいるのかもしれない」とチームメンバーのことを考えるという方向もあると思います。全体的に断定的な言い方になってしまっていますが、要はメンバーのことやチーム全体のためにそういった行動をしているんでしょうか、という問いになります。

だから「あなたはこの価値基準をベースにスクラムチームと一緒に仕事をしていますか？」の問いかけが必要なのだと思っています。それはデイリースクラムであっても、スクラムの中であればどの瞬間でも同じだと思っています。

スクラムマスターはその価値基準をチームに浸透させ、チームが真の信頼を勝ち取り、進めていくためにリードすることが必要だと思っています。

デイリースクラムの重要性

これ、なかなか一言で言えないんですが、いくつか感じたことがあります。まず、デイリースクラムは「開発者のためのイベント」であるということです。ここでプロダクトオーナーやスクラムマスターが出しゃばってはいけないと思っています。デイリースクラムの15分は開発者にとってとても重要なことだと考えています。

スクラムマスターは特にこのことを認識しないといけないと思います。「今日の業務連絡」とか言って、スプリントに関係ない事項を入れるのももっての外です。業務連絡はチャットでよろしく、です。

ところでデイリースクラムはなぜ開発者にとって重要なんでしょうか？

開発は毎日さまざまな不確定な要素と向き合い、その不確定な要素をクリアしながら、日々インクリメント（成果物：ソフトウェアコードやアプリケーション機能）を積み上げていきます。上手く不確定要素をクリアできる時もありますが、ない時の方がほとんどです（8割くらいは上手くいかない＝想定と違うと思います）

これらを今の自分たちの状況と照らし合わせて、「コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進」します。黄色信号でプロダクトオーナーにスコープの調整をお願いしなければならないかもしれないし、今日は少し残業する必要があるかもしれない。一方で嬉しい誤算で、想定よりもとても早く終わったので、今日はプレミアムフライデー（死語）になるかもしれない。

PBIの価値をインクリメントに変換する方法は、開発者にしかわからないはずです。だからこそ、そのインクリメントに変換する方法を検査、適応するためのミーティングは、価値提供に直結し、それらに対してプロダクトオーナーやスクラムマスターが直接的に口出しできるはずは無いと思っています。

スプリントプランニングとデイリースクラム

最近ようやくなんとなくですが、見えてきたスプリントの進捗に関する内容です。まず、前節の引用中に「プロダクトバックログアイテムを 1 ⽇以内の⼩さな作業アイテムに分解することによって⾏われる」とあります。今回「なんでわざわざ抽象化が多いスクラムガイドでPBIを1日以内の小さな作業アイテムに分解するなんて書くんだろう」という点に着目してみました。

そして最近チームに対して思っている「なぜPBIの受け入れがスプリント後半に集中するんだろう」という感覚も同時に沸いていました。ちなみにチームはPBIを1日以内の小さな作業にアイテムに分解していません。

沸々とずっと考えて来たんですが、この二つが改めてつながった感じがしています。

ちなみに「なぜPBIの受け入れがスプリント後半に集中するんだろう」ということについて、これ自体「なぜ後半に集中することがよく無いように書かれているの？」ということですが、割と単純に考えていて、後半（特に最終日）に集中することでPBIの順番（インクリメントにする優先度）が遵守できなくなる可能性があることと、プロダクトオーナーがスプリント最終日に休んだ場合、スプリントゴールが完結できなくなる可能性があること、というリスクがあるため、という意味合いであえて「よく無いこと」という表現をしています。

さて、では話を戻して、

1. PBIを1日以内の作業に分解する

2. PBIの受け入れが後半に集中する

この二つがどうやってつながっているのか、ということです。ズバリ、2の解決策が1ではないかという仮説です。

PBIを1日以内の作業に分解するとどうなるのか。チームは1日の作業の開始「デイリースクラム」で「優先度の高い順に今日終わるであろう作業」を自分たちで選択して実行していきます。翌日のデイリースクラムでは、前日に実施していたタスクが終わっているかを検査（終わっていないものはないか）します。そして終わってなかった場合、適応（対策考える）させます。

めちゃくちゃシンプルですが、ただこれだけです。

一方でPBIを1日以内の作業に分解していないとどうなるのか。チームは1日の作業の開始「デイリースクラム」で「優先度の高い順の作業」を自分たちで選択して実行していきます。翌日のデイリースクラムでは前日に実施していたタスクが終わっているか、検査できないんです。検査しようとしても、それは検査できないんです。PBIで見積もっているのはあくまで作業量であり、それが1日で終わる量、すなわち工数で見積もっていないのです。

そうなると、翌々日でも検査が不十分になり、結果的にズルズルと完成することが後半に伸びてしまいます。

結論

スクラムガイドにちゃんと書いてあるやんけ。