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

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

　この疑問に答えるため、専門誌「日経コンピュータ」は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年の調査から「品質」に換えて「満足度」を採用した。情報システムについて「経営層（あるいは利用者）が満足している」、「経営層（あるいは利用者）がやや満足している」と回答した割合を満足度にした。

　このように2018年の調査はそれ以前の2回と比べ、やり方を変えている。回答者が2つのプロジェクトについて答えられるようにしたため、1201人の回答者から1745件のプロジェクトについて回答を得た。1201人の所属先は一般企業・団体の情報システム部門が60.5％、一般企業の業務部門が16.5％、IT（情報技術）を生業にする企業が23％。一般企業とはIT企業ではないという意味である。これに対し、2003年と2008年の回答者は一般企業の情報システム部門だった。

　調査のやり方を変えたことから「日経コンピュータ」は過去の調査結果との比較はせず、2018年調査の報告記事に『半数が「失敗」』と見出しを付け、成功率52.8％、失敗率47.2％という結果を報じた。

　確かに「半数が失敗」なのだが「半数が成功」とも言える。2018年の回答者の6割は情報システム部門であり、2003年と2008年の回答者とほぼ同じ集団だと強引に見なせば、2003年の26.7％、2008年の31.1％、2018年の52.8％という結果から、成功率は上昇していると言ってよいだろう。

　成功率が上がった理由の一つはプロジェクトにおける定量管理の普及だと見られる。2008年の調査結果によると、品質について定量管理を入れた割合は回答者の18％、コストが14.8％、納期（スケジュール）が29.9％だった。5年前の2003年ではそれぞれ8.7％、5.1％、12.8％に過ぎなかった。

　2008年と2003年との比較から、5年間で定量管理が進み、成功率が上がったと2008年の調査結果記事は説明していた。2018年における定量管理の実施率は明らかではないが10年間でさらに広がったと考えてよいだろう。

失敗理由の筆頭はシステムの「要件定義が不十分」

　成功率が上がったものの、「半数が失敗」している現状がある。2018年の調査で日経コンピュータは失敗したプロジェクトの失敗理由を調べている。それによると、満足を得られなかった理由の筆頭は「要件定義が不十分」、コストを順守できなかった理由の筆頭は「追加の開発作業が発生」、スケジュールを順守できなかった理由の筆頭は「システムの仕様変更が相次いだ」だった。スケジュールを守れなかったプロジェクトで最も苦労した工程を尋ねると「要件定義」が筆頭に来た。

　以上の失敗理由は2008年、2003年の調査結果とまったくと言ってよいくらい同じである。2008年の調査結果で順守できなかった理由の筆頭を見ていくと、品質が「テストが不十分、移行作業に問題」、コストが「追加開発」、納期が「要件定義が長引く」だった。品質を順守できなった理由の2番目に「要件定義の不備」が来ていた。

　2003年調査結果で順守できなかった理由の筆頭は、品質が「要件定義の不備」、コストが「追加開発」、納期が「要件定義が長引く」だった。

　3回分の調査結果を見ると、プロジェクトが失敗する理由は要件定義の不備に集約できる。要件定義とは導入する情報システムで実現したい事項を整理し、決めることだ。

　要件を曖昧にしたままプロジェクトを進めてしまうと、経営者や利用者が真に求めていたシステムができあがらず、品質ないし満足度が下がる。プロジェクトの途中で要件に問題があると気付いた場合、要件定義をやり直し、仕様を変更したりするため、スケジュールが遅れる。修正後の要件に基づいて追加開発をすればコストがかさむ。

　日経コンピュータは2018年の調査報告記事で「まず必要なのは要件定義を疎かにしないこと」と書いていた。2003年から疎かにされがちであった要件定義に対し、どう手を打てばよいのか。

まず業務の構造を整理する

　有効な対策はある。各業務部門の担当者が企業の内外にある業務の構造を整理し、全体の構造を頭に入れてから要件を話し合うことだ。各業務がそれぞれどういう関係にあるのか、各業務でどのような情報が必要なのか、そうしたことが整理されると、業務改革の案がおのずと出てくる。「業務をこう変えよう、そのためにはこういう情報がほしい」という話に進み、システムの要件がまとまってくる。

　全体の構造を整理し、把握しておかないと、各業務部門の担当者が自部門の要求だけを出すことになる。ばらばらの要求を並べただけではシステムの要件定義にならない。そもそも「情報システムを作るから要件を定義せよ」といきなり言われても各業務部門はなかなか答えられない。

　2018年の調査結果を見るとプロジェクトの成功率が低い傾向にあるシステムの分野は「CRM（顧客関係管理）・SFA（営業支援）」と「SCM（サプライチェーン管理）・生産管理・物流管理」であった。後者は複数の業務部門さらには協力会社などが関わるため、全体構造を把握していないと要件を決めづらい。

　一方、前者のCRM・SFAは顧客対応部門や営業部門といった特定部門が使うシステムだが、どちらの部門も多忙であり、要件を決めにくい。やむを得ず、情報システム部門が要件を仮置きして開発を進めると、出来上がってきたシステムを使った途端、現場は「使えない」「入力が面倒だ」などと反発し、要件定義のやり直しや追加開発が発生する。

　CRM・SFAについては「例えばこういうシステムはどうか」と現場に試作品を早めに見せ、意見を求めるやり方がよいとされている。その場合でも、業務の全体構造が整理されていれば「この情報とあの情報を組み合わせると顧客対応や営業活動に役立つのではないか」といった仮説が見えてくるので、より的確な試作品を提示できる。

　「各業務部門の担当者が企業の内外にある業務の構造を整理し、全体の構造を頭に入れてから要件を話し合う」手法は色々あり、日本生まれで実績を上げているものもある。ただし、なかなか普及しない。

　効果が出る手法であっても、業務知識を持つ社員を集め、全体構造を整理、記述していくと聞かされた途端、業務部門は及び腰になるからだ。「業務を説明するから情報システム部門が要件をまとめてくれ」という姿勢の現場部門が多い企業はせっかくの手法を活かせない。

システムに不満を持つ経営者や業務部門がすべきこと

　紹介した3回分の調査において、導入した情報システムの品質や満足度を情報システム部門が主に評価している。本来であれば、経営者や業務部門の声を聞くべきだが、調査の都合上、情報システム部門に代理で回答してもらっている格好だ。

　したがって情報システム部門が「成功」と見なしたプロジェクトを経営者や業務部門が「とんでもない」と批判することが有り得る。仮にそうであるなら、経営者や業務部門は「企業の内外にある業務の構造を整理し」それを「頭に入れてから要件を話し合う」活動にぜひ取り組んでほしい。

　情報システムは業務改革を支えるものだから、業務に責任を持つ人がプロジェクトに参画して要件を取りまとめ、プロジェクトの進行を見守ることが欠かせない。情報システム部門ましてやIT企業に任せきりにする企業はプロジェクトを成功できない。