スクラムマスターが実際のプロジェクトで学んだこと

スクラムマスターを実際に経験して

まず、簡単にスクラムマスターの資格を取得してから携わった2つのアジャイル開発スクラムのプロジェクトを紹介します。

ひとつめは、ローコードツールを活用して社内のプロジェクト管理システムを構築したプロジェクトです。このプロジェクトでは、追加開発フェーズからスクラムマスター兼BA（ビジネスアナリスト）として参加しました。

ふたつめは、上記と同じローコードツール活用して社内の稟議・発注管理システムを構築したプロジェクトです。このプロジェクトでは、プロジェクトの企画構想からスクラムマスター兼BAとして参加しました。

この2つのプロジェクトを通して、スクラムマスターという役割について改めて考えてみました。

ここからはスクラムガイドを読み直しながら、ここは〇〇ということだと改めて理解した、ここは〇〇という点で難しかった、という点を共有します。

▶参考資料　スクラムガイド 日本語版 2020年11月ver.：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

スクラムの理論でプロジェクトの変化にいち早く気付く

スクラムでは、検査と適応のための4つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。

これらはそれぞれ、下記のように読み解くことができます。
透明性：プロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒えていること
検査：スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されること
適応：プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果となるプロダクトが受け⼊れられなかったりしたときは、適⽤しているプロセスや製造している構成要素を調整する必要があること

システムに必要な機能の計画と実装を繰り返す“スプリント（イテレーション）”を回してプロダクトを作り、何か芳しくないことが検知されたらそれに対して調整を行う…ということが、この透明性・検査・適応の三本柱を実現する基本です。実際のプロジェクトでも、この三本柱が機能した局面がありました。

プロジェクト開始後、スプリントを回し始めて1か月を過ぎたくらいで「このままの進捗だと当初予定していたリリース日に間に合わないかもしれない」と開発チームからPO（プロダクトオーナー：開発する製品の責任者）へアラートが上がりました。「まだ始めて1か月なのに…？」と思われる方もいるかもしれませんが、1か月といえばスプリントを4～5回すでに回しており、1回のスプリントでどれくらいのアイテム（機能要求）数が消化できるのか、機能実装の難易度の予測が立てられている状態でした。このタイミングで問題が共有され先延ばしにせずに意思決定できることは、スクラムの理論の実践ではないかと思います。

さらにPO側でも、出来上がった画面を見ながら要求を精査していきます。すると、ある時点でそこまで構築したデータ構造では対応できない要求変更が出てきました。しかも、それは法令対応のためには実現がマストの要求でした。

スプリントが始まった段階で見積もることができていなかった、要求からもれていた、と言ってしまうとそれまでです。よかったところはその問題をプロジェクト開始して1~2か月で見つけることができたこと、対応すれば納期は遅れてしまうが、それを合意の上で一旦スプリントを停止する決断を早期に下すことができたことでした。透明性の高いスクラムで日常的に状況を共有できていたことが、早期の決断につながりました。この点もスクラムの理論（透明性・検査・適応）が健全に機能した場面だったと思います。

動くソフトウェアが早くできるから期待値が上がってしまう

これはスクラムガイドに記載されていることではないですが、アジャイル開発を進めるにあたり、最大のメリットとして挙げられるのが「価値あるプロダクトを早く届ける」です。そのため、ウォーターフォール開発よりも早い段階で実際にユーザーが操作可能なプロダクトができてきます。

このプロダクトを作るために、アジャイル開発スクラムではプロダクトバックログと呼ばれるものに要求事項の一覧が記載されています。その要求事項の機能、要求、要望、背景、受け入れ基準などが詳細に記述されています。そして、要件定義・開発・テスト・実装を1つのスプリントで素早く実行し、繰り返していくことで動くソフトウェアが早くでき、POはそれを基に機能レビューを実施し、修正したい箇所や追加の要求を開発チームに伝えます。

しかし、このバックログアイテム（＝要求事項）の管理が難しいことを改めて感じました。プロジェクトが発足する時点でコアとなる要求が優先順位ごとにバックログに並んでいますが、バックログアイテムが実装されて操作可能になると、その機能をよりよくしたいと追加の要求事項が出てくることがあります。これが、初期リリースの要件としてマストであればよいのですが、そうでない場合は優先順位を入れ替えたり、実装可否を検討し直したりする必要があります。その機能をよりよくしたいという気持ちも理解できるので、新規の要求事項についてはPOを中心にチーム全員で一度立ち止まって考えることが必要だと思いました。

プロジェクトごとに“ベスト”なスクラム運営を

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。

スクラムガイドで定義されているスクラムの成果物は、プロダクトバックログ、スプリントバックログ、インクリメントです。このスクラムを学び始めた当初は「え？それだけ？大丈夫？」と思っていましたし、楽ちんだな…なんてのんきなことを考えていました。

しかし、実際にプロジェクトを進めてみると、企画構想段階で作成される「業務一覧」「業務フロー」、プロジェクト計画段階では「プロジェクト計画」、テスト段階では「テスト計画」「テストエビデンス」、教育展開段階では「教育資料」「操作マニュアル」など、通常のシステム導入プロジェクトの成果物として定義されているドキュメントが必要でしたし、実際に作成もしました。

これらは、アジャイル開発スクラムだから必要ではない（作らなくてよい）のではなく、プロジェクトを推進するうえで関係者間との調整に活用したり、次フェーズへの引継ぎのために必要な成果物であるために作成を進めました。

スクラムフレー ムワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが 定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは 詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。

アジャイル開発スクラムだからスクラムガイドに書いてある通り進めなければならない！…ということではなく、軽量で柔軟なフレームワークだからこそさまざまなプロジェクトで活用できるフレームワークなのだと気が付きました（そして決して「楽ちん」ではない）。プロジェクトチームで必要だと判断されたものであれば必要、スクラムのフレームワークはあくまでも“道しるべ”であって、その上しか走ることのできない“線路”ではないのだと痛感しました。

実際に経験してみることで気づくことの多さ

スクラムマスターを取得して約2年、実際にプロジェクトの経験を通してそのフレームワークや理論について、自分の経験と照らし合わせることで多くの気づきがありました。
実際にスクラムマスターの研修を受講したり、アジャイル開発スクラムに関する書籍を読んだりすると、“経験に勝るものはない”と言われていたり注意書きに書かれていたりします。これからも知識を磨いていけるよう精進していきたいと思います。

最後までお読みいただきありがとうございました。