Alibaba と Tencent の SaaS アクセラレータとローコードの戦いは、大混乱を引き起こす可能性があるでしょうか?

アリババとテンセントの戦争は、CエンドからBエンドへ、そしてBエンドからクラウドへと広がっています。名前や戦略も似ています。

今年初めの Alibaba Cloud Technology Summit で、Alibaba は SaaS アクセラレータ戦略を発表しました。これは、ISV と開発者が簡単なドラッグ アンド ドロップで SaaS アプリケーションを迅速に構築できるようにすることを目的としています。アリババはアプリケーションに一切手を付けないと約束し、テンセントもその後SaaSアクセラレータープログラムを立ち上げた。両社の目標は非常に明確で、企業からクラウドまでのラストマイルを開放することです。 SaaS アクセラレータは、クラウド ビジネスを企業に深く浸透させるための鍵となります。しかし、これら 2 つの巨人を前にして、ISV とソリューション プロバイダーはどのように選択すべきでしょうか?

[[269021]]

簡単に言えば、SaaS アクセラレータはローコード開発プラットフォームです。アリババとテンセントは、このような戦略を通じて、より多くの ISV が自社のクラウド上で自社の製品やアプリケーションを構築するよう誘致したいと考えています。もっと直接的に言えば、クラウド アプリケーションのエコシステムを改善し、より多くの企業が独自のクラウドを選択できるようにすることです。

しかし、ここで問題があります。企業が現在必要としているのは、単一ポイントのアプリケーションではなく、統合ソリューションです。新しいアプリケーション間の統合、および新しいアプリケーションと古いアプリケーション間の統合の傾向が顕著になってきています。誰がそれを解決するのでしょうか?

ISV ソフトウェア ベンダーに依存しますか?明らかにそれは機能しません。ソフトウェアベンダーは自社のビジネス範囲のみを対象としており、それ以上のことは行いません。さらに、ローコードには依然として多くの問題が残っています。アリババとテンセントが企業へのラストマイルを突破できるかどうかに関わらず、鍵となるのはローコード自体の問題であり、それは今後両社が緊急に解決しなければならない鍵でもある。

ローコード開発は新しい用語ではありません。その起源は、有名な調査コンサルティング組織である Forrester によって「ローコード開発プラットフォーム」という用語が作られた 2000 年頃にまで遡ります。その開発はさまざまな段階を経てきましたが、2000 年から 2015 年はローコード プラットフォーム開発の第一段階とみなすことができます。この段階では、ローコード プラットフォーム市場の発展は非常に遅く、大きな浮き沈みはなく、優れたパフォーマンスを発揮する企業もありませんでした。

2015年から2018年にかけて、ローコードプラットフォーム市場は急激に活性化しました。 2015年には、AWS、Google、Microsoft、Oracleなどの大手サプライヤーが市場に参入し始めました。 2018年、シーメンスはローコードアプリケーション開発のリーダーであるMendixを6億ユーロで買収すると発表し、迅速なアプリケーション開発のためのローコードプラットフォームであるOutSystemsは3億6000万米ドルの投資を受けました。その後、ローコード プラットフォーム市場が本格的に成長し始めました。

Forrester のレポートによると、ローコード開発プラットフォーム市場は 2015 年の 17 億ドルから 2020 年には 155 億ドルに成長し、5 年間でほぼ 10 倍に増加する見込みです。

Forresterが描いたこの分野の象限図では、Microsoft、OutSystems、Mendix、Kony、Salesforceが主導的な地位を占めており、ServiceNow、GeneXus、Progress Software、MatsSoft、WaveMaker、Thinkwiseなどの新興企業も追い上げの強い傾向を示しています。

海外市場では、この技術の開発が比較的成熟していることがわかります。もちろん、市場価値のある技術であれば国内企業が注力する方向となり、ローコード開発技術も例外ではありません。

現時点では、中国におけるこの技術分野の発展はレッドオーシャンの状態に達するには程遠いが、それは時間の問題かもしれない。そして、巨人の攻撃は間接的に何らかの情報を明らかにするのでしょうか?

ローコード開発のメリットについては、大手企業の宣伝以外にも、インターネット上のさまざまなコンテンツで見聞きしすぎているかもしれませんので、ここでは詳しくは触れません。

では、潜在的なリスクは何でしょうか?おそらく、このテクノロジーを導入したい、またはアクセラレータを通じて自社を強化したい企業は、次の外国人 CIO のアドバイスに耳を傾ける必要があるでしょう。

CIO のピーター・ウェイナー氏は、ビジネス ユーザーがプラットフォーム、成果、プロセスを詳しく調べると、ローコードで実装するのはそれほど簡単ではないことに気付くと述べています。このテクノロジーが企業の開発プロセスを簡素化するという宣伝にもかかわらず、さらに複雑化する可能性があります。

ピーター・ウェイナー氏は、これらのプログラミングの松葉杖や心を読むインターフェースの背後に潜むいくつかの暗い秘密が、ローコード開発の魅力的な約束を覆い隠している可能性があると考えています。

ベンダーロックイン

多くのテクノロジーと同様に、ローコード ツールで行われる作業量は、企業が持つ制御に直接比例します。

なぜ私はこう言うのでしょうか?作業の大部分をツールに委ねることで、企業のツールへの依存度が高まり、企業プロセスに対する制御力が高まります。

ローコード ツールの使用によって発生するロックインの問題を最小限に抑えることができる戦略をいくつか紹介します。企業は、より移植性の高いコードを記述し、ビジネス ロジックを分離し、それを接続コードでカプセル化して、ローカルのローコード API に接続できます。

このアプローチは実行可能ですが、企業がすべてを自社のサーバー上に置きたい場合、最終的には残りのコードを自社で作成する必要があることに注意する必要があります。

ロックダウンの解除により、新たなプログラミングの仕事が生まれました。企業は何を選択するのでしょうか?

価格変更の隠れた危険性

多くの販売戦略と同様に、クラウド プラットフォームは顧客を引き付けるために低価格を提示し、可能であれば価格を上げることがよくあります。彼らはなぜこんなことをするのでしょうか?その理由の一部は、前述のロックイン問題です。企業がプラットフォーム上にシステムを構築すると、価格をコントロールする力が得られます。

もちろん、長期契約を結ばない限り、来年や 5 年後の運営コストがいくらになるかを確実に知る方法はありません。したがって、企業のローコード作成をこれらのクラウドプロバイダーのプラットフォーム上で完了する必要がある場合、企業は協力を交渉する際にこれを考慮する必要があります。

考えられる価格設定シナリオの例としては、価格設定方式の変更、つまり通話頻度に基づく課金から帯域幅に基づく課金への切り替えが挙げられます。

規制上のリスクがある

ローコード プラットフォームでは記述するコードの量が減るため、ほとんどの企業は舞台裏で何が起こっているかにほとんど注意を払っていません。

おそらく、この背後にあるコードは公式かつ独自のものでしょう。おそらく、API 呼び出しの背後に何らかの秘密が隠されているのでしょう...

規制当局が関与する場合、これは特に厄介です。企業はこうした「舞台裏のこと」を知るすべがないため、何が起こったのかを規制当局に伝えるすべがなく、たとえ本当に自らを弁護したくても「何も言えない」のだ。

隠れた非効率性

フル機能の API、ライブラリ、スタックに制御を委ねるのは素晴らしいことですが、舞台裏のコードは多くの不測の事態に備える必要があるため、効率がはるかに低くなることがよくあります。

誰かの馬鹿がヌルポインタを渡したのでしょうか?すべての関数パラメータは正しい形式ですか? ...

ローコード ツール ベンダーは、愚か者が何をするか分からないため、自社製品を堅牢にする必要があります。こうした防弾技術は素晴らしいかもしれませんが、装甲戦車と同様に、通常ははるかに遅くなります。

機能が制限されている

多くの場合、企業はローコード開発プラットフォームのデモを得意としています。たとえば、セールス エンジニアは、フレームワークに組み込まれている createDoggyDatingSite 関数を呼び出すだけで、たった 1 行のコードで新しいかわいい犬の出会い系サイトを作成しました。

実際、ほとんどのローコード プラットフォームは比較的汎用的ですが、組み込み関数の機能がすぐに使い果たされてしまう可能性があります。顧客が誤って製品の詳細を構築する必要がある場合がありますが、ローコード企業はすべての詳細を予測することはできません。

これには、ソフトウェアが企業のニーズに柔軟に適応できることが求められます。企業が要求する柔軟性が高ければ高いほど、それを満たすために必要なコードも多くなりますが、コードが多いからといってローコードになるわけではありません。

一方的な致命的なバグの脅威

技術者がよく知っている例を見てみましょう。 Libssh にバグが発生すると、サーバー クラスター内のほぼすべての Unix または Linux マシンが危険にさらされます。

成功するローコード プラットフォームは、通常、この一方向性を念頭に置いて設計されています。これはソフトウェアが正常に動作している場合には良い設計ですが、上記の Libssh のバグと同様に、ネットワークに致命的な欠陥が見つかった場合、それに関連するすべてが崩壊してしまいます。

現時点では、この問題を回避する方法はありません。

同じ肌

シナリオは次のようになります。賢い自動車愛好家が、自動車部品メーカーから在庫品を購入し、それらを組み立てることで自動車を組み立てるのはそれほど難しくないことに気付きます。彼は車の曲線的なボディにほとんどのお金をかけましたが、フォルクスワーゲンのドアハンドル、ポルシェ911のシート、フォードのステアリングホイールなど、他のものはすべて一般的なものでした。

実際、ローコード プロジェクトは最終的に同じ効果を生み出します。開発者が同じ標準部品を使用しているため、これらのプロジェクトは最終的に非常に似たものになるでしょう。

コードが倉庫内の在庫管理などのタスクを実行するだけの場合、外観は重要ではありません。しかし、ソフトウェアが自社ブランドの一部である場合、ローコード ソフトウェアが競合他社のソフトウェアと非常に類似している可能性があることを覚悟しておく必要があります。

模倣者か革新者か？

多くの場合、自分にとって簡単に作成できるものは、他の人がそれをコピーするのも間違いなく簡単です。

ローコード プラットフォームが企業に提供する利便性は、単純なドラッグ アンド ドロップやビルディング ブロックなどを通じて、自社のアプリケーションに適したソフトウェア製品を構築できることです。したがって、このプラットフォームが排他性を避けることを望んでいることは明らかです。

ここで問題となるのは、ソフトウェアが競争上の優位性を持つ別のビジネスをサポートするのであれば、それで問題ないということです。したがって、ソフトウェアの作成がビジネス モデルである場合は、ある程度の競争に備えてください。同じ枠組みの中でいかに際立つかは、企業が検討しなければならない課題です。

どのようなテクノロジーにも長所と短所があることは否定できませんが、ローコード開発も例外ではありません。 AT の「ローコード」SaaS アクセラレータが「善意」からなのか「良いメリット」からなのかにかかわらず、アクセラレータに飛び乗る企業は「目を閉じて回転したりジャンプしたり」するだけではなく、足元の「落とし穴」にも注意する必要があります。

前述のローコード開発プラットフォームの隠れた危険性を最小限に抑える方法は、AT が企業向けのラストマイルを開拓し、より多くの ISV やソリューション プロバイダーを引き付ける前に検討しなければならない問題かもしれません。

クラウド内の火花は点火されたが、アリババとテンセントのどちらが先に草原に火をつけるのかはまだ分からない。