【要約】デスマーチソフトウェア開発プロジェクトはなぜ混乱するのか

著者

エドワード・ヨードン

書籍の概要

無理な納期や予算を前提にした過酷なシステム開発プロジェクトに対し、
プロジェクト・マネジャや開発メンバーはどう対処すべきなのか―。
経営陣との交渉術からツールの選択方法まで具体的な防衛策を示す。

デスマーチ・プロジェクトとは、開発期間、開発者数、予算などのいずれかが、
本来必要な水準の半分以下しか割り当てられていないプロジェクトを指す。
本書は、この問題を取り上げて1998年に話題を集めた初版に、大幅に加筆、改訂を加えたものだ。

筆者は、昨今のオフショア開発やアウトソーシングの進行に伴って競争が激化し、
その結果IT部門の限界をはるかに超えたデスマーチ・プロジェクトが生まれていると警告する。

米国の統計では、ごく平均的なプロジェクトでも計画と比べ6~12カ月遅延し、
予算を50~100%超過しているという。
これらの数字をそのまま日本の状況と比較することはできないが、
デスマーチ・プロジェクトが常態化している点に変わりはない。

現場でシステム開発に携わる人だけでなく、運用・保守要員やマネジメント層も、
自らを守るために読むべき一冊と言える。

Amazon 「日経BP企画」より抜粋

手にとってみた経緯

デスマーチ
この業界に身を置く方ならばいつもどこかで見かける言葉でしょう。
私はキャリアとしてプロジェクトマネージャーを目指している為、
この魔物はどうして生まれるのか。どう付き合うべきなのかをこの書籍に求めました。

この記事は2017年にEvernoteにまとめた情報を推敲し、公開しているものになります。

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

デスマーチ第2版ソフトウエア開発プロジェクトはなぜ混乱するのか [ エドワード・ヨードン ]
価格：2420円（税込、送料無料) (2020/10/4時点)

楽天で購入

特徴

対象読者

プロジェクトマネージャー
プロジェクトリーダー
プロジェクトメンバー

良い点

デスマーチが発生する原因とその対策を記載されており、危険を察知する力が向上します。

悪い点

冗長な表現が多く、やや読み難い。

内容紹介

少々冗長な表現がある為、自分なりに整理した言葉でポイントをまとめます。

ポイント！デスマーチになる諸悪の根源を以下の観点で探れ。
ワインバーグ氏の述べる「一見どう見えようとも、それは常に人の問題である」

　→ ヨードン氏はデスマーチ発生の原因を色々述べているが、集約すればこれである。
　　元々計画されていたものから何かが変わったが、元々の計画を踏襲した。
　　又は、元々の計画から誤っていた。この辺りがデスマーチの始まりである。

ポイント！変化を与える者（ステークホルダー）を洗い出し、危険因子を探れ。

　→ ヨードン氏は「政治」という言葉を使用しているが、
　　ステークホルダーと読み替えてもらっても構わない。
　　システムエンジニアならばこの辺りは経験をお持ちの方が多いのでは？
　　 ◎ Aさんからは合意を得たが、その上司や別の人からその合意をひっくり返された。
　　 ◎ 突然参画したステークホルダーが「私は聞いてない！駄目だ！」と暴れ始めた。
　　 ◎ そもそも自分のチーム内でやり切れる資源（リソース）が消失した（有識者の離脱）。

　　こうしたプロジェクトに対する関与度や権力を明確にしておき、
　　そこに対して常に目を配っておかなければ全てが事後対処になってしまう。
　　その対処をしている間に別の問題が発生し、芋づる的に全てが事後対処になり、
　　一人ひとりがこなせる許容量を超えてデスマーチとなる。

ポイント！計画の変更せざるを得ない事態に直面した場合は、必ず交渉せよ。
1. 何かを削減された（ex. 納品を早めろ）場合は、その他のパラメータを削減せよ。
2. 変更幅が「10%」の場合は、1. のパラメータを凡そ「10%」変更すれば良い。
　もし、変更幅が「10%」を超える場合は「n の二乗の法則」に則り変更すれば良い。
3. いつ出来るんだ？いくらで出来るんだ？と聞かれた場合はベターな回答は、
　「○○」までには出来上がると思いますが、「誤差は±○○です。」と
　　必ず不確定要素がある事を伝える事を忘れてはならない。

　→ 顧客は悪気なくソフトウェアの仕様を変更してくる。
　　ちょろっとそこの文を直すだけだと思っているからだ。
　　悪気がないのだからこちらの「受け入れ難さ」を伝える努力をしなければならない。
　　毎日の本当に小さな変更が、葉から木へ、林へ、森へと炎上する火種になるのです。

ポイント！デスマーチ・プロジェクトを防ぐ為のトリアージ
◎ Must：必須
　これを満たさなければプロジェクトの目的は達成出来ない。
◎ Should：推奨
　これを満たさなくてもプロジェクトの目的は達成出来る。
　しかし、大きなデメリットを有した状態になる。
◎ Could：出来れば
　これを満たさなくてもプロジェクトの目的は達成出来る。
　しかし、少々のデメリットを有した状態になる。
◎ Won’t：見送り
　これを満たさなくてもプロジェクトの目的は達成出来る。
　いつか出来れば嬉しい。

　→ この考え方は、MoSCoW分析と呼ばれています。
　　要件定義工程では幾多の要件が出現し、変更管理を受け付ける際も必ずこれは行いましょう。
　　本当に必要な要件を実現する以外に、我々の時間は余ってはいないのだから。

　　このトリアージについてもステークホルダーの合意を必ず得ておく事。
　　時よりMustとして１年に１度しか実施しない業務を自分の部門が大変だからという理由で、
　　提示してくる顧客もいる為。（その逆もありますが）

ポイント！情報は常にオープンにせよ。（特にプロジェクトメンバーに対して）

　→ プロジェクトマネージャー、リーダーのキャパシティが超過した時、
　　そして忙殺される日々が続く頃、彼らとメンバーの間に溝が出来ます。
　　メンバーは彼らが情報を開示しない事に不信感を抱き、
　　徐々にいい様に使われている。といった思いが募ります。
　　彼らに悪気はなく、ただ本当に、時間がないのです。
　　ただ、そういう状況下であっても
　　「今、プロジェクトはどういう状態で、問題は何があり、今後どうなるのか？」
　　そういった事を開示していく事がチームには必要です。

ポイント！デスマーチが発生している時に頼ってはいけないもの。
◎ 管理の為の管理を始める事。
◎ これを使えばうまく行くといった新しいツール。

　→ 管理の為の…は言わずもがな。なので割愛します。
　　２つ目は「銀の弾丸はない」という点をヨードン氏は言っています。
　　ソフトウェア開発は面倒な事や地道な仕事が多いものです。
　　銀の弾丸 ≒ 魔法はないという事を理解しておくだけでも、変な決断を下す事を防げると思います。

次のアクション

デスマーチは本当に辛いです。
なので、デスマーチには極力、距離を置くのが精神衛生上良いことですし、
そうならない様に日々のプロジェクトでもデスマーチの教訓を知っておく事が処方箋になります。

この書籍を読んだ方が、何かしらの仕事のヒントを得られれば、幸いです。

↓クリックしていただければ励みになります！

書評、レビュー