ソフトウェア見積もりの 9 原則
見積書の重要性
ソフトウェア開発における見積もりは常に難しい課題です。なぜなら、ソフトウェア開発には多くの不確実性が含まれ、プロジェクトごとに異なる要素が存在するからです。完璧に見積もることは非常に難しい（あるいはほぼ不可能）かもしれませんが、正確性を向上させる努力は必要です。この記事では、私の経験と深い研究に基づくソフトウェア見積もりの原則を説明します。これらの実践的な原則を適用することで、プロジェクトの見積もりが大幅に向上することを保証します。
見積もりはなぜ重要なのか？ まず最初に、「なぜ」です。見積もりはなぜ重要なのでしょうか？なぜ顧客や経営者、営業担当者、その他のステークホルダーはいつも「どれくらいかかるのか？」や「いつ終わるのか？」と尋ねるのでしょうか？それに基づいて彼らはどのような行動をとるのでしょうか？その答えはビジネスの意思決定にあります。見積もりの究極の目的はビジネスの意思決定をサポートすることです。見積もりは時間とコストに直接影響し、これらはビジネスパーソンが常に気にしている要素であり、投資に対する収益（Return on Investment、ROI）をどれだけ計測できるかを示します。見積もりの目的はリスクの削減や速度の向上、品質の確保ではなく、意思決定をサポートすることなのです。多くの人がソフトウェア開発を行っていると誤解していることがありますが、実際に彼らが行っているのはビジネスなのです。
アジャイルでは、ビジネスを代表し意思決定に責任を持つプロダクトオーナーが、スコープ、リソース、時間の3つの要素に基づいて決定を行います。見積もりは時間に関連しており、プロダクトオーナーはこれらの要素のバランスを監視し、何を開発すべきか、いつ開発すべきかを判断します。例えば、タスクが1日か1年かで、プロダクトオーナーの決定は異なるでしょう。タスクが1日しかかからないと見積もられていれば、即座に取り組むことを決定するかもしれません。一方で、見積もりが1年かかる場合、プロダクトオーナーはそれをキャンセルまたは延期するかもしれません。見積もりはプロダクトオーナーの意思決定に大きな影響を与えるのです。
アジャイルとウォーターフォールの意思決定アプローチは異なります。アジャイルでは、リソースと時間が固定され、一方でスコープは柔軟です。アジャイルは迅速かつ反復的なデリバリーを目指しており、プロダクトオーナーは限られた時間とリソースでどのように製品価値を最大化するかを考えます。もし見積が目標時間内に完了するにはあまりにも大きすぎる場合、スコープは優先順位付けを行って縮小されるべきです。
一方で、ウォーターフォールではスコープが固定され、リソースと時間が柔軟です。アジャイルのプロダクトオーナーと同じ役割を果たす意思決定者は、すべてのスコープを完了するためにどれだけのリソースと時間が必要かを考えます。プロダクトオーナーは必要な人的リソースを確保し、スコープのサイズと見積もりに基づいて計画を立てます。
上記の意思決定アプローチはよく知られた理論ではありますが、ビジネスの状況によっては固定と柔軟な要因が変動することがあります。たとえば、アジャイルでは、ステークホルダーがデリバリー時間を延期して全スコープを完了するよう要求した場合、時間が延びることがあります。ウォーターフォールでは、お客様の予算が限られ、ソフトウェア開発のコストが期待を上回る場合、スコープが縮小されることがあります。これらの基本的なアプローチを心に留めながらも、状況に応じて意思決定を調整する必要があります。
原則１：要件を明確にする
最初の原則は、要件を明確にすることです。推定と開発段階の関係を調査した「不確実性の円錐」は、明確な要件が推定の精度を最も向上させることを示しています。言い換えれば、要件がより明確であればあるほど、推定がより正確になります。
以下の図は、推定の変動（不正確さ）が時間とともにどのように狭まるかを示しています。垂直線が推定の変動を、水平線が時間（開発段階）を表しています。ご覧の通り、初期の概念、承認された製品定義、要件完了、およびユーザーインターフェース完了に従って、推定の変動が著しく狭まります。円錐の大幅な狭まりは、総時間の20%から30%の最初の段階で推定の変動を2倍から4倍に減少させます。もし推定をどこから始めれば良いかわからない場合は、要件をできるだけ明確に定義することから始めてみてください。これは明らかなことのように思えるかもしれませんが、多くのプロジェクトでこのステップが見落とされてしまうことがよくあります。
原則２：完了の意味を定義する
プロジェクトにおける第二の原則は、完了の定義（DoD, Definition of Done）として知られる、完了の意味を定義することです。DoDは、完成したPBI（プロダクトバックログアイテム、チケット、イシュー、またはタスクとも呼ばれる）と未完成のPBIを区別し、出力品質の向上に寄与します。見積もりの最も一般的な落とし穴の一つは、品質保証プロセスの見落としであり、これはしばしば見積もりの過小評価につながります。顧客満足を達成するためには、製品は一定の品質でなければならず、品質保証プロセスはDoDとして定義されるべきです。品質保証ステップを加えることで、開発者はタスク完了により多くの時間が必要であることを認識し、見積もりの過小評価を防ぐことができます。以下に例をいくつか挙げます。
ユニットテストは作成され、カバレッジは80％を超える必要があります。 コードレビューは2人のソフトウェアエンジニアによって実施されなければなりません。 品質チェックはテスターによって行われる必要があります。 機能はプロダクトオーナーにデモンストレーションされ、フィードバックと最終承認を得る必要があります。 DoDはアジャイルのベストプラクティスとして定義されていますが、プロジェクト管理のタイプに関わらず大きな利点をもたらすため、ウォーターフォール方式にも使用される（または使用されるべき）です。そして、DoDはプロジェクトに基づいて大きく異なります。
原則３：完璧を目指さない
第三の原則は、完璧を目指さないことです。これは、見積もりが単なる最善の推測であり、何があっても開発チームが必ず満たさなければならない期限ではないことを意味します。ソフトウェア開発における見積もりは難しいものです。なぜなら、プロジェクトはどれも同じではないからです。「不確実性の円錐」の著者であるスティーブ・マコネルは、どのプロジェクトも要件、人々、ビジネスコンテキスト、技術、制約が同じではないと言っています。したがって、すべてのプロジェクトには大きな不確実性と予測不可能性が含まれ、見積もりを困難にします。
完璧な見積もりを目指すのではなく、時間をかけてより正確な見積もりを目指すことが必要です。これは、改善（カイゼン）または継続的な改善と呼ばれます。開発の終わりに、ソフトウェアエンジニアは実際にかかった時間を振り返り、見積もりと実際の時間の差を確認し、経験を共有し、次の開発に活かします。アジャイル（スクラム）では、スプリントレトロスペクティブが経験を共有する最適なタイミングであり、スプリントごとに見積もりが改善されます。もしソフトウェアエンジニアが複雑なバグに悩まされて予想以上に時間がかかった場合、プロダクトオーナーはそれをどう解決したかを共有し、他のソフトウェアエンジニアが同じバグでつまずかないようにします。特に、ボトルネックは共有されるべきです。なぜなら、それは見積もりの精度を大幅に向上させるからです。
完璧を避けるもう一つのヒントは範囲見積もりです。正確な見積もりを出すのではなく、最小と最大を見積もります。例えば、あるタスクは最小3日、最大5日と見積もられるでしょう。範囲はプロジェクトによって異なり、プロダクトオーナーやビジネス関係者と交渉されるべきです。見積もりが彼らの意思決定に役立つ限り、範囲の大きさは問題ありません。3点見積もりも、最悪のケース、最良のケース、最も可能性が高いケースの3点で見積もる技術であり、同じコンセプトです。
原則４：集合知の活用
第四の原則は、集合知を活用することです。これは、グループとして見積もることを意味します。この背後にある考えは、複数の人々による見積もりは、一人で行う見積もりよりも正確になるというものです。なぜなら、それによって見落としを防ぐことができるからです。一人の人間の見積もりに頼ることは見落としに繋がりやすいので、複数の人々が見積もることでこれを防ぎ、正確さを向上させます。
「スリーアミーゴス」は、アジャイルにおける最良の実践の一つであり、ビジネス担当者、テスター、ソフトウェアエンジニアという3人の主要な人物で要件をレビューします。これにより、集合知が効果的になります。ビジネス担当者はドメインの専門家としての洞察をもたらし、ソフトウェアエンジニアは技術的な観点からチェックし、テスターは品質を確保する方法をレビューします。以前に述べたように、要件の品質と明確さは重要であり、見積もりの正確さに最も大きな影響を与えます。
デルファイ法も、集合知を使用する別の見積もり技術です。専門家のグループが情報を交換し、合意に達するまで何度も議論を行います。デルファイ法も、1950年代の導入以来広く使用されており、グループによる見積もりが個々の努力よりも優れていることを示しています。
原則５：ストーリーポイント見積もりなし
第五の原則は、ストーリーポイントによる見積もりを行わないことです。ストーリーポイントはアジャイルにおける最良の実践であるかのように広く言及されていますが、いくつかの重要な欠点があります。最大の欠点は、ストーリーポイントがビジネスの意思決定を助けることが決してないということです。これは見積もりの究極の目的です。私たちはソフトウェア開発を行う前にビジネスを行っています。したがって、ビジネスで共通して使用され、ビジネスの意思決定を支援する指標を使用する必要があります。たとえあなたがこのタスクの見積もりが15ポイントであると言っても、ビジネス関係者はそれをどう扱えばいいかわからず、最終的には「いつ完成しますか？」または「完成までどれくらいかかりますか？」と尋ねます。ソフトウェア開発は発明や研究開発ではなく、ビジネスです。プロジェクトのタイプに関係なく、BtoBであれBtoCであれ、ROIを気にする投資家やスポンサーは常にいます。
第二の欠点は、ビジネスにとって速度は全く重要ではないということです。私が最初に速度の概念について学んだとき、私は感銘を受けました。しかし、さらに考えると、開発速度の意味について熟考し始めました。例えば、ビジネスの速度やビジネスを行う速度について誰かが話しているのを聞いたことがありません。「今月のビジネス速度は500ポイントだった」と言って喜ぶ人はいません。同様に、誰もソフトウェア開発の速度を気にし、今月のソフトウェア開発速度が1000ポイントだったと聞いて喜ぶことはありません。本当に重要なのは締め切りとタスクが完了したかどうかです。再び言いますが、ソフトウェア開発はビジネスです。
ストーリーポイントの代わりに、時間、日数、週などのビジネスで共通して使用される指標を使用する必要があります。これらは職業、国などに関わらずビジネスで使用されます。プロジェクトによって指標は異なりますが、ビジネスの意思決定に役立つ限り問題ありません。
原則６：大まかな見積もりが機能する
原則6は、大まかな見積もりが有効であるということです。ほとんどの場合、ビジネス関係者はアイデアを出した際や要件を定義する前に、あなたに大まかな見積もりを求めます。あなたが取るべき正しい行動は、それが大まかな見積もりであり、変更される可能性が高いことを強調しながら、大まかな見積もりを提示することです。これはビジネスの意思決定に役立ち、見積もりが修正されても誰も怒りません。
タクシーに乗って運転手が「どれくらい時間がかかるかわからない」と言うか、「30分から1時間かかります」と言う場面を想像してください。前者は全く役に立ちませんが、後者はタクシーを諦めて電車に乗ることを決断するのに役立つかもしれません。これが、ほとんどのライドシェアリングサービスが目的地までの大まかな所要時間を表示する理由です。それは非常に正確ではなく、多くの不確実性（天気、イベント、事故など）のために交通の予測が困難ですが。
例外は、あなたが下請け業者として働いていて、クライアントから支払いを受けていない場合です。見積もりは重要な情報であり、多大な努力を要するため、多くの人が潜在的なクライアントを装ってそれを引き出そうとします。そのような場合、見積もりを交渉の切り札として使用し、それを提示するかどうか、いつ提示するかを慎重に考えるべきです。ソフトウェアの下請け会社で働いていたとき、多くの人や会社が「見積もりだけ教えてください」と尋ねてきましたが、支払いを受けたことはありませんでした。
原則７：縮小する
小さいタスクは、見積もりをより簡単かつ正確にすることができます。アジャイルのベストプラクティスの一つは、タスク（ユーザーストーリー）をスプリント内で完了できるほど小さくすることです。スプリントは通常1週間または2週間であり、1ヶ月以上にはなりません。これは、タスクが大きくなるとソフトウェアの複雑さが線形ではなく指数関数的に増加するためです。たとえば、来週何ができるかを見積もることは、来年何ができるかを見積もることよりもはるかに簡単です。タスクが小さいほど、見積もりは正確になります。プロジェクトのタスクが大きすぎると感じた場合、それらは数週間で完了できるより小さなタスクに分割されるべきです。この実践はウォーターフォールプロジェクトにも適用できます。
加えて、小さいタスクは見積もりの正確性だけでなく、品質も向上させます。小規模な開発、テスト、リリースはデバッグを容易にし、影響を受ける領域を特定するのを容易にします。大きなタスクは、ソフトウェアの複雑さを指数関数的に増加させるため、バグの温床になりがちです。
小さいタスクを採用することで、開発プロセス全体がより管理しやすくなります。各タスクが小さいため、問題が発生した場合に特定の部分を迅速に特定し、修正することが可能になります。これは、特にバグの発見と対処において重要です。大規模なタスクでは、複数のコンポーネントや機能が絡み合っているため、問題の原因を特定するのが難しくなります。しかし、小さなタスクでは、それぞれの機能や部分が独立しているため、問題の原因をより迅速に特定しやすくなります。
さらに、小規模なタスクは、進捗のモニタリングと調整を容易にします。プロジェクトの各段階での成果物が小さいため、プロジェクト全体の進行状況をより頻繁に、そして正確に把握することができます。これにより、必要に応じて迅速に調整を行い、プロジェクトの遅延を避けることが可能になります。また、チームメンバーがタスクに対する責任をより明確に理解し、効率的に作業を進めることができます。
最終的に、小規模なタスクは、リリース後の品質保証にも貢献します。リリースされる機能が小さいほど、それに関連する問題を発見し、対処するのが容易になります。これにより、製品全体の品質と安定性が向上し、最終的なユーザー体験に肯定的な影響を与えることになります。
原則8：独立性を確保する
独立したタスクは見積もりの正確性を向上させます。依存関係はソフトウェアプロジェクトにおける最大の課題の一つであり、特定が困難でプログラミングの複雑さを増加させます。独立したタスクは複雑さが少なく、見積もりの正確性に寄与します。
見積もりとタスク管理の文脈において、独立したタスクとは、他のタスクに取り組んだり待ったりせずに完了し、リリースすることができるタスクを意味します。ソフトウェアプロジェクトの性質上、全ての依存関係を排除することは不可能ですが、できる限りタスクを他から分離する努力をしなければなりません。
依存関係は要件定義が進むにつれて明確になります。しかし、要件定義後でもまだ確信が持てない場合、ドメインモデリングが役立ちます。エリック・エヴァンスによるドメイン駆動設計の一部として作られたドメインモデリングは、ビジネスの観点からオブジェクトが互いにどのように関連しているかを示し、依存関係を明確にします。これは非常に効果的であり、スケールドアジャイルフレームワーク（SAFe）は「アジャイルで一つだけモデル化するなら、ドメインをモデル化する」と述べています。
原則9：スパイクを行う
スパイクはアジャイルの実践の一つで、元々はエクストリームプログラミング（XP）の実践として作られました。スパイクは、見積もり、実現可能性、その他のリスクや不確実性に関する小規模で期限を設けた調査を行います。十分な情報がない場合は、スパイクを実施する必要があります。
スパイクにはビジネスと技術の2種類があります。ビジネススパイクは要件を明確にするために行います。以前述べたように、明確な要件は見積もりの正確性を最も向上させます。したがって、要件について確信が持てない場合は、ビジネススパイクでそれを明確にする必要があります。技術スパイクは技術に関する調査です。新しい技術を使用する場合は、リスクを減らし実現可能性を確認するためにスパイクを行う必要があります。XPは「新しい技術を使用する固定時間プロジェクトによるリスク」を指摘しています。情報が多ければ多いほど、見積もりは正確になります。
スパイクは単一の目標を持ち、期限を設ける必要があります。スパイクを行う際は、明確にしたい目標を設定し、長引かせないように期限を設ける必要があります。
結論
見積もりの主な目的は、ビジネス関係者がビジネスの意思決定を行うことを支援することです。ビジネス関係者は、範囲、資源、時間の三つの要因に基づいて何をし、いつ行うかを決定しますが、見積もりは時間に関連します。完了にかかる時間によって、彼らの意思決定は大きく異なります。
第一の原則は、要件を明確にすることです。開発段階と見積もりの正確性の関係を示す「不確実性の円錐」の研究によると、明確な要件が見積もりの正確性を最も改善します。
第二の原則は、チーム内で完了の意味を定義することであり、これは「完了の定義（DoD）」と呼ばれます。DoDは、完成したPBIと未完成のPBIを区別し、出力品質を向上させ、過小評価を防止します。
第三の原則は、完璧を避け、時間をかけて見積もりの正確性を向上させることです。見積もりは最善の推測に過ぎず、期限ではないため、状況が変化した場合には交渉を通じて調整するべきです。範囲見積もりや3点見積もりは、範囲を使って見積もりを行い、完璧を避けつつもビジネス関係者の意思決定を支援します。
第四の原則は、集合知を活用することです。これは、単独でなくグループで見積もりを行うというアイデアです。これにより、見落としを防ぐため、グループによる見積もりは単独で行うよりも正確です。3人のアミーゴス：ビジネス関係者、ソフトウェアエンジニア、テスターは、要件をレビューし、見積もりの正確性を向上させるためのベストプラクティスです。
第五の原則は、ストーリーポイント見積もりは行わないことです。ストーリーポイントはアジャイルのベストプラクティスであるかのように広く言及されていますが、意思決定に役立たないため避けるべきです。ビジネス関係者は、ビジネスにおいて一般的な計測単位ではないストーリーポイントで決定を行いません。
第六の原則は、大まかな見積もりが機能することです。ほとんどの場合、ビジネス関係者はアイデアを持っていて、詳細な要件が定義される前に大まかな見積もりを求めます。その場合は、それが彼らに役立つので大まかな見積もりを出すことができます。ただし、下請け会社で働いていて、クライアントがまだ支払っていない場合は、見積もりが貴重な情報であるため、多くの人が支払いなしでそれを引き出そうと試みることを考慮する必要があります。
第七の原則は、それを小さくすることです。大きなタスクはソフトウェアの複雑さを増し、バグの温床となり得ます。小さいタスクは見積もりの正確性を増します。また、影響を受ける領域を特定しやすく、デバッグを行いやすくするため、ソフトウェアの品質も向上します。
第八の原則は、それを独立させることです。依存関係はソフトウェアプロジェクトの最大の課題の一つであり、ソフトウェアの複雑さを増加させます。タスクが独立していれば、それを見積もることははるかに簡単です。通常、要件が明確になればなるほど、依存関係はより露見します。必要に応じて、ドメイン駆動設計の技術の一つであるドメインモデリングを使用できます。
第九の原則は、スパイクを行うことです。スパイクは、ビジネスと技術に関する短期間で期限を設けた調査を行うアジャイル技術です。スパイクにはビジネスと技術の2種類があります。ビジネススパイクは要件に関する情報を調査し収集し、技術スパイクは技術に関するリスクを減らし、実現可能性をチェックするための調査です。十分な情報がない場合はスパイクを行うべきです。