投稿元:
レビューを見る
実体験に基づいているという意味では有益なのかもしれないけど、本としての価値はどうなの?という内容。
経験豊富なのはわかるけど、実体験がこうだったから、こうすべきだって言われてもねえ…理論としてのプロジェクトマネジメントと紐付ける部分が欠落し、エンジニアリングになっていない点がこの本の問題なのかも。
投稿元:
レビューを見る
国鉄時代の座席予約システムなど日本を代表するような大規模なシステム開発プロジェクトをまとめてきた著者が書いた、非常に役に立つ実践的なプロジェクト管理の本で、涙が出るくらいためになります。
著者のプロジェクト管理方針が随所に感じられます。
投稿元:
レビューを見る
3月30日読了。日立社にて旧国鉄のシステムのPMなどを手がけた著者が自体験からとく、実践的なプロジェクト・マネジメントの「コツ」やあらかじめ想定しておくべき問題、手を打つ際のポイントなど。お題目ばかりのPM論ではなく、実際の現場でどのようなことを想定し、どう動くと有効か(有効だったか)について説かれており、参考になる。システムというものが抱える特性(システム化しないことが最高の業務効率化/顧客にもベンダーにも「あるべき姿」は見えないもの/立ち上げ当初の労を惜しみ、手を動かすことから着手しがち、など)によりプロジェクトの発足当初から「曖昧さ」を抱え、またその曖昧さを参加当事者たち自身が自明のものとして認識してしまい、とかく「走りながら考える」「後になって火を噴いて後悔する」事態に陥りがちなものだが。打てる手は事前に打っておくべきだし、それがPMの仕事であり醍醐味なのだな。
投稿元:
レビューを見る
プロジェクトマネジメントを学習する際に役立つ一冊。
著者は国鉄時代のマルス(みどりの窓口)鉄道予約システムを成功させた。実体験からのプロジェクトマネジメントをまとめてある。プロジェクトには必ず曖昧な部分があるので、それをどうコントロールしていくかというところを考えさせられた。
投稿元:
レビューを見る
JRの「みどりの窓口」を開発を担当し、その後も多数のプロジェクトを経験した著者によるプロジェクトマネジメントの解説本
受注、見積、開発、顧客との信頼関係と解説していくが、「体験的プロジェクトマネジメント論」と書かれているとおり筆者の体験や感想、教訓が各フェーズで記載されている。システムの開発工程をひととおり体験しており、システム開発の困るポイントを押さえている人が読むと教訓やこうすべきと書いてある内容が理解できるけど、システム開発をやったことのない人が読んでも実感が湧かないだろう。
逆にシステム開発で困っている人にとっては筆者のノウハウがてんこ盛りなのが嬉しい。考え方の整理やノウハウのいいとこどりができる。特にシステム提案、見積、契約、受注は上流工程を仕切るPMには重要な工程だが、このあたりを詳しく説明してくれる本は少なく貴重な一冊である。特に「顧客にも同じ船に乗ってもらう」と称して顧客との信頼関係の構築に章を割いているのがPMBOKなどのきれいごとの論理だけでなく顧客や設計者と渡り合わなければならない現場PMの実感を表わしている。他に修羅場となったプロジェクトを担当した経験が多いせいか、デスマーチとなったプロジェクトからの対処法も各工程の中で説明されている。
『真の理解は「心で理解する」こと』とか、『工程とは承認するものではなく指示するもの』、といった精神論に近い内容も散見されるが、当事者として一人称で考えると納得できるものが多い。
プロジェクトの受注前の段階で悩んでいたり、デスマーチからどう抜け出すかを模索しているPMにはおススメしたい。また、PMはどのように考えているのかを知りたい人にもおススメ。
結びに代えてで『前向きに粘り強く、泥沼をかき分けて』とか、『命をとられるわけではない』と書いているが、これがスマートさよりも何が何でもシステムを稼働させようと考えるITゼネコンの日立らしい発想だなあ、と感じた。
投稿元:
レビューを見る
結びに代えて、が役に立つ。遭遇してしまった危機にどうしたらよいかについての著者の提言。"Muddling through" 「泥の中を通り抜ける」か、、、。良い言葉!
投稿元:
レビューを見る
ITプロジェクトの三大業病、「仕様の曖昧性」「仕様の変動性」「仕様の膨張性」の原因分析と、その対応についてわかりやすく書かれた本。歴戦のプロジェクトマネージャーの経験から多くの知見を学べます。
投稿元:
レビューを見る
これは設計開発、特にソフトウェア開発を行う人にとっては必ず読んでいただきたい本です。開発プロジェクトを実行する上で意識すべきエッセンスが網羅されています。