アジャイル開発の見積もり、これで良いのか？と悩んでいるあなたへ
「アジャイル開発のベストプラクティスに従ってるはずなのに、見積もりがなんかおかしい」と感じる方は多いのではないでしょうか。私もその一人でしたが、様々な経験を積んできた今、私なりのベストプラクティスを見つけることができました。
この記事では、アジャイル開発の基礎を振り返り、私が経験した落とし穴とその対策に焦点を当てて共有したいと思います。今回は特に、タスクの管理方法に注目します。プロジェクトのスコープや技術選定、実行計画については別の機会に解説します。
私の経験については興味がある方はこちらを読んでみてください。
アジャイル開発の概要
プロジェクトの見積もりは、長期的な計画に不可欠です。しかし、ソフトウェアプロジェクトは複雑であり、計画の変更が頻繁に起こるため、見積もりは常に課題となっています。この課題に対処するため、ソフトウェアコミュニティはアジャイル開発の理念とそのベストプラクティスを考案しました。
アジャイル開発のマニフェストには次のように記されています。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
これらの理念を具体的なプロジェクト管理手法であるスクラムやXPが支えています。ここではそれぞれの違いには触れず、タスク管理に共通するベストプラクティスを以下に示します。
２週間程度の期間（スプリント）で計画と実行を繰り返す。
やることのリストをツール上でタスクとして管理する。
各タスクに重要度を割り当てる。
各タスクを日数、ポイント、S/M/L等の単位で見積もる。
過去のデータを元にチームの仕事速度（ベロシティ）を計算する。
タスクリストとベロシティを基に、今スプリントのタスクを決定する。
しかし、これらのベストプラクティスとプロジェクト単位での見積もりにはギャップがあります。複数スプリントにわたるプロジェクト全体の見積もりは複雑であり、業界標準の手法は確立されていません。この点で多くの人が悩んでいると思います。また、これらのベストプラクティス自体にもいくつかの落とし穴が存在します。
私が経験した落とし穴
見積もりに違和感を感じるが何もできない
見積もりに対する違和感は、以下のような状況で生じることがあります。例えば、あるプロジェクトの総タスクコストが100であり、スプリント毎のベロシティが20であるとします。この場合、一見するとプロジェクトは5スプリントで完了するはずです。しかし、実際には何かが違うように感じられることがあります。
この違和感の原因は、次の3つの主要な要因によって引き起こされると考えます。
タスクリストの不安定さ：プロジェクトが進むにつれて、新しいタスクが追加されたり、一部のタスクが不要になったりすることがよくあります。たとえば、仕様の変更、バグ修正、またはリファクタリングが含まれます。しかし、うまく実行計画が立てられていれば、この不安定さはプロジェクトの経過とともに収束していきます。
各タスクの見積もりの不安定さ：タスクの見積もりと実際の実行速度との間には、さまざまな要因によるズレが生じることがよくあります。これらの要因には、スコープや実装方針の誤解、実行者のスキルやモチベーション、過去のタスクの経験、依存関係の遅延などが含まれます。結果、見積もり方法への議論が度々生じて見積もり手法に変更が加えられますが、根本的にこれらの次元のことなる要素全てを単一の見積もり値で表現することはできません。
ベロシティの不安定さ：ベロシティは、スプリントごとにチームがタスクをどれだけ消化できるかを示す指標です。しかし、タスクの見積もり方法の変更、チームメンバーの増減、オンコール対応、タスクの並列実行、進行中のタスクの扱い等により、安定したベロシティを保つのは困難です。
これらの要素をもとに計算される見積もりが信頼できるものになることはまれです。タスクの洗い出しとその粒度を理解した上で、マイルストーンの設計やデモの計画、タスクの割当等の実行計画を立てることが重要です。この実行計画を基にして、数字で表せられない要素があることを念頭に置きながら見積もりを行います。また、実行計画と見積もりは、プロジェクトの進行に伴って調整されることを前提としています。そのため、プロジェクトが進行するにつれて、見積もりの不安定さが小さくなります。
タスクを細かく管理しすぎて時間だけが過ぎていく
たとえばチーム外の関係者が多く、仕様や締め切りが外部に依存しているプロジェクトでは、よくプロジェクトの初期見積もりを正確にしようとする試みが生じます。良く見られる事象として、厳格な仕様やモックデザインの要求、詳細すぎるタスクの説明、過度なタスクの細分化、細かい粒度でのタスク見積もり等が挙げられます。
こういったプロジェクトに遅れが生じると、これを初期見積もりのミスが原因であると信じこみ、より詳細な初期見積もりをしようとする悪循環に陥りがちです。結果として見積もりにかかる時間がどんどんと長くなり、時間だけが過ぎていくことになります。皮肉なもので、こういったプロジェクトほど不安要素が多いものです。関係者と十分にコミュニケーションが取れなかったり、他チームへの依存があったり、新たな関係者に仕様の変更を要求されたり、といった具合です。これらはプロジェクトの遅れに繋がり、上記の悪循環の原因となります。
適度なタスク管理は必要ですが、ある境界点を超えると、実行・デモ・フィードバックの取り込みというサイクルこそが見積もりの不安定さを減らす最も効率の良い方法になると考えています。
タスクの管理が甘すぎて大幅な遅延が生じる
プロジェクトの主導権がエンジニアにある場合、タスクの管理が不十分になることがあります。場当たり的にタスクを作っていく、もしくはタスクを作る文化がない等です。例えばプロジェクトの実行者が数人で、実行計画が全員にうまく共有されている場合には問題が出ない場合もあるでしょう。しかし、多くの場合には、重大な見過ごしから大幅な遅延に繋がるリスクを抱えることになります。
こういったプロジェクトの参加者は、ツール上でのタスクの作成や管理コストを嫌っていることが多い印象です。READMEやGoogle Docなどでも良いので最低限のタスク管理をし、定期的にプロジェクト参加者全体で見直しをすることが重要だと考えます。
まとめ
数字で表せられない要素を考慮しつつ、マイルストーンの設計やデモの計画、タスクの割当などの実行計画を元に見積もりを行う。
タスクを細かく管理しすぎない。時には実行こそが見積もりの不安定さを減らす最も効率の良い方法である。
最低限のタスク管理は怠らない。定期的にプロジェクト参加者全体で見直し、実行計画を調整する。
この記事が気に入ったらサポートをしてみませんか？