こんにちは。@koheitokumasu と申します。資源・廃棄物の収集・運搬・排出作業の効率化SaaS「WOOMS」のプロジェクトマネージャーを務めております。 本記事は、以前公開した「システム開発計画は破綻する、という前提でのやわらかな計画づくり」に続き、社内勉強会で共有した内容をもとに、「アジャイルな見積りと計画づくり」（Mike Cohn著）を参考にしながら整理したメモです。
WOOMSは、基本となるプロダクトがすでに比較的安定的に稼働しております。しかしながら、追加機能の要望も多く、また実際に追加している機能も多いため、体格の大きなプロダクトになりがちです。その中で基本プロダクトに足りない部分で、かつ顧客の細かい要求に対応していくような新プロダクトや機能追加を計画する必要があります。全体としては、大枠のロードマップを作成しつつ、足元では小さく計画し、素早くリリースできる体制構築が重要だと考えています。
前回の記事では「計画が破綻すること」を前提とした計画との向き合い方について述べました。今回は、その計画の精度と柔軟性を両立させるための核心的なプラクティスである「アジャイルな見積り」に焦点を当てます。
※プロジェクトマネジメントにありがちな誤解の図
引用元: pixiv
今回の勉強会で、私たちが至った結論は次の3つです。
- 見積るのは「時間」ではなく「規模（大きさ）」である
- 見積りは「絶対的」ではなく「相対的」に行う
- チームの実績（ベロシティ）を計測し、未来を「予測」する
「どういうこと？」と思われた方は、以下をご一読いただければ幸いです。
なぜ「いつ終わる？」という問いは危険なのか
新しい機能開発に着手する際、必ずと言っていいほど「これはいつ終わりますか？」という問いが生まれます。しかし、この問いは本質的ではありません。
たとえ話：「富士山頂にはいつ到着しますか？」
スライドで使った「富士登山」の例えが非常に分かりやすいです。 「富士山頂にはいつ到着しますか？」と聞かれたら、あなたはどう答えるでしょうか。
- 「いや、私は足が速いから…」
- 「5合目までは車で行くので…」
- 「どのルートで行くかによります」
画像引用元: 白雲荘
答えは、登る人の速度、どのルートを選ぶか、どうやって登るか によって全く異なります。 ソフトウェア開発も同じです。最初にすべきなのは「到着時刻」を問うことではなく、まず「登る山の大きさ（規模）はどれくらいか」を把握することです。
アジャイルな見積りを支える2つの要素
では、どうすれば根拠のある予測ができるのでしょうか。アジャイルな見積りでは、主に「ストーリーポイント」と「ベロシティ」という2つの要素を使います。
1. 規模を測るモノサシ：「ストーリーポイント」
アジャイル開発では、作業の規模を「ストーリーポイント」という単位で表現します。 これは「人日」や「時間」といった絶対的な単位ではなく、あくまで作業の大きさを表す相対的な単位です。
人間は、絶対的な大きさを見積もるのは苦手ですが、相対的な比較は得意です。例えば、複数のビルを見比べて「あのビルはこのビルより高い」とか、動物の写真を見て「ゾウはライオンより大きい」と判断するのは、それほど難しくありません。
ストーリーポイントによる見積りもこれと同じです。 基準となる小さなタスク（例：ボタンの色を変える）を「1ポイント」と決めたら、「このログイン機能の実装は、あのボタン変更の5倍くらい大変そうだから5ポイント」「こちらの決済機能の追加は、ログイン機能よりさらに複雑だから13ポイント」というように、相対的な比較で規模を見積もっていきます。
2. チームの速度を把握する：「ベロシティ」
作業の規模をストーリーポイントで測れるようになったら、次に登場するのが「ベロシティ」です。 ベロシティとは、1スプリント（開発サイクル）でチームがどれくらいのストーリーポイントを完了できるかを示す実績値、つまり「チームの速度」です。
例えば、あるチームが1スプリントで5ポイント、3ポイント、8ポイントのタスクを完了した場合、そのスプリントのベロシティは合計で16ポイントとなります。 これを数スプリント繰り返すことで、チームの平均的なベロシティが分かります。
重要なのは、ベロシティは目標ではなく、あくまで実績の平均値だということです。これにより、私たちは初めて未来の予測が可能になります。
予測への応用と注意点
規模と速度から未来を予測する
「実装したい機能のストーリーポイントの合計」と「チームのベロシティ」が分かれば、簡単な割り算で「すべての機能が完成するまでに、あと何スプリント必要か」を予測できます。
必要なスプリント数 = ストーリーポイントの合計 ÷ ベロシティ
これにより、「来月末までに終わります」という約束ではなく、「私たちのチームの現在のベロシティは38です。残りの作業規模は120ポイントなので、完了までにはおよそ3〜4スプリントかかる見込みです」という、根拠のある建設的な対話が可能になります。
この進捗は、実績線と理想線を比較する「バーンダウンチャート」で視覚的に管理することができます。
注意点：見積りに労力をかけすぎない
最後に、重要な心構えがもう一つあります。それは、見積りの正確性を追求しすぎないことです。ある程度の労力を超えると、それ以上時間をかけても見積りの正確性はほとんど向上しないことが分かっています。 見積りはあくまで仮説であり、完璧な予測は不可能です。 「ほどほどの労力」で素早く見積りを出し、実際の開発を進めながら計画を更新していく方が、はるかに現実的です。
ではエンジニアにはどう質問すれば？
タイトルに「ムムッ」と思って記事を読んでいただいた方もいらっしゃるかと思います。では、アジャイルな見積もりにおいて、エンジニアに締切や期限、スケジュールや見積もりを聞くときにはどのように聞けば良いのでしょうか？これには様々な解答が考えられますが、ひとまずは以下のような質問内容や態度が良いのではないかと考えます。
この機能の開発規模を見積もりたいのですが、どのような情報があれば相対的な見積もりが可能になりますか？
前述した通り、見積もりは「時間ではなく規模」「絶対ではなく相対」「チームのアウトプット実績」をベースに行います。そのため、規模・相対・実績から見積もるための前提となる情報を揃える必要があります。そこからコミュニケーションをスタートしないと、最終的に知りたい内容である「どのくらいにできるのか」を知ることができません。
おわりに: WOOMSではエンジニアを募集中です
ここまで読んでいただきありがとうございます。 このブログでご紹介した「アジャイルな見積りの考え方」は、WOOMSというプロダクトチームが大切にしている開発の姿勢そのものです。
私たちWOOMSは、 廃棄物処理という社会インフラ領域に向き合うSaaSプロジェクト です。 単なる“ごみの管理”にとどまらず、 地域社会の課題解決と、循環型社会（サーキュラーエコノミー）実現の一歩を支える デジタルソリューションを提供しています。
現在、このプロジェクトではエンジニアを募集しています。 以下のような価値観や環境に魅力を感じていただける方は、ぜひ一緒に働きましょう。
プロジェクトの立ち上げ期だからこそ、コードを書くことも、意思決定することも、すべてが次の社会を形づくる“手触りある仕事”になります。
もし、未来の当たり前を一緒につくる仲間として興味を持っていただけたら、ぜひご連絡ください。