デッドライン

著者 : トム・デマルコ 伊豆原弓

• 日経BP (1999年3月19日発売)

感想・レビュー・書評

[masterkaさんの感想 · 2018年1月14日]

感想は以下
http://masterka.seesaa.net/article/456199230.html

[nagoemonさんの感想 · 2016年10月6日]

久々に読んだが、忘れかけていた新しい知見も得られ、毎度参考になっていると思う。

[eraさんの感想 · 2016年5月7日]

2006年に一度読んだことがあるみたいだが記憶になかった。2016年に再読。プロジェクト管理をそこそこしてきた今だから納得できるし発見がある、読んでよかった。トムキンス、ラークサー、NNL、ベリンダ、無理矢理な導入と結末。
・正しい管理の本質、適切な人材を適所にあてはめ人々の士気を保ってチームの結束を強め維持する。
・リスクを管理することによってプロジェクトを管理せよ。
・プレッシャーをかけても思考は速くならない。
・管理者の怒りと侮辱は伝染する。
・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
・入出力の完全なリストのない仕様書は、見込みなしである。
・理想の人数配分は、プロジェクト期間の大部分を少人数のコア・チームで行い、プロジェクトの終盤に人数を大幅に増やすというものである。
・会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである。
・プロジェクトには儀式が必要である。
・病んだ政治を下から治療することはできない。
・倹約精神とは、失敗した企業の中で、その失敗の責任者が作った公式である。

[nzkumagorouさんの感想 · 2016年1月29日]

物語形式で展開される、とあるソフトウェア開発の物語。

さまざまな出来事により、プロジェクトマネジメントの要衝のおさえかた、実行の仕方、ものごとの進め方を学べる一冊でした。

読者がソフトウェア開発プロジェクトに関与しているなら、とても共感できる部分が多いと思います。

たとえば残業時間と生産性の話や、無駄な会議を減らす方法など。

また私自身、自分の経験をうまくあらわせなかったことが整理されていて役立ちました。特に設計段階は少人数で進め、製造で一気に人を投入するあたりは、うまくいったプロジェクトでも同じでした。頭を使うフェーズは、人が多すぎると「船頭多くして・・・」になりかねないと再認識です。

唯一、試してみたいけど怖くてできなさそうなのが、設計時間を圧倒的に費やし、設計段階でバグを潰すという考え方。これ、実際にやったら、ものすごいプレッシャーになると思います。だけど、クソみたいな設計で製造に入るよりも、きちんと机上で言葉で考えぬいてからのほうがいいんだろうなあという共感はできました。

[triangle3さんの感想 · 2016年1月19日]

テストのコメント

[loveyomiuriさんの感想 · 2016年1月2日]

物語とともに教訓を得られるため、非常に分かりやすかった。
気づきのあった言葉をいくつか。
「日常のリスクに注意せよ」
日常のリスクに気づくために、KPT法を使うのは、非常に有用ですね、やっぱり。
「変更はあらゆるプロジェクトの成功のために必要不可欠である」
改善、改善ですね！
「入出力の完全なリストのない仕様書は、見込みなしである」
これ、妥協しないように気をつけないと。

[しんきちさんの感想 · 2015年9月25日]

-

[Bikkieさんの感想 · 2015年9月1日]

最後のオチが良かった、、かな。

[satoshiqauiさんの感想 · 2015年4月29日]

架空の国とシステム開発プロジェクトを舞台にした小説を通して、ソフト開発を成功に導く法則を紹介する内容

・一日をむだにする方法はいくらでもある。しかし一日を取り戻す方法はひとつもない。
・プレッシャーをかけても思考は速くならない。
・我々は味方同士である。敵は問題そのものだ。

■正しい管理の四つの本質
・「適切な人材を雇用する」、
・「その人材を適所にあてはめる」、
・「人々の士気を保つ」、
・「チームの結束を強め維持する」

「バグはモジュールの真ん中にあるんじゃなくて、モジュールの端にあるんだ」

・感情とプライドを持った人間の管理

■戦闘が始まるときには、管理者のほんとうの仕事はもう終わっている
■変更は、あらゆるプロジェクトの成功のために必要不可欠だ
■人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとする
■どれほど強い脅しをかけても、最初に割当てた時間が足りなければ、やはり仕事は完成しない
■短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する
■リスクを管理することでプロジェクトを管理せよ

第12章「プロジェクトの数量化」
■測定単位を気にするな。客観的な尺度ができるまでの間は、主観的な単位を使えばよい
■考古学的なデータを収集し、これまでに完了しているプロジェクトから生産性を算出する
■過去のプロジェクトをもとにトレンド・ラインを引き、予想される労力を合成尺度の値の関数として示す予想をたてるべき

第16章　なぜ管理者は怒るのか?
それは、恐れているから。与えられた役割をまっとうできないのではないか、会社の期待に背くのではないか、立場を失ってしまうのではないか、失敗するのではないか… 仕事場では、恐怖を表に出すことは許されない。けれども、何かを吐き出す必要があるとき、たいてい怒りが選ばれる。以下の文章をもっと早く知っていたら、どれだけ（過去の）わたしが救われたことだろう。
■怒りは恐怖である。部下に対して罵倒の行動をとる管理者は、ほとんどの場合、恐いからそうしているのである
■怒っている人は、恐怖を表に出したくない。つまり、怒りが恐怖の表れだと分かってしまったら、怒りを吐き出すこともできなくなる
■これは怒っている人の問題は解決できないが、他の人の悩みは軽減できるだろう


ソフトウェア開発に関わるプロジェクトは何らかの問題を抱えてしまうものだ。その問題はいつも同じわけではなく、過去のプロジェクトでうまくいったところが問題となってしまう。それは、プロジェクトに関わるすべてのことが問題になりうるということを意味する。多くのプロジェクトのリーダーや管理者はそのことにいつも頭を悩まし続けていなければならない。

多くのツール、手法そして概念がその解決策として取り上げられているが、それだけでは解決しない。プロジェクトを形成するのは人であり、プロジェクトマネジメントに人が占める要因は決して小さくないからだ。本書は、その「人」についてフォーカスを当ててプロジェクトマネジメントを語っている。

とはいえ、プロジェクトマネジメントには多くのツール、手法そして概念は必要である。本書で提示された101個の法則とそれらをうまく活用することがプロジェクトのリーダーや管理者にとって重要である。プロジェクトマネジメントについて不安や問題を抱えている、もしくは経験の浅いリーダーや管理者にまず目を通してほしい。（新保康夫）


■デッドライン ソフト開発を成功に導く101の法則
http://anond.hatelabo.jp/20090725154202

正しい管理の四つの本質
・適切な人材を雇用する。
・その人材を適所にあてはめる。
・人々の士気を保つ。
・チームの結束を強め、維持する。
（それ以外のことは全部管理ごっこ）

安全と変更
・変更は、あらゆるプロジェクトの成功のために（ほかの大抵の物事についても）必要不可欠である。

・人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとする。

・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。

・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力が行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。

負の強化
・脅迫は、結果を上げさせる手段としては不完全である。

・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。

・さらに悪いことに、目標を達成できなければ、脅迫の内容を本当に実行しなければならない場合もある。

管理者の身体の本質的な部分
・管理は心、腹、魂、鼻でやるものだ。

　つまり……

　心で指揮をとる。

　自分の腹を信じる（直感を信じる）。

　組織に魂を吹き込む。

　くだらないものを嗅ぎ分ける鼻を持つ。

戦闘指令と管理の関係
・戦闘が始まるときには、管理者のほんとうの仕事はもう終わっている。

面接と採用
・採用には、管理に必要な身体の器官、心臓、魂、鼻、腹をすべて使う（しかし、腹が大部分だ）。

・一人でやろうとするな。二つの腹には、一つの腹の２倍以上の力がある。

・新しく採用した人材には、１回は実証済みの能力レベルのプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする。

・意見を求めよ。最も採用したいと思った人物は、ほかの優れた人材を知っている可能性が高い。

・話すより聞け。

・これらのことは、下準備をしておけばさらに効果がある。

生産性の向上
・短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。

・短期的な効果を約束するものは、いんちきである可能性が高い。

リスク管理
・リスクを管理することによってプロジェクトを管理せよ。

・プロジェクトごとにリスク調査の方法を確立して継続せよ。

・最終的な望まざる結果だけでなく、日常のリスクに注意せよ。

・それぞれのリスクの実現する確率と予想コストを評価せよ。

・リスクが現実になる前の初期の兆候を予測せよ。

・やる気のある態度を常に引き出そうとしない人物をリスク管理人に任命せよ。

・悪い話が上層部に伝わりやすい経路（匿名性など）を作っておくこと。

防御体制の強化
・無駄を減らす。

・成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。

・失敗した作業は早く打ち切る勇気を持つ。

・チームの結束については必要のない賭けはしない。既存のチームを探して利用する。

・結束の遅い、または結束しないチームのために後継者が困らないよう、優れたチームは維持する（本人たちにその意思があれば）。

・新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つと見なす。

・プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。

・一日をむだにする方法はいくらでもある……しかし、一日を取り戻す方法は一つもない。

開発プロセスのモデリングとシミュレーション
・仕事を完成させるプロセスに関する直感をモデル化する。

・仲間との対話の中で、プロセスの進行に関する考えを伝えたり修正したりするためにモデルを使う。

・モデルを使って結果をシミュレートする。

・実際の結果と照らし合わせてモデルを調整する。

病んだ政治
・いつでもクビを賭ける覚悟が必要である。

・しかし、それでも病んだ政治の影響を受けないとは限らない。

・病んだ政治はどこにでも、最も健全な組織にも出現する可能性がある。

・病んだ政治の決定的な特徴は、個人の権力と影響力の目標が、組織の自然な目標より優先されることである。これは、病んだ目標が組織の目標と相反する場合でも起こりうる。

・病んだ政治の副作用の一つは、少人数のプロジェクトを抱えることが危険になることである。

測定基準
・すべての製品のサイズを測定せよ。

・単位を気にするな。客観的な尺度ができるまでの間は、主観的な単位を使えばよい。

・手に入るすべての基本要素（ソフトウェアの数量化可能な特徴）をもとに合成尺度を作成する。

・考古学的データを収集し、これまでに完了しているプロジェクトから生産性の傾向を算出する。

・合成尺度の公式をいじり、その値と、考古学データベースのプロジェクトの労力の相関関係が最良になるポイントを見つける。

・過去のデータベースをもとにトレンド・ラインを引き、予想される労力を、合成尺度の値の関数として示す。

・つぎに、予想を立てるべき新規プロジェクトのそれぞれについて、合成尺度の値を計算し、それを使ってトレンド・ラインから予想される労力を割り出す。

・生産性トレンドのノイズのレベルは、予測を立てるときの誤差の目安にする。

プロセスとプロセス改良
・優れたプロセスと、プロセスを絶えず改良することは、立派な目標である。それらはまだ、ごく自然な目標でもある。優れた技術労働者は、指示があろうとなかろうと、それらに焦点を当てる。

・形式的なプロセス改良プログラムには時間と金がかかる。一つのプロセス改良プログラムのために、プロジェクトが交替することもありうる。生産性の向上が実現したとしても、そのプログラムを受け入れたプロジェクトでプロセス改良の為に費やされた時間を相殺できる可能性は低い。

・プロセスは、注意深く選んだ一つの手順改良によって、その変更に投資した時間と金に報いるだけの利益を期待できることがある。

・プロジェクトの期間中に二つ以上の手順改良に順応することは、現実には期待できない。複数の技能改良プログラム（たとえば、全般的なＣＭＭ等級の引き上げ）は、プログラムを実施しなかった場合に比べ、プロジェクトの完成を遅らせる可能性が非常に高い。

・標準的なプロセスの危険な点は、人々が賢明な省略を行う機会を失わせることである。特に、人員過剰のプロジェクトの場合、標準的なプロセスによって全員に行き渡るだけの仕事（役に立とうが立つまいが）が発生するなら、標準的なプロセスが厳密に守られてしまう。

仕事のやり方を変える
・デバッグの時間を大幅に減らさなければ、プロジェクトの成績を通常より大幅に高める方法はない。

・優れたプロジェクトは、デバッグに費やす時間の割合がはるかに低い。

・優れたプロジェクトは、設計に費やす時間の割合がはるかに高い。

・相手を好きになり、気遣わなければ、人に違うことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない。

プレッシャーの効果
・プレッシャーをかけても思考は速くならない。

・残業時間を増やすのは、生産性を落とす方法である。

・一時的なプレッシャーや残業は、人々の商店を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。

・管理者がプレッシャーを使うことが多いのは、ほかになにをすればいいのかわからないから、または、ほかの方法の難しさにひるんでいるからである。

・おそるべき推測：プレッシャーや残業を使うほんとうの理由は、プロジェクトが失敗したときにごまかすためかもしれない。

怒れる管理者
・管理者の怒りと侮辱は伝染する。上の管理者が怒鳴ると、下の管理者も同じような行動をとる（虐待された子供が自分の子供を虐待するようになるのと同じ）

・管理者が部下を侮辱すると、それが刺激となって部下は自分の仕事にされに力を注ぐと思われている。これが、「飴とムチ」式管理で最もよく使われる「ムチ」である。しかし、侮辱によってだれかの業績がよくなるという証拠はあるのか。

・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。

あいまいな仕様書
・仕様書があいまいなのは、システムの利害関係者の間で対立が解決されていないしるしである。

・入出力の完全なリストのない仕様書は、見込みなしである。使用を明確にする最初の一歩にもならない。

・仕様書がお粗末だとはだれも言わない。自分のほうが悪いのだと思い込みがちである。

対立
・開発に複数の当事者が関わっている限り、利害の対立は避けられない。

・システムの構築と導入の事業には、特に対立が多い。

・システム開発組織のほとんどは、対立解決能力に乏しい。

・対立は尊重すべきである。対立はプロらしくない行動のしるしではない。

・全員の勝利条件を尊重することをあらかじめ宣言しておく。あらゆるレベルで勝利条件を引き出すようにする。

・交渉は難しい。仲裁は簡単だ。

・勝利条件が相容れないか、または部分的に相容れない場合でも、関係者が対立解決の為に仲裁に移行するように、あらかじめ準備しておく。

・注意：われわれは味方どうしである。敵は問題そのものだ。

触媒の役割
・触媒のような人格というものがある。そのような人は、チームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒がほかになにもしなかったとしても（通常はほかにもいろんなことをするが）、触媒の役割は重要で貴重である。

・仲裁は、触媒の役割の特殊なケースである。仲裁はわずかな投資で学習できる。

・「あなたたちの仲裁をさせてもらえますか」というささやかな儀式の開始が、対立解決の本質的な第一歩になることがある。

人為的なミス
・致命的なのは知らないことではない……知っているつもりで、実は知らない何かだ。

スタッフの人数
・初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるをえない（全員に仕事を与えるため）。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。

・このため、相互依存性が高まり、会議が増え、やり直しが増え、フラストレーションがたまる。

・理想の人数配分は、プロジェクト器官の大部分を少人数のコア・チームで行い、プロジェクトの終盤（プロジェクト器官の最後の６分の１ぐらい）に人数を大幅に増やすというものである。

・おそるべき推察：無茶なスケジュールを達成するように決められたプロジェクトは、妥当なスケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。

プロジェクトの社会学
・会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである。

・プロジェクトには儀式が必要である。儀式は、小規模な会議や無欠点運動など、プロジェクトの目標と理想に目を向けるために使う。

・罵倒などの怒りから人々を守るために手を打つ。

・注意：怒りは恐怖である。部下に対して罵倒などの怒りの行動をとる管理者は、ほとんどの場合、怖いからそうしているのである。

・考察：怒りが恐怖であることをすべての人が理解すれば、怒りは、怒っている人が怖がっていることを明確に示すシグナルとなるだろう。起こっている人は、恐怖を表に出したくない。つまり、怒りが恐怖の表れだとみなにわかってしまったら、怒りを吐き出すこともできなくなる（これは怒っている人の問題は解決できないが、ほかの人の悩みは軽減できるだろう）。

病んだ政治（再び）
・病んだ政治を下から治療することはできない。むだな努力で時間を浪費したり、自分の立場を危険にさらす必要はない。

・問題が自然に解決するか、行動するチャンスが来るのを待つしかない場合もある。

・奇跡が起こることもある（だが、あてにしてはいけない）。

倹約精神
・倹約精神とは、失敗した企業の中で、その失敗の責任者が作った公式である。

・それは、組織の自然な目標である繁栄と福祉の精神とは正反対である。

・「倹約精神」という言葉を聞いたら、その本当の意味である「失敗と恐怖」に置き換えるといい。

急進的な常識
・プロジェクトには目標と予想の両方が必要だ。この二つはちがっていて当然である。

[Escさんの感想 · 2015年1月11日]

ウォーターウォールしかなかった頃のプロジェクト管理者の考え方が学べる本。
101の法則は普遍性もあり、今の時代の仕事にも取り入れることができそう。

ただ、小説部分は作者が書きたいように書いただけと感じてしまい、あまり楽しめなかった。
小説部分がイマイチなせいで、101の法則の説得力も減じているように思う。