こんにちは。都志（@louvre2489）です。
これは Chatwork Advent Calendar 15日目のエントリです。
Chatworkではアジャイルを前提に開発を行っています。プロジェクト特性やチームのルールに依って多少特色はありますが、ほぼ全ての開発がアジャイルに行われているのではないでしょうか（詳細は未確認）。
アジャイル開発に慣れてくるとどういう風に開発を進めれば良いかも共通知ができてくるのですが、アジャイル開発を導入し始める時によくわからなくなるポイントの１つとして『スケジュールをどのように可視化するか？』という課題があると思います。
この課題に対して、私の所属しているチームで行っているスケジュール作成の方法を紹介させていただきたいと思います。
アジャイル開発のスケジュールを立てよう
実はこの内容、以前に藤井 (@yoshiyoshifujii) が書いてくれています。
上記ブログでは、『見積り』の部分が重点的に書かれていたので、今回はその見積りを使ってどのようにスケジュールを可視化していくか、というところにフォーカスを当てたいと思います。
ちなみに、『何を可視化したいか？』によって可視化の方法は変化するはずなので、ここで紹介した方法が絶対の方法ではありません。
チームとその周囲の人たちの関心事に合わせて、必要なことを可視化することが大切だと考えています。
見積りを行おう
作業対象を並べた上で、上記で紹介したブログに従って見積りを行います。徐々に精度を上げていくので、このタイミングでは粗い見積りとなります。
今回はシンプルな匿名掲示板システムを作ると想定して、見積りを行っていきます。
まずはエピック『掲示板にメッセージを投稿する』を一番最初に取り組むことにチームで合意したので、このエピックのストーリーの労力を見積ります。
そして、他のエピックは想定労力からの換算で仮のSPを算出します。（わかりやすくするためにキリの良い数値にしています）
これによる見積り結果は以下のようになりました。
| エピック | 優先度 | 換算によるSP | 実際に見積ったSP | スケジュールに反映するSP |
|---|---|---|---|---|
| 掲示板を作成する | 4 | 10 | 10 | |
| 掲示板内容を参照する | 2 | 20 | 20 | |
| 掲示板を削除する | 5 | 10 | 10 | |
| 掲示板にメッセージを投稿する | 1 | - | 20 | 20 |
| 掲示板のメッセージを編集する | 3 | 20 | 20 | |
| 掲示板のメッセージを削除する | 6 | 10 | 10 | |
| 掲示板の内容をCSV出力する | 7 | 30 | 30 | |
| 合計 | - | - | - | 120 |
実際にはエピックを作業の優先順に並べて運用するのが一般的かもしれませんが、今回は扱う対象が似ているものエピックをかためて並べています。
ベロシティを計測しよう
一番最初に取り組む作業は決まっているので実際に作業を進めてみます。エピック『掲示板にメッセージを投稿する』内にはいくつかのPBLがあるはずですが、ここではその詳細は割愛します。
２スプリント回した結果、いくつかのPBLを完了させることができ、以下のような結果が得られました。
| スプリント | ベロシティ |
|---|---|
| 1 | 5 |
| 2 | 7 |
この５とか７という数字の大小に意味はありません。大切なのはその数字のブレが少ない（少なくとも減少傾向にない）ことです。
スプリントごとにこの数字が安定していることを確認することによって、チームが安定した開発を行えていることを自覚することができます。
完了目処を可視化しよう
開発を開始して実績が数値化されたので、これをベースに完了目処を可視化してみます。
ポイントは以下のとおりです。
- 最初から完璧なスケジュールは立てられない（徐々に精度を向上させる）
- 周囲の人々と開発の目処を共有することを目的とする（幅を持たせる）
この２点を踏まえた上で、簡易なグラフを作成することのできる仕組みを作ってみました。（実際の現場ではもう少し複雑なグラフをスプレッドシートで実現しているのですが、今回のブログを書くにあたって少し簡易に作っています。）
このグラフを利用するためには、以下のような形式のCSVを作成します。（CSVの詳細な説明はこちらの説明を参照してください）
スプリント,総SP,ベロシティ 1,120,5 2,120,7 3,120, 4,120, 〜 省略 〜 20,120, 21,120, 22,120,
- 今回はスプリント２２までの予測を出したいと思います
- 実績が出ているスプリント２までのベロシティを設定します
- 総SPはひとまず全行に同じ数値を設定します
このCSVをグラフにしてみます。
グラフは以下のように読み解きます。
- ベロシティの累積は青色の折れ線グラフで表現されています
- 総SPは緑色の折れ線グラフで表現されており、ここまで到達すれば作りたいモノは全て作れたということになります
- 将来の予測はオレンジの誤差有りの折れ線グラフで表現されており、この誤差の範囲で完了することが期待できます
- 見積りがカンペキで安定した開発を継続できればスプリント２０で開発が完了する見込み（こんなことはまずないんですが）
- 見積りよりも実作業量が少なかったらスプリント１４で開発が完了するかもしれない（こうなることもあまりない）
- 見積りが実作業量が多かったらいつ終わるかもよくわからない（こちらになることの方が多い。。。）
ややこしいのは『誤差』の扱い方です。
今回紹介しているグラフ作成の仕組みでは、デフォルトで『60%』を設定しています。これは以下の理由によって設定しています。
- プロダクトは、ユーザーの反応を始めとする新たに明らかになった情報から『何をやるか？』を常にアップデートしなければならないため、事前に精度の高い仕様や要求を洗い出しきることはできない
- 着手の直前にリリースした機能の反応によって、仕様が変わるかもしれない
- 場合によっては、『予定していた機能開発をやらなくなる』ということもあるかもしれない
- スウォーミング（１つの関心事に集中する）しつつ進めることを前提とし、未着手のエピックを全て『初期のプロダクト定義』の状態として扱う
- 『初期のプロダクト定義』は、仕様や要求が定まっていない開発最初期の状態
- 詳細は、『アジャイルな見積りと計画づくり』の [16章 ベロシティの見積り] を参照
- 『アジャイルな見積りと計画づくり』では、『初期のプロダクト定義』の不確実性を 0.6倍 〜 1.6倍 の幅で定義しているのでそれに則って60%とする
- 書籍に則るなら下は誤差40%・上は誤差60%で考えるのが正しいが、見通しが外れて問題になるのは遅れた場合なのでツールを簡易にするために 0.4倍 〜 1.6倍 の幅で誤差を見るようにする
誤差については各プロダクト・チームでの状況や進め方があると思うので、それを踏まえた上で設定する必要があります。
スケジュールの精度を向上させよう
グラフの話に戻ります。
現在の平均ベロシティが６なので、順当にいけばもうすぐ他のエピックに着手できそうです。なので、次に行う作業について考えます。
２番目に着手するエピックについては、最優先で着手するエピックを決定した時と同じように優先順位を見直して決定します。
これにより、次はエピック『掲示板内容を参照する』に取り組むことにしたので、このエピックのストーリーの労力を見積ります。
見積り結果を反映し、今まで『換算によるSP』を採用していた部分を『実際に見積もったSP』に置き換えた結果、以下のようになりました。（赤字部分が変化点）
| エピック | 優先度 | 換算によるSP | 実際に見積ったSP | スケジュールに反映するSP |
|---|---|---|---|---|
| 掲示板を作成する | 4 | 10 | 10 | |
| 掲示板内容を参照する | 2 | 20 | 10 | 10 |
| 掲示板を削除する | 5 | 10 | 10 | |
| 掲示板にメッセージを投稿する | 1 | - | 20 | 20 |
| 掲示板のメッセージを編集する | 3 | 20 | 20 | |
| 掲示板のメッセージを削除する | 6 | 10 | 10 | |
| 掲示板の内容をCSV出力する | 7 | 30 | 30 | |
| 合計 | - | - | - | 110 |
このエピックは最初に予測していた半分の労力で終わりそうなことがわかりました。
この見積り後、スプリント４まで作業を進めました。ベロシティは以下のようになりました。
| スプリント | ベロシティ |
|---|---|
| 1 | 5 |
| 2 | 7 |
| 3 | 6 |
| 4 | 5 |
CSVは以下のようになります。スプリント３中に見積りを行ったので、スプリント３の時点で総SPが減少しています。
スプリント,総SP,ベロシティ 1,120,5 2,120,7 3,110,6 4,110,5 5,110, 〜 省略 〜 20,110, 21,110, 22,110,
この状態で現時点での見通しをグラフにしてみます。
グラフからは以下のことが読み取れます。
- ベロシティは安定して積み上げることができている
- 総SPが下がった結果、開発完了時期が早まった
- これ以降予定している作業の見積りがカンペキで、かつ安定した開発を継続できればスプリント１９で開発が完了する見込みとなり、１スプリント縮まった
スケジュールの見直しをしよう
ここで時間を一気に進めて、スプリント９完了時点の様子を見てみます。
開発を進める中で見積り精度も上げつつ開発を進めてきた結果、SPは以下のようになっています。
| エピック | 優先度 | 換算によるSP | 実際に見積ったSP | スケジュールに反映するSP |
|---|---|---|---|---|
| 掲示板を作成する | 4 | 10 | 5 | 5 |
| 掲示板内容を参照する | 2 | 20 | 10 | 10 |
| 掲示板を削除する | 5 | 10 | 10 | 10 |
| 掲示板にメッセージを投稿する | 1 | - | 20 | 20 |
| 掲示板のメッセージを編集する | 3 | 20 | 30 | 25 |
| 掲示板のメッセージを削除する | 6 | 10 | 10 | 10 |
| 掲示板の内容をCSV出力する | 7 | 30 | 30 | |
| 合計 | - | - | - | 120 |
スプリント９までの実績を踏まえて以下のようなCSVをグラフにしてみたいと思います。
意図的にスプリント７頃からベロシティを向上させています。（FWの使い方がわかってきて、生産性が向上したのかもしれません）
スプリント,総SP,ベロシティ 1,120,5 2,120,7 3,110,6 4,110,5 5,105,4 6,105,6 7,120,8 8,120,11 9,120,9 10,120, 11,120, 12,120, 13,120, 14,120, 15,120, 16,120, 17,120, 18,120, 19,120, 20,120, 21,120, 22,120,
スプリント４の頃と完了目処のスプリントは大きくは変わっていませんが、残作業の減少に伴って誤差の幅が減ってきているのがわかります。
更にスプリントを進めてみます。
スプリント,総SP,ベロシティ 1,120,5 2,120,7 3,110,6 4,110,5 5,105,4 6,105,6 7,120,8 8,120,11 9,120,9 10,120,14 11,120,12 12,120, 13,120, 14,120, 15,120, 16,120, 17,120, 18,120, 19,120, 20,120, 21,120, 22,120,
グラフは以下のようになりました。
このグラフからは以下のことが読み取れます。
- ベロシティが向上したことによって、このままいけばスプリント１５頃に開発が完了する見込みがある
- 残作業が少なくなっており（残SP：約40）、完了までのブレの幅もかなり小さくなっている
仮に残作業の設計を行った結果、予想よりも開発内容が複雑で当初想定工数よりも時間がかかってしまったとしても、ベロシティが安定していれば６スプリント遅れたスプリント２１の頃には完了が見込めそうです。
開発初期は見積りよりも実作業量が多かったらいつ終わるかすらわからない状態でしたが、開発の進行とともに見積り精度をあげつつベロシティを追い続けることで、かなり正確な着地点が見通せるようになりました。
スケジュールの見直しをしよう 〜Another Story〜
先ほどの例では、意図的に開発初期の見積りSPと実際に個別見積りしたSPを同じにしていました。
しかし、システム開発には要求の変化や追加はつきものです。
同様のシステム開発の別シナリオとして、スプリント７からのベロシティの増加を受けて欲張ってしまったPOが、スコープ８の頃から徐々にスコープを増やしてきたとします。スプリントごとに 20SP の作業をスコープに追加したとします。
スプリント,総SP,ベロシティ 1,120,5 2,120,7 3,110,6 4,110,5 5,105,4 6,105,6 7,120,8 8,140,11 9,160,9 10,180,14 11,200,12 12,200, 13,200, 14,200, 15,200, 16,200, 17,200, 18,200, 19,200, 20,200, 21,200, 22,200,
スプリント２２での完了は絶望的な状態となってしまいました。
グラフを見てみると、ベロシティを示す青色の折れ線よりも総SPを示す緑色の折れ線の傾きの方が急であることがわかります。
こうなってくると、どれだけ開発を順調に進めても完了時期は遠ざかる一方です。デスマーチの始まりです。
（POはスプリント１８からちょい遅れぐらいで作業が完了すると思っているかもしれません）
このような場合はPOと会話する必要がありますが、その際にマズい状況になりつつあることの根拠としてこのようなグラフで視覚的に見通しを伝えることができると会話がスムーズになるのではないでしょうか。
見通しを元にスコープを調整する
ここまでで紹介したグラフを用いることで、必要なスコープを実現することに着目した開発終了時期の調整ができるのではないかと思います。
また、リリースしなければならない時期が決まっている場合は、定められた時期に開発を完了させることに着目したスコープの調整をすることもできるようになります。
以下のグラフでは、スプリント１５でリリースするためにどこまで総SPを抑えないといけないのかを示しています。
まとめ
スケジュールは最初に立てて立てっぱなしでは意味がありません。開発の完了時期を周囲の人たちと会話するためのツールとして定期的にアップデートしておく必要があります。
これにより、セールスメンバーの『いつ機能が使えるようになるのか』という関心や、POの『いつ開発リソースが空くのか』という関心に最新の状況で会話することができるようになります。
このブログがアジャイル開発におけるスケジュール作りの参考になれば幸いです。
