見積書 のバックアップ(No.4)

• バックアップ一覧
• ソース を表示
• 見積書 は削除されています。
  • 1 (2014-08-01 (金) 12:27:59)
  • 2 (2014-08-20 (水) 05:59:19)
  • 3 (2015-01-19 (月) 20:54:09)
  • 4 (2015-01-29 (木) 02:52:53)

ビジネス

目次 †

見積り †

• 仕様や期間などの条件(要求仕様)が確定したとき、見積して金額を確定する。
  • 見積額と請求額は一致する。
  • 見積書には、後でトラブルにならないよう、要求仕様として合意した内容、仕様書の資料番号や納品条件などを記載する。
• 競合との比較でそこに比べてリーズナブルであればお客さんは文句ない。
  • むしろ価格破壊を起こさないために安売りは避けるべき

見積もり変更 †

• 見積もり後に、要求仕様と異なる条件になった場合は、見積の根拠が失われる
  • 見積もりを破棄し新たな条件で見積書を提出する。「見積もり条件がかわるので再見積します」というのが常套句。
  • 請求は再提出した見積書に記載した金額でおこなう。

客先の都合による変更 †

1. 仕様変更を見込んで上乗せ
   • 機能追加がありそうな案件は、ある程度の予め上乗せしておく
2. 仕様変更による再見積もり
   • 先方が追加だと思ってない場合は、やはりトラブルになる。
   • 仕様があいまいだったり、仕様変更がありそうな案件は、見積書に仕様の条件を厳密に記載して縛る。

• ソフトの場合ある程度の仕様変更は仕方ない
  • 本当に厳密に仕様変更を別見積もりにすると、ビジネスにならない。

齟齬による変更 †

• どちらの責任で伝わらなかったのかとかいう責任論になる。(言わなかった、聞かれなかったなど)
• 材料など原価に直結するものの要求は事前に念入りに確認し、見積書に条件を記載する。
  • PCだったら、CPUやメモリー、ディスプレイの仕様など。造形物だったら素材や重量など。

• 具体例
  • たとえば、出張一泊の見積もりで見積もった作業が、客先の都合で二泊にのびた場合、いきなり二泊分で請求するのではなく、二泊になって条件がかわる旨を先方に伝え、見積書を再提出して、その額で請求。
  • こういった場合、見積書と請求書を同時に提出することになる。

要件定義 †

• 要件定義書は私が作りますか、あなたが作りますか

見積りの内容 †

• 要件定義，設計，実装，テスト，ドキュメンテーション

見積りの目安 †

• すべては相場ベース。
  • 人月という概念は、見積と請求のための便宜上の概念でしかない。
  • 人日は、大きな会社だと、人数が大きいので分散が抑えられるため有効
• 人日
  • 1日=8時間にもらうお金。
  • 目安
    • 人にアルバイト任せられる値段の、3倍くらい。
    • 6万円/日で普通の会社のプログラマくらい。
    • 大きい会社ならプログラマーで人日10万とか、PMやコンサルならその倍以上とかもあるから、増やせるなら増やしてもいい。