BtoB SaaSのカスタマイズ要望とどう向き合うか
こんにちは、booost technologiesのスギタ(@tomotomobile)です。
Zennで技術ブログを始めましたので、これからちょこちょこ記事を投稿していきます。
記念すべき第1回の記事を書かせていただきます。
僕たちはCO2排出量可視化ソリューションやESG情報開示ソリューション、小売電気事業者向けの業務システムなど、BtoB SaaSを提供しています。
そんなBtoB SaaSにつきまとう顧客からのカスタマイズ要望にどう対応しているのかを紹介します。
BtoB SaaSとBtoC SaaSの違い
まず最初に、BtoB SaaSとBtoC SaaSの基本的な違いについて触れてみましょう。これらのアプローチの違いが、開発プロセスや要件にどのような影響を与えるのかを理解することが重要です。
BtoBとBtoC SaaSは、ターゲットユーザー層やビジネスモデルの違いから派生する異なる開発要件を有しています。BtoBでは、大企業や事業者などの専門家が主なユーザーであり、製品はビジネスプロセスの合理化や効率向上をサポートすることが期待されます。そのため、高度なセキュリティ、柔軟性、および統合性が求められ、カスタマイズ可能な機能やエンタープライズ向けの機能が重要となります。
一方で、BtoCでは広範な一般ユーザーが対象であり、使いやすさやエンゲージメントの向上が焦点となります。大量のユーザーを想定しているため、スケーラビリティやユーザーエクスペリエンスの最適化が必須であり、個別の要望への対応が難しいことがあります。したがって、一般的な機能の提供が中心となり、複雑なカスタマイズやエンタープライズ向けの特殊な機能は相対的に少ないことが特徴です。このような差異が、開発プロセスや機能の設計において大きな影響を与えます。
BtoBではカスタマイズ要望がほぼ上がってくる
BtoB SaaSの特徴として、顧客ごとのニーズや要件が大きく異なることが挙げられます。顧客が以前から行なっている業務要件を満たしたいとか、業界特有の要件とか、先進的な取り組みをしたいなど、様々な理由からカスタマイズ要望が上がってきます。
これらの要望を満たすことで、顧客に提供する価値が上がり、売上拡大にも貢献します。一方で、カスタマイズしすぎるとメンテナンス性が下がり機能開発のスピードが落ちていきます。
アンチパターン
過去に私たちがやらかしたアンチパターンを紹介します。
個社カスタマイズが入ったらブランチを分けて管理☠️
当時は導入事例を増やすために積極的にカスタマイズを受け入れてきました。スピードを優先していたため事業判断としては当時はそれ以外の選択を検討している余裕がなかったのでしょう。その結果、mainブランチを利用している顧客はゼロとなり、最終的に15バージョンのソフトウェアを管理する羽目になりました。
共通機能のアップデートや追加を行うためには15個のPRが発生し、リリース作業に必要な工数がどんどん膨れ上がりました。今だから言えることですが、このような運用は絶対にすべきではありません。
カスタマイズを最小限にする設計を
本来SaaSでは、個社カスタマイズを受け入れるべきではありません。しかしながら、どうしてもカスタマイズしなければいけない場合は、次のことを検討します。
- カスタマイズ機能ではなく共通機能に昇格する
- どうしても共通機能にできない場合は、フィーチャーフラグを利用する
前者は、例えば、顧客によって請求書のExcelフォーマットが異なり、請求金額を表示するセルの位置が違うとします。その際に、個社カスタマイズを入れるのではなく、請求金額をどのセルに表示するか設定できる機能の開発を検討します。
こうすれば、個社の要望に応えられますし、同一のソースコードで実現できるようになります。
後者は、例えば、ほとんどの顧客は同じ請求書のExcelフォーマットを使っているとします。1社だけどうしても自社独自のフォーマットにしたいという要望があり、やらざるを得ないケースを想定します。（それでも、最大限標準機能を使ってもらうように交渉すべきではありますが。）
1社のために前述のような共通機能を開発するのでは工数が合わないので、フィーチャーフラグを活用することを検討します。
フィーチャーフラグは設定値を読み込み特定の条件で処理を切り替える機能です。コードにするとこんな感じ。
if (Feature('customer_id')==='AAA') {
$this->fillDataAAA($invoiceData);
} else {
$this->fillData($invoiceData);
}
設定値はDBに格納してもいいですし、configファイルや環境変数に入れてもいいです。
PHPを使っていればPackagestにあるパッケージを用いてもいいでしょう。（すみません、実際に使ったわけではないので、使いやすいかは分かりません）
Laravel向けのフィーチャーフラグもあるようです。
私のチームでは諸般の事象によりフィーチャーフラグは自前実装しました。
こういった地道な努力でカスタマイズ地獄から抜け出すことができます。とはいえ、僕らもカスタマイズを吸収してソースコードを一本化する道なかばです。
BtoB SaaSのプロダクト開発を通してこういった課題を解決したい仲間を募集しています。
詳しくは採用ページに書いてますので見てくださると嬉しいです。
Discussion