【対談】エンジニアが考えるBtoB SaaSの魅力とは（前編）

ここ数年、日本でも急速に増えてきたSaaSモデルのプロダクト。スマートキャンプ社が発表しているレポートによると、2016年から2021年にかけて市場規模は2倍近くの約5800億円まで伸びる見通しです。

SaaSに関するニュースやナレッジも少しずつ出回るようになってきましたが、その多くはマネジメントやビジネスサイドに関わるもの。プロダクトを開発するエンジニアにとってのやりがいや実情については、十分に知られていないのではないでしょうか。

そこで今回はCTOの柴山と、SIerを経て当社に加わったエンジニアの池上にSaaSの魅力について存分に語ってもらいました。当社もSaaSモデルのCX（顧客体験）プラットフォーム「KARTE（カルテ）」を運営しています。そこでの体験を軸にプレイドに限らず、SaaS全般に関心があるエンジニアの方の参考になるような情報を届けられればと思います。

【柴山 直樹】プレイド CTO（写真左）

東京大学工学部にて神経科学、チューリッヒ工科大学にてロボティクス、東大大学院にて分散環境における機械学習の研究に従事。2009年未踏本体採択。2013年同大学院博士をドロップアウトし、同社CTOとして参画。

【池上 純平】プレイド エンジニア（写真右）

東京大学経済学部金融学科卒業。2015年、富士通株式会社にSEとして新卒入社し、自治体向けシステム開発に携わる。2016年11月より株式会社プレイドに参画。

SaaSがチームにもたらすもの

ーー まずはSaaSビジネスの魅力や特徴について教えてください

柴山 : 事業面では安定的な収益基盤を作りやすいことが大きな魅力ですね。一度システムをしっかりと作ってしまえば継続的に収益が増えていく構造なので、プロダクトも組織も長期目線で作りやすかったりします。社内向けの投資をしやすいので、会社を育てていくような感覚で運営できる。年間契約とか、少し長めの契約期間でBtoBのSaaSをやっている場合は特にそうですね。

池上 : 短期的に何かを作って、一発でバーンと儲けるようなビジネスにはなりづらいですよね。SaaSの場合は「売って終わり」ではないというか、「売った後でどうちゃんと使ってもらえるか」だったり、「クライアントからのフィードバックをプロダクトにどう反映させていくか、改善していくか」が重要視される傾向にあります。

柴山 : オンプレと比較するとそこがSaaSの特徴ですよね。僕らとしてもまずはちゃんとしたプロダクトを作って、それをいかに長期的に使ってもらえるか、クライアントに対してバリューを出せるかに集中できる。その点ではクライアントと僕らの目線が合いやすいと思うんです。結局はクライアントに喜んでもらえないと解約されてしまってビジネスもスケールしないので、そこはブレずに納得感を持って仕事できるんじゃないかなと。

また機能面では良いアップデートが頻繁に行われ、常に最新版にアクセスできるのが導入する企業からみたメリットだと思います。

池上 : （個別でカスタマイズなどをしていることもあり）オンプレだとサービスに対する変更が入れづらかったりもするけど、SaaSの場合はプロダクトの進化のスピード感を享受できるのは大きいですよね。

柴山 : もちろんセキュリティ周りを気にされて、オンプレの方が良いという声もありますがそこはここ2、3年でもだいぶ変わってきている印象はあって。それこそ大手企業の中でもAWSやGoogleのGCPはOKです、みたいになってきている。以前はオンプレでは無理なんですかと言われることもよくありましたが、最近はそう言うこともあまり聞かなくなってきました。

魅力的なSaaSが兼ね備える抽象度と拡張性

ーー ちなみに柴山さんはかなりのSaaS好きですよね。SaaSのどこが好きなんですか？

池上 : 確かに海外サービスを凄い知っていたり、気づいたら契約していたりしますよね。

柴山 : 個人的にはSaaSにしろ、PaaSにしろ、IaaSにしろ抽象的な視点が入っているものが好きなんです。たとえばオンプレの世界観だと、基本的には各社ごとにカスタマイズすればいいので、そこまで抽象度をあげる必要性はないですよね。でもある程度、幅広いターゲットに対してSaaSという形で展開しようと思うと、そこにどれだけ抽象度や拡張性を乗っけていけるかが勝負になってくる。

そこが理系的で面白いんですよ。何かやりたいものがあった時に抽象度を高めて、一度プロダクトに起こし、そこで具体化するケースを大量に増やしていく。いろいろなものに使える土台を作る、基礎工事のようなイメージです。

池上 : 一つのソリューションでいろいろなところをカバーできるということですよね。

柴山 : 本当に上手くいっているプロダクトはそこの設計がすごく綺麗というか、よく考えられているなと感じ取れるものが多いんですよ。

池上 : 確かに。「無駄のなさ」というか。

ーー 具体的にイケてるなと思うサービスはありますか？

柴山 : たくさんあって、それこそエンジニアの方からすると意外かもしれませんがセールスフォースさんとかすごく好きです。根本は「データベースをどのように見せるか」という発想からスタートしていると思うんですが、いろいろな企業が扱いやすくなるような形をいかに設計し、ラッピングをこらしていくのか。その抽象化の仕方と具体化の仕方のバランスがすごく上手いと思います。他にも、TwilioとかMode Analyticsとか好きです。

明確な正解のない、高難易度の“謎解き”

ーー ここからはもう少し掘り下げて、“エンジニア”がSaaSに関わる魅力を聞いてみたいと思います

池上 : 先ほど柴山が言った「抽象度」の話にもつながりますが、SaaSは通常「なるべく多くのクライアントの課題を、同じプロダクトや同じ機能で解決しよう」というスタンスで開発していきます。その仕組みを考えることが難しい部分でもあり、面白い部分です。

たとえばあるクライアントの特定の課題を解決する機能は比較的簡単にできるかもしれませんが、複数のクライアントの似たような問題をまるっと解決する機能を作るのって、なかなか難しい。

柴山 : そこに謎解きのような面白さがあるんですよね。SaaSとしてビジネスを大きくしていくためには、ある程度スケーラブルに問題を解いていかないといけないので。必然的に解くべき問題が難解で面白くなりがちだし、インパクトも大きくなる。その面白さはSaaSの会社全体に共通するような気がします。

ーー そうなると必然的に解決の難易度が高くなりますよね？

柴山 : そうなんですよね。そこが面白いし、チャレンジングな部分。個別契約であれば要望を聞いて、そこに合わせて開発して、正しく納品すれば十分かもしれません。でもSaaSの場合はそうではない。どういう機能で解決していくのかはもちろん、その順序やリソースなど主体的に考えるべきことが多いです。

新機能などであれば、10社から要望があったからとか、すごく大きなクライアントから要望があったから開発するという話ではないんですよね。本質的に僕らがやりたい方向と、クライアントの要望をすり合わせつつ丁度良いポイントを探って。開発コストも鑑みながら、最も良い解決方法を導き出す必要があります。

池上 : プレイドでも、結果的に「作ったけどあまり使われなかった機能」も結構ありますよね（笑）、過去を振り返ると。クライアントに言われて開発した機能なら使われやすいと思うんですけど、特に何か言われる前から抽象的に課題を解決しようと思って作ったら、全然使われないことも...。

柴山 : デベロッパー目線、デザイナー目線、ビジネス目線、ユーザー目線といろんな目線から優先順位をつけるし、解決方法も見つけるので。そういうのが混ざった時に「死人が出る決断」をする必要がありますよね（笑）。ある目線では良いと思ったけど、他の目線から見たら全然良くないということはよくあるので。

池上 : そこは難しいですよね。何かたった1つの正解があるわけではないので、その中でどれだけ正解に近いものを作っていけるか。そのためにどうするべきかを常に考えないといけない。

柴山 : 基本はやり直し、やり直しの繰り返し。まずリリースしてみてダメだったらぶっ壊して、次に活かせばいいという考え方です。とにかくそのスピード感というか、まずはガンガン取り入れていくというスタンスは大切にしていますし、SaaSは構造的にもそうなりやすい気がします。

前編となる今回は、SaaSビジネス自体の特徴やそこにエンジニアとして関わる魅力について紹介しました。後編では引き続きこの魅力を紹介しつつ、SaaS企業で働くエンジニアに求められる考え方やクライアントとの関係性についてもディスカッションしています。ぜひご覧ください。

プレイドは、共に働く仲間を探しています！