Contents
ノーコード/ローコードツールとは
C/C++、Java、Pythonなどのプログラミング言語は、利用するまでにプログラミングの基礎やITシステムのしくみを習得する必要がある。一方、ノーコード/ローコードツールは文字通りコードを全く書かない、もしくは少ししか書かなくてもやりたいことが実装できるということで、プログラマーだけではなく現場部門で業務に携わっている従業員や、IT部門でプログラミングはできないけれどITシステムをカスタマイズしたい従業員にも使えるのが特徴だ。
ガートナーのマジッククアドラント (MQ)に出ているツールで日本でなじみのあるツールというと、Microsoft PowerApps、Salesforce Lightning Platform、OutSytems、Pega、Kintone、AgilePoint、Zoho、ServiceNowなどが挙げられる。
ノーコード/ローコードツールが出てきた背景
いまノーコード/ローコードツールが注目されている背景としては、大きく2つの事が背景にあると思われる。
ひとつはデジタルトランスフォーメーション (DX) を推進する機運が企業の間で高まっていることだ。DXはデジタルの力を駆使してビジネスモデルを変革することが求められ、現場で業務を理解している従業員の参加が不可欠だ。
もうひとつはクラウドの普及が挙げられる。クラウドコンピューティングが登場してから約10年、様々なアプリケーションがクラウドで提供され、顧客企業でも普通に採用される環境が整ってきている。クラウドコンピューティングでもアプリケーション機能のみを提供するSaaSの形態も一般的になってきたが、SaaSはプログラミングでカスタマイズをすることができない。そのため、SaaSアプリケーションをライトにカスタマイズする手段としてノーコード/ローコードツールが使われる。最近新しく登場しているツールはクラウドのカスタマイズツールであることがほとんどである。
ノーコード/ローコードツールを使うメリット
これらのツールを使うメリットは主に2つある。ひとつは先ほど出てきたように、プログラミングができない現場やIT部門の従業員が扱うことができ、これによりユーザーが広がることだ。「市民開発者 (Citizen Developer)」という言葉も流行っているが、プロの開発者でない市民開発者もアプリケーションのカスタマイズを行うことができるようになる。これにより現場で業務効率化を推進できるようになり、いわゆる「ITの民主化」が進む。
もうひとつは、プログラミングができる開発者にとっても「より短期間で開発」することができるというメリットがある。プログラミング言語での開発は自由度が高い分、一般的に開発とテストにより多くの時間がかかる。ただし技術力のある開発者/ITベンダーには諸刃の剣であり、それはつまるところかける人月が減るということになり、得られる収益が少なくなる可能性があることを意味する。しかし、最近は競争力をつけるためにノーコード/ローコードを積極的に利用するベンダーも現れ始め、状況は変わりつつある。
ノーコードとローコードの違いは？
ところで、ノーコードツールとローコードツールの違いはあるのだろうか？文字通りにとるとノーコードは「まったくコードを書かない」、ローコードは「コードを少ししか書かない」ツールということになる。
しかし、結局のところ開発ツールで想定している一般的な使い方の範囲ではコードを書かなくても開発ができるが、それを超えたところ、もしくは開発者が別途高度な部品を作るところではコードが必要になる、ということは変わらなく、両者の違いはほとんどないと考えていいだろう。
ガートナーでも両方の言葉を使ってはいるが、マジッククアドラント (MQ) などの市場の定義には一貫して「ローコード」を使っている。ガートナーはローコード市場を「LCAP (Low Code Application Platform: ローコードアプリケーションプラットフォーム)」と定義している。
ノーコード/ローコードには決まった形式がない
また、プログラミング言語 (身近なのは高級言語)は、C/C++、Pythonなど文法や記載事項は多少違うものの、ひとつの言語を覚えると他の言語でも作法は似ており、比較的簡単に習得できる。人間の言語で言えば英語とフランス語の違いのようなものである。また、常にソースファイルがテキスト形式で管理されるのも特徴だ。
一方、ノーコード/ローコードは「コードをほとんど書かない」という共通点以外は決まった形式が存在しない。マウスによるドラッグ＆ドロップでフローチャートや積み木を並べてプロシージャを定義していく形式、マウスによるドラッグ＆ドロップでユーザーインターフェイスを作っていく形式、マウスによるドラッグ＆ドロップでフィールド間のリレーションを定義する形式など、マウス操作を使うところは共通点であることが多いといえる。また、専門的にはモデル駆動型アーキテクチャを取り入れることで細かいIT技術の用語や機能をユーザーが意識しなくてもよいようになっている。しかし他にもいろいろな形式が存在するため、ノーコード/ローコードツールといっても使い勝手が一様なわけではないのは注意が必要な点である。
ノーコード/ローコードは新しい概念ではない
技術的にはノーコード/ローコードというのは新しいものではなく、昔からあるものだ。近年のブームはDXの推進のための現場部門の巻き込みの必要性とクラウドコンピューティングの普及によるものであることは前に述べた。一方、パソコンやPCサーバが一般的に仕事環境にも普及して、グラフィカル・ユーザー・インターフェイス (GUI) によるパソコンの操作が一般的になってきた1990年代後半から2000年代前半にかけて、開発ツールや業務アプリケーションでノーコード/ローコードツールが登場して話題となった。
当時からある言葉としてRAD (Rapid Application Development: 高速アプリケーション開発)というものがある。開発ツールにおいてGUIを定義するにはテキスト形式のプログラミング言語で記載するのが普通であったが、Microsoft Visual BasicやDelphといったRADツールで画面をビジュアルに見ながらUI要素をドラッグ＆ドロップでくみ上げていき、必要なコードを自動生成するスタイルの開発ができるようになった。(Visual BasicやVisual StudioのVisualはこの時から使われるようになった)
また、Visual Basicが搭載されたExcelやAccess等のMicrosoft Office製品や、類似カテゴリの製品であるLotus Notes/Domino、FileMaker、SharePointなどもノーコード/ローコード製品に分類されるものとなる。(調査会社が発表する市場データには必ずしも登場しないが) ただし、これらは当時の主流であったデスクトップ製品やクライアント/サーバ型の製品である。
日本で「超高速開発ツール」と呼ばれているツールもノーコード/ローコードと同じものである。
ノーコード/ローコード製品を使う市民開発者にあたる言葉も、当時はEUC (End User Computing: エンドユーザーコンピューティング)という言葉で表現されていた。
ノーコード/ローコードとRPAの違いは？
このようにノーコード/ローコードツールというのは実は幅広い概念を含むものであることがご理解いただけたと思うが、RPAとの違いはどうであろうか、また本当に違うのであろうか？RPAとノーコード/ローコードは定義の仕方や範囲が異なるので、横並びに並ぶ概念ではない。
RPAの定義は突き詰めると「ロボットが人間の代わりに画面操作をしてくれる」のが特徴である。これは「画面操作」と「(ロボットという)簡単なインターフェイス」の2つの要素に分解できる。そしてロボットに指示を出すやり方は「画面操作の記録」か「フローチャートの組み上げ」であり、これらのやり方はノーコード/ローコードの概念と一致する。つまりRPAとは「ノーコード/ローコード開発で画面操作を行う手法」と言い換えることもできるだろう。
調査会社による市場の定義で言うと、RPAは市場が別に定義されており、ノーコード/ローコード開発市場に分類されることはないのだが、これはあくまでも便宜上の分類 (ユーザーが製品導入の際に比較検討をすると思われる製品群を調査会社がひとまとめにしたもの)であり、ノーコード/ローコードとRPAが全く異質のものであるということではない。
ノーコード/ローコードツールを使う際の注意点は？
プロの開発者ではない市民開発者が使うツールとして、ノーコード/ローコード開発ツールは威力を発揮すると考えられているが、これを推進していくうえで注意点もいくつか存在する。主なものは以下の通りだ。
- ITのしくみやプログラミング知識がない人が構築したロジックは通常の常識では考えられないエラーや欠陥を含んでいることがあり、有識者によるレビューが必須となる場合がある。誤動作やパフォーマンス低下の原因となることがある。
- 数十ステップにもわたるロジックを実行しようとすると、見た目がかえって複雑になり一覧性も低下し、メンテナンス性、管理性、コスト削減効果、スピードが悪くなる。
- 現場による開発をガバナンスなく利用させると、シャドーITにより誰も中身を知らない、管理していないロジックが増えてしまう。
このように、ノーコード/ローコード開発ツールはアプリケーション間連携、アプリと人の連携をやりやすくするための「ラストワンマイル」をつなぐ手段として、適度のガバナンスをITでかけながら利用すべきであり、うまく活用することで全体としての生産性を大きく向上させる可能性を秘めている。