トム・デマルコ / ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解
積読してあったプロジェクト管理の本。直訳が多くて（日本語における比喩や、次の結論への示唆などの表現の仕方が無くて）正直読みにくい部分もあったけれど、内容としては頷けるテーマが多い。
ただ、データや、誰が見ても「そのとおりだ」と言える材料は少なかったように思う。
読み手が「システム開発の現場で働いたことがある人」「システム開発チームを何かしらの立場から扱ったことがある人」である場合には納得度は高いが、そうでない場合は、腹落ちするための根拠が少々足りないと思う。
それに、それに対する対処の部分も少々薄いように感じた。
一章が短めなのもあり、1つ1つに対する解の考察は少々浅めな印象。
でも色々とヒントが散らばってます。
現場のジレンマに寄り添ったテーマが多いので、「これに関してはうちのプロジェクト（や組織）はどうか…」という視点で読み進める事ができるのはすごくよいと思う。
読んでいて少々違和感を覚えるくらい、「システム開発における」とか「IT業界の特殊性が云々」という書き方が少なかったので、IT業界じゃなくても、知識労働でプロジェクト単位で動く仕事があれば、そのまま適用出来る内容かもしれないです。
すぐに使えそうなのは、
・知識労働なんだから、単純作業工数のように切り貼りして管理できない」（切替に想像以上のコストがかかり、効率化による恩恵を得るどころか全体として効率が悪くなる可能性がある）こと
・"完成予定日"と、"完成目標日"が同じなのはおかしい
とかですかね。
最高のリスク対策は「ゆとり」
先日、同僚と話していた時に、「結局、突き詰めても"分からない"のであれば、バッファをいくばくか見ておく、ということでしかリスクの対処ができない」という話になったのを思い出した。ものすごく乱暴な言い方をすれば、システム開発の一番のリスク対策は、「ゆとり」なのだ、ということ。
いや、本当にそう思う、現場の人間としては。
そもそも細かい要素の洗い出しが事前にできず、あらゆる技術検証を全てできているわけでもなく、しかも途中での仕様変更を容易に受け入れると想像できるようなプロジェクトで、「実工数で見積を出して下さい」というオーダー自体がおかしいと言える。
あるいは、イメージだけで1ヶ月もあれば十分に実現できる（と自分はなんとなく思う）から、1ヶ月で実現しろというオーダーもおかしい。
（なぜ「技術のことは分からない」と公言している人間が、妥当な工数を見積もれると信じ込んでいるのか、私には理解が出来ない。）
でも、現場を知ろうとしない人は、それがおかしいオーダーだということを理解できない。
なぜ、そういう仕事をするときに、我々がどういう手順でどんな具体的な作業を行うのかを確認しようとしないのか。
そしてそれらほとんどの作業が「うまくいくかどうかは、やってみないとわからない」事だと、どうして理解しようとしないのか。
専門家に聞けばすぐだ、とか、仕様書に書いてあるはずだ（お前が目を通していなかっただけだ）、とかいうのは素人の意見で、そんなことで全ては担保できない。
窓口の自称「技術者」が、全く事実とは違うことを「公式回答」として述べることもあれば、仕様書に書いてあったことと正反対の制約がかかっていること、担当者ですら知らなかった相性の不一致など、残念ながらザラである。いやマジで。
仮に、本当にすべてを網羅し尽くした詳細な契約ができたとしても（何かが起きた時他人の責任だと誰かが認めてくれたとしても）、こっちのプロジェクト期限が延びるわけでもなく、結局最後に泣くのは現場なのだから。
あまりにそういうことが多いから、一つ一つをお互いに追求しあって（訴訟しあって）いたら人生が終わってしまうので、「ゆとり」を見ておくことでお互いがリスク対処するのが一番現実的なのだ。。。。