繰り返されるシステム開発の失敗

　66億円――。これは、上場会社の2年間の有価証券報告書、適時開示を検索して、「システム開発中止」と判断したことで被った損失額を筆者が算定した結果です。表に出てこないもの、不具合がありながら使用しているものを含めれば、おそらく金額はこの何倍にもなるでしょう。たった2年で、少し調べただけでこんなにあるのですから、日本全体でいったいいくらのお金がシステム開発によってドブに捨てられてきたのでしょうか？　考えただけでも背筋が凍ります。

　もちろん、企業もお金を捨てたくて捨てているわけではありません。経営や業務に役立つシステムをつくろうと真剣に取り組んでいます。それなのにドブ捨て現象はいまだ後を絶ちません。

　よく、「システム開発を成功させるには、要件定義をうまくすることが大事だ」と言われます。要件定義は、「この画面でこれができるようにしてほしい」「これとこれを集計して印刷したい」など、ユーザーのきめ細かな個別の要求をかなえる、重要なプロセスなのはまちがいありません。しかし、システム構想や業務改革のように、大胆に業務や組織のしくみを変え、新しいことや斬新なアイデアを考えだすところではありません。

　もし、要件定義でそのレベルの議論を始めてしまえば、収拾がつかなくなります。たとえれば、それは新婚夫婦が建設途中の新築マンションを購入してから「やっぱり戸建てがいい」と言いだしたり、2階建ての戸建ての基礎部分ができたあとに「2世帯で住むことになったから、悪いけど3階建てにしてよ」と注文したりするようなことなのです。

システム開発を成功させるカギとは何か

　事前に決めておくべきことが決められていない、ダメな構想の下では、いくら要件をしっかり定義したところで意味がないのです。システム開発を成功させるカギは“システム構想”にあります。

　実際、筆者がシステム実務者に「システム構想をどう思うか」アンケートをとったところ、システム構想を「とても重要」と回答した人が9割、「まあまあ重要」と回答した人が1割でした。回答者全員がシステム構想を重要だと答えています。

なぜ、システム構想がうまくいかないのか？

　システム構想が重要なことは、ユーザー企業もベンダーもわかっています。でも、うまくいかないのです。それはなぜか。原因は大きく次の3つです。






　このような事態を防ぎ、優れたシステム構想をつくるためには、どうしたらいいのでしょうか？　それは、システム開発プロジェクトから「システム構想」を完全に切り離すこと。つまり、システム構想を経営の単独プロジェクトにするのです。

【次ページ】システム構想を「経営の単独プロジェクト」に切り離せ