プロジェクトの7割では何が失敗しているのか?

 システム構築プロジェクトの約7割は失敗すると一般的に言われています。ここで失敗と言っているのはQCD(品質・予算・納期)の3点が計画に対し達成できなかったという事みたいですが、失敗と判定しているのはいったい誰でしょうか?
 予算と納期は明確なので、成功・失敗は明確に線引きできそうですが、作り手側では途中で納期に間に合わせる事が無理だと判断したその時点でユーザー側と予算と納期の調整をするはずです。この場合、調整を開始する時期にもよりますが、大抵の場合で要件追加はあるものですし、要件追加に対してはそれを盾に予定よりも時間が足りないと主張するのは当然と言えば当然で、ユーザー=発注者側が了解すれば、結果として予算と納期は変更されます。なので、作り手側からみると当初の予定というよりも最終的なコスト・納期で判断している事が多いように思います。でもユーザー側は計画通りではなくなったと考えるでしょう。ここで作り手側とユーザー側で基準にズレが発生している事になります。
 また、品質というのは何を基準にしているか曖昧ですが、品質が計画通りでないというのは基本的にユーザー視点でしょう。作り手側は品質的に問題無いという判断できる段階で納品しているはずなので、そのズレが大きいのでしょうか。カットオーバー後にちょっとした不具合でもあれば、品質が良くないと強く感じてしまうものですし、そもそも要求を全て実現する事なんて殆ど無いのに、いざ動かしてみたら、実現出来ていない点が目立ってしまい、要件外であったとしても一番使うエンドユーザーは大抵そんな経緯は知らず、不満な思いを持ってしまいます。
 作り手である開発者側も発注者であるユーザー側のどちらも経験している筆者の経験上、開発者の立場から失敗だったと感じたプロジェクトはあまり無いですが、発注者側の立場では当初の予定通りに行くプロジェクトは確かに多くはなかったと感じます。途中から担当することになったプロジェクトなどでは既に失敗してないか?というのもありましたので、7割のプロジェクトが失敗したという判定は発注者側、さらに、当初の計画を知っている人、発注者側のシステム部門長の判定と思われます。
 でも、正確に言うとシステム構築プロジェクトの失敗ではなく、プロジェクトを計画する企画段階が失敗しているケースが多いのではないでしょうか?計画に問題があれば、それを実行するのが難しいのは当然です。ヒマラヤ登山の計画がずさんだったらそりゃ大事故が起こるのは当たり前です。でも、登山だったら目的は明確だし、登山道の選択肢も限られているし、過去の経験と照らし合わせて計画ができます。対してシステム構築プロジェクトは、お題目的な目標はあれど、たいていは明確ではありません。例えば業務コストを何%カットというのが目標だったりすると、その為に何をするかは限りなく選択肢があります。極端な話システム開発しなくても達成できる事だってあります。
 数年前に話題になった小惑星探査機はやぶさのプロジェクトですが、あれって期日を何年も超えてるし、恐らく予算もかなりオーバーしていると思いますが、誰もが成功と思っているのではないでしょうか?実は、はやぶさプロジェクトの評価は加点方式で、何のミッションを実現したら何点という評価方法自体をプロジェクト計画時点で明確にしていたので、一般的な減点方式の評価とは違うらしいのです。
 とは言え、前人未踏のはやぶさプロジェクトとは違い、殆どのプロジェクトは減点方式です。計画に対して未達なら減点されてしまうのですが、計画が計画通りにいかないリスクを感じ取るのは不可能、というか、そもそもリスクヘッジした結果として計画が出来上っているはずなんです。時間経過に伴いリスクが顕在化した場合を見越して、要件定義後に計画を再見直しするという前提を設けるとか、曖昧なバッファ期間・バッファ予算を設けるくらいしかできませんが、それを他へ説明するのも難しいものです。細かい機能要件の漏れとかインフラ・ビジネス・他システム連携の前提条件が当初想定したものと一致していない事が判明するのは設計フェーズでよく発生しますが、極端なケースだと実際に他システムと接続できた後の導入開始後だったりもします。当然それらは計画時点では盛り込まれていませんので、計画を変更せずにそれらを受け入れる時、いわゆるデスマーチが始まるのです。もちろん、作り手側の力量不足という理由だけでマーチが始まってしまう事も確かにあるでしょう。とは言え、例えそうであったとしても、失敗という言葉を現場のメンバーのいる場で聞こえるように言わない方がいいですね。

カテゴリー: 徒然草   作成者: bokusui パーマリンク

bokusui について

ソフトウェアハウスでのPG・SEから始まり、10年近く勤めた金融系企業の社内SEを数年前にやめ、フリーランス時代を経たのち法人成りしました。システム開発の全工程をこじんまりとやり続けています。