1. 既存アプリケーションの中で最も複雑な機能（変更不可の機能）を、検討対象のローコード／ノーコード開発ツールが実現可能かどうか
2. 既存アプリケーションの画面（UI）のうち、UIを変更することが許容されず、最も複雑なUIを選定し、そのUIを検討対象のローコード／ノーコード開発ツールで実現可能かどうか
3. 大量データ処理や高いレスポンスが必須な場合、そのような処理を検討対象のローコード／ノーコード開発ツールで実現可能かどうか

ノー／ローコードツールの導入効果を「低く」評価したユーザーの共通点は？

　キーマンズネットが実施した読者調査「ノーコード／ローコード開発ツールの利用状況に関する調査（2024年）」によると、ローコード／ノーコード開発ツールの導入効果を「期待よりも低い」としたユーザーの多くには次の2つの共通点があった。

• 主な開発者がIT部門に所属している
• 主な開発者に一定のコーディングスキルがある

　ノーコード開発ツール「kintone」を提供するサイボウズは、スキルのあるユーザーによる評価が期待値を下回る背景について、「開発経験のある人には、ローコード／ノーコード開発ツールが物足りなく感じられて、期待値が高いほど『この程度しかできないのか』と思われる可能性があります」と推測する。「ローコードツールはノーコードツールに比べて拡張性が高く多少のカスタムも可能ですが、やはり制限は存在することに注意する必要があります」（サイボウズ）

　こうした特性を理解した上で、事業部門の課題を解決するアプリケーション（アプリ）を開発しようとする場合、「誰」が「何を使って」開発するのがよいのだろうか。

　「作ろうとしているアプリがノーコードでも開発可能なのであれば、開発作業は事業部門に任せてIT部門は支援に回る企業が主流になってきています。ローコードで開発することによる拡張性を生かしたい場合は、プログラミング経験のあるIT部門の担当者が開発を担当して展開するというパターンが多いですね」（サイボウズ）。ただし、事業部門で利用するアプリの開発をIT部門が担当する場合は、事業部門の業務内容をIT部門がしっかりと把握しているかどうかにアプリの完成度が左右されることに注意が必要だ。

　ITRの甲元氏は事業部門スタッフによる市民開発を推奨する。「特にノーコードツールは『Microsoft Excel』の延長線上のように使えるので、プログラミング言語やフレームワークを使えない人にとって便利です。クラウドサービスであればサーバの立ち上げも不要で、必要になったタイミングで迅速に開発できます」

「コスト削減」を目的にすべきではない　これだけの理由

　キーマンズネットの調査では、ローコード／ノーコード開発ツールの導入で得られるメリットとして「開発スピードの向上」（51.3%）、「コスト削減」（43.9%）に多くの票が集まった。企業のIT投資における費用対効果への意識が高まる中で「コスト削減」が製品やサービスの導入メリットとして期待されることが増えているが、ローコード／ノーコード開発ツールの導入目的としては適当なのだろうか。

　サイボウズは、「コスト削減を第一の目的として導入すると、うまくいかないケースは多いと思います」と話す。「SIerに発注していた開発費用や保守費用が減り、結果的にコスト削減につながることもありますが、あくまでローコード／ノーコード開発ツールによって事業部門主体の課題解決を軸として導入検討するのが良いと思います。そうした企業には自分たちで業務改善を進めるという社内風土が醸成され、最終的にはそれがDX（デジタルトランスフォーメーション）の実現につながります」（サイボウズ）

　同社は、ローコード／ノーコード開発ツールの導入に当たってまず重要なのは、自社が抱える課題の深掘りだと指摘する。「現在使っているツールにはどのような課題があるのか。自分達でアプリを開発することで、そうした課題をどう解決するのかといった全体像を整理することが重要です」（サイボウズ）

　サイボウズがローコード／ノーコード開発ツールでの開発に適しているアプリとして挙げる条件を整理すると次のようになる。

• Excel以上、 バーティカルSaaS以下
• 専門性や作業の複雑性で言うと低～中レベル
• 情報を大人数で共有する必要がある、あるいは承認プロセスが必要

　「Excelは汎用（はんよう）性の高いソフトウェアですが、さまざまな課題が出てくるケースもあります。Excelからの移行を考える際に、対象となる業務が専門性の高いもので、例えば毎年のように法令への対応が必要になるなどの場合はバーティカルSaaSが有力な選択肢になります。一方、専門性がそれほど高くない作業で、自社の作業にうまくハマるSaaSやアプリが見つからない場合、かつ幅広い課題が存在している場合はローコード／ノーコード開発ツールでの作成が向いていると思います。結果として費用対効果も高くなる傾向にあります」（サイボウズ）

　前編で説明したように、ローコードツールがプログラミングの知識がある程度必要な一方で、ノーコードツールよりもカスタム性や拡張性が高いという特徴があるが、サイボウズによると専門性や複雑性が高いアプリに関しては、ローコードツールでも難しいようだ。

　「ローコードツールが持つカスタム性や拡張性は、簡単に言うと『“横”の選択肢』が増えるイメージで、『“縦”の選択肢』が極端に増えるわけではありません。専門性が高いアプリはバーティカルSaaSやスクラッチ開発が適しているケースが多いと言えます」

　甲元氏も「これまでスクラッチ開発してきたシステムやアプリを内製化することでコスト削減を実現しようという考え方は避けるべきです」と話す。

ローコード／ノーコード開発ツールでERPをリプレイスできる？

　甲元氏は「ローコード／ノーコード開発ツールでERPをリプレイスできますか」という相談を顧客企業から受けることがあるという。「不可能ではないが、かなり厳しい道のりになるとお伝えしています。まず、内製化すべきものとそうではないものがあり、内製化に向いているものの中でもローコード／ノーコード開発ツールでの開発に向いているものと向いていないものがあると考えています」（甲元氏）

　甲元氏の語った内製化に向いているものと向いていないもの、ローコード／ノーコード開発ツールでの開発に向いているもの、向いていないものを整理すると、次のようになる。

内製化に向いているかどうか

• 内製化に向いていないもの：　パッケージ製品やSaaSを利用すべきもの。業務プロセスをITシステムに合わせるべきもの。業界や業種関係なく、汎用的に実施される業務（バックオフィス業務、自社ビジネスの強みとは関わりのないもの）
• 内製化、あるいは外部ベンダーなどに開発を依頼してスクラッチ開発すべきもの：　自社ビジネスの強みに密接に関わるところ。また、その強みを最大限に生かすために現状の業務プロセスの変更が許されないもの。サプライチェーンなど外部企業や取引先の事情で業務プロセスが変更できないもの

ローコード／ノーコード開発ツールでの開発に向いているかどうか

• ローコード／ノーコード開発ツールでの開発に向いているもの：　自社内で利用する業務アプリ。現場で利用するためにクイックに開発したい業務アプリ。特に現場の業務プロセスが変化しやすいケースは好適。変更後の業務プロセスが目的に合っているかどうかをチェックする機会にもなる
• ローコード／ノーコード開発ツールでの開発には不向きなもの：　外部向けサービス、スマートフォン向けのアプリケーション。ローコード／ノーコード開発ツールは自由度が低い。最近はUIが洗練されているアプリが多いが、直感的に利用しやすいUIやデザインが意図した通りに作成できないこともある。また、大量のデータを取り扱う必要がある、データベースの複数テーブルをジョインする必要がある、複雑な分析を実施する必要があるアプリもローコード／ノーコード開発による開発には不向きだ

「脱Excel」のためにどう使う？　注意すべきポイントとは

　Excelのような表計算ソフトは汎用性が高いが、カスタム関数や複雑な数式、マクロが多用されると作成者以外による修正や更新が困難になる。作成者の異動や退職などに伴って、こうした属人性の高いExcelシートは継続利用が難しくなり、また一から作成する作業が発生しがちだ。それ以外にも表計算ソフトは、複数のファイルに情報が散在しやすく、部署ごとにフォーマットがバラバラで集計できないといった課題が発生することもある。

　「情報共有やデータ分析などのためにも、誰でも使えるスプレッドシートであることが重要になります」（甲元氏）

　こうした課題を解決する選択肢の一つが「脱Excel」だ。ローコード／ノーコード開発ツールを導入する目的として「脱Excel」を挙げる企業も多い。

　ローコード／ノーコード開発ツールではスプレッドシートのように利用できるインターフェースを提供されているツールもある。クラウドサービスであれば、常に最新の情報を共有できるのもメリットだ。しかし、「Excelと同じように使える」ことを期待すると、「脱Excel」がうまくいかないケースがあるので注意が必要だ。

　「脱Excel」を検討する際に注意すべきポイントは何か。kintoneを例にサイボウズはこう語る。

　「複雑なトランザクション処理や表の連結はExcelではあまり実施されていないので、ノーコードでもほぼリプレースできると思います。ただし、マクロや複雑な計算式はkintoneにそのまま移行できません。また、Excelと全く同じ操作性や ExcelのUIをkintoneで実現するにはプラグインや連携サービスが必要です。kintoneの操作性やUIがExcelとは異なることが自社においてどう影響するのかを考え、ある程度Excelに寄せるのか、操作性やUIの変更について説明会などを通じて利用者に理解してもらうかを見極める必要があります」

　また、「何のためにExcelから移行するのか」といった目的をユーザーとなる従業員全員が共有することが欠かせないと同社は強調する。

　サイボウズがユーザー企業の代表的な利用例として挙げるのが、「顧客管理」「案件管理」「日報」だ。データが分散している「野良Excel」シートを統合する重要性や、リアルタイムで情報を共有する必要性が事業部門の従業員にも分かりやすい項目と言えるだろう。

kintoneの「顧客管理」アプリの操作イメージ（出典：サイボウズの提供資料）

　kintone移行の重要なメリットとしてサイボウズが挙げるのが、データの整備だ。「 Excelのようなスプレッドシートでは、入力形式の自由度が高いため、項目の名称や氏名、日付などがさまざまな形式で入力されがちです。それに対してkintoneでは項目を定義し、入力ルールを設定できるため、データの一貫性を確保しやすい傾向にあります」

　データ分析をはじめとするデータ活用に取り組みたいと考える企業は多いが、社内データが利用できる状況にないことが足枷（かせ）となるケースも多い。開発プラットフォームが提供する機能を利用することで整備された形でデータを統合、活用できるというメリットも「脱Excel」に取り組む理由の一つとなりそうだ。

　なお、Excelではなくデータベースからの移行を考えている際は、複雑なトランザクション管理や大量のデータ処理といった機能を多くのローコード／ノーコード開発ツールが提供していないことに注意する必要がある。

「結局誰も使っていない」も「野良アプリの山」も避けたい　運用上の注意ポイント

　せっかく導入しても、IT部門の想定と異なり事業部門の従業員に使われなかったり、管理者が把握していない「野良アプリ」が発生したりといった問題が起こる可能性がある。

　ここまで見てきたように、事業部門が自身の課題解決のためにローコード／ノーコード開発ツールを利用する方法を想定する企業も多い。事業部門で使われなければ導入目的が達せられないケースでは、社内浸透策やガバナンス対策の実施はどちらも必須事項になるだろう。

　サイボウズは、利用拡大を推進する体制づくりが重要だと話す。「全社的に広めるのか、一つの部署だけで利用したいのかによってその人数は異なりますが、社内コミュニティーの形成など、開発を担当する従業員を支援する仕組みが必要です。そうした体制をしっかりと構築できる企業では利用が拡大します。それによって内製化の効果がさらに実感できて、内製化がますます進むという好循環が生まれます」

　これまで内製化に取り組んでこなかった企業は、開発経験のない人を支援するノウハウを持たないことが多い。「これから内製化に取り組む企業では人材育成も含めて、利用拡大に向けてプロと一緒に取り組む伴走型支援サービスを利用することも選択肢の一つになります」（サイボウズ）

　利用が軌道に乗った段階でIT部門が気になるのが、管理の行き届かない「野良アプリ」の発生だ。セキュリティリスクや社内の情報取り扱いルールからの逸脱の可能性など、ガバナンス不全で引き起こされるリスクは対策が遅れるほど増大し、把握や対応が難しくなる傾向にある。

　「いわゆる『マクロ職人』が作り込んだExcelシートをめぐる問題や、エンドユーザーコンピューティングで個々に作られたアプリなど、ガバナンスが行き届かないことで発生する課題に頭を抱えるIT部門は多い印象があります。ガバナンス問題への対策は、ツール導入時に考えておくことが重要です」（サイボウズ）

　具体的にはツール導入時にガバナンス方針を決定し、運用に入る前の段階でルールを形成し、利用拡大時に改善することをユーザーに推奨しているという。「運用の初期段階である展開フェーズ、運用がある程度進んだ利用領域拡大フェーズでは考慮すべきポイントが異なります。それぞれの段階、またそれぞれのアプリに合わせてリスクを検討し、ルールを改善する必要があります。締める部分と緩める部分を柔軟に調整して、現場の自律性を損なわずに利用範囲を拡大していくことが大切です」（サイボウズ）

　甲元氏もガバナンスも重要だが、ガバナンスを重視するあまりに開発担当者の自律性を損なわないことに注意する必要があると話す。「全てを管理しようとするIT部門の担当者もいますが、特にどのツールを導入するかといった点などはある程度現場に任せた方がいいと私は考えています」

　全社で統一して管理した方が良いものはIT部門がルールを定めて管理し、製品選びや運用に関しては各部署に任せた方が内製化が進みやすいというのが同氏の考えだ。「コンプライアンスやセキュリティ対策など、押さえておくべきポイントはIT部門がしっかりと押さえ、それ以外はゆるく運用してもいいのではないでしょうか。最近では、IT部門よりもむしろ非IT部門の従業員の方がデジタルツールの活用に熱心という企業もあります。先進的な技術をどんどん取り入れて業務に生かそうとするそうした従業員の自律性を育てるためにも、ローコード／ノーコード開発のダイナミズムが失われないような運用方法を採用すべきだと考えています」（甲元氏）

　ここまで前後編にわたってローコード／ノーコード開発ツールの概要やAIブームの影響、ツールの導入・運用段階で注意すべきポイントを見てきた。

　ITツールとしては比較的歴史が長く、認知度も高い製品分野で「自社の課題が解決できそう」「気軽に使えそう」というイメージが広がる中で、自社の課題の深掘りや、ツールでの開発の向き・不向きといった基本事項を押さえることの重要性がお分かりいただけたのではないか。

　今後、AI技術の活用に本格的に取り組む企業の増加などでローコード／ノーコード開発ツールの需要はさらに高まりそうだ。AIを組み込んだツールの開発やデータ活用など、利用方法がさらに多様化するツールの今後に注目したい。