なぜ８割の企業がシステム開発に失敗するのか？

2018/03/17

システム開発案件の8割が失敗する理由について、依頼者（顧客企業）が注意すべき点に絞って記載します。実はうまくいかないシステム開発にはある共通点があります。

うまくいかないシステム開発の共通点

1. システム開発を「物品調達」と同列に扱ってしまう。

システムというのは、組織があり、運用があり、企業をとりまく市場環境があり、それらの中で「生態系」として存在を成すものです。物品調達という発想で、ハコモノを入れる、単にシステムを外注する、という考え方では、当然立ち行かなくなります。

2. 機能開発に目が行きすぎてしまう。

価値提供や問題解決の全体シナリオにシステムを落とし込むべきところ「さてどんなシステムを作ろうか」と主客転倒するケースです。目的が無いに等しいため作業が迷走します。

3. システムがブラックボックス化している。

上の逆ケースで、プランの中でシステムだけがブラックボックスとして孤立している場合もあります。ベンダに提案を頼んでも評価できないため、迷った挙句安い見積りを出したベンダに発注することになります。その場合、シナリオと整合性の取れたシステムが出来あがることはまず期待できません。

4. 投資に対するリターンの期待値があいまい。

リターンをはっきりさせないと投資が縮小均衡になりがちで、効果を出せるところまでいかずに終わってしまうことがあります。物品調達の感覚で予算を組むと「どうしても安く」になってしまいます。リターンを数字で見込むのが難しければ、人材採用の視点で投資額を決めるべきです。

5. サービス稼働率に対しての指標があいまい。

サービス稼働率に対しての指標は経営マターですが、経営陣に対してはおろか、現場でもあいまいなケースが見受けられます。たとえばシステム稼働率が99.5％の場合、1ヶ月の停止時間はおおむね3時間です。このような概念をもとに影響度を考えるべきところ、かなり高価なインフラ費用を強いられている案件を数多く見受けます。

システム開発会社に対する質問事項を考えることは、依頼者にとっては「自分たちは何を発注するのか？」を自問自答することにつながります。下記の話しも参考にしていただけると幸いです。

どんな風にするのかまず決めること

システム開発の成否は準備段階で80％が決まります。
このことは、インターネットで検索すると、調査結果がアチコチに書かれています。
実際の集計はもっと控え目な数字ですが、私の感覚値でいえば80％です。

これは驚くべき数値です。普通にやればまず失敗するということです。

そして興味深いことに、開発したシステムが失敗に終わったとしても、そのシステムを開発した会社の技術レベルが低いということではありません。むしろ個々の技術者は非常に優秀といえます。システム開発で結果に大きな差を及ぼすのは、「開発対象となるシステムが備えるべき機能要件をどれだけ事前に想定できたか」に尽きます。
もっと分かりやすく言うと、「そもそもどんなシステムにしたいのか？」を決めることです。

この作業工程のことを「要件定義」といいます。

専門家の意見によると、要件定義力は発注側が備えるべき能力と言われていますが、社内に情報システム部門がある場合は別として、実際のケースに照らし合わせるとほとんど無理でしょう。

身近にあることで例えるなら

これは、家造りに例えるとすぐに分かります。「家を建てる」というイベントは一生のうちそう何度も巡り合うことはありません。
経験値と知識を蓄積するにも限度があります。それなのに施主であるあなたが、誰の手も借りずに、住まいのコンセプト作りから機能要件までを定めることができるでしょうか？

それは、おそらく無理です。ハウスメーカーや工務店、設計事務所など、まず専門家に相談することでしょう。そして専門家と打ち合わせを重ねながら、欲しい家の全体像や、絶対に満たしたい条件、逆にあきらめなければならないことと、が浮かび上がってくるはずなのです。

おそらく専門家に相談する前は、いろいろ想像や夢がたくさんあることでしょう。「それぞれの間取りは広く取りたい」、「書斎が欲しい」、「子供にはそれぞれ専用の個室を持たせてあげたい」、「玄関ロビーは吹き抜けにしたい」、「台所は広く機能性豊かに…」、「お風呂はゆったり足が延ばせること」、「欧風なインテリアデザイン」、「バーベキューができる庭」など挙げればキリがありません。

ところが実際には、予算や引越期日の制約で、やりたいことのいくつかは現実と折り合いを付けざるを得なくなります。
そこで「まず優先順位を付けましょう」と専門家に言われると、「そもそもウチの家族にとって一番大事なことってなんだろう？」などと深く考えたりすることもあるはずです。そうやって専門家からほかの事例などを教わりながら、やり取りを重ねていくうちに、当初思い描いていたこととは、ずいぶんかけ離れたイメージが出来上がったりします。

つまり専門家から知恵やノウハウを得ながら、時には導かれながら、「そもそもどんな家にしたいのか？」を決めていくのです。これは家造りの現場では、普通に起こっている出来事です。

思いもよらない提案をしてくれた中古車屋さんの話

少し脱線しますが、つい最近、私が感心した出来事があります。

中古車を探していたときのことです。私が住んでいる地域は、最寄駅から20分ほど離れていることや、郊外型のショッピングセンターが発達していることより、日常生活のうえで車が必須です。しかし私が車で出かけてしまうことが多いため、家内が買い物などに自由に使えるためにもう一台が必要でした。

目的からして、欲しいのは中古の軽自動車です。そこでインターネットで下調べをしたうえで、3件の店を廻りました。
そして3件目の店でのことです。

営業所の若い営業マンは、私が予め伝えてた要望にそって、その条件に合う車を紹介してくれました。
ここまでは今までの2件の店と同じ対応です。そこで試乗してみて思ったのは、「まあどれも似たり寄ったりだな」という感想です。どうもいまいちピンとこないが、そろそろどれかに決めなきゃと感じ始めていました。

営業マンの彼にも、思ったとおりのことを告げました。
そこからの彼の対応が見事でした。

「この車種は新古車がけっこう出まわっているのですよ、よかったら見てみませんか？」

彼は中古車を探しに来た私に、新古車を薦めてきたのです。で、実際に見てみると、予算は15万円ほど上ブレしますが、けっして悪くはないと思いました。いや、それどころか、自分のニーズにぴったりだと思いました。
そしてその場ですぐ契約に至ったのです。

私が、中古車が欲しいという要望を掲げていたのにかかわらず、前のオーナーが残した汚れを気にしていたり、ワングレード上のモデルを探しているような節を、その若い営業マンは見抜いたのかも知れません。（もしかすれば彼は、単に新古車の在庫を抱えていただけかもしれませんが…）

そこで、新古車という新たな選択枝を示してくれたわけです。
つまり彼は、私が気付いていないことを気付かせてくれる人だったのです。
このように自分自身がお客になったときのユーザ体験を通して、私はとても貴重なことを学びました。それは自分の潜在ニーズを引き出してくれる人は、とてもありがたいということです。

システム開発の現場で起こっていること

では話しを戻して、システム開発の現場ではどうなっているでしょうか？

まず多くの依頼者は情報システムそのものを見たことはありません。パソコンやサーバの筐体は見たことはあっても、ソフトウェアの姿を見たことがある人はいないはずです。
自分が見たことがないものには、まず想像が働きません。

その状態から発するシステムに対する要望というのは、どうしても「あれも必要」、「これも必要」となりがちです。要望を全て満足させるのは不可能ですし、依頼者もダメモトで言ってる要望もあります。それでも、現場で見たこと聞いたこと、そこから得た洞察を伝えるしかありません。

こうした依頼者からの「こんなシステムが欲しい」、「そのためにこんな機能が欲しい」、「そういえばこんな機能も必要だ」、「誰にとっても使い勝手良く…」という要望は、システム開発会社によって優先順位を絞りこまれることなく、そのまま要件化されてしまいます。こうしてピントがずれたシステムが出来上がるのです。

家づくりの専門家と比べるとまったく対象的ですが、実際にそうなのです。

ソフトウェア工学の草分け的存在であるジェラルド・ワインバーグはこう言っています。
「建築家の最初の仕事は顧客の要望を変えることである」
何を言っているかというと、顧客は自分の欲しいものを必ずしも知っているわけではない、それくらい顧客が抱く要望は、あいまいでブレやすいものであるということです。
ただし、要望の元となる欲求はその顧客でしか分りません。それを早めに見つけ出すことが最初の仕事だと云うのです。

何故「使えないシステム」が生まれるのか

仕事の一部をシステムにやらせるときに、決して忘れてはいけないことがトレードオフの関係です。トレードオフとは、複数の条件を同時にみたすことのできないような関係を言います。あちらを立てれば、こちらが立たない、という状態のことです。

情報を網羅的に欲しいという要求があれば、現場の担当者にそれに該当するだけの入力作業を強いらなければなりません。これは現場をラクにしたいということとのトレードオフです。

また、ある業務をシステムで自動化したいという要求があれば、現場は一定のルールに従わざるを得ません。各々の担当者が得意先のために機転を利かせたり、例外的な処理を行うという自由さとのトレードオフとなります。
あるいは、予算やスケジュールとのトレードオフもあるでしょう。

このトレードオフをバランスさせるためには、その組織が何を一番優先すべきなのかを、議論しないといけません。
依頼者の名誉のためにあえて触れると、もちろん以前からこのような議論はなされているはずです。

しかし情報システムが介在するとなると、あえてグレーゾーンを残すことで均衡させていた状態を抜け出して、白黒決着させないといけない場合が多々と出てきます。コンピュータは人間のようにアナログな判断はできません。YesかNoしか判別できないからです。

厄介なことに、このトレードオフというのは、要件定義の段階で把握が漏れれば、システムが動き始めるまでのどこかで必ず露呈します。設計の段階で発見できれば、未だ良いくらいです。開発が進むほど、やり直しが大きくなる。つまり発見が遅ければ遅いほどダメージが大きくなります。

ダメージを回避するために、矛盾を最小限に抑えて、トレードオフにふたをするという方法も取れなくはありません。
ところが誰にとっても便利で使いやすい、つまり関係者全員の利害や要求を満たすようなシステムを目指すとどうなるか？これはある意味、ラクな進め方です。面倒な議論はスルーでき、開発途中で誰からも文句は出ません。

しかし、こうやって作られたシステムが、当初の意図を外れ、結局誰にとっても使えない中途半端なものになってしまうのは、もうお分かりですね。

依頼する側がかしこくなるしかない？

それではシステム開発会社は、要件定義という作業工程で、一体何をしているのでしょうか。もしや、工程をまるごとスキップしているのでしょうか？

いえ、要件定義という作業工程そのものは存在しますが、「依頼者の要望を聞いて、システムで実現する方法を考える」という意味に置きかえられているケースがほとんどなのです。というよりも、まともな要件定義ができるシステム開発会社は、そう多くはありません。

これが、現場で実際に起こっている失敗プロジェクトの原因の根っこです。

ちなみに私は、この状況についてことあるごとにシステム開発会社（同業者さん？）に意見を求めるのですが、専業者ですら、とても認識が浅いことが分かりました。

・同業者からの下請けがメインなので、言われたとおりに作るしか能力がない。
・仕様どおりにシステムを作って納品するのが仕事だから、ユーザの領域には深入りしない。
・要件定義には力を入れてますから大丈夫。ウチはけっこう相手に突っ込みますよ。
と、おおよそ3つの回答に集約されます。

上の2つは論外として、一番下の回答も、具体的に聞くと実はかなり怪しいことが分かります。
「相手に突っ込む」というのは、Webブラウザからの印刷要望に対して、PDFを通して行う提案をするといったような、テクニカルな話しだけだったりします。

請ける側もこのような感じなので、発注先を間違うと失敗するしかありません。

これを防ぐためには、依頼する側がかしこくなるしかありませんが、その前に客観的に知っておくべき情報があります。順を追ってご説明します。

依頼者自身「自分たちを意外に知らない」という事実

依頼者自身が、そもそも背負っている「ハンディキャップ」について、お話しします。

これから説明することについて、多くの依頼者は自覚がありません。あっても日常業務に忙殺されて完全スルーされています。これを客観的に「知る」ことが極めて重要なので敢えてご紹介します。

1. 意外と自分たちのことを知らない

依頼者は、システム開発を検討せざるを得ない状況にあっても、意外と分析が出来ていないことが多いのです。
実際に現象を目にしても、客観的に整理をして、原因を分析することはほとんどできていません。
鏡を見なければ自分の身なりの乱れを把握することができないのと同じように、依頼者は現状対応で精一杯で自己分析する時間がないのです。

2. さらに組織全体については知らない場合もある

自分の業務範囲内で起こっていることを把握していても、それ以外のことは知らないという場合もあります。
他の部署が何をやっているかを知らなかったり、過去の経緯は引き継ぎされていなかったりと、情報が限られているケースは少なくありません。またマネジメントの方であれば、現場で起こっていることを仔細までは把握できません。

3. 外の世界についての知識に偏りがあったりする。

同業他社の対処方法はどうなのかや、過去や外の世界で何が起こっているのか、依頼者は現状対応で精一杯で、意外に知らなかったり、あったとしても知識に偏りがあったりします。

ギャップを乗り越えるために、相談すべき相手が備える条件とは？

これらのギャップを乗り越えるには、どうすれば良いでしょうか。
それは先にお話ししましたように、専門家の手を借りるのが、一番手っ取り早いです。
しかし、「誰に相談するのか」が極めて重要です。
あえて「相談」という言葉を使いました。相談というのは、あなたの情報を開示することです。
そしてその相手は、あなたの言葉の裏側にある「本当の欲求」を探ることで、初めて相談相手となり得ます。
これは、あなたが業者に発注するような感覚では無理です。相手も業者としての姿勢で臨むようなら無理です。
お互いに対等なパートナーシップを結ぶことが肝心です。

では、そのパートナーを選ぶにあたって、どのような指針があるのでしょうか。

1. あなたよりあなたを知るパートナー

答えのひとつは「あなたよりあなたを知るパートナーを得ること」です。
なかにはこの考え方に疑問を持たれる方がいるかも知れません。確かに、あなたの目の前で起こっている現象について、あなた以外の人があなた以上に知ることはできません。では、どの程度知れば良いのか？

前章で述べたことを解消するためであれば、そこにパートナーが力を発揮できる余地があります。
それは、パートナー自身があなたに関心を持って、情報を収集するということや、その情報を整理・分析して可視化したり、あるいは外部の事例と比較して業界全体の状況の中にマッピングしたり、その分野のプロフェッショナルとして、あなた自身ができないような理解を深めていくことです。

このようなパートナーの働きによって、あなた自身が知らないあなたの姿を浮き彫りにすることができるでしょう。あなた自身が気付かない「新発見」をするために、一番手っ取り早い方法です。

2. あなたに代わって組織の情報を集めてくれるパートナー

あなたに代わって、多部門の人たちと関係をつくって、今どんな業務をやっているのか、課題は何かを吸い上げてくれるパートナーを得ることです。本来ならあなたの仕事ですが、現状対応で精一杯で手が廻らないところは、パートナーが補完できるスキームを作ったほうが早いです。これによって、組織全体を見渡したロジックを構築しやすくなります。

さらにパートナーを通じて話しを聞くと同時に、プロジェクトの情報を伝えることもできます。うまく巻き込むことで、間接的な根回しになりますので、社内の関係者の協力を得やすくなるメリットもあります。

3. 質問力があるパートナー

密度の濃いディスカッションができるパートナーを得ることです。先述のようにあなただけで解決策を考えるのは限界があるからです。時にあなたは、思いつきのように言葉を発することがあるでしょう。そこを深堀すれば、解決の重要なヒントがあるかもしれません。

また、あなたが業務現場で見た出来事やそこで感じたことについて、質問で深堀してくれるパートナーがいたとしたらどうでしょうか？それに答えるあなた自身も、話しながら頭が整理されてきたり、隠れていた真のニーズに気付くということがきっとあるはずです。

パートナーとの二人三脚でギャップを乗り越える具体的な方法

要件定義には、いろいろな方法論やツールがあります。インターネットで検索すると沢山でてきますが、難しい言葉が多すぎて、依頼者がこれを理解するのは実際は無理です。ここでは、もっと手前のことを身近な言葉で説明します。
具体的には次のように進めていくことでしょう。

1.「システムを作ること」の向こう側にあるものを共有する。

システム開発を思い立った動機に立ち戻って「何を達成したいのか」を明確にしていきます。この「何を達成したいのか」は関係者に尋ねるとバラバラの答えが返ってくることがあります。当事者自身がはっきり認識していないことすらあります。だからこそ、あえて行う必要があります。

コツは「目標」と「手段」を分け、混同しないことです。分けて考えることで、手段に縛られるという制約を外して自由に発想していきます。そうすることで達成したいことの輪郭が浮き彫りになってきます。このときのイメージを共有することがとても重要です。

2. 組織の人の動きをイメージする。

次に「システムで実現できること」と「システム以外で実現できること」を仕分けしていきます。あなたは組織体制や部門責任者および担当者の顔を思い浮かべながらイメージしますし、パートナーからは技術的な見地からアドバイスが得られるでしょう。

さらに、システム完成後、それを実際に使用する人は誰で、その使用頻度はどれくらいかを明確にする必要があります。コンピュータシステムに詳しいか否か、インターネット系のシステムに慣れているかどうかというあたりです。このあとの設計に深く影響します。

3. 業務と情報の流れをイメージする。

1番がはっきりすれば「仕事をどう変えていくか」が検討可能になります。さらに(2)番の結果によって、現実との落とし処を探すことが可能になります。これらとほぼ並行しながら、システムの骨組みを決めていきます。データベースの構造や、情報をどんなタイミングでだれにデリバリするかといったあたりです。きちんとシステムを作るカギはこの骨組みを少数精鋭でしっかり設計しておくことにあります。

ギャップを克服した先に見える世界

本来システム開発というのは、合理化や省力化のみを達成するものではなく、新しい価値を生み出すものです。
組織をどうしたいから、どんなシステムをつくって、実際に何をやるのか。良いパートナーと巡りあわせて、あなたの意思が明確にできあがれば、システム開発は成功します。

あなたの組織が、ユーザの喜びの声に包まれ、健やかに売上を伸ばす。そのような状態が実現することでしょう。
そしてリーダーであるあなたには、拍手と賞賛という見返りがあることでしょう。

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

谷尾薫

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

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