デスマーチ 第2版 の商品レビュー
PMP資格更新に向けて読みました。 個人メモ用にですが、ざっくり要約すると下記の感じかと思いました。 ・デスマーチプロジェクトは多種多様あるが、結局無理な納期やスケジュールのプロジェクト ・デスマーチプロジェクトに対する最も効果的な対処はトリアージする事 ・もちろん状況によるが、...
PMP資格更新に向けて読みました。 個人メモ用にですが、ざっくり要約すると下記の感じかと思いました。 ・デスマーチプロジェクトは多種多様あるが、結局無理な納期やスケジュールのプロジェクト ・デスマーチプロジェクトに対する最も効果的な対処はトリアージする事 ・もちろん状況によるが、新しいツールや手法を導入するより使い慣れたツールや手法をうまく活用する方が効果的 ・デスマーチプロジェクトはどれだけ時代が進んでも無くならない 少しクセがある文章のため、所々流し読みした箇所もあります。読書の時間がとれず細切れに読んでいたため理解しきれていないと感じる箇所もままありました。できるのであればしっかりと時間を確保した上でまとめて読む方が向いている本かなと思います。 また時間がしっかり取れるタイミングでじっくりと理解しながら読みたいと思いました。
Posted by
トリアージしよう。もっとも大切な要求、課題から手を付ける 【感想】 「デスマーチ」をキーワードにして、プロジェクトマネジメントのよもやま話をしていく本。主張は基本的なプロジェクトマネジメント原則と大差が無いかも。ソフトウェア開発プロジェクトの難しさを理解するために読むとよさそ...
トリアージしよう。もっとも大切な要求、課題から手を付ける 【感想】 「デスマーチ」をキーワードにして、プロジェクトマネジメントのよもやま話をしていく本。主張は基本的なプロジェクトマネジメント原則と大差が無いかも。ソフトウェア開発プロジェクトの難しさを理解するために読むとよさそう。書き方はエッセイ的で、メッセージが掴みづらい。既にPMの知見が無いと、難しい。単純にシステム開発プロジェクトについて理解するなら、「システムを作らせる技術」の方が分かりやすい。各章ごとの「まとめ」を読んでから、本文を読んだ方が理解しやすい。勉強のために読むなら、読んだうえで自分で抽象化を試みた方が良さそう。 【本書を読みながら考えたこと、気になったこと】 問いを立てて読んだ方が良さそうな本。 ■なぜ、デスマーチが起こってしまうのか ・正確に作業量を見積もることが難しい。見積もりより作業量が増えても、納期は後ろに伸びない ・時間的、資金的、人的な余裕がない。ソフトウェア開発プロジェクトはビジネスであり、より安く、早いサービスが求められる。市場競争の結果、コンペを勝ち取る際には、他社より少ない予算（人員）、より早いスケジュールでの計画実現を提示できたベンダーが、ソフトウェア開発プロジェクトを受託できる。結果的に、いつもギリギリの状態でプロジェクトはスタートする ・失敗が隠される。過去にソフトウェア開発プロジェクトでの失敗があっても、企業は体裁を守るために、できる限りその事実を隠そうとする ■デスマーチに巻き込まれたら、どうすればよいか ・トリアージする。優先順位をつけて、対応する。全ての問題に対応しなければ、何もかもうまくいかない、ということはない ●１章 はじめに ・デスマーチプロジェクトとは、プロジェクトのパラメータが50％以上超過している物 ・通常であれ二人月かかるところを一人月でやろうとしている等 ・デスマーチは、教育効果が大きい ・プロジェクトの作業量、難易度を正確に見積もるのが難しい。予想より多くの課題、作業が発生し、デスマーチとなる ●２章 政治 ・ソフトウェア開発プロジェクトは、様々な立場の人の思惑に左右される ・顧客、プロジェクトマネージャー、出資者、顧客上層部等 ●３章 交渉 ・納期、人的リソースについて交渉しよう ・時には、PMとして、会社上層部に反旗し、プロジェクトメンバーを守ろう ・「見積もりが難しいのは、見積もりを現状と将来をベースにした最善の予測を」と解釈するため。これが、上層部においては、『厳守すべき値』に変わってしまう」 →見積もりは常に最悪を想定して行いたいな ●４章 デスマーチプロジェクトの人々 ・残業時間が多すぎると、途中から生産性は低下し始める ・プロジェクトの成功には、優秀な人、チームとして機能すること、働きやすい職場環境が必要だ ●５章 デスマーチ・プロセス ・この本で一番大事な言葉「トリアージ」 ・「80/20の法則」に従う。いくつかの項目は、永遠に実装されない。それを目指す。全てに手をつけていては、デスマーチプロジェクトは終えられない ・システムの要求項目は「must」「should 」「could」に分けよう。そそて、mustから手をつけよう ・要求管理をしよう ・そこそこ使えるソフトウェアができれば、それでいい ●６章 プロセスのダイナミックス ・もっとも生産性の高い人から辞めていく。好条件の求人など、いくらでも来る ・プロジェクト上で大切にする人や仕事の取り扱い方の考え方を、チームに共有しよう ●７章 クリティカルチェーンと制約条件の理論 ・プロジェクトのボトルネック、クリティカルパスは確認して仕事を進めよう ●８章 時間の管理 ・無駄なミーティングはするな ・利害関係者の意見が対立する → 承認が遅れることによって、スケジュールが遅れることを文書化して提示せよ ・緊急で重要度の高い仕事、緊急でないが重要な仕事をしよう。緊急だが重要でない仕事（電話応対）などに対応する機会を減らそう ●９章 進捗の管理と制御 ・リスク、問題を整理し、管理し、評価し、対応方法を決めよう ・問題が多いデスマーチプロジェクトではなおさらだ。 ・社内のプロジェクト後に、評価をしよう。同じ過ちは繰り返さないようにしよう ●１０章 デスマーチのためのツールと技術 ・便利なツールは利用しよう。作業を標準化し、効率化しよう ●１１章 シュミレーションと「戦争ゲーム」 ？メッセージが理解できなかった
Posted by
トナメール 10.4.28 E.ヨードンもその著書デスマーチで「デスマーチ回避に、要求工学 やPMBOKやテクノロジーや諸々の手法やツールは一部は役に立って いるが限定的であり、最終的には政治力や交渉力やコミュニケーション 力が鍵となる」と言っています。
Posted by
6年ぶりに前線に復帰したので、初心に戻ってITプロジェクトマネジメントの再学習。デスマーチとはプロジェクトが火を噴いている状態であり、技術やマネジメントの方法論ではデスマーチプロジェクトは解決できないことが多いのです。最新の開発ツール・方法論のようなハードなエンジニアリングアプロ...
6年ぶりに前線に復帰したので、初心に戻ってITプロジェクトマネジメントの再学習。デスマーチとはプロジェクトが火を噴いている状態であり、技術やマネジメントの方法論ではデスマーチプロジェクトは解決できないことが多いのです。最新の開発ツール・方法論のようなハードなエンジニアリングアプローチではなく、優れた人材や効率の良いチームのようなソフトな要素が大事なのです。アメリカのITプロジェクトをベースにしている＆初版が古いのですが、参考になる要素は多いのです。 続きはこちら↓ https://flying-bookjunkie.blogspot.com/2019/04/blog-post_19.html Amazon↓ https://amzn.to/2VhlNYU
Posted by
デスマーチプロジェクトとは「プロジェクトのパラメータ」が正常値を50%以上超過したもの。工期が半分、要員が半分、予算が半分、機能・性能が倍。高い確率で失敗が予測される過酷なプロジェクト。後半は面白くなってきてあるあるを感じる。トリアージという概念。注釈のある本は苦手、交互に読もう...
デスマーチプロジェクトとは「プロジェクトのパラメータ」が正常値を50%以上超過したもの。工期が半分、要員が半分、予算が半分、機能・性能が倍。高い確率で失敗が予測される過酷なプロジェクト。後半は面白くなってきてあるあるを感じる。トリアージという概念。注釈のある本は苦手、交互に読もうとしてリズムがつかめなくなる。
Posted by
発注先の本気度、システムへの理解がある、ないかによって左右される部分が多い気もする。官公庁のような体制や曖昧な人が多くなるとデスマーチはやってくる。
Posted by
デスマーチプロジェクトをどう回すか、ということについて色々書かれている。デスマーチプロジェクトが増え続ける昨今、プロジェクト・マネージャを務める人にはぜひ読んでいただきたい1冊。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
「デスマーチは常態」。うん。 お客さんから、いやむしろ経営者から、大げさに言うと半分の予算で！半分の人数で！半分の納期で！に「期待している」という言葉を添えて任される。 新しい技術、手法を取り入れてみる。誰もやったことない。つまりみんな新人と同じ。遅延する理由がたくさん。 だから圧倒的に時間が足りない。 勉強になったのは、Mustdo、shoulddo、coulddo＋20:80の法則からの気づき。あるシステムを構築するときに本当に必要で核となる機能は全体の20%。だから、アジャイルとかで徐々にお客にリリースしていけば、うまくいけば残りの80％を省略できるかもしれない。ま、ウォーターフォールでは無理ですな。 こういう手法で納期を守りつつ、お客さんの顔色（懐）を見ながら徐々に機能を縮小するのが、生き残るために必要なのかなって思いますた。
Posted by
デスマーチとは、プロジェクト特にソフトウェア開発プロジェクトが陥る悲惨な状況のこと。デスマーチは避けられないということか。
Posted by
デスマーチ、特にIT系のプロジェクトで繰り広げられる、過剰労働と、納期遅延と、品質の悪い事による問題。つまり、仕事が失敗して大変な状態になっていることを指す。 人的にも、時間的にもできない仕事を請け負った場合にデスマーチとなる。社内政治的な関係で、わざとデスマーチを競争相手に仕掛...
デスマーチ、特にIT系のプロジェクトで繰り広げられる、過剰労働と、納期遅延と、品質の悪い事による問題。つまり、仕事が失敗して大変な状態になっていることを指す。 人的にも、時間的にもできない仕事を請け負った場合にデスマーチとなる。社内政治的な関係で、わざとデスマーチを競争相手に仕掛けて潰すことも「よくある」。 また、IT系で、実力が全くないのに、在籍年数が長いため、プロジェクトに抜擢された中堅が、まともに要件定義もままならずプロジェクト終盤にさしかかり、破綻するケースもある。 終盤から、キックオフ以降の本格稼働において、本来するべき業務ができず、常にバグ対応と、不完全な仕様によるリカバリに大量の人月を消費する羽目となり、当初のスタッフを総動員しても、現状復帰すらも絶望的であり、本質的な問題の解決までリソースが避けないという自体に陥る。この状態では、たとえ10年かけても更に悪化することはあっても、正常化することはできない。つまり、プロジェクトが破綻したという事だ。 プロジェクトが終盤にさしかかり、破綻が目に見えてわかった場合、現場のスタッフはさっさと転職先を探して逃げていってしまう。逃げられた場合、大抵の場合まともなドキュメントや引き継ぎ資料はなく、恐ろしいほどに遅延した業務と、正しくない装飾された報告書とが残っており、リカバリは困難である。 1年間のプロジェクトで、遅延が20％だったとして、納期まで1ヶ月でその遅延を挽回するためにどれだけ仕事をすればいいのか、計算はできないケースが多い。解答としては、1日実働8時間とした場合、1日あたり27時間以上働けば挽回できる。実際には14時間目以降から能率は悪化していくことが広く認知されている。そのため、1日あたり35時間ぐらい働けば間に合う計算だろう。 この不可能な数字を前に、仕事のプロセスを飛ばし・品質を悪化させ間に合わせようとする。結果、仕事のプロセスを飛ばしたことで問題が起きた時に原因が特定できず、また、リカバリに、その省略した時間分の数倍から数十倍の労力をかけて挽回をする必要が出てくる。 かくして、非常に頑張っている(つもりである)が、経営者からは残業代泥棒と無能にしか映らず、全く評価されないという不幸な状況に陥る。
Posted by