This page is intended for users in Singapore. Go to the page for users in United States.

洗練されていく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チーム)の開発組織にしていこうと計画しており、採用を強化しているところです!
少しでも興味ある方はぜひオフィスに遊びにきてください!スクラムイベントをやっている日にスクラムイベントに茶々入れに来てくださっても結構です!


Webエンジニア
日本最大の "人" のデータベースを作りたいWebエンジニアWanted!
LAPRASは「世の中のミスマッチを解消する」というミッションを掲げ、機械学習や統計的自然言語処理など最先端の計算機科学技術を用いたHR techサービスを提供している会社です。 あなたもSNSアカウントがあれば、LAPRASに集められた情報を確認することができます。是非試してみてください。 <サービスページ> https://lapras.com/ <会社紹介資料> https://speakerdeck.com/lapras/lapras-company-profile インターネットに存在する情報を収集し、客観的に評価する事でスキルや価値観を可視化することで、その人の力が発揮できる企業とのマッチングを行います。 従来の転職サービスのような経歴だけに関わらず、能力や努力に見合った正当な評価や機会を提供することを目指しています。 ◆ LAPRASが目指している未来 私たちの人生には可能性が無数にあります。 しかし、人は必ずしも人生を豊かにする機会に出会い、選択できるとは限りません。 例えば、日本のキャリア事情に目を向けると、従来のナビサイトや転職サービスでは能力や努力に見合った正当な評価や機会を得られていない人たちもいます。 本当に好きなことがあるのに食べていけるか不安で諦めた人、自分の望むキャリアや待遇を得るため努力しているけど方向があっているのか不安な人。 LAPRASはこうした人たちが夢を掴む機会を提供できるかもしれません。 LAPRASは、インターネット上にあるデータと最先端の人工知能技術を用いて、偶然を必然に変え、世の中のミスマッチをなくしていくことを目指します。それは結果として、個人の市場価値や生活の質を高め、企業の競争力を高めることにつながると考えています。
LAPRAS株式会社
LAPRAS株式会社's job postings
Anonymous
3d24a6d9 2ebd 44ca 929c 3c359466bbe7?1560340061
23231609 884906325012153 7340051220649470478 n
Picture?height=40&width=40
C1e6a108 0b65 400f adb3 bfef2d57bbbe?1545533148
86b66fcb deb4 4a94 9e0d 582e29f5c3c6?1556172558
14 Likes
Anonymous
3d24a6d9 2ebd 44ca 929c 3c359466bbe7?1560340061
23231609 884906325012153 7340051220649470478 n
Picture?height=40&width=40
C1e6a108 0b65 400f adb3 bfef2d57bbbe?1545533148
86b66fcb deb4 4a94 9e0d 582e29f5c3c6?1556172558
14 Likes

Weekly ranking

Show other rankings
If this story triggered your interest, go ahead and visit them to learn more

Page top icon