はじめまして、ぐるなび仕入モールでバックエンド開発を担当している中村です。2020年度に中途入社し、それまでは主にウォーターフォールモデルでの開発に携わっておりました。
今回はそんな スクラム知らないおじさん（以降、SSO）から見たぐるなび仕入モールチームのスクラム開発をご紹介できたらと思います。
この記事で書いていること
スクラムを用いてチームで開発にどう取り組んでいるかをご紹介しています。主に、
- スクラム開発の進み方
- ウォーターフォールモデルとの工程(開発フロー)比較
- いわゆる工数とどう向き合っているか
といった内容を記載しています。
この記事で書いていないこと
- ぐるなび仕入モールで用いている言語、アーキテクチャなどの技術的なトピック
何を作っているか
本題であるスクラムの内容に入る前に、まずプロダクトについて簡単に説明します。
ぐるなび仕入モールでは飲食店様向けに業務用食材・資材の仕入れを支援し、
食材を探す飲食店様と、食材を提供する店舗様を繋げるECプラットフォームとなります。トレンド食材や特産品、タイムセールなどの施策を随時展開しています。
現在のチーム構成
ダイナミックに施策を打っていくための開発チームとしては機能横断的で自律した開発スタイルが必要になります。これを実践していくための構成として
- プロダクトオーナー
- スクラムマスター
- 開発メンバー
の３ロールがチームに存在しています。
スクラムチームの一般的な推奨人数は3〜9名といわれますが、現在のチームは10名以上が所属しているためLeSSという考え方に基づいたチーム運営を行っています。（LeSSの説明は本題から外れてしまうのでここでは割愛します）
つづいて各ロールの説明になります。
プロダクトオーナー
プロダクトの価値を最大化するための施策立案を主に行います。
ユーザーのフィードバックなどから次のアクションを検討し、プロダクトバックログアイテム(=開発対象項目、以降PBIと表記)の整理を行います。
スクラムマスター
スクラムガイドによると、スクラムの促進と支援に責任も持つとありますが、各ロール間のコミュニケーション面でのサポートが主な活動となります。
仕入モールチームでは次のようなことを行います。
- スプリントプランニングの立案支援
- そのスプリントで着手するPBIの選定サポート
- PBIの開発規模見積もり
- PBIの完了定義についての議論
- スプリントレビューのファシリテート
- などなど
開発メンバー
施策検討からモノづくりに至るすべての部分に携わります。
プロダクト品質に対してフォーカスを置いているため、作って終わりではなく、施策の検討段階から開発や運用サイクルそのものの見直しといったことも試行錯誤しながら日々頑張っています。
メンバーによって得意分野（進行管理が得意な人、ガッツリ開発系の人、傾向分析が得意な人etc）は異なっていますが、職能による分業を極力行わない運営に取り組んでいます。
開発のサイクル
プランニングからリリースに至るまで
SSO目線で見るとまず要件をもとに概算工数を出して期間を設定する〜みたいな流れを想像してしまいますが、最初のカルチャーショックはこの時間的な考え方がウォーターフォールと大分異なっているという点になります。
ウォーターフォールが要件から期間や工数を策定するのに対し、現在のチームではあらかじめ決まった期間・工数内で実現できることを行うという逆のアプローチを取っています。
具体的には水曜日(隔週)に実施しているスプリントプランニングから、そのスプリント内でリリース可能な状態にできるPBIを実行するため要件を可能な限り細かく分割します。これはプロダクトの漸進性を実現していくことと同時に、リリースの遅延（=競争力の低下を誘発してしまうリスク）を避けるためでもあります。
スクラムイベントのスケジュール
現在のチームでは１スプリント＝２週間として開発を行っており、そのスプリントの開発成果物は次スプリントの１週目にリリースします。下図はスクラムイベントのスケジュールになります。
ウォーターフォールとのフロー対比
次に一般的なウォーターフォールのフローと仕入モールチームのスクラムイベントを大まかに対比させると、
という具合になります。
スクラムイベントの図と照らし合わせると、開発チームも上流工程から参加していることが読み取れるかと思います。
また基本設計以降の各工程の完了定義は明確には設けていません。これは、
- 施策の検討段階で開発に関わるタスクブレイクを慎重に行っているため
- 開発成果物は小さく作ってフィードバックを受け、追加（または改良）していくことを反復するため
- 工程別に検収作業を設けるよりも、最終成果物でチェックする方がスピードが出せたため
という背景から来ていますが、設計工程でのドキュメンテーションやコミュニケーションをスキップしてしまうという意味ではありません。
実際にはコードレビューの段階でそのコードになった経緯が分かるようにチーム内に存在するDB定義だったりI/F定義などのドキュメント類を併せて提出します。
なので文章作成能力が暗黙的に必要になりますが、どうしてもバラつきが出てしまうので記載粒度を標準化させたいという課題感があります。
何やらカタカナが多い
ここまでで用語がかなり出てきましたので一度意味をまとめておきます。
＊この後出てくる用語も載っています
工数算出をどう行なっているか
開発業に従事されてる方には悩みの種の一つとして上がることもあるのではないでしょうか。かく言うSSOもいまだにコイツの正体がよく分からないと感じる時があります。
しかしながらアジャイル開発を行う上で、経営層だったり社外のステークホルダーとの折衝を行う場面ではやはりコイツが必要になります。そんな正体不明の工数と仕入モールチームのこれまでと現在の取り組みになります。
プランニングポーカー
チーム発足当初に採用していた見積もり手法です。一般的な見積もりはある機能について実際の開発担当者が概算見積もりを行いタスクに着手しますが、チーム全員で見積もることで相対的に妥当と思しき数値を探っていく方法になります。
見積もり結果が恣意的または属人的な値になりにくいというメリットがあるものの、見積もりそのものにかなりの時間を要するという欠点がありました。(仮に見積もりのミーティング１時間に対して10人が参加した場合、工数的には10時間となります)
これでは見積もりだけでスプリントが終わってしまうので次の手法にシフトしていきます。
数値の一律設定型
ストーリーポイントを規模に関わらず一律３と設定する方式になります。（誰がどう見ても３未満のストーリーに対しては１や２を付ける場合もあります）
設定値が一律なので見積もりスピードは爆速になるものの、実際の対応規模とはどうしても乖離が発生してしまいます。もう少し現況一致する手法を探り、次の手法にシフトしていきます。
Tシャツサイジング（今ココ）
プランニングポーカー、一律設定を経て両者の中間的な手法としてTシャツサイジング(Tシャツ見積もり)に辿り着きました。
その名の通り規模をTシャツのサイズに擬える手法で、仕入モールチームではS/M/L/XLの４種類から選んでいく方法で取り組んでみています。実際のやり方としては
- これまでの実績をもとにした経験主義的な発想で議論する
- プランニングポーカーほど時間をかけない
- 一律設定ほどざっくり過ぎない
という具合に開発チーム内で対応規模をメンバー間で相互見積もりします。
最後に
いかがでしたでしょうか。仕入モールチームとしても解決すべきことはたくさんあり、その内容も日々変わっていく中で試行錯誤を繰り返しています。今回ご紹介したスクラム開発もチームの機動性を上げる点では力を発揮しますが、精密性においてはウォーターフォールに劣る部分もあります。
そうした部分を外部ツールや技術を使いながら改善していくことでプロダクトを今日よりも良くしていけるよう、仕入モールは今日も歩いていきます。
