3. 業種・業態を超えたニーズを掴んでいる
強い法人向けクラウドサービスには、特定の業種・業態を想定顧客にしたサービスではなく、業種を超えてニーズがある製品であるという特徴もあります。
• Salesforce：CRM
• Box：クラウドストレージ
• Marketo：マーケティングオートメーション
• Concur：経費精算
• kintone：アプリ作成プラットフォーム
• freee：会計ソフト
• Sansan：名刺管理
これらのサービスはいずれもほぼ全業種・業態が対象となるサービスで、かつ全社員が使用することを想定したサービスとなっています。これは獲得できる市場規模が大きいということを示しており、そのサービスが対象とする顧客範囲の広さをもってミッションを突き詰めていくと、自然と強いサービスに位置づけられるということだと思います。
当のサービス提供者たちがそこまで見越していたかどうかは正直不明です。もしかしたら途中からより多くの市場をターゲットとするようにピボットしたのではないかとも考えられます。
4. プロダクトの継続的改善とそのサイクルの早さ
ちょっとした昔話なのですが、実は私はSansanに所属する4年程度前、Sansanの顧客である企業に所属していた時期がありました。何を隠そう、その会社でSansanの導入を決めたのは私なのですが、その時、名刺管理サービスを導入するに当たって、当然幾つかの製品を比較検討しました。その頃Sansanは市場で大きなシェアを獲得しつつありましたが、機能ベースでは他の製品とそこまで優位性があるわけではなく、かつ価格面ではやや高額であるという理由で今ほど即決できる製品ではありませんでした。
最終的にはSansanともう一社の製品（以後『製品B』と呼びます）に絞り込んだ私は、この２つの製品の特徴を細かく分析しましたが、当時私が所属する会社の要件においては、大して違いがないことを感じていました。機能的に見た場合、大した優位性はなかったのです。「価格は製品Bの方が安く、やれることに大した違いはない」、なのに私はなんとなく製品Bを選ぶ気にはなれず、どうしてもSansanが気になっていました。これについて自分なりにその原因を言語化しようとしたのですが、どうしてもできません。私は最終的に「Sansanの方がなんとなく将来性がありそうだから」という理由で、Sansanを導入することに決めました。
その後、縁あってSansanに入社した私は、当時のこの感情を的確に表現する言葉を発見しました。それはSansanの方がプロダクトの改修サイクルが早かったのです。実は製品比較の際はバージョンアップの回数や今後の製品の方向性はあまり重視されることはありません。もしかしたら全く焦点にならないこともあります。しかし私が製品Bに感じていたモヤモヤ感は、製品Bがこれ以上進化する雰囲気を感じなかったからだということがわかりました。当時を振り返ってみると、Sansanの営業マンから感じた名刺管理サービスにかける情熱、目指したい世界観には目を見張るものがありましたし、直近の機能改善においても今後の進化を感じさせるような点が確かにありました。
現在のクラウドサービスはサブスクリプション型が当たり前です。サブスクリプションモデルは機能改善され、進化していくことが前提になっているので、常にサービス改善を行っていないと顧客に飽きられ（呆れられ）他社のサービスに乗り換えられてしまいます。これは誰でも知っている事実ですが、製品購買時の決定的な理由になることはない、隠れた重要ポイントであるといえます。
上記の体験をして以来、私は「価格もできることもほぼ同じサービスがあった場合、何を決め手に購買製品を決定するか？」という質問に対して、「サービス改善のポリシーとスピードである」と答えるようにしています。そして強いクラウドサービスはその性質を有しています。
プロダクトの改修ポリシー
上記で「サブスクリプションモデルは継続的な改修が前提である」と書きました。ではその機能改善はどのようなポリシーのもとにやるべきなのでしょうか？ プロダクトに対して、どのような機能改善を行うかは非常に重要な問題であるとともに、特に迷いやすいポイントでもあります。そしてその迷いの多くはミッションの欠落にあります。
先に、「ミッションの具現化手段としてのサービスを提供できている会社は強い」と書きましたが、このことが上記の問題を解くヒントになります。結論をいうと、ミッションから導き出されているプロダクトは、機能改善の優先度に迷いが生じることは少ないです。実現したい未来が明確にあり、「そのためには今何を実装すべきか？」を自分に問うことで、自ずと答えが導き出されるからです。
もちろん、「AとBどちらにすべきか？」というレベルで悩むことはありますが、基本方針としてはミッションを実現する手段をプロダクトに投影していけばいいだけなので、迷走することは少ないはずです。たまに、（巨大なサービスであっても）迷走しているプロダクトを見かけますが、おそらくミッションが甘いのだと思います。
※おそらくはミッションを固める前にプロダクトが世の中に受け入れられたがゆえの苦悩だと思います
また、ミッション優先の実装ポリシーは、そのサービスがより売れる／売れないで実装する機能を決めなくていいというメリットもあります。プロダクトの改修ポリシーとして最も安易で賛同が得られやすい方法は、売れる機能を作ることです。企業は自身の提供するサービスを維持し続けるために利益を確保する必要があります。そしてそのことを大義名分として売れやすくなるような機能を実装することがしばしば優先されます。
しかし、これはおそらく大きな誤りであり、迷走の火種となり得ます。過去私は、LINEを世に送り出した森川さん著書を読んだことがありますが、その中で「LINE上に広告を表示すれば収益がでることはわかっていたが、それは絶対にやりたくなかった」と書かれていたのを目にしました。このエピソードは、収益優先の実装ポリシーの危うさを指摘しており、非常に示唆に富んでいると思います。
「そのサービスが世の中に広く知られるため」という目的で売れる機能を実装するのであれば問題ありません。が、時としてそれは、ただ収益を得るための手段にすり替わって実現されることがあります。今自分たちがやっていることが、ミッションに沿った上で収益に繋がっているのか？それともただ売れているだけなのか？これを見極めるとこが非常に重要なのです。
