ノーコードを使った審査業務
ローコード、ノーコードでルールが記述できる
銀行での住宅ローン、車ローンの与信審査、保険の審査、保証対象かどうかの審査、見積がルール通りかどうかの審査、など、あるきまったルールに当てはまっているかどうかを判定することがよくあると思います。このルール判定業務を、プログラムコードを書くことなく、ノーコードツールを利用して、判定する、そういった事例が増えているようです。
Pega の事例
こちらは、Pega を使った三菱UFJ銀行の住宅ローン審査判定の事例です。
事例によると、住宅ローン審査業務のような長くて複雑な業務プロセスをGUIにて設定できるようにしました。結果、業務量の75%削減や、紙資料（印刷物）の月間20,000枚が削減、事前審査が最短2時間で完了、という結果が出たそうです。Pegaという製品分類としては、ローコードですが、ノーコードでもこのような複雑なルールエンジンがすぐに、提供されるくるでしょう。
業務ロジックという特殊ワード
これまで、業務ロジックをプログラム開発に、相当数費やしていたかと思います。それが、開発エンジニアの仕事だと思っていた方も多いと思います。確かに、業務ロジックを設計することは、今後も開発エンジニアの仕事です。ただし、それをコーディングに落とし込む作業は、ノーコードやローコードがやってくれるようになるでしょう。
開発会社との付き合い方
これまでに開発の場合、このようなコーディング作業は、オフショアやニアショアなど単価の安いところに任せていました。ただ、今後はこのようなオフショアやニアショアに任せるのではなく、ノーコード、ローコードツールを用いて開発するようになっていくでしょう。
今後のパターンとしては、３つ考えられます。
１）オフショア、ニアショアとして仕事をしてきた会社に、引き続き、ノーコード、ローコードツールで開発を依頼する
２）新しいツールを使いこなせるリソースを見つけてそこに任せる
３）ツールがあれば短時間で開発できるので、開発エンジニアが自分たちで開発するようになる
４）開発を自社で実施するようになっていく
このなかで一番可能性が高いのは、３）だと、私は思います。オフショア、ニアショアのメリットでなんだったのでしょうか？コストを安く開発できるから、それが一番の理由でした。それに対して、デメリットが多く存在していたことを覚えていますでしょうか。リモートによる仕様伝達不足、オフショアの場合の言語の壁、品質の壁、などがありました。これは、オフショア、ニアショアへ依頼する依頼元側の問題もあったと思います。このような問題は、ノーコードツールが解決してくれます。仕様を伝達するよりも早く開発できてしまうのです。
さて、これまでは、与信業務を組み立てるには、以下のような、ルールエンジン専用の製品がありました。ノーコードの先駆けなのかもしれません。
ルールエンジンの製品一覧
IBM Operetional Decision Manager
これらは、ビジネスルール管理ができ、それが運用できるツールとして一定の実績を持っていました。そして、そのルール設定は、多くのことがGUIベースのある意味ノーコードで設定できるようになっていました。フローチャートを画面で設定していくようにルールが記述できたのです。
ノーコードの発展
これらノーコードツールを発展させ、業務システムにも適用できるようになってきたのが、昨今のノーコードのツールです。今後ますます発展していくノーコード、今からぜひ押さえておくべきツールだと私は思っています。