はじめに

これは3年前に今のプロジェクトにジョインした際にまとめた時のまま、今も使っているものです。
この方法だと、見積もり完了=仕様FIX=設計完了状態なので、見積もりが出るまでにある程度時間が必要になります。
そのため、見積もりが出た時点ではもう工数足りないじゃんってことがまぁあります。（そうなったらどう間に合わせるか調整します）
ただ、これで引いたスケジュールが崩れることは少ないです。

ですが、見積もり次第でリリースバージョンを決めたい場合には、ちょっとイケてないなーと感じていたりするわけで。

というものになるのですが、 品質を重視 してこれまでやってきたので、もうちょっと良い方法がないかなーと模索中なこの頃です。

#・心構え的な

　残業、徹夜等で体調を崩して休むことになったり遅刻してしまっては、結局作業時間をロスしてしまいます。
　MTGがあったり、他のセクションとの連携にも影響が出ます。
　早く帰ってちゃんと朝来ましょう。
　頑張って残業してロジカルなことやろうとしても、きっとバグ生成してますよ。

・単位は時間（h）

　時間で出してください。

・作業時間は1日6時間で見積もる

　MTGなどで 8時間も作業できない はず。

・見積もりは定時で帰る前提

　とりあえず、まともに定時で帰る見積もりを出してみて、終わるのがいつになるのか出しましょう。
　で、リリースしたい希望日との擦り合わせをしながら、一日何時間まで残業を許すかプロジェクトで決めて、どこまで早められるか検討しましょう。
　 最初から残業前提で見積もってしまうのはやめましょう。

・1チケット8時間以内に細分化する

　8時間を超えるチケットはさらにタスクを分けたチケットを作る。

・普段見積もり慣れていない人は、自分が考えた見積もりの1.5倍くらいのバッファを加える

　早く終わる分にはいいですが、遅れた場合はスケジュールに影響があります。

・遅れた時間の倍ロスすることになる

　つまり、1日遅れると2日分ロスすることになると考えます。
　 タスクが終わるのに1日遅れ、予定していた次のタスクに取りかかるのが1日遅れるため です。

・自身で見積もった工数は死守すること

　 約束は守りましょう。
　その見積もりを考慮した上でスケジュールがあります。
　守ってもらえなくなると、どーせ見積もり通り終わらないんでしょってことで信じてもらえなくなります。
　スケジュールの調整もやりづらくなってしまい、結果、プロジェクトが上手く回らなくなります。

・なんとなくで見積もらない

　このくらいかなーで見積もりしないように。
　例えば、課金機能というので見積もりをするとして、なんとなく大変そうだから10日くらいかなーはダメです。
　いうなれば設計をしてください。
　テーブル設計で○h、実装が必要な関数が10個で各○h、修正が必要な機能が5個で各○h、などなど作業を洗い出してください。
　それで初めて工数がでるはずです。

　洗い出した作業はそれぞれチケットを作りましょう。
　関数1つで1チケットでも良いです。
　そこまで細分化しておくと、その関数だけ他の人に担当してもらったりと作業を割り振り易くなります。

・言われた期日に合わせた見積もりはしない

　企画陣はリリースしたい日を言ってきますが、そこに工数を合わせないこと。

　例えば、見積もりが10日だとして、言われた期日までは7日しかないとします。
　だからといって見積もりを7日にしないように。
　自身が品質を担保できるのが10日だとしたら10日で。
　短く見積もり出したところで結局間に合わないので、関係者に迷惑です。
　約束は守りましょう。
　
　ただ、単純にリスケを訴えるのではなく、溢れた3日をどうすればいいかは考えて相談しましょう。
　仕様を削るのか、作業者を追加するのか。
　企画陣は意図があって期日を決めているはず（でないと困る）なので、出来る方法を考えましょう。

・難易度判定ができない、チケットの細分化ができないという場合は、仕様が曖昧 or 技術調査が必要

仕様が曖昧：プランナーへ仕様を確認、確定の上、開発工数を算出
技術調査が必要：調査に必要な工数を提示、その後、開発工数を算出

簡易な見積もり表

（前述の方針を基本として）スピーディに工数見積りを出すべく、難易度判定をして時間を出す方法をとっていたり。
細かく見積もり切れちゃう人はこれは不要です。

難易度	作業時間の目安	Redmine上予定工数（時間）
A	2日以内	12
B	6時間（1日）以内	6
C	3時間以内	3
D	1時間以内	1
E	30分以内	0.5

最後に

うちの見積もり方法イケてるよってのがあれば、ぜひ教えてくださいー。