カスタマイズ要求との向き合い方
「複数の顧客からのプロダクトカスタマイズ要求にはどう対応するのですか？」
これは採用面談、パートナーや採用候補者、投資家など、様々なステークホルダーからよく聞かれる質問です。これについてのStailerという自社プロダクトのケースにおける、現時点での自分なりの回答をまとめておきたいと思います。
問の背景にある3つの目線
まず、Stailerは「Stailer というプロダクトを利用して、N社のパートナーのネットスーパーの事業立ち上げをサポートする」というパートナーシップ型の事業モデルです。そこで、必ず聞かれるのが「カスタマイズはどれだけ対応するのか？」という問です。これに対して考えるとき、複数の視点から考慮します。
まずは、プロダクト開発者としての目線。カスタマイズをそのまま受容してプロダクトに反映していくことは、突き詰めると相手の要求に引っ張られて振り回されることを許容するということです。そして10Xでは「そういうプロダクトの作り方で、大きな価値を出すことは不可能」という強い意識を持っています。
次に、経営者や株主としての目線。いわゆる単純なカスタマイズは使い回しが効きづらく、様々な「リソース効率の悪化」を招きます。一時的な売上は上がるかもしれませんが、粗利を下げることになります。「事業としてパフォーマンスが悪化するだろう」という目線です。
最後に、パートナーの目線。パートナーからすると「自社の事業を推進するために必要な開発要望を受け入れてほしいが、その自由度が十分確保できるのか」という点を意識されます。
これら3つの目線に対して、10Xとしては一貫して同じ回答をしています。そのキーワードが「抽象化」です。
「抽象化」と「断片化」
我々は「影響力が大きいものほど抽象化すべき」という考えを持っています。 抽象化の反対の意味としては「断片化」という言葉を使っています(言語として正確かは不明ですが)。
「抽象化されたプロダクト」とは何かを考えます。例えば複数の会社から以下のようなバラバラが2つ要求がきたとします。ある会社Aは「レシピから商品を買えるようにしてほしい」と要求し、ある会社Bは「商品からレシピをみれるようにしてほしい」と要求したとします。
これらに対し個別の要求をクリアするハードコーディングを行うことは「断片化」に当たります。他方でA社、B社(にとどまらず、潜在的なパートナー)の要求の背景にある達成したいこと、イシューをクリアにし、関連するイシューをまとめて解決する方法をプロダクトに実行することを「抽象化」と呼んでいます。そしてこの抽象化こそがStailerのスタイルです。
この事例で言うと、「商品(果物、人参、玉ねぎなど)」と、商品を利用する「レシピ(カレー、ナポリタンなど)」を紐付けるメタデータをデータベースに構築します。このメタデータを活用しやすいAPIがあれば、「商品からレシピを読み込む」「レシピから商品を読み込む」のどちらに対しても対応できます。こういった抽象的な土台が用意されていると、「最もユーザーへ価値が届くUI」もアジャイルに検証していくことができます。こうやってどのネットスーパーにも必要な機能だろうと判断できる機能は抽象化してStailerに取り込み、全パートナーに提供しています。
逆に抽象化に対して、「断片化」とはどういう状態でしょうか。
これも例を出します。例えばパートナーA社から「本日特売のこのお酒をページの一番上に掲載したい」というニーズがあるとします。
このお酒を、あらゆる掲載ルールを無視して最上位に掲載する処理自体は非常に簡単でしょう。フロントエンドにハードコートで実装して実現することも可能です。しかしStailerではこういった処理は基本的に行いません。
なぜやらないかというと、このハードコートは他者で類似したニーズが発生した際に再利用ができないからです。これを断片化と呼んでいます。このケースであれば「特定の商品の掲載順位を自由に制御できる」といった形に抽象化されていたほうがプロダクト全体の生産性を高く保てるのです。
もちろん効果が不明瞭な場合は、実装コストを捨てる意識で「短期的断片化」を許容するケースもあります。しかしパートナーがどれだけ分散していても、事業としては同じ「流通小売のEC」です。本質的にパートナーやエンドユーザーから求められる要求は類似してくると考えており、1の要求を受けた場合は常にN社へ発想を膨らまし、抽象化を検討することとしています。
Stailer の価値を太らせる
我々のバリューの中に「10xから逆算する」というものがあります。10xとは誰かの深いイシューを解くことによって達成できる非連続的な価値です。この際に必要な態度は「誰かが要求すること」を飲み込むというより、その要求が発生する背景にある構造、原因を噛み砕き、強いイシューとして定義すること。このイシューに対して、ベストな価値を提供する手段としてプロダクトは強力です。
これによって、1社や1人を満足させるだけではなく、他の類似した要求を持っているパートナーやユーザーも満足させることができる。さらにこういう価値に魅力を感じて、新たな無消費層を取り込むことができる、Stailer の導入が決まるといった事業上の付加価値も生まれます。
つまり、我々が行っていることはカスタマイズではなく「Stailer の価値を太らすこと」であると表現しています。パートナーやエンドユーザーのN=1要求と向き合い切ることでStailer というプロダクトのポテンシャル最大化を目指すのです。その上で特定の価値が不要なパートナーに対しては、「この価値を提供しない」というスイッチオフが簡単にできるように内部を整えています。
とはいえ、ネットスーパーという事業や、Stailer 自体の歴史が浅いため、理想状態に対してまだまだ根本的に不足している価値の方が多いと思います。今はいろんな要求の中にあるイシューを深掘ったら、結果的にその多くをStailer に取り込むことになっています。
冒頭での質問「カスタマイズはどれだけ対応するのか？」という問いに対しての回答としては、「カスタマイズという対応方法をとらない。普遍的なイシューへ再定義し、可能な限り抽象化した価値をStailerへ取り込んむことで解決する。その価値をオプショナルに提供したり、しなかったりができる状態にする。断片的な開発はしない。我々が作ったものは資産になって、複数のパートナーに提供できる状態になるので、結果、粗利のインパクトが強い。」となります。
特有の事象においても「抽象化」で事業価値を高める
これまではプロダクトの話でした。他方で僕らはプロダクトだけで事業価値を出しているわけではなく、パートナーのオペレーションを立ち上げたり、効率化したり、コンサルしたり、BPOとしてそのまま受け切ったりするなど側面支援からも事業価値を高めています。
特にネットスーパーだと3つの「心臓」とも呼べるオペレーションがあります。
- 在庫管理
- ピックパック
- 配送管理
例えばピックパックについては、我々が現場に入り込んでオペレーションをセットアップして、それに必要なプロダクトも提供し、立ち上がりをサポートしています。そして各社の現場現物を吸収した上で我々自身のオペレーションの知見の立体度を高め、またサポート価値自体を抽象化しています。
例えば10Xのメンバーがパッと現場に入って、現場の要件を見た時に、「ここの現場だったら、ピックパックにはこういうオペレーションメソッドをインストールすべき」「それに適切なシステムは、5パターンのうちAパターンです」といった形で我々自体の意思決定や、サポート内容をパターン化していきます。
2パターンのオペレーションDX
パートナーをサポートしていく中で、オペレーションDXにも2パターンあるなと感じています。1つは、売上のボトルネックになってるオペレーションにレバレッジをかけること。もう一つはシンプルなコスト改善。これらは別々のものと認識しています。
特に前者はパートナーにとって売上ドライバーとなります。ネットスーパーでいえば在庫管理、ピックパックのオペレーションはまさにこれに該当します。この部分については、10Xとしても圧倒的に知見を持つことや、抽象化したオペレーションを構築できること、そこに最適なプロダクトを持っていること、これら全体が抽象化されて、パターン化されてることが非常に重要だと考え、投資を続けています。
そしてStailerはレベニューシェアのビジネスモデルを採用していることから、オペレーションにレバレッジがかかりパートナーの売上が上がると10Xが得る粗利に直結します。関係者全員にとって良いアライメントになります。
抽象化できないオペレーション部分
最後に、抽象化できない・あえてしないオペレーションを取り上げます。それはBizDevです。BizDevとは何かというと、リレーションとサクセスの2つの要素に分けられます。
リレーションは、相手との関係性を作りディールにまとめ上げる役割です。リードジェネレーションしたり、信頼を築き、対等に交渉を行える状態をつくること。そして両者の合意 ≒ 契約書がアウトプットになります。
そしてStailerは創業者や経営陣しか買えない特性のプロダクトです。それは事業の変革がアジェンダになるからです。その意味ではリレーションはパートナー企業の創業者や社長と伴にする必要があります。更に契約に落とし込む際には、しっかりとネゴシエーションを通じてお互いの妥結点を1個1個見つけていく必要があります。
もう1つ、サクセスというのは、相手(パートナー、その奥にいるエンドユーザー)のペインと、僕らが持っている提供価値(抽象化されたプロダクトやオペレーションを作り上げる価値)のFit&Gapを判断し、Fitする価値を届けてパートナーを成功させること、そして粗利に転換していく役割です。
この2つの役割のうち、サクセスは一定の抽象化ができますが、リレーションは抽象化が非常に困難です。なぜなら、1社1社コンテキストを緻密に把握し戦略を組む必要があるためです。
「どういう立地で、どういった祖業から今の立ち位置になり、周辺の環境はどうだったのか。」
こういった各社のストーリーは驚くほど多様です。パートナーの背景を彼ら以上にリサーチして、知ってる状態になって、その上でベストな選択肢は何かを模索し、提案する。
僕らとしては、「Stailerを使わない方がいい、今はやらない方がいい」という提案をする機会も非常に多いです。それはパートナー自身や、彼らの後ろにいるユーザー、そして10Xと3社の利害が一致しないケースです。どれかに歪みがある場合、長期的な関係を築くことが難しいと判断しています。
通常のセールスであれば、プロダクトを売らずに買えるのはマイナスの場合もあると思います。しかし我々の場合は逆です。ネットスーパーを成功させるためにパートナーがReadyとなるように促したり待つことを良しとし、無理やりStailer を売り込んで事業を立ち上げることは誰にとってもマイナスと考えています。
こういった意思決定ができる理由の1つは会社として十分なリソースマネジメントができていること。もう1つはパートナーの成長とともに我々も成長するアライメントを選択しているためです。このおかげでReadyなパートナーには、10X社としてもフルベットできるのです。
日本を支えてきた小売企業とこういった対等な関係性が築き、新しいイノベーションを推進できるのはストレートで、面白く、プレッシャーもあり、エキサイティングです。
お知らせ: オープンオフィスやってるよ！
※本記事は以下のPodcastの内容を元に作成しました。