• ビジネス
  • xTECH
  • クロストレンド
  • 医療
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • 日経BP

プロジェクト失敗の理由、15年前から変わらず

1745事例を調査、成功率は52.8%

2018年3月8日(木)

  • TalknoteTalknote
  • チャットワークチャットワーク
  • Facebook messengerFacebook messenger
  • PocketPocket
  • YammerYammer

※ 灰色文字になっているものは会員限定機能となります

無料会員登録

close

 情報システムを開発し、導入するプロジェクトの成功率はどのくらいか。

 この疑問に答えるため、専門誌「日経コンピュータ」は15年前の2003年から調査を始め、2008年と2018年にもそれぞれ実施した。3回の調査によって、15年間でプロジェクトの成功率がどう推移したか、失敗の理由は何か、といったことが明らかになった。

 結論を最初に書くと15年間でプロジェクトの成功率は上がっていると見てよい。一方、失敗の理由は15年前も現在も同じだった。成功させる企業が増えている一方、プロジェクトの進め方について何も改善できず、15年前から変わらない理由で失敗する企業がいる。

15年前のプロジェクト成功率は26.7%

 まず、プロジェクト成功率の推移を見よう。2003年9月に実施した1回目の調査によると、情報システム導入プロジェクトの成功率は26.7%だった。この数字は次のようにして求めた。

 1746件の回答者(企業や団体の情報システム部門)が直近(2002年度または2003年度)に動かしたシステムの中から最も規模が大きかったものを1件選ぶ。その開発プロジェクトについて品質、コスト、納期の3点を順守できたか否かを自己評価してもらい、それに基づいて順守率を出す。2003年調査の場合、順守率は品質が46.4%、コストが76.2%、納期が54.9%だった。

 品質、コスト、納期の3点すべてを順守できたプロジェクトを成功したと定義し、成功率を計算した。それが26.7%であった。

 この定義でプロジェクトを成功させることはなかなか厳しい。例えば品質とコストについて順守できたとしても納期より遅れてしまった場合、そのプロジェクトは失敗したことになる。プロジェクトの品質には満足度を含める。「計画通りのシステムが完成」し、しかもそのシステムに「満足している」と回答した割合を品質の順守率にした。

成功率は上がっている

 2003年の結果に合わせて、2008年(同年8~9月に調査)と2018年(2017年12月~2018年1月調査)の結果を列挙してみよう。

●2003年(回答者数1746件)
プロジェクト成功率:26.7%
品質の順守率:46.4%
コストの順守率:76.2%
納期の順守率:54.9%

●2008年(回答者数814件)
プロジェクト成功率:31.1%
品質の順守率:51.9%
コストの順守率:63.2%
納期の順守率:54.6%

●2018年(回答者数1201件、プロジェクト件数1745件)
プロジェクト成功率:52.8%
満足度:78.5%(経営層)、79%(利用者)
コストの順守率:81.8%
スケジュール(納期)の順守率:72.3%

 2018年の調査から「品質」に換えて「満足度」を採用した。情報システムについて「経営層(あるいは利用者)が満足している」、「経営層(あるいは利用者)がやや満足している」と回答した割合を満足度にした。

コメント3件コメント/レビュー

と思ったら、既にそうしたコンサル業は既に多数あるようだ。(2018/03/09 10:17)

オススメ情報

「経営の情識」のバックナンバー

一覧

「プロジェクト失敗の理由、15年前から変わらず」の著者

谷島 宣之

谷島 宣之(やじま・のぶゆき)

日経BP総研

一貫してビジネスとテクノロジーの関わりについて執筆。1985年から日経コンピュータ記者。2009年1月から編集長。2015年から日経BP総研 上席研究員。

※このプロフィールは、著者が日経ビジネスオンラインに記事を最後に執筆した時点のものです。

日経ビジネスオンラインのトップページへ

記事のレビュー・コメント

いただいたコメント

と思ったら、既にそうしたコンサル業は既に多数あるようだ。(2018/03/09 10:17)

こうした問題は我が社でも最近増えてきた。ユーザーは日頃の業務の構造や目的目標をクリアに意識していないし、体系化する事もしない。システム部門と開発ベンダーは対象業務に関する知識が無い。要件に含まれるべき潜在ニーズが見える化されておらず、実現する手段を開発しようにも何をどうすれば良いか分からないまま(分かったつもりで)開発がスタートするために、途中で不都合が露見して手戻りが多発するし、どうにか作ったツールも不評を買う。どんなソフトウエア開発にも予見しにくいトラブルはあり、計画どおりに行くことは稀だが、それにしてもこれほどの割合でそうした「失敗案件」が発生していると言う事は、そこに新たなイノベーションが生まれる余地が有るだろう。ソフトウエア開発にかかる前段階で、こうした問題を解決する手段が見つかれば市場が見込まれそうだ。要件定義のAI化なのか、経験を蓄積した人による要件定義専門のコンサル業なのか、手段はいろいろ考えられるが、いずれにしろ解決手法を提供できればそこには市場がありそうだ。(2018/03/09 10:14)

メーカのOBです。1991年、幸運にも、デミング博士の話を聞く機会に恵まれた。博士は、品質はトップマネージメントが創ると力説していた。博士の考えに沿えばシステム開発の品質管理は経営問題でもある。
さて、10数年前、事業の突発的な事態に対応するため、数百万件の情報を扱う問い合わせ対応システムを、短期間で稼働させる全く新規のシステム開発を指揮した。その際、プロジェクト最初の作業としてマニュアルのドラフト版作成を命じ、これを要件定義とした。ドラフト版は、ハード、ソフトの全域にわたって作成、オペレータ操作画面の雰囲気は同じ、プルダウンリストは可能な限り確定とした。これらの作業は、嫌がられたが、きわめて短期間でシステム稼働となった。マニュアルドラフト版があることで、早期に、現業部門オペレータからの細かい要望を拾うこと、業務フロー妥当性確認することができた。更に、システム開発途中からオペレータ作業環境の構築等を並行して行ことができ、稼働初日より高負荷での業務処理を実現した。意識、無意識に関わらず要件定義の優先度を下げる、要件定義範囲を限定する、はデスマーチへの第一歩である。要件定義こそ品質管理を実践すべき。(2018/03/08 08:24)

ビジネストレンド

ビジネストレンド一覧

閉じる

いいねして最新記事をチェック

日経ビジネスオンライン

広告をスキップ

名言~日経ビジネス語録

そもそも後藤という人間を理解してもらわなくてはならない。

後藤 高志 西武ホールディングス社長