複雑なシステムを効率的に組み合わせるマルチローコード戦略とは?

エンジニアでなくても、直感的に操作できるGUIと設定でアプリケーションを構築できるノーコード。最小限のハンドコーディングで、迅速なアプリケーション開発を可能にするローコード。どちらも少人数の人材や非エンジニアでも扱えるので、高速な開発速度や人件費の最適化、エンジニア教育の面でも高い価値が認められ、毎年利用が拡大しています。
近年ではさらに、複数のプラットフォームを組み合わせて使う、マルチローコード・ノーコードが注目されています。今回は、これについて紐解いてみましょう。
成長が止まらないローコード・ノーコード市場
システム開発の手法として、ローコード・ノーコード開発プラットフォームが引き続き熱く注目されています。プロジェクトやクライアント企業によっては、ローコード・ノーコードの利用が仕様で決まっていたり、各プラットフォームで認定資格試験が実施されるほど、スタンダードなシステム開発手法となっています。
市場の隆盛に伴ってサービスは百花繚乱、まさにカオスな様相を呈しています。つまり、このように多数存在しているプラットフォーム同士を、組み合わせて使うニーズが出てきているのです。
出典:ノーコード&AIカオスマップ更新【2024年11月版】一般社団法人NoCoders Japan協会
https://no-coders-japan.org/nocode-ai-industry-landscape-map
Gartnerの予測では、ローコード・ノーコード市場は年平均成長率20%を超え、2025年までに世界で290億ドル(約4兆4,700億円)規模に達すると予測されています。
▼Forecast Analysis: Low-Code Development Technologies
https://www.gartner.com/en/documents/3995846
しかし、この数字の背景にはエンジニア不足があり、伸び代はさらにあったと考えられています。さらに、生成AIが爆発的に普及して、ローコード・ノーコード開発と組み合わせて使われるようになった2023年以降は、より普及が進んでいると見られています。
IDC Japanの発表によれば、生成AIを含むローコード・ノーコードの国内市場全体は、2023年時点で1,225億円でした。2023~2028年の年間平均成長率も17.1%とし、2028年には2,701億円に拡大すると予測しています。
大企業を中心に普及しているプラットフォームとしては、柔軟性や拡張性にも優れ、既存システムとの連携やセキュリティーの堅牢さが評価されているサービスが人気です。OutSystemsやMendixなど、包括的で高速なアプリケーション開発環境として導入されています。日本では、データベース主導のアプリケーション開発を提供するkintoneが存在感を示しています。SalesforceやCreatioは、CRM(顧客関係管理)のビジネスプロセスやワークフロー管理に威力を発揮します。データ統合と管理に特化したMarkLogicや、ワークフローの自動化と統合を重視するWorkatoもあります。
このように、異なる部門のニーズに最適化された製品を組み合わせることは、極めて妥当な選択です。機能や特徴が被る製品を組み合わせるメリットは限定的ですが、時代の激しい変化に対応するには、異なる目的ごとに最適化された製品を賢く組み合わせる、柔軟な連携やスケーラビリティーが重要です。
ローコード・ノーコードを複数使うのは当前
そもそも、複数のITプラットフォームを併用することは、特別なことではありません。ベスト・オブ・ブリードやマルチベンダーと呼ばれる、複数のプラットフォームやベンダーの製品を組み合わせて使うことは一般的です。
多くの人が仕事で、複数のSaaSやクラウドサービス、パッケージ製品などを使っている現状を踏まえれば、すぐにイメージできるでしょう。例えば、開発や運用、営業、人事、経理、マーケティング、研究など、部門ごとの専用ツールが導入されているはずです。また、プロジェクトによって、取引先が指定するサービスを連携することも当たり前。オンプレミスのシステムとパブリッククラウド、Excelの手作業を組み合わせている仕事も珍しくありません。
今後それぞれが、ローコード・ノーコードを取り入れたり置き換えられていくことで、ユーザーが意識しているかどうかに関係なく、マルチプラットフォーム環境を使っていくことになります。
マルチプラットフォーム化の見極め
理想としては、自社のビジネスに最適化された、単一のサービスを使うことかもしれません。しかし、それは限りなくスクラッチ開発に近づき、膨大な開発期間とコストが掛かります。かといって、すべてのニーズを満たせる、デファクトスタンダードとなるようなキラーサービスが出現することもあり得ません。
従来は、用途が特化したシステムの場合、スクラッチでゼロから開発するケースもありました。自社のニーズを満たし、セキュリティー上も安全というメリットがある反面、時間とコスト、手間が掛かります。代わりに、市販製品を取り入れるCOTS(Commercial Off-The-Shelf:商用オフザシェルフ)が広く普及しています。もちろん、そこにローコード・ノーコード製品も使われています。
自社に最適なプラットフォームが複数か、単独かは、以下のようなさまざまな要因に左右されます。
- 組織の規模と複雑さ
- システムやビジネスニーズの多様性、変化
- 社内ITの能力、人材育成の状況
- DXの進捗、長期的な戦略目標
- 予算と時間の制約
大企業や、多様なシステム要件が求められる組織の場合は、すでにマルチプラットフォームになっている可能性が高いはずです。ユーザーがそれを意識できているかに関係なく、現場のニーズに柔軟に応えられる、目的に特化したツールが活用されているでしょう。
一方、小規模な組織や、システムに対するニーズが比較的均一な組織の場合は、単独のプラットフォームからスタートするのが妥当です。シンプルで費用対効果が高く、管理も簡単です。
いずれの場合も、複雑でも多機能 vs シンプルで制約ありといった比較ではなく、組織の現在と将来のニーズを慎重に評価し、一貫性や柔軟性などのトレードオフで、バランスを取りながら活用すべきです。
この辺りは、次の記事で詳しく見てみましょう。
12月に入り、各地から冬景色が伝えられる時期。今年の冬は2023年の暖冬から一転して、厳しい寒さになると予報されています。
天気予報と雪雲レーダーを見ながら、まとめて対処するのは雪害対策として必須です。人口減が進む自治体にとっては大きな財政負担となり、毎日朝の通勤・通学前の雪かきも市民レベルで重労働になっています。ただし、作業を細分化すると処理や管理が煩雑になってしまいます。
システムも、専用プラットフォームを限定してワンストップでまとめた方が、開発や管理、教育などの面で圧倒的に楽なはず。なぜ、わざわざ複数のローコード・ノーコード開発プラットフォームを使って、複雑化させるんでしょうか?また、複数のプラットフォームを、増やす・入れ替える・統合するのをどこで判断すべきでしょうか?プラットフォームごとにスペシャリストが必要になれば、ノウハウの分断や属人化するのでは?
細かい興味や疑問は尽きないので、次回、もう少し深掘りしてみましょう。