【DX格差拡大中 #4：最終回】開発投資は47％が失敗！？だからこそ知りたい、成功確度を高める要諦を徹底解説

――開発投資の「半数が失敗」という2018年のデータがあります（※）。5年後のいま、この割合をどのように捉えていますか？

野呂：感覚として、失敗する確率はもう一段高い気がします。成功率は3割くらいかと。何を持って成功とするのかにもよりますが、使いづらいと感じながらも使わざるを得ないユーザーの方々も一定数いらっしゃるのではないでしょうか。

――成功の定義は、「経営層や利用者の満足度」「コスト」「納期」の三つすべてを順守したプロジェクト、だそうです。

野呂：それらをもって成功とするとしたら、相当ハイレベルだと思います。
まず、コストや納期といった部分は往々にして膨らみがちですし、その上で、リリース段階で想定通りのユーザーニーズに応えることができるといったこと自体難しいからです。

――また、一番の失敗要因は、「要件定義の不備に集約できる」とされています。

野呂：それはまさにその通りですね、要件定義はとても深いのですが、その認識を持てずにしっかりした「要件定義」をできていない企業は多いのではないでしょうか。①ユーザーのニーズを検証しているか、②担当者が要件を理解できているか、③システム部門とビジネス部門の合意形成が図れているか、――。この三つを満たすことは、欠かせません。

――要件定義は、時間をかけてつくるべきものなのでしょうか？

野呂：丁寧にやることが望ましいものではありますが、半年・1年もかけてやる必要はないと思います。ただ、要件定義を早くしたいのであれば、つくるものも限定的にする必要があります。要件定義が曖昧まま数千万円～数億円のシステムをつくるようなことは、非常にリスクが大きいと感じています。

――山口さんは、成功を阻むものは何だと思っていますか？

山口：一つは部門間の対立です。実際私が目にした事例として、情報システム部門がビジネス部門の話を聞かずに開発を進めた結果、ビジネス側の大反発にあい、大問題になったプロジェクトがあります。100人/月で動くほど大きなプロジェクトでしたが、結果として開発チームは翌月解散することに。金額もこの時点で100億円程度かかってしまい、大きな損害だったのではないでしょうか。また、別の大規模プロジェクトでは、実業務のヒアリングがきちんとできておらず、作っては直し、作っては直し、当初1年でリリースする予定が延びに延びて結果4年かかりました。費用対効果まで考えると、果たしてどれほどの利益を生み出せたのか、疑問を感じるケースとなってしまいました。

このほか、お題目だけ掲げた結果、「何をつくるのか」がブレているにも関わらず、誰も止められず終わりが見えない、というのも失敗する確率が高い気がします。これらは入り口の段階で「ゆくゆく失敗するな」と、分かりますね。

――野呂さんは、成功するために必要なことは何だと考えていますか？

野呂：私は、成功確率を高めるためには、初期段階でユーザーニーズを検証するステップを組み込む必要があると考えており、本開発の前にプロトタイプを使ってサービスイメージを明確にし、ニーズの検証を行うことを推奨しています。プロジェクト期間が2～3ヵ月延びてしまうかもしれませんが、その分開発時の手戻りが少なくなりますし、本来必要なものがプロトタイプの段階である程度形づくられるので、要件定義の品質は向上します。余分な機能を開発するような動きも最小限に留めることができるため、結果として開発スピードも上がるでしょう。ただし、予算を確保するときにはその分の費用を見込んでいただく必要があります。利益を生まない検証にお金をかけるのか、と渋る企業の方々もいらっしゃるかもしれませんが、手戻りによる追加コストの発生を防ぐことができ、ユーザーの満足度が高いものに仕上げることができるという本質的な視点で見ていただきたいと思っています。

――実際、デジタルシフト社ではプロトタイプを使ったプロダクト検証を提案されています。どのように進めているのでしょうか。

野呂：私たちはプロトタイプデザインをもとに、ユーザーヒアリングを毎週行う形で進めています。具体的には、プロダクトに触れてもらい、使い勝手を確かめていただいています。これを行うことで、「開発したものの、そもそもユーザーのニーズがない」という事態を防げるだけでなく、サービスイメージの解像度を高め、社内のステークホルダーが全員同じ方向を向いて進められる状態をつくることができます。

プロトタイプの作成から検証までは大体2ヵ月、長くても3ヵ月程度です。ただし、お客さまの予算もありますから、すべてに提案させていただくわけでもなく、また、実際に採用される企業もまだ3割程度です。しかし、要件定義が曖昧なまま開発を進めることは、よい判断とはいえません。繰り返しになりますが、プロダクト開発を考えている企業には、要件定義の前にプロトタイプ検証といったステップの必要性もご認識いただき、そのうえでご判断いただくことをお勧めしたいです。

――要件定義を言語化するだけでは十分とはいえない、と。

野呂：要件定義でも最低限の画面イメージは作成しますが、その時点での大きな軌道修正は非常に難しいです。また画面イメージも、「〇〇の受付フォーム」「〇〇へのログイン機能」と表現するのが限界で、動的なユーザー体験まで検証することは難しいと思います。具体的にどのような顧客体験となるのか全員が同じように理解するには、やはりプロトタイプである程度使い勝手を試せるレベルまでサービスイメージを高めることが望ましいです。認識の齟齬や、開発の手戻りを無くす手立てになりますから。

――よく「SIerに丸投げはよくない」ということを聞きます。具体的にどのような弊害が出てくるのでしょうか？

野呂：丸投げするのが悪いわけではないですね。

山口：そうですね、要件定義含め、丸投げしてもよいとは思いますが、プロダクトや機能の必要性は企業側で確認していただく必要があります。過去に「こんな機能がほしい」「全社の総意だ」とおっしゃる企業をたくさん見てきました。しかし、丸投げされるSlerにも、つくり手としての矜持があります。やはり使われるものをつくりたいですから。そこで、「本当にニーズはありますか？ 何人のユーザーから必要とされていますか？」と聞くのですが、途端に口をつぐんでしまわれます。確認していただいた結果、まったくニーズがなく、案件自体がなくなることもありました。

つまり、作ること自体を丸投げするのが悪いのではなく、そもそものプロジェクトを立ち上げるタイミングで、きちんとニーズを確認すること。それこそが重要だと思います。

――ちなみに、デジタルシフト社に相談する場合には、どのような要素が必要ですか？

野呂：一つは、つくりたいサービス像です。これは漠然とでも持っておいていただければと思います。それさえあれば、私たちがヒアリングしながら解像度を高めることができます。もう一つは、「この課題を、このようにして解決したいんだ」という想いやビジョンです。それが開発の目的そのものということもあります。

山口：当社がよく申し上げるのは、「共創」です。システムの仕様にまでイメージは至らなくとも「業界をこのようにしていきたい」と言って相談に来られるお客さまは、実際にいらっしゃいます。私たちも「ぜひ一緒にやりましょう」とスタートを切るのですが、進めていくうちに「これはデジタルで解決できそうですね」と話が進み、当社が開発を請け負うケースはよくあります。一方、課題意識と具体的な解決策がないままに進めることは難しいと思います。

―山口さんのおっしゃる「共創」ですが、すでに事例はありますか？

山口：保育関連事業を行うお客さまとの取り組みが進んでいます。業界全体をよりよくするにあたり、すでにリリースしているアプリを改善することがその突破口になると考えていらっしゃいました。そこで、当社の社員に一名出向してもらい、日々いろいろな課題をヒアリングしながら、次の一手を探っているところです。これは、お客さまと本気で共創したいのだという当社の意思の現れでもあります。こちらの会社はどなたも多忙で、課題感は強くお持ちではあるものの、改善案を企画に落とし込む時間がなかなか取れない状況が続いていらっしゃいました。そのため、当社の社員が代わりにその役割を担っている、という構図です。

当社がしたいのは、あくまでもパートナーとしての共創であり、短期的なコンサルのみで利益を上げたいわけではありません。お客さまの中に入り、ともに活動させていただいたほうが、課題や状況を掴みやすいのは確かであり、課題解決の確度も高まります。そういう狙いもあって、最終的に結果が出る方法、お客さまが本当に効果を得られる方法を常に探し、選択しています。これは、社会課題を解決したいという当社の存在意義につながる根幹でもあります。

野呂：共創にはもう一つ意図があります。例えば、あるクライアント企業とは、お客さまと外販につながるようなサービスを共同開発し、一緒に業界を変えるような取り組みをしましょうという構想を描いています。ですから、出向も業界理解を含めこうした意味合いが強いかもしれません。単に一つのプロダクト開発を受発注の関係で終わらせるのではなく、業界を本気で改革するために開発やマーケティングに長けた私たちと、業界の実情を深く知るクライアント企業が一緒に挑む、という形です。私たちは常にアンテナを高く伸ばし、お客さまの業界を変えていけるようなアイデアの種を探しています。

山口：野呂の話のとおり、私たちは常に頭の中には構想を持っています。業界全体を大きく変えるサービスになると思えば、踏み込んだ提案もどんどん行っています。とはいえ、お客さまに最初から壮大なビジョンをご用意いただく必要はなく、現状の課題を起点に私たちが提案したり、一緒にディスカッションしながら検討を進めていく形がほとんどです。

まずは現状の課題を解消し、そのなかで見つかった次の課題を解決して、どんどんよくしていく。そういう共創がしたいと思っています。ささいな課題が業界全体を大きく変えるきっかけになるかもしれません。目下の課題を一つのプロジェクトとして捉えるのではなく、その先に想いを馳せていくことこそ、DXを推進し社会をよりよくする力になると思っています。

※参照：プロジェクト失敗の理由、15年前から変わらず：日経ビジネス電子版
https://business.nikkei.com/atcl/opinion/15/100753/030700005/（2023年5月26日参照）