システム開発

システム開発

タイトル	著者	出版社
デッドライン	トム・デマルコ	日経ＢＰ

「デッドライン」

トム・デマルコ／日経ＢＰ

・わたしが尊敬してた管理者を振り返ってみると、みんな家のように大きな心を持ってたわ。リーダーシップの本質は心にあるの。頭でっかちの「リーダー」でも指揮はとれるけど、人はついてこない。

・わたしたちが求めているのは、世界を知ったらそれを変えていく、自分や部下がめざしているものに合わせて変えていくという意識を持っている管理者よ。

・リスク管理
（１）リスクを管理することによってプロジェクトを管理せよ。
（２）プロジェクトごとにリスク調査の方法を確立して継続せよ。
（３）最終的な望まざる結果だけでなく、日常のリスクに注意せよ。
（４）それぞれのリスクの実現する確率と予想コストを評価せよ。
（５）リスクが現実になる前の初期の兆候を予測せよ。
（６）やる気のある態度を常に引き出そうとしない人物をリスク管理人に任命せよ。
（７）悪い話が上層部に伝わりやすい経路（匿名性など）を造っておくこと。

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

・開発プロセスのモデリングとシミュレーション
（１）仕事を完成させるプロセスに関する直感をモデル化する。
（２）仲間との対話の中で、プロセスの進行に関する考えを伝えたり修正したりするためにモデルを使う。
（３）モデルを使って結果をシミュレートする。
（４）実際の結果と照らし合わせてモデルを調整する。

・プロジェクトの人数を増やしても時間を節約できるとは限らないということです。問題は、吸収率の効果というものがあって、チームが開発できる速さは決まっているのです。それを速めようと圧力をかけると、良くなるどころか悪くなります。それに、相互作用による損失があるので、チームにｎ番目のメンバーを加えると、その前にメンバーを加えたときより効果は薄れます。

・人数を増やしすぎることがプロジェクトにどんな悪影響を、どれくらい、どんなふうに与えるのか、とても正確にわかるだろう。

・こちらが嫌悪感を見せたら、相手はこちらの希望を聞いてくれないだろうということですね。

・好きじゃない人間を説得することなどできない。

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

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

・仕様書にはっきりしない部分があったら、対立があるんじゃないかと探ってみることにするわ。

・まず、実はお互いが敵同士じゃないんだと認識させてやることだね。「きみたちは味方同士なんだ。敵は問題そのものなんだ」と指摘してやることだ。

・初期に人数を増やしすぎることが実はまともな設計を妨げるのだということを何度も考えていた。

・恐れていたから怒りを見せたんだよ。怒りは恐怖だ。

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

［to MAIN］