ストーリーポイント見積りって難しくない？

ストーリーポイントの見積りは難しいと思います。ストーリーポイントが難しいと言うよりは、見積りが難しいのですが。たくさんのチームでストーリーポイントを使ってきての感想ですが、コミュニケーションの道具としてはものすごくよくできています。一方、将来を正確に予測するという点では、割とダメな道具ではないかという気がしています。

見積もること、つまり将来を予測するというのは難しいので、ストーリーポイントを道具として使ったところで難しさは変わらないということだとは思います。いくつか思い当たる理由を挙げてみます。

当事者が(当事者ですら)作業を予測できない

チームがストーリーポイントで見積もるメリットのひとつが、一番よくわかっているはずの当事者が、自分たちの作業を見積もるという点です。しかし、既存コードがスパゲッティで変更量が予想できなかったり、スキル不足で作業内容が想像できなかったり、着手してから仕様が変わったり増えたりしてしまう。予想が外れまくったり、そもそも予想できなかったりします。

内部品質が低い

前の項目とも関係しますが、変更や追加をするとき、既存のコードベースがひどいせいで、予想が困難になる場合があります。コピー＆ペーストが横行していて、同じ変更を何十箇所も適用しないといけない。1箇所変えたら他の箇所が壊れ、直すとまた他の部分に問題が起き、先が見えず延々と終わらない。アーキテクチャの一貫性がなく、変更を定型化できない。自動テストがなくて動作確認をものすごく慎重にやらざるをえない。

見積もる対象が大きすぎる

チームで数日かかるような大きい機能/ユーザーストーリー/PBIは、予想からのブレ幅も大きくなりがちです。スプリントで完成するPBIが3つとかだと、1つ外せばベロシティの変動は30%以上になります。(ひとつひとつが数時間で終わるとか、1人/1ペアで1日程度とか、1スプリントで10個以上あるとか、大きさは小さく数を多くすると安定しやすくなります。)

過去の実績を軽視する

ポイントで見積もるというのがとても直感的なのがわざわいして、大きそうだから5、もっと大きいから8か13、という感覚的な数字になってしまいがちです(このクセを直すのは非常に苦労します)。過去に完成した機能やPBIの実績を生かさないと、正確な見積りには近づきません。

ベロシティの業務量

スプリントで完成したポイントを合計して、ベロシティを算出します。このベロシティは簡単なようで、意外と考えたり可視化するのに手間がかかります。スプリント中に休みなどで時間が増減したときの調整、割り込み作業などの注釈、PBIやタスクの性質による分類や分析、過去のトレンドの発見など。ツールで自動計算するとこのへんの直感が失われてしまいます。さらにチームがその結果を踏まえて、以降のスプリントの見積りに生かせるよう、解釈して議論する時間も必要です。このへんの手間を省いてしまうと将来の予測に使うのが難しくなります。

チームの妨害

チームへの割り込みなどがスプリント中に発生すると、作業時間が変動します。そうするとプランニング通りには進まなくなり、調整にさらに時間を取られたりして、完成できる量が変わります。ベロシティの算出は面倒になりますし、将来的にも割り込みが起き続けるのであれば将来の予測自体が難しくなる(変動幅が大きくなって収束しない)ということにもなります。

じゃあなんでストーリーポイントを使うのか

スクラムでストーリーポイントを使って(使わなくても)見積りをする意義は、ひとつはコミュニケーションやPBIの理解のため。これはとても有用です。

もうひとつの将来予測のため、これはなかなか難しく、自分たちの予想と実績をきちんとふりかえりながら「見積もり精度を高める」という具体的な目標を持って、自分たち自身を修正し改善していくという気持ちがいるなあと考えています。改善する道具のひとつとしてストーリーポイントを使うのはまあいいと思いますが、他の道具も必要になります。

そんな改善を積み重ねて、いわゆる「ベロシティが安定する」状態になって初めて、いくつか先のスプリントを予測できるようになります。それって「ストーリーポイントで予測できるようになった」って言っていいんですかね。ここまで来ていれば、別にストーリーポイントじゃなくてもいいような気がします。

代わりに使えるもの

現状が安定していないときでも将来予測に使える道具はあるんでしょうか。知りたいです。結局は『ソフトウェア見積り 人月の暗黙知を解き明かす』に帰着するのかな……？