プロジェクトの成功と失敗 | イノベーションマネジメント株式会社

プロジェクトにはリスクがつきものである。誰もがプロジェクトを成功に導こうとするが残念ながら成功する保証はどこにもない。プロジェクトの成功確率を話題にすると多くの人が興味を示すが、一概に成功確率を言うことはできない。なぜなら、プロジェクトの成功確率は扱うプロジェクトの特性のよって大きく異なるからである。

ハイリスクプロジェクトの典型は、と言われれば、真っ先に思いつくのが医薬品開発プロジェクトである。どこからプロジェクトを定義するかによって成功確率は異なるが、人への投与が開始される第一相臨床試験から数えて薬が承認されるまでを見てみると、その成功確率は約10％程度に満たない。さらに医薬品開発のプロジェクトは臨床試験から承認まで5～7年はかかるという長期のものであり、そのため製薬企業の研究者で一生のうち一度も自分の担当した医薬品が承認されなかった人もいるくらいである。一生は働いて、自分の手がけた薬が世に出ないなんて、想像し難い事実ではないだろうか。それほど、医薬品開発プロジェクトの成功確率は低いものなのである。私の知る限り、他の業界でこれほど低い成功確率を持つ業界は石油業界くらいしか思いつかない。石油の井戸を掘るにあたっては様々な地質データをもとに分析し、地質探査・解析の結果、油田の層があると判断して掘削を行うが、採算の取れる油田の層に上手く当たる確率が 10％程度でしかない。地質学や解析技術も発達し、衛星からの情報なども手に入るより、石油の存在しそうな場所を探索する技術は格段に進歩してきているが、最新のハイテク機器を用いても如何せん、本当の姿は地下を掘ってみるまではわからないというのが現状である。たとえ石油が出たとしても熟成が足らず、あと1000年くらい寝かせないと使えないというケースなどもざらなのである。

医薬品開発も石油掘削も成功の確率は低いが、その確率はプロジェクトそのものが持っているサイエンス的なリスクに依存している。医薬品では毒性や副作用が強かったり、薬の有効性が低かったりすると新薬としては承認されずプロジェクトは中止される。石油掘削では、掘っても石油ではなかったり、石油として熟成が不充分だったり、石油として使えても十分な埋蔵量がなかったりすると採算に合わないことで油田開発のステップには進まず中止される。どちらもマネジメント的な失敗という以上にプロジェクト自体が持つサイエンス的な失敗であり避けることは難しい。それが故に、この業界の一部には、サイエンス的なリスクが圧倒的に大きいため、プロジェクトマネジメントをやっても意味がないという意見を言う人がいることも事実であるが、逆に、だからこそプロジェクトマネジメントが重要なのだと主張する人もいる。

これについて、ある製薬企業の開発部長の言った言葉は今でも覚えているが、「芝尾さん、サイエンスリスクが高いからプロジェクトマネジメントをやっても意味がないなんてとんでもない。医薬品開発はサイエンスリスクが大きいプロジェクトだからこそ、プロジェクトマネジメントが重要なのです。数少ない成功のポテンシャルのあるプロジェクトをどのようにして事業として大きな成功に結びつけるのか、また失敗するとわかったプロジェクトをいかに早く断ち切るか、まさにマネジメントの問題でありプロジェクトマネジメントの良し悪しが事業に大きく影響を与えるのです」。私も同じ意見である。医薬品の場合、例え効果が認められてもその開発に時間がかかりすぎることで失敗することもある。同じ作用機序を持つ薬が他社に先を越され薬効が同等かそれ以下であると薬が承認される可能性が格段に下がり、下手をすると承認されずそれまでの開発投資はすべて無駄になることさえあるのである。ビジネスの世界は競争の世界でもあり、製薬業界といえどもその例外ではない。他社との競争の中でビジネスをやっている以上、プロジェクトマネジメントの優劣は製品開発の成果に大きな影響をあたえるのである。サイエンスの優劣も競争であるが、マネジメントの優劣も常に競争にさらされていることをマネジメントの方々は常に理解しておくことが大切である。

さて、プロジェクトの失敗ということでいつも話題に事欠かないのがソフトウエアプロジェクトである。どのくらい失敗しているのか、Standish Groupが毎年Chaos Reportを発表している。1996年のデータと2009年に発表されたデータを比較してみることにする。

1996年～　2009年

成功・・・・・・・　32%
失敗・・・・・・・　44%
中止・・・・・・・　24%

約10年間で随分改善されたとは言うものの、未だに成功するプロジェクトは1/3程度に過ぎず、残りは目標を達成できない（納期遅れ、コスト超過、機能不足のうち、一つ以上が発生している）か、プロジェクトを途中で止めてしまうという状況である。

ソフトウエアプロジェクトはそれほどハイテクなプロジェクトではなく、労働集約的なプロジェクトの代表であり、サイエンス的な問題が失敗の原因となることはほとんど無い。失敗の多くの原因は人に関わることでばかりである。2000年のハーバードビジネス・レビュー別冊によれば、プロジェクトの失敗原因として以下の項目が挙げられている。これからもわかるように、サイエンス以外の原因がプロジェクト失敗に繋がっている。

プロジェクトマネジメント･･･ 34.4％
スキル･･･ 20.0％
製品･･･ 17.1％
顧客･･･ 7.1%
外注･･･ 7.1%
管理者の支援･･･ 4.3%
その他･･･ 10.0%

では、なぜソフトウエアプロジェクトの失敗がそれほど大きな数字を占めるのかであるが、これはソフトウエアの特徴に大きく依存している。いろいろ特徴はあるのであろうが、もっとも際立つ特徴は「見えないプロジェクト」であるということである。車やテレビなどハードを扱うプロジェクトは最終系を誰もがイメージでき、成果物も見えるものをベースに議論ができるため、お互いが同じイメージと理解を持ちながら話すためプロジェクトにおける判断は落ち着くべきところに落ち着く。だが、ソフトウエアプロジェクトはなかなかモノが見えず、イメージもしにくい。この見えないという特徴がソフトウエアプロジェクトを難しくしている最大の要因であると言える。

もう一つソフトウエアプロジェクトを難しくしている理由は、変更が容易にできるという柔軟性にある。ハードの場合は簡単に仕様を変えるわけにはいかない。物理的な問題や、作る手間など考えると事前に決めたものをその通りに作るしかなく、途中の変更は相当な注意を払って行われる。しかし、ソフトウエアの最終成果物はソースコードであり、ソースコードが変われば機能も変わるという特徴を持つ。ソースコードに手を加えれば機能が変わり、変更も可能なのである。だがこれは諸刃の剣であり、変更しやすいということは、最後まで仕様が変えられると誤解もしやすく、ユーザの要望を押し留めることも容易ではない。このことがソフトウエアの要件の拡大化、仕様変更の頻発を生じさせプロジェクトを混乱に陥らせる最大の原因となっている。

ソフトウエアプロジェクトの失敗の原因は他プロジェクトの参考にもなる。見えないもの、変更がやりやすいプロジェクトを扱う場合は要注意であり、リスクが高いと最初から頭に入れて、そのための対応や方針を決めて取りかからなくてはならない。

最後に「プロジェクトの成功」についてもう少し掘り下げて考えてみる。プロジェクトが成功したか失敗したか何を持って判断しているのだろうか？これまでMOT（Management of Technology）の講義において、このことを話題にして多くの受講者に尋ねてきたが、多くのプロジェクトにおいて「成功」の基準となるものが明確に存在していなかった。基準がないということは判断ができないということであり、成功したのか失敗したのかわからないプロジェクトが世の中にごろごろしているということに等しい。失敗とわかるプロジェクトは誰が見ても明らかに「大失敗」とわかるほどの失敗をしたプロジェクトであり、多くのプロジェクトはあいまいの中で「成功」の分類に入れられるケースが多い。このことは大きな課題である。プロジェクト成功の基準とは、プロジェクトの意図した目的が確実に達成されたかどうかを測る物差しである。成功の基準がないということは本来達成すべき目標に到達できたかどうかがわからないということであり、さらにはプロジェクトの結果をもとに反省ができないということを意味する。何も全てのプロジェクトが成功するわけでなく、失敗プロジェクトも多く存在する。しかし、成功の基準を持たず、計測もしていないということは失敗プロジェクトから何も学べないということであり、組織としての学習ができないことを意味する。このことは非常に大きな損失である。成功プロジェクトだけでなく、失敗プロジェクトからも学べることによって組織は多くの知識を獲得でき、強くなっていくのである。

Column専門家によるお役立ち情報

第3回プロジェクトの成功と失敗