若手エンジニアが初めてスクラム開発に参加して学んだこと

CSP開発統括部AI技術部の舘です。

近年、ソフトウェア開発を行う上で、アジャイル開発の代表的なフレームワークである「スクラム」を採用することが増えてきています。しかし、まだスクラムを経験したことがない方や、そもそもスクラムって何？という方も少なくありません。

そこで、私が初めて体験したスクラムについて、スクラムの進め方や感じたメリット・デメリットまで、経験談を踏まえてお届けします。これからスクラムを始める方やスクラムが気になっている方の参考になれば幸いです。

スクラムとは

スクラムはアジャイルの一系統で、軽量フレームワークです。スプリントという短い期間を反復していき開発を進めていきます。スプリントの最後に、インクリメントという「動くもの」を作り、フィードバックを実施し次のスプリントに繋げていきます。スクラムの特徴について、以下にまとめています。

スクラムの特徴

スクラムの特徴は大きく3つあります。

• スプリントという短いサイクルで区切り開発を進める
• 開発を効率的に進めるために様々なスクラムイベントが存在する
• 開発チームメンバーをプロダクトオーナー（PO）、スクラムマスター（SM）、開発者の3つの役割に分担して開発を進める

特にスクラムイベントは1スプリントの中で実施し、それを繰り返し行なっていくため、スプリントを重ねていくことでプロジェクト内でのスクラムの進め方がどんどんスムーズに変化し、開発効率も向上していきます。しかし、短い期間の中で複数のスクラムイベントを実施するため、開発を行うための実動時間が短く見えてしまいます。以下でスクラムイベントの種類と、それぞれの目的について紹介します。

スクラムイベント

スプリントには様々なイベントが存在します。適切に機能すれば、開発の手戻りを減らし、短いスプリントの中でも効率よく成果を積み上げることができます。代表的なイベントは次のとおりです。

イベント	目的
スプリントプランニング	スプリントの方向性と実施するPBI※の範囲を決める
デイリースクラム	今日の進め方をそろえ、進行上の妨げを早期に可視化する
スプリントレビュー	インクリメントを検査し、次のPBIの優先度を決め直す
スプリントレトロスペクティブ	働き方を見直し、次スプリントに反映する改善について合意する

このほかに重要なイベントとして、「リファインメント」があります。これは、スクラムで管理する「プロダクトバックログ」を見直し、内容を整理していく作業です。プロダクトバックログとは、プロジェクトを完遂するために必要な作業を優先度付きで管理した一覧のことを指します。この作業では、バックログの内容を具体化し、優先度や作業の粒度をチームで確認しながら、次のスプリントで着手できる状態まで整えていきます。あらかじめバックログを整理しておくことで、スプリントプランニングをスムーズに進めることができ、開発に集中しやすくなります。

※ プロダクトバックログアイテム（PBI）：プロダクトバックログの中で管理している「やること」。

スクラムの進め方

実際のスクラムの進め方について、私が参画しているプロジェクトでの実例を踏まえて説明します。なお、私はスクラムメンバーの中で開発者であるため、今回は開発者の視点から、開発の流れやスクラムイベントの実際の進み方を中心にお伝えします。

準備期間（Sprint0）について

私が参画したプロジェクトでは、すぐに開発スプリントを開始するのではなく、準備期間として2週間の「Sprint0」を設けました。このSprint0での目的は、次から始まるSprint1でスムーズに開発を開始し、価値を提供できる状態にすることです。Sprint0で行なったことは大きく4つです。

• メンバー間でのスキルの共有
• 開発環境の調査・構築
• バックログリファインメント（PBIの作成）
• 作業上の不安解消会

スクラムの進め方やプロジェクトの立ち上げを経験するのは私にとって初めてだったため、スクラム開始に向けたイベントや会議が重なり、開発準備と情報整理の両立に苦労しました。しかし、先輩社員や他の開発者のサポートを受けながら準備を進め、Sprint0での準備期間を終え開発スプリントに入ることができました。

開発スプリントの進め方

Sprint0が終了すると、いよいよ開発スプリントが始まります。Sprint1では準備期間で行なっていた会議に加え、スクラムイベントやスプリント内で実施するバックログリファインメント、Sprint2の準備のための会議など様々なイベントが一気に動き出しました。

私自身まだ開発経験が浅く、当時はスクラムの進め方や開発タスク、会議で共有される情報などが次々に押し寄せ、気づけばプロジェクトの進行スピードに追いつくのが精一杯という状況でした。スクラムはチームで進める開発とはいえ、実際の現場では多くの意思決定や情報共有が高速で行われます。その流れに慣れるまでには、正直苦労しました。

それでも、先輩社員や他の開発メンバーに助けられながら何とか開発を行い、スプリントを乗り切ることができました。参考までに、当時の私の1日のスケジュールを例として紹介します。

私たちのプロジェクトでは、1スプリントを約2週間としています。その中で開発を行うインクリメントを提供しています。1スプリントの中では、次のようなスクラムイベントを実施しています。

• デイリースクラム：15分（毎日）
• スプリントプランニング：2時間
• スプリントレビューとレトロスペクティブ：3〜4時間
• バックログリファインメント：1時間（週2回）

これらを毎スプリント継続して実施するため、作業時間が1日の業務時間の約半分になることもあります。そのためスクラムイベントを時間超過なく円滑に進めることが、スクラムの進め方において重要なポイントです。

スクラム開発で導入したモブワークとは

私がプロジェクトでスクラムを実施する中で、プロジェクトで取り入れたモブワークという開発方法をご紹介します。

モブワーク

モブワークとは、チーム全員が1台のコンピュータを共有し、1つの課題に取り組む手法です。スクラムと同じようにチームの中で、実際に画面を操作するドライバー、主に設計を行うナビゲーター、アドバイスや操作の指摘を行うオブザーバーの3つの役割に分けます。

この開発方法では短期的にはアウトプット量が減少してしまいます。しかし知識の共有やレビュー密度の向上、問題の早期発見といった様々な効果があります。また、モブワークの中でメンバー同士たくさんのコミュニケーションを取るため、チーム形成の速度向上も見込めます。私のプロジェクトではスキル不足と知識量のばらつきを埋める狙いで採用しました。結果として、個人のスキル向上だけでなく、チーム全体で問題を解決する力の底上げにもつながります。

モブワークの効果

モブワーク実施前は、チームがまだ成熟していなかったこともあり、安定してインクリメントを提供できていませんでした。そこでモブワークを取り入れ、1つのタスクを複数人で協力して進めるようにしたことで、自然とチーム内で会話をする時間が増え、設計意図や実装の考え方をその場で共有できるようになりました。徐々にチームとしての理解がそろい、開発の進め方も次第に安定していきました。

また、開発の中で設計やコーディングに関しての知識をシニアエンジニアから共有してもらう機会があり、チーム全体としての開発スキル底上げにつながりました。その積み重ねで、安定してインクリメントが提供できるようになりました。私自身も、コーディングのサポートを受けながら実装を進められたことで、モブワーク前と比較して開発スキルが向上したことを実感しています。チーム内での会話を以前よりも理解できるようになり、一人で開発作業をする際もスムーズにコーディングができることが増えました。

やってみてわかったスクラムの良さと難しさ

これまでスクラムを経験して良いと感じた点や課題点、スクラムを行う上で大事だと感じた点などをまとめます。

良かった点

良かったと思う点は2つあります。

まず1つ目は、短い期間で何度もインクリメントを提出できる点です。2週間で「動くもの」を見せ、その都度レビューから次の方向性を見直せます。プロジェクトのゴールとのズレを早期に発見できるだけでなく、重要な業務に必要な機能を優先して提供できます。また個人的にも、短いサイクルで結果を示せるため業務への達成感を得やすく、プロジェクトに貢献している実感を持ちやすいと感じました。

2つ目は、スプリントの最後に行うレトロスペクティブです。ここでは、業務内での自分の行動やプロジェクト内での仕事の仕方などを振り返り、良かった点や改善点を整理します。次のスプリントでどう改善するかまで話し合うため、チームとしての進め方も少しずつ洗練されていきます。私もレトロスペクティブを繰り返すことで、何ができたか、何を失敗したかを客観的に振り返り、特に失敗した部分をどうすれば改善・予防できたのかを考える習慣が身につきました。

課題と重要なポイント

課題と感じたのは、イベントの時間超過や突発会議により、実装に必要な作業時間が削られてしまう点です。スクラムではイベントを通じてチームの認識をそろえることが重要ですが、予定していたイベントが長引いたり、想定外の会議が入ったりすると、その分だけタスクに割り当てていた時間が減り、スプリント計画のズレに直結します。

私自身スクラムをやっていく上で、タスク量の多いスプリント期間中にスクラムイベントの時間超過や、イベントの目的達成ができず後の時間に続きのイベント枠を設けるということがありました。その結果、予定していた作業時間が減り、スプリント最終日までに開発タスクが完了できないなど、作業時間の調整に悩む場面もありました。

このような経験から、スクラムを円滑に進めるうえで重要なのは、タイムマネジメントとゴールの定義を明確にすることだと感じています。イベントの開始時に「なぜこのイベントを行うのか」というゴールを共有し、決められた時間内で議論を進めると意識することで、会議の長期化を防げます。こうした運営を徹底することで、不要な延長や追加会議を減らし、限られたスプリント期間の中で貴重な開発時間をより有効に使えるようになると考えています。

終わりに

今回は、私が参画しているプロジェクトでのスクラムについて紹介しました。

もちろん、スクラムの運用方法はプロジェクトによってさまざまで、スプリントの期間やイベントの進め方、チームの体制なども一様ではありません。それでも、短いサイクルで価値を届けること、チームで状況を共有しながら改善を重ねていくことなど、スクラムの核心については共通しているものがあると思います。それを、自分たちのプロジェクトに合った形に調整していくことが、スクラムをうまく活用するためのポイントだと感じています。

本記事が、これからスクラムを実践する方や、すでに取り組んでいる方にとって、現場の一例として参考になれば幸いです。

プロフィール