スクラムマスターとしての初挑戦

こんにちは、スプラシアのナムです。

今回は自分のスクラムマスターの経験について話させていただきます。

スクラムマスターとしての旅は、会社がサービスの次期バージョンを開発するタイミングで始まりました。
ラッキーなことに、私はすでにCSPO（Certified Scrum Product Owner）資格を取得しており、スクラムに関する知識を学んできました。
上司はその知識を活かす機会を与えてくれ、チームと一緒にスクラムを試すことになりました。

スクラムは、ソフトウェア開発などのプロジェクトを効率よく進めるためのアジャイルフレームワークです。

反復的なプロセスにより、チームが迅速に価値を提供できるよう支援します。基本の進行は、スプリントと呼ばれる短期間の作業単位に基づいており、スプリント期間中は明確に定義された目標に向かって進行し、終了後にスプリントレビューで進捗や改善点を確認します。

スクラムには以下の3つの主要な役割があります。
・プロダクトオーナー：製品のビジョンを示し、優先順位を決定する。
・スクラムマスター：チームのプロセスを支え、スクラムが適切に実行されるようにする。
・スクラムチーム：実際にサービスを作成するメンバー。

このフレームワークにより、チームは柔軟に変化に対応し、継続的に価値を提供できます。

チームのほとんどはスクラムの概念に馴染みがなく、最初は戸惑いが多く見られました。

特にストーリーポイントの意味や使い方、スパークやエピックストーリーの概念、エピックストーリーを子ストーリーに分解する方法に関して多くの質問が飛び交いました。
これらの疑問に答える時間は多く割かれましたが、それもスクラムマスターの役割の一部であり、チームがスクラムを理解する重要なステップでした。

さらに、メンバーの疑問点をまとめ、社内用のスクラムガイドを作成し、重要な要素をリストアップして共有しました。

スクラム導入後、チーム内でいくつかの大きな変化がありました。

これまでは、各メンバーが事前にタスクを割り当てられていましたが、今では取り組みたいタスクやストーリーを自由に選択できるようになりました。

さらに、スプリントプランニングでプランニングポーカーを使い、プロダクトオーナーから新しい機能の要件を共有してもらったうえで、メンバーがその機能にどれくらいの作業量がかかるかを見積もります。
このプロセスは、作業量を決めるだけでなく、メンバーがプロダクトオーナーや他のメンバーに自然に質問する場にもなります。これにより、機能に関する知識のギャップが徐々に埋まっていきます。
全員がその機能について完璧に理解するわけではありませんが、やり取りを通じてメンバーの理解が深まり、誰かの作業を他の人がカバーする場合にも対応しやすくなります。
この方法は属人化（特定の人にしかできない仕事が増える状況）の回避にもつながり、チーム全体が柔軟に協力できる体制を整えます。

また、チーム内での仕事の共有が進んでいなかったため、メンバー同士が何をしているのかが不透明でしたが、スプリントレビューの導入により、メンバーが他の人の進捗状況を確認できるようになり、機能間の相互理解が深まりました。

こうして、チームとしての一体感が生まれつつあります。

最初のうちは、私自身もスクラムマスターとしての役割に加え、エンジニアとしての作業を同時にこなしていたため、かなりの負荷を感じていました。

さらに、チーム全体もスクラムという新しいプロセスに適応するのに苦労していて、特に初めの数回のスプリントは試行錯誤の連続でした。お互いにまだ慣れていないスクラムのフレームワークに沿って進めることが大変で、予想以上に時間と労力がかかりました。

しかし、いくつかのスプリントを繰り返すうちに、チームが少しずつスクラムの流れに慣れ、プロセスの理解が深まるとともに、私自身の負担も次第に軽減されていきました。

各メンバーが自発的にタスクに取り組むようになり、スプリントもよりスムーズに進行するようになったことで、チーム全体のペースが整い始めました。

今では、次期バージョンのリリースに向けて準備が整いつつあり、みんなが次のステップに期待を寄せています。

今振り返ると、スクラムを導入することで、チーム全体がより協力的で効率的になり、プロジェクトの進行が格段に良くなったと感じています。

これからもスクラムを活用しながら、さらにチームと共に成長していきたいと思います。