スクラム開発初心者、最初の3ヶ月での学び

はじめに

私は2025年春に新卒としてエンジニアになり、研修を経て実際のプロジェクトにアサインされました。右も左も分からない中で、とにかく毎日必死に開発に向き合っていました。

入社して半年ほど経った頃、初めて本格的なスクラム開発のプロジェクトにアサインされました。

正直、スクラム開発がどんな進め方なのかもほとんど理解できておらず、その上プロジェクト全体の規模が大きかったため、最初はかなり不安でした。

そんな状態からスタートしたスクラム開発でしたが、3ヶ月間チームの一員として動く中で、実際に体験してみないと分からなかった学びがたくさんありました。この記事では、私がスクラムに参加して気づいたことをまとめていきたいと思います。

スクラム開発とは

スクラム開発とは、アプリの完成に向けて「小さく計画 → つくる → 振り返る」という流れを短い周期で何度も回していく開発手法です。

スクラムなど開発手法については、この記事でも解説しています。

アジャイル開発とは？メリット・デメリット、他の開発手法との違いを解説

もう少し具体的に言うと、スクラムではスプリントと呼ばれる期間ごとに作業を区切ります。私がアサインされたプロジェクトでは「2週間 = 1スプリント」でした。

スプリントは、以下のような流れで進んでいきます。

1．プランニング（スプリント初日）

目的：この2週間で「何を終わらせるか」を決める

スプリントの初日にはプランニングという場があります。そこでは、今スプリントで消化するチケットを確認し、子タスクに分解して、内容や時間を見積もります。

分解が終わったら、誰がどのチケットを担当するかを話し合って決めます。

やること：

チケットのゴール・受け入れ条件を確認する
チケットを「子タスク」に分解する
それぞれの子タスクの工数感を見積もる
担当者を決める（やりたいタスクを手に取れると成長にもつながる）

各々がやりたいタスクを任されるので、自分の伸ばしたい能力を伸ばすことができますし、使命感も強く感じるので非常に良い刺激になっています。

（プランニングの前にチーム内でスプリントを振り返ることが多いそうですが、私がアサインされたプロジェクトでは日頃から活発にコミュニケーションをとっており、効率面を考え行なっていませんでした）

2．リファインメント（スプリント中頃）

目的：次のスプリントでスムーズに開発に着手できるように準備する

スプリントの中頃にはリファインメントという場があります。ここでは、プロダクトオーナー（以下PO）が作成したチケットの説明を受けます。その説明を元に、DEVチームでそのチケットのStory Point（1Point = 8時間目安）をプランニングポーカーという手法で決定します。

やること：

POから「なぜ必要か」「どんな価値か」「どこまでやるか」を聞く
仕様の曖昧な部分をQ&Aでつぶす（境界条件・例外・文言など）
プランニングポーカーでStory Pointを決める
「次スプリントで実装できる状態」まで整える

プランニングポーカーとは

チームメンバーがそれぞれ見積もり値をカードで提示し、その値が大きく異なる場合は議論を重ねて合意を形成していく
個人の主観に寄りすぎず、チームで納得感のある見積もりを作れます
スクラム開発では、Story Pointの見積もりによく使われる手法

3．スプリントレビュー（スプリント終了時）

目的：できたものを見せて、認識を合わせ、次の一手を決める

スプリントが終わると、スプリントレビューと呼ばれる場で、POチームに成果物を見ていただき、作業内容を詳しく報告します。この時、自分が担当したチケットの成果物をそのチケットのページにまとめておく必要があり、動作確認などもその場で行うことでPOチームに伝えます。

やること：

今スプリントでやったことを説明する
POが判断できる形で動作確認を行う
フィードバック・追加要望をもらう
「受け入れ」か「修正が必要か」を整理する

このサイクルを繰り返しながら、最終的な期限に間に合うようにプロダクトを育てていく、これがスクラム開発と呼ばれる開発手法です。

実際に経験して学んだこと

ここからは、実際にスクラム開発に参加して学んだことを、具体的な経験を交えながらお伝えします。

① タスクの進捗は「現状」と「残り時間」をセットで伝える

スクラム開発では、朝会と夕会を毎日行います。進捗共有は当たり前のように見えますが、実際にやってみて感じたのは、「何をしているか」だけでなく「どれくらいで終わりそうか」までセットで伝えることが大事だということでした。

朝会や夕会では、主に「今日やること」や「今日やったこと」を報告しますが、スクラムマスターは全体の進捗を意識されているため、各タスクがどの程度進んでいるのか、どのくらいの時間がかかりそうなのかといった時間の見通しが重要になります。

例えば、「〇〇の機能を実装しています」と報告するだけでなく、「〇〇の機能を実装していて、全体の7割ほど完了しています。残りは2時間程度で終わりそうです」のように、進捗の割合や残り時間を具体的に伝えることで、スクラムマスターがスプリント全体の進捗を把握しやすくなります。

② 進捗共有は自分だけじゃない：チームの進捗も意識する

自分のタスクだけでなく、他のメンバーの進捗も意識することが重要だと学びました。私の場合は特に、CI上での結合テスト（※）を実装するタスクを通じて、この重要性を痛感しました。

そのタスクでは、他のメンバーの作業がマージされてからでないと、CIの実行に取り掛かれない状況でした。いわゆる「直列のタスク」です。

このような場合、他のメンバーの進捗をボードで確認しておくか、作業が終わり次第声をかけてもらうように事前に伝えておくことが大切だと感じました。

実際、私は他のメンバーの作業がマージされていることに気がつかず、夕会で初めて知ることになり、その結果、CIを回すのが半日ほど遅れてしまいました。

つまり依存関係のあるタスクでは、相手の進捗を能動的に確認する習慣をつけることがとても重要です。

また、自分の作業が他のメンバーのタスクに影響する場合は、事前にコミュニケーションを取ることで、チーム全体の効率を上げられると感じています。

※CI：Continuous Integration（継続的インテグレーション）。コードをマージしたタイミングで自動でテストやビルドを実行して、問題がないか確認する仕組み。

③ 他のメンバーの担当チケットを理解しておくこと

このプロジェクトは、自社メンバーだけでなく他社のエンジニアも含めて8人規模で進めていました。人数が増えるほど、そして会社がまたがるほど、「今、誰が何をしているか」を把握する難易度が一気に上がります。雑談で自然に情報が入ってくるわけでもなく、ちょっとした認識のズレが、そのまま手戻りにつながりやすいと感じました。

スクラム開発では、進める中で仕様が変わることが少なくありません。自分が担当しているチケットの変更は追いやすい一方で、他の人のチケットで起きた仕様変更は、把握しようと意識しないと見落とします。特に他社の方が担当している範囲は、実装の背景や前提が共有されるタイミングが限られることもあり、気づいたときには影響が出ていた…ということが起こり得ます。

そこで私が心がけていることとしては、朝会と夕会を最後まで抜けないことです。他の方に質問を行うタイミングは、朝会と夕会の後が多いです。「この後少し話せますか？」という声かけが多く、その会話を聞くことで仕様の変更や実装の詳細について確認できることがあります。朝会や夕会を途中で抜けてしまうと、こうした重要な情報を見逃してしまう可能性があるため、最後まで参加することを意識しています。

また、他の方のMR（マージリクエスト）も覗くようにしています。まだまだ差分だけで完全に理解できないこともあるので、そのブランチをチェックアウトして挙動を確認するなどを心がけています。実際に動かしてみることで、仕様の変更点や実装の詳細をより深く理解できるようになりました。

この経験から、他のメンバーの担当チケットを理解しておくことは、次のスプリントをスムーズに作業を進めるうえで非常に重要だと学びました。特に、自分のタスクと関連する機能については、積極的にMRを確認しています。これにより、仕様の変更にいち早く気づき、次のスプリントで困ることが減りました。

④ スプリント開始時の仕様理解の重要性

次に、スプリントの初日に自分のチケットを理解することの重要性についてです。

理想は、仕様をきちんと把握した上で、設計の曖昧さや抜け漏れがないかを早い段階で潰しておくこと。ただ、これはまだ十分にできておらず、今の自分の大きな課題だと感じています。

実際にあった例として、とあるエンドポイントの実装を担当することになり、8割ほどの理解のまま進めてしまいました。スプリント後半になり、実装がほとんど終わったタイミングで設計書の文言が曖昧な箇所を見つけ、確認をしたところ私の理解が間違っていることがわかりました。その結果、スプリント終盤にも関わらず大きな修正を加えることになり、レビュワーの方にも再度レビューをお願いすることになり、大きな負担をかけてしまいました。

この経験以来、着手前にできる限り仕様を読み込み、曖昧な点は早めに確認するよう意識しています。それでも、認識のズレが残っていたり、細部の検討が足りなかったりして手戻りにつながることがあり、まだまだ改善が必要だと痛感しています。