DX系SaaSスタートアップ 事業開発の全体像
こんにちは。GLOBIS CAPITAL PARTNERSの野本です。
SaaSビジネスに関しては、メトリックスに関するノウハウはネット上でも豊富な一方で、（僕が見つけられていないだけかもしれませんが）事業開発的な切り口が少ないと思ったので、DX系SaaS事業開発の全体像についてnoteにしてみました（12,000字超なのでちょっと長めですが、ぜひお付き合いください）。
SIerとDX系SaaSの関係
日本の巨大産業における生産性を高めるという文脈でデジタルトランスフォーメーション（以下「DX」）を唄うSaaSスタートアップ（以下「DX系SaaS」）が増えてきていますが、コロナ禍でさらに加速した業務リモート化・ペーパレス化の機運により、DXへのニーズは今後ますます強くなるものと思われます。
個人的にも強力に推進していきたい分野ですが、一方で、日本企業もこれまで何もしてこなかったわけではなく、後述のように、パッケージソフトウェアを利用した取り組みが行われてきました。
すでにDXの前身ともいえる取り組みをしてきたプレイヤーがいて、しかも、彼らもDXに強力に取り組んでいくことを標榜している以上（例えば、NTTデータ）、DX系SaaSとしては、これまでエンタープライズを中心とした日本企業のIT基盤を支えてきたエンタープライズシステム勢（正確性が犠牲になりますが、議論をシンプル化するため、本稿ではSAPなどのパッケージソフトウェアベンダーとその導入を支援するSIerをワンセットとして扱います。）の動きも注視しなければなりません。
そこで、大手企業をクライアントとするDX系SaaSとして、エンタープライズシステム勢とどのような住み分け、どのような戦い方をしていかなければならないのかについて、自分の思考を整理してみました。
そもそもDXとは何か
DXという言葉を目にしない日はないのですが、皆さんは「DX」から何を思い浮かべますでしょうか。おそらく、スタートアップ界隈の人と、僕が以前在籍していた大手通信キャリアの人とでは、まったく違うものをイメージしていると思います（実際、ディスカッションの内容がまるで異なります）。
DXレポート（経産省）が引用するIDC Japanの定義によると、DXとは
企業が外部エコシステム（顧客、市場）の破壊的な変化に対応しつつ、内部エコシステム（組織、文化、従業員）の変革を牽引しながら、第３のプラットフォーム（クラウド、モビリティ、ビッグデータ／アナリティクス、ソーシャル技術）を利用して、新しい製品やサービス、新しいビジネス・モデルを通して、ネットとリアルの両面での顧客エクスペリエンスの変革を図ることで価値を創出し、競争上の優位性を確立すること
とあります。
DXというと、自社の内部システム（バリューチェーン）のデジタル化がハイライトされがちですが、競争環境の変化に合わせて自社の経営戦略をアップデートされることが前提になっているのがポイントかと思います。これは、経営戦略/事業戦略レイヤーの見直しまで含み、かつ、（業界ベストプラクティスではなく）自社固有の戦略に適合したバリューチェーン全体のデジタル化を意味するものであり、大手企業の「中の人」がイメージするDXに近いのはこちらの概念なのではないかと思います。
一方で、部署単位/機能単位における、業界ベストプラクティスの導入を通じた業務改善/業務効率化を指してDXと呼ぶケースも少なくありません。文脈によっては、バックオフィス系のホリゾンタルSaaSも含まれる場合もあるかもしれません。紙やFAXのリプレイスも、エンタープライズソフトウェア勢がこれまで手をつけてこなかった（つけられなかった）領域のDXだといえます。SaaSスタートアップがいうDXは、こちらを意味していることが多いのではないでしょうか。
私見となりますが、これらはまったく別物ではなく、同一平面上のポジショニングの違いにすぎず、DX系SaaSとしては、どの象限で戦うのか、スコープを見定めることが非常に重要になると思われます。
具体的には、「全社・基幹系―機能特化」軸と、「自社カスタマイズ―業界ベストプラクティス」軸で整理できるのではないかと考えています（この整理も私見に基づく暫定的なもので、今後ブラッシュアップしていきたいと思っています）。
前置きが長くなりましたが、以下では、このマップを参照しつつ、
１）これまでエンタープライズソフトウェア勢がどのように動いてきたか
２）これからどのように動いていくと想定されるか
３）その中でDX系SaaSがどのように事業開発していくべきか
について検討していきたいと思います。
これまでのエンタープライズシステムの変遷
基盤がメインフレームからオープン系に移行し、そこからクラウドに移行してきているのは自明として、エンタープライズシステム勢も、①元々は部門最適だった業務システムを全社最適に総合し、かつ、②積極的に標準化/パッケージ化に向けて努力してきたという歴史があります。
① 部門最適から全社最適へ
「SAP 会社を、社会を、世界を変えるシンプル・イノベーター」によれば、以下のとおり、ERPとは、エンタープライズソフトウェアを通じて元々は部門ごとにバラバラだった業務システムを全社最適に統合していく取り組みそのものだったとのことです。
ERPが登場する以前の企業では、部門ごとにオーダーメイドシステムを構築することが一般的であり、経理部門システム、販売部門システム、製造部門システム、購買部門システムなど、その部門における業務ニーズを満たすシステムが作られていた。ERPが全社最適の観点から構築されるシステムだとすれば、これらは部門最適のために構築されるシステムだといえる。そして、現在でも多くの企業がこの「部門最適システム」の状態にとどまっている。（「SAP 会社を、社会を、世界を変えるシンプル・イノベーター」）
個別部門の最適化だけを念頭に置いたシステムから、部門間の情報連携を考慮し、全社的な経営判断を行ううえでの明確な指標、とくに利益や原価など「カネ」のデータを瞬時に入手できる情報システムに発展していくことは必然の流れである。（「SAP 会社を、社会を、世界を変えるシンプル・イノベーター」）
② 積極的な標準化/パッケージ化
また、エンタープライズソフトウェア勢のうち、少なくともSAPなどのソフトウェアベンダーに関しては、個別開発ではなくベストプラクティスの蓄積を志向してきたとの指摘もあります。
案件を重ねるうちに、どの企業も同じような業務要件を抱えていることに気がついた。要件が同じであれば、一度開発したプログラムを別の顧客にも適用できないか。プログラムのソースコードを資産として、利用者間で再利用できるのではないか。（「SAP 会社を、社会を、世界を変えるシンプル・イノベーター」）
多数の企業から集約した膨大なベストプラクティスを備え、これらの取捨選択によって自社業務にフィットするシステムを構築するという仕組みを作り上げた結果、SAP ERPはポテトチップの製造販売から航空機やタンカーの受注生産、電力会社、銀行、政府機関まで、多種多様な業務に対応できる柔軟性を手に入れた。（「SAP 会社を、社会を、世界を変えるシンプル・イノベーター」）
エンタープライズシステムの現状
では、上記の努力は奏功したのでしょうか。
詳細は分かりませんが、欧米では一定程度、全社最適化やパッケージ化が推進されてきたようです。一方で、日本のユーザー企業としては、「全社最適×標準化」という理想には到達できていないとの認識が強いのが実情です。
業務プロセスを変革することができず、結局アドオンを多数開発し、標準化にはほど遠く、データ活用もままならならず、維持管理に多大なコストをかけている（日本企業のためのERP導入の羅針盤）
また、システムの「レガシー化」すら発生してしまっています。システムの「レガシー化」とは、「ユーザ企業において、自社システムの中身が不可視になり、自分の手で修正できない状況に陥ったこと」をいい、その結果、事業環境の変化に対して既存システムのアップデートが追い付かないという問題が生じています。この点については、DXレポートや日本企業のためのERP導入の羅針盤に詳しく書かれています。
エンタープライズシステムが抱える問題・課題
「ベストプラクティスを標準化して、全社最適を実現する」という取り組みが必ずしも奏功していない理由については、日本企業のためのERP導入の羅針盤などにおいて詳しく議論されていますが、個人的には、以下の２点に抽象化・収斂するのではないかと考えています。
① 個別開発問題
まず１つ目が、結果的に標準パッケージを利用せずに、個別開発をする「重力」が強いことです。個別開発には、ソフトウェアエンターベンダーが用意するプログラムライブラリーの組み合わせを行う開発に加えて、アドオンの独自機能を開発することも含まれます。
この「重力」が働くのは、まず、(1)日本企業においては現場の声が強いという事情が影響しているようです。
業務自体を一番理解しているのは最前線の一般社員や派遣社員であり、意思決定する上司は彼らが具体的にどんな事務処理をしているのかまでは知らない。部長クラスは画面を見たこともない。責任者だから「意思決定せよ」と言われても判断できない。下から「これでは仕事ができない」と言われてしまうと反論する材料がない。結果的に現場の言うままに「アドオンを作れ」となり、膨大なコストがかかった。（日本企業のためのERP導入の羅針盤）
業務現場の発言力が強い我が国においては、業務のやり方が変わることへの抵抗が強く、「業務にシステムを合わせる」という理由からパッケージをカスタマイズする需要が生み出され、開発の需要を膨らませていきました。（「システムインテグレーション再生の戦略」）
また、「重力」をもたらしている２つ目の要因としては、(2)SIerとしても、受託のビジネスモデルを採用している以上、稼働向上につながる個別開発をするインセンティブが強いことも指摘されています。
ベンダー側としても、アドオンは売上につながるので、積極的に提案するケースが多い。（日本企業のためのERP導入の羅針盤）
加えて、(3)特に、非競争領域や非コアコンピタンスの機能単位とは異なり、全社横断・基幹系のシステムを構築しようとする場合、システムを個社の経営戦略に適合させる必要があるので、どうしても個別性が高まりカスタマイズが必要になります。全社横断・基幹系に近いシステムであればあるほど、個別開発・カスタマイズの「重力」が強く働く可能性があります。
その結果、日本におけるエンタープライズソフトウェア勢は、個社に合わせたカスタマイズをビジネスの中心とするに至ったものと考えられます。
② 作りっぱなし問題
「ベストプラクティスを標準化して、全社最適を実現する」という取り組みが必ずしも奏功していない２つ目の原因は、システムの「導入」が目標になってしまった結果、いったんシステムを構築してしまうと、SIerによる保守は行われても、自社による保守や運用（その結果としての効果）のモニタリングが行われないという問題にあります。
これは、エンタープライズシステムの導入がプロジェクトベースで実施され、導入が終わるとチームが解散してしまってきたことや、USと異なり日本は社内エンジニアが足りておらず、SIerが全面的に開発を受託してきたため、自社で手を入れられないという点も寄与しているとの指摘があります。場合によっては、SIerに要件定義を含めて委託してしまっており、ユーザー企業において「何を作っているのか」すら把握していない場合もあるとのことです。
その結果として、ユーザー企業ではシステムに手を入れることができなくなり「レガシー化」が進んでしまったのです。
エンタープライズソフトウェア勢の今後の動き
以上が、過去から現在までの振り返りとなります。
DX系SaaSの事業開発の話に入る前に、上記の①個別開発問題と②作りっぱなし問題の２点に対して、エンタープライズソフトウェア勢が今後どのように進化していく可能性があるのかを検討したいと思います。
① 個別開発問題への対応
まず、エンタープライズソフトウェア勢は、個別開発問題に対しては、より強力にノンカスタマイズ・パッケージでの対応を推進していく方向性が想定されます。
需要の多い機能や独自のノウハウをシステム部品化したり、テンプレート化したりすることです。また、構築や開発、コンサルティングをメソドロジー化するといった取り組みも考えられます。（「システムインテグレーション再生の戦略」）
一方で、ノンカスタマイズ・パッケージを通じてユーザー企業に対して価値提供するためには、「ベストプラクティス」に対する深い理解や洞察、既存の業務フローやシステムを捨てさせる説得力、そしてそのベストプラクティスをユーザー企業に採用してもらうための現場オンボーディングが求められます。
この点、DXレポートでは「変化の速いデジタル技術にキャッチアップすることによりユーザ企業に価値を提供することの重要性」が強調されていますが、実は、バーティカルの現場理解・業務理解もそれと同じかそれ以上に重要なのではないでしょうか。エンタープライズソフトウェア勢として、現場を説得できるだけの特定業界に特化した深い知見を蓄積していく必要があります。そのためには、（特にSIerとして）インダストリーカットの組織をつくるなど、大きな組織変革が必要になると思われます（すでに着手しているSIerも少なくありません）。
また、エンタープライズソフトウェア勢はイノベーションのジレンマに直面する（している）可能性も高いといえます。ユーザー企業は、社内にエンジニアが十分にいないため、DXを推進するにあたってエンタープライズソフトウェア勢に頼らざるを得ない状況にあるとの指摘もあります。SI業界の今後の考察」でも言及があるように、実際、SIer（メーカー系を除く）の業績は売上・利益とも伸びています。SIer自身も人材不足が深刻であるため、利幅の薄い案件を断り、結果として案件採算が向上しているとの指摘もあります。
この状況の下では、エンタープライズソフトウェア勢としては、直近においてあえて新しいビジネスモデルに移行する強いインセンティブを持ちづらいのではないでしょうか。
「一時的な売上減少、中長期的な利益拡大」というKPIを受け入れられるかどうかは重要な要件です。これを株主や借入先の金融機関が受け入れてくれるかどうかも大きなハードルとなるでしょう。……案件単価は下がっても回転率を上げることで、利益の規模を確保することは可能です。ただ、それが軌道に乗るまでは売上は減少、および初期投資に伴う利益の減少を受け入れなければなりません。（「システムインテグレーション再生の戦略」）
② 作りっぱなし問題への対応
作りっぱなし問題については、エンタープライズソフトウェア勢としては受託モデルから脱却し、アプリケーション提供型やレベニューシェア型のビジネスモデルに移行し、顧客によっては成果にもコミットしていくことが想定されます（「システムインテグレーション再生の戦略」）。
そのためには、ユーザー企業の業務への深い理解が求められることに加えて、アプリケーション型のビジネスを推進できる人材の獲得・組織の構築も含めて、やはり大胆な組織変革が必要になると想定されます。
こういうケースによくあるのが、あるお客様の要望にあわせてシステムを構築し、「これを横展開すれば、ほかのお客様にも使っていただけるだろう」との期待からサービスを作ってしまうことです。そのようなケースでは、次のような検討がなされていないことが多いようです。
・そのお客様を含む、ターゲットとしている顧客層の需要を十分に満たす機能なのか？そもそも、ターゲットとする顧客層を明確に定義しているのか？
・競合となる製品やサービスと比較し、どのような競争優位があるのか？それがお客様の選択に大きな影響を与えるのか？
・お客様の受け入れてくれる料金になっているのか？
・現行業務の何を代替し、そこにかかるコストをどれだけ減らせるのか？
・「新たな仕事の仕方により、できなかったことができる」「新たな売上を獲得できる」といった、料金に見合うメリットを合理的に示すことができるのか？（「システムインテグレーション崩壊～これからSIERはどう生き残ればいいか？」）
つまり、上記のような項目を当然のように検討できるSaaSベンダー的な組織への変革を進めなければなりません。これは、いま抱えている社内人材だけで実施するのは現状難しいとの見方もあります。
その理由は、そもそも不慣れであるという点に加えて、収益性の高い「ユーザー企業の既存システムの運用・保守にかかる業務が多く、ベンダー企業の人材・資金を目指すべき領域に十分にシフトできない」（DXレポート）のが現状で、新規ビジネスにリソースを配分するには、既存の保守業務から人員が解放される必要があるからです。これは、リソース不足の現れであると同時に、収益性の高い案件を優先し続けてしまう、イノベーションのジレンマの側面もあるように思えます。
DX系SaaSの事業開発
さて、いよいよ本題です。
以上のとおり、エンタープライズソフトウェア勢は、(A)ケイパビリティ含めた大幅な組織変革から必要であること、(B)イノベーションのジレンマに直面する可能性があることにより、「ベストプラクティス標準化」の象限に進出してくるには相当程度の時間を要するものと思われます。一方で、いろいろ課題はあるにせよ、ユーザー企業の基幹システム領域については、ビジネス的にも、人間関係的にも、しっかりとグリップしています。
これを踏まえた上で、DX系SaaSとしてどのように動いていくべきでしょうか。
橋頭堡となる「標準化×機能特化」象限
SaaSビジネスである以上、常にプロダクトをアップデートし続けるはずですし、カスタマーサクセスも徹底することが前提ですので、「作りっぱなし問題」は基本的には起きません。
留意すべきは、大手企業を相手にするが故の「個別開発問題」です。個別開発をしてしまうがために、複数の異なるシステムの面倒を見なくてはならなくなり、結果的に「作りっぱなし」になってしまうという構造もありますので、「個別開発」を断ち切るのが非常に重要です。
そして、「個別開発問題」に巻き込まれないように事業を立ち上げるにあたっては、「業界標準プラクティス」から入るのが正攻法であると考えられます。単なる表面的な業務フローのデジタル化では「現場の声」に押し切られて個別開発の「重力」に勝てないので、ここでは、ディープな業界・現場理解、とりわけ暗黙のノウハウをテックに落とし込んでいくことが重要になるのではないでしょうか。そのためにも、エンタープライズソフトウェア勢がすぐには構築できない領域特化のチームを組成して、深いノウハウを先行して蓄積することが重要となります。
また、全社的・基幹的な領域に対するソリューションは、個社としてのコアコンピタンスに関わり得るものであり、どうしても戦略との連動性を確保する必要もあり個別開発の必要性が高くなります。そして、この領域はまさにエンタープライズソフトウェア勢がグリップしている領域です。個別開発の「重力」を避けつつ、エンタープライズソフトウェア勢との正面衝突を避けるという意味で、まずは機能・部署特化から入るのが正攻法であると考えられます。特に、企業の競争力に関わらない協調領域のほうが好ましい可能性もあります。例えば、DXレポートには、以下のような記述があります。
協調領域については、個社が別々にシステムを開発するのではなく、業界毎や課題毎に共通のプラットフォームを構築することで早期かつ安価にシステム刷新につなげることができると考える（割り勘効果）（DXレポート）
これは、「複数の企業が共同でシステムを構築すること」を想定した文脈における記述ですが、まさに機能特化のSaaSにも当てはまる内容だといえます。
以上のように、DX系SaaSとしては、エンタープライズソフトウェア勢が得意でない、かつ、個別開発の「重力」を避けることのできる、「標準化×機能特化」の領域が橋頭堡になるものと考えられます。
「予算」の有無
しかしながら、「標準化×機能特化」の領域からの参入が比較的容易だということは、裏を返せばそこにエンタープライズソフトウェア勢がこれまで手を付けておらず、ユーザー企業において「予算」が配分されていない可能性があるということです（お財布が耕されていない、「無消費状態」）。だからこそ、「標準化×機能特化」の領域では紙やFAXのオペレーションが残ったままのケースが多いのではないでしょうか。
ここでは、セオリー的には業界リーダーのアカウントを獲得して先行事例とすることで、その競合や業界フォロワーが「予算」を確保する意思決定ができるようにしなければなりません。こちらの論点については、DX系SaaSのGo-to-marketについて詳しい相良さんの記事「システムインテグレーターとエンタープライズSaaSの交差点」を是非あわせてご参照ください。
エンタープライズソフトウェア勢との相見積もり
いざユーザー企業として「予算」を確保する場合、「それって自社のシステムとして開発できるんじゃない？」というトーンで既存代替手段であるエンタープライズソフトウェア勢との相見積もりや比較をされることが想定されます。
当然ながらDX系SaaSとしては、SaaSベンダーである以上、常にプロダクトが最新にアップデートされていくことを訴求することになるでしょう。エンタープライズソフトウェア勢が（旧来のビジネスモデルで）受託開発した場合、その後ソフトウェアのアップデートが難しいこととの差分をアピールしたいところです。
また、システムの内容にもよりますが、エンタープライズソフトウェア勢であれば、期間にして短くても半年程度、通常は数年間のプロジェクトになります。これに対して、オンボーディング含めてスピーディーに導入していく点がポイントになろうかと思います。
加えて、プライシングに関しても、エンタープライズソフトウェア勢であれば金額にして数億円から数十億円を投資することになります。これに対して、DX系SaaSとしては、初期費用が抑制でき、かつ、サブスクリプションによる長期的な課金をもってしても、投資対効果においてエンタープライズソフトウェア勢よりリーズナブルであることを定量的に明示できるとなお良いでしょう。SaaSのプライシングについては、四方さんの「SaaSのステージ別プライシング戦略」も是非あわせてお読みください。
データ連携の重要性
「標準化×機能特化」の象限を橋頭保とするといっても、ソフトウェアとして孤立してては、ユーザー企業の課題を解決できない可能性があり、基幹システムとの適切な関係性を保つことを意識しておく必要があります。
データ・情報資産を数多く保有しているにも関わらず、連携が難しく、活用しきれていない、全社最適に向けての活用が困難になっているという現状があり、AI、IoT、ビッグデータ等、先端的テクノロジーを導入したとしても、その基盤たる企業のデータ利活用・連携が限定的となり、その効果も限定的となっている。（DXレポート）
具体的には、連携しなくても単独で価値を出せるようにしておくか、あるいは、データが連携できるように対処しておく必要があります。特に、基幹系システムの中にあるデータを利用しなければならない場合、データ連携が生命線になるため、エンタープライズソフトウェア勢と上手に付き合う必要も出てくるので注意が必要です。
また、DX系SaaSの導入にあたって、一部のレガシーシステムや古い業務フローを捨てさせるのであれば、データを移行させる支援が必要となります。その際、中長期の事業展開や全社最適（例えばERPとの連携）も見据えた適切な形でデータを移行してサイロ化を防ぐことが重要ですが、一方で、ユーザー企業をロックインするためにデータの吐きだしを制限するという戦術もいちがいに否定できないため、自社の状況に応じてデータの扱いについて検討する必要があります。
基幹系システムの入れ替え・見直しタイミング
とくに基幹系システムの一部置き換えが発生したり、基幹系システムとのデータ連携が必要なDX系SaaSに関しては、基幹系システムの入れ替え・見直しタイミングを意識することが重要かもしれません。SAPについても、旧バージョンの保守サポートが2025年で終了してしまうという「2025年問題」が話題になっています。
システムを見直す入れ替えタイミングだからこそ、DX系SaaSの導入を検討する可能性も高まりますし、その際に一部置き換えやデータ連携の作業が発生したとしても抵抗が少なくなると想定されます。DX系SaaSに関しては、法規制の改正等に加えて、基幹系システムの入れ替えタイミングが一つのマーケットインのポイントになるかもしれません。
５つの展開オプション
以上の議論を前提として、「標準化×機能特化」の象限を軸足にするとした場合、大きく５パターンの事業展開オプションがあると考えます。なお、言うまでもなく以下の５つは排他的な関係にはなく、複数を組み合わせるケースも少なくありません。
① 「標準化×機能特化」の象限の深堀り
まずは、軸足となる「標準化×機能特化」の象限を深堀りしていく方向性です。市場として対象顧客数が多かったり、あるいは業界を横断してホリゾンタルな展開が可能であったり、アップセルを通じてARPUの向上が見込める領域なのであれば、これが一番正攻法ではないでしょうか。
一方で、プロダクトがニッチな業界（寡占であるため対象顧客数が少ないなど）に限定される場合、事業のスケーラビリティが確保できない可能性があります。
② プロフェッショナルサービス
２つ目は、SaaSを基軸としつつも、エンタープライズ企業の個別の要望に寄り添う形で、プロフェッショナルサービス、コンサルティング、個別開発対応でARPU向上を図る方向性です。
ただし、SIerと領域がオーバーラップする可能性がある点に注意が必要です。その際、「どれだけ安く、どれだけの工数を割けるか」という比較軸に持ち込まれるとSaaSスタートアップとしては分が悪いため、あくまでもプロダクトを軸に据えた付加価値ベースでの比較に持ち込む必要があります。
また、組織的にも、プロフェッショナルサービス・コンサルティング部隊を構築する必要があります。プロダクトドリブンなチームとは求められる能力要件が異なることも多いので組織構築に留意が必要です。
③ 領域・機能拡大
３つ目は、自社でプロダクトの領域・機能を拡大していくという方向性です。例えば、会計からスタートして中小企業向けERPまで展開しているフリーがこれに当たります。
着実にプロダクトを積上げていく必要があり時間がかかるのと、ユーザー企業が大企業であれば、プロダクトラインナップが全社的・基幹寄りになればなるほど個別開発の「重力」が強くなるため、これに逆らって事業展開をしていく必要があります。個社に応じたカスタマイズ性すら、UI上では類型化・標準化するなど、プロダクトにも相当な工夫が必要となります。
④ SaaS連携・iPaaS
４つ目は、iPaaSやAPI連携を通じて、他の機能特化SaaSと共に（仮想）基幹システムやエコシステムを作り上げていくという方向性です。Sansanなどがこの方向性で展開しているように見受けられます。
これまで、SIerは、SAPなどが提供するプログラムライブラリー群を組み合わせる開発などを通じてERPプロジェクトを推進してきました。しかし今後は、機能特化のSaaS群がこれを代替できる可能性があり、それを実現するのがiPaaSやAPI連携です。
なお、ここまで「エンタープライズソフトウェア勢」としてパッケージソフトウェアベンダーとSIerを一括りにしてきましたが、SIerが前記のとおり理想的な進化を遂げて、ユーザー企業にいま以上の付加価値を提供できるようになったのであれば、DX系SaaSとしては先進的SIerとの協力関係を構築するのが正解となるかもしれません。その際の倒すべき相手は、大手のソフトウェアベンダー（ERP）となります。
実際に、これまでパッケージソフトウェアを売ってきたSIerが、複数SaaSをインテグレーションしつつ販売するような活動をはじめているので、その端緒は見えつつあるのではないでしょうか。
iPaaSとERPの関係性については、投資先Anyflowの坂本CEOの記事「2020年はiPaaS元年になるかもしれない理由3つ」で言及されていますので、こちらもご参照ください。
⑤ PoCからの汎用化
５つ目は、時間軸が少し手前に動きます。レガシー化してしまった領域からSIer的な立ち位置でPoCを通じてプロダクト開発を行い、汎用的なプロダクトをもって「標準化×機能特化」の象限の橋頭堡を確保するという戦い方です。
ここでは、市場規模や再現性などの観点から何を汎用化するかの見極めが非常に重要でありつつも、汎用化につながるようなPoC案件を獲得できるかどうかは（タイミングや出会いが重要という意味において）アンコントローラブルな面もある点に注意が必要です。
このアプローチについては、「DXビジネスを成功に導く、“4ステップの営業戦略”とは？「社会インフラのDX」を進めるセンシンロボティクスに学ぶ」が非常に参考になりますので是非ご覧ください。
なお、「標準化×機能特化」を押さえた次の展開としては、上記①～④が想定されます。このケースにおいても、初期的にはSIと比較されるため、②の留意点は共通するものと思います。
さいごに
現時点での整理は以上となります。本稿の執筆にあたってはDX系SaaSの起業家、SI出身のエンジニア、VCの方々にヒアリングさせていただきました。ご協力ありがとうございました。
引き続きアップデートしていきたいと考えておりますので、起業家の方、VCの方、ぜひ壁打ちさせてください。
この記事が気に入ったらサポートをしてみませんか？