あらすじ
チームの結束力を強め、ソフト開発プロジェクトを成功させる秘訣とは。
『ピープルウエア』の著者トム・デマルコが、小説の形を借り、設計とデバッグの関係、プロジェクトの測定単位、プレッシャーの是非など、複雑に絡み合う要因を取り上げながら、プロジェクト成功の極意をわかりやすく伝授します。第8回Jolt AwardsのProductivity Award受賞。
感情タグBEST3
Posted by ブクログ
少し変わった立場に立たされた主人公による、プロジェクト管理の経過を小説タッチで描いているのがこの一冊です。
私個人的には、ここに出てくる女性たちが良い味を出していて好きです。
Posted by ブクログ
システム開発のプロジェクト管理やマネージメントをする架空の物語。
おそらく架空の物語だから、内容の割には読みやすくすんなり入ってきやすい。
実際使う場面が出てくるかわからないが、納期に追われるプロジェクトを担当した際には読み返してみたい。
Posted by ブクログ
全てのプロジェクト管理者はこの本を読むべきだ。管理者だけでは無くソフトウェア開発に関わる経営者もだ。プロジェクトを成功させたいと思うのならこの本で得られる教訓は間違いなく役に立つ。
Posted by ブクログ
【すー】 フィクションのストリーを交えつつ、チームのモチベーションを維持する方法、残業やプレッシャーは悪だという理由など。サクセスストーリー仕立てで、読みごたえはライト。SEL以上には、読んで欲しい一冊。残業削減を目指す転機となった、心のバイブルです。
Posted by ブクログ
トム・デマルコを知るきっかけとなった1冊。
そりゃ、ご都合主義だとか色々批判もあるだろうし現実的じゃないけれど。いいじゃない、お話だもの。
少なくとも私は、この本を読み返すたびにワクワクして、仕事に対するやる気が出る。
理想の状態に近づくためには、まず最高のものを思い描けなければ。
Posted by ブクログ
買ってつんどくでした。
次に読んだときは，１０１の法則は読み飛ばしていました。
3度目に書評を書こうと思って読んだら、予想以上に面白かった。
最初の失業する人を、スパイが掠うという設定から度肝を抜かれました。
最後に幸せになる（ハッピイエンドな）ところがすごくよかったと思いました。
ソフトウェア開発者が幸せになるための一つの筋書きとして面白いと思います。
教訓はあくまでも読み取るもので、教えてもらうものではないかもしれません。
作業書（ワークブック）形式にして，経験だけ書いて，
教訓を各自で考えてみる形式にすると面白いかもしれません。
その後で，著者の教訓とのずれの原因としての制約条件の違いを検討するのはどうでしょうか。
Posted by ブクログ
私がプロジェクトマネジメントに興味を持つきっかけになった一冊。
小説仕立てで読みやすくプロジェクト管理の本質を学べる本です。
ソフトウェア開発だけでなく、小は現場のチーム運営から大は事業単位のプロジェクト運営にも役立ちました。
Posted by ブクログ
ストーリ仕立てで、その時々の出来事の中で学んだこと、感じたことを日記として記していく。
その日記が１０１の法則として現れる。
ストーリー仕立てなこともあり、とても頭に入ってきやすい。小難しい理論もない。
プロジェクトを評価するきっかけを与えてくれる良書だと思う。
Posted by ブクログ
ストーリー仕立てでプロジェクト管理の本質を説いた作品。
ストーリーは、架空の国モロビアに
ソフト開発の管理者である主人公が拉致されて、
国家プロジェクトのソフト開発の管理をさせられるというもの。
話はかなりぶっ飛んでいるんですが、
その過程で、管理についての様々な法則を導きだし、
管理についての法則をまとめていくという
至って真面目でタメになる内容でした。
作品自体は小説のようにサクサク読めて、
それでいてめちゃめちゃ面白い。
トム・デマルコの作品は初めて読んだんだけど、
言っていることはものすごく的を射ていて、
「うんうん」と納得しながら読み進められました。
私たちのような知的生産に関わる者としては、
いつの日か会社の総務や営業の方が、
この本の内容を理解してくれる日が来るのを
切に願います。
Posted by ブクログ
ある解雇されたソフトウェア開発が気がつけばソフトウェアで国を興そうという某国のプロジェクト管理者にされていた。
恵まれた環境、幾つかの実験、不意のトラブルの中であるべきソフトウェア開発のコツを見出していく・・・
プロセスでも技法でもない方法でソフトウェア開発を変えようとする著者デマルコが、小説風に示唆とユーモアたっぷりで送る一冊。
こんなに楽しくためになる技術関連書ってまたとないのでは。
Posted by ブクログ
本書では、主人公トムキンスが旧ソ連のモロビア共和国でソフトウェア・プロジェクトを運営するという物語を通して、プロジェクト管理の教訓を分りやすく示しています。
内容的には、大規模プロジェクトで陥りがちな問題に対する初・中級者向けの教訓が中心となっています。
ただ、これまでの自分の常識が覆されるような目から鱗の事実も多く含まれており、小規模プロジェクトの経験しかない私でも大いに共感と収穫がありました。
何より物語自体が楽しくて、一気に読み終えてしまった程で、ぜひ会社の同僚にも勧めようと思っています。
論理的に論じられている指南書も確かに有用ですが、本書のような物語仕立てでの構成の場合、感覚的にノウハウを吸収できるため、特に初心者には非常に有効だと思いました。
ほんとにオススメです！
しばらくは著者の本を読み漁っていこうと思います。
Posted by ブクログ
◼️読んだ動機
Twitterで名著と言っている人がいて気になり読んだ
◼️感想
小説チックに書いてあり、各章の最後にその章のまとめのような文章がある形式だった。
小説の方は、あまり頭に入ってこず流し読みになったが、まとめの文章にはいいことが書いてあることが多く為になった。
◼️以下よかった箇所のまとめ
4章 正しい管理の4つの本質
- 適切な人材を雇用する
- その人材を適所に当てはめる
- 人々の士気を保つ
- チームの結束を強め維持する
それ以外のことは管理ごっこ
変更はあらゆるプロジェクトほ成功のために必要不可欠である
リスクを避けることはそれに伴う利益を持つ逃すことになる
5章 支配者
どれほど強い脅しをかけても最初に割り当てた時間が足りなければやはり仕事は完成しない
7章 管理者の採用
戦闘が始まる中には、管理者の本当の仕事はもう終わっている
新しく採用した人材には、1回は実証済みの能力レベルのプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする
8章 リスク管理と生産性
- 短期的に生産性を高める方法などない。生産性は長期的な投資によって向上する
- 短期的な効果を約束するものは、インチキである可能性がたかい
- リスクを管理することによってプロジェクトを管理せよ
9章 人材管理の智将
- 成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる
- 1日を無駄にする方法はいくらでもある…しかし1日を取り戻す方法は1つもない
11章 理想と現実
- 開発者を増やせば開発スピードが上がるわけではない
- 大人数のチームより、少人数のチームのほうが成果を上げる場合は多くある
- が、政治が蔓延ると少人数のチームは存続できない
14章 設計とデバッグの関係
- 優れたプロジェクトは、デバッグに費やす時間の割合が遥かに低い
- 優れたプロジェクトは、設計に費やす時間の割合が遥かに高い
15章 残業の効果
- プレッシャーをかけても思考は早くならない
19章 プロジェクトの人数
- 初期に人数が多すぎると、プロジェクトは（全員に仕事を与えるため）重要な設計作業をえない
- 設計が感染者する前に大勢に仕事を割り当てると人や作業グループ間のインターフェースを最小化できない
- このため、相互依存が高まり、会議が増え、やり直しが増え、フラストレーションがたまる
- 理想の人数配分は、プロジェクト期間の大部分を承認図のコアチームで行い、プロジェクト終盤に人数を大幅に増やすというもの
- 無茶なスケジュールのプロジェクトは、妥当なスケジュールのプロジェクトに比べ、完成までに時間がかかる
23章 101の教訓
- プロジェクトには目標の予想の両方が必要だ。この二つは違っていて当然である
Posted by ブクログ
プロジェクト管理の勉強をしようと手にとった本ですが、思ったよりも小説寄りでエンターテイメントでした。プロジェクト管理にまつわる人間関係洞察は確かになと思いました。それ以外の技法についてはとくに学べませんが、読んでるうちに感情輸入してベロックにイラついてしまうくらい面白かったです。
Posted by ブクログ
2006年に一度読んだことがあるみたいだが記憶になかった。2016年に再読。プロジェクト管理をそこそこしてきた今だから納得できるし発見がある、読んでよかった。トムキンス、ラークサー、NNL、ベリンダ、無理矢理な導入と結末。
・正しい管理の本質、適切な人材を適所にあてはめ人々の士気を保ってチームの結束を強め維持する。
・リスクを管理することによってプロジェクトを管理せよ。
・プレッシャーをかけても思考は速くならない。
・管理者の怒りと侮辱は伝染する。
・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
・入出力の完全なリストのない仕様書は、見込みなしである。
・理想の人数配分は、プロジェクト期間の大部分を少人数のコア・チームで行い、プロジェクトの終盤に人数を大幅に増やすというものである。
・会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである。
・プロジェクトには儀式が必要である。
・病んだ政治を下から治療することはできない。
・倹約精神とは、失敗した企業の中で、その失敗の責任者が作った公式である。
Posted by ブクログ
物語形式で展開される、とあるソフトウェア開発の物語。
さまざまな出来事により、プロジェクトマネジメントの要衝のおさえかた、実行の仕方、ものごとの進め方を学べる一冊でした。
読者がソフトウェア開発プロジェクトに関与しているなら、とても共感できる部分が多いと思います。
たとえば残業時間と生産性の話や、無駄な会議を減らす方法など。
また私自身、自分の経験をうまくあらわせなかったことが整理されていて役立ちました。特に設計段階は少人数で進め、製造で一気に人を投入するあたりは、うまくいったプロジェクトでも同じでした。頭を使うフェーズは、人が多すぎると「船頭多くして・・・」になりかねないと再認識です。
唯一、試してみたいけど怖くてできなさそうなのが、設計時間を圧倒的に費やし、設計段階でバグを潰すという考え方。これ、実際にやったら、ものすごいプレッシャーになると思います。だけど、クソみたいな設計で製造に入るよりも、きちんと机上で言葉で考えぬいてからのほうがいいんだろうなあという共感はできました。
Posted by ブクログ
物語とともに教訓を得られるため、非常に分かりやすかった。
気づきのあった言葉をいくつか。
「日常のリスクに注意せよ」
日常のリスクに気づくために、KPT法を使うのは、非常に有用ですね、やっぱり。
「変更はあらゆるプロジェクトの成功のために必要不可欠である」
改善、改善ですね！
「入出力の完全なリストのない仕様書は、見込みなしである」
これ、妥協しないように気をつけないと。
Posted by ブクログ
ウオータフォールの管理者が主役の話。自分の目指しているとことじゃないから受け入れがたい点もあるが、でも、製品開発の手法としてはスタンダードだし取り入れたいと思う。
人に焦点をあて、その対策法などを具体的に議論している点はおもしろい前職のプロジェクトを思い出しながら読んでいた。
怒れる管理者の心理、政治の話、スケジュール、プレッシャーなどなど。
Posted by ブクログ
物語調で、実際のITプロジェクトの「あるある」問題と、解決方法をアメリカンジョークな世界観で表現。仕事で疲れ気味のSEが息抜き代わりに読むといいかも。
Posted by ブクログ
ある日突然、全く知らない組織で巨大プロジェクトを任せられることになった主人公の悪戦苦闘ぶり。「管理は脳でやるものじゃない。腹、心臓、魂でやるものよ」
Posted by ブクログ
分野としては管理工学でしょうか。プロジェクト管理の教科書ですが、内容が小説仕立てなので、要点を抽象的なモデル事例として学べるので、初学者に最適だと思います。
Posted by ブクログ
ソフトウェア開発プロセスを、小説仕立てで語っている。なので、読んでいてとてもおもしろい。
ただ、物語の舞台が非現実的かなーと思った。というのも、自分のような一介のエンジニアには、到底想像もできないようなプロジェクト規模だから。
でも、もしかしたら世の中には、物語の舞台と似たようなプロジェクトを管理している人はいるのかも？（きっといるよね）
本の内容については、自分のようなエンジニアでも直面したことある、もしくは直面しそうな事象を取り上げている。事実、自分でも「あー、こんなことあったなー」とか、「自分のことだ・・・」とか思うような内容だった（逆に、こういうことに直面するのは自分だけじゃない、ある意味、正常なことなのかもと思ったが）。
特に、15章以降は、多くのエンジニアが直面したことのある話題ではなかろうか。主人公がメモっていることは、画期的な解決方法ではないにしろ、きっと参考になると思う。
出版された当時と比べて、今はいろいろな管理・開発手法が生まれて、そして流行っている。しかし、多くの人が直面するプロジェクトの問題点の本質的な部分は、今も昔も変わらないんだと思う。
そういった点を踏まえ、この本で学べることを、現在主流の管理・開発手法でいかにして解決を図るかというアプローチが、この本の良い使い方なのかなあと思う。
プロジェクト管理者でなくても、ぜひ、一読していただきたい。読み始めたらとまらないはず。
ちなみに、物語の最後でほろっとした。
Posted by ブクログ
どうやったらプロジェクトが成功するのか？を小説仕立てで気持ちよく読ませてくれる本。人が多くてもプロジェクトは頓挫するとか、プレッシャーを与えても効率は上がらないとか、なかなか示唆に富んだ本。
Posted by ブクログ
システム開発で起こる問題や課題とそれに対する考え方や心構えをストーリー形式で学べる本。
ストーリーは若干、非現実的だけど「PJあるある」がチリばめられているので参考になるとは思います。
Posted by ブクログ
信頼する某SEの方からお薦めいただいた著書。プロジェクトマネジメントの要諦を小説仕立てにで教えてくれる。直観的にそうなんだろうなあというポイントがまとめられている。ただし、作り話であり、かつ、小説の中身もやや抽象的なため、実感がわきにくいのが残念。
・正しい管理の四つの本質
適切な人材を雇用する。
その人材を適所にあてはめる。
人びとの士気を保つ。
チームの結束を強め、維持する。
・変更は、あらゆるプロジェクトの成功のために必要不可欠である。
・人は安全だとわからないと変更を受け入れない。
・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。
・管理者は心、腹、魂、鼻でやるものだ。
心で指揮をとる。
自分の腹を信じる。（直感を信じる）
組織に魂を吹き込む。
くだらないものを嗅ぎ分ける鼻を持つ。
・優れたプロジェクトは、デバッグに費やす時間の割合がはるかに低い。
・優れたプロジェクトは、設計に費やす時間の割合がはるかに高い。
・相手を好きになり、気づかわなければ、人にちがうことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない。
・プレッシャーをかけても思考は速くならない。
・残業時間を増やすのは、生産性を落とす方法である。
・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
・仕様書があいまいなのは、システムの利害関係者の間で対立が解決されていないしるしである。
・仕様書がお粗末だとは誰も言わない。自分の方が悪いのだと思い込みがちである。
・会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである。
・プロジェクトには目標と予想の両方が必要だ。この二つはちがっていて当然である。
Posted by ブクログ
解説書のようなものかと思っていたら小説のようだった。プロジェクトに起こる様々な問題について、主人公たちが考察した上で名言としてまとめられていくスタイルで、読みやすかった。
自分が今まで経験していたプロジェクト管理について思っていたことが、この本で明確に言語化されたように感じた。
Posted by ブクログ
うーん、結果、ソフト開発に王道無しといったところかな。結局想定通りプレッシャーの問題、どうすれば高品質を保てるか、納期を早めるために、高品質を保っていたやり方を省略するなど、まあ、そうだよね、っていった所。ちょっと物足りない感があったが、身近な出来事に感じた。
