このように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年から疎かにされがちであった要件定義に対し、どう手を打てばよいのか。
