Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スクラムエッセンス導入3ヶ月のチームに起きた変化
Search
hacomono Inc.
PRO
June 25, 2024
Technology
1
420
スクラムエッセンス導入3ヶ月のチームに起きた変化
株式会社hacomono UX本部 フロントエンジニア
進藤 渉
hacomono Inc.
PRO
June 25, 2024
More Decks by hacomono Inc.
See All by hacomono Inc.
hacomonoの品質とQA[Findy Job LT]
hacomono
PRO
0
130
社運懸かった大型機能をゼロから作り直した話
hacomono
PRO
0
86
MagicPodでモバイルアプリの”自動テスト”を最速で立ち上げよう
hacomono
PRO
1
210
専任担当からチームに還してQA全員で取り組むテスト自動化
hacomono
PRO
0
250
Nuxt 3ではじめるテスト導入戦略と初手
hacomono
PRO
0
29
Waroomとインシデントと私
hacomono
PRO
0
130
Product Engineer Night #6プロダクトエンジニアを育む仕組み・施策
hacomono
PRO
1
780
初めてアジャイルテストに挑戦してみたら、スクラムチームが良いサイクルを回し始めた話
hacomono
PRO
1
280
スクラムチームの品質戦略 1年の歩み
hacomono
PRO
1
450
Other Decks in Technology
See All in Technology
Data-centric AI入門第6章:Data-centric AIの実践例
x_ttyszk
0
190
Classmethod AI Talks(CATs) #14 司会進行スライド(2025.01.31) / classmethod-ai-talks-aka-cats_moderator-slides_vol14_2025-01-31
shinyaa31
0
120
開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience
kaminashi
0
150
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
6
56k
CNAPPから考えるAWSガバナンスの実践と最適化
nrinetcom
PRO
1
410
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
1
800
Datadog APM におけるトレース収集の流れ及び Retention Filters のはなし / datadog-apm-trace-retention-filters
k6s4i53rx
0
190
デザインから逆算して難易度を見積もるための観点
fumiyasac0921
0
110
Googleマップ/Earthが一般化した 地図タイルのイマ
mapconcierge4agu
1
180
Postman Vaultを使った秘密情報の安全な管理
nagix
3
230
マルチデータプロダクト開発・運用に耐えるためのデータ組織・アーキテクチャの遷移
mtpooh
1
400
A Hidden Pitfall of K8s DNS with Spring Webflux
musaprg
0
320
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
29
2.2k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Automating Front-end Workflow
addyosmani
1367
200k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Raft: Consensus for Rubyists
vanstee
137
6.8k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Designing for humans not robots
tammielis
250
25k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
Transcript
Last Update 2022.03.16 スクラムエッセンス導入3ヶ月のチームに起きた変化
簡単に自己紹介
◾ 所属 株式会社hacomono UX部 エンジニア ◾ すみか 大阪府 ◾ すき
do / 進藤 渉
hacomono UXチームの事例を通じて、 スクラムエッセンスの導入とチームに 起きた変化を紹介します
スクラムエッセンス 導入前のお話
hacomono UXチーム ユーザの顕在・潜在ニーズを探求し続け、期待を超え るユーザ体験(価値)を生み出し、より早くユーザに 届けられるチーム 目指すチーム像
hacomono UXチーム PdM デザイナー 開発エンジニア QAエンジニア
課題感 これまでは職能ごとに開発をバトンタッチしていた (いわゆるウォーターフォールに近い形) PRD (プロダクト要求仕様書) デザイン プログラム テスト
課題感 プログラミング中に仕様やデザインが実現できないと発覚 デザイン プログラム テスト 手戻り! PRD (プロダクト要求仕様書)
課題感 テスト中にクリティカルな問題を発見 PRD (プロダクト要求仕様書) デザイン プログラム テスト 手戻り!
課題感 前工程の遅延がテストフェーズへの負債になりがち PRD (プロダクト要求仕様書) デザイン プログラム テスト PRD (プロダクト要求仕様書) デザイン
プログラム テ ス ト 理想 現実
課題感 チーム全体の 機能理解が浅い? コミュニケーション が不足している? 後ろの工程になるほど リスクが大きいな・・ 全般的にシフトレフト できないかな? (特にテスト)
・・・と、前置きはここまで。 このような課題感を踏まえて、hacomono UXチームが 取り組んだことを紹介していきます!
取り組んだこと / チームに起きた変化
小さく作って、小さくテスト その1
これまで デザイン全部オワタ 実装ヨロシク! 実装全部オワタ テストヨロシク!
こうした デザイン一部オワタ 次の機能に取り掛かるね! 実装オワタ テストヨロシク!
• 開発全体の見通しが良くなった (透明性が上がった) • 開発の進捗が追いやすくなり、デザイン修正の タイミングを測りやすくなった
• 実装で考えることがシンプルになった • レビューもやりやすい • テストがシンプルになった • テストのシフトレフトを実現したことで、 無理のない稼働で安定した品質を確保できた
PRDとデザインを全員でレビューし 受け入れ条件を全員で考える その2
ホバーした時の 挙動どうなる? パフォーマンス みた方が良さそ う リストの並び順 は? スマフォでの 見え方は? ここで解決した
いユーザーの課 題は? こういう見せ方 にすると分かり やすいかも この条件はどう なってる? 本当にファース トリリースで対 応すべき? etc...
• 未検討や未伝達の仕様を洗い出せた • 意見交換が活発になり、どんな発言でも受け入れられる 土台ができた • 細かいデザインや挙動を全員で議論したことによって、 より洗練された
• やるべきことが明確になり、実装中に仕様を聞き回るこ とが減った(集中できた) • 不具合が減った • QAエンジニアだけでは気づき辛いようなテスト観点も 洗い出された • 役割を越えてQAエンジニア以外もテストに関心を持つ
ようになり、チーム全体の品質意識が向上した
プレQA その3
• チーム全体で実動作や仕様について共通認識を作れた • 動くものをベースに議論することで、解像度高く フィードバックサイクルを回せた
今のやり方を疑い、柔軟に変更する その4
全体進捗が見え 辛くなってきた からタスク管理 手法変えない? 会議体見直し て、作業時間増 やしたい 最初の方の実装 はペアプロしな い?
デイリーの「昨 日やったこと」 本当に必要? デザインプロセ ス見直したい QAでモブテスト やらない? Working Agreement 作らない? タスクは1日で終 わる粒度で細分 化しては? etc...
• スクラムエッセンスを取り入れた当初と比べて、 格段に開発チームとして成長した ◦ コミュニケーションの質の向上 ◦ 開発プロセスの最適化 ◦ フロー効率の向上 •
変更したらそれで終わりではなく、 定期的に見直して更なる改善サイクルを回せている
まとめ
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
ユーザの顕在・潜在ニーズを探求し続け、期待を超え るユーザ体験(価値)を生み出し、より早くユーザに 届けられるチーム UXチームの 目指すチーム像 これまでの取り組みで、ある程度の余白が生まれた 今後はこの余白で価値に向き合い、それをより早くリ リースすることに取り組んでいきたい