第4回　ソリューション志向の新事業開発のプロセス

　前回は、ソリューション開発へと思うように舵を切ることができない要因についての考察を述べました。今回は、このボトルネックとなる要因を乗り越えてソリューション志向の開発を加速させるための、開発プロセスの考え方について解説します。

ソリューション志向の開発プロセスの特徴

　ソリューション志向の開発プロセスが従来の開発プロセスとは根本的に異なることを説明するに当たり、オーソドックスな開発プロセスについて説明します。

従来の開発プロセスは「モノ」の確定から始まる

　従来の開発プロセスでは、まずターゲットとするビジネス分野のマーケティングリサーチを行い、自社が保有する技術とお客様のニーズが合致しているかどうか、現状分析を行います。次のステップとして、技術シーズと市場ニーズとが合致した市場セグメント・顧客層を、市場ターゲットとして設定し、先行する競合他社の製品ベンチマーキングや、業界の規制・品質基準などのさらに詳細なリサーチを行いながら商品企画案を詰めていきます。

　ここまでは机上検討が中心ですが、商品企画案のレビューで「売れそうなモノ」であると判断されれば、次のステップで、実際に試作品をつくり、それをデモ、もしくはお客様の環境で使ってもらいます。机上検討の結果が、どこまでのレベルで現実の世界で達成できそうか、フィジビリティ・スタディ:実現可能性の検証(以下、F/Sと記載)を行います。このF/S結果をレビューし、いけそうだという判断になれば、積極的に拡販するための営業・プロモーション体制や、量産化のための調達・生産体制の構築~製造移管のステップに入ります。このように、従来の開発プロセスは現状分析の結果を起点として、つくる「モノ」を確定してから、実際の製造・販売に着手します。

ソリューション志向の開発はお客様の立場に立って考察する

　これに対して、ソリューション志向の開発プロセスでは、現状分析を起点にはしません。前回、ホテルのコンシェルジェの例で解説しましたが、お客様は具体的に自分たちが何をしたいのか、最初はわからない状態なのです。旅行先で美味しいものを食べていい思い出をつくりたいという漠然とした要求はあるものの、それを満たす手段のイメージはまったく持っていない状態を想像してください。そのようなお客様に対し、現状分析によるアプローチで、ホテル近辺にあるお店を調べて地図を渡すだけでは何の付加価値も生みません。そこで、ソリューション志向の開発プロセスでは、現在自社が保有している技術や、それが適用できそうな市場の規模・成長性といった現状分析からはいったん離れ、お客様が置かれている事業環境について、相手の立場に成り代わって考察することから始める点に特徴があります。従来の開発プロセスとソリューション志向の開発プロセスとの比較を下図に示します。

お客様のありたい姿を把握するトレンド分析の例

　最初のトレンド分析はきわめて重要なステップですので、ホテルのコンシェルジェの例で詳細に説明します。

　ホテル周辺の飲食店(=ホテルのロケーションによる自社の強み)という現状分析に縛られず、お客様の目的である「いい思い出をつくりたい」に寄り添い、相手の置かれている環境を考察します。たとえば、小さい子供がいる家族旅行中のお客様であれば、カウンター形式の飲み屋を紹介すると子供連れでかえって気を遣わせてしまい「いい思い出」にはならないでしょう。タクシーが必要になるかもしれませんが、飲み屋でも個室のあるところで、地元名産の珍味だけではなく、子供向けの食べやすい食材も提供するお店の方がよいでしょう。もしくは、単身で出張にきているサラリーマンであれば、明日の仕事に差し支えない範囲で、一人でも入りやすい立ち飲みのバーで、地元名産の簡単なつまみをつくってくれるようなお店がいいのではないでしょうか......。

　この最初のステップを現状分析から入ると、どうしても自社が保有している手段(開発・営業・製造などの現有する経営リソース)を有効に活用したいという経営の事情が前面に出てしまい、その後の開発ステップのデザインレビューにおける判断基準も、自社が保有する手段の活用度合いが主な基準となります。結果として、開発ステップが進むにつれて、徐々にお客様が本当に困っていることからは離れていき、開発や製造リソースをどのようにやり繰りしていくか、自社の経営事情が中心の議論になっていくのです。ソリューション提供とは、その名のとおりお客様の困りごとに対する解決策の提供のことですので、現状分析を起点とする従来プロセスでは、かえってソリューション提案の価値を下げることになります。

　お客様の事業環境を分析することを、トレンド分析と呼んでいます。お客様を取り巻く事業環境の変化を分析することで、その変化に対応するために、お客様はどのような「ありたい姿を目指しているのか」を考察するのです。従来プロセスのように自社の提供価値の手段から考えるのではなく、「いい思い出をつくりたい」という目的・価値観をお客様と共有するところから始めるのです。ここがそもそもお客様の考えることとずれていると、その後の検討ステップをいくら入念に進めても、まったくの的外れのソリューションになりますので、ステップ１でお客様の「ありたい姿」・未来の理想像の仮説を立てたうえで、次のステップ２：有識者ヒアリングでは、その業界に通じた経験者、もしくは可能であればお客様自身にヒアリングを行い、自社の思い込みによる的外れな目的設定になっていないかを検証します。

ソリューション志向の開発プロセスが抱えるジレンマとは

　お客様と目指すべき価値観を共有した、次のステップ３ではボトルネック解消のための手段の検討を行います。ここで始めて自社の保有技術や強みの棚卸しを行い、解決手段において自社の保有するリソースが活用できるかどうかの検討に入ります。

　従来の開発プロセスでは、どうしても「自社で今できること」の範疇で考えてしまうため、必然的に研究開発部門を主役とした検討になります。開発部門以外の部門は、主役のサポート役・引き立て役となるため、よほど経営のトップダウンで開発部門への協力を命じられない限り、協力的に動いてくれないでしょう。これが前回説明したソリューション開発へと思うように舵を切ることができない要因、ソリューション開発の死の谷とも言える状況です。

　それに対して、図に示したソリューション志向の開発プロセスで、お客様の困りごとを起点として検討を進めますので、技術開発はあくまでもネック解決の手段のひとつであり、アフターサービス部門や、購買部門や品質保証部門などのスタッフ部門の力が有効な解決手段となる可能性が検討の初期段階で判明します。したがって、全社・全部門連携でソリューション案の検討をスタートすることができます。ここがソリューション開発の死の谷を越えるための最重要ポイントです。

自社のリソースが介在しない提案をどうするか

　その一方で、お客様の困りごとを起点とした開発プロセスのネガティブな側面としては、自社の強み・リソースありきでスタートしていないがために、現有リソースだけで解決策を立案するのは難しくなることがよくあります。極端なことを言えば、お客様の理想像の実現ありきで考えると、自社が現有する経営リソースでは、直接的にお役立ちできることは何もないということが、この期に及んで判明することがよく起こります。

　小さい子供を連れても気兼ねせず、かつ地元の名産も出て大人も満足できるメニューを出してくれるようなお店は、ホテル周辺には存在せず、かなり離れたロケーションにあることがわかったとします。そこへ案内しても、次回にこの家族が旅行する際には自社のホテルではなく、その店の近くにある他社のホテルの常連客となってしまう可能性があります。確かにお客様からはその瞬間こそは感謝されますが、次回もこの土地に家族旅行をしようとした際に、ホテルから相当な距離のお店に行かなければならないことを考えると、前回と同じホテルに泊まろうと思うでしょうか。以前のホテルのコンシェルジェの親切心は覚えているものの、長旅で家族も皆疲れているなかで、また時間をかけて外出しなければならないことを合理的に考えればNOになることの方が多いでしょう。したがって、自社の現有リソースが介在しない、お客様にとって一方的に理想的な提案は、個人的な善意の提案であり、決してビジネスと呼べるものにはなりません。ここがソリューション志向の開発において、もっとも難しいところであり、最大のジレンマです。このジレンマを乗り越えることがソリューション開発成功の鍵となります。

　次回は、このジレンマを越えて、ソリューション開発を成功裏に進めるための考え方について説明します。