洗練されていくscoutyのスクラム開発

こんにちは、リードエンジニアの伊藤です。最近は 開発：組織づくり＝7：3 ぐらいの割合で仕事をしており、GWはホラクラシー組織の勉強をしていました。

scoutyの開発チームでは2017年10月からスクラムで開発を進めています。導入から7ヶ月が経ち少しずつ各プロセスが磨かれていき、今では教科書通りにすすめている部分もあれば、少しアレンジしている部分もあります。これからスクラムを導入しようとしている方や、他の組織がどうスクラムを実戦しているのか気になる方の参考になれば幸いです。

スクラムを導入した背景

まずスクラムを導入した背景ですが、一番大きな理由は従来のタスク管理方法では開発者の人数が増えた時にスケールしなかったためです。会社が動き出した2016年9月から2017年10月までは私と代表の島田の2人で製品の仕様決め、開発をしていたため、下図のようなスプレッドシートで開発スケジューリングをしていました。

2017年10月に2名のエンジニア（Web1人, 機械学習1人）が増え、開発に関わるメンバーが4人となったためスクラムを開始しました。
スクラムを選んだ強い理由はありませんが、以下の2つが会社の文化に合いそうだと感じました。

1. ベロシティで開発速度が計測できる。会社の哲学の一つに「推測よりも計測」というものがあるが、「なんとなく最近開発速度あがったよね」ではなくて定量的に判断することができる。
2. 個人の成果ではなく、チームとしてどれだけのアウトプットが出せるかを重視する仕組みである。会社への帰属意識が高いメンバーが多く、個人プレーで何かをするよりは組織として何ができたのか。という視点で働いている。

といいつつもこれらの理由は後付けのような感じで、会社の哲学として「LEANに実行する」（何か新しいことをやる時に、やる前にそれを否定しない。やってみて、問題があったらLEANに修正していけば良い）というものがあり、スクラムも実際にやってみないと組織に合う／合わないがわからないので、とりあえずやってみよう！と始まりました。

現在（2018年5月時点）では、Webチーム（開発者3人, 開発兼スクラムマスター1人, プロダクトオーナー1人）のみがここで説明するスクラム開発を採用しており、機械学習チーム（正社員1人, インターン2人）はKANBANで、ビジネスチーム（4人）はスクラムとKANBANを足して2で割ったような手法でタスク管理を行っています。ビジネス側のチームでスクラムを導入している話は他社でほとんど聞いたことがないので、その話も機会をみて記事にしたいと思います。

スクラム scouty Way

一番意見が割れるところでもあるKANBANの管理ツールですが、ZenHubを使っています。ブラウザExtentionでGitHubに機能を追加する形のツールなので、描画が遅いというデメリットがあるのですが、GitHubのIssueをそのまま使うことができるので、プルリクから #[IssueID] するだけでリンクを張れたりとGitHubとの連携の強さに大きなメリットを感じています。

スプリントの期間は2週間で、月曜に始まり翌週の金曜日に終わるようにしています。最終日の金曜日にスプリントレビュー（14:00 ~ 14:30）、スプリントレトロスペクティブ（15:00 ~ 16:30）、スプリント計画ミーティング（16:30 ~ 18:00）のスクラムイベントを一気に実施しています。最近はスプリント期間を1週間にしているチームの話をよく聞きますが、上記スクラムイベントのオーバーヘッドが大きそうなのと、(皆で時間を合わせないといけない)同期的なイベントはなるべく増やしたくないため、scoutyでは2週間で実施しています。

スプリントレビューはチーム内でスプリントの成果物をプロダクトオーナーが確認することが一般的だと思いますが、scoutyでは全社に対して「今スプリントでこういうものができました」という報告をしています。Webチームの成果だけではなく、スクラムを実施していない機械学習チームもこの2週間でやったことを報告して、ビジネスサイドのメンバーに周知しフィードバックをもらっています。
この目的は2つあり、1つは今作っているものがお客さんの欲しがっている機能とズレていないかお客さんと接している最前線のメンバーに確認してもらうこと。もう1つは最新の機能リリースや今後の開発予定を社員全員に共有し製品のアップデートを頭に入れてもらうことです。（この知識があることで営業やカスタマーサポートの質が変わってくると考えています）

スプリントレトロスペクティブでは、テストコードのカバレッジの確認（目標80%）や、チーム全体の残業時間の確認、KPTでの振り返りを行っています。
チームの残業時間については労働時間当たりの生産性の変化を追うために確認しています。チームの生産性を示す指標であるベロシティが上がっていても、その分労働時間が増えていたらただただ辛いだけですからね。
KPTはKeep（良かったこと／継続していきたいこと）、Problem（課題）、Try（課題を解決するために挑戦したいこと】を皆で出し合って振り返りを行う手法です。よく聞く話として、スプリントを重ねる毎にKPTで出てくる意見が徐々に減ってくるというものがありますが、弊社では7ヶ月経ったあともこれだけの付箋が張られています。毎スプリントで何かしら新しい取り組みをしており、日々スクラムが磨き上げられています。

scoutyでは前スプリントのKeepとTryが達成できたか確認し、達成できなかったものはKeepに残しておきます。達成できて無意識のうちにできるようになったものはWorking Agreement RuleとしてTrelloにまとめています。これは新しく社員が入ってきた時に、既存メンバーの開発の雰囲気を素早くキャッチアップしてもらうためです。

スプリント計画ミーティングでは、次スプリントで行うタスクの整理を行います。scoutyでは計画ミーティングの前までにそのタスクは「Ready」な状態になっている必要があります。「Ready」とは、そのタスクの内容や終了条件が誰が見てもわかるように詳細まで詰められている状態を指し、この状態にする行為をリファインメントと呼んでいます。リファインメントは手が空いているメンバーが自主的に行っています。
そして、計画ミーティングではタスクの複雑さ（完了までにかかるコスト）を見積もるためにプランニングポーカー（各自がタスクの複雑さを予想して数字が書かれたカードを出す。下の写真を参考）を行います。計画ミーティングの時点でリファインメントがされていないと、タスクの定義が曖昧なためプランニングポーカーで合意が取れず、計画ミーティング中にリファインメントすることになってしまいます。これは1人でできるタスクを複数人の時間を使ってしまうことになるので大変非効率です。

毎朝行うデイリースクラムでは「昨日やったこと／今日やること」を皆の前で発表することが多いですが、弊社では時間短縮のためそれを実施していません。Slackの #tasks チャンネルにメンバー全員が今日やることを書いているため、必要に応じてそこを確認してもらうようにしています。デイリースクラムではタスクを進めていくうえで障害となりそうな部分の確認や、他のタスクをブロックしているタスクの進捗確認をメインに行っており、平均すると約5分で終わっています。

最後に

少し特徴的な部分のみを抽出してscoutyのスクラム開発を紹介してみましたが、いかがだったでしょうか。組織によって最善な手法は異なると思いますが、気になるものがあればとりあえず取り入れてみて、問題があれば修正して改善してみてください。LEANに実行しましょう。

今回紹介したものはscoutyのメンバーの力だけで生み出してきたものではありません。株式会社エウレカの梶原さんには一度スクラムイベントの様子を見に来て頂いてアドバイスを頂いたり、Regional Scrum Gathering Tokyo 2018 では @ryuzee さんに機械学習チームへのスクラム開発導入について意見を頂いたりと外部の方/スクラムコミュニティの力をお借りして改善してきたものです。大変感謝しております。

弊社Webチームは6月に2名のエンジニアのジョインが決まり計6人となります。2019年春までには合計12名（2チーム）の開発組織にしていこうと計画しており、採用を強化しているところです！
少しでも興味ある方はぜひオフィスに遊びにきてください！スクラムイベントをやっている日にスクラムイベントに茶々入れに来てくださっても結構です！