「ルール駆動開発」知らないなら今すぐ読んでみて= Red Hat Forum 2019 セッション振り返り=

レッドハットのソリューションアーキテクト、松田です。

赤帽エンジニア Advent Calendar 2019 - Qiita

の13日目の投稿です。

11/15に開催された、Red Hat Forum Tokyo 2019では、 『ブラックボックス化した業務システムを”ルールエンジンで”華麗にホワイト化する方法』というタイトルのセッションを担当しました。

セッション資料はこちら↓ redhat.lookbookhq.com

YouTubeもあるよ。顔が丸い人が喋ってます。


Red Hat Forum Tokyo 2019:ブラックボックス化した業務システムを”ルールエンジンで”華麗にホワイト化する方法

今回のセッションテーマは、これでした。 f:id:erinam:20191206160313p:plain

そして、この開発手法を、このたび、 ルール駆動開発と名付け、提唱しました。

f:id:erinam:20191206160452p:plain

ルール駆動開発という名前

セッションタイトルを考えた時は、まだこのワードを出すかどうか決めていなかったのですが、ネーミングとかキャッチフレーズって大事なんですよね。 「ONE TEAM」とか「東洋の魔女」(古!)とか。 もっともらしい御託をつらつらならべるより、一言で伝えられたほうが、話が早いし、心に残りやすいはず。

そこで、今回は、ブラックボックス化したシステムでも迅速にリプレース可能になるこの手法を「ルール駆動開発」と名付けてみました。 といっても、この手法、昨日今日考えついたものではありません。 Red Hatでルールエンジンを用いた開発を重ねてきた結果から導かれた、ベストプラクティスです。

ルール駆動開発のつかいどころ

f:id:erinam:20191210230907p:plain

まとめるとこういう話なんですが、その詳細は、セッション資料をぜひ見ていただきたい。

そして、実はこの手法は、レガシーシステムのリプレース時だけでなく、新システムの構築時にも力を発揮します。

業務ルールを業務目線で整理して、アプリケーションの外に出し、繰返し開発で進めていくやりかたは、まだ業務ルールが固まりきっておらず、Try & Errorを迅速に繰返しながらフィードバックを即システムに反映したい、というような新サービスの構築にも非常に向いています。

最近では特に、顧客へOne to Oneのきめ細やかなサービスを提供したいというようなケースにおいて、ルールエンジンを使った「ルール駆動開発」を適用して、Try & Errorを高速に繰り返しながら、サービス品質を向上させるという事例も増えています。

最後に

様々な開発手法が世の中にあります。 私も長年の開発経験の中で、いろいろな手法を取り入れてやってきました。 どれもそれなりには意味があるものの、これが完璧というものはなく、対象システムの性格に合わせて、うまく組み合わせて使っていくべきものだと思っています。 この「ルール駆動開発」もこれさえやれば、いつでもどこでも完璧にうまくいくというものではありません。 ですが、従来の開発手法に足りていなかった、”業務ルールによる判断を一つのサービスとして切り出す”という重要な観点をプラスすることができる手法です。

業務アプリの開発に携わるすべての方に、ぜひ知っていただきたい、そして試していただきたい手法です。

Red Hatには、この「ルール駆動開発」のスペシャリストがいます。 そして、「ルール駆動開発」に欠かせないのが、優れたルールエンジン製品です。 f:id:erinam:20191210231719p:plain Red Hat Decision Managerについて、また、「ルール駆動開発」について、ぜひご相談ください。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。