この記事は、「架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）」の記事の一部です。
見積書の概要
見積書については說明する必要もないかもしれませんが、意外と見積書を作ったことの無い人、作れない人多いです。
しっかり作れるようになりましょう。
そのためには業務プロセス、各プロセスの内容・負荷理解、人月単価等の理解が必要です。
| 項目 | 内容 |
|---|---|
| 作成目的 | クライアントに費用を伝える |
| 記述すべき内容 | 見積対象項目、金額（小計）、合計、但し書き（有効期限等） |
| 誰がつくるのか | 見積を出す会社（開発会社） |
| 誰向けに作るのか | クライアント |
| 作成タイミング | 発注前（クライアントから要求があったとき） |
| ファイル形式 | ベースはExcel。クライアント送付時はPDFか紙 |
| 備考 | 会社により様式が異なる |
ダウンロード
初期費用のサンプルのダウンロードはこちらから。
保守費用のサンプルのダウンロードはこちらから。
複数のサンプルがシートに分けられて1つのファイルに保存されています。ご注意ください。
営業系ドキュメントは「見積書」を作成すると、その他も記入されます（ヒアリングシート以外）。
作成してみる
では、作成していきましょう。
作成のポイント
見積書をいきなり書かない（まず、内部用の見積根拠資料を作る）
見積書に記述できる内容は限られているので、ある程度サマリを記述することになります。「システム開発費用 一式」として総額を出すという究極のサマリ方もありますが、多くの場合「内訳」を聞かれます。そんなとき、直ぐに答えられるように見積書のための内部用の見積根拠資料を準備しておくといいでしょう。
また、「ひとまず要件定義までを発注したい」といった感じで、プロセス別に個別発注となるケースもあるので、どのような要求が来ても再見積をスムーズにできるように内部的な見積根拠資料を別途作成しておくのが無難です。
（見積根拠資料の例）
カテゴリ別の再見積や見積根拠を聞かれても直ぐに対応できます。
但し書きを適切に入れる
必須項目としてオーソドックスな項目は「有効期限」ですが、その他、「支払条件」や、要件が曖昧な状況で見積を求められたときなどは、「要件定義後に再見積とさせていただきます」などを追記する場合があります。
その他
当然のことですが、見積書をクライアントに提出する際は、内容を必ず上司に確認してもらってから提出します。
会社によっては見積プロセスも厳密に決まっている場合が多いので、一度確認してみてください。
構成（記述項目）を考える
- 見積項目
- 数量
- 単価
- 小計
- 合計
- 但し書き
記述例（サンプルの說明）
見積書
まあ特に変わったところはありません。項目は工期が短いので工程別ではなく、全行程にかかる人月＋開発環境としています。
ま、一定以上の工数ならほぼ100%、工程別に分けてとか言われます。
いずれにしても内容について聞かれたら算出根拠含め、しっかり說明できる状態になっておくことが重要です。
一般的には
実践ガイドブックでは一般ビジネス文章のテンプレートは提供されていません。
ビジネスドキュメントについては一般とサンプルは大きく変わりません（少し簡素化されています）。ネットで該当ドキュメントを検索すると沢山でてきますし、もし、会社に所属しているのであれば会社独自のテンプレートがあるはずなので内容を確認してみましょう。