ScrumGatheringTokyo2016登壇資料。 営業、販売促進チームでスクラムをやってみたお話。

1. 開発チーム外で
スクラムやってみた
2016/1/19
Tomoyasu Ishii@zambiker
Scrum Gathering Tokyo 2016

2. 話すこと
• 開発以外のチームでスクラムを導入した事例紹
介です
• 開発以外のチームと開発チームの同じところ、
違うところを中心に話させていただければと思
います

3. 自己紹介
• 石井智康（Tomoyasu Ishii）
@zambiker
• フリーランスのRailsプログラ
マ兼スクラムマスター
• 色んなところでスクラムマス
ターやったりプログラマーを
やってます

4. コミュニティやってます
• アジャイルひよこクラブ
∼ニワトリへの道∼
（旧：アジャイらないひよこク
ラブ）
• 偶数月の第４週金曜開催＠渋谷
• デブサミ公認コミュニティ
• 2016年のテーマ：
TDD/PO/リモート/UXデザイ
ン/アンチパターン

5. 皆さんのことも
教えてください

6. きっかけ
• 2015年6月に一般ビジネス向
けのスクラムの本が翻訳され
ました
• スクラム 仕事が４倍速くな
る 世界標準 のチーム戦術

7. –p29 第一章 過去のやり方は通用しない
プロジェクトに着手し仕事を進めるうちに、
チームの仕事は３倍のスピードになった

8. –p30 第一章 過去のやり方は通用しない
スクラムで大事なのは開発側じゃありません。
顧客とステークホルダーです

9. –p.79 第三章 チーム
チームが大きすぎると生産性が下がるのは、
人間の習性として確実な法則だと
いってよさそうだ

10. –p.112 第五章 無駄は罪である
私がみてきたかぎり、
一般的に会社の仕事の８５％程度は無駄になっ
ていると言っていい

11. 開発以外でも
やってみたい！

12. 今日の事例
電子書籍サービスYondemillを開発しているフライングライン社

13. 経緯
開発チームに
スクラムを
導入
POが本を読んで
開発以外の
チーム運営にも
スクラムを導入
成果も課題も
色々でてきた
6ヶ月後

14. 今日の事例
• 開発以外の主な活動
1. 営業活動
2. 販売促進/顧客対応
• 販売開始（データ作成、アップロード）
• プロモーション/集客（広告、LP作成、
Twitter投稿）
• 運用サポート
3. 出版社向けCMS構築（ディレクション）
難易度
上がる

15. プラクティスいろいろ
• スプリント
• スプリント計画＆レビュー
• カンバン/バックログ
• デイリースクラム
• レトロスペクティブ/KPT
• プランニングポーカー
• インセプションデッキ
• TDD
• ペアプログラミング
• バーンダウンチャート

16. 導入したプラクティス
• スプリント
• スプリント計画＆レビュー
• カンバン/バックログ
• デイリースクラム
• レトロスペクティブ/KPT
• プランニングポーカー
• インセプションデッキ
• TDD
• ペアプログラミング
• バーンダウンチャート

17. スプリント
• １週間スプリントで設定
月 火 水 木 金
スプリントレビュー
レトロスペクティブ
デイリースクラム デイリースクラム デイリースクラム デイリースクラム
クライアントと
KPT
スプリント計画

18. 導入時に難しいこと
• オフィスにいない
• メンバーによってスケジュールがバラバラ
• 客先をまわることも多い

19. スプリント
• １週間スプリントで設定
月 火 水 木 金
スプリントレビュー
レトロスペクティブ
デイリースクラム デイリースクラム デイリースクラム デイリースクラム
クライアントと
KPT
スプリント計画
月曜日に
大きいミーティングを寄せる
始業時間に朝会を実施
（予定をなるべくいれない）

20. カンバン：販売促進

21. カンバン：CMS導入

22. 導入時に難しいこと
• フィーチャとタスクをどう定義するか？
• あなたのチームで、本当に必要な成果と行動は
なんですか？
• お客さんや外注先のタスクがDoingで止まった
ままになる

23. カンバン：販売促進 黄色がフィーチャー
赤はお客さんの仕事
PVやCVに響くはずの作業
はフィーチャーと定義
サブタスクはIDを振って
管理

24. レトロスペクティブ

25. 導入時に難しいこと
• KPTに関しては特になし！！
• ポストイットの購入と慣れのみ！
• KPTは契約先のお客さんと話すツールとしても
活躍してるそう

26. KPTノート

27. 導入してみて
どうだった？

28. 効果（Keep）
メンバーの行ってい
るタスクが
可視化できる
失敗を肯定的にとら
えられる
一度作ればタスク管
理のストレスがない
日々にリズムがでて
くる
若手が成長する

29. 難しさ（Problem）
フィーチャ実行と売
上が必ずしも結びつ
かない
属人化するタスクを
どう平準化するか
クォリティの担保を
どうチェックする？
フィーチャの精度を
どうやってあげる？

30. 今後やりたいこと（Try）
フィーチャ消化と
売上への効果の検証
が重要
できてないプラクティ
スを試してみたい！
TDD/ペアプロ
インセプションデッキ
（チームの共通ゴール）
を作って貼りだす

31. まとめ
1. 「失敗から学ぶ」ことは開発以外のチームでも重要！
2. ステークホルダーに「スクラム」を読ませるのがオス
スメ。
3. チームで何を解決したいかを明確化する。その時やる
べきプラクティスが明らかになる
4. 何をフィーチャとするかは議論が必要。タスクを早く
終わらせると同時に、効果を最大化する

32. –p.24 第一章 過去のやり方は通用しない
意味のない仕事に人生を費やす人がいてはいけ
ない。ビジネスとしてダメなだけでなく、
その人の心をだめにしてしまう

33. ご清聴
ありがとうございました。