今日は、私が、とあるチームのマネジメントを任されたときの経験談を交えて、
開発初期の見積もりについて、書きたいと思います。

まだ要求フェーズ、リリース日は決定済み

とある年の 2 月、あるチームのマネジメントをしてほしいと頼まれました。
内容は、こんな感じでした。

• チーム人数は 5人
• 新規アプリケーションの開発
• まだ要求仕様を洗い出している段階
• リリース日は決まってしまっている（その年の 11月）
• 7月末までに実装が終わるか、判断してほしい

わかるかボケっ！￣△￣）／-☆

と言いたい気持ちを抑えて、どうすべきかを考えました。
まずは、見積もりの基本をおさらい・・・。

見積もりの不確実性への対処

開発初期の見積もりには、常に不確実性のコーンの問題が立ちはだかります。
特に、新規製品や新機能の開発では、正確な見積もりを出すことは不可能です。

過去に似た製品を作っている場合は、そのときの実績を使えばよいのですが、
今回のケースでは、それもできませんでした。



大事なのは、「この不確実性をなんとかして排除しないと！」と考えるのではなく、
「不確実性を前提に見積もらなければいけない」と考えることです。

不確実性に対応する見積り方法としては、以下のような方法があります。

二点見積もり

「範囲見積もり」と言ったりもしますが、最良ケースと最悪ケースの二点を洗い出す方法です。

この方法は、相手に「見積もりが不確実である」ということを示すことができます。
しかし、実はそれ以外にも良い効果があるのです。


人は、見積もりをするときに、リスクを忘れがちです。
「最悪ケースを見積もってください」と指示することで、
開発者がリスクに目を向けるようになる、という効果があるわけです。

ただ問題なのは、
「開発初期の段階では、最良ケースと最悪ケースも正確に出すことは難しい」
ということです。（参考記事）

だからといって、あまりにも範囲の広い見積もりを出しても、受け入れてもらえません。

見積もりポーカー

やり方はいろいろあるのですが、
お互いの見積もり結果を出し合い、適正値を決めていくというもので、
平たく言うと「複数人で見積もる」という方法です。

良い面としては、見積もりのレビューが同時に行えるということです。
また、お互いの認識のずれを修正することができます。

問題点は、
「時間がかかるうえに、ルールを決めておかないと話がまとまらない」
ということろです。
特に、二点見積もりを大勢で行うと、収拾がつきません。

見積もりを出すことよりも、
むしろ「認識のずれの修正」を目的に行うイベントかもしれません。

ベロシティを測る

スクラム開発などで行われる方法で、簡単に説明すると以下のようなことを行います。

1. 各タスクごとに「大・中・小」などの 3～5 段階くらいのラベルを付ける
2. 「大＝5, 中＝3, 小＝1」などのポイントを割り振る
3. 一定期間に、チームが何ポイント消化できるかを計測する

良い点としては、選択肢が少ないので「悩まなくてよい」という点です。
見積もりの時間が非常に短くなります。

問題点は、「開発が進まないとスケジュールの判断ができない」という点です。
（スクラム開発自体が、そういう思想の開発手法なんですけどね）

見積もりを出して、報告をする

この時点では、機能要求はかなり大雑把なものもありましたが、
出来る限り洗い出して、リスト化しました。
（この段階では、「大項目・中項目」までしか詳細化できない機能がほとんどでした）

方法を決めて見積もる

結局、見積もり方法としては、
前述で紹介した３つの方法の問題点を排除して、いいところだけ採用する
としました。

１．チームリーダーと私の 2人で見積もる

大勢で行うと時間がかかるため、2人に絞りました。
チームリーダーが判断できないものに限り、設計担当者と相談します。

２．各機能要求に対して、選択形式で二点見積もりをしていく

どういうことかというと、選択肢を以下に絞りました。

• 1日～3日
• 3日～1週間
• 1週間～2週間
• 2週間～1カ月

人間は選択肢が多いと決められないので、
二点見積もりとスクラム開発のいいとこ取りをしました。

３．すべての機能要求の見積もりを足していく

あとは単純に足していき、
最短日数の合計を最良ケース、最長日数の合計を最悪ケースとしました。

見積もりの結果と報告

見積もりの結果としては、最良ケースが 7月末、最悪ケースが 11月末辺りでした。
ただし、報告するときに注意が必要です。

まず初めに報告することは「7月末には間に合いません」です。

間違っても、「最短は 7月末です」と報告してはいけません。
7月末に完成する可能性がある、と思われてしまいます。

二点見積もりと実際の完成時期

経験上、私はこんなグラフになると思っています。
「最良ケース ＝ 不可能なスケジュール」というところが大事な点です。



あくまで、これは開発初期の見積もりに関してです。
リスクの洗い出しが難しいので、どうしても予後は悪くなります。

実際、どの時期に完成するかは、
「見積もりの精度」「リスクの多さ」「開発者がどれくらい実装に専念できるか」
などの影響によって変わってくると思います。
ただ、少なくとも私の経験上、最良ケース付近で完成した経験は皆無です。

私は、上司に


と提案しました。

上司がすかさず「それはダメ」と言ってきたので、
私も即答で「では間に合いませんよ」と言い返しました。

一応、こちらには見積もり書があるので（精度はどうあれ）、
あとは、どちらが引くかの勝負でした。

結果、その場で機能を削ることは出来ませんでしたが、
優先度や実装順を調整でき、後は開発の進行状況を見ながら、
無理そうなら機能を削っていく、ということでまとまりました。´´（;＾＾A

開発のその後

その後、見積もり書は、1カ月ごとにチームリーダと見直しをしていきました。

そして、実装が進んだ 6月頃に、この見積もり方法は止めました。
タスク管理システム上のタスク数でスケジュールが引けるようになったためです。

以前の記事でも書きましたが、

経験を積んだ開発者の「実装コスト」の見積もりは大体当たる

ので、開発後半は、見積もり作業を開発者に任せるようにしました。

開発の終結

実際に、Code Fix になったのは 9月で、細かな不具合の修正が 10月まで入りました。
我ながら見事な見積もりだったな・・・。

毎回、こう上手くいくとは限らないのですが、
リーダーやマネージャは、情報が少ない中でも開発の見通しを示さないといけません。

それは、スケジュール管理という点以外にも、開発メンバーに対して

自分たちが、今どれくらいの規模の仕事を依頼されているのかを示す

という意味もあります。
チーム内の認識を揃えて、みんなが同じ目標を持つようにするわけです。

チームビルディングという点からも、開発初期の見積もりは大事なのです。