ご訪問ありがとうございます! < 前回 | 目次 | 次回 >
前々回の工程完了判定基準、前回のカットオーバー・クライテリアに続き、今回はクライテリアシリーズの第三弾として、プロジェクト・サクセス・クライテリアがテーマです。カットオーバーを迎えただけでは、システム開発のプロジェクトが成功したとは言い切れません!プロジェクトの成功は、いったいどうやって判断できるのでしょうか?
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・
プロジェクト・サクセス・クライテリア(project success criteria)という言葉もシステム開発プロジェクトの現場ではあまり馴染みが無いかもしれません。サクセス・クライテリアは、日本語にすると「成功規範」とか「成功判断基準」です。つまり、プロジェクト・サクセス・クライテリアとは、プロジェクトの成功判断基準ということです。
一般的にシステム開発プロジェクトの成功確率は30%程度だと言われています。これは2008年の日経コンピュータによるプロジェクト実態調査の結果がもとになっているように思われます。この調査におけるプロジェクトの成功の定義は、「Q(Quality)、C(Cost)、D(Delivery)」、すなわちシステムの「品質」「コスト」「納期」の3点について当初の計画を順守できたかどうかということでした。(※1)
また、『ソフトウエア開発の定量化手法-生産性と品質の向上をめざして-』の著者として有名なCapers Jones氏は、『ソフトウエアの成功と失敗』という著書の中で、以下の6点を成功と失敗の判断基準としています。(※2)
- ソフトウエアプロジェクトの納品スケジュールと出荷時期
- ソフトウエアアプリケーションの開発に要するコストと資源
- ソフト上の引き渡し時の品質と信頼性のレベル
- ソフトウエアの運用開始時の学習の容易さと利用のしやすさ
- 問題発生時の顧客支援とサービスのレベル
- 運用中のアプリケーションの変更・保守の容易さ
また、同書の中では「一般的な意味におけるビジネスとしての成功と失敗、組織的な、またはハードウエアの運用についての成功と失敗、あるいは人間関係における成功と失敗などを述べるものではない」と明言しています。
日経コンピュータの定義もCapers Jones氏の定義も、「品質」「コスト」「納期」を軸とした判断基準といえます。すなわち、プロジェクト計画書で定義した品質基準、プロジェクト予算、リリース日を全てクリアできた場合に、そのプロジェクトは成功したという判断になります。ただし、プロジェクトの特性に応じて、「品質」「コスト」「納期」のうち何を最も優先すべきは異なり、それぞれの優先度を加味した上で、そのプロジェクト固有のサクセス・クライテリアを設定し、成功と失敗の判断を行う必要があります。
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・
システム開発を行う組織として、プロジェクトの成功確率の向上は、組織目標の達成のためにも欠かすことができないことは言うまでもありません。しかし、実態として、その組織にとって大きな失敗プロジェクトが経営層の目に触れた時だけ、プロジェクトマネジメント力の改善に取り組もうとすることが多いと感じます。
そもそも、その組織において日常的に実施されている数多くのシステム開発プロジェクトについて、それぞれ成功なのか失敗なのかの判定がなされないまま流されていて、いったいその組織におけるプロジェクトの成功確率はどれくらいなのか?とか、「品質」「コスト」「納期」のうち、何がどれだけ失敗しているのかさえ把握できていない組織が多いのではないでしょうか?
もし本気で、組織としてのプロジェクト成功確率を向上したいのであれば、以下のような取り組みを行う必要があるはずです。
このような取り組みを継続していけば、必ずその組織におけるプロジェクト成功確率は向上していくと思います。
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・
さあ、ここまでは「古典的な」システム開発プロジェクトの成功の定義と、それをもとにしたプロジェクト成功確率向上施策についての話でした。Capers Jones氏の『ソフトウエアの成功と失敗』は、日本では1997年に発行されており、もうかれこれ20年近く経過しています。前章で述べたような取り組みについては、少し考えれば誰でも思いつくことであり、ISOやCMMIなどによる組織のマネジメント力の継続的改善という言葉で、多くのシステム開発を行う組織で取り組もうとしていたはずです。(※3)
しかし、実際には、世の中のシステム開発プロジェクトの成功確率はそれほど上がってきてはいませんよね?それ以前に、実際には前章で述べたようなプロジェクト・サクセス・クライテリアの定義やプロジェクトの成功と失敗に関する実績情報の蓄積なども、それほど浸透していないように感じます。その原因はいろいろあると思いますが、その一つの原因を少し私個人の仮設を交えながら考察してみたいと思います。
それは前章で見たプロジェクト成功の判断基準の内容そのものに起因しているのではないかと私は考えています。「品質」「コスト」「納期」を成功基準とするということは、プロジェクト計画書の通りにプロジェクトが遂行できたかという視点となります。
「品質」面の評価は、そのプロジェクトで作り上げるべきもの(新システム)がきちんとできたかどうかという評価になります。
⇒ システム開発の WHAT に対する評価
「コスト」「納期」面の評価は、作り上げるべきもの(新システム)を作り上げるために必要なタスクや資源が、見積りや計画通りにできたかどうかという評価になります。
⇒ システム開発の HOW に対する評価
さあ、ここまで書けば何が足りないと主張しようとしているか、だいたい想像つきますよね。システム開発のWHATとHOWについては評価しているのに、最も大事な
⇒ システム開発の WHY に対する評価 が欠けています。
Capers Jones氏は『ソフトウエアの成功と失敗』で、「ビジネスとしての成功と失敗」はプロジェクトの成功判断基準から除外していますが、システム開発プロジェクトが真の意味で成功したかどうかを評価するためには、ビジネスとして成功したかどうかという視点、つまり、「システム化の目的・効果の達成度合い」を評価する必要があるのではないでしょうか?(※4)
「プロジェクト・サクセス・クライテリアには、システム化の目的・効果の達成状況評価も含めるべきだ!」
そして、「品質」「コスト」「納期」のみによるプロジェクトの成功判断基準は、システム開発を主たる業務とする組織(開発ベンダーや発注側組織のIT部門)にとっての成功判断基準としては成り立つかもしれませんが、発注側組織の利用部門やトップマネジメントも含めた組織にとっての成功判断基準としては不十分だと言えるのでは無いでしょうか?そう、当ブログの 【第3回】問題とは何か? で登場した 問題認識の相対性理論 のように、見方や立場が変われば、成功の定義も自ずと変わってくるのです!
プロジェクト計画に規定された「品質」「コスト」「納期」の通りに新システムのカットオーバーが達成できたとしても、ビジネスとして成功しないシステムは成功とは言えないと思います。逆に、システム化の目的が達成できさえすれば、多少「品質」「コスト」「納期」が計画通りでは無かったとしても、成功とみなすという判断基準だってあり得ますよね?
プロジェクトマネジメントの目的はプロジェクトを成功に導くことなので、「プロジェクトの成功」の定義を見誤るとあらぬ方向に向かってしまいます。したがって、組織としてしっかりとしたプロジェクト・サクセス・クライテリアを定義することをお薦めします。
それでは、次回もお楽しみに! < 前回 | 目次 | 次回 >
工藤武久
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
応援してくださる方は、クリックよろしくお願いします!
◆ 人気ブログランキング
◆ にほんブログ村
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
※1 『日経コンピュータ』2008年12月1日号、日経BP社
※2 Capers Jones(2010)『ソフトウエア開発の定量化手法第3版-生産性と品質の向上をめざして-』共立出版
Capers Jones(1997)『ソフトウエアの成功と失敗』共立出版
※3 「能力成熟度モデル統合」『フリー百科事典 ウィキペディア日本語版』2014年2月2日 (日) 07:37 UTC http://ja.wikipedia.org/wiki/能力成熟度モデル統合
「ISO 9000」『フリー百科事典 ウィキペディア日本語版』2014年7月12日 (土) 01:57 UTC http://ja.wikipedia.org/wiki/ISO_9000
※4 システム開発におけるWHY、WHAT、HOWについては、竹内博樹氏が「PM+BAの実践講座」の中で解説しているので、そちらも参考にしてください。
「PM+BAの実践講座【第19回】ITプロジェクトの成否は、IT化の構想・企画段階において「目的」を明確化出来ているか否かが全て!」