エドワードヨードンのレビュー一覧
-
Posted by ブクログ
ネタバレ書いていることは事実をある視点で記述しているのだと思います。
解決策は、それぞれの現場で違うので、自分達で考えるしかありません。
現場の感触としては、能力のある人間にやる気を与えて仕事をした結果を、
どうお金に変えるかの手腕が経営者や営業にあるかだと思っています。
そういう手腕のある人でも、手腕があるが故に、仕事量が１０倍、１００倍になったときに、対応方法を誤ることがあるように思います。
万能の解決策はないということではないでしょうか。
少なくとも、
１ 有能な技術者を組織する（やる気にさせる）
２ お金を支払う顧客を捜してくる
の２つができれば、大丈夫なのではないでしょうか。
割とありがちな問題と、割とありがちな解決策が体系的に書かれているので、時間があるときにのんびりと読むとよい。くれぐれも、デスマーチプロジェクトの時には読まない方がよいと思った。こまっているときには、原因を解決する方法か、対策が大事で、ありがちな解決策では解決しない。それは、公式プロセスの導入という、デスマーチプロジェクトに適用してはいけないと本書で書いていることと同じではないだろうか？ -
Posted by ブクログ
現在、デスマーチ案件に関わっているので、なにかしらのヒントを求めて買ってみた。
この本を読んでわかったことは、デスマーチはたまたま発生するのではなく、ほぼ恒常的に発生するということ。そ
今までは、管理者の管理能力不足だけがデスマーチ発生の原因と思っていたけど、プロジェクトの内部や外部を問わず、政治的な要因が大きく関わっているのがわかった。
本書では、デスマーチ発生に至るまでの過程を分析し原因を解き明かしている。そして、デスマーチに対して、どう接していけばいいかを説明している。
デスマーチ解決法という内容ではないが、共感できる部分が多い。
この本で、おおよその原因を知っておけば、デスマーチを未然に回避したり、失敗を軽減したりすることが可能かもしれない。
邦訳がよく、読みやすい内容だと思うので、IT業界にかかわる人は新人ベテラン問わず、ぜひ読んでほしいと思う。 -
-
-
Posted by ブクログ
PMP資格更新に向けて読みました。
個人メモ用にですが、ざっくり要約すると下記の感じかと思いました。
・デスマーチプロジェクトは多種多様あるが、結局無理な納期やスケジュールのプロジェクト
・デスマーチプロジェクトに対する最も効果的な対処はトリアージする事
・もちろん状況によるが、新しいツールや手法を導入するより使い慣れたツールや手法をうまく活用する方が効果的
・デスマーチプロジェクトはどれだけ時代が進んでも無くならない
少しクセがある文章のため、所々流し読みした箇所もあります。読書の時間がとれず細切れに読んでいたため理解しきれていないと感じる箇所もままありました。できるのであればしっかりと時間を確保した上でまとめて読む方が向いている本かなと思います。
また時間がしっかり取れるタイミングでじっくりと理解しながら読みたいと思いました。
-
Posted by ブクログ
トリアージしよう。もっとも大切な要求、課題から手を付ける
【感想】
「デスマーチ」をキーワードにして、プロジェクトマネジメントのよもやま話をしていく本。主張は基本的なプロジェクトマネジメント原則と大差が無いかも。ソフトウェア開発プロジェクトの難しさを理解するために読むとよさそう。書き方はエッセイ的で、メッセージが掴みづらい。既にPMの知見が無いと、難しい。単純にシステム開発プロジェクトについて理解するなら、「システムを作らせる技術」の方が分かりやすい。各章ごとの「まとめ」を読んでから、本文を読んだ方が理解しやすい。勉強のために読むなら、読んだうえで自分で抽象化を試みた方が良さそう。
【本書を読みながら考えたこと、気になったこと】
問いを立てて読んだ方が良さそうな本。
■なぜ、デスマーチが起こってしまうのか
・正確に作業量を見積もることが難しい。見積もりより作業量が増えても、納期は後ろに伸びない
・時間的、資金的、人的な余裕がない。ソフトウェア開発プロジェクトはビジネスであり、より安く、早いサービスが求められる。市場競争の結果、コンペを勝ち取る際には、他社より少ない予算（人員）、より早いスケジュールでの計画実現を提示できたベンダーが、ソフトウェア開発プロジェクトを受託できる。結果的に、いつもギリギリの状態でプロジェクトはスタートする
・失敗が隠される。過去にソフトウェア開発プロジェクトでの失敗があっても、企業は体裁を守るために、できる限りその事実を隠そうとする
■デスマーチに巻き込まれたら、どうすればよいか
・トリアージする。優先順位をつけて、対応する。全ての問題に対応しなければ、何もかもうまくいかない、ということはない
●１章 はじめに
・デスマーチプロジェクトとは、プロジェクトのパラメータが50％以上超過している物
・通常であれ二人月かかるところを一人月でやろうとしている等
・デスマーチは、教育効果が大きい
・プロジェクトの作業量、難易度を正確に見積もるのが難しい。予想より多くの課題、作業が発生し、デスマーチとなる
●２章 政治
・ソフトウェア開発プロジェクトは、様々な立場の人の思惑に左右される
・顧客、プロジェクトマネージャー、出資者、顧客上層部等
●３章 交渉
・納期、人的リソースについて交渉しよう
・時には、PMとして、会社上層部に反旗し、プロジェクトメンバーを守ろう
・「見積もりが難しいのは、見積もりを現状と将来をベースにした最善の予測を」と解釈するため。これが、上層部においては、『厳守すべき値』に変わってしまう」
→見積もりは常に最悪を想定して行いたいな
●４章 デスマーチプロジェクトの人々
・残業時間が多すぎると、途中から生産性は低下し始める
・プロジェクトの成功には、優秀な人、チームとして機能すること、働きやすい職場環境が必要だ
●５章 デスマーチ・プロセス
・この本で一番大事な言葉「トリアージ」
・「80/20の法則」に従う。いくつかの項目は、永遠に実装されない。それを目指す。全てに手をつけていては、デスマーチプロジェクトは終えられない
・システムの要求項目は「must」「should 」「could」に分けよう。そそて、mustから手をつけよう
・要求管理をしよう
・そこそこ使えるソフトウェアができれば、それでいい
●６章 プロセスのダイナミックス
・もっとも生産性の高い人から辞めていく。好条件の求人など、いくらでも来る
・プロジェクト上で大切にする人や仕事の取り扱い方の考え方を、チームに共有しよう
●７章 クリティカルチェーンと制約条件の理論
・プロジェクトのボトルネック、クリティカルパスは確認して仕事を進めよう
●８章 時間の管理
・無駄なミーティングはするな
・利害関係者の意見が対立する → 承認が遅れることによって、スケジュールが遅れることを文書化して提示せよ
・緊急で重要度の高い仕事、緊急でないが重要な仕事をしよう。緊急だが重要でない仕事（電話応対）などに対応する機会を減らそう
●９章 進捗の管理と制御
・リスク、問題を整理し、管理し、評価し、対応方法を決めよう
・問題が多いデスマーチプロジェクトではなおさらだ。
・社内のプロジェクト後に、評価をしよう。同じ過ちは繰り返さないようにしよう
●１０章 デスマーチのためのツールと技術
・便利なツールは利用しよう。作業を標準化し、効率化しよう
●１１章 シュミレーションと「戦争ゲーム」
？メッセージが理解できなかった -
-
-
Posted by ブクログ
ネタバレ「デスマーチは常態」。うん。
お客さんから、いやむしろ経営者から、大げさに言うと半分の予算で！半分の人数で！半分の納期で！に「期待している」という言葉を添えて任される。
新しい技術、手法を取り入れてみる。誰もやったことない。つまりみんな新人と同じ。遅延する理由がたくさん。
だから圧倒的に時間が足りない。
勉強になったのは、Mustdo、shoulddo、coulddo＋20:80の法則からの気づき。あるシステムを構築するときに本当に必要で核となる機能は全体の20%。だから、アジャイルとかで徐々にお客にリリースしていけば、うまくいけば残りの80％を省略できるかもしれない。ま、ウォーターフォールでは無理ですな。
こういう手法で納期を守りつつ、お客さんの顔色（懐）を見ながら徐々に機能を縮小するのが、生き残るために必要なのかなって思いますた。 -
-
-
-
-