Regional Scrum Gathering® Tokyo 2015 Day1 [1B-1] 自社ブログサービス「ヤプログ！」でスクラム開発 2014年春に自社のブログサービス ヤプログ！ の再建プロジェクトが立ち上がりました。 従来の開発手法はウォターフォールを崩したようなモデルでしたが、スクラムを導入してのプロジェクト推進を条件としてスタートしました。スクラム初心者である私たちが、スクラムを導入した経緯から実際の現場での苦労や改善、チームがスクラムを受入れ、スクラム脳になるまでのお話をステークホルダー、プロダクトオーナー、スクラムマスターそれぞれの視点からお話しします。私たちの経験がスクラム導入を検討されている方の何か一つのヒントとなればと思います。

1. 自社ブログサービス
「ヤプログ！」でスクラム開発

2. タイムスケジュール
● 概要説明(別府) 5分
● SCRUM導入経緯(別府) 10分
● POから見たSCRUM（甲斐） 15分
● SMから見たSCRUM （天野） 15分
● これからの組織への取り組み (別府) 5 分
● 総括（木村） 5分

3. 3
おことわり
今回のミッション
我が社の誇るブログサービス
会員数200万位。
UU1,000/月位。
能年さんとか居るよ。
のアプリを作る直すぞ！
「これまでの広告収益を
1.5倍以上にするサービス成長
の為に。」

4. 4
おことわり
予め御伝えしておきます
このプロジェクトは
失敗しました
(;´༎yД༎y`)

5. 5
おことわり
あらためてもう一度言います
という事でこの時間は
失敗からマナブ
SCRUM導入事例のご
紹介です
▂▅▇█▓▒░('ω')░▒▓█▇▅▂

6. 6
おことわり
あ、ちょっとニュアンスは違いました
ヤプログへの投資継続という
意味では失敗。
開発手法の導入においては大
きな意味がありました。

7. 名前：別府将彦
fb：masahiko.beppu
2003入社、犬とキャン
プと登山好き。
元Java使い。今人遣い。
名前：天野弘仁
2006年入社。
サービス開発部
マネージャー。
認定スクラムマスター

8. 8
合同会社カナタク：代表社員
アジャイルコンサルタント
CSM/CSPO/CSD
名前：ともぞー
カツ丼食べたい
名前：木村卓央

9. 9
スマートフォンサービス
S
GMOメディアって？
一般ユーザー向け（ＢｔｏＣ）のサービスを提供
I
インターネットメディア

10. 10
あらためて課題
ヤプログアプリリバイバル
● アプリメインで再起を図る。
● 猶予はおよそ半年（2014/06 12）
● 昔からヤプを知らないメンバー
（特に開発陣）が多い。
● 目指すゴールやミッションを作る。
→「短い期間」で
「寄せ集めたチーム」で
「ミッションの脳内同期」を行い
「落目のサービスを上昇気流に乗せる」

11. 11
SCRUM導入経緯①
⃝常日頃から感じている課題
良いものを作る為に変化し続けたい
（けど出来ない）
狙いとアウトプットがマッチしている
（気がしない）
ユーザーの欲求を満たすサービスを提供で
きているのか（わからない）

12. 12
SCRUM導入経緯②
● 可視化できてない
○ 負債が見えない
○ 他の人が何をやっているか見えない
○ 仮説と検証が出来ない
○ 何をやれば良いかわからない
○ 誰が困っているかわからない
● 自己組織化できてない
○ 自分の担当範囲の中で課題を
模索・解決しない
⃝課題の掘下げ

13. 13
SCRUM導入経緯③
⃝課題解決のプラクティスが有るらしい
● SCRUMとの出会い
o 都合良く解釈したアジャイルプラクティスではな
く、一度ちゃんと型にはめたい。
（でも知識は無い）
o ここに居るアジャイルコーチの木村さん（合同会
社カナタク）と出会う。
o 会社からの予算をゲット、ヤプログでやってみ
る・・
この後の紆余曲折は次の発表者から（笑）

14. GMOメディア株式会社
ともぞー
プロダクトオーナーから見たヤプログ！
自社ブログサービス「ヤプログ！」でスクラム開発

15. 1.自己紹介
はじめまして

16. ともぞー
1.自己紹介
スクラム歴1年未満
元エンジニア
今ディレクター（のつもり）

17. 2.プロダクトオーナーって？

18. チームにプロジェクトのビジョンを伝え、チームをリードする。
プロジェクトの舵取り役
２.プロダクトオーナーって？
チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ
いて。
プロジェクトの成否に関する責任をもつ唯一の存在。
偉い人のようなイメージがあるが決してそんなことはありません。
プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任
がある。

19. チームにプロジェクトのビジョンを伝え、チームをリードする。
プロジェクトの舵取り役
２.プロダクトオーナーって？
チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ
いて。
プロジェクトの成否に関する責任をもつ唯一の存在。
偉い人のようなイメージがあるが決してそんなことはありません。
プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任
がある。

20. チームにプロジェクトのビジョンを伝え、チームをリードする。
プロジェクトの舵取り役
２.プロダクトオーナーって？
チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ
いて。
プロジェクトの成否に関する責任をもつ唯一の存在。
偉い人のようなイメージがあるが決してそんなことはありません。
プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任
がある。

21. チームにプロジェクトのビジョンを伝え、チームをリードする。
プロジェクトの舵取り役
２.プロダクトオーナーって？
チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ
いて。
プロジェクトの成否に関する責任をもつ唯一の存在。
偉い人のようなイメージがあるが決してそんなことはありません。
プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任
がある。

22. チームにプロジェクトのビジョンを伝え、チームをリードする。
プロジェクトの舵取り役
２.プロダクトオーナーって？
チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ
いて。
プロジェクトの成否に関する責任をもつ唯一の存在。
偉い人のようなイメージがあるが決してそんなことはありません。
プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任
がある。

24. 大変なこと

25. 大量のバックログ

30. さらに

31. 迫りくるスクラムイベント

32. 実施したスプリントの流れ
リ
フ
ァ
イ
ン
メ
ン
ト
プ
ラ
ン
ニ
ン
グ
レ
ト
ロ
ス
ペ
ク
テ
ィ
ブ
レ
ビ
ュ
｜
月 火 木水 金 月 火 木水 金 月 火 木水 金
プ
ラ
ン
ニ
ン
グ
レ
ビ
ュ
｜
レ
ト
ロ
ス
ペ
ク
テ
ィ
ブ
スプリント期間は2週間

33. イベントが近づくと、
スクラムマスターが言うんです

37. どうしたものか。

38. リリース計画を立てる

39. リリース計画とは？

40. 何番目のスプリントで何をやるかを決めておくこと
いつ、リリースするかを決めておくこと
チームやステークホルダーにプロジェクトの
方向性を示すツール
スプリントが終わる度に見直すことが重要！
リリース計画とは？

41. リリース計画が
無い時 / 有る時

42. チーム：「出来ました！」
PO：「すごく良い感じです。」
チーム：「じゃリリースしますね！」
PO：「え、いや、次やる機能作ってからにしましょう。」
とあるレビューの日

44. リリース計画が
無い時 / 有る時

45. どのスプリントでどの機能をリリースするかが明示されているので、
リリースに関してチーム内で議論することがなくなりました。
チームとしては、やはり成果物を早くリリースしたいものです。
事前にリリース計画を立てておくことは重要でした。

46. チームの雰囲気も
良くなります。

47. もっと大変なこと

50. もう少し大きくして見てみましましょう

52. プロジェクトの成否

53. 己との戦い

54. KPI

58. 結 果

59. チームは、、、

60. 解 散…

61. SCRUMの可能性を実感

62. 自己組織化

63. 自己組織化とは
自己組織化（じこそしきか、英: self-organization、self-
assembly）とは、
自律的に秩序を持つ構造を作り出す現象のことである。
自発的秩序形成とも言う。

64. 自己判断
機能横断的
自発的行動
チームワーク
振り返り
KPT

65. 繰り返す

66. BESTな判断

67. BESTな判断

68. チーム として

69. BESTな判断

70. ご清聴
ありがとうございました！

71. スクラムマスターから見たヤプログ！
自社ブログサービス「ヤプログ！」でスクラム開発
GMOメディア株式会社
天野 弘仁

72. 天野弘仁
1.⾃自⼰己紹介
スクラム歴1年年未満
主要⾔言語は、Java です。
現在はスクラムマスターとして
社内のプロダクト開発に
スクラムを導⼊入してより良良くしよ
うと奮闘中。
認定スクラムマスター

73. 1. はじめましてSCRUM
2. やって良かったこと
3. 変化するチーム
4. 反省と課題
5. まとめ
アジェンダ

74. 1. はじめましてSCRUM

75. このプロジェクトの
システム責任者として
呼ばれました。

76. ・プロジェクトのプレッシャー
・新しい事やる余裕なんてない
・スクラムなんて反対だった
・慣れたやり方でやりたかった
・スクラムマスターをやるなんて思ってなかった

77. いろいろ課題が出まして
話し合って出した解決策が
ロールを変更することでした。

78. チームを出て
スクラムマスターに
挑戦することになりました。

79. 1. はじめましてSCRUM
2. やって良かったこと
3. 変化するチーム
4. 反省と課題
5. まとめ

80. 素直に受け入れました。

81. ピュアな
スクラムを心がけました。

82. プロダクトオーナーも
チームのみんなも
スクラムマスターも
同じ本を読みました。

83. 知識を蓄える
説明が必要な際に引用し易い
（みんなに通じる。）
同じネタで盛り上がれる

84. チームメンバーを
変更しました。

85. （ほぼ）アナログ化！！

86. ・模造紙
・付箋紙
・マジック

87. Product Backlog
Redmine

88. モヤモヤ⼀一覧
Googleスプレッドシート
プロダクトをより良くする為
のメモ

89. 1. はじめましてSCRUM
2. やって良かったこと
3. 変化するチーム
4. 反省と課題
5. まとめ

91. 無秩序（カオス）な状態に
秩序を入れようとする。

92. 慣れ浸しんだリズムを
変えようとする！！

93. スクラムマスターは
その改革（変化）を
推進する人となります。

94. SCRUMは
合理的 で 残酷 だと
感じました。

95. ・前のやり方が早いし・・・
・MTG多いし・・・
・こんな短時間で見積もれな
いし・・・

96. 反発や攻撃の矛先は
（容赦なく）
スクラムマスターに
向けられるでしょう。

97. 決して
スクラムマスター（自分）が
悪いわけ（原因）ではない！

98. みんな変化に
戸惑っているだけ！！

99. 変化後は・・・

100. もうちょっとプロジェクトが続き突き
詰めていければ
かなり⾼高速に開発が進めていけそうな
⼿手応えは感じた。

101. チームでの
助け合いが
素敵だった

102. 自分でデザインを決め、
プロジェクトのデザインにおいては
責任感を得られた

103. 次もやるなら開発は
スクラムでやりたい
と思えるような
良い開発方法だと思った

104. 1. はじめましてSCRUM
2. やって良かったこと
3. 変化するチーム
4. 反省と課題
5. まとめ

105. 喋り過ぎました。

106. 多忙過ぎました。

107. 威圧感
出し過ぎました。

108. プロダクトオーナー
のサポートが
できませんでした。

109. 1. はじめましてSCRUM
2. やって良かったこと
3. 変化するチーム
4. 反省と課題
5. まとめ

110. 変化する時って
戸惑いや、反発、パワー
必要ですよね！？

111. 改善を繰り返していけば
少しずつ受け入れ
変化していきます。

112. 折れない心！！

113. この我々の事例がこれから
SCRUMをはじめる方々の
何か一つのヒントになれば
幸いです。

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

115. 115
これからの取り組み①
⃝SCRIM導入での課題
● SCRUMのワークフローの理解
● SCRUMイベントの意味の理解
● プロダクトオーナーこそ一番大事、難易度
も高い
● 仮説と検証が大事
● 本来の目的を見誤らない。

116. 116
これからの取り組み②
⃝SCRUMの継続による価値創出を目指す
● 当初の２つの大きな課題解決へは手応え
o 可視化
o 自己組織化
● ただし、これが出来るのはメンバーの一部
のみ
o 今後は裾野を広げる取り組みを
o 全体的に可視化、自己組織化
§ その上での価値創出がゴール

117. 〆

119. 御礼

121. プロジェクトのビジョンを関係者全員で

122. みんながバスに乗った

123. 基本に忠実に

124. 自分で考えられるチームが出来た

125. 感謝