User Happyをささえるアジャイルのココロとスクラムのキホン(公開版)

Shinichi Nakagawa(@shinyorke)Retty.Inc Tech Leader(Engineer)

Tech UX Talk 2017/1/25 「Scrum & Agile」

このスライドについて

■ 社内勉強会「Tech UX Talk」登壇資料の公開Ver.です.

■ 導入前,初心者向けの内容です.実践はこれから.

■ オリジナル版と異なり,業務的なTipsなどは外しています.

■ Retty Way(Retty行動指針)の部分は読まれているあなた自身の所

属チーム・企業の行動指針・スタンスに置き換えると良いと思います

orRettyに興味ある方はぜひそのままRetty Wayの風味でお楽しみく

ださい.

■ アジャイル・スクラムの導入の参考となれば幸いです！

■ なお登壇者(中川)は入社三週間目でこれをまとめた模様.

Retty Way

■ User Happyユーザー価値で突き抜けろ。

■ Ownershipいちいち説明を受けないと動けない人間になるな。

■ Think Big小さくとどまるな。

■ All Done徹底的にやりきったか?

■ Hire the BEST全員で採用！

※引用元&完全版はこちら http://corp.retty.me/team/

Who am I?

■ Shinichi Nakagawa(@shinyorke)■ Retty.Inc 魚料理担当/野球の人

■ Tech Leader(Engineer)■ Career

✓ WASHIN SYSTEMS(2000-2003)✓ BayCurrent Consulting(2004-2014)✓ Recruit Sumai Company(2014-2016)✓ visasQ(2016)✓ Retty(2017-)

■ Agile/Scrum/Lean Startup/Python(Web/PyData/Baseball)■ Certified Scrum Master(認定スクラムマスター)

✓ 2009年頃からScrum Masterに目覚める.✓ Product Ownerも少し(RECRUIT/Retty).✓ XP祭り(Speaker, Lightning Talk)✓ Manaslink(blog),EM Zero Vol.9(paper)に寄稿

本日のおみやげ

©PyCon JP

Agile meets Retty Way(本日取り扱うこと)

■ User Happyを実現するプロセスを学ぶ・考える

■ 以下のRetty Wayを実現するためのアジャイルの考え方

✓ User Happy

✓ Ownership

✓ All Done

■ 各チーム・プロダクトにおいて具体的な施策/PDCAを回す

Frameworkとしてのスクラムの紹介

■ 「アジャイル」「スクラム」をテーマに「User Happy」を

実現するアイデアを出してみる

✓ 感想

✓ 意見

✓ チーム・プロダクトで実践できるアイデア

✓ etc...

本日取り扱わないこと

■ あなたのチーム・プロダクトを救う具体的な打ち手・各論

■ スクラム以外のFramework/Practiceの紹介

✓ XP(eXtreme Programming)

✓ Kanban

✓ Lean Development(Lean Startup)

✓ etc...

■ 基本的にプロセス論なので,以下のRetty Wayには触れません

✓ Think Big(ちょっと触れる程度)

✓ Hire The Best(全く触れません)

■ アジャイル/スクラムに関わる具体的なサービス・製品

(ツールとかクラウドサービスなどなど)

おしながき

浜魚 https://retty.me/area/PRE13/ARE12/SUB1202/100000818834/

おしながき

1. アジャイルとは?〜アジャイルソフトウェア開発宣言

2. スクラムis何?

a. 要求を並べ替える(User Happy/All Done)

b. チームについて(Ownership)

i. プロダクトオーナー

ii. スクラムマスター

iii. チームメンバー

c. スプリント(All Done)

d. 頻繁に計画する(User Happy)

e. デイリースクラム(Ownership)

f. ふりかえり(Ownership)

3. [WorkShop]AgileとScrumで実現するUser Happyを考える

4. 結び

アジャイルソフトウェア開発宣言

引用元 http://agilemanifesto.org/iso/ja/manifesto.html

アジャイルソフトウェア開発宣言

■ プロセスやツールよりも個人との対話を。

■ 包括的なドキュメントよりも動くソフトウェアを。

■ 契約交渉よりも顧客との協調を。

■ 計画に従うことよりも変化への対応を。

引用元 http://agilemanifesto.org/iso/ja/manifesto.html

Retty Way文脈では...

■ プロセスやツールよりも個人との対話を。

✓ チームにとってのUser Happyと個人のOwnership

✓ 対話を重ねることによって動くソフトウェアを創るチームを創る

✓ プロセスやツールは手段にすぎない,主役は人！

■ 包括的なドキュメントよりも動くソフトウェアを。

✓ ユーザーさんに価値ある機能を出し切る,つまりAll Done

✓ 動くソフトウェア・プロダクトが価値の源泉

✓ 計画の完遂より価値あるタスクをやり切る(≒やらない勇気)

■ 契約交渉よりも顧客との協調を。

✓ User Happy〜ユーザーさんとの対話を大切に

✓ 契約やルールも大切だがまずはユーザーさんの気持ちが一番

✓ 定量視点(KPI/KGI)もあれば定性(パッション)もあるよ

■ 計画に従うことよりも変化への対応を。

✓ Think Big〜小さくとどまらず,変化に対応する

✓ ユーザーさんの要求やストーリーは常に変化する

✓ 変化を受け入れながら価値あるプロダクトを作り切るスタンス

スクラム(Scrum)

※語源はラグビーのスクラムです (そのまんま)

写真: https://flic.kr/p/gB9oiB

スクラム #とは

■ 継続的に「動くソフトウェア」を提供する手法.

■ 常に進む方向を調整しながらプロダクト価値を高め,

User Happyを達成する.

■ Framework/Practiceとして以下を定めている.

✓ 作業

✓ 会議体

✓ 成果物

■ 数あるアジャイル開発手法の一つ.

※アジャイルとスクラムは同列ではないです！

(アジャイルは思想,スクラムは方法論であり各論)

スクラムの構造

1. 要求を並べ替える(User Happy/All Done)

2. チームについて(Ownership)

a. プロダクトオーナー

b. スクラムマスター

c. チームメンバー

3. スプリント(All Done)

4. 頻繁に計画する(User Happy)

5. ふりかえり(Ownership)

要求を並び替える〜Product Backlog

1番目に欲しい価値

2番目に欲しい価値

3番目に欲しい価値

4番目に欲しい価値

99番目に欲しい価値

100番目に欲しい価値

...

要求を並び替える〜Product Backlog

■ 実現したい価値(要求)をリストにして並び替える

■ リスト化したものを「Product Backlog」と呼ぶ

■ 絶対的な順番をつけるのがポイント！！！

✓ 「優先度A」「優先度B」的なラベル付はNG

✓ メンバーが上から順にピックできる状態が理想

✓ 常にメンテナンスして順序をキープ

■ Retty的にはUser Happyにより近い価値がそのまま実現順

■ User HappyにつながるものをAll Doneに！

価値が低い・無いものは捨てる・やらない勇気(Ownership)

要求を並び替える〜Product Backlog

1番目に欲しい価値

2番目に欲しい価値

3番目に欲しい価値

4番目に欲しい価値

99番目に欲しい価値

100番目に欲しい価値

...

要求を並び替える〜Product Backlog

1番目に欲しい価値

2番目に欲しい価値

3番目に欲しい価値

4番目に欲しい価値

99番目に欲しい価値

100番目に欲しい価値

...

User HappyのためにAll Done!すべき価値

要求を並び替える〜Product Backlog

1番目に欲しい価値

2番目に欲しい価値

3番目に欲しい価値

4番目に欲しい価値

99番目に欲しい価値

100番目に欲しい価値

...

User HappyのためにAll Done!すべき価値

あとでいいorやらない

チーム

写真: https://flic.kr/p/7pVqyH

スクラムチームのメンバー構成と役割

■ プロダクトオーナー(PO) × 1名

■ スクラムマスター(SM) × 1名

■ 開発チーム × 1〜8名

✓ エンジニア

✓ デザイナー

✓ プランナー

※基本的に兼任はNG,特にPOとSMの兼任は絶対NG

※1チーム3〜5名前後がベスト,Maxで10人

役割紹介〜豊臣家(秀吉全盛期)で例えてみる

※本編は「真田丸」でしたが ,スベった大人の事情で差し替えています

©いらすと屋

プロダクトオーナー(PO)

■ プロダクトの結果責任をとる.

豊臣秀吉っぽい人.

■ プロダクトバックログの管理責任

✓ 並び順の最終決定権

✓ 開発チームを活用して

価値を最大化

■ 開発チームに干渉はしない.

※相談はできる

■ Ownershipを持つポイント

✓ User Happyにつなぐ

ビジョンとシナリオを持つ.

✓ SMおよび開発メンバーを

信じることにより,チームの

Ownershipを促す.

スクラムマスター(SM)

■ プロセスを上手く回す働き者.

黒田官兵衛みたいな軍師タイプ.

■ チームを守る・育てる「推進役」

✓ 妨害の排除

✓ 支援と奉仕

✓ 教育/ファシリテート

■ スクラムのイベント・成果物を

円滑に順調に回すところに責務を

持つ

■ Ownershipを持つポイント

✓ チーム全体をモデリングして

創る

✓ 縁の下の力持ちとしてチーム

活動の円滑化にOwnershipを

持つ.

開発チーム

■ プロダクトを創る！

幸村,三成,清正,利休etc…

色んな人がいる(職能別に)

■ POがリリース判断可能なプロダクト

を創る

■ 全員で一つ！上下関係は無い

■ 役割も能動的

■ Ownershipを持つポイント

✓ 自分の役割.特に得意な領域

など

✓ プロダクト価値を最大化する

ためやれることはやりきる( All

Done)

スクラムな開発チーム(豊臣家全盛期)

プロダクトオーナー 開発メンバー

スクラムマスター

スプリント(短く切って繰り返す)

Sprint #week1 Sprint #week2 Sprint #week3 Sprint #week4

Sprint #month1

Sprint #1(week1-2) Sprint #2(week3-4)

スプリント

■ 企画-開発-本番リリースを行う「単位」のこと

■ 固定の期間に区切って行うのがポイント.

固定の方がチームにリズムが生まれやすい&進捗把握が楽.

※ただし諸説あります(変動でもいいという人もいる)

■ オススメのスプリント期間 ※1ヶ月以内に収める

✓ 1週間

✓ 2週間

✓ 1ヶ月

■ スプリント期間内に収まる計画/スプリントバックログを

作る,All Doneへの道筋がみえるように！

オススメのスプリント期間

Sprint #week1 Sprint #week2 Sprint #week3 Sprint #week4

Sprint #1(week1-2) Sprint #2(week3-4)

Sprint #month1

1ヶ月

1ヶ月で割り切れる事が大きなポイント .2ヶ月以上の期間はNG(意味がなくなる )

頻繁に計画する

写真: https://flic.kr/p/4sM2Jy

スプリント計画

■ スプリント単位で実現する価値(User Happy)を計画する

■ POがプロダクトバックログから価値を選ぶ(上から順に)

■ 開発チームは「価値」をどれくらいで出来そうか見積もる

→手法としてはプランニングポーカーが用いられる事が多い

■ POと開発チームでディスカッションしてスプリント内にやることを決め

る.工数的に溢れそうなものをあとに回す等の調整はここでやる(スプ

リント計画MTGといいます)

■ SMはスプリント計画を円滑にすすめるためのファシリテートや助言

を行う

スプリント計画を創る(イメージ)

1番目に欲しい価値

2番目に欲しい価値

3番目に欲しい価値

4番目に欲しい価値

99番目に欲しい価値

100番目に欲しい価値

...

プロダクトバックログ

スプリント計画を創る(イメージ)

4番目に欲しい価値

5番目に欲しい価値

6番目に欲しい価値

7番目に欲しい価値

99番目に欲しい価値

100番目に欲しい価値

...

プロダクトバックログ スプリント #1

1番目に欲しい価値

2番目に欲しい価値

3番目に欲しい価値

1回のスプリントでAll Doneできる量に収める※Velocityといいます

スプリントの全Task

デイリースクラム

※弊社Scrum TeamがDone!して喜んでる様子

デイリースクラム〜毎日状況を確認する

■ いわゆる,「朝会」のこと.

■ 毎日決まった時間・決まった場所でやるのがポイント

なお,必ず朝やる必要はない(サイクルが何より大切)

■ 15分でやりきる,議論禁止,「かんばん」などを用いて可視化

■ 議題

✓ 昨日の状況(どれだけdoneしたか)

✓ 今日やること(なにする?どうやるの??)

✓ 困ったこと

■ 全員がOwnershipをもってやりましょう！その方が結果幸せ

(進行&場作り的に)

■ アイスブレークを入れるとより良いでしょう.

■ (大切なので二度言いますが)必ず朝やる必要はないです！

ふりかえり

ふりかえり

■ スプリントの最後に「ふりかえり」を行う(リリース後など)

■ SMが司会&ファシリテートを行う.

■ 以下の視点で行う.

✓ プロセスやツール,とりくみの効果

✓ チーム活動としての良かった/悪かった

✓ 次のスプリントで実施したいアクション・チャレンジ

■ User Happyだったか?Ownershipを持てたか?

を自問自答してもいいかも.

■ KPT,Five Whys(5なぜ),ワールドカフェetc…

手法はたくさんある,手軽なのはKPT(Keep/Problem/Try)

参考： ふりかえりを分類してみました ※中川のブログです

【例】KPT(Keep/Problem/Try)

Keep(良かった) Problem(反省)

Try(次にやる)

【ワークショップ】Agile × RettyUser Happyを実現するAgile/Scrum

※内容がアレなので隠してます ,ご了承ください

ワークショップ(15分)

■ Extreme Reading**という方式で行います.

■ 近くにいる人たちでグループを作りましょう,3〜4人くらい

■ グループ内で以下のテーマでディスカッションしてみましょう.

※全員が一言発言するように上手くファシッてください！

✓ 話の感想・意見・質問(中川に対して)

✓ 今日の話で気がついたチームの課題やアジャイル/スクラムで解決で

きそうなこと

✓ 実際にやってみたい・取り入れてみたいアジャイル/スクラムのやり方

■ ディスカッションで出てきた内容をポスト・イットに書いて,

ホワイトボードに貼ってください

■ 終了後,時間が許す限り中川が回答します

(回答できないものは後日)

■ Retty Wayを意識するとより学びが深いものになりますよ！

**本を一章ずつ読んで感想をポスト・イットに貼って議論する読書形式 参考: https://techblog.recruitjobs.net/events/agile-samurai-reading-club-vol1 (手前味噌ですが...w)

【参考】ワークショップの回答(抜粋)

■ チームが小さい場合スクラムは必要?

→スクラム=万能じゃないので,都度合ったやり方を！個

人的にはXPとかでいいと思う.

■ チームが3人などの場合,PO/SMの役割分担必要?

→少なくともPOは決めたほうが良いです.他は流れで.

■ リモートメンバーが多い場合のスクラムはどうする?

→一箇所に集まるのがベストなので他の方法を検討す

る.Hangoutなどを活用orスクラム以外の方法とか.

■ ウォーターフォールとアジャイル(スクラム)の違い

→使い分け.小さくカイゼンして数字を伸ばすならアジャイ

ル,ゼロイチでプロダクト作るならかえってウォーター

フォールの方が合ってる...とかそんな感じでわけると◎で

しょう！

■ POとSMって兼任しちゃダメなの?

→教科書通りだと「NG」価値の順番を決める人とチーム

を作る人は分けるべき.

ただ,少ない人数だったり完成度が高いチーム・メンバー

が揃ってる時はかえって有りかも

(スクラムかどうかは別として)

【参考】ワークショップの回答(抜粋)

■ POの優先順位付けは経営観点もあり得る?

→現実的にはある.アジャイル的には「ユーザーファース

ト」なので本来有りえない(と信じたい)

■ リーダータイプはPO,バランス型がSM

→正解！

■ DONE!が重なってるのをみるときもちがいいですね

→そーですね！DONEを剥がす瞬間大好き.

【参考】ワークショップの回答(抜粋)

■ エンジニア以外(営業など)でもスクラムは有効?

→ケースバイケース.CSや総務的なモノでは有効,営業の

場合は向き不向きあると思うのでご相談を！

■ 振り返りを行う時期は?

→スプリントの最後.月スタート金終わりだったら金曜日も

しくは木曜日(リリース物が固まった後とか)

■ 理解しやすかった

→ありがとうございます！

【参考】ワークショップの回答(抜粋)

■ 朝会の効率化に取り入れたい

→ぜひー！まずは可視化(カンバンとか)やると良いです

&あとはファシリとアイスブレーク

■ 複数チームに所属している場合は?

→朝会・振り返りの時間をずらすなどして回す...のが暫

定対処,恒久対処としてはそもそも1チームにすべきかと

■ POが開発に入りすぎ,SM不在

→メンバーが自発的にSMやればいいと思う.

困ったら支援しますよ.

【参考】ワークショップの回答(抜粋)

■ 他チームとの調整

→いわゆる「妨害」の可能性があるときはSMが調整役に

回る.メンバーが調整工数を取られるのを避けるという意

味合いがあります(いいプロダクトを作れるように)

■ 大変そう

→チームが軌道に乗るまでは大変,のるとリズムがでて

むしろ楽になります.

【参考】ワークショップの回答(抜粋)

■ 10人チームのスクラムで困ったこと

→朝会が15分で終わらない,プロダクトバックログの順番

が決めにくい,振り返りが長い,サボる人が出てくる

■ チームメンバーが少ないと何が困る?

→PO/SM兼任など,起きちゃいけないことが起きる

【参考】ワークショップの回答(抜粋)

■ POと開発メンバーがディスカッションをする理由.POとSM

だけで良いのでは?

→理由は２つ.

①スクラムチームは全員が主役(上下関係は無い)

②PO/SMへの過剰な役割集中を防ぐ

メンバーが主体的に参加,自分ごととして捉えるのが重要

で,SMやPOが肩代わりしてしまうとそこがボトルネックに

なる.最終的にはみんなが大人になる「自己組織化」が行

われるように仕向けるのが良い

つまりOwnership持とうよ！ってこと！！

【参考】ワークショップの回答(抜粋)

結び

結び

■ そら(アジャイルは思想,スクラムは方法で)

そう(上手く使ったらUser Happyにつながるに)

よ　(違いないじゃないか?)

■ 実際使いながら取捨選択しながらプロセスを組み立てる

のがベストなので気になる方は試してみて

■ 即効性があるものと無いものがあるので

じっくりやりましょう！(でも見切りは素早く)

■ 導入の相談・スクラムマスターやって！

的なやつはお気軽にご相談ください！！

興味湧いてきました?

■ 会社訪問・オフィス見学

■ もくもく会(Android,機械学習etc…)

■ その他勉強会・イベントなど(企画中)

■ (個人的には)Agileな読書会など.

ぜひ, Rettyに遊びに来てください！

http://corp.retty.me/

https://www.wantedly.com/companies/retty

ご清聴ありがとうございました.浜魚 https://retty.me/area/PRE13/ARE12/SUB1202/100000818834/

【Appendix】参考書籍など

■ SCRUM BOOT CAMP THE BOOK(読みやすい)

http://www.shoeisha.co.jp/book/detail/9784798129716

■ アジャイル開発とスクラム(体系的な話など)

http://www.shoeisha.co.jp/book/detail/9784798129709

■ エクストリームプログラミング(アジャイルの心)

http://amzn.asia/5oAbAZV