2021年7月現在、さまざまなメディアで「ローコード開発」という文字が踊るようになってきました。記事が読まれる環境 = 読者ニーズの需要増があるのは間違いありませんが、裏を返せば「製品がありすぎて、どういう基準で何を選んだらよいか、わからない」という状況になったという見方もできます。
あれもこれも、みんなローコード開発ツール
こちらの記事でうまく整理されていました。
この分類をベースに、さらに私の知っている他社製品群を加味すると、こうなります。
| 分類 | 特徴 |
| 超高速開発（ソースコード生成型） | データモデルや画面レイアウトなどをツール上で設計する。コード生成のため、ビルド処理が必要。コードカスタマイズを認めない／一部認める／かなり認める、といった差がある。 |
| 超高速開発（実行エンジン型） | データモデルや画面レイアウトなどをツール上で設計する。ビルド処理不要ですぐに動作する。ツールが提供するカスタマイズ方法の範囲内で拡張する。 |
| PaaS型 | クラウド上に開発環境と実行環境が提供されている。AまたはBをCとして提供するパターンもある。 |
| データ連携型（iPaaS含む） | 複数のクラウドサービスを連携させることに重点を置いたもの。 |
| グループウェア拡張型 | グループウェアを土台に、独自のアプリケーションを作成できる仕組みを備えたもの。 |
| CRM拡張型 | CRMを土台に、独自のアプリケーションを作成できる仕組みを備えたもの。 |
| ワークフロー拡張型 | ワークフローエンジンを土台に、独自のアプリケーションを作成できる仕組みを備えたもの。 |
| ライブラリ型 | Javaなど特定言語向けの業務ライブラリ。開発スタイルは従来と変わらない。 |
| Excel型 | Excelを拡張する、もしくはクラウドでExcelに近いインタフェースを提供するもの。Excel UI が大前提のシステムに有効。 |
| ETL型 | データの抽出、変換をノンプログラミングで行うもの。UI は別。 |
| スマフォUI型 | スマートフォンアプリのUIイメージをデザインする。実際に動作するアプリとするには、別途開発が必要になることが多い。 |
おそらく市場にはもう100近い製品が存在するのではないかと思います。当社の Wagby は「A」「C」の2パターンがありますが、これだけ乱立すると「他社製品と何が違うのか？」を説明するのが大変です。
原点に立ち戻って、私は何をしたかったのか、を出発点に整理してみました。
基幹システムを自分たちでつくりたい
Wagbyプロジェクトをはじめる前、2000年前後は ERP パッケージ導入がブームとなっていました。しかし私はこの波に乗れませんでした。
- 法律で定められた業務はコモディティ化していい。しかし自社のコア業務を（ERPベンダーがうたう）他社のベストプラクティスにあわせるというのは、自社の良いところを捨てて自社を業界全体の一部品と化すことにならないのか。
- ERPの採用はデータモデルと業務処理を手放すことになる。ビジネス環境の変化に対応するためには ERP パッケージのバージョンアップに頼らざるをえない。自社の独自性・優位性を捨てることは正しい戦略なのか。
要は「自分のデータがブラックボックスなシステムに囲われる」のが怖かったのです。
しかし私の心配をよそに、多くの企業は「自社システムをどうつくるか」から、「どのERPパッケージを採用するか」に舵を切っていきました。その背景の一つに、システム開発の負荷が高くなっていたことがありました。特に1990年代から始まったオープン系、Web系といった要素技術の急激な変化に、既存の開発部隊が追いつけないことが問題でした。企業は開発のリスクを嫌ったのだと思います。
ところで基幹システムの本質は「データ構造とアルゴリズム」を自社で管理することです。OSのバージョンアップや、要素技術の入れ替わりよりも上位の次元で、業務データモデル（データ構造）と処理フロー（アルゴリズム）を抽象的な表現 = 設計情報、として記述することは可能です。そこで ERP の実現というゴールは同じですが、パッケージの採用ではなく「ERP の設計図を動かす基盤」があれば、私の心配を払拭できるのではないか。これが Wagby の思想的原点になっています。
なお私がイメージする ERP は、もちろん業務データが中心ですが、人事や総務系、そしてグループウェアで共有できる情報系までを一括りでとらえています。すべての情報を統合的に扱うための業務基盤を実現する「動く設計図」を作成し、保守し続けること。これが企業にとっての理想形態であると位置付けました。
設計図を動かす基盤、としてのローコード開発ツールが本命
企業の情報システム部というのは、究極的には自社が管理するすべてのデータの「意味」をわかっており、かつ、データの発生から、どの処理で使われて、どこで終わるのかという「ライフサイクル」を知っている責務があると考えています。
この責務を全うするための手段として、ERPパッケージを採用するか、自社でシステムを開発するか、があります。パッケージ採用であっても、パッケージの内部を理解することで同じゴールに至ることができます。ただ、ベンダーが *汎用的に* つくったシステムは、だいたいにおいて冗長で、内部構造の理解は難しいです。それよりも最初から自社が望むデータモデルからシステムを構築するのが、むしろ楽なのではないかと思います。
とはいえローコード開発ツールを使わない、従来型開発の問題点は「設計情報、プログラム、ドキュメントが自動連携されていないこと」でした。設計上を Excel で書き、大量のエンジニアを動員してプログラムを開発する労働集約型開発に嫌気がさすのは当然です。この状態と比較するならば、ERP の内部構造を理解する方が「まだ、まし」なのかも知れません。
しかしローコード開発ツールによって、これらの問題を解決できる目処がたちました。すると自社オリジナルの ERP を内製開発するというアイデアが現実的になります。2021年は、ちょうどその局面に入ったところです。
以上を踏まえ、Wagbyの存在意義をまとめてみます。
- 動く設計図を実現する基盤とすること。
- データベース（テーブル定義）はユーザの手元におくこと。ブラックボックスにしない。
- カスタマイズ性を確保すること。これは UI から既存システムとの連携まで、幅広いテーマである。
この全てを満たすツールはかなり少数ですが、Wagbyはそのうちの一つです。その上で、常に品質を向上させ、マニュアルを充実し、サンプルアプリケーションを増やすことが求められています。お客様は私たちの取り組み姿勢を常にみていらっしゃる、という自覚で日々の開発とサポートを行っていきます。
