デッドライン
データ †
| 項目 | データ |
| 著者 | トム・デマルコ(Tom DeMarco) |
| ページ | 310 ページ |
| サイズ(cm) | 21 x 15 |
| 出版社 | 日経BP |
| ISBN | 4822280535 |
| 発売 | 1999/03 |
感想 †
一番面白かった部分からまず引用しよう。
プレッシャーをかけられても思考は速くならない。
〜本書P196より引用〜
ソフトウェア開発における極端な締め切りや上司の態度など、プレッシャーが開発速度に与える影響はほぼ誤差の範囲である、ということをシンプルに表現したのが、上に引用した1行である。 ラーメン屋に行って「早くしてくれ」と言っても、ラーメンがゆで上がる時間はどうにもならないのと同様だ。 プログラムを早く作れ、納期までに間に合わせろとプレッシャーをかけても、 プログラム開発が頭を回して進める作業である限り、高速化はしないということである。 実際、唯一高速化する可能性があるのは、気分が乗っていて意欲に溢れている瞬間だけだと思う。
本書は、ソフトウェア開発の本をたくさん書いている、有名なトム・デマルコの一冊である。 ちょっと変わっているのは、全体が小説、といかイソップ物語のような寓話になっていること。
アメリカのソフトウェア開発のマネージャが、リストラされたと思ったら東欧の某国にて 大プロジェクトのマネージャに抜擢され、そこでいろいろな経験をするという話。 自由に開発できると思ったら、よけいな横やりが入ったり、上から締め切り前倒しを押し付けられたり。 でも、自分の信念、経験と、周囲の専門家の協力を得て、 ソフトウェア開発を進めていくというストーリーになっている。
その過程で、主人公は発見したことを日記にまとめ、その教訓が101個となって、本書のサブタイトルになっている。
実際にはあり得ない状況下での寓話であるので、理想論や極端な前提もある。 がしかし、極端にすれば、いろいろな物事の特徴や性質がくっきりと浮かび上がることも確か。
本書を読んで、ソフトウェア開発のプロジェクト管理者は、オーケストラの指揮者に似ていると思った。 指揮者は、コンサート当日には実はほとんど必要ない。 それまでの長い練習の日々で、演奏すべき作品を自分なりに解釈し、曲の表情をつけ、オーケストラの団員をまとめ、一つの作品として仕上げていく。 それが完了すれば、極端な話、コンサート当日の演奏中に、指揮者は寝ていてもいいくらいだ。
プロジェクト管理者も同様。 プロジェクトに投入する人数をしっかり配分し、人の能力と割り当てる仕事を最適化し、 各自の協調作業がしやすい環境を整えたら、あとは最前線から一歩下がればいい。
本書は締め切り（デッドライン）以外にも、ソフトウェア開発について、いろいろなif（条件設定）を示してくれる、 変わった本である。
目次 †
- チャンスとの出会い
- 管理ごっこ
- シリコン・バレジット
- 管理者の最初の仕事
- 支配者
- 世界最強のプロジェクト管理者
- 管理者の採用
- リスク管理と生産性
- 人材管理の智将
- モデルとシミュレーション
- デッドライン：理想と現実
- プロジェクトの数量化
- プロセスの改良と変更
- 設計とデバッグの関係
- 残業の効果
- あいまいな仕様書
- 対立解決の指導者
- 対立と仲裁
- 幕間
- プロジェクトの人数
- ムダな会議の減らし方
- 問題解決の奇跡
- プロジェクトの完成
- 101の教訓