本記事は サムザップ Advent Calendar 2025 5日目の記事です。
自己紹介
はじめまして！
サムザップでゲーム開発タイトルのプロジェクトマネージャーをしている@tomeitouです。
今回とある新規プロジェクトで初めて自らスクラムを導入し、スクラムマスターを務める機会がありました。
まだまだ運用途中ではありますが、すでにいくつかの良い効果を実感しています。
ふりかえりも兼ねて、スクラムを主導してみて得られた学びをまとめておこうと思います。
目次
スクラムとは？
スクラムは短いサイクルで仮説検証を行うことで、複雑な問題に対して価値を継続的に生み出していくためのフレームワークです。プロダクトオーナー、スクラムマスター、開発メンバーが協力し、スプリントと呼ばれる期間ごとに計画・開発・ふりかえりを繰り返すことで、プロダクトとプロセスの両方を改善していきます。
▼ イメージ図（🍌）
導入のきっかけ
私は数年前にスクラムへ開発メンバーとして参加した経験がありました。
当時はスクラムの意義や「何のための各イベントなのか」を全く理解しておらず、気持ちも入らないまま、ただ作法に則って進めて、効果を実感できないままに終わった記憶があります。
一方で世の中ではスクラムの効果について耳にする機会が多く、いつかきちんと向き合ってみたいと思っていました。しかし自身が成功経験を持っていないため、なかなか踏み出せずにいました。
今回新しく発足する開発チームにジョインする機会があり、そこにスクラム経験者がいて、またメンバー全員が新しい取り組みへ前向きに挑戦したいという雰囲気がありました。
この機会を実践してみる良いタイミングとして、導入に至りました。
何から始めたか
最初に取り組んだのは、スクラムの意義や各イベントがもつ目的等をチーム全員と共有することでした。
私自身が過去にスクラムの目的を理解できていなかった背景から、"全体像はどんな流れか？""どういう意図があるのか？"“なぜこれを行うのか？”などをスクラムチーム内で前提知識を知る・共通認識を持つことを重視しました。
チーム全員で「まずはやってみよう」という状態になってからスタートしました。
スクラムの事前学習には以下書籍を大いに参考にさせていただきました。
SCRUM BOOT CAMP THE BOOK
実施したスクラムの概要
今回スクラムを適用したのは、新規プロジェクト内の特定機能のプロト版開発です。
チーム構成は以下のとおりでした。
- プロダクトオーナー（ディレクター）
- UIデザイナー
- エンジニア2名
スプリントは2週間で設定しました。
得られた良い効果
● 開発進行面での効果
スクラムチーム内で意思決定に必要な役割が揃っているため、作る内容や優先度の調整を迅速に行えるようになりました。スプリントレビューやデイリースクラムを通して、お互いに細かくコミュニケーションを取り、短いサイクルでアウトプットを出す習慣が身につきました。
また制作物の内容だけでなく、先の計画や意図のすり合わせも繰り返し行うため、チーム全体で同じ方向を向きやすくなりました。
● チームビルド面での効果
特に大きく効果を実感できたのはチームビルドです。
毎スプリントのふりかえり・デイリースクラムでの声掛けが習慣化したことで、課題や気づきを素直に共有できる環境が形成されました。
「スクラムはチーム全員で目的を達成するものである」という意識からメンバー同士の会話量も増え、お互いの状況を把握して協調が生まれました。
ふりかえりによるプロセスの改善や、スプリントを繰り返すことによる見積もり・作業精度の向上など、短いサイクルで成長実感を得られやすい・自分たち自身でどんどん改善できている感覚を得られる構造になっていることも良いポイントだと思います。
ホワイトボード前で議論したり、アウトプットをポスターにして貼るなど、取り組みそのものの外からの見え方が、プロジェクト全体にも良い影響を与えていると感じました。
スクラムはプロダクト開発のための手法であると同時に、チームそのものを強くする文化であると実感しました。
まだうまくいっていない部分
一方で、スクラム運用を続ける中で課題も見えてきました。スクラムでは、機能横断的で「全員が揃えばプロダクトを作れる」状態が理想とされます。しかし、開発フェーズが進むにつれて別の専門スキルが必要な領域（例えば品質の高いエフェクト制作など）が増えていき、既存メンバーでは補いきれない状況も出てきました。
プロダクトのフェーズや品質要求の変化に合わせて、スクラムチームの拡充も計画的に検討しておく必要があると思いました。
ちょっと学びになったTips
▼ PBIと受け入れ基準の書き方のコツ
PBI（プロダクトバックログアイテム）として、バックログに要件・やることを列挙していくのですが、ここの書き方には少しコツがいるなと感じました。
例えば 「〜を決める・〜を作る」 といったふうに書いてしまうと状態定義ではなく、抽象度の高い内容になってしまい、どこまで出来ていれば完了なのか？の認識がズレやすくなります。
として、「〜ができる状態にする」 のように書くことで、そのために必要な要素を皆で洗い出すことができ、漏れを防いだり完了定義を揃えることができます。
具体的な必要条件を、別途"受け入れ基準"として記載して補足しておくと良さそうです。
PBI = 「できたことを確認するための状態定義」
受け入れ基準 = 「具体的に何をしないといけないかの要件定義」
この切り分けによって認識ズレが生まれにくくなり、見積もり精度も向上しました。
▼ FigJamは振り返りツールとして優秀
FigJamはふりかえりで使いたいタイマー、付箋、スタンプ、投票といった機能が揃っており、操作も直感的で非常に使い勝手の良いツールでした。
過去の記録も残しておけるため、スクラム外でもふりかえりで積極活用していきたいツールです。
まとめ
スクラムを初めて主導してみて、スクラムは単なる開発手法にとどまらず、チームの関係性を深め、成長を促す力を持つフレームワークだと感じました。
引き続きこの経験を生かし、今後もより良いプロダクトを生み出せる環境作りをしていきたいと思います。
明日は、 @ninomiya_shota さんの記事になります。お楽しみに！！