&pgid();
#contents
** 講演者 [#bf7f5104]
- 高橋光裕氏
- （財）電力中央研究所 （独）情報処理推進機構
- 1985年頃からずっとコストの見積りをやってきた
- 通称：Jackyさん
- 学生時代に火消しの助っ人アルバイトをしていた
-- 周りに日曜の昼しか子供とご飯を食べられないお父さんたちがいっぱいいた
-- 毎日家で子供とご飯を食べられるようにするために、ソフトウェア工学を志す
** ソフトウェア見積り・評価の難しさ [#wc20e4f3]
- 90%=50%の法則（いかにソフトウェアの測定、評価が難しいか。90%できてると思っても実際は50%）
-- 計画が立てられ名い、計画通りに進められない、成果の実態が見えない
** 見積りの肝は規模把握 [#z1aeb8de]
- プロジェクト混乱の第１原因は規模の過小評価
- 混乱の第２原因は仕様変更（手戻りのコストは機能の観点からは見えなくなる）
- 「当たり前品質」が実は・・・（隠れたお客様の要求仕様）
** リソース見積りを誤まるとほぼ確実にプロジェクトが混乱することのは何故か？ [#scfbd1d3]
- エンジニアの生産性が明日から2倍、3倍になることはありえない。16時間、20時間働いても1.3倍程度がいいとこ。しかもこれが1ヶ月続けられるような人間はいない。
- 兵力の逐次投入は愚の骨頂（純軍事的にも）
-- 後から人が入ることによる生産性の低下は、大規模プロジェクトによる生産性の低下よりかなり悪い
- ポイントは１日でも早く不吉な予兆に気づくこと、そして、やるときは大げさなぐらいに一気に力を投入する（じゃないと逐次投入と同じ末路に）
** 見積り方法の変遷 [#c16f7855]
- エイヤッ！ → KKDD(KKD+妥協)、COCOMO ホスト全盛期までは環境やツールがどれも似ていたのでこの方法が通用した
- マルチベンダ/CSS化になってプロジェクトごとに環境が非常に異なるようになり、熟練者のKKDDも、コード行数をカウントすることも難しくなった。FP法、WBSが流行。
- 今、FP法が当たり前の時代になってきた。また、付帯作業（インストールなど、プログラムやその規模、機能に関係せず必要な作業）に代表される非機能要件も無視できない重みを持つようになったため、これのボリュームも把握できる必要がある。
- スコープマネジメント（何が作りたいのかはっきり認識して規模を認識する）、プロジェクトベンチマーキング（過去の類似プロジェクトとの比較など）
** 見積りのトレンド [#qba2fed2]
- 〜1980年代：工数見積り重視
- 1990年代〜：バブルがはじけて、見積りの説明責任が求められるようになった。規模見積りが必要に。
** 規模見積りの変遷 [#q852b6f6]
- 開発者の作業対象量（プログラム本数や行数）から画面数、帳票数（物理的要求量）、ファンクションポイント（機能数）＝ユーザの要求量に遷移してきた。
-- FPは実装の詳細に依存しないというメリットも
** 工数見積りの変遷 [#j393c33c]
- 単純積算 -> COCOMO（規模の係数が指数でかかる） -> 類似事例の生産性をベンチマーキング
-- COCOMOには指数の乗数があるが、指数を使わなければならないほどの規模の分割で見積りやプロジェクト運営を行うことは非常に危険
- 類似事例のベンチマーキングは非常によい
** FP法の特徴 [#o5d87e0f]
- FPはあやふやな利用者要求を決められた手順と規則で計測/算出していくなかでこれが決定していく。これによって、要件があやふやな状態で見積りを出すことがなくなる。
- 個人差が5〜15%ほどしか誤差がでない。根拠があって、説明ができる。
- 利用者（顧客）にもわかりやすい（。ので、諸々交渉もしやすい）
- FPは全世界で何十種類の流派がある
- 要件定義、機能設計、機能テスト、納品前検査などでは、行数の変わりにFPが使える
- プログラミングフェーズでは行数と工数の相関性が強い（局所の見積りにはFPは向いていない。というか使うべきでない）
- プロジェクトの特徴によって同一の組織でも生産性が異なる。種類別の組織の生産性をFPでプロットしてみることができる
&blikifooter(進地);
#blikifooter(進地);
![[PukiWiki]](image/sandbox.gif "[PukiWiki]")
