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

こんにちは！この記事は、グロービス Advent Calendar 2018 の17日目の記事です。グロービスのデータチームがスクラムを導入した話をさせていただきます。

背景：スクラム(scrum)を導入

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

参考： SCRUM BOOT CAMP THE BOOK

データチーム構成

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

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

スクラムの流れ

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

• スプリント計画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、タスクバックログ、バーンダウンチャートなど)
  

• Trello (KPT 振り返り用)
  

• StoryOnBoard (Story Backlog)
  

• slack (連絡、依頼フォームにて新規タスクからの自動通知)
  

• Github (タスクバックログ)
  

課題

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

• 依頼がバラバラ、工程に影響

  • 最初各部署からの依頼は、slackチャンネル、口頭、メールなどバラバラになっていましたが、社内の方がGASを通して、Googleフォーム&slack自動通知機能を開発してくれて、現在は全部統一しています。依頼は全て依頼フォームから飛んできて、POもメンバーも集中できて、効率がとてもあがってきました。GASの参考はこちらです。

• 見積もりを出しにくい場合 (見積もりの精度)

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

• バーンダウンチャートの消化(ベロシティ消化)が遅れている場合

  • 各メンバーのスケジュール(休みなど)を事前メモし、計画MTGで消化できるストーリーのポイントを考慮しています。
  • 毎日Daily Scrumにて、進捗が遅れた場合、バーンダウンチャートにメモし、KPTで話し合って、改善案を出して動いています。

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

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

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

最後に

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