はじめに
私は以前、ウォーターフォールな開発現場でPLとして仕事をしていました。
会社の先人たちの見積もりを参考に、見様見真似で見積もりをしてみました。しかし、結果としてプロジェクトは炎上して残業漬けでどうにかこうにか納めるという経験をしました。
現在、アジャイルな開発現場に転職しました。
アジャイルな開発現場で働き始めて、もっと早く知っておきたかったと思う見積もりの考え方に出会いました。
この記事は、ウォーターフォールな開発現場からアジャイルな開発現場に転職した筆者が、ウォーターフォールな開発しか知らなかった自分に見積もり方法のアドバイスをするとしたら、というテーマで書いています。
読み進めていきながら「それはウォーターフォール開発もちゃんとできてないだけだ」みたいなツッコミを入れたくなる箇所があるかもしれませんが、私の実体験を元に書いていますので、ご愛嬌ということで生暖かく見守ってくれると嬉しいです。
似たような環境の方にも参考になるかもです。
これまでの見積もり方法と弊害
- 画面ごとに見積もりを行う
- 予期せぬ課題や仕様漏れにより開発工数が伸びる
- 画面単位に開発を進めていくため、1画面全ての開発が終わらないとリリースが難しい
- 人日や人月という単位で見積もりを行う
- 人によってスキルが違うため、人日や人月で見積もりを行っても期日通りに進まない
- PMやPLの立場の人が一人で見積もりを行う
- 抜けもれが発生する
- 見積もりする人の経験など、一人の主観によって見積もりが左右される
どうやって解決する？
- ユーザーストーリーで見積もりを行う
- ストーリーポイントで見積もりを行う
- チームで見積もりを行う
一つずつ詳しく見ていきます。
解決策① ユーザーストーリーで見積もりを行う
そもそもユーザーストーリーって何？
ユーザーストーリーとは、ユーザーに価値を届けられる(=機能) 単位で記述されたものです。
例えば、ショッピングサイトの開発をするとします。
画面単位で見積もりをする場合、
- 商品一覧画面
- カート画面
- 購入画面
それぞれの画面単位で見積もりをしていきます。
一方、ユーザーストーリー単位で見積もりをする場合、
- ユーザーは、商品の一覧を見ることができる
- ユーザーは、商品名で商品を検索することができる
- ユーザーは、商品をカートに追加することができる
- ユーザーは、カートの中の商品一覧を見ることができる
ユーザーのアクション(=ユーザー価値を届けられる)単位に記述をしていきます。
ユーザーストーリーで見積もるメリット
大きく3つのメリットがあります。
1. 画面単位より粒度が細かいため、見積もりの精度が上がる
例えば、同じCRUDがある画面でも、ビジネスロジックの複雑度、データの複雑度、項目数などで見積もりが変わります。
画面単位で見積もりをしてしまうと、上記の要素を鑑みつつも、勘で見積もってしまいがち(少なくとも自分はそうだった)。
ビジネスロジックを分解してシンプルなストーリー複数に分けたり、表示する項目ごとにストーリーを分けるなどして、より細かく正確に見積もれます。1
2. リリース速度が上がる
ユーザーストーリーではユーザーに価値を届けられる単位に分解していくため、例えば「複数表示項目があるうちの1項目だけを出した状態」という小さい単位でのリリースが可能となります。
リリースだけにとどまらず、Gitへのコミットなども小さい単位で行えるようになります。
3. 進捗のトラッキングがより正確になる
画面単位で開発者に作業を振っていった場合、開発者が仕様漏れや仕様勘違いをして後戻りをするというケースがあります(実際に何度も悩まされた)。
ストーリーという価値を届ける単位で開発を進めるため、仕様漏れ等が起きにくくなります。
画面単位で開発者に作業を振っていった場合、開発者の「現在の進捗はxx%です」という言葉を安易に信じて痛い目に遭うことがあります(よく遭った)。
CRUDのある1画面という単位で開発を振って、n日というスケジュールの振り方だと、開発者の感覚によって進捗率が提示されるということがしばしば。
ストーリーという単位で進捗が見える化すると、進捗率をもう少し測りやすくなります。
解決策② ストーリーポイントで見積もりを行う
そもそもストーリーポイントって何？
ストーリーポイントとは、ユーザーストーリーの規模を表したものです。
規模のわかりやすい例は、ドリンクのサイズです。
レストランやカフェなどでドリンクを注文するとき、我々はS、M、Lというサイズで注文すると思います。
S、M、Lというサイズは規模を表しています。
お店によってSの量は200mlだったり、250mlだったりしますが、我々はS、M、Lというサイズを良く使います。
これが規模です。
人月(人日)とストーリーポイントって何が違うのか？
人月(人日)の特徴
人月の問題点は、「時間の見積もり」と「規模の見積もり」を同時にしてしまっていることです。
時間の見積もりとは、何ヶ月(何日)かかるのかということです。1人月の開発であれば、2人いれば2週間程度ということになります(めちゃくちゃ当たり前ですが...)。
規模の見積もりとは、開発規模がどれくらいかということです。2人月の開発は1人月の開発の2倍の規模ということになります(これもめちゃくちゃ当たり前ですね...)。
では、なぜ「時間の見積もり」と「規模の見積もり」が共存することが問題なのでしょうか。
答えはシンプルで、開発する人によってかかる時間が異なるからです。
例えば、「Java+Springでユーザーのログイン機能を作る」というタスクがあるとき、
- Java+Springを触ったことがある人
- Javaは触ったことあるが、Springは初めての人
- Javaを始めとして静的型付け言語を触ったことがない人
の3人では、かかる時間は大幅に変わるでしょう。
しかし、人月で見積もる場合は、「どれくらいの人日(=時間)で終わるか」を決め打つ必要があります。
見積者にJava+Springの経験があり、その感覚で見積もった場合、実際に作業するのが
Javaを始めとして静的型付け言語を触ったことがない人
だと、見積の何倍もの時間がかかるかもしれません。
ストーリーポイントの特徴
一方、ストーリーポイントでは「規模の見積もり」のみを行います。
規模の見積もりをする際には、相対的な量の大きさのみをつけていきます。
山手線を例に考えてみます。2
東京駅から上野駅(4駅)を基準として、ポイントを1とします。
そうすると、
- 東京駅から池袋駅(12駅)は、3ポイント
- 東京駅から渋谷駅(11駅)は、3ポイント
- 池袋駅から新宿駅(4駅)は、1ポイント
となります。
規模の見積をする上で重要なのは、
- 厳密すぎなくてOK
- 厳密に考えると、東京駅から上野駅(4駅)が1ポイントなら、東京駅から渋谷駅(11駅)は2.75ポイントとなります
- しかし、2.75も3も殆ど変わらないため、同じとみなして、わかりやすく3をつけます
- 時間の見積とは切り離す
- 東京駅から上野駅(4駅)の所要時間は7分に対して、 池袋駅から新宿駅(4駅)の所要時間は9分であり、時間の違いがある
- しかし、規模(今回の場合は、駅数が規模になる)に着目して、時間のことは考えないため、同じポイント数になります
ストーリーポイントを使うと、規模の見積もりのみができるのはわかったけど、かかる時間はどうやって見積もるの？と思われた方もいるかもしれません。
時間のトラッキングにはベロシティという概念が出てきます。
ベロシティは簡単に言うと、一定期間の中で何ポイントのストーリーポイントを消化できるかという指標です。
例えば、1週間で10ポイントを消化できるなら、全体で80ポイントの開発を終わらせるのに2ヶ月かかるということになります。
ストーリーポイントで見積もるメリット
「時間の見積もり」と「規模の見積もり」を分けられることに尽きます。
繰り返しになりますが、同じ機能開発を行うにしても、開発者によってかかる時間が異なります。
見積者が「自分なら、この画面を作るのに3人月かかる」と思っても、違う人が開発すれば開発が長引いてしまって、スケジュールに支障をきたすということが容易に起こりえます。
ストーリーポイントで規模のみを見積もることで、そのような問題に立ち向かうことができます。
解決策③ チームで見積もりを行う
そもそも何で1人で見積もっていたんだっけ？
私の場合は、
- PLという立場の人間が見積もりを行うのが当然(という思い込み)
- 細かな仕様まで把握しているのが自分だけで、自分以外の人では見積が難しい(という思い込み)
が原因です。
チームで見積もるメリット
当たり前ですが、複数の視点を交えて見積もりを行えば、
- ストーリーや仕様の抜けもれが減る
- どんなに優秀な人でも1人でやる限り、抜けもれはどうやっても発生してしまいます
- 見積が平準化される
- 1人の場合、その人の経験や勘によってズレが生じてしまう可能性があります
チームで見積もりってどうやってやるの？
小規模な開発であれば、チームメンバー全員で見積もりを行えば良いと思います。
中規模以上の開発で、チームメンバー全員がすべての機能を把握して、すべての見積もりをするのが現実的に難しいというケースもあると思います。
そういった場合は、ある程度の機能のまとまり等で、チームを分割して見積もれば、チームでの見積もりが現実的なものとなります。
おわりに
私自身、ウォーターフォール開発での見積もりで苦労し、炎上を経験しました。
アジャイルな開発を体験してみて、以前経験した問題のいくつかは解決できると感じました(もちろん、完璧に実践できている訳では無いので新しい問題にもぶつかっていますが...)。
ウォーターフォールな開発しかしたことがなく、いきなり何もかもをアジャイルに変えていくというのは難しいというのは、とても理解ができます。
しかし、その中でも、アジャイルなやり方を少しずつ取り入れていくことで、プロジェクト管理や開発がもっと楽になるのでは？という思いで記事を書いてみました。
今回の記事の中では、実践方法について深く言及できていないので、アジャイルな見積もり方に興味を持った方は、是非、下記の参考文献を見てみてください。
参考文献
- 本
- 記事
-
とりあえず画面単位の見積もりを細かくしようというところだけ目指すなら、第一歩としてはユーザーストーリー化しなくてもいいのでは？と思いました。 ↩