「小さな会社のSaaSの育て方」と題して、boardの10年間を振り返る連載の第8回です。
今回は「カスタマイズ」についてお話しします。
boardは、カスタマイズには一切対応していません。ビジネスモデルとして、カスタマイズに対応するかどうかで大きく変わるため、今回はその点について書いていきます。
受託開発の会社としては、カスタマイズは馴染みがある
boardを開発する前の2013年までは完全に受託開発の会社で、EC-CUBEなどのパッケージのカスタマイズ案件を多く手がけていました。そのため、カスタマイズ対応は非常に馴染みがあり、むしろそれまでのビジネスの延長としては、ごく自然なものでした。
boardを始めたころ、「SaaS」という言葉がどれほど一般的だったかははっきり覚えていませんが、まだそれほど浸透していなかったような気がしていて、「カスタマイズをしないSaaSとして進める」という明確な方針を持っていたわけでもありませんでした。
そのため、今振り返ると、「よくカスタマイズを受けなかったなあ」と感じます。
カスタマイズのデメリットは想像できた
カスタマイズのメリットは、短期的にまとまった売上を得られる点です。
一方で、受託開発の経験から、カスタマイズを受けることが中長期的にどのような結果を招くかも十分に想像ができました。
カスタマイズを行うと、それぞれのソースコードが分かれてしまい、将来的な管理コストが増大します。要件によっては、設計思想に合わない機能を無理に実装するケースもあり、そのメンテナンスも困難になります。
また、サービスにアップデートや不具合修正が発生した際、それぞれのカスタマイズに適用していく必要があり、カスタマイズの数が増えるほど、1件ごとの対応にかかる時間と工数も増えていきます。
「開発費用は出すのでこの機能を追加してほしい」というお問い合わせをいただくこともありますが、問題は開発費用ではありません。その先の運用コストのほうがずっと大きな問題です。それによって対応スピードが落ち、結果としてサービスの競争力が低下し、小さな会社のサービスとしては、寿命が縮まってしまうと考えています。
受託開発で収益を得ていたため、短期的な売上が不要だったことも重要なポイントです。目先の利益よりも、長期的に安定して提供できるサービスを目指す選択ができました。
サービスのターゲット層との相違
boardは「中小規模の会社のためのサービス」という一貫したスタンスを持っています。
カスタマイズの費用をかけてまで導入したいというのは、一定以上の規模の会社が多く、boardの本来のターゲット層よりも少し上でした。
カスタマイズの有無にかかわらず、SaaSの売上を拡大するには大きな規模を狙うのが一般的ですが、会社規模が異なれば基本設計も変わってきます。boardは「小さな会社による、小さな会社のためのサービス」であるため、カスタマイズを受けるというのは、サービスの基本方針と一致しない判断になります。
その代わり、ある程度柔軟に対応できる機能にする
カスタマイズには対応しないものの、設定次第でさまざまなケースに対応できるよう、ある程度柔軟性のある仕様にしています。
ただし、設定が増えすぎると別の問題が生まれるため、バランスが重要です。多様なシチュエーションやニーズをカバーすることで、「カスタマイズはできないが、自社にフィットした形で使える」ことを目指しています。
そして、こうした設定の多くは、ユーザーからの要望をもとに実装しています。
特定の1社のために機能を実装するのではなく、一定のニーズが見込まれる機能をサービスとして取り入れ、価値を高めていくことに注力してきました。
振り返っての考察
boardの初期は、受託開発と並行してなんとか必死に作っていた状況で、カスタマイズについても明確な方針はありませんでした。
しかし、受託開発の経験から「カスタマイズを受けたら運用が回らなくなるだろう」という予想ができ、結果として受託開発の経験が意外な形で活きたように思います。
もともとboardは、「受託開発の数を1つでも減らせるよう、売上の“座布団”になれば」という思いで始めた事業でした。つまり、あくまで受託開発が本業であり、boardを数年のうちに主力事業にするつもりではなかったのです。ずっと「売上の座布団」と呼んでいました。
最初の数年は、boardの売上見込みを会社の計画に含めてすらいませんでした。
もし当時、早急に売上を立てなければならない状況だったら、カスタマイズを受けていた可能性はあったかもしれません。
これに限らず、経済的な余裕は（といっても大した余裕があったわけではないですが）、選択肢を広げると思っているのですが、これもその一例かなという気がします。
