無謀な締め切りに追われたくない人のためのアジャイル開発の見積もり

「アジャイル開発をやってはいるけど初期見積もり前提のスケジュールになってて、これは本当にアジャイル開発なのか」「アジャイル開発での見積もりって結局なんなんだ」

こんなふうに思ったことはないだろうか。

実は、筆者は以前に参加したアジャイル開発プロジェクトでこういった経験をした。あるあるかもしれないが、エンジニアが出す初期見積もりが確定期日になってしまっていたのだ。「ざっくりでいいからこれ見積もってくれないですか？」と言われて、本当にざっくりと見積もっただけなのにである。

この記事では、そういった悩みを抱える方に向けて、アジャイル開発における見積もりのやり方を紹介する。

この記事がアジャイル開発の見積もりについての正しい知識を広める一助になり、より多くの開発者が見積もりで悩むことがなくなってくれると幸いだ。

それではさっそく見ていこう。

１　アジャイル開発の見積もりで知っておくべき３つのこと

この章では、アジャイル開発の見積もりについてまず必ず押さえておきたい以下の３つの前提を紹介する。
・見積もりは完了予測であり、コミットメントではない
・アジャイル開発でもプロジェクト全体の見積もりをするべき
・社内で共有認識を持つ

１−１　見積もりはタスクの完了する確率であり、コミットメントではない

まず一番大切なのが、見積もりとは対象の作業がその期間内に完了する確率のことであって、その期日までに終わらせるというコミットメントではないという点だ。なぜなら、見積もりは必ずブレるからだ。

これはプロジェクト全体に対する見積もりと、プロジェクト内部の個別の案件に対する見積もりの双方にいうことができる。

プロジェクト全体に対しては、やるべきこと（What）もその実現方法（How）も初期の段階では不確実性がかなり大きい。例えば、プロジェクトの後半になって必要な要件が追加されることだってある。また、技術的な実現方法に関しても実際にやってみないとわからないことは大いにあるはずだ。

プロジェクト内の個別案件に関しても同様のことが言える。事前に要件を詰めきれていない可能性だってあるし、他の案件との兼ね合いで開発自体がかなり複雑になる場合もあり得る。

例えば、とあるプロフィール管理システムを作っていた時の話だ。サービスの概要としては、プロダクトの開発を発注していただいた広告代理店が、自社で取引実績のある人材のプロフィールをデータベースとして管理し、広告出稿をする企業に自由に閲覧してもらえる様にするというものだった。

そのため、ざっくりとサービス利用の流れをいうと、タレントなどのプロフィールを広告代理店の社内の人が作成し、広告出稿をする企業がタレントの情報をネットから自由に閲覧できるというものだ。

また、このプロジェクトでは素早くサービスを立ち上げることを前提にしていたため、新しい技術スタックを利用していた。特に、DBにはAirtableというスプレッドシート感覚で使えるDBを採用していた。

そこで、プロフィールの作成フォームを作っていた時の話だ。そのフォームからはプロフィール画像を登録できる想定があった。しかし、開発を進めていくうちに当時使っていたAirtableというDBでは、画像を直接登録できないことがわかった。また、Airtableが提供しているライブラリを利用して画像を登録するとなぜかプログラムのビルドエラーが発生することも実装中にわかった。

そのため、対応方針を都度変更しつつ最適な方法を探りながら案件を終わらせた。そのため、当初の工数見積もりよりも実際は工数が多くかかってしまったということがあった。

こういった開発を実際に進めてみないとわからない不確実性が発生するのが開発プロジェクトである。そのため、見積もりはコミットメントではないことを理解しておくことが重要だ。

１−２　アジャイル開発でもプロジェクト全体の見積もりをするべき

アジャイル開発でもプロジェクト全体の見積もりをするべきだ。

前の章では、見積もりはブレるからコミットメントとして扱ってはいけないと説明した。しかし、だからといって見積もりに意味がないと勘違いし、全く見積もりをしないのはよくない。

見積もりを全くしないとプロジェクト全体のスケジュールが引けないだけでなく、単体の案件（ユーザーストーリー）の開発に要するコストもわからないため案件間での開発優先度もつけられないからだ。

１−３　プロジェクト内で「見積もりは確率である」と共有認識を持つ

プロジェクト内で、発注者やビジネス側の担当者も含めて、見積もりは確定期日ではないという認識を常にすり合わせておくことが重要だ。

その共通認識を醸成するためにも、重要なのが見積もりの報告の仕方だ。

まずはよくない例から見てみよう。
・「１１月３０日にリリースできそうです」

これだとあたかも正確な見積もりができていて、この日付が確定値であると捉えられてしまう可能性が高い。

そうではなく、時期には幅を持たせて報告するのが良い。これであれば、「日付は確定していない目安」として伝えられる確率が高まる。例えば以下の様になる。
・「現状想定されているプロジェクト規模とチームのパフォーマンスから考えると、プロジェクトは５〜６ヶ月かかりそうです」

２　アジャイル開発の見積りのルール２つ

この章では、アジャイル開発の見積もりをする際の要点を以下の２つ紹介する。
・相対サイズで算出すること
・単位に意味を持たせないこと

２−１　相対サイズで算出すること

アジャイル開発においては、見積もりは相対サイズで行う。これによって見積もりの負荷が格段に下げられる。

例えば以下の３つのストーリーがあるとする。「求職者側の登録」の開発に必要なサイズを「３」とした時に、それぞれの相対的なサイズを見積もってみよう。

反対に、今度は先ほどのユーザーストーリーの絶対的なサイズを見積もってみてほしい。

….

どうだっただろうか。

前者の方が全ての工数を算出するのが圧倒的に楽だったことが実感できたのではないだろうか。

２−２　単位に意味を持たせないこと

アジャイル開発の見積もりにおいてはあえて単位に意味を持たせないことがおすすめだ。そのため、工数見積もりの単位には「ポイント（ストーリーポイント）」を使うことが一般的だ。

なぜなら意味を持った単位をつけてしまうと、実工数とのブレが発生した時に、全ての見積もりを再計算し直す手間が必要になるからだ。

反対に、意味のない単位を使っていれば再計算の必要はない。

たとえば、工数見積もりを以下の通りしていたとする。

ユーザーストーリー	見積もり（日）
求職者側の登録	３
企業側の登録	３
企業が求める求職者を見つけられる	９
企業が求職者をスカウトできる	１５

「求職者側の登録」の実装が完了して、実工数としては５日かかったとする。見積もりの３日が実際は５日だったのだから、それに応じて他の見積もりも再度算出した方が良さそうだ。そうなると、以下の様な工数が再度算出されることになる。

ユーザーストーリー	見積もり（日）	実工数（日）
求職者側の登録	３	５
企業側の登録	３→５
企業が求める求職者を見つけられる	９→１５
企業が求職者をスカウトできる	１５→２５