はじめに
スクラム開発をやっているとうまくいかないことが山ほどありますよね！
そんなとき、あなたならどうしますか？
私の場合はスクラムに関する書籍を読んだり、周りの人に相談して同じような失敗をどのように切り抜けたかを質問することが多いです。
でも書籍を読むのは時間がかかりますし、周りで同じような失敗をしている人がなかなか見つからないことも多いですよね！
そこで今回は私の経験したうまくいかなかったことと、それを切り抜けた方法について共有させていただきます。
今回の「しくじりあるある」に挙げたケースはいずれも私のチームで実際に起きたことですので、少しでも参考になれば幸いです。
要約
書き上げてみると割と長い記事になってしまいましたので、忙しい方向けに大事な部分だけをまとめます。
- あるある1. デイリースクラムが形骸化してしまった
- 対策. アジェンダを見直してバーンダウンチャートを見てから各SBIの状況を確認しよう！
- あるある2. バーンダウンチャートが形骸化してしまった
- 対策. SBIは優先度の高い順に最速でDONEできるように計画しよう！
- あるある3. 見積もりの精度が悪く、SBIをDONEできずに落としてしまう
- 対策. 実際の作業に関わるリソース（ソースコードやドキュメントなど）を見ながら作業イメージのすり合わせを行おう！
お時間がある方は引き続きそれぞれの詳細についてご紹介しますので、読み進めていただけると幸いです。
あるある1. デイリースクラムの形骸化
毎朝のデイリースクラム（以下DS）がこんな風になってしまってはいないでしょうか？
スクラムマスター(以下SM)「おはようございます。今日も朝会を始めていきましょう！それではAさんから順番に、昨日やったこと、今日やること、何か課題があれば共有をお願いします」
Aさん「昨日は◯◯の実装をやっていました。今日は引き続き実装を進めます。特に課題はないです。」
Bさん「昨日はXX案件の機能試験書を書いていました。今日も引き続き機能試験書を書きます。特に課題はないです。」
：（以下同様の報告がチーム全員分続く）
SM「はい、特に課題や問題はなさそうですね！では今日も一日よろしくお願いします！」
・・・
さて、いったい上記の流れのどこに問題があったのでしょうか。詳しく考えていきたいと思います。
問題点. DSの目的を忘れ、テンプレ通りのやりとりしかしていない
問題について考えていく前に、スクラムガイド2020日本語版の「デイリースクラム」のチャプターから、DSに関する記載についておさらいしておきます。
デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
そうなんです。DSにおいて重要なのは今朝時点の進捗確認ではありません。
チームの現状を整理し、今スプリントはこのままの調子でスプリントゴールを達成できそうなのか？
現在進行しているスプリントバックログ（以下SBI）のうち、優先度の低いSBIを担当しているメンバーにより優先度の高いSBIのサブタスクに入ってもらうほうがスプリントゴール達成の可能性が上がるのではないか？
最も優先度の高いSBIのうち、並列で進められるサブタスクはないだろうか？
そんなことを確かめることこそがDSの目的なのです。
各メンバーが自分の担当するSBIの進捗を気にすることは自然なことですが、本来はそれがスプリントゴールの達成においてどのような位置づけ、意味合いであるかまで含めて意識する必要があります。
SMはDSにおいて、メンバーがスプリントゴールを意識し、現状と比較した上でそれぞれがどのSBIを進めるべきか考えられるように促す必要があります。
では具体的にどのようなDSを行えばスプリントゴール達成に向けた効果的な情報共有ができるのでしょうか。
対策: アジェンダの見直し
正解はありませんのであくまで一例となりますが、私のチームでは以下の内容にアジェンダを見直しました。
（※チームの状況に応じて、現在でも定期的に見直しを行なっています）
1．全体周知（当日の勤怠や不在予定の確認など）
2．今スプリントのTryの取り組み状況確認
3．バーンダウンチャートの確認
4．各SBIの状況確認および本日進めるサブタスクの担当者決め
5．スクラムオブスクラムズへ持っていく情報の確認
6．クロージング(共有漏れの確認など)
上記のアジェンダのポイントは3と4にあります。
バーンダウンチャートでそのスプリントに対する現在のタスクの進捗状況を検査しつつ、
理想との乖離があった場合は次の各SBIの状況確認でその原因を特定するという流れです。
想定外事象の発生などにより進捗が遅れたり、技術的課題が発生した際にはデイリースクラムが数分長引いてしまうことがありますが、
スプリントゴールの達成に向けて全力を尽くしたと言える自信が持てるようになりました。
デイリースクラムが時間内に完了できない状況が継続した場合、二次会やパーキングロットの活用を検討するべきでしょう。
なお、私のチームでは過去にバーンダウンチャ－トが形骸化してしまうことがありました。
それをどのように乗り切ったのかについても、次の章で解説しようと思います。
あるある2. バーンダウンチャートが形骸化してしまう
皆さまのチームでもバーンダウンチャートを一度は使ってみたことがあるのではないでしょうか。
※ここでの「バーンダウンチャート」は「スプリントバーンダウンチャート」を指すものとします。
実は私のチームでは過去に一度バーンダウンチャートの利用をやめてしまったことがありました。
その理由は以下のようなバーンダウンチャートが続き、利用している意味がなくなってしまったためでした。
以下の図は2週間スプリント（スクラムイベントを除き作業可能日数が7日のケースを想定）を適用しているふわふわチームにおけるバーンダウンチャートのイメージです。
これと同じような事象が起きて困っているチームや、それが原因でバーンダウンチャートはやめてしまったよ、という方もいらっしゃるのではないでしょうか。
まるでナイアガラの滝のようですね。
これではスプリントの前半や中盤での各SBIの進捗状況が全くわかりません。
どうしてこのようなことが起きてしまうのか、どうやったらバーンダウンチャートが機能するのかを詳しく考えてみます。
問題点. SBIの優先度が定まっていない or 優先度に従って進められていない
バーンダウンチャートが機能していない場合、まず疑うべきはこれです。
先述のナイアガラの滝のようなバーンダウンチャートになってしまう場合、内部的には以下のようなことが起きているはずです。
なお、以下のイメージにおいてはSBIの数字が低い方がより優先度が高いと思ってください。
4名のエンジニアのチームの想定ですが、スプリント初日からSBIの優先度に関係なくWIP4で作業が進んでいることがわかります。
これではバーンダウンチャートがナイアガラの滝状態になってしまうのも納得です。
さらによく見ていただけるとわかるかと思うのですが、
最も優先度の高いバックログ1よりも先に優先度が相対的に低いバックログ2やバックログ4がDONEしています。
これでは何のためにスクラム開発を採用しているのかがわからなくなってしまいます。
また、少し別の観点でも考えてみたいと思います。
先ほどの図における3日目のバックログ1で技術的課題が発生し、
担当者の佐藤さん以外のメンバー全員が次の日から丸2日分バックログ1のサポートに入ったケースについて考えてみましょう。
すると、以下の図のようなことになります。
優先度の最も高いSBIの技術的課題解消のためとはいえ、バックログ3をDONEできずに終わってしまいました。
それもそれより優先度の低いバックログ4はDONEできているにも関わらずです。
また他のSBIについても軒並みスプリントの最後の方にギリギリDONEできているという状況です。
これではあまり健全な状態とは言えませんね。
さて、このような状況を回避するためにはどうしたらよいのでしょうか。
次の「対策」の項目で私のチームでの実績を解説したいと思います。
対策. SBIは優先度の高い順に最速でDONEできるように計画する
私のチームではSBIの優先度の高いものから最速でDONEできる人数やメンバーを割り振っていき、
それ以上は人をかけても1分、1秒でも早くDONEできないというところから次に優先度の高いSBIに入ってもらうようにしました。以下の図のようなイメージです。
バックログ1を最速で進めるために鈴木さん、佐藤さんに入ってもらい、誰が入ってもそれ以上早く進めることはできないと判断しました。
そしてバックログ2には残りの井上さんと高橋さんに入ってもらうことになりました。
バックログ1の方が先に完了したため、次に優先度の高いバックログ3に鈴木さんと佐藤さんが入ることになりました。
次にバックログ2を担当していた井上さんと高橋さんの手が空きましたが、バックログ3の状況を確認するともう１人入ることでより早くDONEできそうだということが判明したため、
井上さんもバックログ3に入ることになり、残った高橋さんがバックログ4に入ることになりました。
（バックログ3がDONEした時点で高橋さん以外のメンバーもバックログ4に入ってもらう想定です）
この進め方をした場合のバーンダウンチャートは以下のようになります。
このようなバーンダウンチャートであれば、スプリント3日目には順調なのかそうではないのかがパッと判断できますね。
さて、ここで先ほど同様にバックログ1において技術的な課題が発生した場合の動きを考えてみますと、以下の図のようになります。
先ほどと同じように技術的課題の解決にはメンバー全員の2日分の工数を要したとします。
基本的な動きは先ほどと同じでSBIの優先度に従って必要な人員で進めていくのですが、
技術的課題解決のために計画外の工数が必要となったため、すべてのSBIをDONEすることはできませんでした。
ただし、ここで重要なことはそれでも落としてしまったSBIは最も優先度の低いものであるということです。
また、最も優先度の高いバックログ1をDONEした日付に着目してみると4日目にはDONEすることができています。
サービス観点で絶対に落とすわけにはいかないSBIをスプリントの中盤でDONEするか終盤にDONEするかではかなり状況が変わってきます。
あるある3. 見積もりの精度が悪く、SBIをDONEできずに落としてしまう
プロダクトバックログ（以下PBI）のリファインメントに関する「しくじりあるある」です。
そもそも皆さまのチームではPBIのリファインメントをどの粒度で行なっているでしょうか。
あるPBIのストーリーポイントを事前のリファインメントでは5ポイントだと見積もったが、実際に作業を進めてみると想定していなかった作業が必要で10ポイント相当だった
そんな経験はありませんか？この見積もり精度の低さを改善するにはどうしたらよいでしょうか。
問題点. 見積もる対象の具体的な内容を把握できていない
スクラムガイド2020日本語版にはPBIのリファインメントについて以下の記載があります。
スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を⽀援することもできる。
「作業を行う開発者は、その作業規模の評価に責任を持つ」と明記されています。
スクラムにおいて作業規模は人日や人月等の時間ベースの見積もりではなく、作業ボリュームをTシャツサイズやストーリーポイントに置き換えて数値化するやり方が一般的です。
この時に見積もりの根拠となるのが過去に行なった作業です。
例えばある架空のプロダクトがあり、会員登録機能を提供するために必要な一連のバックログの見積もりの合計が10ポイントだったとします。
そこに対して今回の対応はその半分くらいの規模なのか、同じくらいなのか、それ以上なのかと相対的に数値を算出します。
実際に見積もる対象の具体的な内容のイメージができていれば、先ほどの会員登録機能との比較も容易に出せることでしょう。
ところが開発メンバーの中でもスキルの違いやプロダクトに携わってきた経験の違いから、同じインプットを受けてイメージする作業内容に大きな差分があったりします。
それではどうすればスキルや経験といった前提知識の違いがあっても、見積もりの精度を上げることができるでしょうか。
対策. 実際の作業に関わるリソース（ソースコードやドキュメントなど）を見ながら作業イメージのすり合わせを行う
私のチームではソースコードやドキュメントを見ながら具体的な作業イメージを膨らませながら見積もりを行うことで見積もり精度が改善されました。
例えばあるプロダクトで新規顧客獲得に向けたLPを新規で追加する案件があったとして、
サブタスクに「1.実際の画面の実装」「2.UT」「3.サービス仕様書の更新」「4.STGリリース」「5.商用リリース」の5つがあったとします。
フロントエンドに明るくないメンバーからすると、画面の実装やUTの実装がどれくらいのボリュームになるのかはあまり想像がつきません。
一方でこれまで何度もフロントエンドの案件を対応してきたメンバーからすると、「あぁ、この要件と画面仕様であれば以前に対応したあの案件と同じくらいだから8ポイントくらいかな」とかなり具体的なイメージを持つことができているはずです。
この時このメンバーが頭の中でイメージした過去の案件の実際の作成物（ソースコードやサービス仕様書）を他のメンバーにも具体的に見せればよいのです。
この工程を踏むことで実際の作業をしたことがないメンバーについても作業内容の具体的なイメージを持つことができます。
その後に見積もりを行うことでメンバー間の前提知識の違いによる見積もり誤差はなくなるはずです。
逆にこのすり合わせを行わない状態で見積もりを行うと、自分の出した見積もりに自信がないからと他のメンバーの見積もりに自分の見積もりを寄せてしまうという事象が発生しやすくなります。
これでは複数メンバーで見積もりを出している意味がなくなってしまいます。
おわりに
今回は私が実際に経験し、乗り切ってきた「スクラムしくじりあるある3選」について解説してみましたが、皆さまのチームの参考になりそうな「あるある」はあったでしょうか。
あくまでも私のチームでの事例となりますが、少しでも参考になれば幸いです。
また「こんなケースはどのように乗り切ったか？」などご要望があれば別の機会に解説させていただこうと思いますので、ぜひコメントをいただけると幸いです。