アジャイルな見積もりと計画づくり

アジャイルな見積もりと計画づくりを読んだので，特に見積もりの方法についてまとめようと思います．

見積もりと計画づくりの目的

そもそも見積もりと計画づくりを行う目的は何なのでしょうか？それはこのソフトウェアがユーザに届ける価値の探究をする為です．その時点で最も価値が高い機能を届けるために，リソースを配分し，フィーチャのスコープを考えスケジュールを検討する．なので見積もりはこれに使える数値であればいいのです．正確にリリースの時期を予測する必要はなく，これらの意思決定を支えるレベルの見積もりを早く出すことが大切なのです．以下でお話させて頂くのはこの前提の元早く意思決定に使えるレベルの見積もりをどうやって出すかを記しています．

規模を見積もる

本書はアジャイル開発におけるユーザーストーリーの規模に対して見積りをすることを推奨しています．そして規模を見積もったあとに，ベロシティ（1イテレーションにおける消化したストーリーポイントの合計）を使うことで開発完了する期間を推定します．まさに距離と速度でかかる時間を導出するのと同じです．ここでいう規模とは必要な作業，開発内容の複雑さ，リスクを総合的に判断したものです．そしてこの規模をストーリーポイントと呼びます．

相対的に見積もる

ストーリーポイントは相対ポイントとしてつけます．ある基準のストーリーに対して，ある別のストーリーの規模は何倍かを考えてポイントをつけます．はじめの1つ目のストーリーは一番小さそうなストーリーを1ポイントにするか，真ん中ぐらいの規模のストーリーを想定するポイント幅の中央値にする方法があります．

なぜこのように見積もるのか？

1つ目の理由が長持ちするからです．あるストーリーが完了する作業時間というのは，使用する技術，経験によって変化します．例えばJavaの経験が浅いプログラマーがJavaを使って実装をすると時間がかかってしまいます．一方で慣れてくると同程度の規模のアプリケーションをもっと早く実装できるようになるでしょう．このように作業時間が変化するので，見積もりとしての賞味期限が短くなってしまうのです．

2つ目の理由が早く見積もれるからです．作業時間で見積もろうとすると具体的にどんな実装をするかを話してしまいがちです．相対的な規模で見積もることで，作業を想像することなく早く見積もることができます．見積もりは時間をかけてもどうせ不確実なもので，かつ意思決定を支えられればいいので時間をかけるのは勿体ないです．

3つ目の理由が属人化を防ぐことができるからです．作業時間で見積もるときはある人を想定して見積もることになります．なぜなら作業する人によって作業時間の見積もりが異なるからです．そうすると実際の作業もその人がやると決まってしまいます．規模の見積もりは人には関係ないのでこういったことを防ぐことができます．

4つ目の理由は相対的に見積もる方が正しく見積もれるからです．作業時間を絶対的に見積った場合は，作業時間と実際にかかった時間にかなりの差が現れたようです．しかしそのズレには一貫性があるようでした（アートオブアジャイルデベロップメントより）．つまりある一定分ずれるといったことおきます．なので相対的に見積もるとうまくいくのです．相対的に見積もることの効果は普段の業務でも感じます．しっかりと規模に対して一貫性を持って相対的につけると，１週間あたりのポイントの消化分はほぼブレずに見積もれます．

見積もりの技法

この見積もりを行う際のコツについてもいくつか書かれたいので紹介します．

チームで見積もる

見積もりは，その作業を行う人が見積もるのが一番正確だと言われています．アジャイル開発においてはチームで仕事をするので，チームで見積もるのが一番正確なのです．また各人の思い込みを，他の人が指摘することで修正することができます．

プランニングポーカー

見積もりをする際のプロセスとしてプランニングポーカーという方法があります．大体以下のように行います． 1. チームで集まる 2. あるストーリーに対して各々が思うポイントをつけ，カードを出し合う 3. なぜそのポイントをつけたかを説明し，合意したポイントをそのストーリーにつける

プランニングポーカーで用いるカードの数字はフィボナッチ数列を扱うことが多いです．フィボナッチ数列は「0, 1, ,2 ,3 ,5 ...」という1つ前と2つ前を足した数でなる数列で，後ろに行くほど数字の振れ幅が大きくなります．実際の作業でも仕様の規模が大きくなればなるほど、作業工数の振り幅は大きくなっていきます．この性質とフィボナッチ数の性質がマッチしているのでフィボナッチ数を使っています． プランニングポーカーをやる際の注意でとしては，時間をかけすぎないことです．そもそも見積もりはどうやっても正確でにできないので時間をかけるとコスパに見合わなくなります．また僕の感覚的には，話し合いに時間がかかる時はストーリーのDoneの定義や，仕様上に認識のズレ，前提条件がうまく共有されていないことが多いです．まずはこちらの認識を合わせるかこのストーリーの見積もりを飛ばして，Doneの定義，仕様などを確認してからもう一度見積もり直すのがいいと思います．

ストーリーの分割

ストーリーを見積もる際にあまりに大きすぎるストーリーは見積もりの精度が低くなってしまいます．本書による人は10倍のものまでうまく見積もれるそうです．つまりストーリーポイントの最小単位が1ポイントならば，その10倍の規模の10ポイントのストーリーまではうまく見積もれるということです．なので大きすぎるなと思った際はストーリーを分割することを考えて見てください．また分割することで見積もりの精度というメリット以外にも，早くユーザーに価値が届く機能をリリースできたり，そのフィードバックを受けてのピボットがしやすくなります．以下の記事で分割については少しまとめているので良かったら参照してください． https://oboe-note.hatenablog.com/entry/2020/08/31/211001

ストーリーの結合

ストーリーを分割しすぎると逆に，精度が悪くなると言ったことも発生してしまいます．あるストーリーAをストーリー1〜4に分割して見積もるとします．それぞれのポイントが2~5ポイントだとすると，ストーリーAは最小で8ポイント，最大で20ポイントをつけることとなります．これらの数字はストーリーAとして考えた時おそらく違和感を感じてしまいます．なので分割しておかしいな？と思ったらまとめて，見積もり直してください．僕も仕事で見積もりをする上で，分割をしてポイントつけて合計を考えたときに，違和感を感じまとめて見積もり直して見たりします．