[スクラム]デイリースクラム・プロダクトインクリメントの定義と運用事例（2024 Advent Calendar 6日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の6日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

本記事ではデイリースクラムとプロダクトインクリメントの定義と自分たちのプロジェクトでの運用を紹介します。

デイリースクラム

デイリースクラムの定義

デイリースクラムはスクラムチーム全員が定期的に集まる場であり、朝会やスタンドアップミーティングと呼ばれることもあります。自分たちのチームでは毎日11:45から12:00までの15分間実施していました。みんな朝会と呼んでいたので以下では朝会と書きます。

朝会は一般的に進捗報告の場と考えられています。「昨日やったこと」「今日やること」を朝会で共有しているチームは多いでしょう。しかし、スクラムガイドによるとデイリースクラム（朝会）の主な目的は検査と適応です。では、その検査と適応とは具体的に何を指すのでしょうか。

デイリースクラムの目的1: 検査

朝会の検査とは進捗のチェックをすることです。自分たちのチームで進捗のチェックはバーンダウンチャートを使って行っていました。朝会実施時点で未消化のアイテムのポイントを合計し、前日より減っているか、変わらないか、増えているかを確認します。バーンダウンチャートについては「スプリント」の項目で説明をしたので詳細は省きます。スプリントで設定したバーンダウンチャートを朝会で更新するのです。

アイテムの消化が順調に進めばポイントは減る一方です。しかし、仮にスプリント3日目でポイントが18に増えていればメンバーの誰の目から見ても何かがおかしいことがわかります。するとスプリントプランニング時に想定していなかったことが明らかになったのだろうとメンバー誰もが気づけます。

ポイントが増えた場合、作業が終わりきらないためスプリントゴールを達成できなくなる可能性が高まります。もしゴールを達成できなくても誰かを責める必要はありません。その時は大きいアイテムを次のスプリントに持ち越したり、アイテムの中の一部のタスクの優先順位をさらに下げてリリース後に対応するなどの意思決定をします。

スプリントを実施すると毎日状況が変化します。この変化した状況の最新情報を朝会でチーム全員に共有するのです。これがデイリースクラムの検査です。

デイリースクラムの目的2: 適応

適応とは、デイリースクラムの検査で判明した新情報を元に意思決定をすることです。例えば、アイテムのポイントが見積もりより大幅に増えるとわかった場合にアイテムの優先順位を変更することを決めることです。また、アイテムが大雑把に書かれていることがわかったらきちんと定義してメンバー全員で認識を合わせるリファインメントを実施することを決めることも適応です。なお、リファインメントはデイリースクラムとは別の時間で午後に30分時間をとって開発者全員で実施していました。

主な適応はスプリントバックログに手を入れることです。チーム開発に不慣れな人は全員が見るスプリントバックログを自分が変更してもいいのだろうかと遠慮するかもしれません。しかし、一番やってはいけないことはスプリントバックログに最新状況を反映しないことです。

例えば「ある実装タスクを3ポイントとして当初見積もっていた。作業を進めていくうちに既存のコードのリファクタリングが必要であることがわかり、作業量は5ポイント相当と判明しました。しかし、リリースを遅らせたくないから自分が頑張って作業をするのでポイントは3のままで行きます」という態度です。

デイリースクラムは適応の場なので、ポイントが3から5に変わったとわかったらそれをバックログに反映させます。アイテムのポイントの増加はネガティブなことばかりではありません。タスクの着手によって、着手前より多くの情報を手にしたため不確実性が減ったのです。ポイントの増加にばかり目を奪われるのではなく、このことをこそチームで歓迎するべきなのです。現実は変えられないため、現実をベースにして次の手を考えていきましょう。

このように、デイリースクラムは他の人の進捗報告を聞くだけの場ではありません。デイリースクラムとは、スプリント実施中にアイテムにまつわる最新情報を共有して（検査）、次の意思決定をする（適応）という積極的なイベントなのです。

進捗報告の形骸化を打破する

自分たちのチームも当初は朝会を進捗報告と不安要素を共有する場だと考えていました。

朝会では前日の自分の仕事の内容とその日に着手することを各メンバーが順番に話していました。しかし、自分たちのチームではペア・モブプログラミングを採用していため、6人いる開発者のうちの半分は「ペアの人と同じことをやります」と話していました。また、開発者は全員Gatherを使って常にオンラインで集まっており、不安要素があればタイムリーに他のメンバーと相談をしていました。開発者同士は密にコミュニーションを取れているため、どのペアが現在何に着手しており何に詰まっているかお互いに知っていました。このため朝会は実質的にプロダクトオーナーとスクラムマスターに対する報告がメインになっていたのです。

すると他の開発者の進捗報告は「自分が知ってる内容なので聞き流してもいいかな」という雰囲気が蔓延し、何週間かそのような状況が続いていました。しかし、スクラム開発を始めて数スプリントたった頃のスプリントレトロスペクティブ（振り返り）であるメンバーがこう言いました。「スプリントバックログを見ればアイテムの進捗状況は一目瞭然だ。だから進捗確認はみんなでカンバン形式のバックログをサッと見るだけに留め、口頭での朝会の進捗共有を無くしたい」と提案しました。その提案はすぐに受け入れられ、チームは早速翌日の朝会から適応することにしました。

確かにFigJam上のスプリントバックログのアイテムには、それぞれ「Done（アイテムの完了）」「Check（タスクの完了）」「WIP」のステッカーが貼られています。さらに、各アイテムと各タスクには担当者のFigJamアイコンのスタンプが押されていたり、スプリント中に新しく追加したタスクには「New」のステッカーが貼られていました。

（画像を貼る）

アイテムの進捗を示すマークをつけるタイミングは朝会でした。口頭で進捗を共有しながらステッカーを貼っていたのです。しかし口頭での進捗共有をなくしたため、各メンバーは朝会まで待たずにアイテムやタスクが完了したタイミングでFigJamをタイムリーに更新するようになりました。その結果、口頭での進捗共有という形骸的な儀式を無くして朝会の時間を短縮できた上に、スプリントバックログが常に最新の状況を反映するようになったのです。

この時はスクラムを始めて3ヶ月しか経っていませんでしたが、あらゆるスクラムイベントの中で最初の時点と比べて朝会（デイリースクラム）が一番ブラッシュアップされました。ここでは一番大きな変化だった進捗の共有方法のみを紹介し、他の有意義な変化はスプリントレトロスペクティブの項目で紹介します。

プロダクトインクリメント

プロダクトインクリメントの定義

プロダクトインクリメントとはスプリントの成果物を指します。具体的にはスプリントの中で完了したアイテムとプロダクトの進化した部分のことです。あるスプリントの成果物を前回スプリントの成果物に追加することで、成果物が増えてプロダクトは成長します。

インクリメント（increment）は増加という意味の英単語です。プログラミングでは特に「値を1増やす」という意味で、0を1に、1を2にというように値を一つずつ増やすことを指します。スプリントが完了するたび着実に成果物が一つずつ増えていくことを表現するためにプロダクトインクリメントという言葉が選ばれたのでしょう。

プロダクトインクリメントの運用

具体的なインクリメントはスプリント中に完了したアイテムであると述べました。プロダクトバックログのアイテムは誰が何をできるようになるというユーザーストーリーの形で記述します。自分たちのチームでは、アイテムの作成と同時にアイテムの完了条件をあらかじめ決めました。アイテムの完了条件を決めるのはプロダクトオーナーの役割です。完了条件を先に決めることで、そのアイテムの完了、未完了を適切に判断できます。

自分のいるチームでは、この完了条件に細かい仕様や挙動を記述していました。例えば、XXX というユーザーストーリーのアイテムがあるとき、完了条件は1.YYY、2.ZZZとするというように。

開発者が機能を追加するだけではアイテムの完了とはいえません。開発環境にデプロイをしてプロダクトオーナーが実際に動作確認をできるようにします。自分たちはプロダクトオーナーによる動作確認を受け入れテストと呼んでいました。この受け入れテストをパスしたら本番環境にデプロイをします。本番環境でも問題が発生しなければアイテムのステータスを完了としました。

なお、スプリントが終わった時点で完了条件を達成できなかったアイテムはプロダクトバックログに戻します。その後リファインメントで他のアイテムと優先順位を比較し、改めて次のスプリントで着手を続けるかプロダクトオーナーが判断をします。

スプリントバックログアイテムとスプリントレビューはプロダクトインクリメントと密接な関係を持ちます。開発の観点からは、プロダクトに新しいインクリメントを追加するにあたって過去のインクリメントを壊していないこと、つまりデグレが起きていないことが重要です。スプリントレビューでは、これまでに達成した全てのインクリメントをステークホルダーに披露するからです。前回のスプリント終了時点で出来なかったことが今回のスプリントで出来るようになることは当たり前です。しかし、前回出来たことが今回出来なければステークホルダーは失望するでしょう。このため、自動テストを書いてCI環境を整備してデグレが起きたら素早く見つけられるようにします。

良いスクラムチームは出来ないことを出来るとは言いません。スプリントレビューでは、あるアイテムの調査や開発が完了しておらずインクリメントとして扱えないときには「ここは完了していません」とステークホルダーに伝えましょう。そして出来なかった合理的な理由をステークホルダーに説明できればきっと納得してくれます。誇大広告的に10のものを100だと言わず、10のものは10以上でも10以下でもないとステークホルダーに伝え続けましょう。するとチーム外部のステークホルダーの人たちに、このチームは嘘をつかないし隠し事をしないと思って貰えます。結果的に、スクラムチームとステークホルダーの間で長期的な信頼関係を築くことができるのです。

開発者にとってプロダクトの内部品質の維持は重要です。スプリントレビューに間に合わせるためコードを汚く書いてさっと動くものを作ってアイテムを完了させて、それをインクリメントとした場合があるとする。早く綺麗なコードを書くことが実は一番早いと言われているが、事情が許さずどうしても一時的に汚く書かざるを得ない時はあるでしょう。そのような場合はプロダクトオーナーに掛け合って次のスプリントをリファクタリングから始めるのが良いでしょう。そうでないと質の悪いコードが足を引っ張るはめになり、長期的にはベロシティの悪化に繋がってしまう。質とスピードは両立するのです。

次回はスプリントレビューついて説明します。