見積りに関する3つの重大な誤解
学生時代は教科書以外の本をほとんど読まなかったのに、社会人になってから月に1万円以上を書籍に費やすようになりました。みなさんはいかがでしょうか？
実は半年ほど前に買った本「ソフトウェア見積り 人月の暗黙知を解き明かす」を読みながら過去の出来事を振り返っていると、私が初めてプロジェクトリーダーになってプロジェクト管理を任されたころのことを思い出しました。
ここでは私の実体験をもとに以下についてお話します。
- 上司に見積りを提出しても突っ返されてしまう
- 見積りを出す必要性がわからない
- 見積りを立ててもうまくいかない
もしかしたらあなたもこういったことに心当たりがあるのではないでしょうか？
とあるプロジェクトでの出来事
自社の小さなプロダクトの機能改善を任された日のこと、上司に
「ロードマップ上では今年の3月末にリリースすることになっている。どのくらいで終わりそうなのか見積りを立てて欲しい」
と言われました。
私は「わかりました」と一言告げて見積りを立てはじめました。
もうすでに年は明け、今は1月中旬。人生で初めて見積りを立てるのでどうやって立てるのかわかりませんでした。とりあえず必要なタスクをそれなりにまとめてこれらにかかる時間を予測し、数日後に上司に報告に行きました。
「これらの機能を全て対応するには3ヶ月くらいかかりますので4月中旬くらいになりそうです。」
すると上司はこう一言。
「遅い。3月末までにリリースするように計画を立てろ。」
…はい!?
言っている意味がわかりませんでした。
いやいや、見積りを立てろって言われたから見積りを立てたのにそれをひっくり返すように3月末までに終わるように計画立てろってどういうことですか？
当初は訳がわからず困惑しましたが、私が経験不足ということと上司に逆らうことができないという理由から「わかりました、3月末でリリースします」と約束してしまいました。
結局リリースできたのは4月末で、当然プロジェクト評価は下げられました。
Q1.「見積り」とはなんだ？
見積りとはなんなのでしょう？
日本国語大辞典にはこのように書かれています。
① 目分量ではかる。目で見てだいたいをはかる。
精選版 日本国語大辞典
② だいたいを計算して目やすをつける。あらかじめ時間や経費などを概算して予測をたてる。
計算をして目安を立てる、概算して予測を立てると書かれている通り私は確かに予測を立てました。それなのになぜ突っ返されてしまい、挙句の果てに無茶な要求を呑まされたのか？
あの頃はそんな理不尽な思いをして苦しみましたが、「ソフトウェア見積り 人月の暗黙知を解き明かす」では見積りについてこう言及されています。
辞書にある「見積り」の定義は厳密な意味では正しい。見積りとはプロジェクトにかかる期間やコストを予測することだと言ってよい。だが、ソフトウェアプロジェクトの見積りとは、ビジネスのターゲットと、コミットメントと、コントロールとの間の相互作用である。
(中略)
ターゲットが実現したいビジネス目標の記述であるのに対して、コミットメントとは、定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束を意味する。コミットメントと見積りが、同一のものを指すこともあるが、コミットメントが見積りより挑戦的だったり保守的だったりすることもある。言い方を変えると、コミットメントと見積りが同一でなければならないと考えてはいけない。そもそも同じではないのだ。
著書「ソフトウェア見積り 人月の暗黙知を解き明かす」より一部抜粋
つまりあの日上司が要求してきたことは「見積り」ではなく「コミットメント」だったと。
経営陣は技術的な背景を知らないため、「見積り」「ターゲット」「コミットメント」「計画」を明確に区別はしないと述べており、この点については近年の私の経験を照らし合わせてもその通りであると思います。
結局のところ、「見積りをだせ」というのに対して言葉通り「見積り」を出すのではなく、その前に実は「コミットメント」を求めているのではないかを確認しなくてはいけなかったということです。
Q2. 何のために見積りをするの？
そういえば過去にプロジェクトマネジメント研修を受けたときに以下のことについて学びました。
- プロジェクトは不確定要素が多いため、計画通りに物事がいくことはほぼない。しかし計画を立てることに意味がある
- プロジェクトが計画通りにいかないことが分かったらそのたびに計画を練り直す
これらはとてもためにはなったのですが、これでは「見積りは外れて当然、やっていく中で調整するしかない」というように聞こえてしまい何のために見積りを立てるのかわかりませんでした。見積りがずれるたびに上司から過度なプレッシャーをかけられるストレスは避けられないのかと。
結局研修の時ではこの疑問は解決できませんでしたが、本書では「見積り」と「計画」は別物だと指摘しています。
見積りは、先入観に縛られない分析的なプロセスでなければならない。一方、計画は先入観を排除せずにゴールを志向するプロセスだといえる。見積りを行う際に、特定の解に到達できると思い込むのは危険な考え方だ。見積りのゴールは正確性であって、特定の結果を追求することではない。一方、計画のゴールとなるのは、特定の結果の追求である。
著書「ソフトウェア見積り 人月の暗黙知を解き明かす」より一部抜粋
つまりどうすれば目標が達成できるのかを試行錯誤してプロセスを組み立てるのが「計画」で、客観的に分析して目標を達成するのにどのくらいかかるのかを割り出すのが「見積り」だということです。
では何のために見積りするのか？本著では以下のように述べられています。
見積りの主目的はプロジェクトの結果を予言するものではない。見積りを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的かどうかを判断するためである。
（中略）
見積りにとって重要なことは、完璧なまでに正確であることより、有益な情報を提供することである。正確な見積もり、適切なターゲットの設定、適正な計画とコントロールの三拍子が揃って、「見積り」に近いプロジェクトの結果が実現できる。
著書「ソフトウェア見積り 人月の暗黙知を解き明かす」より一部抜粋
つまり、見積りは外して当然のものではなく、望む結果が得られる程度にプロジェクトがコントロールできるかを判断するために適切に行う必要があるものだということだ。
Q3. なぜ見積りがはずれてしまうのか？
ではすべて上司の表現の仕方が問題だったかといわれると、少なくともあの頃の自分も過ちを犯してました。4月中旬にできるといいながらリリースしたのはその2週間先だったからです。
また、他のプロジェクトでも何度か見積りを立てる必要に迫られましたが、いずれも完了日がずれてしまい全然うまく見積りができないことに対してしばらくコンプレックスを感じていました。
なぜ見積りがうまくできないのかずっと気になっていました。
本著によるとソフトウェア見積りは不確実性が多く含まれるものであり、その結果は確率分布に従うものであるといいます。つまり、見積りというのは「○○から○○の間」という形で表現されるべきであるということです。
しかし、私が今までやってきた見積りというのは「(おそらく)4月中旬くらいに終わります」という一点型の表現でした。これは見積りの皮をかぶったターゲットだと著書では述べられています。
もしあの日上司に「プロジェクトは3月下旬から4月末の間に完了する見込みで、3月中に終わる可能性は30%くらいです」と報告していたら少しは評価が変わったのではないだろうか？(上司が求めていたのはおそらく「コミットメント」だったと思うのでそんなに変わりはしなかっただろうが)
まとめ
書籍「ソフトウェア見積り 人月の暗黙知を解き明かす」を読み、私の過去のプロジェクト経験を振り返ることで3つの重大な誤解について説明しました。内容をまとめるとこのようになります。
- 上司のいう「見積りをだせ」というのはコミットメントを示唆している可能性がある。本当の意味で「見積り」を求められているのか、「コミットメント」の達成方法を尋ねられているのかを区別すること
- 見積りと計画は別プロセス。見積りはプロジェクトのターゲットがコントロールすれば達成可能な程度に現実的かどうかを判断するために必要なこと
- 見積りは「○○から○○の間」という形で表現されるべきで、「(おそらく)○○までに終わります」という一点型の表現は「見積りの皮をかぶったターゲット」
まだ見積りについては学ぶべきことはたくさんありますが、これらを知るだけでもだいぶ仕事はしやすくなります（少なくとも私はそうでした）。
見積りを立てる前にもう一度ここに書かれている内容を確認して上司とうまく折衝しましょう！
PS
これらはすべて本著の第一章で書かれていた内容にもかかわらず、これだけ多くの気づきを与えてくれます。もしあなたがプロジェクトマネージャーでプロジェクト管理を任されているなら「ソフトウェア見積り 人月の暗黙知を解き明かす」は見積りについて非常に有益な情報が書かれています。一度手に取って読んでみることをお勧めします。
