コンサルタントコラム

プロジェクトは失敗するものである

2013年06月19日

コンサルタント

菅野 徹夫

こんにちは。
東京都BCP策定支援プロジェクト担当の菅野かんのと申します。

あえて断定的に言いきったタイトルに、
「そんなことはない!」「成功したプロジェクトもたくさんある!」
と思われたかもしれません。
実は、このタイトルには条件が付きます。

 ■プロジェクトは“組織的にリスクマネジメントしないと”失敗する
 ■プロジェクトは“初期段階で依頼者と実行者間で共通認識がないと”失敗する
 ■プロジェクトは“変更管理を適切に運用できないと” 失敗する

等々。
これらを総じて言い換えれば、
「プロジェクトは“失敗するという前提で取り組まないと”失敗する」
と言えるのです。
この「法則」をもとに、
私は、自分が関わるプロジェクトは何が何でも成功させるつもりでいます。

私は、いくつかのIT企業で10年間をプロジェクトマネージャーとして、
その後の20年間をプロジェクトの品質保証に携わってきました。
ここでプロジェクトマネージャーとしての体験をご紹介します。

私は、ある金融機関のITシステム全面刷新プロジェクトで、
IT企業側の責任者に任命されました。
お客様の要求仕様にもとづいて見積り、提案、受注したプロジェクトです。
一括請負契約で開発期間は2年、
未経験の技術や新しい業務要件が含まれていました。
当プロジェクトには多くの不確実性があり高リスクだと判断し、
お客様と役割分担や意思決定方法などを合意し、
適切なプロジェクト運営体制を確立した上で、
キックオフミーティングを皮切りに要件定義に着手しました。

要件定義は実に順調に進行し、立派な要件定義書が完成しました。
記述範囲も十分で、性能や操作性などの非機能要件も漏れなく記述され、
未決定事項は優先順位、実施責任者、期日が設定されていました。
要件定義に関わった全員が出来映えに満足し、達成感を感じました。

そこで次の外部設計局面を開始したのですが、
外部設計計画書に沿って進捗管理をしていた時、
もっとも重要な業務系アプリケーションで進捗遅れが表面化したのです。
早急に対策チームを立ち上げ、原因を究明したところ、
私たちが良い出来映えと満足していた要件定義に
重大な欠陥が隠れていたことが明らかになりました。
たとえば記述粒度のバラツキ、検討不十分、未決定事項などです。
私たちは外部設計を停止し、業務知識を有する人材を集め、
要件定義レビューを集中的にやり直しました。
おかげで外部設計を再開できましたが、この要件定義の後戻りが
最終的にプロジェクト全体の遅延と予定コスト超過を招いてしまったのです。

プロジェクト開始前から十分にリスクマネジメントを行い、
準備をしっかり行ったつもりでいても、
人間が行う複雑な共同作業には必ず欠陥が生じてしまいます。
それはなぜでしょうか。
次のような「プロジェクトの特性」を考えるとその理由が見えてきます。

 ■期間が限定されている
 ■個々にユニークで同じものではない
 ■人による創造的活動である
 ■決めるべき時期に決めるべきことが多い
 ■利害関係者が多い

(社)日本情報システム・ユーザー協会の2006年企業IT動向調査では、
システムの出来上がりに満足している企業は10%程度と報告されています。
つまり、
「プロジェクトは“失敗するという前提で取り組まないと”失敗する」のです。

例にあげたITシステム開発プロジェクトばかりでなく、
展示会出展、新商品開発、社内業務改革、
JSOX法対応、ISO認証取得、BCP策定等といったプロジェクトにおいても、
すべて不確実性とリスクがついて回る点で同様と言えます。

最後に、失敗しそうなプロジェクトを事前に判定する基準を紹介します。
社内プロジェクトでは
「お客様」を「依頼者(オーナー)」と読み替えてください。

【失敗プロジェクト事前判定10項目】
 □初めてのお客様からの受注である
 □お客様内に利害関係者が多い
 □お客様の要件定義力が弱い
 □新システムの要件に「現行どおり」という記述がある
 □開発期間が短い
 □一括請負契約である
 □お客様の予算に合わせて見積りを調整している
 □新技術、新方式を採用している
 □プロジェクトマネージャーが類似システムの開発経験がない
 □協力会社に中核部分を外注している

10項目中3個以上にチェックがついたら
重点管理プロジェクトに指定して組織的支援体制で臨む、
5個以上にチェックがついたら受注を見送る、といった判定に使えます。

「では、プロジェクトを成功させる方法は?」
とお思いの方もいらっしゃると思います。
次回は、そのテーマでコラムを書いてみたいと思います。