「見積もり」は難しくて当たり前
ある程度の経験を積んだエンジニアであれば誰もが通る「見積もり」についてのお話。
こんにちは。
渋谷のベンチャー企業でエンジニアをしております、よこいと申します。
エンジニアとして仕事をする中で、工数の見積もりをお願いされることがございます。
ただ私ははこの工数見積もりがまだあまり得意ではなくて、見積もった工数よりも実際の作業がオーバーしてしまうといったことが起きてしまいます。
今回のお話は私の経験からなぜ工数見積もりが難しいのか解説したいと思います。
なぜ見積もりは難しいのか？
どうして見積もりは難しいのでしょうか？
原因を考えてみたところ、以下のようなものが考えられそうです。
未知数の要素が多すぎる
「過去にやったことがない」「ライブラリの選択肢が豊富」「ライブラリやフレームワークのバージョンが上がっている」など、システム開発においては未知数なことが多く発生しやすいです。
そのためそれらに対応しようと思うと正確な工数を見積もることは難しくなってしまいます。
レビューにかかる工数を含めづらい
レビューにどれくらい時間がかかるのは状況に左右される可能性が高いため、単純にタスクそのものの重さと比例させるだけでは正確な見積もりにはなりません。
未来のことなので完璧に予想することは無理でしょう。
重いタスク一つよりも複数の軽いタスクの方がスイッチングコストが大きくなる
未知数な要素が少なくある程度正確に見積もれそうな範囲においては、一つの重いタスクよりも複数の軽いタスクの方が工数にバッファが乗ります。
その理由はタスクごとにスイッチングコストが発生するからです。
大きなタスクを細分化した場合は別ですが、軽微な修正であれば複数の関連性の低いタスクがまとめて振られることがあります。
こういった場合どうやって処理するのかをタスクごとに考え直さなければならないため、効率的にタスクを処理することができません。
実装者ごとの能力差を考慮しなければいけない
見積もりをする際、自分の能力を基準にして工数を出すという方も多いかと思います。
しかし見積もりを行ったエンジニアが、必ずしもそのまま実装を担当するとは限りません。
もし自分との能力差がある方にタスクが振られた場合、工数が大きく膨れてしまうかもしれません。
こういったケースは経験的に、みなさんがイメージするよりも高確率で発生しています。
そもそもどこまで見積もるのか？
見積もりのゴールとはどこなのでしょうか？
各タスクにはタスクの種類ごとにいくつかの工程に分かれていて、それらの工程ごとに必要な時間が異なります。
これらの工程をどこまで正確に把握して見積もれば良いのでしょうか？
私の考えとして一概に言えることではないですが、時間が許す限り細かく見積もるのが正しいと思います。
特にクライアントが存在する受託開発等ではこの考えが有効です。
例としてあるAPIの実装タスクを挙げると
詳細設計
テストコード実装
コーディング
レビュー
修正・リファクタ
最低でもこれらの工程がありそうですし、さらに各工程を分解すると
正常系テスト
異常系テスト
単体テスト
のようにも分けることができます。
各タスクをここまで細分化して見積もるのは相当な時間がかかるため、完璧にこなすのは無理なのですが、ある一定の水準まで引き上げることでその後の開発もスムーズに進みます。
できる限り正確に見積もるために何ができるか？
見積もりの難しさがわかったところで、ではどうすれば性格に見積もることができるのでしょうか？
いくつかヒントになりそうなアイデアを出してみたので参考にしてみてください！
複数人で見積もりを行う
一人のエンジニアで見積もりを行うと、「実装者の能力さの考慮」が書けてしまうことがあります。
複数人で見積もりを行うことでこの能力ギャップがあることに気づき、より正確な見積もりに近づくと考えます。
しかし欠点もあるため注意したい所です。
欠点というのが「見積もりに時間がかかってしまう」ということです。
複数人で見積もりを行うと議論が発生してしまうからですね。
ですのでPJの性格をよくみて判断したい所です。
プランニングポーカーを使う
少しユニークな方法に「プラニングポーカー」というものがあります。
こちらは上記複数人での見積もりと通じる部分もありますが、カードを使って手早く見積もりを行うことで、見積もりに時間がかかりすぎるという欠点を緩和しております。
複数のプランを提案する
実装者の経験が想定したものよりも低かったケースなどを事前に考慮して、複数のプランを用意しておくという戦略です。
そして状況に合わせて適したプランを選択する。
こちらもできるのであれば理に適った戦略だと言えるでしょう。
しかしこちらの手法も複数のプラン作成のために、コストが増大してしまうというデメリットがあります。
タスクを可能な限り小さくする
見積もりを依頼される場合、多くのケースではPJを管理する立場の方から機能一覧をもらってから見積もり作業を行うことが多いかと思います。
もしいただいた機能一覧のタスク粒度が大きい場合には、小さく
さいごに
いかがでしたでしょうか？
やはり工数見積もりはエンジニアのタスクの中でも難易度が高く、一朝一夕で正確に見積もれるようにはなりませんが、その後の開発業務に大きな影響を与える重要な仕事ですので、丁寧にこなしていきたいですね。
最後までお読みいただきありがとうございます✨
もしよろしければスキ・フォロー・コメントよろしくお願い致します🙇♂️
この記事が気に入ったらサポートをしてみませんか？