3K Views
March 18, 22
スライド概要
Regional Scrum Gathering® Tokyo 2015 Day1
[1B-1] 自社ブログサービス「ヤプログ!」でスクラム開発
2014年春に自社のブログサービス ヤプログ! の再建プロジェクトが立ち上がりました。
従来の開発手法はウォターフォールを崩したようなモデルでしたが、スクラムを導入してのプロジェクト推進を条件としてスタートしました。スクラム初心者である私たちが、スクラムを導入した経緯から実際の現場での苦労や改善、チームがスクラムを受入れ、スクラム脳になるまでのお話をステークホルダー、プロダクトオーナー、スクラムマスターそれぞれの視点からお話しします。私たちの経験がスクラム導入を検討されている方の何か一つのヒントとなればと思います。
木村 卓央(Takao Kimura) 合同会社カナタク 代表社員/アジャイルコーチ 2003年頃にアジャイルに出会い、アジャイルコミュニティへの参加を通してアジャイルを学び。個人や小さいチームでアジャイルの実践を行ってきた。 2009年よりスクラムマスターとして経験を積み、2012年にはアジャイルコーチとして、他社へのアジャイル導入支援や、アジャイル研修などを行っている。 LeSS Study主催 Agile Discussion!!主催 Fearless Change アジャイルに効くアイデアを広めるための48のパターン 共訳 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 共訳
自社ブログサービス 「ヤプログ!」でスクラム開発
タイムスケジュール ● 概要説明(別府) 5分 ● SCRUM導入経緯(別府) 10分 ● POから見たSCRUM(甲斐) ● SMから見たSCRUM (天野) 15分 15分 ● これからの組織への取り組み (別府) 5 分 ● 総括(木村) 5分
おことわり 今回のミッション 我が社の誇るブログサービス 会員数200万位。 UU1,000/月位。 能年さんとか居るよ。 のアプリを作る直すぞ! 「これまでの広告収益を 1.5倍以上にするサービス成長 の為に。」 3
おことわり 予め御伝えしておきます このプロジェクトは 失敗しました (;´༎yД༎y`) 4
おことわり あらためてもう一度言います という事でこの時間は 失敗からマナブ SCRUM導入事例のご 紹介です ▂▅▇█▓▒░('ω')░▒▓█▇▅▂ 5
おことわり あ、ちょっとニュアンスは違いました ヤプログへの投資継続という 意味では失敗。 開発手法の導入においては大 きな意味がありました。 6
名前:別府将彦 fb:masahiko.beppu 2003入社、犬とキャン プと登山好き。 元Java使い。今人遣い。 名前:天野弘仁 2006年入社。 サービス開発部 マネージャー。 認定スクラムマスター
名前:木村卓央 名前:ともぞー カツ丼食べたい 合同会社カナタク:代表社員 アジャイルコンサルタント CSM/CSPO/CSD 8
GMOメディアって? 一般ユーザー向け(BtoC)のサービスを提供 S スマートフォンサービス I インターネットメディア 9
あらためて課題 ヤプログアプリリバイバル ● アプリメインで再起を図る。 ● 猶予はおよそ半年(2014/06~12) ● 昔からヤプを知らないメンバー (特に開発陣)が多い。 ● 目指すゴールやミッションを作る。 →「短い期間」で 「寄せ集めたチーム」で 「ミッションの脳内同期」を行い 「落目のサービスを上昇気流に乗せる」 10
SCRUM導入経緯① ◯常日頃から感じている課題 良いものを作る為に変化し続けたい (けど出来ない) 狙いとアウトプットがマッチしている (気がしない) ユーザーの欲求を満たすサービスを提供で きているのか(わからない) 11
SCRUM導入経緯② ◯課題の掘下げ ● 可視化できてない ○ 負債が見えない ○ 他の人が何をやっているか見えない ○ 仮説と検証が出来ない ○ 何をやれば良いかわからない ○ 誰が困っているかわからない ● 自己組織化できてない ○ 自分の担当範囲の中で課題を 模索・解決しない 12
SCRUM導入経緯③ ◯課題解決のプラクティスが有るらしい ● SCRUMとの出会い o 都合良く解釈したアジャイルプラクティスではな く、一度ちゃんと型にはめたい。 (でも知識は無い) o ここに居るアジャイルコーチの木村さん(合同会 社カナタク)と出会う。 o 会社からの予算をゲット、ヤプログでやってみ る・・ この後の紆余曲折は次の発表者から(笑) 13
プロダクトオーナーから見たヤプログ! 自社ブログサービス「ヤプログ!」でスクラム開発 GMOメディア株式会社 ともぞー
1.自己紹介 はじめまして
1.自己紹介 ともぞー スクラム歴1年未満 元エンジニア 今ディレクター(のつもり)
2.プロダクトオーナーって?
2.プロダクトオーナーって? プロジェクトの成否に関する責任をもつ唯一の存在。 チームにプロジェクトのビジョンを伝え、チームをリードする。 プロジェクトの舵取り役 チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ いて。 プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任 がある。 偉い人のようなイメージがあるが決してそんなことはありません。
2.プロダクトオーナーって? プロジェクトの成否に関する責任をもつ唯一の存在。 チームにプロジェクトのビジョンを伝え、チームをリードする。 プロジェクトの舵取り役 チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ いて。 プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任 がある。 偉い人のようなイメージがあるが決してそんなことはありません。
2.プロダクトオーナーって? プロジェクトの成否に関する責任をもつ唯一の存在。 チームにプロジェクトのビジョンを伝え、チームをリードする。 プロジェクトの舵取り役 チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ いて。 プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任 がある。 偉い人のようなイメージがあるが決してそんなことはありません。
2.プロダクトオーナーって? プロジェクトの成否に関する責任をもつ唯一の存在。 チームにプロジェクトのビジョンを伝え、チームをリードする。 プロジェクトの舵取り役 チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ いて。 プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任 がある。 偉い人のようなイメージがあるが決してそんなことはありません。
2.プロダクトオーナーって? プロジェクトの成否に関する責任をもつ唯一の存在。 チームにプロジェクトのビジョンを伝え、チームをリードする。 プロジェクトの舵取り役 チームで1番プロダクトのことを考える人。もちろん、ビジネス価値に基づ いて。 プロダクトバックログの優先順位の最終決定権を持ち、それに伴う説明責任 がある。 偉い人のようなイメージがあるが決してそんなことはありません。
大変なこと
大量のバックログ
さらに
迫りくるスクラムイベント
実施したスプリントの流れ 月 火 水 木 レ ビ ュ | プ ラ ン ニ ン グ レ ト ロ ス ペ ク テ ィ ブ 金 月 火 水 木 金 月 リ フ ァ イ ン メ ン ト スプリント期間は2週間 火 水 木 レ ビ ュ | プ ラ ン ニ ン グ レ ト ロ ス ペ ク テ ィ ブ 金
イベントが近づくと、 スクラムマスターが言うんです
どうしたものか。
リリース計画を立てる
リリース計画とは?
リリース計画とは? 何番目のスプリントで何をやるかを決めておくこと いつ、リリースするかを決めておくこと チームやステークホルダーにプロジェクトの 方向性を示すツール スプリントが終わる度に見直すことが重要!
リリース計画が 無い時 / 有る時
とあるレビューの日 チーム:「出来ました!」 PO:「すごく良い感じです。」 チーム:「じゃリリースしますね!」 PO:「え、いや、次やる機能作ってからにしましょう。」
リリース計画が 無い時 / 有る時
どのスプリントでどの機能を リリースするかが明示されているので、 リリースに関してチーム内で 議論することがなくなりました。 チームとしては、やはり成果物を早くリリースしたいものです。 リリース計画を立てておくことは重要でした。 事前に
チームの雰囲気も 良くなります。
もっと大変なこと
もう少し大きくして見てみましましょう
プロジェクトの成否
己との戦い
KPI
結 果
チームは、、、
解 散…
SCRUMの可能性を実感
自己組織化
自己組織化とは 自己組織化(じこそしきか、英: self-organization、selfassembly)とは、 自律的に秩序を持つ構造を作り出す現象のことである。 自発的秩序形成とも言う。
チームワーク 機能横断的 KPT 振り返り 自発的行動 自己判断
繰り返す
BESTな判断
BESTな判断
”チーム”として
BESTな判断
ご清聴 ありがとうございました!
スクラムマスターから見たヤプログ! 自社ブログサービス「ヤプログ!」でスクラム開発 GMOメディア株式会社 天野 弘仁
1.⾃自⼰己紹介 天野弘仁 スクラム歴1年年未満 主要⾔言語は、Java です。 現在はスクラムマスターとして 社内のプロダクト開発に スクラムを導⼊入してより良良くしよ うと奮闘中。 認定スクラムマスター
アジェンダ 1. はじめましてSCRUM 2. やって良かったこと 3. 変化するチーム 4. 反省と課題 5. まとめ
1. はじめましてSCRUM
このプロジェクトの システム責任者として 呼ばれました。
・プロジェクトのプレッシャー ・新しい事やる余裕なんてない ・スクラムなんて反対だった ・慣れたやり方でやりたかった ・スクラムマスターをやるなんて思ってなかった
いろいろ課題が出まして 話し合って出した解決策が ロールを変更することでした。
チームを出て スクラムマスターに 挑戦することになりました。
1. はじめましてSCRUM 2.やって良かったこと 3. 変化するチーム 4. 反省と課題 5. まとめ
素直に受け入れました。
ピュアな スクラムを心がけました。
プロダクトオーナーも チームのみんなも スクラムマスターも 同じ本を読みました。
知識を蓄える 同じネタで盛り上がれる 説明が必要な際に引用し易い (みんなに通じる。)
チームメンバーを 変更しました。
(ほぼ)アナログ化!!
・模造紙 ・付箋紙 ・マジック
Product Backlog Redmine
モヤモヤ⼀一覧 Googleスプレッドシート プロダクトをより良くする為 のメモ
1. はじめましてSCRUM 2.やって良かったこと 3.変化するチーム 4. 反省と課題 5. まとめ
無秩序(カオス)な状態に 秩序を入れようとする。
慣れ浸しんだリズムを 変えようとする!!
スクラムマスターは その改革(変化)を 推進する人となります。
SCRUMは 合理的 で 残酷 だと 感じました。
・前のやり方が早いし・・・ ・MTG多いし・・・ ・こんな短時間で見積もれな いし・・・
反発や攻撃の矛先は (容赦なく) スクラムマスターに 向けられるでしょう。
決して スクラムマスター(自分)が 悪いわけ(原因)ではない!
みんな変化に 戸惑っているだけ!!
変化後は・・・
もうちょっとプロジェクトが続き突き 詰めていければ かなり⾼高速に開発が進めていけそうな ⼿手応えは感じた。
チームでの 助け合いが 素敵だった
自分でデザインを決め、 プロジェクトのデザインにおいては 責任感を得られた
次もやるなら開発は スクラムでやりたい と思えるような 良い開発方法だと思った
1. はじめましてSCRUM 2.やって良かったこと 3. 変化するチーム 4.反省と課題 5. まとめ
喋り過ぎました。
多忙過ぎました。
威圧感 出し過ぎました。
プロダクトオーナー のサポートが できませんでした。
1. はじめましてSCRUM 2.やって良かったこと 3. 変化するチーム 4.反省と課題 5.まとめ
変化する時って 戸惑いや、反発、パワー 必要ですよね!?
改善を繰り返していけば 少しずつ受け入れ 変化していきます。
折れない心!!
この我々の事例がこれから SCRUMをはじめる方々の 何か一つのヒントになれば 幸いです。
ご清聴ありがとうございました。
これからの取り組み① ◯SCRIM導入での課題 ● SCRUMのワークフローの理解 ● SCRUMイベントの意味の理解 ● プロダクトオーナーこそ一番大事、難易度 も高い ● 仮説と検証が大事 ● 本来の目的を見誤らない。 115
これからの取り組み② ◯SCRUMの継続による価値創出を目指す ● 当初の2つの大きな課題解決へは手応え o 可視化 o 自己組織化 ● ただし、これが出来るのはメンバーの一部 のみ o 今後は裾野を広げる取り組みを o 全体的に可視化、自己組織化 § その上での価値創出がゴール 116
〆
御礼
プロジェクトのビジョンを関係者全員で
みんながバスに乗った
基本に忠実に
自分で考えられるチームが出来た
感謝