業界特化型SaaSの開発がエンジニアにとって面白すぎる理由

メディカルフォースCTOの畠中です。

現在弊社はシリーズAの資金調達を完了し、拡大に向けた取り組みを行なっている最中です。

前回のnoteでは、ARR1億円までに行った取り組みとして良かったことと悪かったことといった振り返りを行いました。

今回のnoteでは、ここまでの道のりやこれからの拡大フェーズに向けた準備を通してエンジニアとして感じた「Vertical SaaSの面白さ」について書こうと思います。
Vertical SaaSの開発は本当に面白いので、一人でも多くのエンジニアの方に面白さが伝われば嬉しいです。(一緒に開発してくれるメンバーも募集中です)

以下、目次です。

顧客へのコミットが会社へのコミットとなる

一つ目の面白さはなんといっても顧客へのコミットが会社の価値へと繋がっていく点です。
この面白さはSaaSというビジネスモデルの面白さからくるものです。
SaaSとは神前さんのお言葉をお借りすると以下のように説明できます。

カスタマイズ性を削ぎ、クラウド技術を活かした低い原価率とThe Modelに代表される効率的な組織オペレーションを土台とし、サブスクリプションを前提とする「LTVの最大化とコスト(COGS/CAC)の低減」により、高収益かつ圧倒的成長スピードを実現するビジネス。

神前達哉『【考察】評価され続けるSaaS企業とは?〜LTVの本質とNRRの重要性・Expansion戦略について〜 』
(https://note.com/tatsuya_org/n/n3143c5f200c8)

よく商談時にお客様からオンプレミス型のサービスと、SaaSとの違いを聞かれることがあります。
ここで一般的には、自社でサーバーを用意する必要がなく導入コストが低いことや、セキュリティやデータの安全性といったオンプレミスとクラウドの差分に注目がいくことが多いです。

しかし、私はSaaSの最大の利点はクラウド型であることから、アップデートを頻繁に行うことができ、お客様の求めるものをより速く届けることができることだと考えています。

従来ソフトウェアは売り切り型であり、現状のソフトウェアに課題や要望があった場合でもそれらを実際にプロダクトに落とし込みお客様のもとへ届くまでには長い時間がかかります。しかし、SaaSの場合は頻繁に(数日や数週間といった単位)でシステムに変更を加えそれらの価値をリアルタイムで届けることができます。
これらがSaaSがお客様にとって優れている点でもあり、またそれが故にプロダクトを中心とした会社においては会社の成長スピードを最大化できる理由だと考えています。

さらに、SaaSでは通常買い切りではなくサブスクリプションモデルが採用されることが多いです。
サブスクリプションモデルでは、月額や年額といった単位での課金体系なため売り上げが積み上がっていくという反面、逆にお客様が価値を感じなくなった時点で課金が行われなくなるという側面もあります。

これが故に本質的な価値を長期間にわたって提供し続けない限りは会社が成長することができないという性質をSaaSは持っています。

SaaSの本質的な価値は、「ユーザーを起点として、ユーザーへの価値を高め続けられること」にあると私は思う。もっと極端な言い方をすると、SaaSモデル自体が、”ユーザー起点を強いる”と言っても過言ではない。

ご存知の通り「オンプレ・ソフトはプロダクト提供がゴール。SaaSはその逆。提供してからがスタート」と言われるが、SaaSは”先払い・継続課金モデル”で、プロダクトを提供してからがスタートだ。プロダクトを提供してからもユーザーの声を聞き、観察し、ユーザーに価値を提供し続けることでしか、事業として生き延びられない。

この健全なプレッシャーを、SaaS企業は日々受け続けているため、進化を続けられる。これはただの理念ではなく、ビジネスモデルレベルに落とせているのがSaaSはスゴイ。

湊 雅之 『SaaSって、結局何がスゴイのか?』
(https://medium.com/@masayukiminato/%E3%81%AA%E3%81%9Csaas%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%81%AF-%E3%81%93%E3%82%8C%E3%81%BB%E3%81%A9%E6%B3%A8%E7%9B%AE%E3%82%92%E9%9B%86%E3%82%81%E3%82%8B%E3%81%AE%E3%81%8B-28fb58429566)

上の記事にもあるようにSaaSはその性質上、全員がユーザーの視点に立って本当にユーザーにとって価値のものを追い求めるということを提供者に強います。

しかし、この性質は本当に価値のあるものを作って届けたいという人にとってはこの上なく美しくやりがいのある仕事になると感じます。
個人的にも会社やプロダクトの見せ方だけではなく,その等身大の価値で評価されるという性質はとても好きです。

この性質は、弊社における「顧客commit」というバリューにも表れており顧客にコミットすることにいかに重きを置かれているかが表れていると思います。
このバリューもSaaSをやっていく上で意図的に生み出したものではなく、SaaSをやる上で必然的に生まれたものなんだと思います。

また、SaaSにおいては実際に契約をいただいた後もお客様と接点を持ち続けることが必要です。そのためお客様からの声をいただく機会もかなり多いのですが、自分達で作り上げた価値に対するフィードバックを直接いただけるのはやはり嬉しいです。

特に弊社のような業界特化型のSaaSでは、業界に特有の課題を解決していくことになりますが、業界に特化している分、やはり業界に深く根ざしている課題は多く、解決が難しいため解決した時のインパクトが大きくとてもやりがいがあります。

ドメインの理解とモデル化と設計

二つ目の面白さは、ドメインの業務をモデル化しそれをプロダクトに反映するべく設計するという過程そのものです。

SaaSを開発するにあたって「ユーザーの求めるもの」をいかに正しく早く作るかということがとても大事になってきます。
そのために必要なプロセスはいくつかあると思っているのですが、エンジニアにとって以下の3つのプロセスは特に重要だと感じます。

  1. ドメインについて深く理解する

  2. ドメインを正しくモデル化する

  3. モデル化されたドメインを正しくプロダクト設計に落とし込む

これらの3つのプロセスをいかに正しく早く実行するかが、そのまま「ユーザーの求めるもの」をいかに正しく早く作るれるかに繋がると考えています。

まず一つ目の「ドメインについて深く理解する」ですが、このステップが土台にあり重要であるのになかなかエンジニアが触れられる機会が少ないというのがよくあるケースだと思います。
特にVertical SaaSにおいてはドメイン知識のあるエンジニアを集めるというのは困難であり、エンジニアが開発の過程でドメイン知識を蓄えていく必要があります。

次に「ドメインを正しくモデル化する」というステップが重要になってきます。ドメインについて深く理解があるからといって必ずしも正しくモデル化できるとは限らず、ドメイン知識を体系的にまとめ、それぞれの要素がどのように相関しどのような影響を及ぼし合っているのかということを整理するという過程が必要になります。

玉村豊男『料理の四面体』

例えば料理をモデル化するには、個別の料理のレシピや、それぞれの食材についての知識のほかに料理というものがどのような構成要素でできていて、それぞれの要素がどのような影響を及ぼしあった結果できているものなのかということを理解し整理する必要があります。

このようにプロダクトを作る際にはそれぞれの要望や課題、業界についての知識に加えてそれらの課題をモデル化するという過程が必要です。

最後に「モデル化されたドメインを正しくプロダクト設計に落とし込む」というステップが必要になります。

モデル化まではエンジニアリングの知識が介在せずとも達成することができますが、最後のステップには各々のエンジニアリングについての知識を総動員してモデル化されたドメインをプロダクトに落とし込むにはどのような設計を行うのか、またどのようなインフラやサービスを用いるのが最適なのかを選択する必要があります。

このように、プロダクト作りには獲得したドメイン知識とエンジニアリングについての知識を総動員し正しい選択を行う必要があります。

特にVertical SaaSにおいては獲得すべきドメイン知識が大量にあることからモデル化の難易度もやはり高いですし、その分設計も難しいです。
しかし、難易度が高い分モデル化や設計の面白さや深さがより理解でき、やりがいのある業務だと思います。

特に弊社ではエンジニアがドメイン知識を獲得するために実際にユーザーを訪問するということが日常的に行われており、ドメイン知識を得やすい環境であること、またエンジニア全員でモデル化や設計のステップを行なっていることからこのような面白さは感じやすいです。

プロダクトを重ねていく

三つ目の面白さはプロダクトを重ねていく面白さです。
通常SaaSでは一つのプロダクトがPMFを迎えると、いかにシェアを拡大していくかに大きなリソースが割かれ、シェアを拡大することでARRを大きくしていきます。
しかし、Vertical SaaSでは一般的に市場がそこまで大きくないことが多く、一つのプロダクトで勝負する戦い方には限界があります。
そのため、シェアを大きくすると同時に単価をあげていくためにプロダクトをどんどんリリースしていく必要が出てきます。

新プロダクトの開発が好きなエンジニアにとってこれほど良い環境はありません。常に新しいプロダクトのことを視野に入れながら開発できます。

しかも個人的にもっと面白いと思っていることは新プロダクトが完全なアイディアベースにならない点です。
先程の章でも述べたようにプロダクト作りにはドメインの知識を大量に獲得し、モデル化する必要があります。
その過程で色々な潜在的な課題やビジネスチャンスが見えてきます。

例えば、弊社では現在『medicalforce』というクリニック向けのSaaSを提供していますが今のプロダクトで価値を提供できる範囲はクリニックの業務のみです。
しかしどの業界でもそうですが、複数のプレイヤー間でそれぞれトランザクションを行い影響を及ぼしあいながら業界というものは成り立っています。
そのため、クリニックについての業務についての理解が深まれば、クリニックを中心としたトランザクションや周辺のプレイヤーの課題など、まだまだ価値を提供できそうなところが見えてきます。

このように、Vertical SaaSを開発する過程で現存のプロダクトを中心として、周辺にも解決できそうな課題や価値を提供できそうな部分がどんどん溢れてきます。
あとはそれらを思うままにプロダクトにすれば良いので(といっても大変ですが、、)、なかなか新プロダクトを開発したいけれどアイデアがない、や新プロダクトを開発したいけれど需要があるのかわからない、といった悩みはあまり生まれてこず、どちらかというと「やりたいことややるべきことは沢山あるのにリソースが足りない」といった悩みの方が多いです。
新プロダクト好きのエンジニアにとっては良い環境になることが多く、常に新しいワクワクや楽しみがある状況でとても面白いです。

まとめ

以上が個人的に感じたVertical SaaSの面白さです。
まとめると、、

  • 本当に価値のあるものを作って届けたい

  • エンジニアリングそのものだけでなく、エンジニアリングがドメインに提供できる価値に興味がある

  • 新プロダクトが好き

このようなエンジニアにとってはVertical SaaSの開発は本当に面白い業務になると自信を持って言えます。

また、ドメインについてあまり興味がない方も特に心配する必要はあります。
ドメインについての興味があるためドメイン知識を獲得しやすいというわけではなくドメインについて学べば学ぶほど必ずドメインに対する愛着は生まれてくると私は思います。

このnoteを読んで興味を持っていただけた方はぜひ、一度カジュアルにお話ししましょう。以下のmeetyでお待ちしています!


この記事が気に入ったらサポートをしてみませんか?