はじめに
こんにちは、Baseconnectでエンジニアをしている米丸です。みなさん、工数見積もりって難しくないですか？しんどくないですか？嫌いじゃないですか？
私も以前「見積もり、やだなーこわいなー」と強く思っていた時期があったのですが、工数見積もりが持つ特徴について学ぶことで、ちょっと気持ちが楽になった経験があります。同じように苦手意識を持っている人向けに、「これを知っているだけでも見積もりがしやすくなる」という、Tips的な話をしたいと思います。
なお、この内容はBaseconnect社内で行っているエンジニア共有会（通称：Developer Closer）でのLTをもとに作成したブログになります。社内エンジニアから役に立ったよーという声をいただけたので、ブログとしてまとめてみました。
工数見積もりはなぜしんどいか？
本題に入る前に、工数見積もりはなぜしんどいかを考えてみます。工数見積もりがむずかしい理由はいくつかありますが、エンジニアが工数見積もりをしんどいと感じる理由としては、「早くしなきゃと遅れちゃいけないの心理的ストレッチ」があると考えます。
早くしなきゃと遅れちゃいけないの心理的ストレッチ
一般論としてですが、ソフトウェア開発において機能のリリースは早ければ早いほど価値につながるため、エンジニアは管理者から「できるだけ早く開発してね！」とプレッシャーがかけられます。一方で、期限に遅れてしまうとユーザーや関係部署に迷惑がかかってしまう場合があるため「絶対に遅れないでね！」とも釘をさされます。
この「早くしてね」「遅れないでね」というメッセージングがあるため、工数を短めに見積もりたくなる気持ちと、長めに見積もりたくなる気持ちという相反する想いが同時に生じ、心理的ストレッチがかかってしまいます。
くわえて、工数見積もりは非常に難しく、実装経験さえあればできるというものではありません。心理的ストレッチがある中で見積もりを大きく外してしまい、トラウマになっているエンジニアは少なく無いのではないでしょうか？
個人的には、工数見積もりは技術を要するものだという認識をもっと広めたいです。
気持ちをちょっと楽にする工数見積もりの技術
ここから本題です。工数見積もりに苦手意識を感じていた私が、知るだけでもだいぶやりやすくなった見積もりの技術を紹介します。
1.ぶれ幅の特徴を掴む
工数と確率のベータ分布
工数見積りにはぶれ幅があります。
ソフトウェアの開発期間のばらつきを、縦軸に確率、横軸に時間軸を置いたグラフに表すと、このようなベータ分布になるといわれています。うまくいけば左端の短い期間（楽観値）で開発が終わるが、問題が起きれば右端の期間（悲観値）まで開発は長引いてしまう、という開発期間のぶれ幅を表しています。山になっている最頻値は、もっとも着地する確率の高い期間です。
まずは、見積もりには幅があるものなので、神様でも点での見積もりを正確に出すことはできないのだと、安心してください笑。また、自分が出した工数見積もりが、楽観値、最頻値、悲観値のどれにあたるのか意識するだけでも精度は上がると思いますし、受け取り手にも、それが伝わるようにしてみてください。
工数と確率のベータ分布 - 50%ライン
さらに、このグラフが面白いのは、左右対象ではなく後ろに尾をひく形になっていることです。非対称の理由としては、開発期間の短縮には限界があるが、開発を遅らせる問題には制限がないためと言われています。
グラフに赤線でひいていますが、50％の確率でここまでには開発が終わるという、50％ラインというものが存在します。左右非対称のため、この50%となるラインは、最頻値よりも少し右側にあります。そのため、一見妥当そうに見える最頻値の見積もりを基準にスケジュールを引いてしまうと、確率としては 2回に1回以上、スケジュール遅れになってしまうことになります。必ずしも最頻値の見積もりを出せばよいというわけではないのです。
もう少し言うと、大きなプロジェクトでは、50%ラインをベースにスケジュールを引きつつ、「各タスクの50%ラインと悲観値の差の標準偏差」をバッファとして持つ、といった方法もあったりします。ここでは詳細は言及しませんが、楽観値、最頻値、悲観値から50%ラインを割り出す計算式もあったりします。
2.場合分けする
いつもきれいなベータ分布になるとは限らない
先程のベータ分布のグラフはあくまでモデルであり、実際にはいつもきれいなベータ分布となるとは限りません。 例えば、ライブラリ更新だけで終わると思っていたら、思ったように動かずスクラッチでつくることになった・・・という悲しい経験が個人的にはあるのですが、そのような事例では、うまくいく場合といかない場合とで、開発工数の差は大きく乖離ができ、確率と工数のグラフもフタコブラクダのようになります。このような見積もりを大きく左右する要素が最初から分かっている場合は、それがうまくいく場合とそうでない場合とで、場合分けをして見積もりを立てるのが一つの手だとおもいます。
3.相対的に見積もる
「相対的に見積もる」とは、とあるタスクを基準として２倍/３倍/４倍といった比較値をだしたり、アバウトにS/M/L/XLといったTシャツのサイズでタスクの大きさを表す手法を指します。このとき比較するのは、過去に実施したタスクとの比較、あるいはこれから実装するタスク同士で比較をします。
個人的には、絶対時間の見積もりが必要な場合も、まず相対的な見積りをだして考えるようにしています。なぜ相対的な見積もりを出すかと言うと、まず、絶対時間の見積もりよりも相対的な見積りの方が人間は出しやすいからです。実際に、人は10倍以内のものならうまく見積もれる、という研究結果もあるそうです。あとは、絶対的な見積もりは、実装者のレベルなど諸条件によって変わるところがありますが、タスク間の相対見積もりは比較的影響をうけないので、管理がしやすいことがあげられます。
フィボナッチ数列での見積もり
アジャイルの文脈では、相対見積もりであるストーリーポイントとして、「1, 2, 3, 5, 8, 13, …」というフィボナッチ数列が使われることがあります。ソフトウェア開発は規模が大きくなるにつれて不確実性が増していくため、数が大きくなるにつれて間隔が大きくなっていくフィボナッチ数列は見積もりを表すのに相性がよいと言われています。
個人的な理解では、「うーん、このタスクの見積もりは、10、11、いや11.5かな…」などと細かい数字の違いに気をとられることなく、大きく外さないレベルまでの見積もりを意識せず出せることが、フィボナッチ数列を使うメリットだと理解して、アジャイルな開発ではなくても使える技術だと思っています。
4.理想時間と現実時間を区別する
理想時間と現実時間とは？
理想時間
- 何者にも邪魔されない、精神と時の部屋のような理想の環境で作業した場合の、開発にかけられる時間
現実時間
- 予定されていない差し込みのタスクや、切り替えのオーバーヘッドの影響を受けた、実際に開発にかけられる時間
例えば、とあるタスクを3日程度でできそうだと見積もった時に、その3日は8時間フルでタスクにあてた場合の見積もりでしょうか？カレンダーに入っている予定は考慮して差し引いているかもしれませんが、差し込みで入る小タスクや、slackで送られてくる連絡や質問へのリアクション、カフェスペースでの同僚との雑談などにかかる時間は考慮されていないことが多いのかなと思います。特にマルチタスクをしているような場合は、タスクを切り替えるときのスイッチングコストもそれなりに掛かっています。
理想時間と現実時間の活かし方
見積もりを出す時に、理想時間と現実時間を明確に分けずに考えると、失敗しがちです。理想時間での換算なのか、現実時間を考慮したものかを区別する事がまずは大事です。
ただ、現実時間をとらえることは難しいです。計測することも一つの手ですが、細かいタスクの積み重ねやスイッチングコストがどれくらいかかっているかは計測しにくいところです。一つの手として、極力理想時間と現実時間の差分が無くなるように予定を組むのは有効です。ミーティングをまとめたり、複数のタスクを持たないようにしたり、差し込みをシャットアウトする集中時間を設けたり、などです。
5.複数人で見積もる
プランニングポーカーというチームで見積もる技法があります。
- プランニングポーカーの手順
- 開発に携わる全員で集まる
- それぞれで見積もりを考え、数字が書かれたカードを伏せた状態で自分の前に出し、せーので公開する
- 自分が立てた見積もりの根拠を議論する。ギャップがあればすり合わせる
この方法の良いところは、一人よりも数人で考えた方が正確性が増すことと、開発内容について認識ずれがあった時に見積もり段階ですり合わせができることにあります。
そうはいってもチームで毎回集まるのは難しい場合があります。プランニングポーカーまでは行かなくとも、コードレビューのように見積もりをレビューしてもらう方法は、効果もあり取り入れやすいと思います。
実際にプランニングポーカーをおこなった経験では、人によって出てくる見積もりはおもしろいほど異なり、正解は無いものだと実感することができました。
むすび
工数見積もりと仲良くなるための技術をご紹介しました。どうでしょうか。ちょっとでも工数見積もりへの苦手意識がなくなったら幸いです。
本来、工数見積もりとは不確実な未来に対して道筋を建てるための有効な武器のはずですが、出す側も受け取る側もコミットメント（期限の約束）と捉えてしまうことで、エンジニアを苦しめる足かせになっていることがあります。
正確な見積もりを出すことは不可能だと認めた上で、見積もりの特性を理解し精度を上げ、足かせではなくプランを建てる武器としてうまく使って行きたいものです。
Baseconnectでは不確実性と戦うエンジニアリングマネージャーを絶賛募集しています。興味を持たれた方は、是非カジュアル面談で一度お話しましょう。お気軽にご応募ください。
