こんにちは。ライクル事業部 エンジニア兼スクラムマスターの寺戸です。
ライクル事業部には現在 2 つのチームが存在していて、私はそのうちの 1 つのチームのスクラムマスターを担当しています。
今回は、私がライクル事業部のスクラムマスターとして取り組んだ施策の中でやって良かったと思ったことを紹介します。
それ、いつ頃リリースできるの？問題
ライクル事業部では、PM 陣が「いついつまでにこれこれこの機能をリリースしたい」というロードマップを策定し、そのロードマップに沿って開発を行っています。
ロードマップに沿って開発はしていきますが、なかなかそのロードマップ通り順調に開発が進んでいくばかりではありません。
そうなった時に、「この機能はいつ頃リリースできそうなのか？」という問題がついてまわります。
こういったスケジュールの話はどこのプロジェクトでも発生するのではないでしょうか。
ライクル事業部では現時点での進捗が策定したロードマップ上のどの程度のところまで来ているのか、というのが正確に可視化されていなかったので、私のチームでその可視化にチャレンジしてみました。
バーンアップチャートとは
バーンアップチャートとは、その機能を作り終えるために必要なタスクと完了したタスクの累積を可視化したものです。
縦軸が必要なタスクの総量で横軸が時間軸で表現されます。
下記のバーンアップチャートは実際の私のチームが現在開発している機能のバーンアップチャートです。
あまりキレイなチャートでなくて恐縮ですが。。
どうでしょう？
この機能は 9 月 29 日までに開発を終えることを目標としていますが、なんとなくそれ以前に完了しそうなことがこの図から伝わると思います。
簡単にこの図の解説をしますと下記のとおりです。
- 天井の青い実線 … タスクの総量
- 緑の実線 … 完了したタスクの量の推移
- 緑の破線 … 最高消化ポイントで消化した場合の予測線
- グレーの破線 … 平均消化ポイントで消化した場合の予測線
- 赤い破線 … 平均を下回るペースで消化した場合の予測線
このグラフを作成するためには色々とやることがありました。
- 必要なタスクの洗い出しとその見積もり(正確な見積もりではなくざっくりとした見積もり)
- 平均消化ポイントの算出(グレーの破線の元になるもの)
- 最高消化ポイントの算出(緑の破線の元になるもの)
- 最低消化ポイントの算出(赤い破線の元になるもの)
各ポイントの算出方法
バーンアップチャートを作成する上でここが最も重要なポイントになるかと思います。
前提として、ライクル事業部ではタスクを事業系タスク、改善系タスク、保守系タスクの 3 つに分類して管理しており、各スプリントにおいて 事業系タスク:改善系タスク:保守系タスク = 6:2:2 の割合でアサインするようにしています。
参考: エンジニア歴 17 年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。
また、それらに分類されないミーティングや、弊社の制度の 1 つで技術研鑽の時間に充てられる growing-pain(通称グロペ)の時間も実際の業務時間には含まれるのでそういったもののポイントも記録するようにしています。
ベースとなるポイントの算出
直近の 10 スプリントの平均消化ポイントを元に、バーンアップチャートを作るためのベースのポイントを以下のように定義しました。
1 スプリントあたりの平均消化ポイント - MTG などのその他のタスクのポイント = 開発などの作業に充てられるポイント … (A)とする
これと前述の 6:2:2 の割合の法則を元に各ポイントの算出方法を定義します。
各ポイントの算出方法の定義
バーンアップチャートは「事業系タスク」のポイントの累積なので、1 スプリントでどれだけ事業系タスクにポイントを割り振れるかをパターン別に可視化します。
- 最高消化ポイント: (A) のポイントを事業系タスクに全振りしたもの
- 平均消化ポイント: 事業系タスク:改善系タスク:保守系タスク = 6:2:2 に則り、
最高消化ポイントに 60%をかけたもの - 最低消化ポイント: 直近 10 スプリントで最もポイント消化が少なかった時のポイント
これらのポイントの算出方法はあくまでも私達のチームにおいて最適な算出方法であっただけなので参考程度に見ていただけると幸いです。
バーンアップチャートを導入した結果
バーンアップチャートを運用し始めた結果、以下のような効果がありました。
視覚的に分かるようになったので開発の進捗を把握しやすい
目標に対して現在の進捗が一目瞭然になるので PM だけでなく他のチームに対しても共有が簡単になりました。 視覚化されたことは PM からはかなり好評だったのでやって良かったと思えました。
グラフの変化に応じてパターンを決める後押しにも
タスクの追加削除に応じてグラフが変化して完了予定日が前後するのも計画段階では非常にありがたいです。
私達のチームでは実際に機能開発する前に、実装のパターンを 3 パターンほど用意してそれぞれのパターンでポイントの見積もりを行いました。
その結果、
「PM の要望をフルで実装するパターン 1 ではリリース日は 1 ヶ月後になりそうですが、画面を作らず CLI で対応するパターン 3 の場合は 2 週間でできそうです。」
といった会話があり、リリース日との兼ね合いでどの実装パターンにすべきか悩んでいる時の決断の後押しにもなりました。
戦略の立て直しが早めに行える
中期的な進捗状況が可視化されたことで、予定していたスケジュール通りに終わりそうにないということが早めに判明したりもします。
その結果、「今回のリリースからはこの機能は外しましょう」だったり、「ちょっとリリース日を後ろ倒しできないか調整してみます」といった会話が早め早めになされるようになりました。
もう少しで終わる！という気持ちになる
これは心理的な話ですが、日々スプリントをこなしていくことは終わりのないマラソンをひたすら走っているような気持ちになってしまいます。
バーンアップチャートがあることで明確にゴールが存在するのでこのバーンアップチャートが登り切れば完成だ！あと少し頑張ろう！という前向きな気持を後押ししてくれます。
終わりに
スクラム開発におけるバーンアップチャートの導入についてお届けしました。
スプリントのバーンダウンチャートは運用しているけどバーンアップチャートは運用していないというチームも意外とあるんじゃないでしょうか。
バーンアップチャートを運用したことがない、運用してみたいというチームは是非これを機に導入してみてその結果を聞かせていただければ嬉しいです！
最後までお読みいただきありがとうございました！
