2021年に入ってから、ローコード開発という言葉を耳にするようになりました。アプリケーションを作るのに、より少ないプログラミングで(時には一切プログラムを実装しないで)可能にすることができるツールやサービスを指しています。

このブームと言うか火付け役になったのが、Microsoft Power Automate だと思います。ローコードのサービスは主に海外のスタートアップで盛り上がっており、GoogleもAppSheet、AWSもHoneycode等のサービスをリリースしていますが、あくまでもエンジニア向け。WindowsにRPAツールが標準搭載されたので、大いに盛り上がりました。RPAもローコードには違いないですからね。

では、ローコードの「low」の部分は、何を示しているのかを解説します。

目次
  1. ローコード開発は、開発工程を圧縮することで実現できる
  2. ローコード開発は社内システムに適している
  3. ローコードを活かすにはアプリケーション開発経験が求められる

ローコード開発は、開発工程を圧縮することで実現できる

皆さんが使っているWebシステム等の開発手順を大きく言えば、この内容に集約されます。

  1. 画面を設計する
  2. データを保存するデータベースの設計をする
  3. 画面を開発する
  4. 開発した画面のユーザー操作に応じて、呼び出す機能を実装する
  5. 呼び出した機能に対し、データ操作のロジックなどを実装する
  6. 適切な動作になっているかどうかテストを行う

画面を設計しないと入出力するデータの構成が決まらないですからね、画面から設計することが多いです。

ローコード開発では、設計と開発を１つにまとめて、開発手順を圧縮して単純なものにします。

  1. 画面を設計する(パワポでパーツを切り貼りするようなイメージ)
  2. 設計したアプリが適切な動作になっているか確認する

これがローコード開発の開発手順です。

入力値をそのまま保存するだけなら、機能は「入力値を保存する」だけで良い。そのため、画面を設計したらツールが入力値を保存するプログラムとデータベースを自動で作れば、ユーザーはプログラムを実装する必要がなくなります。設計するとアプリが自動で作られるので、設定内容と業務内容に齟齬が無いかチェックして、終わりです。

逆に言いますと「入力値を保存する」以外のデータ操作が求められる場合、ローコード開発いえどもカスタマイズであったり、追加のプログラム実装が求められます。

また、ローコード開発ツール全般の特徴として、UI周りを細かく設定・変更することができません。やろうと思えばできるが、ローコードじゃなくフルコードになってしまうので、ローコードのメリットが活かせず本末転倒になります。

ローコード開発は社内システムに適している

不特定多数の一般ユーザーが使うようなサービスは、UI/UXの向上が最も大切です。これによってアプリの使い勝手やサービスの競争力に直結するので、このような用途でローコード開発ツールを用いるのは現実的ではありません。ツールが提供するUIに、制限があるからです。

ローコード開発で適しているのは、社内システムです。ローコードのメリットが活かせます。

  • 売上向上ではなく、業務効率化や改善を目的としている
  • Webシステムは必要だけど、実装する技術もそれができる要員も不足している
  • 項目の追加や集計の追加など、自分たちで設定して変更できる余地を残したい
  • 初期投資を抑えたい

上記のような状況にピタッとハマるのが、ローコード開発ツールです。

１つだけ注意しないといけないのは、ローコードに限らないですけど、作ったWebシステムはそう簡単に他のサービスに移転できません。ローコードの場合はコードをユーザーが手に入れることができないので、サービスが無くなったらシステムもなくなります。なので、母体がしっかりしている or マーケットシェアが高いツールを選んで下さい。

ローコードを活かすにはアプリケーション開発経験が求められる

作ると、活かす。この違いは大きいです。

ローコード開発はパワポでパーツを切り貼りするような感覚で画面が作れますので、誰でも作れます。プログラミングが一切できない人でも作ることはできます。

ただ、作ったシステムを業務効率化等に活かせるかは、全く別の問題です。

Excel管理を脱却する目的で現行利用しているExcel台帳のようなものをWebシステム化したけど、業務の手順が全然変わらず効率化されていないので、結局これなんなので社内展開されず朽ちていくケースを耳にしました。これが、作ると活かすの違いです。

ローコード開発ツールを活かすためには、作ったシステムが皆さんの業務内容を変革するテコになる必要があります。そのためには、もう１つ上の視点から業務を見直して、この処理をITで自動化してやっつけようという裏付けが必要。この裏付けには、アプリケーションの開発経験が必要です。

業務をITで変革した経験が不足している場合、発想に限界が生まれます。ツールの特性と業務変革の度合いを鑑みれば、もっと良い状態になるかもしれません。なので、業務をただシステムに置き換えるのではなく、その先のメリットやゴールを共有した上で推進して頂ければ、必ず爪痕は残ります。

ITコンサルティングをやっていてよく思うのですが、私達コンサルタントに求められるものを一言で言えば「推進力」です。推進の源になるのは、皆さんが「これはいいね」というゴールを見出して、ステップを踏んで着実に進める流れを作ること。

業務改善は楽しい行いです。楽しく進めて行きましょう！