タイミーでアジャイル開発した話
はじめに
こんにちは、地方大学院生のアツ 🔥 です。
株式会社タイミーの「26 卒 Web エンジニア向け就業型インターン」に、バックエンドエンジニアとして参加していました。
実務でのアジャイル開発を経験したので、備忘録として残そうと思います。
対象読者
- アジャイル開発の実例を探している方
- Web 系エンジニアの働き方を知りたい方
- タイミーで働きたいと考えている方
インターンの概要
- 期間： 2025 年 1 月（1 ヶ月間、週 3 日以上）
-
対象： 26 卒 Web エンジニア向け就業型インターン
- タイミーでのエンジニア新卒採用は 26 卒からスタート。1 期生に該当。
-
勤務形態： リモート
- 勤務時間は柔軟に調整可能。10:00~19:00 で稼働。最終日のみ出社
- 使用言語（FW）： Ruby on Rails
- 選考： 書類選考 → カルチャーマッチ面談 → 技術テスト → 技術面接 → 最終面接 → インターン参加
過去のアジャイル開発
なぜ今回のブログで「アジャイル開発（スクラム）」に焦点を当てるのか？
それは、以前私が大学の研究員として働いていた際に、ソフトウェア開発プロジェクトにアジャイル開発のスクラムを試験的に導入したものの、具体的な方法の説明が少なく運用で苦労したからです。（Miro とか導入してみたものの形骸化させてしまった。）
スクラム には、SCRUM BOOT CAMPを代表に著名な書籍が数多くありますが、内容は概念的なものが多く、実際のツールの使用例などについての記載はあまりありません。
過去の私がそうであったように、1 から スクラム を導入しようする人の多くは、運用面で 1 度はつまずくのではないでしょうか？
そこで今回のブログでは、アジャイル開発（スクラム）を具体例とともにまとめていきます。
補足資料
アジャイルソフトウェア開発宣言：アジャイル開発の基本的な価値観や原則を示した公式文書
スクラムガイド：スクラムのフレームワークを理解するための公式ガイド
配属チームとスクラムの運用
ここからが本題です。
配属チームについて
私が配属されたのは、主に資格関連の機能を担当するチームで、私を含めた 10 名で、スクラムでの開発を行いました。
| 役割 | 人数 |
|---|---|
| プロダクトオーナー | 1 名 |
| PMM（プロダクトマーケティングマネージャー） | 1 名 |
| デザイナー | 1 名 |
| バックエンドエンジニア | 4 名 |
| フロントエンドエンジニア | 1 名 |
| ネイティブエンジニア | 2 名 |
スクラムの運用
- スプリント期間: 1 週間ごとに回す
- 司会進行（ファシリテーター） イベントごとに回り持ち
-
イベント:
- スプリントプランニング（45 分）
- スプリントレビュー（1 時間）
- スプリントレトロスペクティブ（45 分）
- デイリースクラム（毎朝 15 分程度）
デイリースクラム以外のイベントは水曜日におこわれ、その他の時間は基本的に割り振られた開発タスクに取り組みました。
ここからは、個々のスクラムイベントについて、実際の例を交えながら説明していきます。
なお、実際のプロジェクト内容を公開することはできないため、私が以前開発した「大学の授業レビューサイト」の新機能を題材として具体例を記載しています。
※「大学の授業レビューサイト」はこちら
今回のプロダクトゴールは下記に設定しました。
スプリントプランニング
スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。
— スクラムガイドより
スプリントプランニングでは、今回のスプリント（1 週間）で「何をゴールとして、どのようなタスクを進めるのか」をチーム全体で決めます。
① プロダクトオーナーから取り組みたいことの説明
プロダクトオーナーが、スプリントで取り組むべき課題や目標を説明し、チーム全員で方向性を共有します。あわせて、問題や確認事項を洗い出し、スプリントをスムーズに進行できるよう準備を整えます。
② スプリント内で完了できる PBI（Product Backlog Item）の選択
スプリントプランニングでは、以下の手順でスプリント内で完了できる PBI を決定します。
スプリントの PBI の決定手順
-
PBI のリファインメント（見直し）
各 PBI（Product Backlog Item）で決まっていない部分の内容を具体化し、作業内容を明確にします。
-
PBI のリストアップ
プロダクトバックログから、スプリントに含めるかどうか迷っている PBI をすべてピックアップします。
（補足）PBI に書かれている数字について
プロダクトバックログに書かれている数字は、各タスクにかかる時間の指標（ストーリーポイント）を示しています。 これを参考にして、チームがスプリント内で無理なく完了できる量を判断します。
今回のチームでは以下のような指標（フィボナッチ数）を元に、ストーリーポイントを判断しました。
-
Five Finger で合意形成
チームメンバーで 全員が Five Finger を実施して、今スプリントにおける PBI に対する合意を取ります。懸念事項があれば議論し、スプリントに乗せる PBI を最終的に決定します。
立てる指 意図 0 本 絶対だめだ！ 1 本 深刻な反論があります！ 2 本 懸念はあるけどやってみよう 3 本 そのアイデアサポートしますよ！ 4 本 そのアイデアいいね！ 5 本 完全同意！
③ スプリントゴールの決定
PBI（Product Backlog Item）の選定が完了したら、それをもとに スプリントゴール を決定します。 スプリントゴールは、スプリント期間（1 週間）の開発において チーム全体が目指す指針 となるものです。
話し合いの結果、今回のスプリントゴールを決定しました！
スプリントレビュー
スプリントレビューの目的
完成の定義を満たした PBI（成果物）をデモして、チームやステークホルダーからフィードバックや協力を引き出すことです。
これによって、プロダクトバックログの項目を追加したり削除したり順番を入れ替えたりして、限られた時間の中で価値を最大化できるように向かう先を修正していきます。
① 完了した PBI のデモ
スプリントレビューでは、今スプリントで開発した内容をデモし、プロダクトゴールへの進捗を共有します。必要に応じて関係者を招き、成果物の挙動を直接確認してもらうことで、より具体的で有益なフィードバックを得ること目的としています。
今回のチームでは、開発者が事前にデモの準備を整えて、スプリントレビューに参加していました。
② 完了した PBI のステータス更新・状況確認
- 完了した PBI のステータスを更新し、終了しなかった PBI に関しても進んだ部分の内容を反映して、最新の状態にしましょう。
- 今スプリントで達成できた「実績ストーリーポイント」を PBI ごとに記入して、チーム全体でスプリントごとに行える作業の予測と実際のズレをチェックしましょう。
下記の例では、予測よりも 実績が 2 ポイントほど少ないので、次のスプリントではもう少しタスクをこなせそうということがわかります！
スプリントレトロスペクティブ
レトロスペクティブの狙い - 「品質と効果を高める方法を計画すること」by スクラムガイド
スプリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う
今回のチームでは、Miro を利用して、今スプリント中の出来事、Keep、Moreについて話し合いを行いました。
反省点から具体的なネクストアクションを決めて、次回のスプリントに反映させていきました。
今スプリントでは、次のデモで remote test kit を使うことと、PBI をもっと細かく分割することが決まりました！
デイリースクラム
デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
- メンバーの体調やスプリントゴールを達成できそうか、作業の余裕などの確認を行います。
- その後、PBI をみながら各々の進捗状況を全体で共有します。
次のスプリントへ
これらのイベントを含むスプリントを何度も繰り返し、プロダクトゴールの達成を目指しましょう！
まとめ
今回の記事では、私が経験したアジャイル開発（スクラム）の一例をご紹介しました。
今後、自身でアジャイル開発を導入する際は、導入自体が目的とならないように、チームに合った方法を模索しながら自己組織化を目指していきたいと思います！
最後に、このインターンを通じて、たくさんの学びと貴重な経験を得ることができました。
関わってくださった皆様、本当にありがとうございました。
Discussion