3日連続でサラリーマン時代のネタになってしまった。
PCのディスクの隅に、サラリーマン時代に読んだ仕事関係の本の読書記録があったので公開したい。10年以上前の読書記録だが、お役に立てば幸いだ。
読んだ本は、『ソフトウェア見積りのすべて―規模・品質・工数・工期の予測法
』(Caper Jones著 構造計画研究所 2001)だ。
ソフトウェア開発の作業工数を正確に見積もるためのノウハウ本だ。
見積もりは難しい
ソフトウェア開発で「低く見積もりやすい工数」は次のような作業だ。
- 非コーディング作業
- 欠陥除去（デバッグ）作業
- スペシャリストのコスト
- ユーザー側のコスト
- カットオーバー後数年間の保守コスト（欠陥修復・機能追加）
見積もり担当者が注意すべき点は次のようなのがある。
- 用心深くあれ
- 品質はコスト、スケジュールに影響を与える
- 文書作成も見積に含める
- 「徐々に増大する要求」の影響
- アクティビティレベルでコストを見積もる
正確な見積もりは「良いデータの蓄積」が必要→「カン、経験、度胸」で見積もっていては、いつまでたっても「良い見積もり」はできない。
とはいえ、見積もりは「単純な経験則に基づく手作業」が最も一般的だ。
「経験で見積もる」ことを「十分正確ではない」と知りつつ用いていることがプロジェクト管理の厄介な問題となっている。
銀の弾丸はない！
プロジェクトの工数とスケジュールには互換性はない！
つまり、スケジュールを圧縮しようとして投入人員を増やせば、それだけ生産性は低下する。
これは、ソフトウェア開発論のバイブルともいえる『人月の神話』(フレデリック・P・ブルックスJr.著 ピアソン・エデュケーション 2002)において、
「狼人間を撃つ銀の弾はない」
という金言で表現されている。
エンジニア1人で1ヶ月でできる作業ならば、2人投入すれば半月でできるかといえば、できない。
人が多くなるとコミュニケーションのコストが上がるからだ。
顧客・経営者が足を引っ張る
見積りが顧客、経営者の意に反する場合、彼らの主観的意向(笑)が強く反映される。
ただし、結果（悲劇）の責任はプロジェクトリーダーが負わされる。
もちろん、悲劇は開発現場にいる一般社員にも及ぶ。
21世紀のソフトウェア開発現場はどうだろうか。悲劇を繰り返さないために何かやっているのだろうか。
理想的な作業環境
ソフトウェア開発・保守の環境は次が理想とされている。
- 外部からの中断なく集中して働ける状況が最適。
- 開発と保守は分離→保守と開発を同時に行っているような場合には害をもたらす中断が最も高い頻度で起きる。
- スケジュールがタイトになってもプロジェクトメンバーに圧力をかけるな→スケジュールプレッシャーは誤りを犯しバグを混入させるような不注意につながり、逆にスケジュールの延長を引き起こす。
こんな「理想的な環境」は日本企業では難しいかな。
プロジェクトメンバーに負荷にならない現実的な見積もりを怒り狂う顧客（またはユーザー）、上司、経営者に対して説得できるかがポイントだ。
