開発に戻った際に忘れないように自分用メモ。
開発見積もり系のテクニック。
見積もりや契約の前提基礎知識おさらい
見積もりの系統としてざっくり以下がある。
これは基本情報とか応用？のレベル。
1.既存の経験から今回の案件を見積もる(パラメトリック法)
2.実装する機能、という観点で見積もる
3.WBSを出し、それらの合計を元に見積もる
1はCOCOMO法とか、CoBRAとか色々あるが、最終的にはKKD法になりがち（KKD法:経験・勘・度胸でエイヤする時の揶揄）
2はお出しする機能に対する費用と考え、他技術や言語で同様に実装した際の金額と剥離しない金額に収まる。ファンクションポイント(FP)法。
3は（同じ作業をしたことがないため、）具体的な作業をイメージし細かく刻んで見積もる。積み上げ法。
個人的な経験では、ウォーターフォールの更改は1が多く、完全新規だと2、規模が小さめでちょっと変わった依頼だと3を取ることが多い。
見積もりに必要なインプット
当たり前であるが大事な前提として、契約に対する「インプットとアウトプット」をお客様と合意した上で見積もる。
インプットとして、要求仕様と、その外側にある要素（工期、納期、責任範囲や立場（SESなのか、請負なのか）、開発環境、お客さんのITリテラシーとか）。
アウトプットとして、ナニがどこまで必要なのかをヒアリングする必要がある。
具体的には、例えば普通の開発ならソースと設計ドキュメント、テストエビデンス一式だとは思うけど、、運用手順書や運用設計書が必要なのか、ユーザマニュアルの種類やユーザ教育の有無、法律向けや官公庁向けドキュメント対応とか必要か、報告義務などはどれだけ必要か、など。
業務プロセスのコンサルテーション、法律要件があるとか、ＣＤ-ＲＯＭつけるとか、紙だしするとか、セミナーやるとか、そういうのもこの段階で確認し、費用をちゃんと盛り込む。
見積もり書に載せるべき情報
全体金額、対応内訳（細かすぎないこと）、作業開始日、納品日、全体スケジュール（報告会などがある場合はそれも記載）、納品物一覧（請負なら必要）、アサイン人数（SESの場合必要。バイネームはダメ）
アウトプットが決まらない場合の見積もりや契約の進め方
特に更改や新規開発などの場合、請負とはいえ当初は何がどこまで出来るの分からず、アウトプットのボリュームが決められないことが多々ある。
その場合は、調査工程と実装～リリース工程で請負契約を分割する。
もしくはプロトタイプを挟むなどする。
前工程のアウトプットにプロトタイピング結果を含め、次の工程の見積もりのインプットとする。
ユーザの反応を見ながら・・とか非常に柔軟にアウトプットが変わる前提ならむしろスパイラル開発やアジャイル・スクラムなどがよいのでは？と思う。それならSES。
自力でエンジニアを指揮できず稟議に時間かかる日本では流行りにくいのでは？と個人としては思うけど、不勉強で申し訳ないのですが、今スクラムはどうなってるんだろうか…
見積もり金額がお客さんの想定内なのか謎な場合の対応
1.気にしないで会議に持ってく
2.会議前に費用感を直接聞く
3.会議に松竹梅の案を持って行く
下に行くほど手間がかかる。
お客様との信頼関係が有りかつ相見積もりじゃないなら２のように聞いてみるのが手っ取り早い。
１の場合、想定の桁が一つ違ったりすると場が無駄になることもあるので、だいたい３も一緒に考慮する。
リスク回避の為のチェックポイント
見積もりにはかならず以下を考慮する。
1.工期の1/2はテストに使うくらい余裕があるスケがよい
2.ドキュメントの粒度、テストの粒度を予め確認して計算する
3.進捗報告工数、レビュー工数と管理工数をちゃんと入れる（請負は必須）
4.リスクを数字にして、元の値との掛け算の係数とする
リスク係数:デフォルトのリスク工数(1.2とか)、アサインメンバーの技術野の習熟度、お客の連携の遅さとか
5.お客さんマターの再見積もり条項をつける。
例えば、開発環境を期日よりもかなり遅れて渡された時とかに「この状況に該当したので、再見積をさせて頂けますでしょうか」ってなる。
1とか、あまりにも夢見ていないか？と思われそうであるが、少しでも連携先があるようなシステムなら連携テストなどやると一月とかすぐ吹っ飛ぶので、これくらいがちょうどいい。
またこれは単なる経験上だが、テスト期間は1/3を割ると炎上することが多い。
2と3は意外と考慮が甘いことが多いから、必要ならフォーマットまで作って考えるのがいい。
4と5は、各社色々味付けがあると思いますからそこに倣う感じで。
また思いだしたら書きます。