スクラムマスターに聞いた、スクラムチームの1週間　社内システム開発③

スクラムはアジャイル開発の手法の一つ

―――まず、スクラムについて教えてください。スクラムとは、アジャイル開発を進める手法の一つだと認識しています。

はい。そもそもアジャイル開発は、プロジェクトの中でも不確実性の高いプロジェクトに有効です。
ウォーターフォール型では、やることが段階的に決まっていて、ひとつ進んだらもう前に戻らないという考え方です。一方でアジャイル開発は、進めながらやることを決めていくのが基本です。
そのアジャイル開発の中でも、スクラムガイドで定義されているプロジェクトの進め方を「スクラム」と呼びます。

―――進めながらやることを決めていく場合、最終的なゴールはどこに置くのでしょうか。ゴールを置いていても、やっているうちに全体の方向性が変わってしまったり、ゴールを見失ったりすることは無いのですか。

そうですね、「どんな価値を届けたいか？得たいか？」をゴールとします。
よく言うプロジェクトのQCD（品質・予算・納期）はウォーターフォール型と同じようにありつつ、「届けたい価値が届けられるか？」という大前提のもとで判断します。
途中でやることが変わっても、それは「届けたい価値のため」だとチームで認識合わせをします。

―――目的を見失わないようにするんですね。今回のプロジェクトでは、初期リリース時には目的としていたことは達成できましたか。

今回、別のシステムと同時リリースすることが決まっていたので、リリース日は変更できない要素でした。そのため、当初スコープに入れていた機能を削り初期リリースを迎えました。
スクラムでは、開発チームが一定期間に開発できる開発規模（ベロシティ）を見積もるのが難しいと言われますが、達成できそうにない目標を目の前にしては士気も下がりますよね。
結果的には、チームで最善の道を選択しました。

小さなチームで、大きな価値創造を目指す

―――スクラムではどのようにプロジェクトを進めるのでしょうか。ですか。今回のプロジェクトには、スクラムマスターである坂口さん、プロダクトオーナー2名と、開発メンバー2名、計5名が参加されていましたよね。

はい。スクラムの基本単位は、スクラムチームという⼩さなチームです。スクラムマスター、プロダクトオーナー、開発者というメンバーで構成されます。
スクラムチームは、敏捷性を維持するために、規模はあまり大きくないほうが良いかなと思います。スクラムガイドにも、⼩さなチームのほうがコミュニケーションがうまく、⽣産性が⾼いことがわかっている。とありました。大きなチームでスクラムをやる場合は、またいろんな工夫が必要だと思います。

―――スクラムマスターやプロダクトオーナー、どの役割もウォーターフォール型にはないものですね。慣れないと「この場面ではどう動いたらいいのかな」「何をするべきなのかな」と悩むこともありそうですね。

スクラムガイドから引用すると、スクラムマスターは「スクラムを確⽴させることの結果に責任を持つ人」、プロダクトオーナーは「スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ人」、開発者は「各スプリントにおいて、利⽤可能なインクリメント（システムなどの製品）のあらゆる側⾯を作成する人」です。
役割が少ないように見えますが、プロジェクトはまわります。役割は決まっていますが、それぞれその時の状況に合わせて柔軟に対応します。
やっぱり、メンバーがそれぞれ自立していて、能動的に動くことができる前提なので、そういうメンバーでチーム構成をする必要はあるかなと思います。
スクラムガイドにも、スクラムは専門家が集まった単位であるとされていますが、確かにその通りかなと思います。

Day1：スプリント計画

―――まずは、水曜日の午後に1週間の計画を立てるところから始まるんですね。

はい。水曜日というのに深い意味はなくて、はじまりを何曜日にするかは、メンバーのスケジュールも考慮して決めます。
まず1週間、最初は水曜日の午後から始まるんですが、スプリント計画の打合せがあり、ここで来週水曜日までにやることを決めます。
ここでは、プロジェクトメンバー全員が集まって実施します。

―――アジャイルやスクラムの教科書では、対面でチームが集まりホワイトボードや付箋を使って、1スプリントでやりたいことを出して、ポイントを見積もって…というスプリント計画のシーンをよく見ます。今回プロジェクトメンバーは物理的に離れていて、完全にリモートだったそうですが、何を・どのように決めたのですか。

最初から最後まで、直接会うことは無く…（笑）。
そのため、Jira（進捗管理ツール）やmiro（オンラインホワイトボードツール）を活用し、プロダクトオーナーやスクラムマスターから次のスプリントでやりたいことを説明していました。
開発チームから質問があればここで認識合わせをし、実現したい仕様を詰めていきます。開発チームでおおよその実装イメージがつかめたら、どれくらいの工数でできそうかというポイントを付けます。
わいわいとした雰囲気でした。

―――雰囲気づくりも重要視されていたんですね。このスプリント計画で、気を付けることはありますか。

はい。機能の説明だけでなく、なぜそれが必要なのかといった業務背景を伝えることが重要だと考えています。

例えば、こんな課題があって、そのためにこの業務をやっています、という感じです。実現方法はなるべく決めず、開発チーム側に出来るだけ自由に作ってもらうようにします。ここをチェックボックスにして…とかは言わないように。
実現したいことが実現できるように、開発チームの人にどういう実装がいいのか考えてもらいます。

―――白紙から1スプリント目を始めるのは、難しそうですね。先程の「どのくらいの工数でできそうかというポイント」も、どのように見積もったらいいか悩みそうです。開発メンバーの過去の実績や感覚で決めていくイメージですか。

そうですね。システム化するところは、既存の業務なのかどうか、既にシステム化されているのかどうか、によっても進め方が変わるので、そういう前提を整理する時間は必要ですね。
スプリントを始める前に準備フェーズの様な期間を設けて、全体像の認識合わせをしたり、開発メンバーにプレの作業をしてもらいポイントを見積もったり…。
そういう意味では、プレ要件定義のような全体の設計フェーズはやっぱり必要かなと感じました。そこは、スプリント0とか呼んでいましたね。

Day2：朝会、開発、バックログリファインメント

―――1日は朝会から始まるんですね。いわゆる、デイリースクラムですか。

はい、朝会と呼ばれることが多いみたいです。
朝からチームのみんなで集まって、顔を合わせて話します。持ち回りでファシリテーションし、昨日やったこと・今日やること・今苦戦してること…などを共有します。
ポイントは、小さなことでも共有できるように「Something New」コーナーを設けていました。プロジェクト外では、こんなことやっているよーの話だったり、週末のお出かけ予定だったりします。

―――楽しそうですね！一方、メンバーの作業状況も把握する必要があるかと思いますが、人によってはちょっと困っていても「大丈夫です」って言ってしまいそうですね。スクラムマスターはどのようなことに気を付けていますか。

そうですね。話してみて、ちょっと困ってそうだからサポートに入ろうとか、そういう対応もします。
でも、人って仕事の顔だけじゃないところもありますよね。リモートでなかなか対面で会う機会もなく、雑談的なところもできない環境だったので、そういうことを話す時間も大事にしていました。
そういう積み重ねが心理的安全性につながるだろうと考えていたので、しんどいことはしんどいと言える環境づくりは意識していました。
他の人に迷惑をかけたくないとか、いろんな理由で助けが呼べないことってありますよね。

―――チーム形成において、一朝一夕ではいかないことも多いですよね。その後の「開発」は、開発メンバーのみで実施するのですか。

基本は開発メンバーで実施するのですが、毎日10時～11時はみんなで集まって実装を行う会をやっていました。これは「モブプロ会」と呼んでいて、スクラムマスターの私も適宜入ります。
同じ画面を見ながら、要求を実装していく作業を共有します。個人作業でつまづいているところを持ち寄り、解決方法を相談します。
しゃべりながらやることで、頭の整理をしながら実装が出来ます。
あとは、みんなで知恵を絞ってやるので三者三様の気づきポイントがあり、考慮漏れを減らせます。
分担した方が効率的って思われがちなんですが、特に初期の段階はみんなでこれをやるのが意外と、遠回りのようで近道でした。

―――木曜日の午後は、「バックログリファインメント」とありますが、これは何ですか。

次のスプリントに向けて、ユーザストーリー（要件）を分解、具体化していく時間です。Jiraやmiroを使い、画面イメージや仕様を相談します。
まだシステム化するかどうかも決まっていないレベルの話もあるので、運用や業務整理の話もここで話します。アイテムが大きいと、やることがぼんやりしたり、ポイントを見積もるのが難しくなります。
なので、とにかくアイテムを小さくしていって、次スプリント、次々スプリント分くらいまで分解して、いつでもスプリントバックログに持って行ける状態だと安心ですね。

Day3~5：朝会、開発の繰り返し＋勉強会

―――木曜日以降は、「朝会→モブプロ会」を繰り返し、開発を進めるんですね。結構スピード感があって、冒頭でもお話があったようにあっという間に1週間が過ぎそうですが、いかがでしたか。

水曜日に計画を立てて、実質木曜日・金曜日・月曜日で開発して、火曜日にはもうテストも実施して、水曜日にはまた新しいスプリントが始まります。
なので、3日ぐらいで開発して、動くものとして出す…というのを毎週やるのは、まあ結構きつかったですね（笑）。
もちろんスプリントが終わる時点でアイテムを全部こなせない時もあるので、そこは次に持ち越したり開発メンバーと相談して調整したりしました。
あとは、金曜日の午後に勉強会をやっていました、みんなスクラム初挑戦だったので（笑）。

―――1週間って長いようで短いですし、イベントもたくさんありますよね。メンバー各々の作業の時間を確保するために、このイベントはスキップしたい…みたいにはなりませんでしたか。

難しいですけど、どれも欠かせないイベントなんですよね。
初めの方は、これ進め方どうするんだっけ？とか、なんでやるんだっけ？と、はじめの3スプリントくらい目までは、結構迷うタイミングがありました。
一方で、スプリントに慣れるとリズムができるので、定着化していきました。
あと、目的を共有して「みんなで作業する」が基本なので、そういった意見はなかったですね。

Day6：スプリントレビュー、デプロイ、ふりかえり

―――そして、次の水曜日ですね。水曜日は予定がぎっしりですね…。

確かに（笑）。
水曜日の午後イチに、スプリントレビューを実施します。みんなで出来たアイテムを動かしながらレビューします！スプリント計画で決めたアイテムを一つ一つ確認し、実際にデモをします。そして、プロダクトオーナーから追加のリクエストがあれば、バックログにその場で追加していきます。
ポイントとしては、プロダクトオーナー側は積極的に相槌をうったり、感想を話したりします。「イメージ通り！」「これだとユーザーが少し迷うかな・・・」「おーすごい！」とか。開発チームからも、気になることは積極的に確認します。「ここはアイテムには記載なかったけどこういう風にしなくていいですか？」とか。

―――「みんなで」できたものを確認するんですね。その後すぐに、ふりかえりを実施する…と。これも先ほどお話があったように、心理的安全性…言いたいことを言えるような環境づくりでもあり、次のスプリントをより良いものにするためにおこなうのですか。

はい。今回のスプリントをKPTでふりかえります。
まず、約10分シンキングタイム…。その後、miroに付箋をぺたぺたはっていきます。書けたらみんなで共有・ディスカッションします。この人のここがグッジョブだった！と素晴らしかったところは積極的に褒めて、逆にこれが出来なかった・失敗した…も次回のために積極的に話します。
ここまでで１スプリントです。1週間おつかれさまでした！
そして、また次のスプリント計画へ続きます。

スクラムで進めることを選択肢として持っておく強さ

―――今回は、メンバーみなさんはじめてのスクラムということでしたが、やってみてどうでしたか。

体制の組み方は、ちょっと課題として残ったかなと思います。今回プロダクトオーナーは、20%の稼働で想定していましたが、実際もっと稼働の時間を割くか、意思決定ができるサポート役のような人を置く必要があるかなと思いました。
プロダクトオーナーは重要な役割なので、その点もしっかり考慮して、キックオフの際に体制を検討する必要がありますね。
またスクラムチームは、メンバーそれぞれが自由に動ける分、それぞれに委ねられている権限や責任も大きいかなと思います。
スクラムチームが有効なのは、不確実性の高いプロジェクトの場合です。いかなる場合もスクラムが最良というわけではなく、ケースバイケースで、スクラムチームを組んだときに最大の価値を発揮できそうな場合に、選択肢としてあるといいですよね。

―――ありがとうございました。

---

ライター