データチームもScrumでやってきた

こんにちは！この記事は、[グロービス Advent Calendar 2018](https://qiita.com/advent-calendar/2018/globis) の17日目の記事です。グロービスのデータチームがスクラムを導入した話をさせていただきます。


# 背景：スクラム(scrum)を導入
今年(2018)七月末、メンバーが増えてきて、それに応じて、データチームがスクラム開発体制を導入しました。スクラムについて、ウェブ上でも書籍でも色々説明があると思っていて、ここで詳しく述べるのを割愛しますが、簡単にいうと、よく使われているウォーターフォール(water fall)開発フレームワークのかわりに、アジャイルで現状を柔軟に対応できる開発フレームワークの一つ、「スクラム」というものです。

[参考： SCRUM BOOT CAMP THE BOOK](https://www.amazon.co.jp/SCRUM-BOOT-CAMP-BOOK-%E8%A5%BF%E6%9D%91/dp/4798129712)

![image.png](https://qiita-image-store.s3.amazonaws.com/0/200629/3d571251-d5ad-a2fb-083b-108ffa2788bf.png)



# データチーム構成
* PO (Product Owner) 
    * ストーリー式のプロダクト(やること)を決めます。各依頼、求めていること、やっていきたいことなどを元に起票します。
* Scrum Master
    * 主要役割は、PO & 開発メンバーの間に挟んで、架け橋として各タスクをうまく進めるようにします。リソースを調整しつつ、POにも開発メンバーにも密接にコミュニケーションを取ります。
* 開発メンバー
    * タスクを完了し、プロダクト(成果物)を作ります。

つまり、Product Owner、Scrum Master、開発メンバーという三つの構成になっています。


# スクラムの流れ

主に下記の図のように、プロセスを回しています。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/200629/2e50048b-ef3b-da11-9c79-deb2fe627f5f.png)

* スプリント計画MTG
    * どのストーリー式のプロダクトをスプリントに入れるか決める場です。また、各プロダクトに含めるタスクを、開発メンバー同士と話し合って決めます。ストーリーのポイント(工数に似ていて、基準ストーリーに相対工数のイメージ)を足して、バーンダウンチャート(Burn Down Chart)を描いて、スプリントを始めます。

* 開発
    * 開発メンバーがのせてあるタスクを潰し、プロダクトを作ります。

* Daily Scrum
    * 毎日、開発メンバーが現状と進捗を共有し、「やったこと」、「やること」、「困っていること」など伝えます。優先順位や緊急タスクや勤怠などの問題が発生したら、適宜でタスクやストーリーを調整します。メンバーのメンタル面なども迅速で把握し対応します。また、振り返りMTGで出て来たアクション(後ほど記述)もレビューします。

* スプリントレビュー(Sprint Review)
    * プロダクト(成果物)をレビューします。ちゃんと仕様通り作られているか確認し、メンバーがお互いに情報共有する意味もあります。

* 振り返りMTG (KPT)
    * 完了したスプリントや、チームの動きに対して、維持していきたいこと(Keep)、改善すべきところ(Problem)、試したいこと(Try)などを話し合って、振り返りを行います。また、改善点と試すことを元に、アクションを決めます。全員の合意に至って、且つ常に意識しやることであれば、working agreementとしてみんなで認識します。

* Refinement MTG
    * POが各プロダクトの説明を行い、お互いに認識を深め、scrum masterと開発メンバーが見積もりを出します。基準ストーリーに対し、どのぐらいかかりそうなのか想像しつつ、出した見積もりのばらつきがなくなるまで対話します。カードを使っていますので、一番面白い時間といっても過言ではありません。つまり、各メンバーがちゃんとプロダクトへの認識ズレをなくす目的です。そうすると、プロダクトに関わるタスクも出しやすくなるし、見積もりの精度も上がっていくわけです。

* Product Backlog MTG
    * POとscrum masterが、現状進めているプロダクトの進捗を考慮し、新規プロダクトの優先順位を決めます。バックログの起票もできます。



# 使っているツール

* 付箋 + white board (Story Backlog、タスクバックログ、バーンダウンチャートなど)
![image.png](https://qiita-image-store.s3.amazonaws.com/0/200629/e6e34edb-1942-326a-61e5-7400b331a024.png)

* Trello (KPT 振り返り用)
![image.png](https://qiita-image-store.s3.amazonaws.com/0/200629/9f1a0d5e-eb44-7ea7-3467-5a4cb59e1bb5.png)


* StoryOnBoard (Story Backlog)
![image.png](https://qiita-image-store.s3.amazonaws.com/0/200629/7778003a-7bc9-2204-7e83-1d98eca652a3.png)


* slack (連絡、依頼フォームにて新規タスクからの自動通知)
![image.png](https://qiita-image-store.s3.amazonaws.com/0/200629/9070b75b-69e8-3d3e-e186-a8c0434900a7.png)

* Github (タスクバックログ)
![image.png](https://qiita-image-store.s3.amazonaws.com/0/200629/42c8bd59-1674-361c-3ae8-b3e93e083470.png)


# 課題
スクラムを行ってきて、課題も結構ありました。それらはKPT振り返りを通して、徹底的にアクションを実施しています。一部ここで述べさせていただきます。

* 依頼がバラバラ、工程に影響
    * 最初各部署からの依頼は、slackチャンネル、口頭、メールなどバラバラになっていましたが、社内の方がGASを通して、Googleフォーム&slack自動通知機能を開発してくれて、現在は全部統一しています。依頼は全て依頼フォームから飛んできて、POもメンバーも集中できて、効率がとてもあがってきました。[GASの参考はこちらです。](https://qiita.com/tanabee/items/4a5056f468ae71d8d648)

* 見積もりを出しにくい場合 (見積もりの精度)
    * ストーリーを分類し、「調査系」、「開発系」、「分析系」の三つで分けられ、それぞれに応じて考慮し、精度をあげる工夫をしています。
    * 更に、見積もりがものすごく多くなった場合、ストーリーの細分化を行い、小さくしています。
    * 各プロダクトを作る背景をきちんと納得するため、ストーリーのテンプレート(標準化)もしています。

* バーンダウンチャートの消化(ベロシティ消化)が遅れている場合
    * 各メンバーのスケジュール(休みなど)を事前メモし、計画MTGで消化できるストーリーのポイントを考慮しています。
    * 毎日Daily Scrumにて、進捗が遅れた場合、バーンダウンチャートにメモし、KPTで話し合って、改善案を出して動いています。
 
![image.png](https://qiita-image-store.s3.amazonaws.com/0/200629/2635a26c-2d44-9345-4c68-c77eaa78227d.png)


* 成果物の管理
    * 最初は散らばっていて、今は全部Gihubの看板機能を利用し、成果物を登録しています。


また、計画MTGをやっている途中、中断されないように、「会議中」という看板も作りました。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/200629/3ead0103-ff12-eb0c-e73d-9668d8980d81.png)


あと色々もありますが、ここで割愛させていただきます。また次回話させてください。


# 最後に
スクラムをやっていて、ここまで約半年が経ちました。メンバーと色々乗り越えて、辛かったり嬉しかったりしています。もちろんまた幾つの課題も出ると思いますが、メンバー同士と一緒にチャレンジを受けつつ、クリアしていこうと思っています。これからも頑張っていきましょう ^0^