![[PukiWiki]](image/sandbox.gif "[PukiWiki]")
ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（4） http://www.ark-web.jp/sandbox/wiki/3076.html
ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（4）
ソフトウェア見積り―人月の暗黙知を解き明かす
http://www.amazon.co.jp/dp/489100522X/miqqle-000-22/ref=nosim
の読書メモを記していきます。
※ 引用内の強調は筆者（進地）による。
※ 引用内の中略は（中略）で示す。
5章 見積りに影響するもの †
プロジェクトの規模 †
- ソフトウェア見積りの最大の変動要因はソフトウェアの「規模」
- 規模は他の要因以上にばらつきがある
- 規模はLOC（Lines Of Code：コード行）、ファンクションポイント、要求、Webページ数などではかれる
- どの尺度で測ってもプロジェクトの規模と工数は正の比例関係にある
- 最大のコスト変動要因がプロジェクトの規模であるというわかりきった事実に組織は二つの点で違反する。
- 「■そのソフトウェアがどれだけの規模になるかわからずに、コスト、工数、スケジュールを見積ってしまう（p.62）」
- 「■ソフトウェアの規模が意識的に増やされた場合（つまり要求変更に応じた場合）にも、コスト、工数、スケジュールを調整しない（p.62）」
- ソフトウェアの規模の不経済＝「ソフトウェアにおいて、プロジェクトが大きくなるほど、より大きなグループ間のコーディネーションが必要になる。大きなグループになるほど、より多くのコミュニケーションが必要になる（Brooks 1995）（p.63）」
- コミュニケーションパス（経路）はプロジェクト人数nの２乗で増加する（n × (n - 1 ) / 2 ≒ nの２乗の関数）。つまりソフトウェアの工数はプロジェクトの規模に応じて非線形で増加する。
- 最悪ケース（生産性が規模の増加により急速に低下したプロジェクト状態）では、100万LOCの工数が1万LOCの規模の工数の100倍ではなく、300倍にもなる。
- コミュニケーションパス（経路）はプロジェクト人数nの２乗で増加する（n × (n - 1 ) / 2 ≒ nの２乗の関数）。つまりソフトウェアの工数はプロジェクトの規模に応じて非線形で増加する。
- プロジェクト規模と生産性とには負の相関がある。
- プロジェクト規模が1万LOCのプロジェクトの人年あたりのLOCは2,000〜25,000だが、規模が1,000万LOCになると人年あたりのLOCが300〜5,000になる。
- 「小規模のプロジェクトの生産性は大規模のプロジェクトの2〜3倍を示し、最も小さいプロジェクトと最も大きいプロジェクトを比べると、生産性は5〜10倍も変わる（p.66）」
- プロジェクトの規模が異なる場合、見積りに最も影響を与える要素が異なることになるため、既存の見積りデータからの単純な比率等では見積れない。こうした場合は、統計技法を駆使した「サイエンス」としての見積りを使う必要がある。具体的には見積りツールを利用する。
- 「見積りをしているプロジェクトとほぼ同じ規模（最大と最小の差が3倍以内）のプロジェクトを以前に完了した経験があるなら、人月あたりのLOCなどの比率を使った見積り方法でも、新しいプロジェクトをさほど問題なく見積ることができるだろう（p.67）」
- 同一組織ではプロジェクトは似た規模になることが多いため、その場合は規模の不経済は無視しえる
- 規模の不経済はもちろん重大な影響があるが、しかし、見積りに最も大きく影響を与えるのは構築するソフトウェアの元々の規模であり、規模の経済は２次的なものであることに注意する必要がある。
開発するソフトウェアの種類 †
- 「規模」の次に見積りに影響を与えるのはソフトウェアの「種類」。
- ソフトウェアの種類が異なればおのずと工数は変わってくる。人命に関わるソフトウェアと業務システムとでは必要とされる工数が異なってくるのは自明。
- 「社内向けイントラネットシステムを開発しているチームは、航空電子工学関連やリアルタイムシステムや組み込みシステムのプロジェクトで作業しているチームに比べて、10倍〜20倍も早くコードを生成できる（p.69）」
- 自分の組織の過去データを使うことが、「自分の働く業界特有の開発要因を自動的に組み込んでいる（p.69）」ため、最良のアプローチになる。
人的要因 †
- 「COCOMO�兇砲茲譴弌⊃妖�要因の組み合わせによる影響は、10万LOCのプロジェクトにおいて、その見積りを22倍も変動させる可能性がある（p.70）」
- 書籍には人的要因の影響の表があげられており、要素としては、要求アナリストのスキル、プログラムの（一般的）スキル、要因の継続性（離職率）、アプリケーション（業務領域）の経験、使用言語とツールの経験、プラットフォームの経験、チームの結束があげれている。表では要求アナリストのスキルの影響が最も高く、最低ランクの要求アナリストのいるプロジェクトは見積りより42%多くの工数を必要とし、最高ランクの要求アナリストのいるプロジェクトは見積りより29%少ない工数で済む。
- 「こういった人によるばらつきは、その作業を誰が行うのかわからなければ、プロジェクトを正確に見積ることができないことを意味している。パフォーマンスは人によって、10倍あるいはそれ以上にばらついているからだ。しかしどんな特殊な組織でも、見積りにおそらくそれほど多くのばらつきを計上する必要はないだろう。なぜなら、最高ランクの開発者と最低ランクの開発者は、似たようなスキルレベルを持つ人たちのいる組織に動いていく傾向があるからだ（Mills 1983, DeMarco and Lister 1999）（p.70）」
プログラミング言語 †
- 「プロジェクトで使用する言語とツールの経験が、プロジェクト全体の生産性におよそ40%の影響を与える（p.71）」
- プログラミング言語が選択できない状況であれば、あまり見積りには関係がない。選択可能な場合は、コンパイル言語よりも一般にスクリプト言語（インタープリタ言語）の方が生産性が高い。
- 「インタープリタ言語で作業する開発者は、コンパイラ言語で作業する開発者に比べて、おそらく２倍ほども生産的であるという点だ（Jones 1986a, Prechelt 2000）」
- 言語のみならず、言語に付随するツールと環境の豊富さが重要。
- 「COCOMO�兇砲茲襪函∈念�のツールセットと環境は、最強のツールセットと環境に比べて、プロジェクトの総工数をおよそ50%増加させるという（Boehm et al. 2000）。プログラミング言語の選択は、ツールセットと環境の選択でもあることを、はっきりと認識しよう（p.71）」
COCOMO�兇諒篝軌�子 †
- COCOMO�兇諒篝軌�子
- 見積りに影響を与える因子とそれぞれの因子に対して組織（やプロジェクトチーム）の評価を行い、見積り工数の補正に利用できる。
- 例えば、因子にはアプリケーション（業務領域）の経験、データベースの規模といったものがあり、それぞれに対して、組織、チームを非常に低い、低い、高い、非常に高い、特別に高いの5段階評価を行い、それぞれに定義された係数を見積りにかける。アプリケーション（業務領域）の経験は非常に低い場合の係数は1.22で、非常に高い場合は0.81であり、その比率は1.51になる。これを影響度と呼ぶ。つまり、アプリケーション（業務領域）の経験が非常に低い組織は、非常に高い組織に比べて1.51倍の総工数を必要とするとみなせる。
- コントロールノブの多さは見積り誤差につながるため、見積りにCOCOMO�兇鰺�用することは著者は賛成していない。しかし、COCOMO�兇話�者いわく、統計的にもっとも厳密に特定因子を分析しているので、プロジェクト因子のプロジェクトに与える影響と重要性を理解するために補正因子の学習を勧めている。
- 一般に影響の大きい因子（ただし、ソフトウェアの規模によって影響を受ける因子もある）
- プロダクトの複雑さ、要求アナリストのスキル、プログラムの（一般的スキル）、時間的な制約条件、要因の継続性（離職率）、複数サイトでの開発、ソフトウェアの信頼性に関する要求、文書化要求の程度、アプリケーション（業務領域）の経験、ソフトウェアツールの活用（以上、影響度が1.50以上のものを影響度が大きい順にリストした）
- 以下、いくつか気になった因子の詳細をとりあげる。
- 要求アナリストのスキルは人的要因としては最も大きい影響度(2.00）を持つ。「優れた要求技能は、最も大きな人的要因であり、プロジェクト全体の工数に2倍の違いを生む。この分野で適正があれば、他の因子以上に、プロジェクト全体の工数を見積りから減少できる可能性がある（p.77）」
- 複数サイトでの開発も影響度(1.56）を持ち影響はやや高い。「世界中の複数サイトにまたがって実施されるプロジェクトは、一か所に作業場所を集結したプロジェクトに比べて、56%も多くの工数がかかる。複数サイトで実施されるプロジェクト（アウトソースまたはオフショアのプロジェクトを含む）は、この影響を深刻にとらえる必要がある（p.76）」
- 文書化要求の程度は影響度(1.52)。「あまりに多くのドキュメントはプロジェクト全体に悪影響を与える。影響はやや高い（p.76）」
- アーキテクチャとリスクの開発は影響度（1.38）は相対的に低めだが、プロジェクトマネージャによってコントロール可能な数少ないCOCOMO�兇琉�子。「プロジェクトが積極的にリスクを除去するほど、工数とコストは低くなる（p.76）」
スケーリング係数 †
- COCOMO�兇諒篝軌�子の内、プロセスの成熟度、アーキテクチャとリスクの解決、先例、チームの結束、開発の柔軟性の５つの因子はスケーリング係数と呼ばれ、規模の不経済を助長して、規模によってプロジェクトに与える影響が異なる。
- スケーリング係数はプロジェクトの規模が小さいうち(10万LOCなど)は上位因子とならない影響の小さい因子だが、規模が大きくなると(500万LOCなど)すべてが上位因子になってくる。
- 「プロジェクトの計画とコントロールの観点からこれが意味することは、小・中規模のプロジェクトでは、個人の力量で成功の大部分は決まるということである。大きなプロジェクトでも個人の力量はやはり必要だ。しかし、大きなプロジェクトでは、どれだけぷロジェクトがマネジメントされるか（特にリスクマネジメントに関して）、どれだけ組織が成熟しているか、そしてどれだけ個人がチームに溶け込むかといった要素の方が重要になる（p.79）」
5章の感想 †
- まず規模が何よりも見積りに影響するという当たり前の事実を肝に銘じる必要がある。だから、規模の見積りを行わずにいきなり工数、コスト、スケジュールを見積るのは絶対NG。
- 規模の不経済の影響は大きいが、留意するのはこれまで行ってきたプロジェクトと著しく規模が異なる場合だけでよさそう。それよりも、見積りに自分達の組織、チームの過去の実績データを利用することの方が組織や業界、ソフトウェアの種類といった固有の特性も含まれているのでよりよいアプローチになる。
- 優れた要求技能が人的要因として見積りに大きな影響を与えるという認識はとても重要だと思った。最大2倍の影響は大きい。
- 複数サイトでの開発の影響は、弊社のようにパートナーとの協業、プロジェクトメンバーがリモートで協力してプロジェクト運営していく体制を採用している組織にとっては重要。弊社はSkype+VNCによる画面と音声共有やSVN、Remineの利用など複数サイト体制でも効率的に開発できる手法を工夫しているが、今後ももっと意識して改善していく余地があるだろう。
- プロジェクト、ソフトウェアの規模によって見積りに大きく影響する因子が異なってくるのは面白い。規模の不経済も影響してのことだと思うが、規模が大きくなればよりチームワーク、組織運営力が要求されるし、規模が小さい場合は個々人のスキルにプロジェクトの成功が影響される。プロジェクト規模を大きくすることを望む場合は、スケーリング係数の因子の向上を図らないといけない。単に同じスキルを量的に伸ばせば大規模案件に対応できるということではないということか。
関連コンテンツ †
Menu
Movable Type用プラグイン Aシリーズ
ECサイト構築 Zen Cartハイエンド
Tag
A-Form
Ajax
CPAN
EC2
FastCGI
FlashLite
Flex
Google
Google Calendar
GoogleMaps
GoogleMapsAPIforFlash
Graph
JSON
JSONP
Jamal
JavaScript
MT
MTPlugin
MTテンプレート
MVCフレームワーク
Maple
Movable Type
MySQL
OpenSocial
PHP
Perl
Plugin
PukiWiki
RIA
RightFields
Ruby
Ruby on Rails
Skype
Spam
Twitter
Web2.0
WebAPI
gettext
prototype.js
script.aclo.us
selenium
trac
エクスペリエンス
オープンソース
スクレイピング
セキュリティ
ツール
テスト
ネットワーク
勉強会
最新の20件
2017-05-12
2014-04-30
2013-09-16
2013-02-21
2012-09-04
2012-04-03
2012-02-29
2012-02-06
2012-01-19
2011-12-19
2011-11-13
2011-08-08
2011-07-07
2011-02-17
2010-12-02
2010-11-04
2010-09-16
ARK-Webビジネスブログの最新記事
2014-01-08
2014-01-07
2014-01-06
2013-12-13
2013-12-11
2013-11-29
2013-11-28
2013-11-26
2013-11-19
2013-10-28
2013-10-18
2013-10-15
2013-10-11
2013-09-26
2013-09-24
