開発現場以外でも
「スクラム」
GMOペパボ株式会社
和島 史典
自己紹介
 和島 史典(わじま ふみのり) @wajimaf
 埼玉県狭山市
 昭和50年生まれ 39歳 2児の父
 もともとはDTPデザイナー 1996年からWEBデザイナー
 いろいろ経験して 広告代理店・企画会社ディレクター・取材
 GMOペパボで WEBデザイナー・プロデューサー・マネージャー
 スクラム導入の動きに合わせてスクラムマスター業
自己紹介
スクラムマスターとしての取り組みの紹介
 2013年2月からJUGEMブログでスクラムマスター
 他サービスでのスクラム勉強会 東京・福岡
 社内カンファレンス
 WEB+DB PRESS Vol.78事例寄稿
GMOペパボの紹介
 2003年創業 「ロリポップ!!レンタルサーバー」
 2014年4月 paperboy&co.から社名変更
 ドメインサービス「ムームードメイン」
 ショッピングカート「カラーミーショップ」
 ブログサービス「JUGEM」
 ヘテムル ブクログ 30daysAlbum カラメル
 minne SUZURI ロリポタッチ kiteco
アジェンダ
 導入事例
GMOペパボ(主にJUGEM)でのスクラム導入話
 開発現場以外でのスクラムの取り組み
法務とCS(カスタマーサービス)でのやりとり
新卒向け研修としてのワークショップ
GMOペパボでのスクラム導入
 2013年2月 JUGEMから導入開始
きっかけは「障害」
属人化されていた
リリースまでのプロセスが曖昧
テストの環境が不十分
コード管理が十分になされてなかった
焦っていた
「仕事のしかた」から変えていかねばならぬのでは
導入前のJUGEM
 運用しながらの新規開発
→ ユーザ対応
不具合対応 調査などなど
→ 老朽化の進むハードウェア
死にゆくサーバ コスト的なメリットでの乗せ替え
→ 日々バージョンアップするいろいろ
ミドルウェア プログラム 脆弱性・・
ブラウザ PC ガラケー スマホ タブレット・・
導入前のJUGEM
 予測不能な割り込みタスクが盛りだくさん
→ 都度都度対応できる人が対応している状況
→ 優先順位も結構「気づいた順」
→ その場限りの対応 「なんか新規開発すすまないね」
導入前のJUGEM
 属人化していく
→ 歴史あるサービスが故の負債
・ドキュメントが古い もしくはない
・バージョン管理されてない
・ローカルにしか存在しないコード
・その人にしかわからない nogami_special.php
→ 休んだらどうなるの? もしやめたらどうするの?
導入前のJUGEM
 七夕の短冊のような叶わぬ開発計画
→ やりたいことは決まれど、手がつけられない
・スケジューリングが無意味
・あれ?全然すすんでないの?
→ そこへ来ての障害
「仕事のしかた」から変えていかねばならぬのでは
書籍を読んだり勉強会したり、外部講師を招いたり
1周間スプリントで回し始めました
スクラムマスターとしてやったこと
 「見える化」 で抱えてるタスクの洗い出し
→ 個人で抱えるのはやめよう
スクラムマスターとしてやったこと
 「優先順位」 でタスクの管理
→ タスクボード作成
→ デイリースクラムで共有
→ 割り込みが発生したらすぐPOへ
スクラムマスターとしてやったこと
 「ふりかえり」 でKPTを出す
→ 主にプロセスについて
→ 良かったこと・悪かったこと
それぞれで原因をさがす
→ それを次のスプリントで試す
スクラムマスターとして気づいたこと
 理解は容易・習得は困難
→ 気兼ねなく突っ込む 本質を聞く
「あれ?それって今やるんだっけ?」
「計画時と違わない?POに確認した?」
「遅れてるなら助け求めないとじゃないの?」
→ 時には天使のように、時には鬼のように
→ スクラムマスターは大変である。。。
スクラムマスターとして気づいたこと
 スクラムで気づいたこと
→ みんながわかるようになる
タスクボード・バックログで可視化
→ 決定権ある人が理解しやすい
やること(TODO)・やってること(DOING)
終わること(DONE)・やれる量(ベロシティ)
→ 何が終われば完成なのか
しっかりと計画することでゴールが明確に
透明性
スクラムマスターとして気づいたこと
 スクラムで気づいたこと
→ 進捗にあわせた協力
割り込みの可視化 タスクボード デイリースクラム
→ やばい状況もわかる
短いスプリント期間で調整が可能・変化に対応
定期的な検査・改修
スクラムマスターとして気づいたこと
 スクラムで気づいたこと
→ 雰囲気が良くなることが多い
デイリースクラム・自分が何のために存在しているか
→ みんなで考える
優先順位の共有・合意
脱属人化にむけてのチームワーク・困ったときは助け合う
良かったことも悪かったことも自分!
コミュニケーションのツールとして
スクラムマスターとして気づいたこと
私、気づきました
スクラムマスターとして気づいたこと
透明性
決定権ある人が見ても、誰が見てもわかるように
ゴールが明確で共有される
定期的な検査・改修
急激な変化に対応できる
コミュニケーションのツールとして
やっぱり仲良く仕事がしたい
スクラムマスターとして気づいたこと
開発現場以外でも活かせるのでは
(スクラムの本質から外れるかもしれないですが)
開発現場以外で試したこと・1
 開発現場以外で試したこと・1
きっかけは「法務グループマネージャーの悩み」
→ 法務グループの業務範囲が広い
→ 日々生まれるルーチンワーク的な業務が多い
→ サービス側でも判断できる物がある
開発現場以外で試したこと・1
 まずは現状把握
→ 現状の洗い出し
何に困っていて、どこまで手助けができるか
→ ゴールの設定
法務担当のF君の業務に関わる時間を減らす
開発現場以外で試したこと・1
 やらないと決めたこと
→ タスクボード・デイリースクラム・計画
やることは決まってるし、距離が離れている
→ githubやIRCで代用
→ 振り返らない
なんとなく決めるとか一度決めてハイ実行!では確実に
継続しないし、リスキーすぎる
→ お互いが協力関係であることの認識
仲良くお互い幸せになろう
開発現場以外で試したこと・1
書面到着
内容審査
依頼書作成
送信・報告
回答・検討
対応
完了報告
JUGEM
法務  このフローを共有し
メンバーで以下を
決定・試してみる
 まずは復習 徹底的に共有
 F君じゃなくてもできる部分を洗い
出し
 法務の専門知識が必要な部分
はそのままで残す
 他部署やシステムに関わる部分
は今回はいじらない
 まずはコンパクトに目的を果たす
開発現場以外で試したこと・1
書面到着
内容審査
依頼書作成
送信・報告
回答・検討
対応
完了報告
JUGEM
書面到着
内容審査
依頼書作成
送信・報告
回答・検討
対応
完了報告
法務
JUGEM
法務
開発現場以外で試したこと・1
F君の作業時間が4割削減できた!
JUGEM側では作業が増えたが、
JUGEMのデイリースクラムで共有し合いカバー
開発現場以外で試したこと・1
 重要な時間「ふりかえり」
週に1回、30分程度だが、必ず顔を合わせる
どんな些細な事でもKPTを出す
→ 問題点を洗い出し、次に活かす
→ 良い気付き、働きによるモチベーションアップ
→ 何よりも、お互いでやってる感がでる!
やらされてる感じゃなくてやってる感
開発現場以外で試したこと・1
 KPT例
このようなやりとりを毎週行っています
スプリント2
Keep
・ルーチンとしてできている
・フロー通りに動いている
Problem
1.書類のやりとりがめんどくさい
2.保管する範囲が確定してない
3.JUGEMでトラブって手が回らない
Try
1.PDFでやってみる
2.保管する範囲を決める
3.やばいと思ったらすぐ相談!
スプリント3
Keep
・PDF最高だ!
・IRCでコミュニケーション問題なし
Problem
1.PDFが多くて探すのが大変
2.まだまだ法務がボトルネックになる
Try
1.PDFのファイルの命名規則を決める
2.巻き取り箇所を増やしてみよう
開発現場以外で試したこと・1
SM、一人振り返る
 今回なぜこのような事をやるか、を明確にできた
 「何とかしたい」とみんな協力しあえる環境を作れた
 指示ではなく自主的に解決する機会を作った
 法務グループとJUGEMチームの責任者同士で
この働きの合意がとれていた
開発現場以外で試したこと・1
透明性
定期的な検査・改修
コミュニケーションのツールとして
この3つは実践できた
(これがスクラムなのかと問われると・・・)
開発現場以外で試したこと・2
 開発現場以外で試したこと・2
きっかけは「人事部マネージャーからのお願い」
→ 全社的にスクラムを推進している
→ 新卒社員がいきなりホワイトボードとか付箋見て
わけわからんようにならないか不安
→ 配属になる前にスクラムとは何かを伝えてほしい
→ 新卒は全部で10人!
開発現場以外で試したこと・2
 やったこと
ただ単にスクラムの仕組みだけ説明してもわからんだろう
ウォーターフォールとか言われても・・・
まずは我々がいる業界(IT)の流れを理解してもらって
なぜスクラム(的な意識)が
大事なのか を認識してもらう
開発現場以外で試したこと・2
開発現場以外で試したこと・2
ミクシー
フェイスブック
LINE
開発現場以外で試したこと・2
無料の
カートサービス
STORES.jp
×
BASE
開発現場以外で試したこと・2
 じっくり練って出して終わりではない
 みんなで探索して把握して対応してを
スピーディに「繰り返す」
そのためには
 自分たちで考えて行動する(自律)
 自分たちに制限を付けない(成長)
 みんなで一緒に大部屋で働く(交流)
開発現場以外で試したこと・2
 自己組織化することが重要
でも自己組織化って言われても・・・
 理解は容易・習得は困難を僕らは知っている
単なる座学では習得には至らない
いくつかワークショップを行い身を持って学んでもらう
ワークショップの内容は、角征典さん・角谷信太郎さんの研修で
学んだことをアレンジ
開発現場以外で試したこと・2
開発現場以外で試したこと・2
かかった時間は2分4秒
開発現場以外で試したこと・2
開発現場以外で試したこと・2
かかった時間は43秒
開発現場以外で試したこと・2
 自分たちで考えて行動する(自律)
 自分たちに制限を付けない(成長)
 みんなで一緒に大部屋で働く(交流)
自己組織化とは何かを実際に経験して身につける
開発現場以外で試したこと・2
開発現場以外で試したこと・2
 出てきた答え
最高の材料を集める
社長出身地ゆかりの物を使う
社長家族にサプライズで参加してもらう
究極に空腹になってもらう
などなど
開発現場以外で試したこと・2
 気づいて欲しかったこと
「味見してもらう」
 じっくり練って出して終わりではない
 みんなで探索して把握して対応してをスピーディに
「繰り返す」
これに気づいてほしい (ちょっと前に言ったのに。。。)
開発現場以外で試したこと・2
開発現場以外で試したこと・2
 ブロックを使って街づくり
1.3チームにわかれます
2.チーム内で役割を決めます(父・母・息子・娘など)
3.街にほしい施設をそれぞれ3つ書きます
4.「隣のチームの街」を作ります
街を「考える側」と、「作る側」、両方を体験する
開発現場以外で試したこと・2
 気づいて欲しいこと
1.作り手に目的を明確に伝える大事さ
2.決められた制限内(時間・人)で、どうすれば
目的が叶えられるか、計画づくり
3.その中で出てきた良い点・悪い点を振り返って
次に活かしていく検査・改修
4.変化に対応できるチームワーク
開発現場以外で試したこと・2
開発現場以外で試したこと・2
開発現場以外で試したこと・2
開発現場以外で試したこと・2
開発現場以外で試したこと・2
開発現場以外で試したこと・2
 とあるチーム
1.シングルファザーの家庭だった(妻は死別)
2.突然父親が再婚すると言い出した
3.死別した妻のために作っていた施設よりも再婚相手の
求めている施設の方が優先になった
さあどうする!!!
突然の変化にチームでどうやって対応するか
開発現場以外で試したこと・2
 残されている時間もブロックも少ない
1.再婚相手が「本当にほしいもの」を見極める
2.少ない時間で目的を叶えるために試行錯誤する
3.チームとしてどういった動きが最適なのかを検討する
突然の変化は日々やってきます
指示を待つより自主的に考え動く組織づくり
開発現場以外で試したこと・2
まとめ
 理解は容易・習得は困難を僕らは知っている
必要な知識と協力し合える環境が大事
 本来スクラムは開発手法だが
その中には「仕事のしかた」としてどの環境・職種でも
活かせる良いアイディアがたくさんある
まとめ
 ご清聴ありがとうございました
GMOペパボでは
一緒に働けるエンジニア仲間を
待ってます!

GMOペパボ 開発現場以外でも「スクラム」的な取り組み