作りたい機能から、工数のたたき台に。

作りたい機能や案件の説明を貼ると、工程ごとのざっくりの人日と、この見積もりが成り立つ前提条件、崩れうるリスクを出します。そのまま社内チャットに貼れる文章もつくります。正式な見積書ではなく、着手前に規模感をつかむための下書きです。

WHAT YOU WANT

作りたいものを貼る

作りたい機能・案件の説明要件メモ・やり取り・箇条書きなど、形式は問いません。具体的なほど工程が分けやすくなります。開発体制前提・気になっていること（任意）

貼った内容はこのブラウザ内だけに保存されます。まず動きを見たいときは「見本を読み込む」から。

まだ何もありません左に、作りたい機能や案件の説明を貼ってください。
工程ごとのざっくりの人日と、前提・リスクが出ます。
まず動きを見たいときは「見本を読み込む」から。

「ちょっとやってほしい」に、その場で答えない理由

先に結論

1つの数字ではなく、範囲（幅）で答える。情報が少ない段階ほど、幅は広くなって当然。
見積もりには、必ず前提条件が付く。前提が崩れれば、見積もりも崩れる。ここを黙っておくと、あとで「言った通りにならなかった」と揉める。
ざっくりのたたき台は、正式な見積もりではない。社内合意の材料であって、対外的な約束の文書ではない。

社内から「これくらいすぐできる?」と聞かれたとき、その場で数字を出すと、あとで根拠を聞かれても説明できません。逆に「わかりません」だけで終えると、次から相談されなくなります。あいだにあるのが、工程に分けて、ざっくりの範囲で答え、前提とリスクを添えるという手順です。1つの数字ではなく、幅と前提を出すことが、見積もりを「約束」にしないための唯一の方法です。

1見積もりが「約束」になってしまう理由

「1週間でできます」と口頭で答えると、その場では規模感の共有だったつもりでも、聞いた側には約束として残ります。あとで前提が変わっても、最初の数字だけが記憶されます。

幅と前提をセットで出すことで、「その前提が崩れたら、幅の上のほうに動く」という会話ができるようになります。数字ではなく、数字の周りにある条件のやり取りが本題です。

2工程に分けると、どこが膨らんでいるかが見える

「全部でざっくり◯人日」だけだと、あとから増えた作業がどこに埋もれたのか分からなくなります。工程ごとに分けておけば、増えたのはどの工程かがすぐ指せます。

工程	含まれるもの	増えやすい理由
保存先の用意	データの持ちかたと登録・削除の処理	あとから項目が増えると、ここに追加の作業が乗る
画面	入力・表示・操作の見た目	デザインが後から変わると、ほぼやり直しになる
確認・調整	実際に操作して崩れを直す	ここを最初から入れておかないと、後工程が丸ごと抜ける

3このたたき台が向いていないもの

これは着手前に規模感をつかむための下書きで、契約金額の根拠にする正式な見積もりではありません。金額を出す見積書・請求書には、既存の「見積書・請求書をワンセットで発行」のような別の道具を使ってください。

納品後に「検収が揉める」という別の問題には、既存の「追加依頼の切り分け」「納品前の検査」が向いています。

よくある質問

この人日は、どのくらい正確ですか?

正確な数字ではなく、着手前の規模感をつかむための幅です。要件が固まるほど幅は狭くなり、逆に情報が少ない段階では幅は広くなります。契約金額の根拠には使わないでください。

前提条件は何のために出るのですか?

この見積もりが成り立つために仮に置いた条件です。前提が崩れると、見積もりもその分ずれます。着手前に、この前提が本当に正しいかを確認するために使います。

金額は分かりますか?

金額は出しません。人日（作業量の目安）だけを出します。

工数は、1つの数字ではなく、範囲と前提のセットで持ち歩くものです。