- 締切済み
誰でもできる工数見積りってあるの
誰でもできるソフトウエアの工数見積りの手法を作ってくれなどと、会社から言われています。ＦＰ（ファンクションポイント）法などがあるそうですが、今ひとつしっくりきません。いつも勘に頼ってやっているのですが、何か良い方法があったら教えてくれませんか。
- emac
- お礼率57% (12/21)
- SE・インフラ・Webエンジニア
- 回答数4
- ありがとう数14
- みんなの回答 （4）
- 専門家の回答
みんなの回答
- ymmasayan
- ベストアンサー率30% (2593/8599)
No.1、No.2のymmasayanです。 ＞５倍の誤差が生じたのには様々な経緯があります。 ＞第１は・・・。第２は・・・。第３は・・・。などが挙げられます。 ＞でも一番悪かったのが、受注額に対して、かけ離れた工数見積りやプロジェクト ＞計画を私の上司らが受け入れなかったことにあります。 ＞複雑な力関係なども絡んでいてどうしようもない状況でしたが・・・ そうでしたか。第一、第二、第三は見積り対実績の差異分析はかなりできると思いますね。 でも、最後の話は、問題を先送りする粉飾決算のような話（失礼）で 、工数見積もりの話を超えていますので、私にはコメント不可能です。 ＞私の場合、工数見積り時に仕様が明確なっていることは少ないのです。 ＞このことについては、見積り手法というよりも契約方法に問題を感じます。 ＞「うちの会社だけ仕様が決まってから見積ります。」とは言えないのが現実です。 ハードウエアに比べて、ソフトウエアのほうがコスト比率が高くなり、しかもはるかに見積りが難しいのに、あまりにも早い時点で契約するやり方には大いに疑問がありますが、慣例なので仕方がないですね。ソフトウエア有償化をＩＢＭが打ち出した時のように、強力なリーダシップか、強力な連帯でもできない限りは。
- Marony
- ベストアンサー率22% (11/50)
ソフトウェアの見積・・・。 苦労しますよね。 我が事のように、思い出されます。 さて、見積の方法ですが、どの段階から開発されるのでしょうか。 よく言われる、開発段階としては、 ０：事前検討 １：要件定義 ２：概要定義（外部設計） ３：詳細定義（内部設計） ４：開発 ５：テスト ６：運用 に、分かれます。 契約形態としては、契約の時期で分けると、 Ａ：段階ごとに契約を更新する Ｂ：全てを一本の契約とする。 清算方法で分けると ａ：かかった工数に単価をかけて清算 ｂ：事前に見積を行い、定額で請負契約 ですよね。 今回のケースは、Ｂ－ｂということでよろしいでしょうか？ 見積手法に関しては、どの段階から請け負うかによって、 全然、変わってくると思います。 ０または１の段階からの請負であれば、ファンクションなんて 分かるはずもありませんので、ほとんど勘と経験と度胸が勝負ですよね（笑） で、２以降の見積のケースですが。 基本的にＦＰ法による見積でよいと思います。 ただし、そこに登場する係数は、御社の今までの経験値が 蓄積されてなければ意味がないんですよね。 会社によって、得意分野やスキルレベルが違いますので、 なんとも難しいところです。 ファンクションのレベルに関しては、細分化すればするほど 精度は上がると思われがちですが、必ずしもそうではありません。 ここの作業のバッファ的工数がつもり積もって、合計すると、 とんでもない工数になるのが、ほとんどです。 よって、ファンクションの細分化もよいですが、 各ファンクションのレベルごとに見積ってみて、 大きな差が出ないか確認するべきでしょう。
- ymmasayan
- ベストアンサー率30% (2593/8599)
No.1のymmasayanです。 ＞過去に見積りの５倍以上の実績となり、ン億円の赤字を出した経験があります。 ５倍ですか？ ２～３倍は良くある話ですが。 そういう話だと、どこまで仕様・機能を確定（推定）してから見積もるかと言う話に帰結してしまうように思います。早い時点で見積もるほど、経験豊富なベテランでないと難しく、しかも誤差が大きいと言うことになってしまいます。 ＞ところで、やっぱりＦＰ法がＢＥＳＴなんですか。 仕様・機能がかなり確定した時点ならＦＰ法のようなやり方がいいと思いますが、かなり早い段階で見積もるにはＦＰ法は苦しいかもしれません。 粗くてもＦＰ法（もどき）が適用できるタイミングの確保とＦＰ法の要因の見積能力の向上が課題だと思います。
- ymmasayan
- ベストアンサー率30% (2593/8599)
自作自演の１人作業は別として、超ベテランでも当たったためしがないというのが 工数見積もりです。まして、「誰でもできる」というのは永遠の課題でしょう。 と言っててもしょうがないので、現実論を。 詳しくは書きませんが、工数を左右する要因（項目）は山ほど有ります。 その中で具体的に要因と工数の関係が定量化できるものはごくわずかです。 結局は難易度係数とか、調整係数とか、訳のわからないものが入ってきます。 ピンと来ないところも有りますが、ＦＰ法をベースにして自社で必要な項目（要因）を 抜き出し、過去のプロジェクトの実績データを用いて重回帰分析などで重み付けが出きればいいですね。 それだけで吸収できないバラツキ要因は、癪ですが、難易度係数や調整係数を導入して補正するしかないのでしょう。 あとは、これを使用して見積もり事例を増やし、実績結果で差異（理由）分析を行い、 見積もりモデルの修正をして行くと云う事になるでしょう。 あと、見積もりを複数人の合議で行うとか、誰かが見積もったものを、複数人の合議で評価すると言う方法も見積もり精度アップに寄与すると思います。
お礼
経験の深さがにじみ出ている回答を頂きありがとうございます。 これって永遠の課題ですね。 やはり経験と実データによる地道な努力が必要だと改めて感じた次第です。 過去に見積りの５倍以上の実績となり、ン億円の赤字を出した経験があります。 ところで、やっぱりＦＰ法がＢＥＳＴなんですか。
補足
＞５倍ですか？ ２～３倍は良くある話ですが。 ５倍の誤差が生じたのには様々な経緯があります。 第１は受注したいあまりに発注側の無謀な予算を受け入れたこと。 第２はチーム或いは自社にとって未知なる技術を要する要件であったこと。 第３はスキルの高いメンバーを集められなかったたこと。 などが挙げられます。 でも一番悪かったのが、受注額に対して、かけ離れた工数見積りやプロジェクト計画を私の上司らが受け入れなかったことにあります。 複雑な力関係なども絡んでいてどうしようもない状況でしたが・・・ ＞仕様・機能がかなり確定した時点ならＦＰ法のようなやり方がいい 私の場合、工数見積り時に仕様が明確なっていることは少ないのです。 このことについては、見積り手法というよりも契約方法に問題を感じます。 とは言っても、仕様も決まってないうちから受注しようとするソフトハウスが多いため、「うちの会社だけ仕様が決まってから見積ります。」とは言えないのが現実です。