スクラムって実際どうなの？という方へ。初めてスクラム開発を行なった所感

Livesenseでプロダクト・エンジニアをしている山下です。
普段は転職会議の開発に携わっており、スクラム手法を用いた開発をプロジェクトで行なっています。

今携わっているプロジェクトが自分の中で初めてのスクラム経験であり、始めて1ヶ月ほど経ったので、振り返りと共有を行えればなと思います。

「スクラムってよく聞くけど詳しくわからない」「実際やってみてどうなの？」といった人に読んでもらえたら嬉しいです！

スクラム開発とは？

まずはじめに、簡単にスクラム開発とは何かをまとめておきます。

スクラムとはアジャイルソフトウェア開発と呼ばれる開発手法の一つであり、以下のような特徴を持っています。
・優先度順にプロダクトの開発を行う
・期間を固定で区切り、開発のスケジュールを行う
・プロジェクトの進捗具合を、毎日メンバーで確認し合う
・開発している機能が要求通りであるか、定期的に確認の場を設ける

また、思想として「設計段階で全て見通すのは不可能」と考えており「小さく分割して開発し、確認を繰り返す」といった方針をとっています。

要件定義、仕様策定、設計、開発、テストの各プロセスを順にこなしていくウォーターフォール形式ではなく、小さな成果物を確認しながら進めていくことによって、変更に強いプロジェクトを運営していきます。

どんなプロジェクトに向いている？

個人的な意見ですが、以下のようなプロジェクトにはスクラムが向いているのではないかと思います。
・関わる人（職種）が多い
・仕様が確定していない
・大きめな開発を伴う

プロジェクトに関わる人が増えるほど、その分だけメンバー間での認識を揃えるコストが大きくなるかと思います。
人数が少なければ、必然的に全員で話す機会も多くなり、認識を揃えることも難しくはないのですが、人数は職種が多くなると、リーダー単位のミーティングに移行しがちであり、なかなか認識を揃えるのも、揃っているのかを確認するのも、難しくなるかと思います。
スクラムでは対話を重視しており、全員参加のミーティングを設けることが求められてきます。
これにより、認識のズレが早期で発見でき、修正もしやすくなります。

また、仕様が固まっておらず、プロジェクトを進めながら詳細な仕様を決めていくといった場合でも、開発を小さく分割し確認していくスクラム手法であれば、柔軟に対応できるかと思います。

大きめな開発を伴う場合でも、スクラムではチームとしてどれだけのスピードで開発を行えるかを測る仕組み（後述）があるので、ウォーターフォール形式よりはスケジュールの見積もりもつけやすいのではないかと考えいます。
※ スクラムでも完璧な見積もりは難しいとされており、あくまで参考となる計算がしやすくなる、といった具合です。

どうやって進めている？

まず最初に役割分担ですが、今回のプロジェクトでは以下のようなチームでスクラムを開始しました。

・PO（Product Owner）：プロダクトにおける意思決定を行う。プロダクトの価値の最大化に責任を負う
・SM（Scrum Master）：スクラムが円滑に進むよう、メンバーにスクラムのコーチングなどを行う。スクラムの運営に責任を持つ。
・Developpers：エンジニア、デザイナー、PMで構成され、仕様を詰めるところから開発するところまでを行う。

PO、SMが各1名ずつ、エンジニア2人、デザイナー1人、PM2人の7人でスクラムを組んでいます。

スクラムでは「小さく作って確認しながら開発する」を実現するために、いくつかのフローが用意されています。
自分たちがどのようなフローでスクラムを行なっているか、簡単にまとめていきます。

0. タスクの洗い出し

まずはじめに、プロジェクトの目的達成のために必要なタスクを洗い出しておきます。
この時、洗い出したタスク一覧をプロダクト・バックログと呼びます。

1. スプリント・プランニング

スプリントと呼ばれる、開発の区切りとなる期間を設けます。
今回は2週間を1スプリントとしました。

次に、このスプリンントでどこまで開発すべきか、という目標を立てます。
これをスプリント・ゴールと呼びます。

スプリント・ゴールが決まったら、プロダクト・バックログの中からこのスプリントでやるべきタスクを選択します。

その後、開発チーム全員でタスクの見積もりを行います。
この時、エンジニア、デザイナー、PMも含めたチームメンバー全員で見積もりを行い、タスクの認識にズレがないか、などを確認しながら見積もりを行います。

また、プランニング時の見積もりでは、ストーリー・ポイントといった考え方を用いて見積もりを行っています。
これは、プロジェクト内で基準となるタスクを定義し、そのタスクの作業量をベースに相対的な作業量を見積もります。
自分たちの例では、DBの変更処理の作業量を2とし、他のタスクがどれくらいの作業量なのかを見積もるようにしていました。
この時、見積もりを作業量ではなく時間で行なってしまうと、タスクに取り組むメンバーによって値が変動してしまうため、スプリント期間中にどれだけのタスクをこなせるのかが、分かりにくくなってしまいます。
作業量を基準にすることにより、チームとしてどれくらいの作業量を決められた期間でこなせるのか、をわかりやすくなるようプロジェクトを進めています。

2. スプリント・レビュー

スプリント期間が終わったら、メンバー全員で振り返りを行います。
この時、実際に動作する成果物をPOに見せながら、問題がないかも確認します。

また、このスプリント期間中でどれだけのストリー・ポイントを消化できたたかを、次回スプリントの参考値としています。

3. デイリー・ミーティング

開発チームは、日時で決まった時間に集まり、タスクの状況や困りごとがないかを共有するようにしています。

なるべく顔を見ながら行うようにしているのですが、どうしても参加が難しい人がいる場合はチャットで共有を行うようにしています。

やってみてどうだった？

スクラムによる開発スタイルも1ヶ月ほどたち、自分も含めて他のメンバーも慣れてきたのではないかと思います。
最初のうちはなかなかスクラムになれず、各フローも探り探りで行なっていましたが、慣れてくると非常にスムーズに開発に進めるようになってきました。

以前のプロジェクトでは、スクラムを用いない手法で開発を行なっていたこともあり、都度メンバー全員を集めてミーティングを行なったり、ドキュメントを用意したりなどで開発以外の負担がかなりかかっていました。

また、見積もりも時間単位（これは1日かかりそうだな、など）で行なっていたため、想定外のタスクやプロジェクト外のタスクが発生するたびにスケジュールを修正しており、見通しもなかなか立てづらい状態でした。

スクラムの手法にのっかることで、プロジェクトの進行が非常にやりやすくなったのではないかと思います。

開発に関しても、スクラムでは小さく分割し確認も取りながら進めることになるので、作っているものの安心感があります。
また、成果物を実際に動かしながらみなで確認することになるので、仕様の把握や実装の漏れも見つけやすくなっています。

まだプロジェクトの途中のため、最終的にどうなるのかは分からないのですが、現状はこの仕組みの上でスムーズに開発ができているのではないかと思います。

最後に

まだまだ自分もスクラム経験は浅く、まだまだ模索している箇所も多いかと思います。
自分のチームではこうしているよ、であったり、こんな進め方おすすめだよ！といった情報がある方はぜひコメントください！

スクラム開発で悩んでいる方も気軽に連絡ください。自分もまだまだ勉強中ですが、お互い情報交換しあえればなと思います！