ローコード開発導入企業の課題からみる、「内製化」の前に自問すべき2つの問い：特集：「内製化」の誤解と、今すぐなすべきこととは？（2）

ローコード／ノーコード開発ツールによる「システム内製化」への関心が高まっている。取り組みを進めるに当たってユーザー企業が留意しておくべきことは何か。ノークリサーチ、シニアアナリストの岩上由高氏に聞いた。

[柴田克己，＠IT]

　ビジネスの変化に迅速に対応し、ニーズに適合するシステムを、ユーザー企業が自らの手で作り上げていく「内製化」の取り組みを支援する環境として「ローコード／ノーコード開発ツール」が注目を集めている。市場には「ローコード／ノーコード」をうたう製品やサービスが、オンプレミス、クラウドを問わず次々と投入されており、その特徴もさまざまだ。

　しかし、こうした「ユーザー企業が、業務のためのシステムを自ら作る」という動き自体は、昨今に始まったものではない。かつて、そうした取り組みは「EUC」（End User Computing）という名称で盛んに行われ、それを実現するためのツールも市場に多く投入されていた。

ノークリサーチの岩上由高氏

　「ローコード／ノーコード開発ツールは、EUCでユーザーが直面した課題を、全て解決できる“魔法のつえ”ではない。導入の仕方や使い方を間違えれば、EUCの弊害を再び生み出してしまう可能性が十分にある」

　そう警鐘を鳴らすのは、ノークリサーチでシニアアナリストを務める岩上由高氏だ。では、「ローコード／ノーコード開発ツール」による内製化の取り組みにおいて、かつての「EUC」での失敗を繰り返さないためにユーザー企業が心得ておかなければならないことは、何なのだろうか。

多様な「源流」が混ざり合うローコード／ノーコード開発ツール市場

　市場には多数の「ローコード／ノーコード」をうたう製品やサービスが存在している。その定義もさまざまだ。ノークリサーチでは「ローコード／ノーコード開発ツール」について、「プログラミングが不要（ノーコード）もしくは簡易なプログラミング（ローコード）によって業務をシステム化できる開発ツール」と、かなり幅広く定義している。

　その理由には「ローコード／ノーコード」をうたっているツールの「源流」が、極めて多様であることが挙げられるという。

　コンピュータの支援によって、ソフトウェア開発の生産性を高めるための取り組みは、コンピューティングの初期から継続的に行われてきた。歴史をさかのぼれば「CASE（Computer Aided Software Engineering）ツール」による設計支援やソースコード生成などが挙げられる。現在の「ローコード／ノーコード」ツールの中にも、そのコンセプトを発展させたものが複数存在している。

　1990年代に入ると、PCの普及やクライアント／サーバコンピューティングの隆盛に合わせて、用途をある程度絞った上で、アプリケーション開発の生産性をより高めるような仕組みが登場する。主にデータベースベンダーがフロントエンド開発のために用意した開発環境は「4GL開発ツール」などとも呼ばれ、SIベンダーによるシステム開発にも広く利用されていた。

　それとほぼ時期を同じくして、こうした開発ツールをさらに簡易化し、GUIと平易なスクリプティングで業務のためのアプリケーション開発を行える環境が生まれた。これが、いわゆる「EUCツール」と呼ばれるジャンルで、「Lotus Notes/Domino」「Microsoft Access/Excel VBA」（Excelマクロ）などが、その代表格となる。

　EUCは、企業が「ITによる業務の効率化」を促進するための取り組みとして、一時期盛んに行われていたが、その中で幾つかの課題も浮上していた。例えば、Lotus Notes/Dominoであれば、独自のアーキテクチャに由来するシステムのブラックボックス化やマイグレーションの難しさ。Microsoft Access/Excel VBAであれば、ファイル単位でアプリケーションとデータを管理するという構造に起因する、データのサイロ化や無秩序な分散といった問題だ。

　岩上氏は「ローコード／ノーコード開発ツールは、こうしたEUCツールが技術の進歩やクラウド化などを通じて使いやすく進化したものだと捉えている」とする。つまり、EUCで顕在化した課題は、ローコード／ノーコード開発ツールによる内製化でも同様に起こり得るというわけだ。

ツールの分類を知れば自社に適したものが見えてくる

　ノークリサーチでは、現在、市場にある「ローコード／ノーコード開発ツール」を、主にその「登場のいきさつ」によって、大きく以下の6種に分類している。

分類	主な特徴	具体的な製品例（一部）
A：超高速開発ツール	データ構図や画面レイアウトなどをツール上で設計／指定することで、プログラムを自動生成するもの	「GeneXus」ジェネクサス・ジャパン 「OutSystems」OutSystems 「Magic xpa（dbMagic）」マジックソフトウェア・ジャパン 「Web Performer」キヤノンITソリューションズ 「AppSQUARE」日立ソリューションズ東日本
B：カジュアルデータベース	Microsoft Accessのようにデータ構造を定義し、部品を組み合わせて操作／表示の画面を作成するもの	「File Maker」Apple Japan 「UnitBase」ジャストシステム 「Zoho Creator」ゾーホージャパン 「コンテキサー」アプストウェブ
C：PaaSとして提供されているもの	クラウド上に開発環境と実行環境が配備されており、月額／年額のサービスとして提供されているもの	「Lightning Platform」セールスフォース・ドットコム 「kintone」サイボウズ 「Microsoft Power Apps」日本マイクロソフト
D:データ連携を重視したもの（iPaaS）	複数のクラウドサービスを連携させることに重点を置いたもの	「Microsoft Power Automate」日本マイクロソフト 「Dell Boomi」デル 「IFTTT」IFTTT 「Zapier」Zapier 「Anyflow」Anyflow
E:グループウェアと関係が深いもの	グループウェアベンダーによって提供され、独自のアプリケーションを作成できる仕組みを備えたもの	「AppSuite」ネオジャパン 「SmartDB」ドリームアーツ 「POWER EGG Webデータベース」ディサークル 「サイボウズデヂエ」サイボウズ　※新規販売は既に終了
F:CRMと関係が深いもの	CRMの一環として導入されることが多く、独自のアプリケーションを作成できる仕組みを備えたもの	「SMILE V Custom AP Builder」OSK（大塚商会） 「SMILE V CRM Quick Creator」OSK（大塚商会） 「SPIRAL」パイプドビッツ

ローコード／ノーコード開発ツールの登場経緯に基づく分類（提供：ノークリサーチ）

　この6つの分類を、「新規システムの開発向けか、既存システムの移行や補完向けか」「オンプレミス環境向けか、クラウド環境向けか」の2軸上にプロットしたものが、次の図になる。

ノーコード/ローコード開発ツールの俯瞰（ふかん）図（提供：ノークリサーチ）

　この分類に準じると、自社にとって導入しやすく、要件に合う「ローコード／ノーコード開発ツール」がどのようなものか、イメージが見えてくる。

　Microsoft Access/Excel VBAなど、いわゆる「簡易データベースソフト」を源流とするのは「B：カジュアルデータベース」である。既にそうしたデータ資産が社内に多く存在しているのであれば、Bが有力な移行先として検討できるだろう。また、Bにはオンプレミス環境を前提とするツールが多く属するが、これがクラウド上でPaaS的に提供されるようになると「C」に分類される。マイグレーションを機に、クラウドでの新規開発も視野に入れるのであれば、Cもフォーカスに入ってくる。

　スケジューラーや掲示板といった「グループウェア」と密接に関連した開発環境は「E」、CRMを中心とした特定用途の業務アプリケーションのカスタマイズ環境として利用しやすいものが「F」だ。既に導入しているグループウェア、CRMのベンダーがこうしたツールを提供しているのであれば、それらを優先的に検討できる。

　CASEツールのコンセプトを進化させた「A：超高速開発ツール」については、アプリケーションの開発・実行に加え、Microsoft .NETやJavaといった汎用（はんよう）プラットフォーム向けのソースコードを生成できる機能、変更管理・リリース管理機能なども含まれることが多く、大規模なレガシーシステムのマイグレーション用途で採用されるケースも少なくない。

　「D：データ連携を重視したもの」は、複数のシステムやクラウドサービス間でのデータ連携にフォーカスしたツールであり、他のツールで作るアプリケーションと既存システムとの連携を行いたい場合や、RPA（Robotic Process Automation）の一部としても選択肢に入る。

　「ローコード／ノーコード開発ツールとRPAツールは、どちらも“コーディング不要（もしくは少量）”という意味で近しいツールだが、前者は『アプリケーションを作るもの』、後者は『既にあるアプリケーションの操作を自動化するもの』と、用途に明確な違いがある。Dに分類されるツールについては、RPAツールや、既存アプリケーションの連携を補完する目的での導入も想定される」（岩上氏）

「導入済み」の企業が実際に直面した課題とは

　では、これらのローコード／ノーコード開発ツールの活用において、ユーザー企業が直面する具体的な課題とは、どのようなものなのだろうか。ノークリサーチでは、ツールを「導入済み」の企業と、「導入予定」の企業のそれぞれに対し、「ローコード／ノーコード開発ツールの課題と感じていることは何か」というアンケート調査を行った。

ノーコード／ローコード開発ツールの課題（複数回答可）（出典：2020年版中堅・中小企業におけるRPAおよびノーコード／ローコード開発ツールの活用実態レポート）（提供：ノークリサーチ）

　調査は、中堅・中小規模企業を対象に行われたが、この結果については大規模企業にもおおむね当てはまるという。グラフ上で、青で示されているのが「導入済み」企業の回答比率、赤が「導入予定」企業の回答比率だ。

　この結果で注目したいのが、「導入済み」「導入予定」のいずれにおいても、3割超の企業が「課題」と感じている「複雑な処理はプログラムが必要になる」という項目だ。さらに、「部署ごとにアプリケーションが乱立する」つまり「アプリケーションのサイロ化」については「導入済み」企業の24.2％、「導入予定」の19.7％が「課題」と感じている。「導入予定」よりも「導入済み」の企業で、より多く「課題」と認識されている項目は「導入後に課題が顕在化した」状況を表していると考えられる。

　岩上氏は「この2項目の結果からは、ツール独自の環境による『ブラックボックス化』や、アプリケーションやデータの『サイロ化』といった、旧来のEUCで起こっていたのと同じ課題が、ローコード／ノーコード開発ツールでも起こっていることが分かる。つまり、EUCの推進時に必要とされていた、組織的、計画的に開発を行う体制やスキルは、ローコード／ノーコード開発ツールでの内製化においても、同様に重要といえる」と指摘する。

　また、「導入済み」「導入予定」双方の企業で、約25％から30％が感じている課題には「開発ツール固有のスキルが必要になる」「実現できる機能や性能に制限がある」がある。これらは「導入予定」より「導入済み」の企業の方が多く回答している項目だ。

　「『開発ツール固有のスキルが必要になる』という状況は、そのツールにロックインされるリスクが高くなるということ。また、『実現できる機能や性能に制限がある』と感じるのは、導入以前に、そのツールで何ができるのか、どの程度の規模の用途に適しているのかの見極めが不十分だった可能性を示唆している。ツールの検討に当たって、機能要件は細かくチェックしたが、性能要件の検討が不十分だったために期待した成果が得られないというケースも聞く。ローコード／ノーコード開発ツールにおいては、開発の容易性が前面にアピールされがちだが、導入する企業には、複数のツールの特長を理解して比較検討できるスキル、導入後に使いこなすためのスキルが、やはり必要になる」（岩上氏）

それでも「内製化」を進めたい企業が自問すべき2項目

　岩上氏は、この調査結果を踏まえ、これから「ローコード／ノーコード開発ツールで内製化を進めたい」と考えている企業には、以下の2つを自問してみることを勧めている。

問1：社内にシステム開発を計画的に進めるスキルおよび体制はあるか？

問2：複数のツールを比較、理解し、自社のニーズに合わせて使いこなすスキルはあるか？

　もし、この2つの問いに、両方とも「Yes」と答えられるのであれば、十分な計画のもとで内製化に取り組むことで、成果を得られる見込みがあるとする。一方、1つ以上が「No」であれば、ローコード／ノーコード開発ツールについては「システム開発を担うIT企業が活用するもの」と捉え、そうした企業をパートナーとしながら活用を検討した方が、現状では「堅実」だという。

　以上を十分に検討した上で、ローコード／ノーコード開発ツールによる「内製化」に取り組みたいと考えているユーザー企業に対し、岩上氏が勧めるのは「小さなシステム・新しいシステムの内製を積み重ねる」という進め方だ。

　「システムには、コアビジネスに深く影響するような『大きいシステム』と、現場単位の業務効率化やビジネスプロセスの改善といった領域に関わる『小さいシステム』がある。これから、内製化に取り組もうと考えている企業には、まず『小さいシステム』を新しく作るところから始めることを勧めたい。特に、近年増えているクラウドベースのローコード／ノーコード開発ツールには、環境を迅速に用意でき、トライ＆エラーを繰り返しながら自分たちが欲しいアプリケーションを作り上げていく経験を積むのに適しているものが多い。その際には、特定の環境に完全にロックインされてしまわないよう、業務仕様とデータについては自社でエクスポートできるようにしておくこと、アプリケーションやデータのサイロ化が起こらないよう開発の粒度や権限といったルールを管理することに留意すべきだろう」（岩上氏）