【3つの失敗事例】ローコード導入のデメリット｜成功するための教訓とは？

1つ目のデメリットは、ローコードプラットフォームの使い方を習得する必要があることです。

ローコード開発では、プログラミングをほとんど行わずに開発を進めるための基盤である「ローコードプラットフォーム」を活用することになります。

プラットフォーム上では、ドラッグ&ドロップのような簡単な操作でアプリケーションの大部分を構築できますが、細かい操作方法や用意されているテンプレート・機能について知らなければ使いこなすことはできません。

そのため、例えば、Microsoftが提供するローコードプラットフォーム「Power Apps」では、7,000ページを超える公式ドキュメントが用意されています。

もちろん、その全てを読み込まなければ使いこなせないということではありませんが、こうしたドキュメントを参考に、練習でアプリケーションを構築してみるなどの事前学習は欠かせません。

また、プログラミング無しで開発を行えるノーコードプラットフォームと比べてみても、使いこなせるようになるまでの学習コストは大きくなりやすいです。
非エンジニアによる開発を想定しているノーコードプラットフォームは、ローコードプラットフォームよりもシンプルな操作感である場合が多いからです。

以下の通り、初学者向けの講座の所要時間で比較してみても、このことが暗に示されています。

• ローコードの初学者向け講座…18時間
  ※参考：マナビDX「FileMaker オンライン学習 初級編 」
  
  
• ノーコードの初学者向け講座…7時間
  ※参考：マナビDX「【法人向け】ノーコード開発研修」

従来の手法（スクラッチ開発）であれば、そもそも実践的なプログラミングスキルを数年スパンで習得する必要があるため、それよりは開発ハードルが格段に下がりますが、学習コストがゼロとはいかないことは留意しておきましょう。

2つ目のデメリットは、従来の開発手法（スクラッチ開発）よりも開発の自由度が低いことです。

ローコード開発では、必要に応じてプログラミングによるアプリケーションのカスタマイズが可能なので、プログラミングを一切行わないノーコードに比べれば自由度が高いと言えます。

ただ、アプリケーションのベースはプラットフォーム上のテンプレートやパーツを組み合わせて構築するため、カスタマイズできる範囲には限界があります。外部ツールとの連携についても同様です。

例えば、

「開発する顧客管理アプリにチャット機能を追加して、顧客ごとに情報共有用のスレッドを用意したい」

と考えていても、プラットフォーム側で追加用のチャット機能が用意されていなければ、この要望は叶えられません。外部連携するにしても、連携できるチャットツールは限られてしまいます。

ローコードでは、プラットフォーム以上の機能実装が困難な部分も少なくないため、用意されたパーツ（機能）の組込みにとどまるなど、機能が制限されてしまうケースも珍しくありません。

一方で、全面的にプログラミングを行い、要件に合わせてオーダーメイドで開発を進められるスクラッチ開発（従来型の開発）なら、上記の要望には問題なく応えられます。
柔軟にプログラミングを行えるので、要件通りのチャット機能を構築するなり、使いたいチャットツールを連携させるなり、いくらでもやりようがあるのです。

このように、従来型の開発と比べると自由度が低いことから、ローコードは以下のような大規模で複雑な開発には不向きとされています。

• 全社で横断して利用するような大規模で複雑なシステム、アプリケーション
  …全社で横断するシステムには、部署ごとの業務に応じた細かい要件が求められるが、ローコードで可能な範囲のカスタマイズでは、その全てに応えられない可能性がある。
  
  
• 株価チャートなどの動的なコンテンツを要するシステム、アプリケーション
  …リアルタイムで移り変わるグラフを表示させるような複雑な機能を開発することは難しい。
  ※ただし、チャートを表示できる既存のツール等とうまく連携すれば実装できる可能性もある。
  
  
• UI／UXの細やかなデザインによる訴求が必要なアプリケーション、Webサイト
  …アプリケーションの大部分は、あらかじめ用意されたテンプレートやパーツを組み合わせて構築するため、細部まで調整することは難しい。

プラットフォームによってカスタマイズできる範囲は異なるため、一概に「ローコードではこうした開発が不可能」とは言えませんが、一般的に難しいとされているという点は把握しておくべきです。

3つ目のデメリットは、基本的なプログラミングスキルを持つ人材も必要という点です。

ローコード開発では、プログラミングはほとんどしなくても済みますが、「開発」であることには変わりがなく、目的に応じた設計力などはある程度必要です。

また、プラットフォームの仕様だけで叶えられない要件は、プログラミングで実装することになります。

こういったことから、ローコード開発では以下のような基本的なプログラミング（エンジニア）スキルを要する人材が少なからず必要なのです。

ローコード開発で必要なプログラミングスキル例

ソースコードを記述するスキル …機能をカスタマイズしたり、外部システムと連携させるためにプログラミングを行う必要がある 業務プロセスの設計・分析力 …業務のどの工程がシステム化の対象となるのか分析し、その工程をどのように効率化させるのか判断する必要がある システム設計力 …目的に応じて、どのような仕様や機能を実装させるべきか、その順番で処理を行うべきか的確に判断する必要がある 工数計算スキル …どれくらいの工数（人・時間）を要するのか計算できる必要がある データベースの知識 …データを参照するアプリケーションには、適切なデータベース設計・管理が必要となる

ローコード開発では、チームの中にこうしたスキルを持つ人材が居なくては、開発がうまく進行しなかったり、使えるレベルのアプリケーションが完成しなかったりという恐れがあるのです。

また、こうしたスキルを持つ人材が、開発チーム内にどれくらい必要なのか、開発手法ごとに比較してみると以下のようになります。

【5人編成の開発チームに必要なプログラミングスキル人材（一例）】

• ノーコード開発・・・0人
• ローコード開発・・・1人
• スクラッチ開発（従来型）・・・5人

この通り、一からプログラミングを行う従来型の開発手法とは違い、アプリの構築を担う全員にプログラミングスキルが必要なわけではありません。

ただ、プログラミングを必要としないノーコード開発なら、スキルを持つ人材がゼロでも開発を行えます。

このように、ノーコードの圧倒的な開発ハードルの低さと比べてしまうと、プログラミングスキルを持つ人材が少なからず必要な点は、デメリットと言わざるを得ません。

ローコード開発では、プラットフォームの使い方を習得する必要があります。

このデメリットは、せっかく導入したローコードプラットフォームが思うように使いこなせないという失敗につながります。

例えば、現場主導でアプリケーションの開発を行うためにローコードプラットフォームを導入した場合を例に、この失敗について詳しく見てみましょう。

ローコードプラットフォームを使いこなせない失敗例

A社では、現場主導のアプリケーション開発を実現させるため、ローコードプラットフォームの導入に踏み切りました。 自社にエンジニアが在籍していることもあり、プラットフォームは比較的柔軟にプログラミングによるカスタマイズが可能なものを選定。 ところが実際導入してみると、操作や機能が複雑で、各自でマニュアルを読んでもらうだけでは、非エンジニアの従業員には使いこなすことが難しそうです。 エンジニアの従業員もローコードプラットフォームを使った開発プロジェクトを含め、既存の案件で手一杯なため勉強会などの対応もできません。 結局、プラットフォームは基本的にエンジニアが活用するに留まり、現場主導の開発は叶いませんでした。

このような失敗は、完全にアプリユーザー（非エンジニア）による開発を前提としたノーコードプラットフォームでは起こりづらいはずです。

一方、ローコードプラットフォームには、エンジニアが開発に携わることが想定されているものも多いため、仕様や機能が非エンジニアからすると複雑に感じられることもあります。

そのようなプラットフォームを導入した場合、十分な時間を割いて使い方を習得しなければ、こうした失敗を招いてしまうのです。

ローコード開発では、従来の開発手法に比べると自由度が低くなります。

こうしたデメリットにより、アプリケーションに必要な機能を搭載できないという失敗が起こり得ます。

例えば、帳票の管理を行うためのアプリケーション開発を例に、この失敗について見ていきましょう。

必要な機能を搭載できない失敗例

B社では、ローコードにより、案件ごとに帳票を管理できるアプリケーション開発に乗り出しました。 採用したプラットフォームには、帳票管理アプリのテンプレートが用意されており、それをもとに機能などを組み替えながら開発を進めることが可能です。 ところが、開発を進める中で、元々社内で使っている経費精算システムとの連携ができないことが判明。 B社では案件に関わる全ての帳票を紐付けて、案件ごとの利益率の計算も効率化したいと考えていましたが、そのためには経費精算システムとの連携が必要でした。 結局この連携の代替案を検討する間、アプリ開発は一旦中断することとなりました。

このような失敗は、要件に合わせてオーダーメイドでプログラミングを行う従来の開発手法なら起こりづらいはずです。

しかし、カスタマイズの範囲がプラットフォームにある程度制限されてしまうローコード開発では、要件に応じたプラットフォームを慎重に選ばなければ、こうした失敗に直面しかねないのです。

ローコードで開発を進めるには、基本的なプログラミングスキルを持つ人材も必要です。

このデメリットが関わる失敗例として、非エンジニアのみで構成された開発チームにおいて、開発が滞るというケースがあります。

例えば、外部システムとの連携が必要な開発を例に、この失敗について見ていきましょう。

開発が滞る失敗例

C社では、ローコードプラットフォームを導入し、非エンジニアの従業員も業務効率化のためのアプリケーション開発を担えるようになっています。 シンプルなアプリケーションなら、ほとんどエンジニアが介在することなく開発可能なほどです。 現在も、売上予測アプリの開発を非エンジニアの開発チームで進めています。 ところが、この売上予測アプリには、既存の販管システムとの連携が必要であり、連携を実装するにはプログラミングを行わなければなりません。 売上予測アプリの開発チームには、エンジニアが起用されておらず、社内のエンジニアは他の案件で手一杯です。 結果的に、開発は一時中断せざるを得なくなってしまいました。

エンジニアが最初から開発を進める従来の開発手法や、プログラミング無しで開発を進めるノーコード開発では、このような形で開発が滞ることは無いはずです。

非エンジニアも開発を担えるけれども、プログラミングスキルを持つ人材も必要とするローコード開発だからこそ、こうした失敗に見舞われやすいのです。

失敗例も確認したことで、ローコードのデメリットがどのようなものか、詳しくおわかりいただけたかと思います。

ただ、実はローコードには、デメリットとまでは言えないまでも、注意が必要な点もあります。
それが以下の2点です。

ローコード開発の注意点

セキュリティレベルがプラットフォームに依存する ベンダーロックインの状態になる

こうした注意点についても、デメリットと同じく詳しく把握しておきましょう。
それぞれ、詳しく説明しますね。

ローコード開発では、プラットフォーム上にアプリケーションを構築するため、セキュリティレベルはプラットフォームに依存します。

プラットフォーム上にアプリケーションを構築するには、プラットフォーム提供会社の用意したインフラ（クラウドサーバーやネットワーク）を使わざるを得ないためです。

もちろん、プラットフォーム側もそのことを理解しており、きちんとセキュリティ対策を講じています。
第三者機関からの認証を受けているプラットフォームも少なくありません。

こういった点は、一般的なセキュリティレベルで開発が行えれば問題ない企業にとっては、むしろ「セキュリティ対策をプラットフォーム側で行ってもらえる」という利点と捉えることができます。

一方で、以下のようなセキュリティ要件の厳しい企業にとっては、プラットフォーム側のセキュリティでは不十分ということもあり得るはずです。

• これまでオンプレミスでシステムを運用・管理してきた
  （セキュリティレベルを自社でコントロールしてきた）
  
  
• サーバーの管理体制やプラットフォームを利用する際のネットワークまで管理したい

このような企業は、セキュリティレベルがプラットフォーム側に委ねられてしまうことに注意して、慎重にプラットフォームを選ばなければなりません。

ローコード開発では、ローコードプラットフォームを用いて開発を進めるため、ベンダーロックインは避けられません。

ベンダーロックインとは

プラットフォームやシステムへの依存度が高くなり、課題があってもそのツールを使い続けるしかない状態のこと。

とはいえ、提供会社のシェアが大きかったり、プラットフォームの品質が安定していれば、ベンダーロックインについて心配しすぎる必要はありません。

例えば、Windows OSを使っている企業では別のOSに切り替えるのは難しいかもしれませんが、多くの企業ではそのようなロックイン状態を問題視していないはずです。

しかし、ローコードプラットフォームは数多く存在するため、導入するプラットフォームによってはベンダーロックインが問題となってくるのです。
例えば、以下のようなプラットフォームでは、そのリスクが高くなってしまいます。

ベンダーロックインが問題になりやすいプラットフォーム

利用企業の少ないプラットフォーム →メジャーなプラットフォームに比べるとサービス終了や提供会社の廃業といった可能性が高く、開発したアプリケーションが使えなくなるリスクを孕んでいる。 バージョンアップの対応が遅い →新しい技術が発展し続ける中で、バージョンアップがそれに追い付いていないことは、開発するアプリケーションの品質にも影響する。

このようなプラットフォームへの依存度が高くなってしまうと、サービス終了に伴う混乱や、開発するアプリケーションの品質低下を避けられません。

そのため、プラットフォームを選ぶ際には、利用企業が多く、バージョンアップも頻繁に行われているものを選ぶよう気を付けておきましょう。

このケースにあてはまる場合、ローコード開発はおすすめできません。

「従来の開発手法よりは自由度が低い」というデメリットの影響を大きく受け、必要な機能や要件を満たすシステム・アプリケーションを開発できないからです。

大規模で多様な機能の搭載が必要なシステムや、自社独自の業務内容に合わせた仕様が必要なアプリケーションを開発したいのであれば、やや自由度の下がるローコード開発ではなく、従来の開発手法を選択しましょう。

一からプログラミングを行い、柔軟に機能や仕様を付与できる従来の開発手法なら、あなたの会社が求める要件に合わせたアプリケーションが開発できます。

このケースにあてはまる場合も、ローコード開発はおすすめできません。

以下の通り、ローコードのデメリットが、あなたの会社の要望を阻害するからです。

• デメリット：プラットフォームの使い方を習得する必要がある
  →簡単なプラットフォームを使いたいという要望とはミスマッチ
  
  
• デメリット：基本的なプログラミングスキルを持つ人材も必要
  →非エンジニアの従業員だけで開発を行うのは難しい

こうしたデメリットに阻害されず、要望通りに開発を進めたいなら、プログラミングを一切必要としないノーコード開発の方がおすすめです。

プログラミングを行わない、非エンジニアによる開発を想定したノーコード開発なら、プラットフォームの仕様もローコードプラットフォームよりシンプルな場合が多いです。

また、ノーコードはプログラミングが不要なので、非エンジニアの従業員だけでも十分開発を進めることができます。

このように、とにかく開発のハードルを下げることに重きを置くのであれば、ローコード開発は避けた方が無難です。

導入するローコードプラットフォームを選ぶ際には、プラットフォームの無料トライアルを活用するようにしましょう。

このことで、実際の操作画面や操作感を事前に確認できるので、よりマスターしやすいプラットフォームを選びやすくなります。
つまり、「プラットフォームの使い方を習得する必要がある」というデメリットを低減することができるのです。

そのために活用すべき無料トライアルを提供しているローコードプラットフォームには、例えば世界中の企業で導入・活用されているMicrosoft Power Appsをはじめ、以下のようなものがあります。

無料トライアルを提供するローコードプラットフォーム（一部抜粋）

Kintone さわってみよう！kintoneアプリ作成画面 | ドラッグ&ドロップでかんたん！ 楽々Framework3 体験版ダウンロード | ローコード開発基盤 楽々Framework3 Microsoft Power Apps Power Apps 無料試用版の概要

これらは有力なプラットフォームなので、ぜひ一度試してみることをおすすめします。

自社の開発に携わる従業員に、こうした無料トライアルでプラットフォームに触れてもらい、よりスムーズに使いこなせるプラットフォーム選定に役立ててください。

導入候補のローコードプラットフォームの機能や柔軟性はエンジニアの方と一緒に確認するようにしてください。

搭載されている機能や、カスタマイズの柔軟性は、プラットフォームによって異なります。

「従来の開発手法より自由度が低い」というデメリットの影響を最小限に抑え、自社の開発体制に合ったプラットフォームを選定するには、エンジニアの目線が欠かせません。

例えば以下のような点について、エンジニア視点で自社と合っているかどうかを検討するようにしましょう。

• 用意されているテンプレート・コンポーネント（アプリケーションのベースや部品）
• カスタマイズ可能なプログラミング言語の選択肢  
• スマホ対応の有無
• 外部システム連携の範囲
• セキュリティ対策

もし社内にエンジニアが在籍していない場合は、外部の開発支援会社に相談してみるのも一つの手です。

プラットフォームの導入直後は、エンジニアが開発を監修するようにしましょう。

ローコード開発には、プログラミングスキルを持つ人材も必要ですし、特にプラットフォーム導入直後は、非エンジニアの支援も兼ねてエンジニアサイドからの監修を行うべきです。

初動でしっかりエンジニアによる監修や支援が行われれば、非エンジニアもスムーズに開発に慣れることができ、将来的には単純なアプリケーションならエンジニア無しでも作成できるようになるはずです。

そのように、より柔軟な開発リソースの確保を実現させるためにも、プラットフォームを導入して間もないうちは、エンジニアの方にしっかり開発を支えてもらいましょう。

ローコードプラットフォームのセキュリティレベルについて判断するには、外部認証の有無をチェックしてみてください。

プラットフォーム側でセキュリティ対策を講じているとはいえ、その内容やレベルはプラットフォームにより異なります。

そこで、判断基準の一つとなるのが、第三者機関による認証です。
「◯◯（プラットフォーム名） セキュリティ」などで検索して、公式情報を確認し、プラットフォームがきちんとした認証を受けていれば、信頼性が高いと判断できます。

そのような判断基準となる外部認証としては、例えば以下のようなものがあります。

• ISO/IEC 27001（ISMS／情報セキュリティに関する国際規格の認証）
  
  
• ISO/IEC 27017（クラウドサービスセキュリティに関する国際規格の認証）
  
  
• ISMAP（政府のセキュリティ要件を満たすことの証明）
  
  
• DoD IL2（アメリカ国防総省のセキュリティ要件を満たすことの証明）

こうした認証の有無を確認し、プラットフォームのセキュリティレベルを確かめるようにしましょう。

導入するローコードプラットフォームに迷った場合は、シェアの大きなものを優先させましょう。

シェアの大きなプラットフォームを選んだ方が、ベンダーロックインの状態が問題になりづらいからです。

そもそもロックイン状態は、プラットフォームが使えなくなるリスクがあったり、プラットフォームの品質に課題がある場合はデメリットとなってしまいますが、そうでなければさほど大きな問題ではありません。

つまり、安定した企業経営や質の高いサービス運営が見込まれる、利用企業の多いプラットフォームを選べば、ベンダーロックインを必要以上に警戒する必要はないのです。

そのようなシェアの大きなローコードプラットフォームの代表例が、Microsoftの提供するPower Appsです。

Power Appsなら、ベンダーロックインを心配も少なく、、Microsoft製品との親和性が高い点も魅力です。
Office 365やDynamics 365といったツールとスムーズに連携できるため、Microsoft製品を多用する企業においては、特におすすめのローコードプラットフォームと言えます。

ここまでお読みになって、もしPowerAppsに関心がおありなら、ぜひ当社クエストまでご相談ください。

クエストの提供するMicrosoft365の導入・運用サービスでは、Power Appsによる業務アプリの内製化の支援も行っております。

「Microsoft製品を多用しているからPower Appsに興味があるけど本当にアプリの内製が叶うか不安…」
「導入するにしても、Power Appsについて不明点があった際の相談先が欲しい。」

など、Power Appsによるローコード開発に興味がありつつも不安を感じられているなら、クエストの伴走型のサポートがお役に立てるはずです。

ぜひお気軽にご相談ください。