はじめてアジャイル開発をする人は、見積りしてほしいと言われた時にお悩みになるのではないでしょうか。
私は悩んでいました（笑）
この記事では、アジャイル開発の見積り時の考え方や依頼元に回答する際の注意事項をなるべく簡単に説明します。
アジャイル開発の見積もりって不安なんですよね……
開発スコープが変化する中でどのように見積りをすればいいの？
とも坊金額や工数、ポイントなど求めらる回答も違うことがあるよね。
依頼元へ回答する際のポイントや注意点を解説するよ！
・アジャイル開発の見積りはどの単位で回答すればよいかわかる
・「ポイント」「工数」「金額」それぞれの算出方法がわかる
・依頼元へ回答する際のポイントや注意点がわかる
アジャイル開発の見積り単位
アジャイル開発のプロダクトバックログの見積りは「ポイント」と呼ばれる単位で見積ります。
では、皆さんが見積り依頼元に求められる単位は何でしょうか。
「工数」や「金額」で回答して欲しいと言われることがほとんどだと思います。
特にウォーターフォール開発の文化が根強い会社では「ポイント」を求められることはまずありません。
また、受託開発の場合も客先からの求められる単位は「工数」や「金額」であることがほとんどだと思います。
いったいどの単位で見積もるのが正解なんでしょうか？
結論：ポイントで見積もろう！
先に結論です。理由はあとから説明します。
[結論]
・アジャイル開発の見積りは「ポイント」で回答する。
・「工数」「金額」で回答する必要がある場合は、スプリントごとに見積りをアップデートする。
ポイントで見積もる理由
アジャイル開発は、プロダクトの取り巻く環境やユーザーからのフィードバックをもとに変化を受け付ける前提のフレームワークです。
開発中の状況に応じてやることが変更になるため、初期要求の段階で見積りの精度を上げたとしても、その見積りのほとんどは役に立たないものになります。
着手しない開発要件に対して、必死に見積もっているわけですから、残念ながら時間のムダです！
開発着手前の見積りの時点では、初期要求を元にざっくりとした粒度でプロダクトバックログを作成し、実際に対応するスクラムチームの開発者がポイントを見積もるようにしましょう。
ポイントの見積り方法
・初期要求のプロダクトバックログ作成後、プランニングポーカーで「ポイント」を見積もる
開発者がポイントを見積もるためには「プロダクトバックログ」が必要です。
プロダクトオーナーはプロダクトバックログを作成するために、初回リリースへ向けた開発スコープを決定しましょう。
以下3つのステップで開発スコープを決定します。
- ペルソナを明確にする
- 提供したい機能や体験（ユーザーストーリー）を洗い出す
- 初回リリース時に提供したい価値（MVP）を決定する
ユーザーストーリーマップを作成し、開発スコープ（MVP）を決定するための具体的な手順は以下の記事で解説しています。
開発スコープ決定後、プロダクトオーナーは「プロダクトバックログ」を作成します。
この時点のプロダクトバックログは見積りに必要な最低限の内容だけ記載があればOKです。
「プロダクトバックログ」に関しては、以下の記事で詳しく解説しています。
プロダクトバックログを元に、開発者は各プロダクトバックログアイテムのポイントを見積ります。
ポイントの見積り手法には「プラニングポーカー」というものがあります。
具体的な手順は以下の記事で解説しています。
それでも「工数」「金額」を求められる場合
「ポイント」で見積もるべきとわかっていても、そうもいかないのが今の日本の現場だと思います（残念）
初期要求の見積りを「工数」や「金額」で求められる場合は、以下の観点でも見積もるようにしましょう。
工数で見積もる方法
・初期要求のプロダクトバックログを元に、実際の開発者が作業工数を見積もる
・スクラムイベントに参加する工数も見積りに含める
・スクラムチームの体制を考慮し、必要な工数を計上する
工数を見積もるためには「ポイント」から、より具体的な「時間」変換する必要があります。
ポイント見積り時に作成したプロダクトバックログを元に、開発者が作業工程を洗い出し、各工程で必要な時間を見積もるようにしましょう。
ただし、初期見積りの時点では十分な情報が集まっていないため、精度が高い見積りをだすことはできません。
不明瞭なことにどれだけ時間を費やしても精度は向上しないので、時間をかけ過ぎないように注意しましょう。
また、他人が見積もった工数ベースで成果をコミットメントできる人は少ないと思います。
実際に開発するメンバーが見積もるように心がけ、営業や管理職が見積りしているようであれば見直しましょう。
先ほど見積もった工数は「プロダクト開発に必要な工数」のみです。
単に開発スコープの完了に必要な工数だけの見積りだけで算出すると必ず予算をオーバーします。
以下3つの観点で考えるようにしましょう。
プロジェクトの前提条件によって異なりますが、プロダクト開発以外に計上するべき工数がないか確認しておきましょう。
（例）
・プロダクトオーナの業務を依頼元ではなく、受託側で委託されている場合。
→委託されているプロダクトオーナーの業務を行うための稼働が含まれているか。
・オフショアアジャイル体制のため翻訳者がチームに必要な場合。
→翻訳者の稼働が漏れていないか。
・既存プロダクトのリファクタリング案件の場合。
→自動化がどこまでされているか。
・スクラムイベントの時間が決まっていない場合。
→開発者のプロダクト開発に充てる稼働が、スクラムイベントの参加を考慮されているか。
金額で見積もる方法
具体的な金額で見積りを出すには、以下の3つのどのパターンか確認し、チーム単価 × 総スプリント数で算出する
・チーム体制が決まっている場合
・開発期間（納期）が決まっている場合
・チーム体制と開発期間（納期）が決まっている場合
チーム体制が決まっている場合
チームの体制が決まっている場合は簡単です。
上図のような体制を想定している場合、1スプリントにかかる費用はチーム単価の合計の750万円です。
このチームが何スプリント実施するかで総額が決まります。
計算しやすいように1スプリント1ヶ月の場合で考えると、初回リリースまでに6スプリントを想定しているチームの開発コスト総額は750万円 × 6スプリント = 4500万円となります。
ちなみに、スプリント数の見込みは「ポイント」や「工数」を利用して算出できます。
・過去プロジェクトのベロシティとポイントからスプリント数を算出
チームの体制が決まっている場合は、別案件を対応していたチームがそのまま今回の案件にアサインされるケースが多いと思います。その場合は、初期要求から見積もったポイントと過去案件で測定したチームのベロシティからスプリント数を算出できます。
・開発者の稼働と見積り工数からスプリント数を算出
開発者がプロダクト開発に充てることができる稼働と初期要求時に見積りしたプロダクト開発に必要な工数からスプリント数を算出できます。
この時、開発者の工数からスクラムイベントに充てる工数を除いた稼働で計算が必要です。
（月に120時間の稼働を想定している場合、スクラムイベントに30時間かかるとするとプロダクト開発に充てる時間は90時間となります。）
過去ベロシティや初期要求の工数を利用して見積もる場合は見積り精度は低いです。
スプリント中も初期見積りをアップデートする作業を忘れないようにしよう！
開発期間（納期）が決まっている場合
これまでウォーターフォール一筋だった会社で、はじめてアジャイル開発をやろうとすると上記パターンに出くわす可能性があると思います。
上図のように開発期間が固定の場合、プロダクト開発に充てる稼働を増やす必要があるため、チーム体制を変更（開発者の増員）をする必要があります。
その時は以下の順番で初期見積りをしましょう。
・現在のチームのベロシティを確認する
・必要なベロシティを算出する（初期要求に対するポイント / スプリント数）
・不足しているベロシティをカバーするために必要な体制を検討する
・開発コスト総額 = 必要な体制を満たすチーム単価 × スプリント数
（例）
・初期要求30ptのプロダクトバックログを4スプリントで実施する場合
開発者4名で20ptのベロシティであれば、追加で2名増員が必要
どうしてもこのような状況になってしまうこともあるかもしれませんが、これは邪道です！
アジャイル開発は、チームを継続的に維持することによって、チームの文化や規律や技術力を向上させ、生産性を高めていく手法です。
そのため、開発者を増員すればその分チームのベロシティが比例して向上する訳ではなく、この場合の見積もりはあってないようなものです。
開発者を増員するというよりは初回リリースのスコープを調整する方向にシフトしましょう。
最終的な費用は、スプリントを繰り返す中でアップデートし、精度をあげていく旨を必ず共有してください。
・スプリント開始時の体制のまま、初回リリースとする開発スコープを調整するようにしましょう。
・開発期間が6ヶ月以上ある場合は、1,2スプリント実施した時点で増員を検討するのはありです。
チーム体制と開発期間（納期）が決まっている場合
プロジェクトによっては、チーム体制と初回リリースのターゲット（納期）や開発期間が決まっている場合があります。
正直これは絶望です（笑）
「時間」「予算」「品質」「スコープ」のうち、時間と予算が固定ということです。
品質を落とすのは考えられないため、「スコープを調整する」しかありません。
また、開発着手時に、依頼元と「トレードオフ・スライダー」を作成し、初回リリースへ向けてどんな観点を優先するかしっかりと合意しておきましょう！
トレードオフ・スライダーの作成方法は、以下の記事で解説しています。
見積り回答時の注意事項
見積りが完成して安心してはいけません。
相手に見積り内容を正しく理解してもらうまでが見積りです。
どこかで聞いたことがあるフレーズ…（笑）
・見積もり金額がひとり歩きしてしまう。
・初期要求から要求がどんどん肥大化する。
・開発着手後に依頼元が無関心。スクラムイベントに参加してくれない。
依頼元と見積り回答に対して認識合わせができていないと、金額がひとり歩きしてしまい、結果的に予算が柔軟に調整できなかったり、要求が肥大化していつまで立ってもMVPが確定せずリリースできないと行ったことに陥ります。
見積り金額のことだけにはなっていないですが、回答時に以下観点を伝えるようにしましょう。
【依頼元に必ず伝えること】
・見積りはあくまで見積り。スプリントを繰り返すことで精度が上がっていく。
・リリース計画や最終的なコストの見込みはスプリントレビューで共有する。
・リファインメントやスプリントレビューで追加要望や変更を受けつける。
・MVPやプロダクトバックログの優先度は柔軟に対応するがトレードオフが基本。
・トレードオフの判断ができるように、事前にトレードオフスライダーの作成、内容の合意が必要。
アジャイル開発では、依頼元もステークホルダーとして、スクラムイベントに巻きこんで行くことが大切です。
そのためには、依頼元が知りたい情報がスクラムイベントで共有されることを理解してもらう必要があります。
「スプリントレビューでスケジュール進捗や開発コストの見込み、リリース時期が知れるんだ！」
と依頼元に思ってもらえるように、見積り回答時に情報が常にアップデートされていくことを伝えましょう。
見積りをアップデートしよう！
アジャイル開発の初期要求の見積りはあくまで見積りです。
スプリントを繰り返すことで、チームのベロシティが安定し、初回リリースへ向けたMVPも正確になっていくため、見積りをアップデートすることが非常に大切です。
例えば、MVP達成まで4スプリント、1スプリントあたり750万円かかる場合の初期見積りは以下です。
初期見積り時の金額 = 1スプリントあたりのチーム単価 × スプリント数
3000万円 = 750万円 × 4スプリント ※上図の左表
初期見積りの予算3000万円で開発着手したとします。しかしながら、スプリント1のベロシティは想定よりも1pt少ない4ptでした。
ここでプロダクトオーナーは、以下のように見積りをアップデートします。
見積りのアップデート後の金額 = 1スプリントあたりのチーム単価 × スプリント数
3750万円 = 750万円 × 5スプリント ※上図の右表
スプリント1はほとんどのチームが低いベロシティでスタートするため、この時点で初期見積り時のトレンドラインを下回っていても慌てる必要はありませんが、スプリントレビューなどで依頼元に状況をしっかりと共有しておきましょう。
依頼元へのアップデート後の見積りを共有
スプリント1の見積り：3000万〜3750万
スプリントを繰り返すごとに見積りをアップデートします。プロダクトオーナーがMVPのトレンドラインを管理することが理想ですが、手が回らない場合はスクラムマスターに相談して集計などを手伝ってもらいましょう。
スプリントを繰り返す度に見積り精度が向上
スプリント2の金額予想：3000万〜3375万
スプリント3の金額予想：3000万
このように、スプリントを重ねるごとにチームのベロシティは安定し、実績ベースの見積りになるため精度が向上します。また、同時にMVPがいつ頃リリースできるかの指標にもなるため、リリース計画にも非常に有効です。
コメント