minneでは、2021年に入り大きくスクラムの実施方法を見直ししてきました。この記事では、その背景や実施した見直し内容、その成果についてまとめたいと思います。 記事内で何度も出てくるかと思いますが、チームによって目標達成のためのフレームワークは様々です。この記事にある方法が最善とは限りませんし、もしかしたらminneでも1年後には全く違った形で開発をしているかもしれません。あくまであるチームでの改善の一例としてお読みいただければ幸いです。
背景・プロジェクトフォースの発足
スクラムを再出発するのと時を同じくして、組織改編もありました。これまでは、minneでは職種ベースでチームが組成(開発ディレクター,webエンジニア,androidエンジニア,iosエンジニアなどなど…)されており、その中でタスク管理やスクラムを実施していましたが、組織改編によって職種横断のプロジェクトフォース的なチームが新設されました。 これがスクラム再出発の大きな追い風となりました。新設されたチームでのタスク管理をゼロベースで考えることができたからです。また、スクラムを効率的に実施するには、PO（プロダクトオーナー）の積極的な参加が必要不可欠ですが、職種横断のチームであったことからその働きかけができたことも幸いしました。
このような背景・下地があって、スクラムを改善することに成功しています。
きっかけと課題と改善
スモールスタートという言葉がありますが、スクラム改善は偶然的に小さく始まりました。筆者が所属する10名規模のminneの新制チームの一つで、タスク・バックログ管理についてメンバー間での話し合いが行われました。そこでよりスクラムを前進させようという認識の一致を得て、ひとまずチーム内でスクラム改善が始まりました。
minneでのスクラム課題感
minneでは、以前よりスクラム開発を導入しており、ある程度型に乗った形で運用されていました。例えば、デイリースクラム（朝会）、スプリントプランニング（計画会）、スプリントレトロスペクティヴ（振り返り会）はすでにMTGとしては存在しており、それぞれ実施が形骸化することもなく目的をもってMTGを行っていました。 しかしながら、以下のような課題がありました。
- スクラムイベントに長時間費やすもののそれに見合った成果を感じられない
- 相対見積もりへの苦手意識
- 要件と異なる実装での再実装の発生
- 職種間でバックログの見通し齟齬
- スプリントゴールの達成率の伸び悩み
こういった課題は、MTGをただ設定するだけでは解決に至るのは難しく、バックログに対する認識の統一や、MTG内容の改善を同時に行うことで解決を試みました。
改善
言葉の統一
まず、言葉の認識統一を最初に行いました。スクラムガイドを基本とし、一部チームで便利なように独自解釈している部分もありますが、同じ認識をもって言葉を使うことでコミュニケーションがスムーズになりました。例えば、PBI（プロダクトバックログアイテム）に関して、PBIとはユーザーストーリーであることを基本とし、 リリース可能な単位で構成されていることとしました。これによって、「○○のPRレビュー」といった様なタスクがPBIとして定義されることはなくなりました。PB（プロダクトバックログ）を見たときにも、ディレクターは施策の進行状況について、またエンジニアは機能のリリース進捗についてそれぞれ把握することが出来、あらゆる職種から有用な統一されたバックログを作成することが出来ました。 バックログが統一されたことで副次的に便利になったものもあります。それは、ロードマップです。ロードマップはPBIをさらにまとめ施策単位（エピック）で参照することができるように準備されました。それによって、PBIにおける進捗を反映したものをすぐにロードマップ側から参照することが出来、スコープの大きい議論においてもいつでも詳細な進行状況が必要に応じて誰でも確認できるようになりました。
新鮮なバックログ
言葉の統一の次に大きく改善されたのはバックログの鮮度管理です。スクラムチームが施策のスケジュールや優先度について話し合うとき、バックログが古くなっていると「これなんだっけ・・・」「担当者が不在だ・・・」といった問題が起こってきます。そのため、バックログは常に最新の状態に更新されている必要があります。バックログの内容を更新する作業をリファインメント活動と呼びますが、minne内ではもっぱらリファ活と略し、毎朝定例で行っています。 理想では、何らかバックログを更新したい潜在的なニーズがあるときにいつでもメンバーが結集してリファインメント活動を行えれば良いのですが、時間の都合が合わないこともあるため毎朝定例で行うこととしています。
リファインメント活動を毎日やることには他にもメリットがあります。それは、細かくインターバルをもうけることが出来ることです。長いMTGを設定して一気にリファインメント活動をしようとしても、1つのPBIや施策に関しての議論が白熱し、丸一日潰してしまったりすることなどもあるでしょう。しかしながら、毎日決められた時間内で行うことは、一旦議論を終結させ、あるいは24時間、各個議事録を読み返したり、調査を行ったり、意見を考える時間をとり情報をまとめることで、少ないMTG時間でより多くのPBIについて議論することが出来るようになっています。
もちろん、中には非常に大きな施策についてリファインメント活動を取り組む必要がある場合や、込み入った事情のあるものも存在します。それらは別途スプリントに一度のまとまった時間を取ってリファインメントをすることとしています。
これらのリファインメント活動はすべてチームメンバー全員集まって実施します。そのため、後からPOが想定した仕様とエンジニアの実装が異なる！といった事象や、要件矛盾・作業規模の齟齬について早い段階で気づきを得ることができ、結果として作業の再発生や、見通しの齟齬をチームメンバー内で解消することにも役立っています。
デイリースクラムの改善
デイリースクラムは漫然とした進捗報告会であってはならないと考えています。そこで、minneのスクラムではスプリントゴールを達成するための「お困りごと」の共有を中心にMTGを進行しています。 とはいえ、「お困りごと」はなかなか作業者自身から報告出来ない場合もあると思います。ソフトウェア開発者なら誰でもドツボにはまってうんうんとうなったまま時間が過ぎてしまった、という経験はあるでしょう。これそのものの善し悪しは別の議論に任せるとして、一つの作業に大きな時間をかけてしまうと、「お困りごと」はないけれどもそのスプリントのスプリントゴールを達成出来ないということがおこり得ます。そのため、「お困りごと」がない場合などは「スプリントゴールを達成できそうですか？」という問いかけが有効で、何らかの「お困りごと」を見つけるところから議論がスタートすることもあります。
もちろん、デイリースクラムの本来の目的はスプリントゴールを達成するための障害を取り除くことであるので、これらの流れが自然とチームメンバー間で馴染んできているのは、大きな成果といえると思います。
結果
上記にあげた改善は、今回行った改善の一部ではありますが、こうした改善への取り組みを経て、スプリントプランニングが丸一日かかっていたところを30分～1時間、長い場合でも2時間程度に納められるようになってきました。また、実装中の新たな要件の発見を防いだり、見積もりの肌感を職種間・メンバー間でそろえることが出来るようになっており、すべてのチームメンバーにとって少しずつ開発しやすい・開発を提案しやすい体制が整ってきていると思います。
おわりに
冒頭にも書いたとおり、ここにご紹介したminneのスクラムがすべてのチームにとって最善の開発フレームワークであるとは思っていませんが、もしこれらの事例が別のチームのフレームワークに影響を与えることが出来ていればとてもうれしく感じます。 また、もっといい開発フレームワーク知ってるよ！改善できるよ！という熱意のある方がminneのメンバーとして参加していただければ、これからも楽しく開発フレームワークをアップデートしていくことが出来ると思うので、ぜひお待ちしています！