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

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番目に欲しい価値
...

■ 実現したい価値(要求)をリストにして並び替える
■ リスト化したものを「Product Backlog」と呼ぶ
■ 絶対的な順番をつけるのがポイント！！！
✓ 「優先度A」「優先度B」的なラベル付はNG
✓ メンバーが上から順にピックできる状態が理想
✓ 常にメンテナンスして順序をキープ
■ Retty的にはUser Happyにより近い価値がそのまま実現順
■ User HappyにつながるものをAll Doneに！
価値が低い・無いものは捨てる・やらない勇気(Ownership)

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

...
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を
持つ.

開発チーム
■ プロダクトを創る！
幸村,三成,清正,利休etc…
色んな人がいる(職能別に)
■ POがリリース判断可能なプロダクト
を創る
■ 全員で一つ！上下関係は無い
■ 役割も能動的
✓ 自分の役割.特に得意な領域
など
✓ プロダクト価値を最大化する
ためやれることはやりきる( 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
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 × Retty
User 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

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

More Related Content

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