私達Backlog開発チームでは2016年1月から現在まで約3ヶ月、アジャイル開発手法のScrumに取り組んでいて、それなりに成果がでているように思います。理想的に上手く行っているという程ではありませんが、その試行錯誤の様子について書くことにしました。Scrumに興味がある方の参考になれば幸いです。
※なお、私達の製品であるタスク管理ツール「Backlog」とScrum用語の「バックログ」が紛らわしいので、製品のほうはアルファベット、Scrum用語のほうはカタカナで表記しています。
もくじ
発端
ある日、弊社CTOの縣が言いました。「Scrumやってみません？」
Backlog開発チームリーダーの中村が言いました。「やりましょう」
私はまだヌーラボに入って日が浅いですが、こういうことをわりと軽い感じで始めてしまえる企業文化は得難いものがあるなと思います。
目的
「開発にリズムを作りたい」縣が最初からずっと言っていることです。私達のプロダクト「Backlog」はおかげさまでユーザ数も増え、日々のサポートや問い合わせ、サーバ障害への対応だけでもかなりの作業量となっています。それらをこなしながら、ユーザの皆様に新機能もお届けしたい、既存機能の改善もしたい、UIも刷新したい、と、やりたいことも山ほどあります。
去年までは、各自の判断でできそうな課題をやっていて、より優先度の高い問題が発生したら、できそうな誰かがやっている作業を中断してとりかかっていました。良く言えば柔軟、悪く言えば行き当たりばったりと言えたかもしれません。
課題の管理には当然Backlogというツール（とても便利なのでおすすめです！）を使っているので、作業を中断しても忘れ去られたりということはないのですが、優先度や担当者の変更、今やっている作業を中断すべきかどうかの判断を毎回するのは少しずつですが各人の負担になっていました。そして、今にして思えば、作業がたびたび中断することによる効率やモチベーションの低下もあったように思います。
少しずつでも前進している、Backlogというプロダクトが毎月良くなっているという実感を得られるようにしたい、そして何より、もっともっとユーザの皆様により良い体験を届けたいという思いがありました。
準備段階
Scrumチームには (1)プロダクトオーナー (2)スクラムマスター (3)チームメンバー という3つの役割があります。自然な流れで縣がプロダクトオーナーに、中村がスクラムマスターになりました。それ以外のメンバーは6人なのでScrumで言われている「全部で9人まで」という基準に適っています。
縣と中村は仕事の合間に勉強して、「Backlogチームのスクラム開発」というドキュメントを作成しました。その最初の方には次のように書いてあります。
目的
– 開発にリズムを作りたい
– 目標に向かってチームが一丸となって集中して取り組めるようにしたい
– 良いプロダクトや機能を生み出せるようになりたい
成功のイメージ
– 今週やるタスク、今月やらなければいけないタスク、今月末にアウトプットされる成果が明確になっている
– ３ヶ月〜半年先までのプロダクトバックログが管理され、開発計画が明確になる
– 自分が全体のどこを作業しているかがわかる。また、チームがどこに向かっているかがわかる。
このドキュメントは毎回のスプリント計画ミーティングで参照され、更新され続けています。目標を明文化して共有するのはどんな活動であっても大切ですね。
そしてScrumで非常に重要とされている「プロダクトバックログ」の作成ですが、元々課題はBacklog上に山のように積み上がっています。初回スプリントでは見積もりにくそうな「新機能・機能改善」は外すことにして、「バグフィックス」の中から優先度の高いものを選んでGoogle Spreadsheetで一覧表を作成し、優先度順に並べました。
第1回計画ミーティング
社内にScrum経験者はいるものの、Backlogチームは全員Scrum初心者です。まず教科書通りにやってみて、それから考えよう、という感じでスタートしました。
説明を聞いて「なんとなく良さそうだな」という感想はありましたが、計画ミーティングにしっかり時間をかけるとか、スプリント中の割り込みを許さないとか、それらが実際にどのように影響するのかについてはうまく想像できなかったのです。
私個人は「まあダメだと思ったらやめればいいし。」ぐらいのノリでした。他のメンバーもだいたいそんな感じだったのではないでしょうか。こういうものはあまり気負い過ぎないのがいいんじゃないかと思います。
一般的にスプリント期間は1〜2週間と言われていますが、私達の第1回スプリントは1月13日〜31日の2週間半でした。理由は単に「キリがいいから」。どれぐらいの長さが自分たちに合っているのかわからないので期間も手探りでした。
見積もり
Scrum には「ポイント見積もり」という活動があります。プロダクトバックログの各項目に対して、それが基準としている作業と比較して「どの程度大変そうか」を見 積もるのですが、最初の方のスプリントではやっていませんでした。理由は「なんか難しそうだから」。見積もりはすべて「何時間かかりそうか」という実時間見積もりでした。
Scrumでは課題ごとに、メンバー全員が「いっせーのーせっ」で自分の見積もりを提示する「プランニングポーカー」を行います。Backlogチームは3拠点に分かれていてミーティングはビデオチャットを使っているので、カードを使った方法は使えません。そこでみんなで一斉に 編集できるGoogle Spreadsheetが役立っています。誰かが編集状態にしたセルは他の人からはグレー背景に見えるという仕様を利用して、全員のセルがグレーになった ら「いっせーのーせっ」と声をかけるルールにするとスムーズにポーカーができます。
各項目はBacklogに登録されている課題単位で粒度はまちまちでした。それをそのまま見積もっていたため、課題によって2時間とか10日とか、かなりの開きがありました。
私のような新しいメンバーは改修する場所も方法も見当がつかないことが多く、勘で「うーん2日」とか適当なことを書き込んでいました。
スプリントでの作業範囲決定
各人1日およそ6時間をスプリント内のタスクに使えると仮定して、
(人数) × (6時間/日) × (残り日数) − (メンバー個別のスプリント外業務で使う時間)
で使える時間の合計を出しました。そして各課題の見積もり時間の合計がその数字に達したところで見積もり終了、これが「スプリントバックログ」となります。
「教科書通り」というにはかなり端折った形ですが、第1回計画ミーティングは4時間程で終わり、私達の初回スプリントは始まりました。
最初期（1回〜3回）
すぐに発生した問題
スプリント開始から1週間後の1月20日に、中間ふりかえりミーティングを行いました。これはScrumで決められたものではありませんが、最初は手探りしながらなので、一度集まってみた形です。そこで
- タスク外の仕事が結構あるので1日6時間も課題に使えない
- gitブランチを作って開発を行いテストを経てプルリクエストをマージするまでのフローに非効率な箇所がある
- Backlog上で課題を完了ステータスにする条件を決めてなかった
という問題点が出て、1日に使える時間は5時間とすることになり、gitを用いた開発〜リリースまでのフローは話し合って効率を改善し、
Cacooでフローの図を書いてBacklogのWikiに記載して全員で手順を共有しました。また、各課題はプルリクエストがマージされた時点で完了とすることに決めました。
Scrumに詳しい人から見れば当たり前すぎることなのでしょうが、完了条件と、完了までのフローをきちんと整備しておくことがとても大事というのもやってみてから気付いたことです。
最初の頃の感想
そして1月末にBacklogの本番環境リリースを行い、初回スプリントは終了しました。そのまま微調整をしながら2週間スプリントを2回ほど回して3月になりました。その頃に私達が感じていたことです。
集中できる
Scrumには「スプリント中は計画ミーティングで計画した以外のタスクを入れない（スクラムマスターが割り込ませない）」というルールがあります。この効果は始めてすぐ現れて、作業中断が大幅に減り、集中できる割合が増えました。スクラムマスターは心労が増えたかもしれませんが。
皆で一斉に見積もったのは良かった
一回目のスプリントにして、計画ミーティングで見積もりに時間をかける有用性は実感できました。メンバー全員で改修方法を話し合ったことにより、知識が共有されて何から手を付ければいいかわかりやすくなっていました。
先の予定がわかる
プロダクトオーナー視点では、作ったプロダクトバックログの上の方から消化されていく様子が見えるようになりました。多少のずれはあるにしても、どの機能がいつごろリリースできるのか、ある程度先まで見通すことができるようになりました。また計画ミーティングで計画したこと以外はやらないということは、逆に言えばミーティングに参加してさえいればスプリント中はチームメンバーが何をしているか聞かなくてもわかるということです。これらはとても安心感があるそうです。
実績時間の計測が面倒
見積もりと実績の乖離を計測するために実績時間を記録することにしていたのですが、自分の作業時間を測るのはやっぱり面倒なため精度も低く、結局乖離の状況が計測できたとはいえませんでした。
見積もりが難しい
最初の頃のプランニングポーカーでは、課題一つに対して各人が「えいやー」で何時間掛かりそうかを提示していました。そこでばらつきが大きければ話し合うのですが、各人とも確たる根拠がないため「なんとなく3時間」対「なんとなく10時間」のような議論になりがちでした。
想定外の作業がでてきて終わらない
実際に作業にとりかかってソースコードを見始めると、思ってもみなかった影響範囲があったり、付随して直さなければならない部分があったり、見積もり時に想定していなかった作業がでてきて予定時間を何倍もオーバーしてしまいスプリント内で終わらないケースがいくつも出ました。
試行錯誤期（4回〜現在）
こうしてみると初期に起こった問題は見積もりに関するものが多かったように思います。そういう問題を毎回のスプリントで修正しながら続けてきました。
4月8日現在、スプリントは8回目です。まだまだScrum初心者の私達チームですが、いくつかの改善を行ったりやめたりしながら少しずつ進んでいるのでこれまでに行った施策を紹介します。
専門家に意見を聞いた
3回めのふりかえりミーティングの日にBacklog-GuildWorksの集い #1でお世話になったギルドワークスの認定スクラムマスターである中村洋さんに東京オフィスに来て頂き、アドバイスをもらいました。進めていくうえでの心構えなどとても参考になりました。
こんな場合はどうするものですか？といろんな質問をしましたが、だいたい答えは「チームで話し合って決めてください」という感じで、なるほどScrumとはそういうことか、ととても納得しました。初心者にとって先達の教えはいつも貴重です。
1週間スプリント
教科書的には、スプリント期間を変えるとベロシティの計測値が当てにならなくなるため、変えてはいけないことになっています。しかし私たちはそれまでポイント見積もりをしておらず、ベロシティも出していなかったので、じゃあせっかくだから、ぐらいの軽い気持ちで5回めからは1週間スプリントに挑戦しています。
メリット：1回の規模が小さいので見積もりが楽。急ぎの用件を次回スプリントに回せるので割り込みが発生しにくい。
デメリット：毎週1日はふりかえりと計画ミーティングに時間を割くことになる。個人が使える時間の自由度が小さいため、メリハリや余裕がなく疲れる。追い立てられてる感。
1週間と2週間のどちらにするのが私達にあっているかはまだ結論がでていません。
ポイント見積もり・ベロシティ
中村洋さんの話を伺った日、「やっぱりポイント見積もりやりたい。ベロシティ計測したい」と私が言い出して「じゃあやってみようか」となりました。ほんとに腰が軽くていいチームだと思います。
プロダクトバックログの各課題に対して、それまで適当に「3日」とか「5日」とか見積もられていたものをいったんクリアしました。
次に、バックログの中から、そこそこの作業量があって、全員がやることをちゃんとイメージできる課題を選び、基準にすることに決めました。
そしてその基準の課題の作業量を「2」として、各課題はそれと比較してどれぐらい大変そうか、の数字を1、2、3、5、8のどれかで入れていきました。
これをしただけでは特になんの変化もありませんが、このプロダクトバックログが毎回のスプリントで消費されていくスピードが「ベロシティ」となり、この変化を計測し続けることで、様々な効果が期待できます。が、まだこれからですね。
ポイント見積もりはあくまでも、あまり詳細に考えずたくさんの課題を大雑把に見積もるためのものです。しかし基準となる作業のイメージを各人がしっかり保ったうえでやらないと、いつのまにか訳の分からない数字になってしまいます。そこでいつでもイメージを思い出せるよう、ポイント見積もりをする時使うSpreadsheetには基準となる課題に含まれるおおよその作業を書いておくことにしました。
ケーキ・クッキー
スクラムマスターの中村の提案で、スプリントで予定していたポイント分の80%を完了できたらケーキ、50％ならクッキーを会社に買ってもらえることになりました。見積もりが正しければ毎回100％完了できるはずなのですが…なぜかケーキは遠いです。
先週はみんなでクッキーを食べました。福岡メンバーはチョコレートショップで買ってきました。美味しかったです。
ミーティングの時に「ベロシティを上げるためには」なんて堅いことを言うより「ケーキのためには」って言う方がスムーズに発言できるというのも発見でした。
詳細見積もりによる精度向上
ポイント見積もりでしばらく先までの課題を大雑把に見積もった後、毎週の計画ミーティングではその週にやる課題だけを実時間で見積もります。あとから想定外の作業がでてくるという見積もり失敗をなくすため、ほとんど詳細設計レベルまで細かく課題を分割してそれぞれに何時間かかるか見積もることにしてみました。
おかげでスプリント7回目の計画ミーティングは5時間もかかってしまいましたが、各課題の詳細設計を全員で集中して行う効果は大きかったです。
- 全員で設計することで、作業をほとんど漏らさず洗い出せるようになった
- 手順がはっきり記述されるので新しいメンバーでもとりかかりやすく、知識の伝達にも役立つ
- 作業を明確にイメージできるのでプランニングポーカーでのばらつきが小さくなり、妙なモヤモヤ感がなくなった
- 他の人がやっている作業もだいたい把握できているのでプルリクエストのレビューがスムーズ
- 結果、予定時間と実績時間の差が数百％→数十％まで劇的に改善した。
たださすがに1週間スプリントの計画ミーティングに5時間はかかりすぎなので、このメリットを受け取りながらせめて2〜3時間まで短縮できたらいいなと皆で考え中です。
助けたこと／助けられたこと
Scrumの本には、デイリースクラム（朝会）で、
- 昨日やったこと
- 今日やること
- 困っていること
をチームに報告するとあります。私達はこれに加えて、
- 助けたこと／助けられたこと
を報告することにしました。
誰かの作業で問題が発生したとき、他のちょっと余裕がある人が手助けして3人で取り組むと、1人の場合の3分の1以下の時間で解決して、結果的にベロシティが上がる（＝ケーキが近づく）という現象がよく起こります。自分の作業に集中することも大事だし、助け合うことも大事ということですね。そのことを意識するためにあえて口に出して言うことにしました。
実績時間測定ツールbacklog-todo-timer
集中して作業するほど、実績時間を計測するのが面倒になります。面倒なのでそれ専用の小さなWebアプリ”backlog-todo-timer”を作りました。
http://backlog-todo-timer.herokuapp.com/
Backlogをお使いいただいているユーザ様であればどなたでも利用できますのでよろしければお試しください。
Backlog上で自分が担当で期限日が設定されている課題を一覧表示していて、タイマーStart/StopボタンをクリックするとStartからStopまでの時間を計測してBacklogの実績時間を更新します。
そして自分が担当となっているプルリクエストにもタイマーボタンがあり、プルリクエストのレビューにかかった時間を計測することができます。
実績時間がきちんと記録できれば、見積もりが正しかったかの効果測定になります。それにより次の見積もりがより確からしくなるというスパイラルを期待していますが、まだまだこれからです。
これを作ったので時間の計測が面倒という問題は多少改善されました。まだ使い始めたばかりで改善点がいろいろあるため、しばらくは私の余った時間はこれに費やすことになりそうです。
なお実績時間についてはチームで意識していることがあります。
- 予定時間を実績時間を少し超えるぐらいは気にしない
- 大きく超えた場合は「予定時間でできなかった」のではなく「見積もりが間違っていた」ととらえて次回の計画に活かす
計測することで気持ちが苦しくなるようでは本末転倒ですからね。
スプリント計画ツールspritoon
プロダクトバックログの作成やスプリント計画ミーティングのとき、Google Spreadsheet上で次のような作業をしていました。
- 各行に課題を記載し、Backlogの課題にリンクを貼る
- 優先度をつけて並べ替える
- 議論しながらメモを追加したり、細かく分割してそれぞれの見積もりをプランニングポーカーで行う
- 見積もり時間の合計が一定に達した時点でスプリント計画ミーティング終了
Google Spreadsheetでは、複数人でいっせいに書き込んだり行の追加や削除もできますが、やはりちょっと操作がモタついてちょっとした待ち時間ができたりします。そこでそういうことをする専用のアプリを、3月からヌーラボに入社したメンバーの新人研修という名目で作りました。WebSocketで双方向通信たくさんで楽しそうです。
最初”sushi”という名前だったのがいつのまにか”spritoon”になって、弊社デザイナーが悪乗り気味のスプラッシュ画面を作ってくれてたりしましたが任天堂のゲームとは一切関係ありません。
こちらもまだ改善中ですが、もしかすると将来的に公開もあるかもしれません。
俺達の戦いはこれからだ
Scrumを始めてから4ヶ月目に入っていますが、いまのところまだ、ベロシティが安定するとかそんな高度なところまで達してはいません。「正しく設計して見積もって、決めたとおりに集中して作業する」ということのために、少しずつやり方を調整している段階です。
ただ、始める前に比べてチームメンバー自身の知恵と議論でプロセスを改善するという習慣が根付き、多くのことが改善され、前に進んでいるという実感があります。
チームとしてより多くの価値をユーザの皆様に届けられるよう、頑張っていきたいと思います。
ヌーラボではプロセス改善も自分達でやりたい！というエンジニアを募集しています。