はじめに
「デスマーチ（死の行進）」は長い間、多くのプロジェクト関係者を悩ませています。某サクラダファミリアと呼ばれる銀行システムでも続いているでしょうか。
私は、その最も合理的な回避策について私はトリアージを自然に組み込んだアジャイル開発への移行だと思ってますが、ウォーターフォール開発に突入する際には、覚悟をしなければいけません。
ポイント
デスマーチ（死の行進）の定義
- プロジェクトのパラメータが正常値を５０％以上超過しているもの。
- or 公正かつ客観的にプロジェクトのリスク分析（技術要因の分析、人員の解析、法的分析、政治的要因の分析も含む）をした場合、失敗する確率が５０％を超えるもの。
発生要因
- いろいろ。
知るべきはトリアージ(triage)
- 開発システムの要求項目を３つに分類する。
- やらねばならぬ。must-do
- やった方が良い。should-do
- やれればやる。could-do
- ４つ以上に分類してはいけない。優先度３か優先度４か、という不毛な議論は避ける。
- トリアージは、戦場や災害が起きた場所で、割り当てなければならない医療資源に限りがある場合に用いられる手法として有名。
残念な現実
- プロジェクト開始時からトリアージできれば事態は悪化しない。しかし、プロジェクト開始時にプロジェクト・マネージャから幹部への進言に対し、幹部はそれを理解しない。
- 納期に間に合わないことが現実的になってきて、初めて幹部が騒ぎ始める。そして、プロジェクト・マネージャの責任とされて退職する。
- 新たな後任のプロジェクト・マネージャ（火消し）が納期延伸や要求項目の精査を実施する。チームがその酷い危機に陥った理由が幹部にあったことがわかるので、今度は強く幹部と交渉できる。
デスマーチ・プロジェクトは常態であって例外ではない。
書誌情報
- 書籍名：『デスマーチ』なぜソフトウェア・プロジェクトは混乱するのか
- 著者：エドワード。ヨードン
- 出版社：トッパン
- ISBN：4-8101-8982-1
参考
- 「みずほ システム障害」でYouTube検索すると、・・・