今日の夜、トレタの増井さん（@masuidrive）さんと会って晩御飯を食べました。下らない話や日本企業の海外進出の話などをする中で、B2Bサービスがカスタマイズを受け入れるというのがどういうことなのか、という話が大変面白かったので、許可を得た上でブログ記事にさせてもらいました。
B2Bとは、Business to Businessの略語であり、企業が主に企業に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指す言葉です。対義語がB2C(Business to Consumer)で、企業が主に個人に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指します。B2Bビジネスの場合は契約1口あたりの金額が大きくなる傾向があり、逆にB2Cビジネスは1口あたりの金額はさほど大きくないのが普通です。
自分も昔の会社でB2Bを経験したことがあるのですが、B2Bをやる上で1つ大きな要因になるのが「カスタマイズ」です。B2Bだとクライアントから「この部分を変更してくれたら契約する」というような要望が入ることが多く、契約単体あたりの売上や利益が大変大きいので、つい受け入れたくなってしまうのですが、これが将来禍根を残すことも大変よくある話なのです。
例えば、
- 顧客ごとにわずかずつ変更が入ったブランチが発生し、本体の改修の負荷が高くなり機能追加が難しくなる
- 顧客ごとに細かい対応が必要になり、それぞれの顧客ごとに専用のエンジニアが必要になる
- 複数の顧客が要求した似たような機能がそれぞれのブランチで実装され、メンテナンスの負荷があがる
といったことが想定されます。
カスタマイズ案件が増えてくるとエンジニアの工数が大変大きくなり、かつカスタマイズ案件はエンジニアにとって魅力的ではない作業であることがほとんどで、上手くコントロールしないとエンジニア全体のモチベーションも大きく下がるという負の側面もあります。
しかし目の前の顧客に「このちょっとした機能を実装してくれたら大口の契約を約束する」と提案されたりすると、将来の負担と現在の売上を考え、経営判断としてカスタマイズを受け入れることもよくあることです。
ところがトレタはそういう判断をすることが一切なく、増井さん曰く現在のトレタは一切のカスタマイズを受け入れていないと言っていました。
一番驚いたのが、サービス初期に大手のチェーンから「（トレタは緑基調のUIですが）自社のコーポレートカラーが赤なので、UIを赤基調にしてくれたら全チェーンで導入する」という依頼があったらしいのですが、それを断ったそうです。
例えば設定ページで色を変更できる機能を追加して全クライアントに出してしまえば、少なくともソースコードベースは同じなので各社のカスタマイズコードは発生しなくなり、エンジニアの視点からすれば大きな問題がないように見えます。この程度のカスタマイズを受け入れる経営者は多そうです。
しかしそれだと、
- 緑、赤だけでなく、今後増えるであろう全ての色の組み合わせで、きちんと文字が見やすいかどうかなどを確認するコストが大きい
- サポートがお客さんに対して、例えば「緑のボタンを押してください」というように言うことが出来なくなり、サポートのコストが増える
- 営業が「どこまでカスタマイズ出来て、どこから出来ないのか」を客先ではっきり判断出来なくなる
というような問題が起こり得る、とのことで、なるほど確かにエンジニアの外側に視点を向けてみると、色の変更1つでも相当色々な問題が発生することが理解できます。
もちろんトレタはお客さんの要望を否定するのではなく、安易にカスタマイズに走らずにその背後にある本当の問題を解決するのを心がけているとのことです。例えば「トップページにこのボタンを置いてくれ」という要望が来た場合、なぜそのボタンが必要なのかヒアリングし、トレタの使い方の問題であればコンサルをし、もしトレタも気付いていない大きな改善につながるなら積極的に（メインブランチに）実装をしていく方向だそうです。
また、トレタは将来的なカスタマイズを否定するわけではなく、本当にカスタマイズでしか対応出来ないような要望もいくつか来ているそうです。ただ現在の企業ステージで安易にカスタマイズに手を出すと様々な工数が跳ね上がるので対応出来ないだけで、将来的に対応が可能になれば、少しでも広く顧客をサポートをするために対応をしたい、という話はされていました。
B2Bのビジネスにおいて、経営者からすれば「カスタマイズさえすれば契約確定」という提案は大変魅力的です。カスタマイズの際には改修費用を請求できることがほとんどで、その案件のみに注目すれば損は一切発生しません。しかし長い目で見た場合、カスタマイズというのはジワリジワリと影響が発生し、最終的にかなり大きなコストとしてのしかかることもあります。
Atlassianのサービスなどは、設定画面を通じて様々なカスタマイズを可能にして普及しているサービスが多い印象です。一方GitHubやSlackなどは、カスタマイズ可能な機能が少ない印象があります。どちらが正解というわけではなく、それぞれに需要があるのは間違いありません。ただ、もし自社のサービスのカスタマイズ案件を提案された場合、それが将来どのような問題になり得るか、について事前にしっかり理解しておくのは大切なことだと思います。