2022年7月27日水曜日

開発工数を見積るときの個人的なポイント

開発工数を見積るときの個人的なポイント

概要

あくまでも個人的な考えです

まずはやることを洗い出す、必ずここからスタートする

やることがなければ工数の算出もできません
まずは自分がやるべきこと、タスクを洗い出しましょう

更に言うとそのタスクは可能な限り細かく洗い出したほうがいいです
その上でこの設計にはこれくらいかかりそう、この実装にはこれくらいかかりそう、テストはこれくらいかなと見積もりましょう

そのほうがより具体的になりますし見積もりの精度も向上すると思っています
また後述していますがそのプロジェクトや開発以外も掛け持ちしている場合はそれらに割くタスク、工数も洗い出して置くと良いです

洗い出しのコツは先にざっくり出してそこから細かくしていく

例えば「設計」「開発」「テスト」くらいはじめはざっくり洗い出してそこから更に設計では「API設計」「ライブラリ設計」「DB設計」など必要になりそうなコンポーネントレベルで細かくしていくとやりやすいです

自分の技量を低く計る

自分の生産性をある程度数値化しておいた上で見積もる場合は少し低めの数字で見積もりましょう
理由は常にそのパフォーマンスが出るわけではないのと書くコードがセンシティブであったり複雑である場合もあり神経を使いながら書くことでパフォーマンスが落ちることもあるのでそういった状況が発生することも踏まえて低めにしておくといいかなと思います

ギリギリ、カツカツで計算しない

これも上記に似ていますが納期などは100%フルパワーを続けた場合の納期ではなく 50-70% で開発を続けた場合の納期を考えておきましょう

理由は先程と同じですが常に 100% を出すのは難しいからです
またスケジュールに余裕があると心の余裕もできるので結果的に成果物の精度がよかったり早く終わったりすることもあると思います

機能だけでなくテストやレビュー、リファクタの時間も考慮する

一口に開発と言ってもやることはいろいろとあります
すでに正確にやることが算出されているのであればあとはそれに工数を割り当てるだけでいいのですが大抵の場合はあとからタスクが追加になったり予期せぬ外力というかタスクが振ってくることがあります
なので開発以外のコストも含めて工数を算出したほうがいいかなと思っています

通常の運用業務なども考慮する

もし本当に開発のみであれば考慮する必要はありません
開発しながら運用業務を片持ちしている方も多いと思います
その場合はそれらのコストを割くことも考慮して見積もりましょう

体調の変化や日常の生活も多少は考慮する

常に元気であれば常に 80 - 100% のパフォーマンスは出せるはずです
しかし人間は病気になったりプライベートもあります
なので体調が悪かったり風邪になったりして休む場合もあります
そういった自分の体調の変化も多少考慮しておきましょう
もちろん体は資本なのでそもそも体調を悪くするのは良くないですが何があるかわからないのが人生です

事前に何が必要になるのかイメージする

実際に開発する前にある程度設定すると思います
更にその前段階で何をやるかを具体的にイメージできると良いです
例えば「こういうツールが必要になりそう」「こういう調整が発生するだろうな」「こういう機能が必要になりそう」などある程度具体的にイメージできるとそれをベースにして工数が算出できます

ただこれはある程度経験をしないとわからない部分が多いのでわからないところはわからないまま進めても良いと思います

あとは依頼主との調整

最終的には自分の見積もりを依頼主などにレビューしてもらい OK がもらえるかどうかです
当然早ければ早いほどいいに決まっていますが自分の経験的にギリギリカツカツで見積もった場合は大抵の場合どこかで再スケジューリングが入るか品質が悪くなるかになります

最後に

要するに安かろう悪かろうなのかもしれませんが人間が頑張る分結局ミスも必ずあるということです
もちろんスキルや経験の違いで見積もりが全然違う場合もありますが、それは考えずあくまでも自分がやったらこれくらいになりそうというのを自信を持って言えればいいのかなと思っています

高効率、低コストになるのは経験を積めばできるようになるのでそれまでは自分の技量や技術、生産性を理解するという意味でも自分に合った工数算出をするべきだと思います

あとはファンクションポイント法や過去の実績から見積もる類推見積法などの技もあるのでそういったものを理解してから自分なりに見積もるのもありだと思います

0 件のコメント:

コメントを投稿