スケジュールにまつわるエトセトラ。

ずいぶんと以前にどこかで知ったことをメモったもの。
おおむかしの話にはなるけども、今も変わりはないと感じる。

あたりまえだろ、みたいなところなんだが、
ここは権威を借りて記しておくことに意味がある。
すでに出典がわからなくなってるものもあるし、少し自分で文章をいじったものもありそうだけど。

・過度のスケジュールプレッシャーは、
　エラー対策に極端に費用がかかるモジュールを生み出す最大の原因である
　(Jones1991)

・スケジュールプレッシャーが極端なときにリリースされた製品は、
　プレッシャーが少ないときに開発されたものと比べて約4倍の不良が発生する
　(Jones1994)

・期限に対するプレッシャーはソフトウェアエンジニアリングの唯一最大の敵である
　(Costello1984)

・過度、または不条理なスケジュールは
　ソフトウェアすべてに対して唯一最大の破壊的な影響がある
　(Jones1991,1994)

・見積もり結果を疑うのは有効な手段の一つだが、
　明らかに無理な期間や費用の（切望する）見積もりに書き換えることは
　自殺行為なのにそれを行なうことが多いのはばかげている。
　（出典不明）

・楽観的すぎるスケジュールは、少しの遅延では終わらない。
　平均的な小さなプロジェクト見積もりでは、100%以上の遅延になる
　(Standish Group1994)

・楽観的で達成不可能なスケジュール設定は、
　プロジェクトが計画なしで実行されるリスクを増大させる。
　→そして上流工程（要求分析・設計）の手抜きの原因となる
　→かつ下流工程では余分なテスト、不良修正、再設計、やり直しが多発
　→結果、最初から適切に作業を行なった場合より10～100倍の費用がかかる
　(Fagan1976,Boehm and Papaccio1988)

・楽観的すぎるスケジュールとそれに付随したプレッシャーは、
　転職希望率を極端に高める原因になりがち
　そしてプロジェクトを離れていく人達は、
　高いパフォーマンス評価を持つ有能な人達であることが多い
　(Jones1991)

・（遅延など）失われた時間を取り戻すのはほとんど不可能であり、
　プロジェクトはさらに遅れる傾向にある
　(Van Genuchten1991)

・プログラマはプロジェクトを20％～30％少なめに見積もりがちである
　(Van Genuchten1991)

まずはこの本を読め！
『ソフトウェア見積り　人月の暗黙知を解き明かす』
内容はこんなかんじ。