【感想・ネタバレ】デッドライン ソフト開発を成功に導く101の法則のレビュー

トムデマルコ / 伊豆原弓

チームの結束力を強め、ソフト開発プロジェクトを成功させる秘訣とは。
『ピープルウエア』の著者トム・デマルコが、小説の形を借り、設計とデバッグの関係、プロジェクトの測定単位、プレッシャーの是非など、複雑に絡み合う要因を取り上げながら、プロジェクト成功の極意をわかりやすく伝授します。第8回Jolt AwardsのProductivity Award受賞。

[ブクログ · ★★★★★]

買ってつんどくでした。
次に読んだときは，１０１の法則は読み飛ばしていました。

3度目に書評を書こうと思って読んだら、予想以上に面白かった。
最初の失業する人を、スパイが掠うという設定から度肝を抜かれました。

最後に幸せになる（ハッピイエンドな）ところがすごくよかったと思いました。
ソフトウェア開発者が幸せになるための一つの筋書きとして面白いと思います。

教訓はあくまでも読み取るもので、教えてもらうものではないかもしれません。
作業書（ワークブック）形式にして，経験だけ書いて，
教訓を各自で考えてみる形式にすると面白いかもしれません。

その後で，著者の教訓とのずれの原因としての制約条件の違いを検討するのはどうでしょうか。

[ブクログ · ★★★★★]

ある解雇されたソフトウェア開発が気がつけばソフトウェアで国を興そうという某国のプロジェクト管理者にされていた。
恵まれた環境、幾つかの実験、不意のトラブルの中であるべきソフトウェア開発のコツを見出していく・・・
プロセスでも技法でもない方法でソフトウェア開発を変えようとする著者デマルコが、小説風に示唆とユーモアたっぷりで送る一冊。
こんなに楽しくためになる技術関連書ってまたとないのでは。

[ブクログ · ★★★★☆]

◼️読んだ動機
Twitterで名著と言っている人がいて気になり読んだ

◼️感想
小説チックに書いてあり、各章の最後にその章のまとめのような文章がある形式だった。
小説の方は、あまり頭に入ってこず流し読みになったが、まとめの文章にはいいことが書いてあることが多く為になった。

◼️以下よかった箇所のまとめ
4章 正しい管理の4つの本質

- 適切な人材を雇用する
- その人材を適所に当てはめる
- 人々の士気を保つ
- チームの結束を強め維持する
それ以外のことは管理ごっこ

変更はあらゆるプロジェクトほ成功のために必要不可欠である

リスクを避けることはそれに伴う利益を持つ逃すことになる

5章　支配者
どれほど強い脅しをかけても最初に割り当てた時間が足りなければやはり仕事は完成しない

7章　管理者の採用
戦闘が始まる中には、管理者の本当の仕事はもう終わっている
新しく採用した人材には、1回は実証済みの能力レベルのプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする

8章　リスク管理と生産性
- 短期的に生産性を高める方法などない。生産性は長期的な投資によって向上する
- 短期的な効果を約束するものは、インチキである可能性がたかい
- リスクを管理することによってプロジェクトを管理せよ

9章　人材管理の智将
- 成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる
- 1日を無駄にする方法はいくらでもある…しかし1日を取り戻す方法は1つもない

11章　理想と現実
- 開発者を増やせば開発スピードが上がるわけではない
- 大人数のチームより、少人数のチームのほうが成果を上げる場合は多くある
- が、政治が蔓延ると少人数のチームは存続できない

14章　設計とデバッグの関係
- 優れたプロジェクトは、デバッグに費やす時間の割合が遥かに低い
- 優れたプロジェクトは、設計に費やす時間の割合が遥かに高い

15章　残業の効果
- プレッシャーをかけても思考は早くならない

19章　プロジェクトの人数
- 初期に人数が多すぎると、プロジェクトは（全員に仕事を与えるため）重要な設計作業をえない
- 設計が感染者する前に大勢に仕事を割り当てると人や作業グループ間のインターフェースを最小化できない
- このため、相互依存が高まり、会議が増え、やり直しが増え、フラストレーションがたまる
- 理想の人数配分は、プロジェクト期間の大部分を承認図のコアチームで行い、プロジェクト終盤に人数を大幅に増やすというもの
- 無茶なスケジュールのプロジェクトは、妥当なスケジュールのプロジェクトに比べ、完成までに時間がかかる

23章　101の教訓
- プロジェクトには目標の予想の両方が必要だ。この二つは違っていて当然である

[ブクログ · ★★★★☆]

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

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

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

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

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

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

[ブクログ · ★★★★☆]

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