みなさんこんにちは。kintone フロントエンドリアーキテクチャプロジェクト（フロリア）で、エンジニア兼スクラムマスターとして活動している村田（@kuroppe1819）です。
現在、フロリアには兼務も含めて約 30 人のメンバーが参加しています。フロリアは小さな 4 つのクロスファンクショナルチーム体制で、それぞれが独立したスクラムチームとして活動しています。
今回はその中のひとつのチームである、サイレントリリースを部分的に試みているチーム（Mira チーム）で取り組んだ、ソロプログラミング（以下、ソロプロ）とモブプログラミング（以下、モブプロ）を両立したスウォーミングの実践事例を紹介します。
スウォーミングとは？
まずはスウォーミングという言葉について説明します。
Swarming を直訳すると「群れる」です。ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するという意味合いになります。
scrum.inc では次のように定義されていました。
スクラムにおけるスウォーミングの定義とは？スウォーミングは、できるだけ多くのチームメンバーが同じ優先項目で同時に作業可能なときに発生します。その 1 つの項目が完了するまで、彼らはその項目にだけ取り組みます。
What is the definition of swarming in scrum? Swarming occurs when as many team members as possible work simultaneously on the same priority item. And they work on just that one item until it is done.
引用：Swarming: How To Instantly Boost Your Scrum Team’s Productivity
実践しているスウォーミングの紹介
最も優先順位が高いタスクを最速で完了させることを目的に、Mira チームでは次のような流れでスウォーミングを実践しています。
1.スプリントの始めにプロダクトバックログアイテム(PBI)をスプリントバックログアイテム(SBI)に分割する。優先順位をつける。
2.優先順位の高い SBI から担当者を割り当てる。最も優先順位の高い SBI に着手している担当者がキャプテンになる。
3.基本的にソロプログラミングで SBI を完了させる。
4.キャプテンからのモブプロ・相談・レビュー依頼があれば、メンバーは着手中の作業を止めて最優先で対応する。誰もキャプテンの作業を邪魔してはならない。
5.キャプテンが担当している SBI が完了したら、次点で優先順位が高い SBI に着手している担当者がキャプテンになる。元々キャプテンになっていた担当者は次に優先順位の高い SBI に着手する。
6.例外として、キャプテンが担当している SBI より先に他の SBI が完了しそうなときはそちらを優先してレビューする。これはリリース可能になったものは最速でリリースし、在庫を抱えないようにするためである。
現在は 1 スプリント = 1 週間でスクラムを実践しています。朝会では SBI の進捗状況、優先順位、キャプテンを担当する人を確認しています。
スプリントの途中で追加でタスクが差し込まれた場合は、まずそのタスクの優先順位を決めて SBI を並べ替えています。スプリントで着手する SBI はすべて完了する前提の元（※実際には終わらないこともありますが）、最初に決めた SBI の優先順位は途中で入れ替わることを許容しています。ただし、優先順位の変更を頻繁に行うとすべての SBI の完了が全体的に後ろに倒れるため、優先順位の高い SBI はなるべく早く完了にして次の SBI に意識を向けるようにしています。
これらの流れをスプリントで繰り返し、すべての SBI の完了を目指して開発しています。
ここからはどのような流れで現在の開発フローになったのかを解説します。
モブプログラミングオンリーから徐々にソロプログラミングを併用するようになった
チーム結成時はフロントエンドの設計を話し合いながらコードに落とし込んでいく作業が大半を占めていたため、常にモブプロで開発を進めていました。しばらくの間はモププロが効果的だったのですが、大枠の設計が形になってくるとメンバー同士で相談することが徐々に減少し、「同期コミュニケーションの時間を減らして非同期で開発を進められるようにしたいね」という意見が出てくるようになりました。
スプリントで優先すべきは不確実性の高いタスクです。着手する SBI で不確実性の高いタスクが出てきた場合、必要に応じて群がって解決を試みるようにすれば並列で着手しても問題ないだろうと考えていました。スプリント単位で見れば PBI の粒度でスウォーミングできていることになるため、フロー効率を維持したままリソース効率を高められると考えていました。
このように、開発が進むにつれてチームメンバーは基本的にはソロプロで、適宜必要なタイミングでモブプロを実施できる開発フローを求めるようになりました。
ソロプロとモブプロを臨機応変に使い分ける方針にしたらリードタイムが伸びた
各々のメンバーが並行して開発を進められるように、次のルールを設定しました。
- スプリントの開始時にスプリントで着手する PBI を 並列着手可能な単位で SBI に分解する。
- SBI に担当者を割り当てる。
- 必要に応じてモブプロを行う。
このルールに則って実践してみたところ、実装が完了するまでのリードタイムが伸びました。
Miraチームでは PBI の完了条件にテスト、アクセシビリティチェック、脆弱性検証を含んでいます。PBI 完了までの開発フローは次の記事をご覧ください。
スプリントの終了日間近にテスト、アクセシビリティチェック、脆弱性検証が集中すると、すべての項目を検証する時間が不足するため、スプリントの中盤にはいくつかの PBI の実装が終わっている状態が求められていました。しかし、実装の完了が全体的に後ろに倒れてしまったことでスプリント終了日間近に業務負荷が増加。PBI が完了できなくなる懸念が生じるようになりました。さらに、いずれかの工程で手戻りが発生した場合には、それを修正するための時間が足りず、PBI が完了にならない事態も発生するようになりました。これではベロシティは安定しません。
原因は、都度モブプロや相談、レビューが発生することによって、他のメンバーの開発がブロックされ、1 つ 1 つの SBI の完了が全体的に後ろに倒れたことだと考えられます。
必要なタイミングでモブプロ、相談、レビューを行うと、他のメンバーのタスクを妨げることになり、実装の完了が全体的に後ろに倒れることが分かりました。スプリント終了日間近に慌ただしく PBI を完了していたチームメンバーは、このような経験を得て最も優先順位が高いタスクを妨げない開発フローを求めるようになりました。
群がるタイミングと対象の粒度について考える
基本的にはソロプロで、適宜必要なタイミングでモブプロを実施できる開発フローでは、必要に応じて闇雲に SBI に群がっていました。改善後のフローでは、必要に応じて最も優先順位が高い SBI に群がることを目指しました。
フローを考える上で参考になったのは Swarming: One-Piece Continuous Flow** に記載されていたキャプテンの仕組みです。
プロダクトバックログの 1 つの項目にチームの最大限の努力を集中させ、できるだけ早く完了させる。この項目を担当する人は、チームのキャプテンである。全員が可能な限りキャプテンを助けなければならず、誰もキャプテンを邪魔してはならない。キャプテンが Done になったらすぐに、次のバックログ項目に責任を持つ人がキャプテンになる。
Focus maximum team effort on one item in the Product Backlog and complete all known work as soon as possible. Whoever takes this item is Captain of the team. Everyone must help the Captain if they can and no one can interrupt the Captain. As soon as the Captain is Done, whoever takes responsibility for the next backlog item is Captain.
引用：Swarming: One-Piece Continuous Flow**
記事では PBI にキャプテンを割り当てていますが、我々のチームでは SBI にキャプテンを割り当てることにしました。群がる対象の粒度を考えると PBI は大きすぎると判断したことが理由です。PBI にキャプテンを割り当てるとサイズによってはスプリントの最初から最後まで同じ人がキャプテンを担当する懸念がありました。キャプテンは頻繁に交代したいと考えており、SBIのサイズは並列な可能な単位で細かく分割したものを用意しています。
また、チームとして最優先のタスクを最速で完了させるために、キャプテンからのモブプロ・相談・レビュー依頼に対して、メンバーは着手中の作業を止めて最優先で対応することにしました。全メンバーの招集をキャプテンの特権にすることで、最も優先順位の高い SBI に割り込みを発生させないようにする狙いがありました。
キャプテンの招集に応え、最優先のSBI（=キャプテンのタスク）を妨げなければメンバーのタスクの進め方は自由です。全メンバーを巻き込む必要のない簡単な相談はメンバー同士でその都度実施してもらっています。キャプテンの参加は任意です。
ただし、レビューが終わると完了になる SBI は例外としてキャプテンにも優先的にレビューをしてもらっています。これはリリース可能なものから逐次リリースし、在庫を抱えないようにするためです。
ルールをまとめると次のようになります。
- 優先順位が最も高い SBI の担当者がキャプテンになる
- キャプテンからのモブプロ・相談・レビュー依頼に対して、メンバーは着手中の作業を止めて最優先で対応する
- キャプテンが担当している SBI が完了したら、次点で優先順位が高い SBI に着手している担当者がキャプテンになる
- レビューが終わると完了になる SBI は優先的にレビューする
我々はこのルールをキャプテン制度と名付け運用することにしました。
キャプテン制度を運用して得られた効果
PBI がスプリントの中盤から完了するようになり、ベロシティが安定するようになりました。
開発メンバーからも肯定的な意見が見受けられました。
肯定的な意見が多かったですが、もちろん問題点もあります。招集権を持つ人(=キャプテン)が一人でタスクを抱えて手が止まってしまうと全体が遅延する点です。キャプテンは最速で SBI を完了させる責任を担っており、能動的にチームメンバーに頼る立ち振る舞いが求められます。ときにはメンバーからキャプテンに何か困っていることはないか様子を伺うことも重要です。チームの心理的安全性を高め、些細なことでも質問しやすい雰囲気を構築することがスウォーミング成功のカギとなります。
さいごに
今回はソロプロとモブプロを両立したスウォーミングの実践事例を紹介しました。
最も優先順位の高いタスクの担当者をキャプテンとし、周りのメンバーがキャプテンを全力で援助する体制を作ることで、基本的にソロプログラミングでもフロー効率が高い開発ができるようになりました。
チームによって PBI、SBI のサイズや、そもそもの開発の進め方が違うのでこのフローをそのまま適用させることは難しいと思いますが、開発フロー改善のきっかけや参考になる点があれば幸いです。
