#Sprint 4 いざ、アジャイルでスプリントを回す！（後編）
こんにちは、Yachiです。
前回は前編として、ユーザーストーリーを使ったプロダクトバックログの作り方や、スプリントプランニングでの見積りなど説明しました。
スプリントにおいて、計画を立てる要素が強いパートでしたね。
今回書く後編では、スプリントプランニングの実施後として、開発やデモを行ってスプリントを回すパートに入っていきます。
チームや顧客とのコミュニケーションやフィードバック、アウトプットやプロセスの改善など、日常的なオペレーションや改善のアクションについてポイントを絞って書いていきます。
☝“はじめてScramをやることになったら読む本！“という名のとおり、プロセスに沿って丁寧に書かれている良書。僕も最初Scramをやった時は、常に片手に持っていました。
1.デイリースクラムで、スプリントの状況を把握する
スプリントが始まれば、スプリントプランニングで出したタスクをチームで分担して進めていきます。
ですが、見積りどおりに進まないこともあります。機能の追加やバグの修正など、イレギュラーが発生するのは良くあることです。
また、スプリントプランニングにおいて、スプリントバックログをタスクに細分化しますが、タスク一つひとつにも重要度や前後関係があります。一つのタスクがボトルネックとなり、プロジェクト全体に影響を及ぼすこともあるのです。
このような問題をいち早く発見し、修正していくために行うのが、“デイリースクラム”です。
デイリースクラムは、その名の通り毎日15分程度で実施をするチームミーティング（日本的に言えば、朝会みたいなもの）です。
話すべき内容は、以下3つ。
①前回デイリースクラムからやったこと（前日にやったことの報告）
②次回デイリースクラムまでにやること（今日やることの予測）
③問題点
つまり、毎日定時にこの報告を行うことで、チームのアクション予測と実際のアクション結果のズレを測ることができ、そのギャップの原因を浮き彫りにさせることができます。
重要なのは、同時刻・短時間（15分）、ホワイトボードやJIRA（Atlassian社）などのボード（図1）を見ながら、3つの報告をインタラクティブに行うことです。
インタラクティブに行うのは、チームメンバー間で問題やTipsの共有を行い、単なる進捗報告会とならないようにするためです。
図1:JIRA（Atlassian社）のスクラムボード
「レビューまでに終わるの？」「どれくらい遅れているの？」「リカバリーできるの？」
このような詰問状態になってしまうと、開発チームは皆、デイリースクラムに臨む足取りが重くなってしまいます。
それに、“遅延こそ悪“という状況になり、プロセスやプロダクト上解決すべき課題に蓋がされてしいます。これは絶対に避けなくてはなりません！
とはいえ、遅延か否かは一目でわかるようにしておく必要がありますので、進捗状況はバーンダウンチャートで可視化（図2）したりします。
図2:JIRA（Atlassian社）のバーンダウンチャート。①スプリント内の見積り合計、②残りの見積り、③基準となるタスク進捗ガイドラインで構成。グレー線より赤線が上にあれば遅延の可能性が高く、下にあれば進捗予定を上回っていると判断する。
また、僕の場合ですが、上記3つの質問以外に、
・仕事の進め方やコミュニケーションに関する提言
・メンバーの予定（プライベート含む）や健康状態の共有
などを把握するようにしています（Scrumにおいては、メンバーが欠けることが致命的になりかねないので）。
15分という限られた時間ですので、予めボードにコメントを書き込むなど工夫をすると良いですね。
2.スプリントレビューで、プロダクトを確認する
スプリントレビューは、スプリント期間中に開発チームが作ったプロダクトをプロダクトオーナーが確認する場として行います。
プロダクトバックログの項目が依頼通りのものであると確認したら、“作業完了”とします。
ここでは、動作するプロダクトを実際に触ってもらうことが重要です。
スライドで説明をしても、要件を満たしているかイメージが付きづらいですよね。そうすると、後々プロダクトができた時に「イメージと少し違うな...」と、なりかねません。
手戻りリスクを避けるために、動作するプロダクトをレビューしてもらいましょう。
それでもレビュー時に、「ちょっと要求と違うのなあ...」「なんか反応がいまいちだったなあ」と、プロダクトオーナー・開発チームがそれぞれモヤモヤすることもあります。
そんな時は、プロダクトバックログを一緒に見返しましょう。
ユーザーストーリーとして書かれている内容が、プロダクトオーナーと開発チームとで共通の認識となっているでしょうか？なぜその機能が必要なのか、理由や意図が伝わっていますでしょうか？
この点の認識を擦り合わせると良いです。
Scrumのメリットは、要求を頻繁に確認しあえるところにあります。ですので、一度のレビューで認識がずれていても落ち込む必要はなく、何度もコミュニケーションをとることが必要です。
これまた僕の場合ですが、プロダクトオーナーの要求だけで伝わりづらい場合、実際のユーザーを読んでコメントをもらったりもします（可能な範囲で）。そうすると、リアルなコメントをもらえたり、利用シーンがより明確に伝わるからです。
また、プロダクトに対するレビューだけでなく、
・スプリント期間中に終わらなかったプロダクトバックログの確認・説明
・プロダクトバックログに追加する項目の検討
・プロジェクトを進めるうえでの問題点の確認
・リリースのタイミングの確認
これらの確認も行います。
そうすることで、プロダクトバックログの優先順位の見直しが行われ、次のスプリントにやるべきタスクが明確になります。
スプリントレビューは、1ヵ月のスプリントであれば3～4時間、2週間のスプリントであれば1.5～2時間とします。
3.レトロスペクティブ（振り返り）で、学習とチャレンジを繰り返すチームへ！
スプリントレビューが終わったら、うしっ、次のスプリントに入るぞー！
...ではなくて、このスプリントでのプロダクトやプロセスを検査し、改善策を考えましょう。
それが、スプリントレトロスペクティブ（振り返り）です。次のスプリントプランニングに入る前に行います。
ここでは、「何ができなかったか」が浮き彫りになるため、どうしても問題解決のためのイベントになりがちです。
ですが、スプリントレトロスペクティブの本来の目的は、次のスプリントでもっと良くするにはどうしたら良いか？もっと良いチームであるにはどうすべきか？を考えるところにあります。
改善点だけを見るのではなく、良かった点、難易度が高いけど次回にチャレンジしたい点なども挙げることが重要です。
この会議の位置づけによって、学習とチャレンジを繰り返せるチームになれるかが決まってきます。失敗を改善に生かせるチームにしなくてはなりません。
☝失敗から学習する組織とそうでない組織を科学的に解説。マネジメントや脳科学など、様々な観点で書かれているため分かりやすく、超実践的。
“KPT”（Keep：良かったこと、続けたいこと、Problem：問題、改善したいこと、Try：チャレンジしたいこと）、これらに整理して書き出すと分かりやすくて良いです。
それと、少し気を付けたいのが、ステークホルダーへの対応です。
レトロスペクティブやデイリースクラムの場に、上司やその他関係者が覗きに来ることがあります。チームで付箋を使ったりワイワイやっていると、どうしても目立ちますしね。
そんな時、黙ってみてくれれば良いのですが、アジャイルを理解していない人ほど口を挟んできます。WBSがないし、全体の進捗や進め方が分かりづらいですので、仕方ないですが。
そういった時は、事前に飛び入りの参加者に根回しして、話す時間が必要なのであれば時間を決めるようにしましょう（デイリースクラムで10分とか話されたら最悪！）
また、開発に直接関係のないステークホルダーの意見は、あくまで参考意見としましょう。そのように開発チームに伝えることも重要です。
そうでないと、外部の意見や差し込み案件（外部からの要求）に左右されて、Scrumチームとして成立しなくなってしまいます（図3）。ステークホルダーから身を守ることも、スクラムマスターの重要な役割です。
図3:スクラムチームとステークホルダーの関係を表すのが、この“ハムエッグの漫画“。鶏（ステークホルダー）は口を出すくらいだが、豚（スクラムチーム）は身を削って開発を行う。
ここまで、スプリントレトロスペクティブまでやって、1スプリントを回したことになります。
実際にやってみると、様々な不測の事態が起こるし、こんなに文字で残すほどスムーズにいかないことが殆どです。また、このようにお作法はありますが、柔軟に対応しなくてはならないこともあります。
それでも、型を覚えないと、型を破るということはできません。少しでも型の理解に役立てられたら嬉しいです。
4.まとめ
最後に要点をまとめます。
・デイリースクラムでは、毎日15分行い、チームのアクション予測と実際のアクション結果のズレを測りながら、ギャップの原因を浮き彫りにさせる
・スプリントレビューでは、動作するプロダクトを用いながら、プロダクトに対するプロダクトオーナーと開発チームの認識を揃える
・スプリントレトロスペクティブでは、“KPT”を明らかにすることで、学習とチャレンジを繰り返すチームを目指す
以上です。
振り返ってみると、やっぱりアジャイルの考え方はプロダクト開発だけでなく、プロジェクト型のジョブであればほとんどに応用が利くのではないかなと、改めて思いました。
“What is Agile?”というテーマでは、全4回と短編かつ要素は絞ってありますが、アジャイル（Scrum）のことが少しでも伝えられ、色々なシーンで活用してもらえたらと思います。
今後も、これからのデジタル時代の働き方や組織のあり方など、興味の範囲ですこしずつ書いていきます。
この記事が気に入ったらサポートをしてみませんか？