SaaS開発における手戻りを減らすためのリファインメントの実践

物流業界向けのSaaS開発では、複雑なドメインや曖昧な要件など、多くのリスクが存在します。こうした課題に対処するため、私たちのチームは手戻りを減らすためのリファインメントの型化を実施しました。この経験を通じて得た知見を共有し、「リファインメントの現在地」についてお話しします。

【著者について】

- Portfolio: bicstone.me
- X(Twitter): @bicstone_me

【この資料で発表したイベント】

- みんなの「リファインメントの現在地」を語ろう！【Startup in Agile #2 】 - connpass

【お詫び】

このデッキはアクセシビリティに対応しておりません。ブログ記事化を予定しています。

© 2024 Oishi Takanori

Transcript

1. ハコベル株式会社 大石 貴則 (@bicstone) リファインメントの実践 SaaS開発における手戻りを減らすための (C) 2024 Oishi Takanori 2024/11/06 | Startup in Agile #2 みんなの「リファインメントの現在地」を語ろう！
2. Certified ScrumMaster® is a certification mark of Scrum Alliance, Inc. Any unauthorized use is strictly prohibited. 2 自己紹介 ハコベル株式会社 大石貴則 (@bicstone) 高専卒の元機械エンジニア。 インターネットが世の中を変えていく のを目の当たりにしWeb業界に転身。 現在はSaaSの開発を通じて物流業界の 課題解決に正面から向き合っている。 最近Duolingoはじめました。
3. https://findy-code.io/engineer-lab/bicstone_me Findy Engineer Labにインタビュー記事公開中！ Findy 大石 で [検索] 宣伝 3
4. 4 2022年: 物流DXの新プロジェクト立ち上げ プロダクトの背景 引用元: https://www.hacobell.com/optimization 配車計画業務をAIで支援し、効率化と属人性解消を目 指した新規事業SaaSのMVPへ向けた開発がスタート * MVP (Minimum Viable Product、実用最小限の製品)
5. 5 プロダクトの背景 アルゴリズムやUIの不確実性が存在するため、先行 導入した顧客と共同で仮説検証を実施 顧客からフィードバックを得ながら、アジャイルに プロダクト価値向上を目指す 先行導入顧客と協力しMVPを目指す → 要求の変化に機敏に対応するため スクラムチームを構築
6. なぜ実施する？ 何を話し合う？ どのタイミングで実施する？ これらの意識はどう浸透させる？ みなさんの事例も ぜひ教えてください！ 今日話すこと 弊チームにおける「リファインメントの現在地」 1 2 3 4 6
7. なぜ実施する？ 1 「選択に必要な◦◦◦を獲得する」ため スクラムガイド 2020年版 <https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf> ◦◦◦ ◦◦ ◦◦ 7
8. なぜ実施する？ 1 「選択に必要な透明性を獲得する」ため スクラムガイド 2020年版 <https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf> → スクラムの柱「透明性」を高める 透明性 検査 適応 8
9. 9 プロダクトゴールを再確認 ゴールに対する進捗の共通理解を形成 必要に応じてゴールの変更も実施 ゴールを元に優先度順にアイテムを並び替え 1～2スプリント後でやることを明確に チーム全体で優先順位の認識を揃える I. プロダクトバックログアイテムの優先順位 → 上位のアイテムを誰でも選択できる状態 2 何を話し合う？
10. 10 II. 上位のアイテムのブレイクダウンと明文化 2 何を話し合う？ Notionを用いてアイテムを作成 アイテムの価値 やらないこと・ブロッカー 議事録 受け入れ基準 受け入れテスト観点 → テンプレートを活用し 考慮漏れを防ぐ
11. 11 価値・やらないこと・ブロッカー 2～3スプリント前から議論して決めきる 議事録 意思決定の透明性を確保 受け入れ基準 アイテムごとに「完成」の共通理解を形成 スクラムガイドの「完成の定義」とは異なる 受け入れテスト観点 QAも巻き込むことで観点漏れを防止 2 何を話し合う？ II. 上位のアイテムのブレイクダウンと明文化
12. 12 プランニングポーカーによるポイント投票を実施 投票にあたって懸念がないことを確認 同時に投票することで個人の意思を可視化 8ポイント以上になった場合は分割を検討 アイテムを適切なサイズにし洗練 プロダクトバックログの肥大化を防止 III. 上位のアイテムの相対見積り → 見積りを通じてチーム内で合意を形成 2 何を話し合う？
13. 13 １日目: 改善・事務など ２日目: プランニング ９日目: リファインメント (1.5時間) 最終日: スプリントレビュー・レトロスペクティブ 毎日　: リファインメント (15分)・デイリースクラム ほぼ毎日リファインメントを開催 → 高頻度のリファインメントで新鮮な状態を確保 どのタイミングで実施する？ 3
14. 価値観を明文化したドキュメント ステークホルダー全員で合意する いつでも誰でも見られる場所に置く 定期的に見直しをして陳腐化を防ぐ チームのルールを作成 (Working Agreement) → スクラムガイドのチームの解釈を明確に 4 これらの意識はどう浸透させる？ 14
15. スクラムイベントの定義やアジェンダ メンバーの役割と行動規範 開発・レビュー・リリースの手順 意思決定における投票手法 Working Agreement ルールの例 4 これらの意識はどう浸透させる？ 15
16. 「選択に必要な透明性を獲得する」ために実施 テンプレートを活用し考慮漏れを防ぐ 上位のアイテムを誰でも選択できる状態 見積りを通じてチーム内で合意を形成 高頻度のリファインメントで新鮮な状態を確保 Working Agreementでスクラムガイドの解釈を明確に 大石 貴則 (@bicstone) 登壇資料 & SNS (bicstone.me) まとめ 16