あるあるネタ集という感じ
2017/01/20 09:30
0人中、0人の方がこのレビューが役に立ったと投票しています。
投稿者：ルイージ - この投稿者のレビュー一覧を見る
他の人のレビューにもあるけど、失敗プロジェクトにデスマーチという名称を付けて広めた功績はあるとしても、いろんなあるあるネタ集になっていて、その対策や解決策については後世に委ねているので、これを読んで溜飲を下げても現実はなんにも変わらない。勉強になる類の本ではない。
デスマーチ・プロジェクトを乗り切るために
2010/01/07 01:42
2人中、2人の方がこのレビューが役に立ったと投票しています。
投稿者：御於紗馬 - この投稿者のレビュー一覧を見る
著者は「デスマーチ・プロジェクトとは『プロジェクトのパラメータ』が正常値を50％以上超過したもの」と定義しています。要は時間や人間、資金などの資源が完成させるための半分以下しかないのに「やれ」と言われている状態です。
こんな無茶ぶりが発生するのは何故か、どんな人物たちが登場しているのか、著者は検討します。そしてどこが折中ポイントか（完全な完成は不可能ですから）つぶさに解析し、勝機を見出していくのです。
ＩＴ業界向けの本になっていますが、他業界でも通じるものがあると思います（特に、日本の企業は内部的にはデスマーチ・プロジェクトではないでしょうか？）。
ただ目の前の仕事を淡々とこなすだけではデスマーチ・プロジェクトは乗り切れません。好む好まざるに関わらず政治は巻き込まれますし、最悪、退職を迫られる事もあるかもしれません。
確かに日本独自の問題もありますが、指針として非常に優れています。特に技術書というわけでもなく、ＩＴ業界の人じゃないと解らないという事もないので、ビジネス書として普通に読めると思います。
今を生き抜くために役立つ一冊です。
投稿元：
レビューを見る
なんか読んでいて「ですマーチになるくらいならさっさと辞めよう」という匂いがぷんぷんして、それはそれで楽しかったり。私はIT業界の人ではないので、なるほどこうやって死屍累々となるのか、と興味深く読みましたが、よく考えればIT業界に限らず様相はどこでも一緒だったり…orz
投稿元：
レビューを見る
ソフトウェア開発の現場がどうしてこんなに混乱するのか、がよく分かる気がする本です。身につまされます。
投稿元：
レビューを見る
結局のところ「銀の弾丸は存在しない」。どうしても抽象的な話になる。しかし、学んだ単語もある「トリアージ(triage)」だ。本書に上げられているようにデスマーチの発生要因は多々あり、多分防ぐことは出来ないのだろう。
投稿元：
レビューを見る
http://blog.setunai.net/20060707/%E3%83%87%E3%82%B9%E3%83%9E%E3%83%BC%E3%83%81-%E7%AC%AC2%E7%89%88/
投稿元：
レビューを見る
翻訳が読みにくい、ひどい、読むのなら原本を読むべき。知的労働者にとって職場環境の良し悪しが、生産性を左右する。（図書館）
投稿元：
レビューを見る
トリアージを覚える。やる事・タスクについて、Must Do、Should Do、Could Doの3種類に分類する。
20:80の法則で20％の完成部分で要求仕様の80%を満たせる。。しかしこれは言いすぎかなと。。
あとポストモーテム(事後分析)が大事と。プロジェクトを主要メンバーと振り返って品質、財務、プロセス改善、教育などが上手くいき、予算の範囲内で利益をきちんと生み出したかを確認する。
投稿元：
レビューを見る
火を噴いたプロジェクトに入った時に，「これって俺たちのことじゃないか？」と先輩に教えてもらった本．お酒飲みながら，ゲラゲラ笑って読んだのも，今では良い思い出です．
投稿元：
レビューを見る
現在、デスマーチ案件に関わっているので、なにかしらのヒントを求めて買ってみた。
この本を読んでわかったことは、デスマーチはたまたま発生するのではなく、ほぼ恒常的に発生するということ。そ
今までは、管理者の管理能力不足だけがデスマーチ発生の原因と思っていたけど、プロジェクトの内部や外部を問わず、政治的な要因が大きく関わっているのがわかった。
本書では、デスマーチ発生に至るまでの過程を分析し原因を解き明かしている。そして、デスマーチに対して、どう接していけばいいかを説明している。
デスマーチ解決法という内容ではないが、共感できる部分が多い。
この本で、おおよその原因を知っておけば、デスマーチを未然に回避したり、失敗を軽減したりすることが可能かもしれない。
邦訳がよく、読みやすい内容だと思うので、IT業界にかかわる人は新人ベテラン問わず、ぜひ読んでほしいと思う。
投稿元：
レビューを見る
和訳特有のヘンな日本語の言い回しに、終始ギクシャクしたかんじ。 ナニが趣旨だったか、ナニを感じ取ればいいのか漠然としていて、つかれました…。 この本がデスマーチな雰囲気でしたよ。 読まなくてイイです。
投稿元：
レビューを見る
たぶんプロジェクト経験後に読むべき本だったのでしょう。
とりあえず、IT系プロジェクトは覚悟して取り組もうと思った。
ただ、この本は海外(アメリカ？)でのことであり、日本でもこのまま当てはまるのかは疑問だった。デスマーチから逃れるために、仕事を簡単にやめても良いというスタンスは日本でも実行出来るのか…？
投稿元：
レビューを見る
まずはITベンチャーのリスクを知っておくためにデスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのかを学習させました。この本はIT系の人間からすると耳が痛いことが山ほど書かれており、それを意識して組織を作るか耳をふさぐかで大きな違いが出ると思ってます。
投稿元：
レビューを見る
書いていることは事実をある視点で記述しているのだと思います。
解決策は、それぞれの現場で違うので、自分達で考えるしかありません。
現場の感触としては、能力のある人間にやる気を与えて仕事をした結果を、
どうお金に変えるかの手腕が経営者や営業にあるかだと思っています。
そういう手腕のある人でも、手腕があるが故に、仕事量が１０倍、１００倍になったときに、対応方法を誤ることがあるように思います。
万能の解決策はないということではないでしょうか。
少なくとも、
１ 有能な技術者を組織する（やる気にさせる）
２ お金を支払う顧客を捜してくる
の２つができれば、大丈夫なのではないでしょうか。
割とありがちな問題と、割とありがちな解決策が体系的に書かれているので、時間があるときにのんびりと読むとよい。くれぐれも、デスマーチプロジェクトの時には読まない方がよいと思った。こまっているときには、原因を解決する方法か、対策が大事で、ありがちな解決策では解決しない。それは、公式プロセスの導入という、デスマーチプロジェクトに適用してはいけないと本書で書いていることと同じではないだろうか？
投稿元：
レビューを見る
一時間ほど時間があったので図書館にて。あまり面白くなかったので、途中まで。タイトルだけ追って見た。まぁ、関わりたくは無いわな。
