ローコード開発について
少し前になりますが、先代の社長からローコード開発ツールを勧められたことが
あります。
当コラムの初回にも書きましたが、我々はパッケージソフトを自社開発して、ビ
ジネスを行っています。なので技術者は全員バリバリのプログラマです。
そこにローコード開発ツールを勧められたので、社長の意図が分からず戸惑った
ものです。ちなみに社長は親会社から天下ってくるので、この業界の人ではあり
ません。
これまで作って来た商品ソフトウェアを、このローコード開発ツールで開発でき
るようにしろということなのか。ローコード開発ツールで受託開発をしろ、とい
うことなのか。
ローコード開発ツール自体を否定するつもりは全くないのですが、自分達がソフ
トウェア開発を生業としている以上、ローコード開発ツールを導入してのビジネ
スにあまりメリットを感じません。ましてや自社でパッケージ開発をしているの
で、社内技術者のプログラミングスキルは高いと思っています。それなのに、ロ
ーコード開発ツールを担いでしまうと、せっかくのプログラミングスキルの高さ
が生かされなくなるように感じます。
我々のやり方としては、パッケージを開発し、お客様に導入する際にはカスタマ
イズ。そしてカスタマイズ内容の中で他社でも使えそうな機能はパッケージにフ
ィードバック、というサイクルを繰り返しています。そのため、商品ベースとな
るソフトウェアはかなり機能が充実しています。たしかにパッケージ売切りのビ
ジネスではないので、カスタマイズにはそれなりのスキルと工数が必要になりま
すが、いちからスクラッチ開発することを考えると、必要となる工数は各段に少
なくなります。
実はあるシステム開発のRFPコンペがあり、我々も見積提案した案件がありまし
た。結局採択にはなりませんでしたが、後から聞いた話によると、相手の開発会
社はスクラッチ開発での提案で、金額規模で我々の提案の1桁上。これをローコ
ード開発ツールを導入して開発するので、ということでフルスクラッチの見積の
半分で提案しましたが、それでも我々の提案の２倍以上の金額だったそうです。
いろいろと条件が異なるので一概に比較することはできませんが、ローコード開
発ツールを使っての開発よりも、パッケージ＋カスタマイズの方が安く短納期で
開発が可能なのか、という点にローコード開発のひとつの議論があるように思え
ます。
例えば在庫管理システムを開発する際、棚卸資産の評価方法（先入れ先出し法や
移動平均法など）というのは法律上決まっています。それをソフトウェア化する
際には、端数処理の方法など独自のアルゴリズムが必要になります。このプリミ
ティブな機能の上に、各社独自の業務管理機能が必要になってくるのです。この
様に機能が共通的な機能と独自的な機能の階層的構造になっている場合、ローコー
ド開発ツールのみでの開発では厳しくなると踏んでいます。ローコード開発ツー
ルがどのような種類のシステムも作れるという汎用性を謳えば謳うほど、共通的
な機能も毎回作りこまなければならず、端数処理などのシビアなアルゴリズムを
コーディングなしで作りこめるのか、といことに甚だ疑問を感じるからです。
逆にパッケージ＋カスタマイズの場合、評価方法や端数処理などはパッケージと
して既に作りこまれています。その上に、各社独自の業務管理機能のみをカスタ
マイズとして作りこめばよいので、これがローコード開発ツールとの優位性にな
ります。代わりにパッケージ＋カスタマイズでは、元となるパッケージ機能がな
い限り、そのシステム開発には対応できませんので汎用的にどのようなシステム
も開発できるローコード開発ツールの方がその間口の広さにおいて優位性がある
のです。
つまりローコード開発ツールは、個社特有の専用システムをスクラッチ開発する
場合の解決案であり、パッケージ＋カスタマイズは各社共通システムを個社対応
するための解決案となりアプローチの仕方が真逆であるという事がわかります。
ただローコード開発という意味においては、システム導入時の開発工数を減らす
ための施策、という意味で目指しているところは同じ、ということになるのはな
いでしょうか。ただパッケージ自体をローコード開発ツールで開発するには、ま
だまだツールでは力不足だと考えております。
これが、前社長からローコード開発ツールを勧められた際の戸惑いでした。本質
的に違っているアプローチのためのツールを勧められたのだから、戸惑うのは当
たり前でしょう。
因みに今後、パッケージ＋カスタマイズはどの様に進化させてゆくかの腹案を少
し書いておこうと思います。
15年近くパッケージ化をしてきたので、パッケージの機能は随分と充実してきて
います。ただ一方でパッケージ自体は一つのシステムなので、それが肥大化して
おり、どの機能がどの様に使われているか見通しが悪くなってきます。特に業務
と密接に関係しているので、業務知識も必要となるなかで業務とシステムの含め
てすべてを理解することが難しくなってきているのです。その影響はカスタマイ
ズフェーズにも出てきており、慣れた技術者が担当すると少工数で対応が可能で
すが、慣れない技術者が担当するとパッケージ自体の理解が足りず余計に時間が
かかってしまいます。パッケージの習熟度による差が大きく、パッケージの習熟
に時間がかかってしまうようになってしまいました。
そこで、次のバージョンとしてパッケージのマイクロサービス化を実現したいと
考えています。参考になるのはＡＷＳをはじめとしたクラウド―サービスです。
クラウドサービスでは、サーバやストレージ、ネットワークなどがそれぞれ独立
したサービスでありながら、サービスが別のサービスを利用した構成をとること
ができます。そして制御、運用、セキュリティから課金の仕組みまでが各サービ
スに内包されています。これを業務システムで各業務機能単位で実現したい。例
えば在庫管理機能と勤怠管理機能がそれぞれサービス化されており、それぞれ独
立して機能しつつも在庫管理から勤怠管理機能を呼び出して使うことができる。
そしてそれぞれの機能にあった課金の仕組み（在庫管理ならアイテム数で課金、
勤怠は管理対象者数で課金など）まで有する機能。そしてそのサービスは自社パッ
ケージ内だけはなく、他社システムからも利用することができる。
そんなシステムを作りたいと思ってはいますが、生きている間に実現できるかは
問題です。