GMOメディアとスクラム
Tweet
どうも、あんま考えていないようでホントに何も考えてません。
ともぞー@ディレクターです。
GMOメディアで運営しているヤプログ！というブログサービスがあるんですけど、ある日のことです。
偉い人「そろそろ本格的にヤプログアプリ作りましょう！」
じぶん「はい」
偉い人「スクラムで」
じぶん「はい。（全然意味わかんないけど頷いとこ）」
今までヤプログ！ではいわゆる“ウォーターフォール”という開発モデルで進めていたのですが、今回は偉い人を信じて“スクラム”を導入することに！
今回はそのスクラムの取り組みについて、状況を踏まえて紹介したいと思います。
また、スクラムに対する知識と理解はこの2ヶ月でそれなり身に付いてはいるのですが、偉そうにあーだ！こーだ！言えるほどのノウハウはありませんので、我々の状況をメインにお伝えしていく予定でございます。
はじめに
チームメンバーは15,6名ほど。
しかも、誰1人としてスクラムでの開発経験はありません。（たぶん）
キックオフはチームメンバー以外の関係者にも集まっていただき、インセプションデッキの作成から始まりました。
インセプションデッキとは？
アジャイル開発で使用されるツールの1つで、プロジェクトの全体像(目的、背景、優先順位、方向性等)をわかりやすく伝えるためのドキュメントです。アメリカのシリコンバレーではよく使われてるみたいです。言葉はむずかしそうですか実際テンプレートに合わせて簡単に作れてドキュメントは見やすくてわかりすいです。プロジェクトのなぜなぜなぜを考えるのは面白いです。
しかし、このインセプションデッキの作成にかなりの時間を要しました。
どれぐらいでしょうか、キックオフから10日以上は過ぎてたのではないでしょうか？
外部からコーチングの方を招いたり、グループ会社にも協力いただき、スクラムに精通している方にも参加していただいたにもかかわらず…です。
それは関係者の人数も多く、皆で集まれる時間が取れないことや、会議室の準備などにも少なからず影響を受けていたはずです。
が、1番の理由は新規サービスではなく、既存事業の再定義だったことに1番足を引っ張られていたように感じました。
環境改善(※1)の為に行うインセプションデッキに足を引っ張られていては本末転倒でございます。
(※1)ヤプログ！は今までサービスを造る”サービス開発部”とサービスを運営する”事業部”とで部署を跨いでサービスを動かしていました。
※サービスによって開発部と事業部が分かれるという編成はGMOメディア社の中でも少ない方のサービスです。（たぶん）
それ故にインセプションデッキでサービスを再定義し、ビジョンを共有する狙いがあったのです。（たぶん）
スクラム始動
チーム構成とスクラムイベントについて先に書いておきます。
- チーム構成
- プロダクトオーナー1名
- スクラムマスター1名（ぼくが立候補しました）
- 開発チーム15名 ※スクラムで推奨している開発チームの人数は5-9名なので、かなり溢れている状況。
- スクラムイベントについて
- スプリント期間：2週間
- スプリント計画：隔週木曜日
- スプリントレビュー・振り返り：隔週水曜日
- プロダクトバックログリファインメント：隔週水曜日
- デイリースクラム：毎日10:00～
インセプションデッキの作成も終わり、バックログの洗い出しも一通り完了。
※バックログの作成はユーザーストーリーマッピングを利用しました
プロダクトオーナーがバックログに優先順位をつけ、プランニングポーカーを使ってバックログの見積りを行いました。
正直、この時点になってもほとんどのメンバーがスクラムを理解しておらず、今やっている作業はなんの為にやっているのか理解出来ている人はいなかったと思います。
僕はスクラムマスターとして、チームに理解を深めてもらうことよりも「1度スクラムで開発をやってみた方が身になるのでは？」と思い、スプリントを開始しました。
正直、グダグダでグデングデンのまま1回目のスプリントを終えました。
振り返りはKPTを利用して行い、スクラムマスターとして解決出来そうなものは1つ1つ改善していきました。
恐らくメンバーそれぞれのモヤモヤは解消されないままスプリントは進んでいたと思います。
（今でもそうかもしれませんが。笑）
しかし、そのモヤモヤこそスクラムにとっては糧になるものでありまして、
SCRUMは実践したから開発が上手くいくというものではない。SCRUMは問題点が見つけやすくなり、その問題点の改善をチームで行うことで結果としてソフトウェアの開発が成功するというモデルだ。
http://morizyun.github.io/blog/scrum-agile-xp-book-review/
とあるように、そのモヤモヤ＝問題点をチームで改善していくのです。
あくまでもスクラムはフレームワークと定義されているので、スクラムの枠の中であれば自由にカスタマイズ可能です。
むしろ、カスタマイズ＝改善出来ることが素晴らしいのではないでしょうか。
今回はスクラムとの出会いをお話しました。
次回は、現在の状況をはじめ、改善していった内容について書いていこうと思います。
レポートする気はあったのですが、まったく写真を撮っておりませんでした！
なのでスプリント計画とレトロスペクティブの間に行われたピザ会の様子を…
しっかり文章を書くと疲れますね、次回はもっと雑にラフな感じでお届けしたいと思います(^~^)/
