デスマーチの構造： プロジェクトは始まる前に失敗している Vol.2：ITアーキテクトを探して （15）（1/2 ページ）

デスマーチの構造：プロジェクトは始まる前に失敗している Vol.1では「デスマーチ」が知らず知らずの間に始まってしまうという恐ろしい事実を明らかにした。今回は実践的な解決策を提示する。

[構成：唐沢正和，＠IT]

キープレイヤーを把握して政治的対応を

　この失敗しやすい「デスマーチプロジェクト」をうまく管理運営していくためのポイントはいくつかありますが、ここではプロジェクトマネージャの立場から2つの点に注目します。まず、何より必要なのは、抜け目のない政治的な対応です。特に、日本人の方は苦手なところだと思いますが、実はコンピュータ業界の米国人も苦手としているところです。

　政治的な観点で重要なポイントは、誰がキープレイヤーなのかを把握することです。その人物がプロジェクトを続行するかどうかの判断を下すことになるからです。キープレイヤーに対して最初から相談していない、また、問題が起こってからその人物に接触しようとする。これでは、プロジェクトはうまくいきません。さらに、どんな人がそのプロジェクトにかかわっているのか、チームすべての人間が理解していなければいけません。プロジェクトマネージャだけがすべてを知っているというのでは十分ではありません。

　その中には、ルーサーユーザーという、政治的に考えてプロジェクトが成功したら損をしてしまう人もいます。つまり、プロジェクトが成功すると自分の権力がなくなってしまったり、部下を失ってしまうかもしれない人です。そういった人がいることも理解してプロジェクトを進めていく必要があります。こうした人が、後々プロジェクトを失敗させる原因になることもあるわけです。

　いま、私は弁護士さんと一緒に時間をかけて、大きなコンピュータプロジェクトがなぜ失敗したのか、その原因を調べています。まず、弁護士さんが電子メールのメッセージをすべて収集します。何十万というメールがありますが、それを読むことでプロジェクトの大体の流れがつかめます。その結果、問題の原因は常に政治にあることが分かってきました。プロジェクトのとんでもないスケジュールや予算など、最初からできるはずのない計画が立てられていることがあります。どんなプログラミング言語を使っても、どんな手法を使っても、最初から成功するはずがないプロジェクトが実在しているのです。しかし、企業はそれを認めたがりません。

　こうした最悪の結果にならないためには、政治的な疑問、質問をプロジェクトの初期段階でぶつけておくことです。特に、プロジェクトが成功する可能性がどれだけあるのかという問題は、プロジェクトの初日に考えておかなければならないことです。もし、プロジェクトチームにおいて、そういった観点から見ている人が誰もいないのであれば、そのプロジェクト自体が大きな問題を抱えているといえるでしょう。