DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

宇宙はビッグバンにより誕生し、膨張し続けていると考えられています。（※１）

「膨張する宇宙」と同じように、多くのシステム開発のプロジェクトも、要求、スコープ、コスト、スケジュール、リソースなどが膨張し続けます。

「膨張するプロジェクト」においては、エドワード・ヨードン氏が言うように、プロジェクトの初期段階から「トリアージ」を行う必要があるのでしょうか？（※２）

【　膨張するプロジェクト　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
プロジェクトはどのようにして膨張していくのでしょうか？

＜要件定義＞
ユーザーによる検討が進めば進むほど、あれも必要これも必要と要件が増えていく傾向があります。

＜外部設計＞
ユーザー要件を実現するための画面、帳票、機能などが増えていきます。イレギュラーケースを救おうとすることで、機能が増えたり、データベースの項目数が増えたりしますよね。
それに、外部設計の発注側とのレビューはなかなか収束せず、再レビュー、再々レビューなどにより、どんどん時間やコストを食いつぶしていきます。

＜内部設計～結合テスト＞
品質目標をなかなかクリアできずに、品質向上タスクが追加されていきます。

＜システムテスト、ユーザーテスト＞
ようやく新システムがどういう動きをするかが見えてくるため、仕様変更が多発して手戻りが発生します。

＜移行＞
テストが終わってようやく本番稼働を迎えられると思ったところ、移行判定会議で重大なタスクの漏れが発覚して、急きょ漏れていたタスクを実施する必要があります。

さあ、あなたのプロジェクトでは、これらの追加タスクが発生するかもしれないリスクに対して予防対策は十分打たれているでしょうか？

そして、もしこれらのリスクが顕在化したときのために、実現性のある発生時対策が十分検討され、それを実施するためのコスト、スケジュール、リソースなどのバッファが十分確保できているでしょうか？

この質問に胸を張ってＹＥＳと答えられなければ、プロジェクトの膨張は避けられず、「膨張するプロジェクト」はデスマーチへの道へまっしぐらです！

【　膨張するプロジェクトへの処方箋　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここでエドワード・ヨードン氏による「デスマーチ・プロジェクト」の定義を確認してみましょう。（※３）

「デスマーチ・プロジェクトとは、『プロジェクトのパラメータ』が正常値を５０％以上超過したもの」である。

具体的には、以下のようなプロジェクトのことです。
１． 必要なスケジュールが半分しか無い
２． 必要な要員の半分しか割り当てられない
３． 必要な予算の半分しか無い
４． 技術的な要求が通常の倍以上

また、エドワード・ヨードン氏は、次のように「デスマーチ・プロジェクト」の定義を言い換えています。

「公正かつ客観的にプロジェクトのリスク分析（技術的要因の分析、人員の解析、法的分析、政治的要因の分析も含む）をした場合、失敗する確率が５０％を超えるもの」

この定義に基づけば、前章で述べたような膨張するリスクへの対応策が不十分なプロジェクトも、「デスマーチ・プロジェクト」であるといえるでしょう。

私の経験から想像すると、最初から失敗する確率が５０％以上とわかっているプロジェクトよりも、どのくらい失敗する可能性があるかよくわからないままキックオフし、時間の経過とともにプロジェクトが膨張し続けることで、いつの間にかデスマーチに陥っていくことの方が多いのではないかと思います。

このように「膨張するプロジェクト」にアサインされた場合、プロジェクトの終盤で危機的状況が訪れるのは目に見えているので、そうなる前の早い段階から「トリアージ」を行うことで、より整然と「デスマーチ・プロジェクト」をコントロールすることができるというのが、エドワード・ヨードン氏の趣旨であると考えられます。

まあ、危機的状況に陥って「トリアージ」を経験したことのあるプロジェクトマネージャーであれば、誰しも早め早めに「トリアージ」を行うようになるのは間違いないでしょう。つまり、危機的状況に陥ることが運命づけられた「デスマーチ・プロジェクト」において、少しでも危機的状況を緩和するための処方箋のひとつが、プロジェクト初期段階から「トリアージ」を行うことであるのは確かでしょう。

【　トリアージ依存症　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
しかし、世の中のシステム開発プロジェクトの成功確率が３割程度だとしたら、半分以上のプロジェクトは失敗しているため、世の中のシステム開発プロジェクトは、デスマーチだらけということになります。

世の中のプロジェクトマネージャーは、デスマーチを何度も経験していることになるので、そのようなプロジェクトマネージャーはみな、プロジェクトの初期段階から「トリアージ」に頼りだすことになるでしょう。「トリアージ」を行う時期が早ければ早いほど効果を発揮するでしょうから、要件定義段階から要求の3分の１をあきらめるようユーザーと調整することになります。

このようにして、プロジェクトの危機的状況に対する不安でいっぱいのプロジェクトマネージャーは、「トリアージ依存症」に陥ることになります。「トリアージ依存症」のプロジェクトマネージャーが増えてくると何が起きるでしょうか？

ユーザー要求の３分の１はカットされてしまうので、構築されるシステムはどれもこれもユーザー要求を十分満足するものとは、ほど遠いものとなってしまう可能性があります。そうなると、「トリアージ」された要求をもとに進めたプロジェクトとしては、ＱＣＤ（品質、コスト、納期）のプロジェクト目標を達成しているものの、そもそもシステム化の目的が十分達成されないという状況に陥ってしまうのではないでしょうか？

そんな状況に陥らないためにも、プロジェクト・サクセス・クライテリア（成功判断基準）を明確に定義することで、形だけのＱＣＤ（品質、コスト、納期）達成に向けた「トリアージ依存症」に陥らないようにする必要があると思います。（※４）

「ＩＴプロジェクトにおけるトリアージは劇薬であり、用法や用量には注意が必要です！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　「宇宙」『フリー百科事典　ウィキペディア日本語版』2014年9月25日 (木) 12:58 http://ja.wikipedia.org/wiki/宇宙

※２　【第３９回】トリアージでデスマーチを脱却せよ！

※３　エドワード・ヨードン（2006）『デスマーチ第２版』日経ＢＰ出版

※４　【第３５回】プロジェクト・サクセス・クライテリア（成功判断基準）