SaaSはエンジニアリングの民主化を加速させる

どうも、エンジニアのgamiです。

人事・労務向けのSaaSを提供するSmartHRさんが、約156億円を調達し、企業価値が約1,700億円のユニコーン企業になったそうです。

SmartHR、シリーズDのオンライン記者発表会をやりました。そのスライドを少しだけ公開します！

・約156億円を調達
・ARR 45億円（YonY +106%）
・Churn Rate 0.4%未満
・エンプラ比率が上昇
・幅広い業種で導入

ARRは初公開、Churn Rateは会見内で口頭で開示した数値です。https://t.co/7pgp1w7kHP pic.twitter.com/AKE0O5uAqe

— Shoji Miyata (@miyata_shoji) June 8, 2021

ユニコーン企業となったSmartHRは、どれほど規格外なのか？

SmartHRは仕事でも使っているし、中の人も何名か知っていて、個人的に応援しているプロダクト&会社の一つでした。日本のSaaSスタートアップに希望を与えるような嬉しいニュースです。

また近年のマザーズ市場におけるIPO時価総額の上位企業を見ても、SaaS企業が占める数が多くなっているようです。

（出典: SaaS企業の時価総額はなぜ高いのか？ - ITmedia ビジネスオンライン）

このように、投資家の間で日本のSaaS企業に対する注目が高まり、多額の資金を集められるようになってきました。

僕は新卒の頃からずっとBtoBの仕事をしていて、「地味で全然目立たないなー」と感じ続けてきました。BtoB SaaS企業にここまで市場の注目が集まっている状況は、驚くばかりです。

ただし、（僕も含めて）投資とか資金調達とか言われてもピンと来ない人が多いと思います。そこで今回は利用企業の目線に立ち、多くの顧客企業がSaaSを無視できなくなってきた理由について考えてみます。SaaS企業の時価総額が上がっている背景には、SaaSにお金を払う利用企業が長期的に増え続けるだろうという市場の期待があるはずです。

特に、日本であと数年は語られ続けるだろうDXというムーブメントと絡めながら企業とSaaSの関係について考えます。

DXはエンジニアリングの対象を広げる

DXについては、以前にもnoteにまとめました。

経産省が2018年12月に公開した『DX 推進ガイドライン』におけるDXの定義は次の通りです。

企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること。

重要なのは、現在の市場の激しい変化の中で優位性を維持し続けるためには、コンピュータやエンジニアリングの力が不可欠であるという点です。

まず、生活者がお金や時間をかける対象がデジタルの世界にどんどん移動しています。たとえば実際の店舗に行かずにオンラインで完結する購買行動が増えると、小売業界はそれを無視できなくなります。当然、人間がスマートフォンの中に入って顧客全員を接客するわけにはいかないので、アプリケーションやWebサイト、あるいはその裏にあるシステムを構築することになります。

また、組織や働き方にも素早い変化が求められるようになり、社内の業務も人間が紙ベースでやり続けるには限界が来ます。たとえば新しい業務フローに対応させるにも、人間がやる領域が大きいと採用や学習に時間がかかります。コンピュータの力を最大限に引き出すシステムを使った方が、設定を変えるだけで業務フローを簡単に変更したり規模を拡大したりすることができます。（実際には色々と難しさもありますが。）

そんなわけで、ベースとしては「エンジニアをガンガン雇ってアプリ開発とか業務効率化とかしないと変化に対応できなくてヤバい」という世界が到来しつつあります。

SaaSはシステムの共同利用を実現する

しかし、お察しの通り「エンジニアをガンガン雇って云々」というのは様々な事情によってうまくいきません。たとえば、そもそも市場に優秀なエンジニアがいない、いても採用コストや人件費が高すぎて払えないなど。もちろん、多くの場合はSIerなど開発会社に外注することになりますが、それはそれでコスト増やベンダーコントロールの難しさなどいろんな問題を含んでいます。

そこで、「エンジニアじゃなくてもエンジニアリングできるようにしよう」という方針が重要になります。その1つのための重要な武器がSaaSである、と僕は考えています。

少し立ち止まって、SaaSとは何か改めて振り返りましょう。SaaSとは、主にクラウドサービスとして提供されるアプリケーションソフトウェアやシステムのことを指します。クラウドサービスについては以前noteに書きました。

SaaSについては、次のように説明しました。

多くの企業は次第に「自分たちで開発しなくても、システムが使えればそれでよい」と気付き始めます。サーバー管理コストが安くなっても、そのサーバーを使って実現するWebサービスや業務システムの開発には多額のコストがかかります。一方、幸いにも多くのWebサービスや業務システムには、企業を超えて共通する部分があります。その共通部分については、自社で開発するよりも他社が構築したシステムを使わせてもらった方が一般にコストは安くなります。

要するに、SaaSというのは「企業を超えて同一の業務システムを共同利用しようぜ」というムーブメントです。これによって、それまで各社が独自にやっていた業務システムの構築や運用が不要になったというわけです。これでエンジニアのリソースが逼迫する自体はだいぶマシになりました。めでたしめでたし。

SaaSはエンジニアリングの民主化を加速させる

ただし、ここで1つ問題があります。それは、SaaSを自社の業務に組み込むプロセスについてです。

1つのSaaSは業界や事業特性が異なる複数の会社によって共同利用されます。たとえば、SmartHRのプレスリリースによるとSmartHRの登録企業数は2020年11月時点で30,000社を突破しています。これほどの数の会社が、全く同一のシステムを使っているわけです。世の中のSIerがシステムのカスタマイズで儲け続けていることを思うと、にわかには信じられない事態です。

実際、SaaSをただ契約しただけでは自社の業務にフィットさせることはできません。当然、初期の設定やアカウント管理は必要になります。また自社の既存業務とそのSaaSを比べて機能的にちょっと足りない部分も見えてきます。そのときは、SaaSの機能に合わせて業務フローを変えたり、SaaS側の高度な設定でなんとか回避したり、別のSaaSとの連携によって実現したりすることになります。独自に構築したシステムは自由にカスタマイズができる（はず）のとは違って、SaaSを使う以上は「言うことを聞かないシステムと折り合いを付けてなんとか業務フローを実現していく」というプロセスを踏むことになります。

つまりは、自社や他社のエンジニアが独自にシステムを構築していたものが、SaaSの導入と非エンジニアの頑張りによって代替されつつあるということですね。これを言い換えたのが、前述した「エンジニアじゃなくてもエンジニアリングできるようにしよう」の真意です。

SaaSカオスマップと組み合わせの創造性

抽象的な話が続きました。実際のSaaSプロダクトに触れる機会が少ない方は、「SaaSを駆使すれば非エンジニアでも業務システムを構築できるぞ！」と言われてもピンと来ないかもしれません。「自分の業務に対応するSaaS製品が世の中にあるとは思えない」と感じる可能性もあります。

ある界隈の企業やサービスの多さを表現するための図式化の手法として、カオスマップというものがあります。One Capitalが公開しているカオスマップを見ると、国内SaaS製品だけでも膨大な数があることがわかります。ちなみにホリゾンタルSaaSとは、SmartHRのように利用企業の業界を問わず使えるようなSaaSのことです。

（出典: 「ホリゾンタルSaaS カオスマップ2020」を公開します｜One Capital｜note）

さらに最近は、特定の業界に特化したSaaS（バーティカルSaaS）もたくさん生まれつつあります。レガシーな業界の負を解消したいという熱い思いを持った起業家たちがたくさんSaaSを立ち上げている状況は、とても頼もしいですね。

（出典: 「バーティカルSaaS カオスマップ2020」 を公開します｜One Capital｜note）

ちなみにこのカオスマップも国内SaaSプロダクトのごく一部であり、またSlackやSalesforceなど海外プロダクトも含まれていません。

ということで、「この業務システムはSaaSになっていないだろう」と思っても、探すと意外と見つかるような状況になりつつあります。

当然、企業には様々な業務があります。また、それらは相互に連携が必要だったりします。SaaS利用も同じで、SaaSをヘビーに使っている企業の中では、複数のSaaSを契約してそれらを組み合わせて使っています。よくできたSaaSは、外部サービス連携のためのAPIを用意しています。

SaaSを武器に戦う非エンジニアにとってのエンジニアリングとはどのようなものでしょうか？それは、世の中の無数にあるSaaSプロダクトを調査し、自分がやりたいことを実現するにはどのプロダクトのどの機能を組み合わせればいいのか仮説を立て、実際にそれを検証していくようなプロセスになります。SaaSプロダクト側も日々変化していくため、それに合わせてSaaS利用者側もその使い方を日々見直していくことになります。

SaaSという発明

ここまでのまとめは、こちら。

・DXという言葉で表現される状況によって、エンジニアリングの需要が爆発的に高まっている
・十分なエンジニアの確保は厳しいので、非エンジニアがなんとかするしかない
・SaaSの盛り上がりによって、非エンジニアでも自社に合ったシステムを構築できるようになった

以上で、今回書きたかった内容はおわりです。

SaaSというものは、知れば知るほどよくできています。質の良いBtoBアプリケーションの開発とビジネスとしての成功を両立したければ、SaaS以外の手段が考えられないと思えるほどです。

最後に、僕の余りあるSaaS愛を抑えるために、本編に書ききれなかったSaaSのすごさをざっと補足します。SaaSが多くの利用企業を魅了できる理由について、次の3つに分けて軽く説明します。

・SaaSはサブスクモデルである
・SaaSはWebアプリケーションである
・SaaSはクラウドである

SaaSは主に月額や年額のサブスクリプション契約を前提とします。初期費用は無料か、かかってもかなり安いことが多いです。よって、「とりあえず使ってみよう」という意思決定がしやすくなります。システムのカタログスペックだけを見ても、実際に自分が求めているものなのかどうかを真に判断するには使ってみるしかありません。DX下の企業は、「変化に強くなること」が求められます。そのときに、独自システム構築で半年とか1年とかかけている暇があったら、とりあえず目の前のSaaSプロダクトを来月から試しに使って見た方が有利になることが多いはずです。

また、SaaSプロダクトには品質が高いものが多いという特徴があります。その理由はいくつかありますが、「SaaS開発側が余計なことを考えずに機能開発に集中できるようになっている」というのが大きいと思います。

1つは、Webアプリケーションであること。クライアントのPCへのインストールを前提としないので、サポートがかなり楽になります。まず、クライアントサイドのアプリケーションの複数バージョンサポートが不要になります。また、Webブラウザレベルで動作を担保すればいいので、PC端末やOSの違いによって発生するバグの多くを回避することができます。Webブラウザという偉大なソフトウェアの恩恵を受けられるわけです。

もう1つは、クラウドであること。オンプレサーバーにインストールするタイプのパッケージシステムと違って、こちらも複数バージョンのサポートが不要になります。「1つのシステムを全クライアントが共同利用している」というシンプルなアーキテクチャによって、気にすべきことを大きく減らせます。

これらの事情によって、同じ機能を作るにしてもパッケージソフトと比べてSaaSの方が一般にコストが安くなり、それだけ新機能開発や機能改善に投資しやすくなります。

他にも、利用データの取得がしやすい、ライセンスの管理が楽、プロダクトの品質向上が売上に直結するなど、SaaSにはプロダクト開発において有利な点がたくさんあります。このあたりは、個々のテーマを掘るだけでもそれぞれ1記事書けそうなくらいなので、また別の記事で紹介しようかなーと思ってます。リクエストあればぜひください。