この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の7日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者はプログラミングをするパンダです。
スプリントレビュー
本記事ではスプリントレビューの定義と自分たちのプロジェクトでの運用を紹介します。
スプリントレビューの定義
スプリントレビューとはスプリントで作成したインクリメントをチーム外のステークホルダーに披露して、プロダクトについてフィードバックを貰う場です。
特に、ソフトウェアの場合は開発者が操作して説明するデモやプロダクトを見せずにスライドだけで完結するプレゼンではありません。ハンズオン形式でステークホルダーが実際にソフトウェアを操作することが重要です。これにより現段階でプロダクトの可能なことと不足していることについて、スクラムチームとステークホルダーの間で認識を揃えることができるのです。
包括的なドキュメントではなく動くソフトウェアに価値を置きましょう。ステークホルダーは自分の手でプロダクトを操作することで開発の進捗を自ら把握できます。プロダクトを操作してステークホルダーが得た気づきは、スクラムチームに対してより深いフィードバックになるでしょう。
一般論として、開発チームとステークホルダーの関係が疎遠であれば頻繁に交渉が発生してしまいます。しかし、スクラムチームはスプリントレビューを通してステークホルダーと交渉ではなく対話をするのです。この対話にはステークホルダーがチームにフィードバックをすることやスクラムチームがステークホルダーに相談や提案をすることも含まれています。スプリントレビューではプロダクトを中心に据えることでヒトではなくモノとコトに集中するため、健全な対話と健全な議論を推進できるのです。
チームはスプリントレビューで得たフィードバックをもとに、次のスプリントで着手するものを決めます。スプリントレビューはプロダクトのフィードバックサイクルの起点であり、このサイクルがプロダクト開発の好循環を産むのです。
チーム内外で対立・交渉するのではなく対話をすること。プロダクト開発では方向性の変更はつき物ではあるものの、スプリントレビューでチーム外の人も巻き込んで話し合うことで突発的で大きな方向性の変更を防げます。つまり、適切なスプリントレビューはいわゆるメテオフォールの防御壁にもなるのです。
スプリントレビューの運用
運用のポイント1: ユーザーインタビューの手法でフィードバックを集める
自分たちのチームではスプリントレビューでユーザーインタビューの手法を採用しました。当時開発していた機能は社内で新設されたビジネスチームのためのものです。このため、完成した機能を実際に利用するビジネスチームの方々をレビュワーとして毎回レビュー会に参加してもらっていました。自分たちの顧客は社内にいたのです。
レビュー会はスプリント終わりにZoomで1時間実施していました。参加者はプロダクトオーナー、スクラムマスター、開発者のスクラムチーム全員と社内のステークホルダーです。
レビュー会の前にはプロダクトオーナーがプロダクトの操作シナリオを準備していました。シナリオはある操作に成功したり、失敗したら何らかのエラーメッセージを出すパターンを用意します。テストアカウントやファイルアップロードなどデータセットが事前に必要であればプロダクトオーナーが併せて用意します。
スプリントレビューの内容は以下のとおりです。ビジネスチームの側の参加者でありプロダクトを操作する方を以下ではここではAさんと呼びます。
まずプロダクトオーナーがAさんに操作シナリオとゴールを簡単に説明します。シナリオは「ログインする」「Xをアップロードする」「Yを登録する」のように方向性だけを共有します。どのフォームに何を入力してどのボタンをクリックするといったような細かい手順はあえて伝えません。
AさんはZoomで自分のパソコンの画面共有をして手元の操作が見えるようにします。また、Aさんは操作中に頭の中で考えていることを全て声に出して貰うようにプロダクトオーナーが依頼します。Aさんはプロダクトオーナーのシナリオ通りに操作を進めてもらいます。Aさんが次のアクションに迷っている様子を見せても「下のXボタンをクリックしてください」といった答えをすぐには伝えません。チームメンバーはAさんを一定時間観察して、本当に詰まれば次の操作を伝えます。
議事録にGoogle Documentを使っていました（今であればNotionを使います）。スクラムチームは、Aさんの操作画面を見ながらのGoogle Documentの同時編集機能を使って気づいたことをメモしていきます。メモの内容はAさんの操作を観察して得られる、プロダクトの改善に繋がる洞察です。例えば「Aさんがボタンクリック前に迷っていたので、ボタンを上に持ってくるといいかも」や「エラーメッセージを見ても次に取るべきアクションが伝わっていなかったので、メッセージを変えた方がいい」などのコメントです。
Aさんの操作が一通り終了したら、プロダクトオーナーが他にも操作してみたいシナリオがあるかAさんに質問します。もしあれば、そのシナリオに沿ってまた操作をしてもらいます。
操作が全て終了した後に、Aさんからフィードバックを貰います。ポジティブな言葉は開発チームのモチベーションになるためただの感想でも良いですし、ここを変えてほしいという具体的な要望でもチームにとっては嬉しいものです。このタイミングで出てくるAさんの改善要望には明確な根拠があり、その根拠は操作画面を見ている中でチーム内に共有されているからです。「もしユーザーが実際に操作したらここが不便になるんじゃないかな」という推測ではなく、実際に不便だった点が具体的に改善要望として上がってくるのです。
開発チームにとって一通り開発が終わったと思った箇所の改修は腰が重くなるものです。しかし、自分たちが作った機能を目の前で使いづらそうに操作しているAさんを見ると、むしろ「早く修正したい」という気持ちが沸き起こってきます。スプリントレビューはプロダクトをさらに良くしたいという次のスプリントのエネルギーにもなるのです。
レビュー会の最後にはスクラムチームが取ったメモをAさんにも見てもらいます。Aさんにはチームからのプロダクト改善に対する各提案を「開発してほしい」「どちらでもいい」「開発しなくても良い」の3段階に振り分けてもらっていました。
「開発して欲しいもの」と「どちらでもいいもの」はプロダクトバックログにアイテム化をします。プロダクトオーナーはプロダクトバックログリファインメント時に、前者の優先順位を高めに、後者は低めに置くことが多かったです。チームからの改善提案で「開発しなくてもいいもの」を振り分けることも重要です。ユーザーにとって無駄な開発を避けることができ開発工数をいくらか少なくできるからです。チームメンバーが頭の中で構築した根拠の薄いユーザー像ではなく、目の間にいるユーザーの声を直に取り入れることこそが重要なのです。
総じてレビュー会の効果はスクラムチームがゴールを設定しやすくなることです。ビジネス側から「最低限の機能でいいから早くリリースして欲しい」という要望があれば、その最低限の内容についてステークホルダーと認識を合わせられます。するとチームメンバーが「最初からもっと良いものができるのではないか（しかし、良いものの定義は曖昧）」「他にも機能が必要ではないか（しかし、何の機能さえあれば十分という答えを持っていない）」という不安からくる開発工数の増大の懸念を払拭できます。
自分たちは本当に必要十分な機能を作っているのだという自信を持って開発作業にに集中した結果、ステークホルダーが期待した以下のものでもなく過剰だと思うものでもなく、期待通りのものを出すことができるのです。これこそがスプリントレビューにおけるチームの垣根を超えた理想のコラボレーションです。
運用のポイント2: ビジネスチームの新しいワークフローの構築を手伝う
機能の利用者であるビジネスチームにレビュー会を通して開発チームから進捗の共有ができただけではなく、開発チームもビジネスチームの準備状況を知ることができました。以下ではレビュー会がビジネス側のワークフロー構築に役立てたというエピソードを紹介します。
社内チームの新しい仕事のワークフローではスプレッドシートを使ったり外部のSaaSを使ったりもします。メールで社外の人とやり取りをすることもあれば、新しい機能を使って作業をした後、他の人に「次の作業に進んでください」とSlackで報告することもあります。
これまで述べたようにプロダクトオーナーはレビュー会で新機能の操作を中心にシナリオを考えていました。しかし、実際にビジネスチームの方が手を動かしているところを見ていると、開発チームに「新機能を使う前後には何をするのか」という疑問が自然に持ち上がりました。開発が初期段階のあるレビュー会でチームメンバーがその質問をすると、なんと前後の業務フローがまだ決まっていないことがわかったのです。
会社の名誉のために書いておくと、当時開発していたのはビジネス側で新設されたチームが使う新機能でした。新チームなのでもちろん会社として初めての仕事です。ゆえに過去の手順を参照することもできず、誰かが業務フローを一から考えなければなりません。そのチームの部署が発足したばかりで、仕事のやり方を決めるところまで手が回っていなかったのです。
もちろんワークフローはリリース日までに余裕を持ってしっかり整備されました。開発初期のレビュー会で未整備だったワークフローが、レビュー会を重ねるごとに順次整備される様子が開発チームにも伝わってきました。スクラムチームが「この時はどうしますか」と業務フロー上で未確定の事項を質問をすると、「これはまだ決まっていないです。次のレビュー会までに決めておきます」とビジネスチームの方が回答するというケースが何度かありました。ビジネス側での視点の抜け漏れを開発チームが補えたのです。また、ビジネス側に情報が足りず判断に困る場合は、プロダクトオーナーが適宜話を聞いて彼らの意思決定に必要な情報を伝えていました。
ビジネス側のワークフローが整備されるにつれて、プロダクトオーナーはレビュー会の操作シナリオをアップデートしていました。誰かから作業依頼が来ることをきっかけに作業を始めることや作業の完了報告をするといった機能外のアクションもフローに含めたのです。
スクラムチームはレビュー会で新機能の使われ方を見る一方で、ビジネス側で作業フローが構築されているかも見ていました。その結果、レビュー会はスクラムチームがそのスプリントの成果物であるインクリメントをビジネスチームを含めたステークホルダーに見せてフィードバックをもらうだけでなく、ビジネス側のワークフローの構築を促進することにもなったのです。
運用のポイント3: セキュリティチームと協力して「情報セキュリティのシフトレフト」を実現する
DevOpsのプラクティスに「情報セキュリティのシフトレフト」というものがあります。ここでいうレフトは時間軸の左側です。つまりこのプラクティスはセキュリティ面を開発の最後に考慮するのではなく、開発の初期段階から考えておくことを奨励するものです。
自分がいたチームでは開発初期から実現は出来なかったものの、開発の中盤からこれを実践できました。4月は仕様策定と技術調査がメインの月でした。4月の終わり頃に、どうやら社内のセキュリティチームに相談したり確認することが必要らしいことがわかってきました。また個人情報を扱うため法律面の懸念点が出てきたため、チーム内から法務にも確認が必要だという意見が出てきました。
そこですぐにプロダクトオーナーがセキュリティチームと法務チームに確認・相談のミーティングを設定して疑問を解消することになりました。普通の開発なら単発か数回のミーティングで終わらせてしまっていたでしょう。法務に対する確認は実際それだけで十分でした。
しかし、このミーティング時点ではビジネス側のワークフロー整備がまだ完了していませんでした。このためセキュリティチームはこちらから依頼した新機能の懸念点の洗い出しに加えて、ビジネス側のワークフローも一緒に確認したいという意見を出してくれました。
そこで5月のレビュー会からはセキュリティチームの方々にもステークホルダーとして参加してもらうことになりました。セキュリティチームはレビュー会で新機能に対する開発面での懸念と、作業のワークフロー全体の懸念点をスクラムチームとビジネスチームの両方に伝えてくれました。レビュー会のたびにビジネスチームがセキュリティチームの懸念を一つ一つ潰す対応をすることにより、整備途中であったワークフローがセキュリティリスクを低減したものにブラッシュアップされていきました。
例を一つ挙げると、ビジネス側の方はその作業専用のPCを用意して必ず会社でその操作を行うことに決まりました。もしセキュリティチームがワークフローのレビューをしなければ、ビジネスチームは個人支給のパソコンで作業を行なっていたかもしれません。セキュリティリスクを低減できた良い例です。
開発チームはセキュリティチームが開発における懸念点として出してくれた項目をプロダクトバックログに載せるアイテムとしました。大まかにリリースまでに対応が必須なアイテムとリリース後に対応するアイテムに分けて、リファインメントで対応の優先順位を決定しました。これによりアイテムが増えてリリース日は少し伸びたものの、セキュリティ対応は必須だと全員が認識していたため、ビジネスチームもリリース日が伸びたことを納得していました。
プロジェクト全体の振り返りで「4月の仕様策定段階からセキュリティチームに相談できればベストだった」みんなで話し合いました。それでもリリース直前の突発的な対応ではなかったので急にリリースを延期することもなく、事前にセキュリティ対応も工数に含めたリリース日を改めて算出できていました。セキュリティ対応という不確実性を開発途中で折り込み済みにすることができたのです。
このようにして、スプリントレビューにセキュリティチームも参加してもらうことで「情報セキュリティのシフトレフト」を実現できたのです。
運用のポイント4: スプリントレビューからインシデントの予行演習実施へ
レビュー会の副産物として、機能のリリース2週間前にインシデント発生時の予行演習を実施することになりました。この段階で開発は大方完了し、初期リリースに必要なアイテムが残り僅かになったため、一連の作業フローを実行する準備が整ったためです。
当日は通常1時間のレビュー会を2時間に延長し、スクラムチーム、ビジネスチーム、セキュリティチームに加え、CS（カスタマーサポート）チームにも参加してもらいました。セキュリティインシデントが発生した際の対応フローは事前にプロダクトオーナー、ビジネスチーム、セキュリティチームで策定し、法務チームにも共有済みでした。この対応フローに抜け漏れがないか確認するため、関係者全員がこのインシデントの予行演習に参加しました。
プロダクトオーナーがシナリオを準備し、各メンバーに役割を割り当てました。開始時間になると、インシデント発生を想定したSlackチャンネルを作成し（もちろん予行演習とわかる名前を付けました）、参加者はドキュメントに記載されたインシデント対応フローに基づいて行動しました。
社外秘のため実施内容の詳細は書けませんが、これは非常に有意義な時間となりました。特にこれまでのレビュー会を通してチーム内外ですでに交流があったことや、CSチームの顧客第一の姿勢も相まって、どのチームも必要な訓練として前向きに取り組んでくれました。この取り組みはスクラムの集大成だといえるでしょう。
訓練の一場面を紹介します。ビジネスチームのAさんは、想定されるインシデント内容を社内のCSチームに電話で説明し、謝罪しました。当初は「はい、ここで謝罪を行いました。次に進みます」と適宜省略しながらシナリオを進めるものと考えていました。しかし、Aさんは実際に電話をかけ、顧客役のCSチームの方に謝罪と説明を行いました。AさんはSlackのハドルでエンジニアに共有しているので、エンジニアはカメラとスピーカー越しに謝罪の様子がわかります。
それまでエンジニアたちは「事前に何重も対策をしているから、滅多なことではこのインシデントは発生しないだろう」と考えていました。しかし、現実にインシデントが起きたかのように心底申し訳さそうに謝罪を続けているAさんの姿勢は迫真の演技どころではありません。電話の受け手のCSチームの方も個人情報が漏洩していまった顧客になりきって、言葉を選びながら静かに怒っていることがわかるやり方でAさんを質問攻めにしています。
息を呑んで二人の電話のやり取りを聞いていたエンジニア全員が「このインシデントは本当に起こしてはいけない。そのような重要な機能の開発に自分達は関わっているんだ」ということを改めて認識できた。開発内容の重要性と責任をエンジニアたちが強く認識する機会となったのです。
ビジネスチームのAさんの真剣な謝罪を、たまたま社内で耳にしたCTOが「重大なセキュリティインシデントが発生してしまった。もう終わりだ…」と青ざめてしまったと後から聞きました。今では笑い話ですが、単なる演習であっても社内の多くの方に実施を共有しておこうとチームで反省をしました。
次回からは2回にわたってスプリントレトロスペクティブの説明をします。
画像