デスマーチの教訓、そしてPMOとは

先日の炎上プロジェクトを火消しした。

教訓としてまとめておく。

 

問題の原因

アプリケーションサーバーのバグ

何故発覚が遅れたか

• 前回上手くいってたという先入観
• 論理的に分析していない
• 問題をツリーで分析してない

根本原因

• 心身の疲れによる思考力低下
• 「何となく気づいてた」メンバーがいたが次の「アクション」に結び付かなかった

 解決法

• ログ、バグ報告の公式ページ、こうだからこう、という資料をまとめた
• 資料をエビデンスとし、お客様に制約事項として調整
• 「落としどころ」を提示し納得させる

次回の教訓

• 先入観を疑う
• 論理的に問題を構造化し、見える化する
• 心身が疲れない工夫
• 何か疑問を感じたら「頭の中に残す」だけでなく「行動する」
• お客様への早期アラート、早期解決案提示
• 「問題の解決」とは何か？を考える
• 問題の直すことより、問題そのものを「無くする」ことも可能。交渉能力も問われる

あと、この辺の教訓は、今回参画メンバーは認識持つのは当然として、

社内横断的なPMO(プロジェクト・マネジメント・オフィス)が教訓を管理し、今後のプロジェクト全体に行き渡らせる必要があるだろう。

PMOとは、各プロジェクトを横断的に支援する部門だ。残念ながら元職場では、そのような部署は無いのだが。。

デスマーチ 第2版　ソフトウエア開発プロジェクトはなぜ混乱するのか