📖

ソフトウェア開発の見積もり入門

2022/03/23に公開

見積もりとは？

Wikipediaによると見積もりとは、以下のようにあります。

見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。
Wikipedia

このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。

見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。

見積もりが苦手な人は多い

ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います。

このような時間的な見積もりを苦手とする人は意外に多いのではないでしょうか？僕も若い頃はすごく苦手でした。

「この見積もりどおり終わらなかったらどうしよう。」とか「この作業自体全然想像できないから、どのくらいの時間がかかるかわからない。」とか毎回プレッシャーが掛かっている気がして、見積もり作業はすごく嫌だった記憶があります。

ではどうやったらこの見積もりに対する苦手意識をなくせるのでしょうか？それは『見積もりとはどういうものか？』をもっと深く理解することです。
僕が想像する見積もりへの苦手意識の原因として『見積もりについて理解が足りない、または勘違いしている』というケースが多いのかなと思っています。

見積もりをおこなう上で重要な心構え

まず、見積もりを行う上で心構えとしてとして重要な点をあげます。それは『見積もりは外れるものだ(実際の結果とは乖離するものだ)』と理解することです。

見積もりは、前述のとおり何かをする前の予想・概算です。世の中に予想に近い概念は多く存在しますが、これを必ず正解する物だと考えている人は少ないと思います。

同じように見積もりも当然外れます。どんな内容の見積りかにもよりますが、ソフトウェア開発は人が行うものなのでこの辺りのズレは顕著で、初期開発であればおそらく見積もり通り進むほうが珍しいでしょう。

ですので、見積もりが苦手な人で『見積もりが当たることが前提』として捉えている人がいたらまず、この意識を変えるのが良いと思います。それだけで無用なプレッシャーや責任感から少しは解放されるでしょう。

「上司から依頼された見積もりなのだから大きく乖離してはいけない」とか「自分が見積もりを外したせいでチームに迷惑を掛けてしまうのは嫌だ」などネガティブなプレッシャーを感じてしまう必要はありません。

見積もりのステップ

見積もりの心構えについて記載したので、もう少し実践的な内容を説明します。見積もりには自分自身で完結するものもありますが、ここでは第三者に依頼された見積もりを想定して、見積もりの基本ステップについて説明します。見積もりは基本的に以下の工程に分かれます。

① 何のための見積もりなのかを確認する
② 見積もる
③ 見積もりの根拠を説明する
④ (必要であれば修正する)

①について、見積もりが苦手な人はこのポイントを省略している場合が多いので、もし当てはまる人がいた場合は意識すると良いと思います。

見積もりには必ず目的があります。
『開発金額を概算したい』『開発期間(リリース時期)を知りたい』『生産性を算出したい』など、依頼している人がどんな目的でその見積もりが欲しいのかを必ず確認しましょう。

目的確認で特に知りたいのは『見積もりの精度』です。②、③の説明として見積もりの根拠について後述しますが、目的がわからないと正しい精度で見積もりができない場合が多く、後から説明する場合や大きく乖離があった場合にうまくコミュニケーションが取れないトラブルが発生します。
このような問題を回避するために、必ず見積もりの目的は確認するように意識しましょう。

見積もりの根拠について

ここからが実際に見積もりをする工程についての説明ですが、まず見積もりをする上で『見積もりの根拠(何をもとに見積もったのか？)』について理解する必要があります。
見積もりとは、【何か】をもとに事前にする予想です。まずはその何をもとに見積もりをすればよいのか？を理解しましょう。
ここでは、『自分が行う作業時間の見積もり』にフォーカスして説明します。

見積もりの根拠はざっくり分類すると以下の5つに分けられます。(正確にはもっと別の分類もあるかもしれませんが、今回ざっくり次のようにわけます。)

① 自分が過去に経験した同じ事象
② 自分が過去に経験した類似する事象
③ 他人が過去に経験した同じ事象
④ 他人が過去に経験した類似する事象
⑤ 当てずっぽう

①は、自分が過去全く同じことを経験したことがある場合です。『Aというタスクは以前やって2時間位だったため、今回も2時間で見積もる。』というケースです。

②は、全く同じではないが、同じような構成の作業をしたことがある場合です。

③については、自分ではない別の人が同じタスクを経験している場合です。この場合は『Xさんが以前2時間で終わったと言っていたので大体同じ位で見積もる』となります。

④は、他の人が類似した経験をしている場合で②と内容は同じです。

③、④の場合は、自分の作業スピードと別の誰かの作業スピードのギャップを理解する必要があります。Xさんが行うスピードが自分よりも早いならばもう少し、時間を取る必要がありますし、遅いなら短めにします。

⑤は、適当に当てずっぽうで決めます。全く想像ができないが数字は出さなくてはいけないときの最終手段です。

この見積もりの根拠は、①が一番精度が高く、⑤が一番精度が低くなる傾向にあります。

見積もりの精度は経験の量に比例する

根拠から見積もるときに、精度を意識することも重要です。
前述のとおり見積もりで一番精度が高く出せる経験として『自分が過去全く同じ経験をした場合』がありますが、このようなケースにおいても精度にはブレが生じます。
それは、『経験の量の差』です。基本的に見積もりの精度は経験値の大小に比例します。

例えば、【徒歩で会社へ通勤している人の通勤時間を見積もる】という場合。
同じ会社へ1年通っているAさんと、その日が2回目の出社のBさんであれば、Aさんのほうが正確でブレが少ない見積もりができます。それは、1年間という経験の量から誤差が生じる可能性がある懸念点を予め考慮できるためです。

このように見積りとは経験の蓄積によって精度が変わります。そのため、仮に同じタスクを経験済みだったとしても、1度しか経験していない場合はそれなりの精度しか出せないことがあります。

見積もりに対してバッファを乗せる

これはソフトウェア開発において一般的な考え方ですが、開発を行うときに想定していないトラブルや遅延は日常的に発生します。開発するのは人間のため、体調や家庭の事情による遅延などいつ起こるかは不定な要素が多く含まれるためです。このような場合は、見積もった時間に対して バッファ(何かトラブルが発生した場合の余剰時間) を予め上乗せしておきます。

バッファについては、考え方が色々と存在するため、どのくらいのバッファを上乗せすべきかはここでは詳細に記載はしません。個人的な考えとしては、2割でも、5割でも、ある程度適切なバッファ(根拠があるバッファ)であれば問題ないと考えています。バッファもまた、経験によってどのくらいの量が適切かという精度に差が生まれる要素の一つです。

見積もりの根拠を説明する

ここまでで、『何かの根拠を持って見積もりを行う。』『見積もりに対してバッファを上乗せするする。』という流れで説明を行いました。

最後に最も重要なポイントとしてその見積もりを 依頼者へ説明する というタスクがあります。
ここでのポイントは、

何を根拠に今回の見積もりを作成したか？
何割のバッファを上乗せしたか？(理由も説明できればなおよし)

など、見積もりの内容を正確に伝えることです。
この【説明する】というタスクは非常に重要です、ある意味見積もりの精度よりも重要といえるかもしれません。

前述のとおり、見積もりには必ず目的があります。この説明によって『その目的が本当に果たせているか？』をすり合わせるわけです。

逆にここで根拠やバッファの説明を正確に伝えたうえで、仮に見積もりが外れたとしても、それを非難されることはないはずです。(少なくとも僕はそれで何かを言われたことはありません)

重要なことは、必要な内容を正確に相手に伝えて、見積もりに対して合意をとること です。
見積もりはあくまで予想なので、合意さえとれていれば結果はそれほど重要ではないのです。(もちろん正確に見積もれるに越したことはないですが。)

まとめ

見積もりが苦手な人は、『見積もりという作業がどういうものか』を改めて理解すると良いと思います。
ポイントを押さえさえすれば見積もり自体は全く難しい作業ではなくなります。
重要なポイントを以下にまとめます。

見積もりは外れるものだと理解すること
見積もりの根拠を明確にすること
見積もりの根拠(やバッファ)について依頼者に説明し合意をとること

以上、見積もりが苦手だと感じている方は参考にしてみてください。