ストーリーポイントという儀式を、そろそろやめませんか
ここ何件か立て続けに「アジャイルで開発しています」「スクラムによる開発をしています」という現場に入ったのですが、毎回出てくるのがストーリーポイントです。
タスクを見て、
「これは3ですかね」 「5じゃないですか？」 「じゃあプランニングポーカーやりましょう」
となる。
数字が割れたら理由を話して、またカードを出して、最終的に5になったり8になったりする。
やるたびに思うのですが、これ本当に必要なんでしょうか？
エンジニアが何人も集まって30分〜1時間くらい見積もりをしている。もちろんその時間にも人件費はかかっています。だったら、その時間で仕様を確認したり、設計したり、コードを書いたりしたほうがよくないですか?
以下、ストーリーポイントは本当に無駄なのでやめましょうという話を書きます。
相対見積もりって本当に成立しますか？
ストーリーポイントの説明ではよく、
「時間ではなく、相対的な大きさを見積もります」
と言われます。
基準となるタスクを1ポイントにして、それと比べて2倍くらいなら2、もっと大きければ3や5、と付けていく。
理屈としては分かりますが、その1ポイントは誰にとっての1ポイントなんでしょうか？
プロジェクトには様々な人が参加しています。ある人なら30分で終わる作業が、別の人なら調査込みで半日かかることは普通にあります。
ストーリーポイントは担当者ごとの作業時間そのものを表すものではなく、作業量や複雑さ、不確実性を相対的に表すものだ、と説明されますが、その「複雑さ」や「不確実性」をどう感じるかは人によって違います。
既存コードをよく知っている人なら不確実性は小さく見えるし、初めて触る人なら大きく見える。ある技術に詳しい人には簡単に見える仕事が、そうでない人には難しく見える。
つまり、ストーリーポイントは長さや重さのように測定できるものではなく、結局のところ、その場にいる人たちが主観的に決める数字です。
その数字、本当に合意できますか？
たとえば、一人が3を出して、別の人が8を出したとします。
3を出した人が間違っていて、8を出した人が正しいわけではありません。
3の人には3だと思う理由があるし、8の人には8だと思う理由がある。
そこで話し合って、
「じゃあ5で」
となったとしても、作業量が客観的に5になったわけではないし、不確実だった部分が数字を決めたことで消えるわけでもない。単に、3と8という二つの主観を5という数字に丸めただけです。
もちろん、3と8に分かれた理由を聞いたら有益な話が出てくることはあります。
「そのAPIにはこういう制約があります」 「そこは既存コードを使えます」 「そのケースは考えていませんでした」みたいな話です。
でも、それなら最初からその話をすればいいと思うんです。
「何か実装上のリスクありますか」 「分からないところありますか」 「この仕様で抜けているところありますか」と聞けばいい。
3とか8とかいう数字を一度挟まないとできない会話ではありません。
そして、仮に最終的に「このタスクは5ポイントです」と合意できたとして、 その合意した数字を、結局何に使うのでしょうか？
単にタスク同士の大きさを比較したいだけなら、3、5、8といった精密そうな数字まで決める必要はありません。「これは小さい」「これはかなり大きい」くらいの判断でも目的は果たせます。
一方、スプリントにどれだけ仕事を入れられるか、あるいはプロジェクトがいつ終わりそうかを判断するために使うのであれば、最終的には「このポイント数なら、だいたいこれくらいの期間で終わる」という話になります。
すると、ストーリーポイントは「時間ではなく相対的な大きさを見積もる」と言いながら、実際の運用では時間との対応関係が必要になってきます。
1ポイントが何時間か分かるなら、最初から時間でよくないですか？
現場によっては、
「1ポイントはだいたい半日」
みたいな話が普通に出てきます。
それならもう時間でよくないですか。
3ポイントなら1日半くらいで、5ポイントなら2〜3日くらい。それを最初からそう言えばいいだけです。一度ポイントに変換して、それをまた時間に戻す意味がよく分かりません。
これを言うと、
「ストーリーポイントを時間に換算するのは間違いです」
と言われることがあります。
もし本当に時間と無関係だとしたら、平均ベロシティが1スプリント30ポイントで、残りが90ポイントだから、あと3スプリントくらい。こういう話が出てくること自体がおかしいです。
これも結局、 30ポイント ≒ 1スプリントという時間との対応を使っています。
1ポイント何時間、と直接換算していないだけで、やっていることはポイントから期間への換算です。時間と関係がないなら、ポイントを使って完了時期を考えることもできないはずです。
なので、ここで最初の疑問に戻ってきます。ストーリーポイントという単位を間にはさむ必要は本当にありますか？
じゃあ時間で見積もればよいのでしょうか？
ここまで書くと、「じゃあ時間見積もりをすればいいという話か」と思われそうですが、そういうことでもありません。
私はそもそも、個々のタスクを細かく見積もること自体にどれだけ意味があるのか疑問を持っています。
「これは4時間」 「これは1日」 「これは5ポイント」
と事前に数字を付けても、実際にやってみたら全然違った、ということは珍しくありません。
- 既存コードを触ったら思っていたよりひどかった。
- 使う予定だったライブラリに制約があった。
- 外部APIが変な挙動をした。
- 仕様に矛盾があった。
逆に、難しいと思っていたものが既存実装を少しいじるだけで終わった。
そんなことはいくらでもあります。
全部最初から分かっているなら、そもそも開発はそんなに難しくありません。
やってみないと分からないことがあるから難しいわけです。
その、まだ分かっていないものに対して、
「何時間です」 「何ポイントです」
と数字を付けたところで、未来が分かるようになるわけではありません。
過去は分かる。でも未来は分からない
「先週タスクが10件終わった」
これは分かります。
でも、
「来週もタスクが10件終わる」
は分かりません。
考えれば当たり前の話なのですが、どういうわけか開発現場では後者にもかなり正確な数字を求められます。
さらに困るのが、見積もりがいつの間にか約束になることです。
「3日くらいだと思います」
と言ったら、数日後には、
「3日で終わると言いましたよね」
になっている。
「予測が外れた」だけなのに、「約束を守れなかった」ことになっている。
こういうことが重なると、結局は残業して帳尻を合わせる、みたいな話にもなっていきます。
では、見積もりをしないでどう管理するのか
ここまで書くと、
「じゃあ見積もりをしないで、どうやってプロジェクトを管理するんだ？」
という疑問が出てくると思います。
納期はある。
予算もある。
必要な機能もある。
そうした制約の中で、何を作るかを決める必要はあります。
ただ、そのために未来を正確に言い当てる必要があるのか？という話です。
必要なのは状況が変わったときに何を動かすのかを決めることです。
そこで出てくるのが、予算・納期・スコープのトライアングルです。
見積もりを管理するのではなくトライアングルを調整する
プロジェクトには、
- 予算
- 納期
- スコープ
のトライアングルがあります。
仕事なので期限があります。予算もあるし、営業やマーケティングの都合もあります。
だから「いつできますか」と聞きたくなるのも分かります。
でも、予算・納期・スコープのすべてを好きなように固定することはできません。
納期を絶対に動かせないなら、予算かスコープを動かす必要があります。
予算も増やせないなら、スコープを削るしかありません。
逆に、どうしても全部の機能を入れなければならないのであれば、納期か予算を増やすしかありません。
これはストーリーポイントをどれだけ精密に付けても変わらない話です。
そこで必要なのは、見積もりの精度をさらに上げることではなく、
「では、この機能は今回なくてもいい」 「ここは次のリリースに回そう」 「この要件はもっと単純にできないか」
と判断することです。
途中で想定外の問題が出たら、その時点でもう一度トライアングルを調整する。
- 納期を動かせないなら、スコープを減らす
- スコープを減らせないなら、納期を延ばす
- 予算を増やせるなら、外部サービスを使う、自動化する、人員を増やす
何を固定して、何を動かすのかを決める。
結局、プロジェクト管理で必要なのはこちらだと思います。未来を正確にいい当てることではありません。
見積もりを作って、「この計画なら全部入ります」と安心することでもありません。
分からないことが出てきたときに、
予算、納期、スコープのどれを動かすのかを判断することです。
未来に不確実性がある以上、この調整は避けられません。
だったら、最初から未来をいい当てようとするより、変化が起きることを前提にして、その都度トライアングルを調整するほうが現実的だと思います。
どうしてもプロジェクトがいつ終わるのかを正確に知りたいなら、エンジニアではなく占い師か超能力者を雇ってください。
ブラック企業にはかなり便利そう
ここまでとは少し別の話ですが、ストーリーポイントにはもう一つ嫌なところがあります。
それは、見積もりのために作った数字が、そのまま人の評価や圧力に使えてしまうことです。
「今スプリントは何ポイントやった」 「前よりベロシティが落ちた」 「Aさんは何ポイントやった」
こういう使い方です。
もともとは主観的に決めた数字なのに、いったん合意された途端に客観的な生産性指標のような顔をし始める。
昨日までは、
「これは3ですかね」 「いや5じゃないですか」
と相談して決めていた数字なのに、翌日からは、
「今週は20ポイントあります」 「前回は30ポイントできています」 「今回はベロシティが落ちています」
という管理の数字になる。
しかもプランニングポーカーをしていれば、
「でも、このポイントはチームで合意しましたよね」
という圧力にも使えます。
問題なのは、主観的な見積もりのために作った数字を、あとから客観的な生産性指標として扱ってしまうことです。
もちろん、ストーリーポイントを使っている会社が全部そうだと言っているわけではありませんが、人を安く買い叩きたい組織にとってはかなり使いやすい仕組みだと思います。
ストーリーポイントを作った本人も「やめたほうがいい」と言っている
もう一つ余談ですが、この話について面白い記事があります。
Ron Jeffries氏の「Story Points Revisited」です。
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Jeffries氏はXPの初期から関わっていた人物で、本人いわく、ストーリーポイントという名前を付けたのは自分だったかもしれないそうです。そして「もし自分がストーリーポイントを発明したのだとしたら、今では申し訳なく思っている」と述べています。
興味深いのは、ストーリーポイントがもともと「Ideal Days」という時間ベースの見積もりを「points」と呼び替えたところから始まった、という話です。つまり、「ストーリーポイントは時間とは関係のないまったく別の尺度として生まれた」というわけではありません。
さらにJeffries氏が問題視しているのは、
- ポイントから「いつ全部終わるのか」を予測すること
- 見積もりと実績を比較して、見積もり精度を上げようとすること
- チーム同士のベロシティを比較すること
などです。
Jeffries氏は、可能なら見積もりそのものを避けて、仕事を小さくし、価値の高いものから素早く届けることを勧めています。
「全部いつ終わるんですか？」という問いについても、答えはかなりシンプルで、
誰にも分からない と言っています。
だから「全部作るといつ終わるか」を当てるより、「この日に出すなら、何を入れるか」を考える。
これは、さきほどの予算・納期・スコープの話ともそのままつながります。
記事の最後では、ストーリーポイントがチームや会社に大きな価値をもたらしていないのであれば、無駄として捨てることを勧めています。
もっとシンプルに仕事をすればいいと思う
最初に未来を細かく数値化する。
その数字を確定した計画として扱う。
実際がそこから外れたら「遅れ」とみなす。
これを「アジャイルな開発」と呼ぶのは、私にはかなり違和感があります。
アジャイルソフトウェア開発宣言には、
「計画に従うことよりも変化への対応を」
とあります。
さらに、その背後にある原則では、価値のあるソフトウェアを早く継続的に提供すること、動くソフトウェアを短い間隔でリリースすること、そして動くソフトウェアを進捗の主な尺度とすることが掲げられています。
それなのに、ストーリーポイントを付け、ベロシティを測り、その数字からスプリントごとの完了タスクを割り出して、その計画通りに進むことを求める。
そこまで来ると、「計画に従うことよりも変化への対応を」というアジャイル宣言から、ずいぶん離れてしまっているように思います。