モバイルプロジェクトの見積もり — 概要とタスク評価の手法

見積もりとは？

見積もり（英語のestimateから — 評価）とは、タスクを完了するために必要な時間や工数の予測です。モバイル開発では、見積もりは時間、日数、ストーリーポイント、または金額で表現されます。見積もりの目的は正確な予測ではなく、意思決定のための不確実性を減らすことです。

見積もりとコミットメントの違い

見積もりは誤差の範囲を含む予測です。コミットメントは特定の日付までにタスクを完了するという約束です。この違いは重要です。見積もりは「おそらく5日」と言い、コミットメントは「5日でやります」と言います。マネージャーはこれらの概念を混同し、見積もりを誤差の許されない締め切りに変えてしまうことがよくあります。

コミュニケーションツールとしての見積もり

見積もりのプロセスは、その結果と同じくらい重要です。チームがタスクの見積もりについて議論するとき、隠れた要件、依存関係、リスクが明らかになります。最終的な数字が不正確でも、議論によってすべての参加者がタスクを理解できます。そのため、集団での見積もり手法（Planning Poker）は個人での見積もりよりも効果的です。

開発における見積もり手法

プロジェクトの段階や詳細レベルに応じて、いくつかの見積もり手法があります。手法の選択は、利用可能なデータと必要な精度に依存します。

Planning Poker

Planning Pokerは、Agileで最も人気のある見積もり手法です。各開発者はフィボナッチ数列（1、2、3、5、8、13、21）のカードを受け取ります。タスクについて議論した後、全員が同時にカードを提示します。見積もりが異なる場合、最小値と最大値の開発者が自分の理由を説明し、再投票が行われます。この手法は権威バイアスを排除し、より正確な見積もりを提供します。

T-Shirt sizing

T-Shirt sizingは、Tシャツのサイズ（XS、S、M、L、XL、XXL）による大まかな見積もりです。この手法は、詳細が不明な初期段階で大規模タスク（エピック）を迅速に見積もるために使用されます。その後、各タスクは分解され、Planning Pokerで見積もられます。T-Shirt sizingはタスクあたり5〜10分かかりますが、規模の概算のみを提供します。

三点見積もり（PERT）

PERTは、楽観値（O）、悲観値（P）、最有可能値（M）の3つの見積もりを使用します。最終見積もりは式（O + 4M + P）/ 6で計算されます。この手法は不確実性を考慮し、単一の見積もりよりも現実的な結果をもたらします。PERTは特にリスクの高いタスクや新しい技術に役立ちます。

見積もりの精度：期待と現実

見積もりの精度は、プロジェクトの段階と既知の情報量に依存します。見積もりが早期に行われるほど、誤差の範囲は大きくなります — これは正常であり、計画に組み込む必要があります。

不確実性のコーン

不確実性のコーン（Cone of Uncertainty）は、プロジェクトの進行に伴って見積もり誤差がどのように減少するかを示すモデルです。概念段階では誤差範囲は400%（タスクに1〜4ヶ月かかる可能性）です。スプリント段階では20%（1〜1.2ヶ月）になります。このモデルを理解することで、初期段階で正確な見積もりを要求しないようにできます。

精度に影響する要因

• タスクの複雑さ — 新しい技術か既知の技術か？未知のものは誤差範囲を2〜3倍に増やします。
• タスクのサイズ — 小さなタスク（2日以内）は大きなタスクよりも正確に見積もられます。分解により精度が向上します。
• チームの経験 — 6ヶ月以上一緒に働いているチームは、新しいチームより30〜50%正確に見積もります。
• 過去のデータ — ベロシティメトリクスとサイクロメトリーのデータがあれば、予測精度が向上します。

相対見積もり vs 絶対見積もり

相対見積もり（ストーリーポイント）は、絶対見積もり（時間）よりも正確です。なぜなら、人は時間を見積もるよりもタスクを比較する方が得意だからです。「このタスクはあのタスクの2倍複雑だ」という判断は、「このタスクは8時間かかる」よりも信頼性が高いです。相対見積もりは特定の開発者に依存せず、担当者が変わっても精度を維持します。

見積もり精度を向上させる方法：ベストプラクティス

見積もりの精度は、体系的なアプローチ、集団での議論、過去のミスの分析によって向上できます。いくつかの実証済みのプラクティスがあります。

1〜2日への分解

2日以上と見積もられたタスクは、サブタスクに分解する必要があります。原則：タスクを50%以上の精度で見積もれない場合、それは大きすぎます。理解可能で見積もり可能なステップに分割します。分解後、合計見積もりは初期見積もりの1.5〜2倍になることがよくあります。

過去のデータとメトリクス

見積もりの履歴を保持し、実際の工数と比較します。例：「3ストーリーポイントと見積もられたタスクは、平均4日かかり、2日ではない」。予測にはチームのベロシティを使用します：チームがスプリントあたり20ストーリーポイントを完了する場合、30を計画しないでください。過去の見積もり精度の分析は、見積もりスキルを向上させる最良の訓練です。

アンカリングとキャリブレーション

アンカリングは、最初に発言された見積もりがすべての参加者に影響を与える心理的効果です。Planning Pokerでアンカリングを避けるには、順番ではなく全員が同時にカードを提示します。キャリブレーションは、見積もりと実際の結果を定期的に比較することです：10〜20スプリント後、チームはフィードバックを通じてより正確に見積もることを学びます。

リスク調整済み見積もり

すべてのタスクには隠れたリスクがあります：開発者の病気、APIの問題、要件の変更。見積もりにリスク調整係数を追加します：高リスクタスクには1.5〜2の乗数、低リスクタスクには1.1〜1.2。どのリスクが考慮され、それらがスケジュールにどう影響するかをクライアントに透過的に示します。

見積もりにおけるよくある間違い

見積もりの誤りは、成熟度に関係なくほとんどのチームで繰り返されます。これらの誤りを知ることが、修正への第一歩です。

楽観バイアス

最も一般的な誤りは、最良のシナリオで見積もることです：「すべてが完璧に進めば、3日でできる」。現実には、何も完璧には進みません：バグ、要件に関する質問、依存タスク。解決策：楽観的ではなく、最も可能性の高いシナリオで見積もります。変動性を考慮するためにPERTを使用します。

プレッシャー下での見積もり

マネージャーが「金曜日までに必要だ」と言うと、開発者は無意識に見積もりをその締め切りに合わせます。プレッシャー下での見積もりは常に過小評価され、期限切れにつながります。解決策：見積もりは締め切りに先行すべきであり、その逆ではありません。まずチームが見積もり、次に関係者がスケジュールに合意します。

複雑さと時間の混同

タスクの複雑さ（考える量）と時間（行う量）は異なるメトリクスです。タスクはシンプルだが時間がかかる場合（10画面の構築）や、複雑だが迅速な場合（レガシーコードのバグ発見）があります。ストーリーポイントは通常複雑さを見積もり、時間はチームのベロシティから導き出されます。

コンテキストスイッチの無視

開発者は一つのタスクに8時間連続で取り組むわけではありません。ミーティング、コードレビュー、同僚の支援、管理業務が労働時間の30〜50%を消費します。コンテキストスイッチは見積もりに考慮されるべきです：実際、開発者は1日に3〜4時間しかコードを書きません。