ソフトウェアの柔軟性と、ユースケースのブレ

January 25, 2020

最近最も悩んでいる、対応するユースケースをどこまで広げるかについて書く。

ユースケースが広くなりすぎるのは悪なのか

基本的に機能を増やす事は悪とされる。
機能が増えても、最終的に顧客のジョブを適切に解決できるケースは殆どない。

Evernoteの5%問題としても言及されるように、「5%の機能がユーザー毎に違う使われ方」をして、結局何を解決するプロダクトなのかはっきりしない事がある。

それぞれが独立した機能として種類の異なるジョブを解決し始めると、途端に機能を削るのは難しくなるし、オンボーディングの複雑さが上がってしまう。

サービスの「本質的な価値」で訴求して受注できないと、次のようになる。

見当違いなジョブを解決しようとする → 非本質的な部分なので機能が足りず解約 → 解約をみて要望対応しようとする → 非本質的な機能が増える → ソリッドでない製品が出来上がる

なので、やはりプロダクトの本質的な価値を理解し、その価値で訴求するべきである。

所謂PennyGapであれば、「MVPをMSPにする、市場からのフィードバックを経て製品仕様を磨き上げる」フェーズである。 Zuoraのファウンダーが言う通り、様々な要求をソフトウェアにかける事で、ソフトウェアはそれに適応しようとする。結果として市場の要求に耐えうる柔軟性が持たせられる。

Zuoraにとって重要な「柔軟性」という特性は、多種多様な顧客を持つことによってのみ身につけられるという考えだった。そのため私たちは、ハードウェア企業、メディア企業、消費者向けサブスクリプション企業など、多様なタイプの顧客を求めて営業に歩いた。

SaaSやマーケットプレイスなら、何かしらのネットワーク効果が生じるプロダクトを扱っているケースがある。そのような場合はユースケースが広い製品の方がアカウント数が増え、結果的に事業として強力になり、より大きな価値を提供しているケースも多い。

まだそもそも正しい売り方が定義できてない。最適なユースケースを見つけきる前に、ユースケースに制約をかけてしまっている可能性がある。現段階で最も顧客の課題に強烈に刺さるユースケースを探している段階。なので、その探索を適切に行うために対応できるユースケースを増やしている。

複数のユースケースに対応出来るようにすることは、ことSaaSにおいては時期を見て確実に求められるようになる。何故ならSaaSは最終的にエンタープライズ領域に売っていく事になり、当初の顧客層とは大きく異なることが想定される。

とは言え、最初はペインの深い所から刺していくのが一番であり、そこから広げていくのが定石。なので、顧客が抱えるペインの大きいケースを優先的に対応できるようにするのは当然の事。

サービスの本質的価値に対して、顧客の抱えるジョブの種類が同じで、インターフェイスが異なるだけでなのであれば、なるべく対応するのが吉。その上でジョブに対する課題の深さは、優先順位のために使う。

最終的にどのユースケースまで対応するかは意思決定次第のはず。個人的には、それを限られたリソースの中で、どのような順番で進めていくのが中長期的に最もアウトプットを出すのかによって「判断する」必要がある。

SMB向けのマーケットプレイス事業を売却後、エンプラ向けのSaaSをやってます。元エンジニア：Ruby / Go / Nuxt / ReactNative