2020年11月6日(金)に開催されたCROSS2020というオンラインイベントに、登壇者として呼んでいただきました。コミュニティ感の強いIT系勉強会で、様々なトピックのパネルディスカッションが行われました。

僕が2017年からやっているエンジニア向けポッドキャスト「しがないラジオ」のリスナーさんがイベント運営メンバーにいたことで、「普段のポッドキャストで話すようなことをセッションで喋ってくれませんか？」ということになったという経緯です。そしてなんと、このイベントの運営に関わるさくらインターネット株式会社の田中社長と対談できることになりました。

田中さんは沖縄に住みながら、日本最大手のサーバーホスティング会社の社長業をしつつ、複数のIT業界団体の理事も務めています。そんな田中さんから日本のIT業界について1.5時間も話を聞けたのは、とても幸せな時間でした。参加者の方からは、「神回」というお言葉もいただきました。

中でも個人的にハッとさせられたのは、「既存のソフトウェアを使うのか内製化するのかの線引き」についての話でした。僕が「大体の業務は既存SaaSでカバーできる今、あるシステムを内製化するかどうかの判断ってどうすればいいんですかね？」という旨の質問をしました。それに対して田中さんは少し悩んでから、「1つ重要なのは、自社向けにシステムを作ったとしても、それをSaaSで売りなさいということかな」といいました。この発言は一見すると、多くの企業にとって突飛で難易度の高いことのように思います。しかし考えれば考えるほど合理的に思えてきました。

今回のnoteでは、「システム内製化するならSaaSとして売る」というルールを設けることが、なぜ合理的で強いかについて考えてみました。

ちなみに、実際に田中さんが話している様子は、イベントのYouTubeアーカイブ動画から見られます。1.5hもあって長いので、該当の話をしている箇所のリンクを貼っておきます。

ITシステムが欲しくなったらどうするか？

さて、あなたの会社が目の前の業務を効率化したり新しい事業を始めたりするとき、多くの場合は何らかのITシステムの調達が必要になります。

とある業務をカバーするシステムが欲しくなったとき、少なくともテクノロジーに強い企業の中では、次のような順番で選択肢を検討します。

まず、そのシステムが本当に必要かを考えます。システム導入のためのコストやリスクを最も軽減する選択肢は、システムの導入自体を取りやめることです。「本当にそのシステムが必要か？」を問い直すことで、「そもそもシステムを導入しない」という選択肢の妥当性を検証します。同時に、「本当に必要だとしたら、そのシステムに最低限求められる要件は何か？」を考えます。

「そのシステムは必要」という話になると、すぐに「じゃあシステムの開発をしよう」という判断をしがちです。その気持ちをグッと抑えて、「すでに世の中にあるソフトウェアで実現できないか？」を考えます。ご存知の通り、システムを内製したり外注したりするには、それなりのコストとリスクを伴います。誰かがすでに近いものを開発しているなら、なるべくそれに乗っかるべきです。極端な話をすると、Googleスプレッドシートを使いこなせれば単純な業務システムはなんでも実現できてしまいます。そうじゃなくても、昨今のSaaSブームで大抵の汎用的な業務は既存SaaSの利用でカバーすることができます。

その業務が既存ソフトウェアで実現できないと予想される場合、または実際にSaaSなどを使ってみて限界が来た場合に、初めて「自社のためにそのシステムを開発しよう」という判断が行われます。システムを開発する際の選択肢は、雑に分けると「内製する」か「外注する」の2択です。このうち内製の方が優先度が高い理由は、以前noteに書いた通りです。

ここまでのイメージをシンプルな図にまとめてみました。

この図では、ほとんどの企業で共通する業務については同じ "SaaS z" （Horizontal SaaS）が使われています。たとえばGoogleスプレッドシートやSmartHRをイメージするとわかりやすいかもしれません。そこに業界特化のSaaS（Vertical SaaS）が積み上げられて行きます。とはいえまだSaaSで賄いきれない業務やSaaS化に向いていない珍しい業務については、内製や外注によってシステムが構築されます。

ちなみに、PaaS的にも使える汎用的なSaaSが増えた結果、「SaaSを使うこと」と「システムを内製化すること」の線引きはやや曖昧になってきています。たとえば前述したGoogleスプレッドシートは代表的なSaaSですが、Google Apps Scriptを駆使するなどして簡単な業務システムを構築することもできます。

また、ここでは「ソフトウェア」と書くべきところをあえて「SaaS」と書いています。業務によってはデスクトップアプリケーションやパッケージシステムが主流のケースもあると思いますが、大半はSaaSに置き換えられていくという予想も込めています。

「システム内製化するならSaaSとして売る」の事例

今回の主題は、「システム内製化するならSaaSとして売る」というルールについてでした。先ほどの図の「内製」部分が全て「自社SaaS」（内製して自社でも使っているが、SaaSとして外販もしている状態）に変わったとすると、次の図のようになります。

このような事例は世の中にあるのでしょうか？

実際、エンジニアを多く抱えるテック系企業には、自社システムをSaaSとして外販する事例が多くあります。

極端な例はAmazon/AWSです。Amazonの巨大なECや物流網を支える様々なシステムは、AWSプラットフォーム上で外販されています。有名なのはIaaSやPaaSと呼ばれるクラウドインフラ領域ですが、コールセンター構築のためのAmazon Connectやドキュメント共有のためのAmazon WorkDocsのように、アプリケーションレイヤーに近い製品も提供されています。これらはAmazonというグローバルECプラットフォームの実現のために内製された自社システムに対して、手を加えて他社でも使えるようにし外販されているものです。

Salesforceも多くの内製システムをSaaSとして外販しています。Salesforceにはその製品群について顧客やパートナーが学ぶためのオンライン学習サイト「Trailhead」がありますが、その学習コンテンツ作成機能はSaaSとして切り出され、myTrailheadという名前で外販されています。myTrailheadを契約した企業は、「自社の社員教育のための学習コンテンツを、Trailheadと同じプラットフォームを使って構築できる」というわけです。他にも、Salesforce社が顧客やパートナーとのコミュニケーションのために使っているフォーラムなどのシステムは、Experience Cloudとして外販されています。

国内企業の例もあります。たとえば株式会社はてなでは、自社サービスのために内製していたサーバー監視システムを、Mackerelという開発者向けSaaSとして外販しています。他の会社でも、たとえば受託開発事業を効率化するために内製していたシステムをSaaSとして外販する事例などを目にしたことがあります。

また所謂テック系企業以外の事例も、少ないながら存在します。

国内で最も有名な事例は、おそらく老舗旅館業を営む陣屋でしょう。先代の跡を継いだ宮崎富夫さんは、元本田技術研究所のエンジニア。ITシステムを内製しながら業務効率化を進め、10億円もの負債を抱えた旅館をわずか3年で黒字化。さらにその旅館管理システムを「陣屋コネクト」というSaaSとして外販し始め、立ち上げからわずか6年で年商2億円を売り上げるまでの事業に成長したそうです。

このように、自社内製システムをSaaSとして外販するという事例は確かに存在します。それでは聡明な各社は、なぜ自社システムの外販などという一見面倒臭そうなことをするのでしょうか？

オープンソース文化と車輪の再発明

「システム内製化するならSaaSとして売る」という戦略を深く理解するための近道は、オープンソース文化にあります。オープンソースについては語ることが多すぎるのでまた別の記事で詳述しますが、ここではSaaSとの対比の中で簡単に触れたいと思います。

ソフトウェアの内部は、小さな部品の組み合わせでできています。現代のソフトウェア開発において、その部品全てを自社で内製するということはまずありません。ではどうするかというと、多くのソフトウェアで共通に使われる部品については、オープンソースソフトウェア（OSS）を使います。OSSは、文字通りソースコードがインターネットを通じて世界に公開されており、指定のライセンスに従えば大抵は無料で商用利用することができます。たとえば日付計算、グラフ描画、暗号化など、多くのソフトウェアに共通して求められる部品については、世界の誰かがすでに開発しOSSとして公開してくれています。

OSSが豊富にある現代では、前述したシステム調達と同様の選択肢が、ソフトウェア部品調達にも生じます。

既存のOSSがあるのに同じ機能を自分で開発することは「車輪の再発明」と呼ばれ、一般的には「時間の無駄」を意味する言葉として使われます。

もちろん「ある既存OSSを使いたいが、自分が欲しい機能が少しだけ足りない」というケースもあります。そんな場合であっても、OSSは「オープン」であるので、開発コミュニティに機能要望を出したり、なんなら自ら欲しい機能を開発して「良ければ次のバージョンに入れてくれ」とオーナーに言うことすらできます。

それでも、OSS化されていない領域や既存OSSが気に食わない場合は、代わりに自社で開発するということもあります。この「OSSが無いからソフトウェアを内製しよう」という判断は、前述した「SaaSが無いからシステムを内製しよう」という意思決定にとても似ています。

そしてソフトウェア産業の世界の中では、「ソフトウェアを内製するならOSSとして公開しよう」といったことがしばしば行われています。代表的な例はGAFAで、たとえばGoogleでは自社が公開している大量のOSSを検索するためのサイトまで提供されています。また日本のテック企業でも、そこそこの規模になれば大抵の会社は何らかの内製ソフトウェアをOSSとして公開しています。（たとえば、「クックパッド オープンソース」のように、「"会社名" オープンソース」で検索してみてください。）

雑に図示すると、あるシステムやソフトウェアは既存OSSと内製した部分との組み合わせでできています。ただし、内製した部分の一部は自社OSSとして外部に公開されます。

これを聞くと、「せっかく自社で作ったソフトウェアをなぜ無料でOSSとして公開するのか」と疑問に思うかもしれません。そのメリットをこの記事だけで全て伝え切ることはできませんが、わかりやすいメリットを一言で言うなら「OSSとして公開することで、利用者コミュニティから多くのフィードバックを貰い、より質が高く変化に強いソフトウェアに育てられる」という点が挙げられます。ソフトウェアは、その利用者が多いほど、品質改善のためのサイクルを高速に回すことができます。OSSとして公開してでも自社のソフトウェアの品質を上げることは、その最大の利用者である自社にとっても重要というわけです。

オープンにすることで独自開発のリスクを回避する

「システム内製化するならSaaSとして売る」という行為にも、「ソフトウェアを内製するならOSSとして公開する」と同様のメリットがあります。「自社システムをSaaSとして外販する」と聞くと、「新たにSaaS事業を立ち上げて売上を伸ばしたいんだな」という感想を抱く人が多いでしょう。しかし、たとえ自社システムを無料で公開したとしても、そこには大きなメリットがあります。（もちろん、SaaSとして公開する場合は普通インフラコストがかかるので、無償提供するわけにはいかないでしょうけれど。）

自社システムをSaaSとして広くオープンに外販することは、主に次の2つのリスクを回避することにつながります。

1つ目のリスクは、システムの改善サイクルが止まってしまうリスクです。SaaSとして広く提供されている世の中のシステムは、多くの利用者のフィードバックを糧に毎日のように改善されていきます。それを利用する企業の業務効率もどんどん上がっていきます。こうした中で、自社だけが「改善が止まったシステム」を使い続けることは、競争優位性を失うことにつながります。もちろん、そのシステムにお金を払う企業が多いほど、システム改善にかけられるコストも大きくなります。「世の中のSaaSの改善スピードに勝つために、自社システムもSaaS化する」というわけです。

実際、前述した陣屋コネクトについても、「システムをもっと進化させるために外販を始めた」ということがITmediaの記事に書いてあります。

2つ目のリスクは、APIエコシステムから孤立するリスクです。現代において、ITシステムは相互に連携することが求められています。個々のシステムが他のシステムから完全に独立して動くということは稀で、データ統合や自動化の観点から、他のシステムと相互に連携することで価値を増します。SaaSとして公開することで、外部のSaaSから連携してもらいやすくなり、孤立したシステムになりにくくなったりします。この点についてもここでは説明しきれないので、別の記事で詳述したいと思います。

他にも、自社システムをSaaSとしてオープンにすることで、エンジニア採用のためのブランディングにつながったり、事業としての柱が増えたり、様々なメリットがあります。

ちなみに、IT産業の歴史の中で「オープン化」というと、メーカー独自の非公開仕様に基づくメインフレームをUNIX系OSなど標準的な公開仕様に基づくサーバー製品に置き換えるような動きを指します。1980〜90年代に巻き起こったインフラレイヤーの「オープン化」に対して、現代はアプリケーションレイヤーにまで「より標準的でオープンであれ」という力学が働き始めているとも言えるかもしれません。（厳密に言えば、ソースコードが公開されていないソフトウェアはまだまだ真に「オープン」とは言えませんが。）

利用企業から見た「SaaS版自社システム」の価値

システムを開発する側だけではなく、それをSaaSとして利用する企業から見ても、「開発会社が実際にそのシステムを自社の業務で使っている」というのはとても魅力的です。

最大の理由は、その業務と無関係のITベンダーが作っている製品よりも品質が高いことが期待されるからです。実際に業務が発生している会社内でその業務のシステムを開発・改善した方が、一般的には品質が良く使いやすい製品ができます。これは、外注より内製の方が品質が上がりやすい話と全く同じです。そのSaaSの品質が低いことはSaaSベンダー自身の業務に影響するので、SaaSベンダーが利用企業と同じ目線に立ってサービスを改善し続けてくれることが期待できます。また、開発会社自身がそのSaaSの魅力的な利用事例になります。

なお、世の中のSaaSが全て「自社システムを外販する」というプロセスから生まれるわけではなく、最初からSaaSベンダーとして事業をスタートさせる会社もたくさんあります。しかしそのような場合であっても、顧客目線に立って製品の改善サイクルを回すために、SaaSベンダーは社内業務に自社サービスを積極的に使う傾向にあります。このような目的で企業が実際に自社製品を使うことを、「ドッグフーディング」と呼びます。

SaaS版の開発は難しい？

もちろん、自社だけが使えれば良かった内製システムをSaaSとして他社にも使ってもらうためには、それ相応の準備が必要になります。中でも大変なのは、開発の手を入れなければならない点です。1社だけで使うものを複数社で使えるようにするには、請求管理、プロジェクト管理、セキュリティ、スケーリング、など追加で必要になる要素がたくさんあります。社内システムしか開発したことがないチームがSaaSを作るには、超えなければいけないハードルがたくさんあります。

一方、こうしたSaaS開発を支援するような製品も世の中にたくさんあります。たとえば前述した陣屋コネクトは、Salesforce社が提供するSalesforce Platformと呼ばれるPaaS上で開発され、ログインや決済の機能も全てSalesforceのプラットフォームを利用しています。

陣屋コネクト 宿泊施設向けクラウドアプリケーション - AppExchange

もしSalesforceのようなフルパッケージのプラットフォームに乗っかるのが嫌なら、SaaS開発に利用できるSaaSを使うという手段もあります。たとえばAuth0のようなアカウント管理のためのSaaSや、Stripeのようなオンライン決済のためのSaaSを使うことで、一部の機能を開発せず別のSaaSで補うこともできます。これによって、自社システム独自の機能開発に集中することができます。

このようにサービス開発者向けのSaaS/PaaSが増えたことで、自社システムをSaaSとして外販するためのハードルも下がってきています。

「そのシステムはSaaSとして売れるか？」

すでに述べたとおり、システムを新しく開発する行為はそれなりのコストとリスクを伴います。特に「変化を止めたシステム」を抱え続けることは、この変化の激しい現代において大きなリスクにつながります。システム開発の意思決定を前にして、「そのシステムはSaaSとして売れるか？」という問いを自らに投げかけることは、こうした選択を客観的に見つめ直すきっかけになります。

もちろん東証のシステムのように、その性質上、内製化することすら難しいものもあります。

しかし、大抵の会社の大抵の業務システムは、誰かがすでにSaaS化しているか、他社にとってもニーズがあるものか、いずれかになります。「そのシステムはSaaSとして売れるか？」という問いに答えることは、次の2つの要素を検証することになります。

この問いに自信を持ってYesと答えられるなら、実際にシステムを開発しSaaSとして外販する中で、次のようなプロセスで改善サイクルを回し始めましょう。

SaaSというビジネスモデルを介したこのシステム改善サイクルを回し続けることは、「より良い業務の進め方を考えた結果が、システムの価値として積み上がり、その価値が広く社会に還元されるような営み」を実現することに他なりません。そんなサイクルが回っている会社で働くことは従業員としても価値実感を得やすくきっと楽しいですし、企業の社会的価値も上がって社外のファンも増えるし、良いことづくしに思えます。

この記事が、そんな素敵な会社がたくさん生まれる世界への一助になれば嬉しいです。