これは採用面談、パートナーや採用候補者、投資家など、様々なステークホルダーからよく聞かれる質問です。これについてのStailerという自社プロダクトのケースにおける、現時点での自分なりの回答をまとめておきたいと思います。
まず、Stailerは「Stailer というプロダクトを利用して、N社のパートナーのネットスーパーの事業立ち上げをサポートする」というパートナーシップ型の事業モデルです。そこで、必ず聞かれるのが「カスタマイズはどれだけ対応するのか？」という問です。これに対して考えるとき、複数の視点から考慮します。
まずは、プロダクト開発者としての目線。カスタマイズをそのまま受容してプロダクトに反映していくことは、突き詰めると相手の要求に引っ張られて振り回されることを許容するということです。そして10Xでは「そういうプロダクトの作り方で、大きな価値を出すことは不可能」という強い意識を持っています。
次に、経営者や株主としての目線。いわゆる単純なカスタマイズは使い回しが効きづらく、様々な「リソース効率の悪化」を招きます。一時的な売上は上がるかもしれませんが、粗利を下げることになります。「事業としてパフォーマンスが悪化するだろう」という目線です。
最後に、パートナーの目線。パートナーからすると「自社の事業を推進するために必要な開発要望を受け入れてほしいが、その自由度が十分確保できるのか」という点を意識されます。
これら3つの目線に対して、10Xとしては一貫して同じ回答をしています。そのキーワードが「抽象化」です。
我々は「影響力が大きいものほど抽象化すべき」という考えを持っています。 抽象化の反対の意味としては「断片化」という言葉を使っています(言語として正確かは不明ですが)。
「抽象化されたプロダクト」とは何かを考えます。例えば複数の会社から以下のようなバラバラが2つ要求がきたとします。ある会社Aは「レシピから商品を買えるようにしてほしい」と要求し、ある会社Bは「商品からレシピをみれるようにしてほしい」と要求したとします。
これらに対し個別の要求をクリアするハードコーディングを行うことは「断片化」に当たります。他方でA社、B社(にとどまらず、潜在的なパートナー)の要求の背景にある達成したいこと、イシューをクリアにし、関連するイシューをまとめて解決する方法をプロダクトに実行することを「抽象化」と呼んでいます。そしてこの抽象化こそがStailerのスタイルです。
この事例で言うと、「商品(果物、人参、玉ねぎなど)」と、商品を利用する「レシピ(カレー、ナポリタンなど)」を紐付けるメタデータをデータベースに構築します。このメタデータを活用しやすいAPIがあれば、「商品からレシピを読み込む」「レシピから商品を読み込む」のどちらに対しても対応できます。こういった抽象的な土台が用意されていると、「最もユーザーへ価値が届くUI」もアジャイルに検証していくことができます。こうやってどのネットスーパーにも必要な機能だろうと判断できる機能は抽象化してStailerに取り込み、全パートナーに提供しています。
逆に抽象化に対して、「断片化」とはどういう状態でしょうか。
これも例を出します。例えばパートナーA社から「本日特売のこのお酒をページの一番上に掲載したい」というニーズがあるとします。
このお酒を、あらゆる掲載ルールを無視して最上位に掲載する処理自体は非常に簡単でしょう。フロントエンドにハードコートで実装して実現することも可能です。しかしStailerではこういった処理は基本的に行いません。
なぜやらないかというと、このハードコートは他者で類似したニーズが発生した際に再利用ができないからです。これを断片化と呼んでいます。このケースであれば「特定の商品の掲載順位を自由に制御できる」といった形に抽象化されていたほうがプロダクト全体の生産性を高く保てるのです。
もちろん効果が不明瞭な場合は、実装コストを捨てる意識で「短期的断片化」を許容するケースもあります。しかしパートナーがどれだけ分散していても、事業としては同じ「流通小売のEC」です。本質的にパートナーやエンドユーザーから求められる要求は類似してくると考えており、1の要求を受けた場合は常にN社へ発想を膨らまし、抽象化を検討することとしています。