システム開発の成功率3割についてビル建設と比較してみる

2019/04/10

システム開発プロジェクトの成功率をビル建設に当てはめると10棟のうち7棟が立たない

システム開発プロジェクトの成功率はわずか3割という定説があります。

実に7割のプロジェクトが、途中で行き詰まりやむなく中止したり、完成してもシステムが動かないのです。
ビルの建設であれば10棟のうち7棟が立たない計算ですが、現実の世界では勿論そんなことはありません。

せっかく投資したにもかかわらず、失敗したものが全体で7割に達するというのは、企業経営の投資項目の中でもワーストのほうに飛びぬけています。
その理由についてビル建設と比較しながら考察してみましょう。

作っているものが目に見えない

両者を比べるうえで一番の違いは、ビル建設の成果物であるビルは目に見える、システム開発プロジェクトの成果物であるプログラムは目に見えないということです。ビルを建てる場合は設計者が書いた図面に、建物の全体構造から各室の間取りや水道管の位置まで表現されます。建設会社はそれをもとに作ります。システム開発プロジェクトでも設計者が書いた設計図をもとにプログラマが作っていくのは同じです。

しかしシステム開発プロジェクトがビル建設より大変なのは作っているものが目に見えないことです。

それでもクライアントとシステム開発会社は意思疎通しないと仕事になりませんので、文章や絵やチャートなど手段で表現しようと試みますが、如何せん「目に見えないものを一生懸命頑張って表現している」ことに変わりありません。
このことはお互いのコミュケーションに齟齬が紛れ込みやすく、間違いを発見しづらいことにつながります。

ビル建設であれば作業現場を目で見れば、いまどれくらい作業が進んでいるかは素人でも一目瞭然です。一方システム開発プロジェクトの作業現場を覗いても、作っているプログラムが今どれくらいできあがっているのかは分かりません。
仕事の進み具合はチャートや進捗率で掴むしかなく、もし報告の時点で間違っていても即座に気付けないのです。

「システム開発会社はクライアントの業務を知らない」が出発点

システム開発プロジェクトは「システム開発会社自身が依頼主の業務を知らない」ところから始まります。もちろん依頼主から業務についての情報を引き出しながらシステムの仕様を作りますが、どこまで頑張っても「聞いたことの中から一生懸命理解しようとする」ことに変わりありません。

またクライアントにとって自分たちの業務は空気のように当たり前のことですが、当たり前のことを噛んで含んで、それを知らない相手に伝えるのは至難の業なので、情報量が満たされることはありません。

つまり自分たちの経験や知識を再利用しやすいビル建設に比べて「まず依頼主の業務の理解」から出発するシステム開発プロジェクトはどうしても高リスクなのです。

ITは想像以上に複雑である

ITの真髄として見た目は「出来るだけシンプル」という共通ルールがあります。

たとえば銀行のATMは高齢者の利用を想定してボタンの数はできるだけ少なく、一つ一つのボタンはできるだけ大きく、となっています。Googleの検索画面にいたっては真ん中に検索窓が一個あるだけです。しかし見た目がシンプルだからと言ってその裏側もシンプルというわけではありません。ITとしてはその裏側に膨大なロジックがぎっしりと詰まっています。つまりATMやGoogleの画面を見て想像するよりも実際には数万倍も複雑なのです。

またITは１行１行のプログラム記述の積み重ねで構築していきます。その一つ一つはコンピュータへの命令なので、各行が等しく重要です。
ビル建築ではネジを一本入れ忘れても、建物が傾くようなことはないでしょう。しかしITのプログラムではどこか1文字間違っているだけで動かなくなることがあります。動かなくなるならまだしも金額を数え間違うようなことがあれば、もっと事態が深刻になります。

テストに想像以上の手間と時間がかかる

システム開発プロジェクトにおける投下資金の3割はテスト工程に費やされると云われます。
テストというのはシステムが実際に設計どおり動くかどうか確かめる工程です。また開発直後のシステムには「プログラムの間違い」が至る所にあります。この間違いを直してプログラムが正しく動くようにする工程でもあります。

さてテストの工程が重要であるとしても、なぜ投下資金の3割も費やされるのでしょうか。もし建設現場で起きる施行ミスの場合であれば、その半分もかからないでしょう。例えば作業員が配管の位置を間違えたとしても配管をし直して完了です。

ところがITの難しいところは「どこが間違っているかはテストしてみないと分からない」ことです。通常のシステム開発プロジェクトでは、いくつかの固まりに分けて開発したプログラムを最終的に一つにつなげて完成させます。ひとつひとつの固まりでは間違いが出てこなくても、全体を繋げてみて始めて分かる間違いがあります。また一箇所を直すと、別のところで影響が出るかも知れません。

以上のことから、ITは一見、自分たちの常識観に収まらない要素を兼ね備えています。
これが発注者が知っておくべきポイントとなります。

この記事を書いた人について

谷尾薫

オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。