こんにちは。Android開発チームのグループマネジメントを担当している衛藤です。 Android開発チームでは、不動産・住宅総合サイトのLIFULL HOME'S Androidアプリを開発しています。
Android開発チームでは、2019年9月にスクラム開発を導入しました。 もともと2014年あたりにスクラム開発を行っていたのですが、今回再導入するまではウォーターフォール型で進めたり、アジャイル風に進めたりと様々でした。 前回は私自身メンバーとして稼働していましたが、今回は初スクラムマスターとしてチャレンジしました！！
スクラム開発導入に至った背景や導入後の効果、遭遇した問題点と対応策などについてご紹介してみようと思います。
長い記事になりますので、時間を持て余しているときにでもゆっくり読んで頂けると嬉しいです。
導入の背景
スクラム開発を導入する以前は、以下のような体制で開発を進めていました。
- プロジェクト単位でエンジニアをアサイン
- 見積りはアサインされたエンジニアの裁量で算出
- 必要があればMockを作成し、早い段階で軌道修正する
- 3ヶ月など長期に渡るプロジェクトは、中間レビュー会を開くなど、細かくマイルストンを設定
- 予めどのリリースバージョンに入れるかを確定し、そこに合わせて開発していく
- プロジェクト遅延の場合はリリース日を調整する、もしくは、間に合いそうな場合は無理やり対応
- アプリのクラッシュバグや機能バグについては、個人の空き時間等を利用して対応（緊急性の高いもの以外）
うまくいく場合はもちろん問題ないのですが、何か問題が発生するとすぐに遅延や遅くまでの残業が発生してしまい、心身ともに枯れ果ててしまうケースが度々発生していました。 また、バグ対応についても施策の優先度が上がってしまうと対応を後回しにしてしまい、品質が落ち始める事態となりました。
そこで、現在の開発体制から見直していこうと、以前やっていたスクラム開発を再び導入してみることにしたのがことの発端です。
スクラム開発とは
Webや専門書籍にスクラム開発に関しての情報がたくさんあるため詳細は割愛しますが、1週間〜1ヶ月程度のスプリントというイテレーションを繰り返し、イテレーション毎に振り返りによる改善を実行することで、開発効率をチームとして上げていくアジャイル開発フレームワークの一つです。
一般的なウォーターフォール型とは違い、追加されたタスクはプロダクトバックログと言われるスタックに積まれていきます。 そのため終わりが多少見えづらくなるデメリットはありますが、その分品質を担保しつつ継続的に動作可能物をデリバリーすることが出来るため、問題の早期発見や起動修正など柔軟な対応ができます。 このように、スクラム開発は「短い期間で、最大限の成果をあげる」ことが可能になる開発手法です。
すべての現場にスクラムが合っているわけではないので、現状のプロジェクト体制やチームメンバーとも協議のうえ、選択すると良いのではないかと思います。 スプリントが一定期間でまわり続けるため、慣れない最初はスピード感を感じないかもしれません。いかし、一度慣れてくると高速に回る開発サイクル・成長するチーム・品質の担保を実感できます。 特にスクラム開発の醍醐味である「自律的なチーム」に育っていく様子も感じられるのは幸せな瞬間です。
それでは、LIFULL HOME'S Androidチームがスクラム開発を始めて変わったこと・問題点をどう対処してきたか、などを紹介していきたいと思います！
まずはスクラム開発の一般的ルールに則って開始
スクラムルールの整理
チーム独自のルールを定めても良いのですが、まずは一般的なスクラム開発の手法に則って始めてみることにしました。改善する箇所は徐々にチーム独自のルールに変更していく予定です。 そこで、どのようなルールやイベントがあるかをチームで定めます。
- インセプションデッキ
- スプリント
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
以下、順を追って簡単に説明していきます。詳細については、Webや専門書籍等を参考にしてみてください。
インセプションデッキ
インセプションデッキとは、プロジェクト憲章とも呼ばれ、プロジェクトに対するビジョン・方向性や基本的な取り決めをチームやステークホルダー全員で定義する文書のようなものです。 取り決める内容はチームによって変わってくるかと思いますが、一般的には
- 我々がいる理由、何を目指しているのか
- プロダクトのニーズ・差別化ポイントを簡潔に
- やること・やらないことを明確にする（スコープの設定）
などを決めます。
プロジェクトが進む上で、様々な問題によりチームが乱れてきたとき、インセプションデッキに立ち戻ることで、改めてチーム全体の方向性を再認識することができます。 また、「最初に作って終わり」ではなく、定期的に振り返って内容を精査することも大事と言えます。
LIFULLは、ビジョンを大切にする会社です。社員全員がビジョン・経営理念に共感し、そこから具体的なビジョンを最小組織単位で掲げています。 このビジョンは、部署メンバー全員で話し合いのうえ決めるため、インセプションデッキと同義とみなし今回は割愛しました。
スクラムイベント
スプリント
スプリントとは、一定期間内にユーザーストーリーなどのタスクを実行し、動作可能物をデリバリーするイテレーションのことです。このため、スプリント期間をチームで定める必要があります。
もともと、Androidチームでは2週間単位でアプリのアップデートを行っていました。スクラム開発のスプリント推奨期間は1週間〜1ヶ月なので、そのまま2週間を1スプリント(=1イテレーション期間)として開発をしてくことにしました。
小規模なプロジェクトでは1週間でも可能かと思いますが、少しサイクルが早すぎて息苦しさを感じるかもしれません。逆に1ヶ月だとスプリントごとの改善効果が出るのが遅くなることもあるかもしれませんね。 チーム内で相談して最適なスプリント期間を定めるとよいと思います。試しにスプリントを回してみて、不都合があればスプリント期間を変えるのも一つの手段と言えます。
LIFULL HOME'S Androidチームでは、
月曜にスプリント開始、翌週の木曜日にスプリント完了、隔週金曜日はスプリントプランニング → 終わったら飲み会🍺
というスケジュールを組みました。（パーッと騒いで週末を迎えられる心理的安全性。でもだんだん飲みに行かなくなる・・・）
スプリントプランニング
1回のスプリントで対応するタスクを定めます。スプリントに入る前のタスクはプロダクトバックログというスタックに積まれ、それが「すべて」の作業を意味します。 そのプロダクトバックログの中で優先度を付け、スプリント期間に収まる量のタスク(=チケット)を開始前に整える作業を行います。
スプリントプランニングで定めたタスクは、基本的にはすべて完了させます。すべて効率よく完了させるため、開発メンバーは声を掛け合ってどの作業を担当するか各自で定めて開発を行っていきます。 以前のように「この施策は●●さんにアサイン」ということはなく、施策単位で担当するか手分けして施策を完成させるかは開発者に委ねられています。
スプリント期間に収まるかどうかを判断するには、各チケットに工数が振られていないといけません。この見積作業もスプリントプランニングでチーム全員・または開発者全員で行うことが必要になります。
そして、スプリントプランニングは時にはかなり長い時間をかけることもあります。極稀にですが、3−4時間スプリントプランニングを行っていたこともありました。
なお、工数については後ほど触れますがストーリーポイントを導入しています。これにより相対的見積が可能になるとともに、全員で見積るため考慮漏れによる工数超過やその逆の超過見積りが減って精度が高まっていきます。
デイリースクラム
一般的なデイリースクラムに従い、以下の内容を15分以内で話します。
- バーンダウンの確認
- 昨日やったこと
- 今日やること
- 問題・障害になっていること
しかし、やっているうちに問題が出てきたため、後述の方法に改善をしています。
スプリントレビュー
スプリントの最終日は成果物を全員で触り、見落としや致命的なバグがないかの確認をやっています。問題があれば、次のスプリントバックログに積んで対応を行います。
また、このスプリントレトロスペクティブは、テスト仕様書を伴わない探索的テストも兼ねており、機能テストでは発見しづらいバグやデグレードの発見にもつながっています。
各スプリントでは、毎回Buffer工数を設けており、スプリントレビューで発生したバグについては、そのBuffer内で出来る限り消化するようにしています。
スプリントレビューが終わり、masterブランチにマージされたものが「次期リリース可能状態」となりリリースフローに乗ることになります。
スプリントレトロスペクティブ
スプリントが終わる度に、振り返り会を行います。
KPT方式で、Keep / Problem / Tryを話し合い、やりにくい点や問題点を早期発見し、具体的な改善策を実行することで次のスプリントに活かしていきます。
スプリントレトロスペクティブでは、改善策を話し合ったあとに、それを実行するアクション担当者のアサインまで決めてしまう運用でしたが、ここでもひとつ課題があり、改善が必要だったため後述にて改善策について触れています。
使用ツール
初めてスクラム開発を行う場合は、ホワイトボードやコルクボード等の物理的なボードを利用することも推奨されていますが、今回は弊社で利用しているJIRAにスクラム開発機能がサポートされいるため、そちらを利用することにしました。
- JIRA スクラムボード
- プロダクトバックログ
- スプリントバックログ
- バーンダウンチャート
- ベロシティグラフ
- SpreadSheet (スプリントプランニング補助ツールとして)
ストーリーポイント(SP)の導入
ストーリーポイント(以下、SP)と言われる見積手法を使っています。SPとは、単なる見積ではなく、あるタスクを基準（このタスクで"2時間"など）として、相対的に見積りをする手法です。
この見積を開発者全員で話し合い、スプリントプランニングでそのスプリントで対応するタスク量の目安を確定します。また、スプリント完了時に何SP完了したかをベロシティとして計測が可能になります。
SPは時間ではなく、あくまで単位、という考え方が一般的なようですが、Androidチームでは以下のような基準を定めています。
| SP | 換算 |
|---|---|
| 1 | 1時間以内で終わるタスク |
| 2 | 2時間以内で終わるタスク |
| 3 | 2時間〜4時間以内で終わるタスク |
| 5 | 4時間〜6時間以内で終わるタスク（ ≒ ミーティング時間を除いた1日の実稼働時間） |
| 8 | 8時間以内で終わるタスク ( ≒ 残業すれば1日で終わる) |
| 13 | 2日以内で終わるタスク |
このように、SPが大きくなるほど時間に幅を持たせることで、考慮漏れなどの事態が発生しても見積時間内に収まるように調整しやすくなります。
最大は13SPになっていますが、基本的にはこのレベルのSPになった場合は、更に細分化して小さいSPへと変換していきます。
13SPでは、まだ内容がしっかりと把握できていなかったり、見落としによるリスクが多いと考えているためです。
タスクを見積可能な状態で細分化し、一つ一つのタスクに対して一斉にSPを出し合います。（プランニングポーカー）
そして、一番SPが少ない人・多い人で理由や考慮漏れなどが無いかの認識を合わせることで、驚くほど見積りの精度が上がります。
また、SPは決めた通りに動かなくといけないわけではなく、
- 予定よりも早く終わったら、前倒して次タスクに取り掛かる、または予定になかったリファクタなどを行う
- 予定よりも多くかかりそうなら早めにスクラムマスターに相談、タスクを再整理する
という動き方をしています。
見積りは個人のレベルや経験年数などに応じて必ず差が出てきます。
特に個人間では認識に違いがなかったとしても、差が出てしまうのはそのためです。そのような場合はプランニングポーカーで出した数字の中間のSPを設定するようにしています。
このままでは個人間の差が出てしまうため、各人が持っている工数（稼働時間）に対して、係数を設定することで、誰が対応しても全体的には見積り通りに収まるような仕組みを導入しました。
以下、例を記しました。
- 1スプリント = 9day × 1日稼働6hours(ミーティング等の時間削除) = 54hours
- 開発者Aさん 係数:1.0 = 54hours
- 開発者Bさん 係数:1.2 = 64.8hours
- 開発者Cさん 係数:1.1 = 59.4hours
- 開発者Dさん 係数:0.9 = 48.6hours
- 係数を加味したトータル時間 = 226.8hours を該当スプリント期間の全稼働工数とする
- Buffer期間（スプリントレビュー後のバグ修正や不測な事態への考慮）: 全体の1〜2割 = 226.8 * 0.2 = 45.36hours
- 全稼働工数 - Buffer = 226.8hours - 45.36hours = 181.44hours
この場合、最終的な181.44hoursを全稼働と想定し、そこに収まるSPの時間合計をスプリントバックログに仕込みます。
もちろん、進行によっては早めに終わったり、Bufferが不要になる場合もあるので、そのときは予定になかったタスクを前倒したり、リファクタリングを行う時間に充当します。
早く終わったからといって早く帰るのではなく、その分最大限の付加価値を提供できるようにチームとして動くことが大切です。
この計算により、大幅に想定外の事態で遅延したり、バタついて付け焼き刃での対応を入れることによる品質低下を招くことがほぼなくなっています。
余談
チーム独自のルールとして、「バグやクラッシュ対応をする時間を必ず入れる」を徹底しています。
1スプリントごとに、5〜10SP程度の時間を必ず設け、品質向上に務めることにしました。平均して大体3-4のクラッシュを対応しています。
発生数や発生箇所によって優先度を付与し、高いものから順次スプリントバックログに予め積んでいくことで、品質向上につなげることが出来ます。
クラッシュやANR(Application Not Responding)はユーザーがアプリから離れてしまう原因に直接的につながってしまいます。
1クラッシュ等の些細なクラッシュも必ずチケット起票し、優先度を付与します。
Crashlyticsでクラッシュ状況の監視を続け、件数が上がってきた時点で優先度を付け替える作業も行うことで、「気付いたら大量クラッシュしていた」という事態も回避出来るようにしておきます。
この地道な作業により、以前と比較し確実に品質が上がってきたことが分かりました。具体的な結果については最後にまとめています。
スクラム開発を導入の結果
これまでに記載したとおり、開発方針や体制は事前にチーム内で合意を取り開発に着手しました。
導入して2〜3スプリント経ったあたりから、効果が目に見えて分かるようになります。
- 炎上案件がほぼなくなった（焦って修正してまたバグが発生する、などが極端に減る）
- 施策の優先度や差し込みタスクの調整がしやすくなった
- 品質が圧倒的にあがる
- 見積精度が高いので、スケジュール引き直しがほぼ発生しなくなった、など
ただ、やっていく中で、やはり問題点は出てくるものです。そのような問題点はスプリントレトロスペクティブで洗い出し、次々に改善をしていきます。
このあとは、浮上してきた問題点や課題をどのようにクリアしていったかをご紹介します。
発生した問題・課題とその対処について
振り返りアクション事項の放置
スプリントレトロスペクティブは毎回行い、うまく行った点や問題点を深掘って話し合えるのはいいのですが、それで満足してしまうことがありました。
そうなってしまうと、せっかく決めたTRY項目が実施されずにまた次回以降の振り返りで課題にあがってしまうことになってしまいます。
そこで、週に1回開催しているチーム定例の最初に、アクション事項の進捗を確認する時間を設けました。
スプリントレトロスペクティブで出たTRY項目は残さず定例議事録に記すことで、対応を忘れてしまうことなく週単位で改善して行けるようになっています。
施策の優先順位、仕様追加時のルールが曖昧
優先度が高い施策からスプリントバックログに登録はしているものの、少し気が緩んでしまうとまた元の状態に戻ってしまいます。
その結果、「差し込みタスクとして無理やり工数にねじ込んで作業 → 焦ってしまうため品質が低下してしまう」という事態が発生してしまいます。
最初に決めたルールを厳格化し、
- 施策には優先度を必ず付ける。低・中・高だと優先度が被ることがあるため、番号で優先度を付ける
- スプリントバックログには、番号が優先度の番号で一番若いものから積んでいく
- 優先度が入れ替わった時点でスクラムマスターに相談、現時点のスプリントバックログの優先順位を入れ替える。工数が溢れたものは次回以降のスプリントバックログに移動
- 仕様追加時は、追加分のSPを見積り、Buffer時間で出来そうならそのまま対応。あまりにも大きい場合は優先度を入れ替える
このようなルールを厳守することで、チーム内でバタつき混乱することがほぼなくなっています。
何より重要なのは、このルールをチームとして合意しておくことです。開発者が勝手にこのような行動すると認識の食い違いによるトラブルが発生してしまうため、ステークホルダー全員で握っておくことが大切だと思っています。
1スプリント = 1リリースの問題
当初は、もともとやっていた2週間サイクルのリリースと合わせてスプリントを回していたため、
1Sprint = 1リリース
として開発をおこなっていました。
そのため、スプリント名もSprint_v1.2.0のようなバージョン名をもとに作成していました。
これでも十分スクラム開発の利点は発揮できるのですが、少しでもバタついてしまうと以下のようなことが発生してしまいます。
- 1施策でも考慮漏れや仕様追加によりスケジュールが伸びると、スプリントが破綻する
- 無理やりねじ込んで作業する
- スケジュールが伸びた場合は、次のスプリントも予定通りに開始できない
- 次のスプリントもバタついてしまい、負の連鎖に陥ってしまう
そこで、スプリントとリリースの関係を次のように変更することをチームとして合意します。
- Sprint = リリースではない
- リリースはこれまで通り2週間サイクル
- ただし、リリース時点でmaster branchにマージされているものだけがリリース対象
このように、Sprintとリリースの関係を断ち切ることで、負の連鎖を解消できます。
ここでも重要なことは、チームとして方針に合意することです。全員の認識が合っていることで、施策調整がスムーズに進むようになりました。
そこで問題になるのがスプリント名です。これまでのようにリリースバージョンを付けるわけにはいきません。
スプリント名を考える
単純なことです。リリースバージョン名以外を付ければよいのです。ただ、普通に名前を付けるだけだとつまらないですよね。
コードネームのような形で以下の方針に決めました。
アルファベット順にその文字から始まる動物の名前をスプリント名とする
こうしてみると、スプリント名を決めるイベントが楽しみになってきます。
ちなみにこれまでは
Sprint_Alligator / Sprint_Butterfly / Sprint_Chicken / Sprint_Dingo / Sprint_Echidna / Sprint_Falcon / Sprint_Gekco ・・・
のような名前を付けてきました。
毎回スプリント名を決めるときは大いに盛り上がり、定期的な息抜きにもなるのでオススメです。
動物が終わったら次は何にしよう・・・笑
SPの精度測定
こちらはまだ試している途中です。
スプリント終了後、SPの見積がどれだけブレていたかを振り返る機会がありませんでした。
そこで、タスク終了時にざっくりとかかった時間を記録してもらい、ブレた理由や浮いた時間がどれだけ発生したかを観測できるようにしています。
スクラムイベントの形骸化
長く続けていると、やっていることが形骸化してしまい、気づかずに「なんとなく続けている」という状態になってしまいます。
そうなってしまうと、もはや続けている意味はありません。やめてしまうか、やり方を変えるかの2択になります。
今回はっきりしてきたものが「デイリースクラム」です。
前述の通り、
- 昨日やったこと
- 今日やること
- 問題になっていること
を一人づつ共有するのですが、慣れてくると「昨日やったこと、共有やること」の単なる報告会になってしまっていました。
これではデイリースクラムをやる意味がありません。毎朝チャットに一人づつ書けばよいだけです。
もともとデイリースクラムを行うのが、日次で各自の作業状況を把握し、小さな問題だとしても報告、事態が大きくなる前に解消する、という目的があります。
そこで導入したのが「ファイブフィンガー」です。
有名なアジャイルの書籍である「KAIZEN JOURNEY」
でも紹介されていましたが、ファイブフィンガーとは、
- 1本：絶望的でどうしようもない
- 2本：不安がある、問題になりそうな種がある
- 3本：普通。可もなく不可もなく
- 4本：うまくやれているかも！
- 5本：絶大な自身がある！すばらしい！
この基準に則り、デイリースクラムで全員が一斉に手を出してその日の状態を共有します。（一斉というのがミソです。バラバラと出すと先に出した人に合わせてしまう傾向があるため）
そして、全員出揃ったら一番本数が少ない人からその理由を聞いていきます。
そのときに少しでも問題がありそうならその時点で調整を行い軌道修正をします。
4本以上の人にも話してもらうことで、チーム全体に安堵感を与えることにも繋がります。
ファイブフィンガーの導入により、問題になり得る小さな種を早期に発見し、大きな問題になる前に軌道修正も可能になり、ますます安定した開発チームとなっていきます。
スクラム開発を導入して変わったこと
これまでに、スクラム開発の手法や問題点について紹介してきました。
導入後、どのようなチームに変わってきたかも触れてみたいと思います。
見積のブレが少なくなっていく
スクラム開発導入に伴い、ストーリーポイントを開発者全員で出すようにしました。
最初の頃は、ブレもありバーンダウンが収束しないこともありましたが、最近では多くても見積りプラス・マイナス1時間程度に収まっています。 全員でタスクを見積るため、考慮漏れやいつもなら直前に発覚したであろう問題などを、なるべく事前に協議し解消することが出来るようになっています。
バーンダウンを意識するようになるチーム
デイリースクラムでは、毎回バーンダウンを確認するようにしています。バーンダウンとは、タスクの見積りに対して日次でどの程度のタスクを消化する必要があるのかを示すグラフです。
参考までに、これまでに行ったスプリントで最初の頃と最近のバーンダウンを以下に貼ります。
このように、最近ではキレイに理想線に従って進むことが出来ています。
スクラムを始めた当初は、チーム全員でバーンダウンを意識することが少なかったのですが、バーンダウンを毎日確認することで納期に関する意識付けにも繋がっています。
なくなる炎上PJ
スクラム開発以前は、メンバー各自が施策にアサインされ、見積り・設計・開発を独自に進めていました。これにより個人作業による見積り時の見落としや追加作業によりリリース日に影響を及ぼすことがありました。
しかし、スクラム開発を導入し、全員の知見を見積り時に集合させることで遅延の割合が激変しました。
これにより、夜遅くまで作業し、さらに次の施策にまで影響が出るという負の連鎖の解消に繋がっています。
劇的に改善するCrashfree Rate
アプリのクラッシュはユーザーにとってストレスの高いイベントです。あまりに多くクラッシュが発生するアプリはアンインストールにもつながるため注意が必要です。
弊社では、Crashlyticsを導入し品質を数値として監視しています。
安定した品質のプロダクトは、ユーザーにも安心感を与えます。開発しているアプリがどれだけの品質かを示す指標が、Crashlyticsで提供されている「Crashfree Rate」というものです。 これは、アクティブなユーザー・デバイスのうち、どの程度の割合がクラッシュせずに利用できているかを示しています。
また、全期間でクラッシュ数を比較すると、以前にくらべてかなり改善したことが確認できます。（下図の点線は前年度比較です）
過去90日間の比較で、Crashfree Rateは0.5%向上しました。直近3バージョンの比較では、99.95%前後を維持できています。
向上率としては小さいかもしれませんが、ある程度のDAUを抱えている状態で品質を維持し続けるのは大変難しいことです。
スクラム開発により、健全なチーム体制を整えることができ、皆が自律的な対応をとることで品質向上・維持も実現することが出来たのは非常に嬉しいことです。
（何よりメンバーのみなさん、ありがとうございました！！）
まとめ
自律的チームへの第一歩
スクラム開発を導入し約半月が経過しました。プロジェクトの進行はスムーズになり、品質はこれまでの歴史の中でトップクラスの水準に達しようとしています。
「どうすれば課題をクリアできるのか」「共通のゴールを達成するためにどう動くべきか」をメンバー一人ひとりが考え行動した結果が出始めてきたのではないかと思っています。
単純に言われたタスクをこなすのではなく、チーム全員が共通のビジョン・ゴールに向かって突き進んでいくことが何よりも重要であると実感しました。
高い効果を実証できたので、今後もスクラム開発は続けていく予定です。しかし、現状で満足しているわけではありません。
長く続けていく中で、必ずやりにくい点や課題は浮上してくるはずです。そのような壁をチーム全員で解決し、高速に、高品質なプロダクトの開発を進めて行きたいと思っています。
長くなりましたが、最後までお読み頂きありがとうございました！！
スクラム開発や、LIFULL HOME’S Androidアプリチームの体制について、少しでも興味を持って読んで頂けたなら嬉しいです！
最後に
Androidエンジニア募集中です！！
最後に、LIFULL HOME'SのAndroid開発チームは、一緒にプロダクトを成長させていって頂けるメンバーを募集しております！
現チームメンバーと一緒に、最新技術をいち早く取り入れ、開発を楽しんで頂ける方、ぜひ以下の応募フォームよりエントリーくださいませ！！
「入社までは考えてないけど、社風や事業内容聞いてみたい…」という方向けに、カジュアル面談も実施しています（採用合否には関係ありません）。
カジュアル面談は以下からご応募ください！
一緒に働ける日を楽しみに、お待ちしております！！！
