SlideShare una empresa de Scribd logo
1 de 97
はじめてのアジャイルのその後
ーシン・サービス立ち上げ、スクラムぽくなってきたー
Apr/13/2017 at Agile Japan 2017
Reina Otsuka
New Service Development Supervisory Department,
Rakuten, Inc.
https://agriculture.rakuten.co.jp/
2
自己紹介
3
大塚 怜奈
Otsuka Reina
 楽天株式会社
 2010年に新卒で入社
 Webアプリケーションエンジニア
 チームコンダクター
 プロダクトオーナーはじめました
Background
2010. Arp.
2016. May.
Rakuten入社
- 0からのソフトウェア開発
2013. Mar. キレイドナビリリース
- はじめての0から立ち上げ
2015. May. エンジニアリーダー
- 9人チームのリーダーに
2016. Apr. RaCareリリース
-リーダーとして立ち上げ
新サービスカンパニーに異動
-新たなチーム構築
2017. Mar. Ragri リリース
-新たなチームでサービスの立ち上げ
Background
2010. Arp.
2016. May.
Rakuten入社
- 0からのソフトウェア開発
2013. Mar. キレイドナビリリース
- はじめての0から立ち上げ
2015. May. エンジニアリーダー
- 9人チームのリーダーに
2016. Apr. RaCareリリース
-リーダーとして立ち上げ
新サービスカンパニーに異動
-新たなチーム構築
2017. Mar. Ragri リリース
-新たなチームでサービスの立ち上げ
Wellness And Healthcare
Team
Ragri Team
Background
2010. Arp.
2016. May.
Rakuten入社
- 0からのソフトウェア開発
2013. Mar. キレイドナビリリース
- はじめての0から立ち上げ
2015. May. エンジニアリーダー
- 9人チームのリーダーに
2016. Apr. RaCareリリース
-リーダーとして立ち上げ
新サービスカンパニーに異動
-新たなチーム構築
2017. Mar. Ragri リリース
-新たなチームでサービスの立ち上げ
Wellness And Healthcare
Team
Wellness And Healthcare Team
7
男性
女性
20代
30代
40代新卒
中途
未婚
既婚
Partner
Proper
前衛的 保守的
Engineer
Product Owner
Project Leader
卒業
新加入
8
Wellness And Healthcare Team
• アジャイルの手法を使って、
ちょっとだけチームが改善された
強いチームをつくる
Story of Wellness And Healthcare Team
9
https://www.slideshare.net/leinaotsuka/agile-in-2016
• アジャイル何それ?のチーム
• 改善
• Morning Stand Up MTG
• Kanban
• KPT
• Scrumへの挑戦
• 改善を楽しめるチームへ
Today’s story
2010. Arp.
2016. May.
Rakuten入社
- 0からのソフトウェア開発
2013. Mar. キレイドナビリリース
- はじめての0から立ち上げ
2015. May. エンジニアリーダー
- 9人チームのリーダーに
2016. Apr. RaCareリリース
-リーダーとして立ち上げ
新サービスカンパニーに異動
-新たなチーム構築
2017. Mar. Ragri リリース
-新たなチームでサービスの立ち上げ
Ragri Team
11
4月5日
Ragri(ラグリ)
オープン
Today’s Story
12
迫る現実
手探り
ベンダー開発
新しいチーム
新しいビジネス
0からの立ち上げ
リモートでのコミュニケーション
リリース直前のどんでん返し
Face to face の大切さ
開発プロセス大改造
ベンダーとsprintをまわしていく
Today’s Story
13
今日のお話
Today’s Story
14
ウォーターフォールからスクラムへ
しなやかなチームをつくる
Attention
15
• アジャイル, アジャイルな話ではあ
りません
• 特効薬の話ではありません
• アジャイルの手法を使って、改善
された一例です
Team
16
Business Owner
Farmers
Business Unit
Development Unit
UX & Design Unit
ME
Ragri Story
17
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep. 開発メンバーどんどん増える
2016. Oct.
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
QA & Security Audit
Ragri Story
18
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep. 開発メンバーどんどん増える
2016. Oct.
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
QA & Security Audit
リーンに
開発したいな!
Ragri Story
19
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep. 開発メンバーどんどん増える
2016. Oct.
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
QA & Security Audit
要件定義
Ragri Story
20
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep. 開発メンバーどんどん増える
2016. Oct.
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
QA & Security Audit
え、機能が盛り盛り
Ragri Story
21
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep. 開発メンバーどんどん増える
2016. Oct.
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
QA & Security Audit
開発対象
機能一覧の合意
Ragri Story
22
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep. 開発メンバーどんどん増える
2016. Oct.
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
人がいない!
ベンダー策定
QA & Security Audit
Ragri Story
23
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep. 開発メンバーどんどん増える
2016. Oct.
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
仕様書/WF/
デザインのレビュー
QA & Security Audit
Ragri Story
24
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep. 開発メンバーどんどん増える
2016. Oct.
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始 開発スタート
QA & Security Audit
Ragri Story
25
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep. 開発メンバーどんどん増える
2016. Oct.
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
あれ、
ウォーターフォー
ルっぽい
QA & Security Audit
Ragri Story
26
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep.
2016. Oct.
QA & Security Audit
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
メンバーどんどん
増える
開発メンバーどんどん増える
Team
27
Business Owner
Farmers
Business Unit
Development Unit
UX & Design Unit
ME
Ragri Story
28
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep.
2016. Oct.
QA & Security Audit
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
内部テスト開始
開発メンバーどんどん増える
Ragri Story
29
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep.
2016. Oct.
QA & Security Audit
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
リリースまで
もう少し!
開発メンバーどんどん増える
Ragri Story
30
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep.
2016. Oct.
QA & Security Audit
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
やっとこ
社内リリース
開発メンバーどんどん増える
Ragri Story
31
2016. May.
2016. Nov.
Project Start
2016. July. 仕様策定&設計開始
2016. Sep.
2016. Oct.
QA & Security Audit
Ragri 社内リリース
2016. Dec. Ragri 社外リリース延期!
2017. Jan. Ragri 社内フルリリース
2016. Aug. 開発開始
延期!!!
開発メンバーどんどん増える
32
Retrospective
33
• 参加者
• Business Owner
• Business Unit
• UX & Design Unit
• Development Unit
• 目的
• Project Startからいままでの
振り返り
• 今後のプロセス改善を検討
Retrospective
34
• Business Owner /
Business Unit / UX &
Design Unit /
Development Unit それ
ぞれの視点で振り返り
Business Owner’s wants
35
• ほしかった機能がない
• 実物を触ってみないと
わからない
• もっと開発スピードを
あげたい
36
どうする?
Agile Coach
37
38
スクラムを
導入してみては?
Word of Agile Coach
Business Owner’s wants
39
• ほしかった機能がない
• 実物を触ってみないと
わからない
• もっと開発スピードを
あげたい
• 次月に開発するものの
優先度を一緒に決める
• Demo日を決めて、一
緒に確認する
• 2週間のSprintで進めて、
リリースできるものか
らリリースする
Team
40
Business Owner
Farmers
Business Unit
Development Unit
UX & Design Unit
ME
41
どうやって実現する?
3 Steps for changing
42
1. Business Unit / UX & Design Unit /
Development Unit でアジャイル講習
2. 開発チームみんなでスクラムワーク
ショップ
3. プロセス大改造プラン
3 Steps for changing
43
1. Business Unit / UX & Design Unit /
Development Unit でアジャイル講習
2. 開発チームみんなでスクラムワーク
ショップ
3. プロセス大改造プラン
Step 1 : Small Lecture of Agile
44
https://www.slideshare.net/kawaguti/jikkan-kudo
• 参加者
• Business Owner
• Business Unit
• UX & Design Unit
• Development Unit
• 目的
• アジャイルとは何かの共通認識
をもつ
• 今後のプロセス改善を導入する
Step 1 : Small Lecture of Agile
45
https://www.slideshare.net/kawaguti/jikkan-kudo
Step 1 : Small Lecture of Agile
46
https://www.slideshare.net/kawaguti/jikkan-kudo
https://speakerdeck.com/kawaguti/jikkan-kudo
要件は小さく砕く
分類する
優先度決める
47
Business Owner
Business Unit
Development Unit
UX & Design Unit
ME
開発の進め方が、実感を
もって理解できた!
この進め方を試したい!
開発について、
ちょっと理解
できた
アジャイルについて、
イメージができた!
Step 1 : Small Lecture of Agile
3 Steps for changing
48
1. Business Unit / UX & Design Unit /
Development Unit でアジャイル講習
2. 開発チームみんなでスクラムワーク
ショップ
3. プロセス大改造プラン
49
Development Unit
ME
Step 2 : Scrum workshop with members
• 参加者
• Project Leader
• Product Owner
• Developer
• Tester
• 目的
• スクラムプロセスを実感して
もらう
• 実施内容
• レゴを使ったスクラムシュミ
レーションワークショップ
Step 2 : Scrum workshop with members
50
Planning
Sprint
Retrospective
のスクラムを実感
• ストーリーポイント
での見積もり
• ROIに基づいた優先
順位決め
• DONEの定義
51
Step 2 : Scrum workshop with members
• チームで進めることを実感できた
• 実績に基づいての見積もり方法が
わかった
• 優先順位の高いものからタスクを
行っていくことの重要性を理解で
きた
• Retrospectiveを行うことで改善さ
れることを体験できた
3 Steps for changing
52
1. Business Unit / UX & Design Unit /
Development Unit でアジャイル講習
2. 開発チームみんなでスクラムワーク
ショップ
3. プロセス大改造プラン
Step 3 : Changing planning way
53
• プロダクトバックロ
グとして、要件を
カードに書く
• カードに書ける大き
さの要件に砕く
• 定常作業もカードに
書き出す
チケット番号
チケット内容
54
Step 3 : Changing planning way
• リアルを使って、要
件をビジネスオー
ナーと合意する
Step 3 : Changing planning way
55
• ストーリーポイント
で見積もる
Step 3 : Changing planning way
56
• 1ヶ月に開発チームが消化
できそうなストーリーポイ
ントを決める
• ビジネスオーナーと一緒に、
優先順位を決める
• 2ヶ月分のタスクの優先順
位を決めておく
• リリース作業等の定常作業
分も見積もる
Step 3 : Changing planning way
57
• ボードに並べて、
Sprintの準備OK
58
れっつ、すたーと
Sprint
2017 February
Mon Tue Wed Thu Fri Sat Sun
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 1 2
59
Release
Release
DEMO
KPT
Sprint way
60
1. Morning Stand Up MTG
2. Kanban
3. DEMO
4. KPT
Sprint way
61
1. Morning Stand Up MTG
2. Kanban
3. DEMO
4. KPT
Morning Stand Up MTG
62
それぞれの
• 昨日やったこと
• 今日やること
• 困っていること
Morning Stand Up MTG
63
それぞれの
• 昨日やったこと
• 今日やること
• 困っていること
毎日進捗確認
ゴールの設定
リスクの共有
Morning Stand Up MTG
64
• タスクを共有することでチーム
全体の進捗をメンバーが意識す
るようになった
• リスクのキャッチアップがはや
くなった
Sprint way
65
1. Morning Stand Up MTG
2. Kanban
3. DEMO
4. KPT
Kanban
66
67
Kanban
67
Backlog
Kanban
68
Backlog
Sprint 10days
Kanban
69
Backlog
Sprint 10days
Doi
ng
Kanban
70
Backlog
Sprint 10days
Doi
ng
DO
NE
Kanban
71
Backlog
Sprint 10days
Doi
ng
DO
NE
Today
タスクがカードが
残っていたら計画から遅延
Kanban
72
• タスクを見える化することで
チーム全員でタスクの消化に取
り組む雰囲気ができた
• チーム外メンバーにも実施内容
が見えるようになった
• タスクの入れ替えが柔軟になっ
た
Sprint way
73
1. Morning Stand Up MTG
2. Kanban
3. DEMO
4. KPT
DEMO
74
• 画面遷移を見える化
• Wireframeを実機で確認
• 実際に動きを
見ながら確認
DEMO
75
• 仕様に関する認識違いが減った
• 仕様の合意を取りやすくなった
• プロダクトの全体や遷移を把握
しやすくなった
Sprint way
76
1. Morning Stand Up MTG
2. Kanban
3. DEMO
4. KPT
KPT
77
• KPT
振り返りの為のフレームワーク。
Keepでは、「良かった事」を
Problemでは、「改善点」をそ
れをもとに、
Tryでは、Problemに対する「改
善案」をあげいく
KPT
78
Keep Problem
4つのTryを策定
KPT
79
February March
Total
1st 2nd 1st 2nd
Keep - 23 23
Problem - 34 34
Try - 4 4
Look back February
80
• 開発チームの進捗が見える化された
• チーム全体で進めている感がでてき
た
• 柔軟にタスクの入れ替えができるよ
うになった
• 認識違いが減った
Storypoints
81
0
30
60
90
February March
Storypoint Planned
2017 March
Mon Tue Wed Thu Fri Sat Sun
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 28 30 31
82
Release
Release DEMOKPT
KPT
Sprint way
83
1. Morning Stand Up MTG
2. Kanban
3. DEMO
4. KPT
Morning Stand Up MTG
84
それぞれの
• 昨日やったこと
• 今日やること
• 困っていること
毎日進捗確認
ゴールの設定
リスクの共有
Kanban
85
Backlog
Sprint 10days
Doi
ng
DO
NE
Today
タスクがカードが
残っていたら計画から遅延
Next Sprint
DEMO
86
KPT
87
February March
Total
1st 2nd 1st 2nd
Keep - 23 25 24 72
Problem - 34 24 27 85
Try - 4 4 3 11
11歩前進できた!
Look back March
88
• チーム全体で進めている感が
でてきた
• 認識違いが減った
• 柔軟にタスクの入れ替えがで
きるようになった
• 突発に対応できるようになっ
た
• システム改善の時間が確保で
きるようになった
Storypoints
89
0
30
60
90
February March
Storypoint Planned
Look back
90
 Ragriチームの一体感がでてきた
 認識のずれが減ってきた
 柔軟にタスクの対応ができるように
なった
 対応できるストーリー
ポイントが増えた
 月2回の計画リリースが
できた
91
2ヶ月で
改善された!!
Today’s Story
92
ウォーターフォールからスクラムへ
しなやかなチームに
Today’s Story
93
これから
94
よりよいサービスを
創るために
さらなる改善を
Today’s Story
95
お知らせ
96
https://corp.rakuten.co.jp/careers/engineering/
WE'RE HIRING
Ragri(ラグリ)を一緒に
創っていってくれる方を
募集しております!
ぜひ、ご連絡ください。
97
ご清聴、ありがとうございました!

Más contenido relacionado

La actualidad más candente

NaITE(長崎IT技術者会) オープニング資料
NaITE(長崎IT技術者会) オープニング資料NaITE(長崎IT技術者会) オープニング資料
NaITE(長崎IT技術者会) オープニング資料Takayuki Ujita
 
世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクス
世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクス世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクス
世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクスHiroyuki Ito
 
世界最大級のアジャイルカンファレンス報告:Agile2016参加レポート
世界最大級のアジャイルカンファレンス報告:Agile2016参加レポート世界最大級のアジャイルカンファレンス報告:Agile2016参加レポート
世界最大級のアジャイルカンファレンス報告:Agile2016参加レポートHiroyuki Ito
 
DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道Arata Fujimura
 
XP祭り2016でAgile2016を語る
XP祭り2016でAgile2016を語るXP祭り2016でAgile2016を語る
XP祭り2016でAgile2016を語るHiroyuki Ito
 
Jasst16 tokyo 参加報告
Jasst16 tokyo 参加報告Jasst16 tokyo 参加報告
Jasst16 tokyo 参加報告Takayuki Ujita
 
SAP TechEd 2019 歩き方セッション「ブロガーがみてきたSAP TechEd 2018」
SAP TechEd 2019 歩き方セッション「ブロガーがみてきたSAP TechEd 2018」SAP TechEd 2019 歩き方セッション「ブロガーがみてきたSAP TechEd 2018」
SAP TechEd 2019 歩き方セッション「ブロガーがみてきたSAP TechEd 2018」MasashiOtsuka1
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドHiroyuki Ito
 
SaPID を導入するまでとそれから
SaPID を導入するまでとそれからSaPID を導入するまでとそれから
SaPID を導入するまでとそれからLIFULL Co., Ltd.
 
CTOの考えるエンジニアマネジメント2
CTOの考えるエンジニアマネジメント2CTOの考えるエンジニアマネジメント2
CTOの考えるエンジニアマネジメント2LIFULL Co., Ltd.
 
スクラムマスターはじめのいっぽ
スクラムマスターはじめのいっぽスクラムマスターはじめのいっぽ
スクラムマスターはじめのいっぽTakeba Misa
 
LIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっている
LIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっているLIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっている
LIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっているLIFULL Co., Ltd.
 
サイボウズQAの働き方
サイボウズQAの働き方サイボウズQAの働き方
サイボウズQAの働き方Cy1DayCy1Day
 
RubyKaigi 2015 の Drinkup を支える技術
RubyKaigi 2015 の Drinkup を支える技術RubyKaigi 2015 の Drinkup を支える技術
RubyKaigi 2015 の Drinkup を支える技術Koichi ITO
 
品質保証を体験しよう
品質保証を体験しよう品質保証を体験しよう
品質保証を体験しようCy1DayCy1Day
 
Agile Discussion 1st
Agile Discussion 1stAgile Discussion 1st
Agile Discussion 1stTakao Kimura
 
Agile development-course-advanced-15
Agile development-course-advanced-15Agile development-course-advanced-15
Agile development-course-advanced-15Miho Nagase
 

La actualidad más candente (20)

NaITE(長崎IT技術者会) オープニング資料
NaITE(長崎IT技術者会) オープニング資料NaITE(長崎IT技術者会) オープニング資料
NaITE(長崎IT技術者会) オープニング資料
 
世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクス
世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクス世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクス
世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクス
 
世界最大級のアジャイルカンファレンス報告:Agile2016参加レポート
世界最大級のアジャイルカンファレンス報告:Agile2016参加レポート世界最大級のアジャイルカンファレンス報告:Agile2016参加レポート
世界最大級のアジャイルカンファレンス報告:Agile2016参加レポート
 
DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道
 
XP祭り2016でAgile2016を語る
XP祭り2016でAgile2016を語るXP祭り2016でAgile2016を語る
XP祭り2016でAgile2016を語る
 
Jasst16 tokyo 参加報告
Jasst16 tokyo 参加報告Jasst16 tokyo 参加報告
Jasst16 tokyo 参加報告
 
SAP TechEd 2019 歩き方セッション「ブロガーがみてきたSAP TechEd 2018」
SAP TechEd 2019 歩き方セッション「ブロガーがみてきたSAP TechEd 2018」SAP TechEd 2019 歩き方セッション「ブロガーがみてきたSAP TechEd 2018」
SAP TechEd 2019 歩き方セッション「ブロガーがみてきたSAP TechEd 2018」
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
 
YAPC2014_day2_LT_GeekDojo
YAPC2014_day2_LT_GeekDojoYAPC2014_day2_LT_GeekDojo
YAPC2014_day2_LT_GeekDojo
 
SaPID を導入するまでとそれから
SaPID を導入するまでとそれからSaPID を導入するまでとそれから
SaPID を導入するまでとそれから
 
system testing in Scrum
system testing in Scrumsystem testing in Scrum
system testing in Scrum
 
CTOの考えるエンジニアマネジメント2
CTOの考えるエンジニアマネジメント2CTOの考えるエンジニアマネジメント2
CTOの考えるエンジニアマネジメント2
 
スクラムマスターはじめのいっぽ
スクラムマスターはじめのいっぽスクラムマスターはじめのいっぽ
スクラムマスターはじめのいっぽ
 
LIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっている
LIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっているLIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっている
LIFULLでは新卒エンジニアに 丸一日のテスト研修を行なっている
 
進捗と品質
進捗と品質進捗と品質
進捗と品質
 
サイボウズQAの働き方
サイボウズQAの働き方サイボウズQAの働き方
サイボウズQAの働き方
 
RubyKaigi 2015 の Drinkup を支える技術
RubyKaigi 2015 の Drinkup を支える技術RubyKaigi 2015 の Drinkup を支える技術
RubyKaigi 2015 の Drinkup を支える技術
 
品質保証を体験しよう
品質保証を体験しよう品質保証を体験しよう
品質保証を体験しよう
 
Agile Discussion 1st
Agile Discussion 1stAgile Discussion 1st
Agile Discussion 1st
 
Agile development-course-advanced-15
Agile development-course-advanced-15Agile development-course-advanced-15
Agile development-course-advanced-15
 

Destacado

スタートアップを陰ながら支えるときに心がけるべき5ヶ条
スタートアップを陰ながら支えるときに心がけるべき5ヶ条スタートアップを陰ながら支えるときに心がけるべき5ヶ条
スタートアップを陰ながら支えるときに心がけるべき5ヶ条Atsumi Kawashima
 
絶望と最後の希望
絶望と最後の希望絶望と最後の希望
絶望と最後の希望Tatsuya Sato
 
コーポラティブハウスを建ててみた
コーポラティブハウスを建ててみたコーポラティブハウスを建ててみた
コーポラティブハウスを建ててみたJun Inose
 
20140823 devlove甲子園
20140823 devlove甲子園20140823 devlove甲子園
20140823 devlove甲子園Mitsuo Hangai
 
RO装置から取り組む 除錆方法の検討
RO装置から取り組む 除錆方法の検討RO装置から取り組む 除錆方法の検討
RO装置から取り組む 除錆方法の検討akihiko kondo
 
Java ee7 with apache spark for the world's largest credit card core systems, ...
Java ee7 with apache spark for the world's largest credit card core systems, ...Java ee7 with apache spark for the world's largest credit card core systems, ...
Java ee7 with apache spark for the world's largest credit card core systems, ...Rakuten Group, Inc.
 

Destacado (6)

スタートアップを陰ながら支えるときに心がけるべき5ヶ条
スタートアップを陰ながら支えるときに心がけるべき5ヶ条スタートアップを陰ながら支えるときに心がけるべき5ヶ条
スタートアップを陰ながら支えるときに心がけるべき5ヶ条
 
絶望と最後の希望
絶望と最後の希望絶望と最後の希望
絶望と最後の希望
 
コーポラティブハウスを建ててみた
コーポラティブハウスを建ててみたコーポラティブハウスを建ててみた
コーポラティブハウスを建ててみた
 
20140823 devlove甲子園
20140823 devlove甲子園20140823 devlove甲子園
20140823 devlove甲子園
 
RO装置から取り組む 除錆方法の検討
RO装置から取り組む 除錆方法の検討RO装置から取り組む 除錆方法の検討
RO装置から取り組む 除錆方法の検討
 
Java ee7 with apache spark for the world's largest credit card core systems, ...
Java ee7 with apache spark for the world's largest credit card core systems, ...Java ee7 with apache spark for the world's largest credit card core systems, ...
Java ee7 with apache spark for the world's largest credit card core systems, ...
 

Similar a はじめてのアジャイルのその後 ーシン・サービス立ち上げ、スクラムぽくなってきたー

僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!Yasui Tsutomu
 
Agile development-course-advanced-3-4
Agile development-course-advanced-3-4Agile development-course-advanced-3-4
Agile development-course-advanced-3-4Miho Nagase
 
「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」大貴 蜂須賀
 
Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理You&I
 
ナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるためにナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるためにRecruit Lifestyle Co., Ltd.
 
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかたふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかたYoshitaka Kawashima
 
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~InnovationSprint2011
 
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~You&I
 
SPI Japan2016発表資料
SPI Japan2016発表資料SPI Japan2016発表資料
SPI Japan2016発表資料Reiko Rikuno
 
はじめてがアジャイル
はじめてがアジャイルはじめてがアジャイル
はじめてがアジャイルKenichi Takahashi
 
Agile development-course-advanced-13-14
Agile development-course-advanced-13-14Agile development-course-advanced-13-14
Agile development-course-advanced-13-14Miho Nagase
 
QAファンネル振り返り術
QAファンネル振り返り術QAファンネル振り返り術
QAファンネル振り返り術JumpeiIto2
 
Stripeを1年使ってみて思ったこと
Stripeを1年使ってみて思ったことStripeを1年使ってみて思ったこと
Stripeを1年使ってみて思ったことtomoaki koshi
 
アジャイル開発&TFS導入
アジャイル開発&TFS導入アジャイル開発&TFS導入
アジャイル開発&TFS導入You&I
 
リモートチームとふりかえり改善フレームワーク
リモートチームとふりかえり改善フレームワークリモートチームとふりかえり改善フレームワーク
リモートチームとふりかえり改善フレームワークMaehana Tsuyoshi
 
チームにRedmineを適用せよ! #RxTstudy
チームにRedmineを適用せよ! #RxTstudyチームにRedmineを適用せよ! #RxTstudy
チームにRedmineを適用せよ! #RxTstudyDai FUJIHARA
 
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年verソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年verKosuke Fujisawa
 

Similar a はじめてのアジャイルのその後 ーシン・サービス立ち上げ、スクラムぽくなってきたー (20)

僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!僕らのおれおれメトリクス / We Metrics Our Own Way!
僕らのおれおれメトリクス / We Metrics Our Own Way!
 
Agile development-course-advanced-3-4
Agile development-course-advanced-3-4Agile development-course-advanced-3-4
Agile development-course-advanced-3-4
 
「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」
 
Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理Pivotal Trackerでアジャイルなプロジェクト管理
Pivotal Trackerでアジャイルなプロジェクト管理
 
[デブサミ関西2013]チケット駆動で プロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動で プロジェクトチームを加速せよ
 
Scrum
ScrumScrum
Scrum
 
Scrum"再"入門
Scrum"再"入門Scrum"再"入門
Scrum"再"入門
 
ナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるためにナレッジを共有する文化をつくるために
ナレッジを共有する文化をつくるために
 
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかたふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
 
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
イノベーションスプリント2011 infragisticsにおける世界分散アジャイル開発事例~ communication matters ~
 
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~
No Managers, Yes Agile. ~アジャイルなプロジェクト管理とは~
 
SPI Japan2016発表資料
SPI Japan2016発表資料SPI Japan2016発表資料
SPI Japan2016発表資料
 
はじめてがアジャイル
はじめてがアジャイルはじめてがアジャイル
はじめてがアジャイル
 
Agile development-course-advanced-13-14
Agile development-course-advanced-13-14Agile development-course-advanced-13-14
Agile development-course-advanced-13-14
 
QAファンネル振り返り術
QAファンネル振り返り術QAファンネル振り返り術
QAファンネル振り返り術
 
Stripeを1年使ってみて思ったこと
Stripeを1年使ってみて思ったことStripeを1年使ってみて思ったこと
Stripeを1年使ってみて思ったこと
 
アジャイル開発&TFS導入
アジャイル開発&TFS導入アジャイル開発&TFS導入
アジャイル開発&TFS導入
 
リモートチームとふりかえり改善フレームワーク
リモートチームとふりかえり改善フレームワークリモートチームとふりかえり改善フレームワーク
リモートチームとふりかえり改善フレームワーク
 
チームにRedmineを適用せよ! #RxTstudy
チームにRedmineを適用せよ! #RxTstudyチームにRedmineを適用せよ! #RxTstudy
チームにRedmineを適用せよ! #RxTstudy
 
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年verソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
 

はじめてのアジャイルのその後 ーシン・サービス立ち上げ、スクラムぽくなってきたー

Notas del editor

  1. 15 sec / slide はじめてのアジャイルのその後 新サービス立ち上げ、スクラムぽくなってきたというタイトルで、 楽天株式会社、新サービスカンパニーの大塚 が発表させていただきます。
  2. まずは、自己紹介です
  3. 大塚怜奈と申します。 楽天株式会社に2010年に新卒で入社しました。 WEBアプリケーションエンジニアとして従事してまして。 最近は、チームコンダクターとプロダクトオーナーの役割をやっております。
  4. 経歴を紹介させていただくと、 楽天において、いくつかの新サービスの立ち上げに携わってきたした。 2013年にキレイドナビというサービスの立ち上げに、いちWEBアプリケーションエンジニアとして携わりました。その後、そのチームのエンジニアリーダーをやらせていただき、そのチームで、新たなサービス、RaCareの立ち上げを行いました。そして、去年、新サービスカンパニーにひとり移動し、0からのチーム構築を行いながら、Ragriのサービス立ち上げを行いました。
  5. 経歴を大きく分けると、2つに分けられまして、 キレイドナビとRaCareのリリースは、wellness and healthcare teamとして、 Ragriの立ち上げは、新しいRagriチームで行いました。
  6. Wellness and healthcare teamでは、
  7. 20代、30代、40代、パートナー、プロパーと 様々なバックグラウンドと持って、 それぞれの仕事に対する姿勢も違うチームにおいて、
  8. 強いチーム作るべく、アジャイルの手法を使って改善を行いました
  9. 改善の過程は、はじめてのまいあじゃいるというスライドで公開しているので、 ご興味ある方は、こちらを見ていただけると幸いです。
  10. 本日の話は、その後の、新しい部署に移動し、0から構築したラグリチームでのお話になります。
  11. ここで、ラグリとはなんぞやという話なのですが、 つい先日の4月5日にラグリをオープンさせていただきました。 みなさん、ぜひ、検索してみてください。
  12. ラグリという新しいサービスをたちあげるにあたって、 0からチームを構築し、ベンダーさんと開発を行いました。 大きな特徴としては、ビジネスオアーナーは、社外にいることと、 現在は、ベンダーさんと一緒にsprintまわすようになっております。
  13. 3min 13:03 15 sec /slide ということで、きょうの話は、
  14. ラグリを立ち上げるなかで、 ウォーターフォール型からスクラムへ変革へ しなやかなチームをつくるプロセスについてお話させていただきます
  15. 注意としては、アジャイルアジャヤいるな話ではありません 特効薬の話ではありません アジャイルの手法と使って、チームが改善された一例です
  16. ラグリチーム、プロジェクトが始まったときにどんなチームかというと、 ビジネスオーナーがいて、ビジネスサイドのメンバーがいて、UX デザインのメンバーがいて、 開発のメンバーがいました。 開発メンバーのうちの一人がわたしになります。 人数もスライドのような人数でした。 また、ラグリは、農家とユーザーをつなぐプラットフォームになります。 そのため、利用者としての農家さんがいます。
  17. ラグリがリリースされるまでにどういった流れかというと 去年の5月にプロジェクトがはじまりました
  18. 立ち上げ当初は人数も数なく、ぜひ、リーンな開発にしたいなという意気込みを一人もっていました
  19. 要件定義のフェーズの段階になって、ビジネスオーナーやビジネスサイトのメンバーを話を詰めていくと
  20. あれ、機能がモリモリ。
  21. どの機能も必要とのこと。 せめて、優先順位とリリースに必要なものは決めましょうと一覧を作って、合意をとりました。
  22. よし!機能一覧の合意をとったらと思ったら、作り人がいない!ということで、ベンダー策定して、 ベンダー開発なプロジェクトとなりました。
  23. ベンダーが無事にきまって、 仕様書/Wireframe/デザインを決め、 ビジネスオーナーのレビューをもらって、
  24. 8月ころに開発スタート!
  25. ふと、気づいたときには、 リリースターゲットとリリース日がなぜか決まっていて、 フローがウォーターフォールっぽい感じになっていると気づきました
  26. 開発が遅延するので、メンバーどんどん増え、
  27. 9月には、このような状況で、 開発メンバーが最大30人超えるようになりました
  28. 紆余曲折しながらも、内部テストにこぎつけ
  29. QAとセキュリティ監査を行い
  30. 一部機能を社内リリースすることができました
  31. そして、12月に社外リリースを行う予定だったのですが、 ここで大どんでん返し、上層部の判断で社外リリースが延期になりました
  32. もう、こんな感じですよね。 社外リリースに向けて必死に進めていたのに延期なんて。 延期の理由としては、社外にいるビジネスオーナーが社外リリースに対して 難色しめしたためでした。 なんで、その判断になったのを確かめるために行ったのが、
  33. このときこのプロジェクトとしてはじめて、 ビジネスオーナーとビジネスメンバー、UXデザインメンバー開発メンバーで プロジェクト開始からそのときまでの振り返りを行いました
  34. 付箋でそれぞれのチーム視点での振り返りを共有し、
  35. ビジネスオーナーとしての思いとして、わかったことが、 まずは、ほしかった機能がなかった。プロジェクト始まりのときに、機能一覧と優先順位を決めて合意をとったつもりでいたのですが、本当につもりだっただけで、全く納得していなかったことがこのときにわかりました。 みなさんにもありませんかね?こんな経験。 そして、fireframe等で画面イメージは共有して合意をとったはずなのですが、いや、触ってみたら思っていたのと違った。また、社内リリースまで見れる機能が何もないって、なんでそんなにかかるんだ! ということでした
  36. ビジネスオアーナーの合意がないとリリースはできない、 はて、どうしよ。。。
  37. そのとき、社内のアジャイルコーチにアドバイスをもとめました。
  38. 賢者曰く、スクラムを導入してみては?
  39. ということで、ビジネスオーナー欲しかった機能がないということには、次月に開発するものの優先度を紙を使いながら一緒に決めることにしました。 実物を触ってみないとわからないという要望に関しては、 月に1回から2回のDemo日を決めて、ビジネスオーナーと一緒に確認しました。 もと開発スピードあげたいということには、2週間のSprintで進めて、リリースレディなものからリリースすることとアドバイスをいただきました、 なんかよさげな気がする!ということで、
  40. ウォーターフォールになれたこのチームで
  41. 10min 13:10 15 sec / slide どうやって実現しようか
  42. ということで、プロセス変更に向けて、3つのステップを踏みました。 それぞれのステップで具体的に何をやったかをお話させていただきます
  43. まず、開発チーム以外のチームメンバーにもアジャイル講習をうけてもらいました
  44. チーム全体に、社内アジャイルコーチの川口さんにアジャイルとは何かの講義をしていただきました。 アジャイルを導入するには、ビジネスオーナー、ビジネスメンバーの理解が必要だと考えたためです。 これによって、アジャイルとは何かの共通認識をチームでもち、 今後のプロセス改善の導入しやすい環境にしました。
  45. 話していただいた内容は、 機能は大きく作らず、小さく作って、常に改善リリースすることのメリットについて。
  46. そして、要件を小さくして、優先度をきめ、 ビジネス的に価値のあることから作りましょうという アジャイルのシンプルで重要な話をしていただきました。
  47. この講義によって、 開発についてあまり知らないビジネスオーナーにも、開発フローについて理解していただき、 ビジネスサイドにもこの進め方を試したいといった同意を得ることができました。
  48. 次に開発チームでのスクラムワークショップについてです。
  49. ベンダーさんもふくむ開発チームみんなでスクラムのワークショップを実施しました 目的としては、ウォーターフォール型になれたメンバーに、スラクムのプロセスを肌で実感してもらうことです。
  50. ワークショップのなかで、プランニング/スプリント/振り返りのプロセスを実感していただき、 ストーリーポイントでの見積もり、ROIに基づいた優先順位決め、DONEの定義を デベロッパー、テスターの方全員に体験していただきました。
  51. これにより、リーダーの指示のもと個々人で進めていた雰囲気の開発チームが、 チームで進めることを時間していただきました また、スプリントを行って、その実績に基づいた見積もり方法を理解していただきました 優先順位の高い物からタスクを行っていくことの重要性を理解することができました レトロスペクティブをおkなうことで改善されることを体験することができました
  52. メンバーの準備とともに、 プロセス大改造プランを行いました
  53. エクセル等で管理していたタスクを 1要件を1カードに書いて、見えることとリアルに話し合いのなかでも優先度を入れ替えることができるようにしました
  54. また、画面に映し出したwireframeでは認識を合わせづらかった仕様については、 画面を紙に印刷して遷移や仕様を同じ空間で書き込むことで合意を取りやすい環境にしました
  55. その仕様に基づき、ストーリーポイントで規模を見積もり
  56. 1ヶ月間で消化できるストーリーポイントをもとに 開発チームのタスクの優先順位をビジネスオーナーときめました。 これによって、ほしかった機能がないといったことの認識の差を軽減させるようにしました。
  57. タスクをボードにならべて、スプリントの準備OK
  58. 15 min 13:15 れっつ、スタートスプリントをいうことで、 ここまでの準備を行い、初のスプリントをスタートさせました
  59. 2月のスケジュールはこのような形で。 タスクは月単位で計画しつつ、 リリースは月に2回に設置。 ビジネスオーナーに実際に見せるDEMO日を設けて、 KPTによる振り返りの時間をおきました
  60. スプリント中に実際に行ったことは、この4つになります
  61. まずは、Morning Stand Up MTGをはじめました
  62. 開発チームのメンバーがそれぞの昨日やったこと、きょうやること、こまっていることを共有することにより
  63. メンバーの進捗を全体で把握し、その日のゴールを宣言して、 何か困ってたら、すぐにキャッチアップできるようにしました
  64. これによって、チーム全体の進捗をメンバーが意識して終わらせるという雰囲気になりました。 また、リスクを共有する時間をつくることで、 いままで最後に湧き出てきたリスクに対するキャッチアップがはやくなりました
  65. 次にKanbanです
  66. このような看板を作成しました
  67. 1スプリント分のプロダクトバックログを配置して
  68. 10営業日分の日付を書き、タスクを実施する計画日にタスクを配置するようにしました。 これで、スプリントちゅのプランニングがみえるようになります。
  69. 左には、各メンバーがおこなっている付箋を置き、だれが何に着手しているかを見える化
  70. テストまで完了したらDONEにもって完了を確認
  71. こによって、その日にタスクカードの付箋が残っていたら、プランニングから遅延していることがパッと見でわかるようになりました
  72. Kanbanによって、 チーム全員でタスクの消化に取り組む雰囲気ができた チーム外メンバーにも実施内容が見えるようになった タスクの入れ替えに対しての柔軟性がましました
  73. 次にDEMOについてです
  74. さきほどのお話させていただいたのですが、 画面を紙に印刷することによって、全体を把握しやくし、 Prottといったプロトタイピングツールもテスト環境を駆使して、画面だけでなく、 リアルの動きを見ながらビジネスオーナーを確認できるようにしました
  75. DEMOによって、仕様に関する認識違いが減った 仕様の合意を取りやすくなった 全体や遷移を把握しやくなりました
  76. 次にKPTです
  77. KPTは振り仮のためのフレームワークです。 実施したことがあるかたはいらっしゃいますかね。 よいこと、改善点をだして、チームで改善できるようになります これを実施するようになりました
  78. 初回のKPTの風景はこのようになりました。 KPTを行うのが初めてのメンバーが多かったのですが、
  79. 23個のキープ、34のプロブレム、そこから4つのトライを作成しました
  80. 2月を振り返りと1ヶ月、スプリントを回すことによって、 開発チームの進捗が見えるかされ、 個々人ではなくチーム全体で進めている感がでてきました また、見えるかによって柔軟にタスクの入れ替えができるようになりました そして、ビジネスオーナーや他チームメンバーとの認識違いが減りました
  81. ストーリーポイントとしては、このような結果です。 40のプランニングに他指定、62ポイントのストーリーポイントを消化できました
  82. 13:20 20 sec / slide この調子で、3月です。 2月とどうように月単位でタスクをきめ、 リリースは月2回実施しました。 リリース後にはKPTを行い、 月半ばにはビジネスオーナーとのフェイスツーフェイスのDEMO日をおきました。
  83. やったことは2月と同様です。
  84. Morning Stand Up MTGで進捗とリスクを確認。
  85. ボードもKPTの結果、次のスプリント内容の見えるように改善。
  86. 画面遷移をリアルに見えるかして、実際に動かしてDEMOをおこないました。
  87. KPTも、このようになり、2月、3月で、 Keepは、72個。 プロブレムは、85個。 トライは11個作成され、チームとして11歩前進することができました。
  88. 3月を振り返るとよりチーム全体で進めている感がでてきて、 認識違いもへりました。 柔軟いタスクの入れ替えができるようになり、突発の対応もできるようになりました。 それもやりつつもシステム改善の時間を確保できるようになりました。
  89. 3月の結果として、2月の実績のもとに60で計画していたのですが、 82のストーリーポイント消化できるようになりました
  90. 2月、3月をまとめますと ラグリチームでの一体がでてきました 認識のずれも減ったきたように感じます 柔軟にタスクの対応ができるようになりつつも 結果として、対応できるストーリーポイントを増やすことができました そして、月2回の計画リリースをいまも達成しています
  91. 2ヶ月間のスプリントで改善することできました
  92. ウォーターフォール型からスクラムへ しなやかなチームに近づくことができました
  93. これから、
  94. よりよりサービスを作るためにさらなる改善を進めていきます
  95. 最後にお知らせです
  96. ラグリでは、一緒にラグリを作っていってくれる方を募集しております。 ご興味あるかたはご連絡ください。
  97. ご清聴、ありがとうございました!