はじめに

現在、私のプロジェクトはもうすぐ開発2年が立ちますが、スクラム開発に導入して実際にどんなメリットを感じたか振り返りたいと思います。
チームでは不明瞭は責任の所在、コミュニケーション不足などで様々な問題が発生しますが、スクラムというフレームワークによって、この問題に対処できると感じました。

スクラム開発とは

スクラム開発はアジャイル開発の一種です。
スクラムガイドと呼ばれる公式のマニュアルがあり、内容も難しいものではありません。実際にガイドの中でも軽量級フレームワークと呼ばれています。

スクラム開発ではスクラムマスターと呼ばれる、スクラム開発の有識者がチームが上手く運用できるようサポートします。
私のプロジェクトにはスクラム開発の経験者はいなかったため、私がスクラムマスターを担当することになりました。

※ 以降はスクラムガイドの用語に乗っ取って記事を進みます。

まずスクラム開発を回すためにプロジェクト管理ツールを決める必要がありました。
スプリントごとにチケット発行できるようなツールであれば、基本どれでも対応可能ですが、もともと使っていたReadmineの拡張機能で対応できたため、これを利用しました。

次にスクラムマスターからメンバーに役割や、1スプリントの流れを共有します。
1スプリントを1週間に設定し以下のサイクルに定義しました。

メンバーの役割は以下のように定義しました。

毎週のレトロスペクティブでは、改善点をメンバー同士が共有しあっていました。
開発環境の改善や、スクラム自体の改善など、レトロスペクティブにより発見できた改善点は多かったです。

プランニングは全員でタスクの割り当てやスケジュールの検討を行っていましたが、毎週1時間かかっていました。

数か月もスクラム開発をしてくると、レトロスペクティブで共有される改善点がほとんど出てこなくなりました。このタイミングでレトロスペクティブを廃止し、何かあれば、デイリーで共有することになりました。

プランニングもメンバー全員でスケジューリングしているのは、時間がかかりすぎるということで、事前にタスクの割り当てとスケジュール作成を行い、その他のメンバーは合意するだけというフローにすることでプランニングは1時間から10分前後まで短くなりました。

最終的には以下のサイクルに落ち着きました。

スクラム開始直後と比べて、スクラムを回すための時間はかなり短くなりました。

スクラム導入前のフロー

プロダクトオーナーと開発者の接する機会が少なく、要件と仕様をすり合わせる機会がとても少なかったと思います。
チーム内で発生した疑問を吸い上げるタイミングが少ないため、改善が改善されず効率が悪いことも気づかず進めていたかもしれません。

スクラム導入後のフロー

プロダクトオーナーと開発者が毎日接することで、要件、タスク、個人の考えなどが密に確認でき、課題が見つかれば時期を決めて取り組むなど、細かい軌道修正ができ、全員がスプリント終了へ向って正しく進む感覚を感じることができたと思います。

チーム一丸の意識が強まり、ルール化された各スクラムイベントにより、チームの透過性が増したと思います。

個人的にはスクラムを導入したことで、チームで働きやすくなったと感じるので、これからも適した場面があれば、積極的に採用したいと思いました。