Safie Engineers' Blog!

Safieのエンジニアが書くブログです

スクラム開発のメリット 〜スクラム初心者が経験して感じたこと〜

初めまして。セーフィーの伊原と申します。
今年で社会人3年目で、セーフィーには2021年11月に入社いたしました。

現在はビジネスユニット1にてフロントエンド開発を主に担当しています。
ビジネスユニット1は主に飲食・小売業のDX実現を目的とした部署で、多店舗経営者向けのクラウドカメラ管理アプリケーションや、店舗内の人を検知するAIを搭載したクラウドカメラの開発を行っています。

今回は私が所属しているフロントエンドチームにて実施しているスクラム開発についてご紹介いたします。
私にとってスクラム開発はセーフィーが初めての経験で、当初は慣れない事も多かったですがとても良い取り組みだと感じています。

本記事では初めにスクラムの簡単な説明をした後、開発現場で実践している開発フローについてご紹介いたします。その後、私が考えるスクラムの良さについて所感を述べます。

スクラム開発の概要

まず初めに、スクラム開発を知らない方に向けて簡単にスクラム開発の説明をいたします。

スクラム開発とは、スクラムと呼ばれるフレームワークを活用したソフトウェア開発のことです。チーム毎にスプリントと呼ばれる一定の期間を指定し、次の図の流れを繰り返すことでプロダクトのゴールを目指していきます。

①バックログリファインメント
プロダクトに必要なものを洗い出し、プロダクトバックログと呼ぶ一覧にします。新規機能の追加、機能改修など様々なものをまとめるため、抽象的な内容も含みます。
これはスプリント初めに行うのみでなく、適宜開催することもあります。

②スプリントプランニング
プロダクトバックログの内容をタスクレベルまで落とし込み、1スプリントの間に実施するタスク一覧に抽出します。ここで抽出されたものをスプリントバックログと呼びます。
選定の際には、チーム全員でタスクの作業量を見積もり、スプリント内で終わる現実的な量を抽出します。

③スプリント期間
各メンバーにタスクを割り振り、開発を進めます。
タスクは最初に全て割り振ってしまうのではなく、メンバーが自主的にスプリントバックログから取得します。タスクが完了次第、新しいタスクを取っていく形です。
期間内はタスクの遂行を円滑にするためにデイリースクラムと呼ばれる集まりを毎日実施します。
スプリントの終了まで③を繰り返します。

④スプリントレビュー
開発期間の終了時に、以下の2点を評価します。

  • 期間内で完了したタスク量の算出:チームの生産性の計算
  • 良かった点・改善点の洗い出し

評価の内容を踏まえ、再び②に戻ってサイクルを回します。

一連のスプリントを繰り返すことで徐々にプロダクトと開発フローを発展・洗練させていくのがスクラム開発です。

Safieのフロントエンドの開発フロー

私のチームにて実際に取り組んでいる開発フローを前述した図の①〜④に当てはめてご紹介します。
チームでは1スプリントを2週間として設定しています。

①バックログリファインメント
スプリントの初めに1度実施しており、本イベント後の同日に②のスプリントプランニングも実施しています。
ここでは開発チームメンバーで集まり、プロダクトに必要な機能を一覧化します。
タスクの進捗管理にはWrikeというツールを使っており、タスクを次の段階に分け、ボードで管理しています。

  • Backlog: プロダクトバックログ
  • ToDo: スプリントバックログ
  • Doing: 遂行中
  • Dev Review: レビュー中
  • QA Review: QAチーム確認中
  • Done: 完了したタスク
  • Closed: スプリント中に完了したタスクの一覧

それぞれのリストにあるタスクは移動させられるようになっており、各自が自分の持っているタスクを段階に応じて移動させます。Doneまで移動させたらタスクは完了となります。
DoneからClosedへの移動は後述するデイリースクラムにて実施します。

②スプリントプランニング
前回のスプリントにて完了したタスク量を目安に、スプリントバックログを作成します。
必要があれば、機能をタスクの粒度まで落とし込みます。例えばユーザ登録機能が必要な場合、「ユーザ登録」という機能単位ではなく、「画面開発」・「API連携」という単位に分割するような形です。
ここでは機能の優先度のみでなく、企画やサーバサイドの進捗状況に合わせて柔軟にタスクを選定するようにしています。

スプリントバックログの作成後、積んだタスクの見積もりをチーム全員で行います。見積もりはストーリーポイントで数値付けをしています。
ストーリーポイントとは相対見積の指標で、「このタスクだったらどれぐらいかかりそうか」の規模感をこれまでのタスクから考慮して設定します。ここで重要なのは、何人日・人月といった絶対値で見積もりをしないことです。
ストーリーポイントの決定にはプランニングポーカーという方法を採用しており、これは各メンバーの見積もった数値を一斉に開示するやり方です。
見積もりの数値はフィボナッチ数列から選択します。開示した際にメンバー間で見積もりが一致しなかった際には、互いに想定した理由を伝え合って議論します。ここで重要なのは、見積もり内容にメンバー全員が納得する事です。
見積もった結果として想定のタスク量との差が大きかった場合には、プロダクトバックログを再度見直してタスク量を調整します。

③スプリント期間
スプリント期間内は毎朝15分程度のデイリースクラムを実施し、以下の3点をチームで共有しています。

  • 前日にやったこと
  • 本日やること
  • 困っていること

報告の際にはWrikeのボードを画面共有し、各自が持っているタスクの総量を全員が把握できるように進めます。「本日やること」の報告の際に新しいタスクをスプリントバックログから取っていくのですが、この際にもタスク内容を宣言しておく事で、今後どういったタスクに取り組む予定かをチーム全員が知っているようにします。
また、WrikeにてDoneとなっているタスクを確認し、本当に完了で問題ないかをチームメンバー全員で確認するようにしています。これによって、本人が気付かないタスク漏れ等を防止しています。

④スプリントレビュー
スプリント中に完了したチケットを整理し、チームのベロシティを算出します。
また、以下4点に関してスプリント区間内の振り返りを行い、次のスプリントの改善を目指します。

  • Good: 良かった点
  • Problem: 課題点
  • Try: 改善策
  • Keep: 次回以降も続ける試み

スクラム開発のメリット

ここで、私がスクラム開発を実際に体験して良かったことを3つに分けて説明いたします。

1. 属人化の軽減
1つ目は、属人化(ノウハウが共有されない状態)を防ぐことができる点です。
スクラムではチームメンバー間でやっていることが共有されるため、各メンバーのタスクの全容が透明化されます。Aさんでないと/Bさんでないと分からない、というような事がなくなると共に、メンバー間での質問やアドバイス等が行いやすい環境が促進されます。

スクラム開発における最大のメリットはこの点であると私は考えています。
設計方針や実装方針の良し悪しを開発者間で積極的に話し合う事ができ、技術者として成長できる環境が整っていると感じました。

2. メンバーの負荷状況の可視化
「属人化の軽減」の項で透明化について述べましたが、透明化によってチーム内の負荷がかかっているポイントが明確になること、それが2つ目の良い点です。
デイリースクラムで困りごとを共有する機会を作ることで、課題に個人ではなくチームとして取り組む流れを自然に作り出す事ができます。また、手が空いている人が他の人のタスクを巻き取るなどの融通も効きやすいです。

3. 見積もり能力の向上
全てのタスクに見積もりが行われるため、実際に業務を遂行する中で予想より短い・多かったという事が必ず発生します。そこで「なぜ想定と異なったのか?」を考えて共有することで、チーム全体でタスクに対する見積もりの感覚が向上していきます。
ストーリーポイントを付ける際に他の方の意見を聞く機会も多く、見識が広まりやすいのも利点です。
また、チームがどの程度のタスク量をこなすことができるかも明確になるため、開発スケジュールに無理が無いかを早めに判断することができます。

最後に

セーフィーでスクラム開発を経験してみて、開発を健全に進める上でチームに必要な要素を自然に促してくれるような、良い開発体制であると感じています。
各メンバーの自主性は求められますが、自主的に動く事の重要性はかなり大きいので、それも含めて成長する必要があると思っています。
セーフィーは厳格な上下関係が無い事もスクラム開発との相性がよく、開発として社内のコミュニケーションを取りやすく、開発していてとても楽しいです。

本記事で少しでもセーフィーの開発フローの良さがお伝えできていれば幸いです。
読んで頂きありがとうございました🙇‍♂️

本記事の執筆に当たり、次のスクラムの解説記事を参考にさせていただきました。
詳細を理解する上で非常に勉強になる内容でした。 qiita.com

© Safie Inc.