TODO
要件定義 †
契約の種類 †
雇用 †
請負 †
- 完成に責任を持つ．
- リスクが高いので，見積の際はその分を上乗せする
- 瑕疵担保責任（検収で気づかないミスがあったら、１年以内ならば売主に対し損害賠償の請求ができる．損害賠償ができないなら売買契約そのものを解除することも可能．契約で瑕疵担保責任をなくすこともできる）
準委託 †
契約書 †
- 与信管理
- 売掛で逃げられないように（着手金，中間金を要求する）
仕事の受注 †
見積もり †
- 仕様や期間などの条件(要求仕様)が確定したとき、見積して金額を確定する。
金額の策定 †
- 3つの制約条件を満たす最大値を提案する
- 自分の報酬（以上）
- 相手にとっての価値（以下）
- 競合との相場（以下）
- 論理的に考えた見積もりで高すぎると言われたら，「じゃあいいです」という余裕が重要
- もし交渉するなら，相手にとってどこがボトルネックなのかを見極める
- 自分の報酬の場合：瑕疵担保責任などあり，上乗せの必要があること．能力の格が違うこと．したがってバイトとは一線を画していることを伝える．ダメならさよなら．
- 相手にとっての価値：さよなら．
- 競合の場合：競合の項目を更新して再度見積もり．ダメならさよなら．
その他の補正 †
火消屋 †
- 炎上したプロジェクトを救うと、とにかくお金がもらえる
- 具体的には、客先への信用＋請負契約の損害賠償の最大額まで、最大でもらえる。
注意 †
- 業界自体の価格破壊を起こさないために安売りは避けるべき
見積りの内容 †
- 要件定義，設計，実装，テスト，ドキュメンテーション
- 必ず全て含めること
- 「本当の」人日で見積もりをするわけではない．それは自分の報酬に関する制約でしかない．実際に客に出す人日は，価値と相場を込みで考えた時の値から逆算する．
見積もり変更 †
- 見積もり後に、要求仕様と異なる条件になった場合は、見積の根拠が失われる
- 見積もりを破棄し新たな条件で見積書を提出する。「見積もり条件がかわるので再見積します」というのが常套句。
- 請求は再提出した見積書に記載した金額でおこなう。
客先の都合による変更 †
- そもそも仕様変更を見込んで上乗せ
- 機能追加がありそうな案件は、ある程度の予め上乗せしておく
- 仕様変更による再見積もり
- 先方が追加だと思ってない場合は、やはりトラブルになる。
- 仕様があいまいだったり、仕様変更がありそうな案件は、見積書に仕様の条件を厳密に記載して縛る。
- ソフトの場合ある程度の仕様変更は仕方ない
- 常套句：「本当はないんですけど，今回だけ特別にサービスで」
- 厳密に仕様変更を別見積もりにすると、ビジネスにならない。
齟齬による変更 †
- どちらの責任で伝わらなかったのかとかいう責任論になる。(言わなかった、聞かれなかったなど)
- 材料など原価に直結するものの要求は事前に念入りに確認し、見積書に条件を記載する。
- PCだったら、CPUやメモリー、ディスプレイの仕様など。造形物だったら素材や重量など。
- 具体例
- たとえば、出張一泊の見積もりで見積もった作業が、客先の都合で二泊にのびた場合、いきなり二泊分で請求するのではなく、二泊になって条件がかわる旨を先方に伝え、見積書を再提出して、その額で請求。
- こういった場合、見積書と請求書を同時に提出することになる。
参考価格 †
- 人にアルバイト任せられる値段の、3倍くらい。
- 6万円/日で，普通の会社のプログラマ
- 10万円/日で，大きい会社のプログラマー
- 25万円/日で，PMやコンサル
仕事の断り方 †
- 本音は抜きにした断り方
- 理由：今別の仕事があるので．繁忙期にお引き受けしてクオリティを下げてしまっては申し訳ない．私には荷が重い。
- クッション：残念ですが、申し訳ありませんが、お話ありがたいのですが、
- 代替案の提案：一週間後でいかがでしょうか。他のこういった事ならできます。
- NG
- 「当方に利益がでないので …」「やりたくないんだから、断って当たり前」という態度
- 「できません」など、否定語の多用
- 「どうしても時間がとれないので」「上司から了承されないので …」
著作権 †
守秘義務 †
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
