ソフトウェア開発プロジェクトの利益率とかリスク率とかのお話 | ぽんぽんぺいんなう＼(^O^)／
最近、来季（４月〜）のお仕事のお見積りの嵐。そこで気になっている話をしてみる。 ソフトウェア開発の依頼を受けた場合のお見積りの流れはこんな感じ。（数字は究極の社外秘なのでてきとーです。） １）まずは純粋に工数見積り 依頼された工程（設計・開発・単体試験・結合試験とか）について、機能毎の難易度などを考慮しながら工数を出す。 今回は１００人月（例えば１０人で１０ヶ月）だったとする。 ２）コストを試算 予定メンバーのコスト（その人の給料や手当や共通配賦（事務所の家賃や間接部門の人達のお給料をみんなで負担する分）などの合計）からプロジェクト全体のコストを試算する。 例えば、全メンバーの平均コストが５０万円／月だったとすると、コストは５０万円×１００ヶ月＝５０００万円。（そのほかの経費などもあるが省略。） ３）リスク率 今回は１００人月と見積もったけど、始めてみたら話が違ったりトラブルがあったりで１
根拠のない見積もりはなぜ生まれるのか？ - MOONGIFTのプロジェクト管理ブログ
例えば「ECサイトに新しい決済機能を追加したい」という要望に対して見積もるとしたらどう回答するでしょう？ もちろんこれだけの漠然とした条件では分かりませんが、例えば「3週間あれば」と回答したとしましょう。そこで疑問になるのはなぜ「3週間」なのかということです。2週間と3日間でも、3週間と4日間でもありません。なぜ3週間という数字が出てきたかが問題です。 通常、そこにはこれまでの経験則から導きだされる予想数値が入ります。しかしシステム開発というのは大抵はこれまでにないものを作ることが多いので、経験則だけではカバーしきれません。そこで使われるのが“直感”です。 個人的に直感はおおむね正しいと考えています。しかし直感は定性的なものであり、定量的な測定に対して用いるべきではありません。つまり「できそう」か「できなさそう」かの判断に直感は必要だと思いますが、3週間という数字に対して用いると誤差が大き
精度の高い見積もりを行うためのたった一つの秘策 - MOONGIFTのプロジェクト管理ブログ
これは確かJoel on Softwareで紹介されていた方法だったと思うのですが、個人的にずっと実践しているものです。 一つのタスクは最大16時間を限度とする これだけです。もし16時間以上かかりそうなら、タスクを分割します。このルールを守るだけで見積もりの精度は間違いなく向上します。 なぜかというと、人は今日明日くらいの予定であれば概ね把握しています。明後日になると途端に読めない部分が出てきます（突然ミーティングが入ったり、体調不良になったりなど）。なので1日の労働時間8時間×2日分の16時間は絶対に越えてはいけないのです。 逆に16時間以内で見積もれる範囲にまで作業を細分化すると、概ね自分の経験則から作業量が読めるようになり、予定時間数も分かってきます。これまで何となく“2日分”だった工数が実は15時間分だったのか、はたまた20時間分だったのかも分かるようになります。もし20時間分だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
寄 稿 海 外 調 査 レ ポ ー ト 自 主 研 究 国 土 経 済 論 叢 講 演 再 録 建 設 経 済 調 査 レ ポ ー ト 自主研究 COCOMO IIによる工数見積り 「経済調査会ソフトウェア開発データリポジトリ」��
cmmntr.com
