ソフトウェア開発の失敗確率と、原因が上流工程にあるという根拠データを確認してみた

「ソフトウェア開発プロジェクトの成功確率は3割」「ソフトウェア開発が失敗する原因は、往々にして上流工程（企画とか要件定義）にある」という都市伝説（？）に関して。これを説明する際によく紹介される業界データがやたら古かったり、引用があいまいだと感じることがあるので整理してみた記事。

日経コンピュータによるプロジェクト実態調査（2003、2008）

プロジェクトの成功率が

2003年調査 26.7%
2008年調査 31.1%

となっていて話題性が高いのと、記事のファインダビリティが高いのでよく引用されている印象。
また雑誌記事が元ネタなので（根拠は無いけど）ちょっと数字を作りにいっているイメージがある。

いっぽうで、プロジェクトの中で品質問題がどこで発生しているのかというデータも提示されている。

2003年調査
- 第1位：要件定義が不十分（35.9%）
- 第2位：その他（27.7%）
- 第3位：テストが不十分、移行作業に問題（21.9%）
2008年調査
- 第1位：テストが不十分、移行作業に問題（41.7%）
- 第2位：要件定義が不十分（36.7%）
- 第3位：システム設計が不正確（31.7%）、システム開発の質が悪い（31.7%）、エンドユーザへの教育不十分（31.7%）

こう見ると、引続き「要件定義が不十分」という要因はトラブルの主因であるとは言えそうだ。

ただ、データそのものが10年前のものなので、現在このデータを参考にするのはちょっといかがなものかと思う。

IPA/SEC ソフトウェア開発データ白書　(2017-2005)

SEC BOOKS：ソフトウェア開発データ白書2016-2017：IPA 独立行政法人情報処理推進機構

さて、一方でIPA/SECさんのデータ白書でもプロジェクト成否のデータが収集されている。こちらではどうか。試しに日経コンピュータの調査と対比できるように2005年、2008年、および最新2016年のデータを拾ってみた。

プロジェクトの成功率（QCD全て成功）は

2016年調査 67.1%
2008年調査 63.0%
2005年調査 46.1% ※ただしこの年の調査はQCD達成基準は不明確

となっている。前述の日経コンピュータ調査は（おそらく）発注者視点であることに対して、こちらの調査は受注者（ベンダー）視点であることが成功率の乖離の原因なのだろう。そういう意味では、例えば以下のデータのほうが、発注者視点で見た場合のプロジェクトの成功率をより明確にあらわしているのかもしれない。

顧客満足度に対するベンダ側の主観評価で「十分に満足している」は

2016年調査 31.2%
2008年調査 28.8%
2005年調査データなし

となっている。

また、プロジェクトの成功という観点ではないが、品質観点で以下のような分析もあるようだ。

テスト密度と、信頼性の高さは有意な関係にない

テスト検出不具合密度が低いほうが、信頼性が高い傾向がある

テスト検出能率が低いほうが信頼性が高い傾向がある

つまり、テスト開始時点での作りこみ品質の高さが、信頼性に直結する

よって、信頼性を確保するには上流工程の注力が重要である

ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」を公開～定量的データに基づくソフトウェア開発のプロセス改善を目指して～：IPA 独立行政法人情報処理推進機構

日本情報システム・ユーザ協会（JUAS）企業IT動向調査報告書（2017-2003）

企業IT動向調査 | JUAS 一般社団法人日本情報システムユーザー協会

最新版は一般公開されていないのだけれども、2016年の結果の一部は"SEC BOOKS：ユーザのための要件定義ガイド～要求を明確にするための勘どころ～"で引用されているのでそこからピックアップ。

プロジェクトの成功率そのものは示されていないが、同報告によれば

年度別システム規模別システム開発工期遵守状況

開発規模：500人月以上

2015年度･･･予定通り完了 21.9% ある程度は予定通り完了 35.8% 予定より遅延 42.3%

2009年度～2014年度平均･･･予定通り完了 19.7% ある程度は予定通り完了 35.7% 予定より遅延 44.5%

2004年度～2008年度平均･･･予定通り完了 11.1% ある程度は予定通り完了 36.9% 予定より遅延 52.1%

年度別システム規模別システム開発の品質状況

開発規模：500人月以上

2015年度･･･満足 14.2% ある程度は満足 59.6% 不満 26.1%

2009年度～2014年度平均･･･満足 14.1% ある程度は満足 56.7% 不満 29.2%

2004年度～2008年度平均･･･満足 8.2% ある程度は満足 61.8% 不満 30.2%

（出典：日本情報システム・ユーザ協会「企業IT動向調査報告書2016」）

とのことである。

また、工程遅延理由のアンケート結果のうち55%が要件定義の問題となっており、具体的には

システム化目的不適当
RFP内容不適当
要求仕様の決定漏れ
開発規模の増大

が工程遅延を引き起こしているという記載もあった。

Standish Group Chaos Report（1995-2016）

ここまでは国内システム開発に関する情報だが、グローバルでは有名どころとしてStandish Groupが出しているChaos Reportがある。というか、ITプロジェクトの低い成功率を最初に示して話題をさらった元ネタという印象。リサーチ自体は非公開の模様だが、InfoQに解説記事があがっている。

Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch

これによれば、

2015年成功（Successful）29% 課題あり（Challenged）52% 失敗（中止）19%
2011年成功（Successful）29% 課題あり（Challenged）49% 失敗（中止）22%

となっていたりする。

まぁ、他にデータが無いならいざしらず、国内におけるITプロジェクトの成功率を語るのなら、Chaos Reportを参照するのはちょっと筋が悪いだろう。

まとめと感想

発注者の観点から見るのであればJUASのレポートが参考になる。
- 利害関係者すべてが満足するプロジェクトの成功は引き続き難しい。計画期間内に十分な品質のソフトウェア開発を完了させられる確率は2割以下である。
受注者の観点から見るならIPA/SECのデータ白書が参考になる。
- ベンダー観点でのプロジェクト成功確率は6割強であり、適切にベンダを選定し発注したのであればプロジェクトはちゃんと完了する。
上記を踏まえると、プロジェクトの成否を決めるのはベンダーへの発注以前、すなわち計画や要件定義といった上流工程がポイントであろう。
日経コンピュータの調査はけっこう古いので、現時点ではあまり参考にしないほうが良い印象（個人的な見解）