こんにちは。Red Hat Decision Manager ジャック2日目です！
昨日の内容
に引き続き、その2をお送りします。お楽しみくださいませ。
製品トレーニングはあるか？
Red Hatのコンサルタントが提供しているRed Hat Decision Manager HandsOn（有償）を受講いただくのが一番効率よく、かつ、皆様が抱えている課題に対してディスカッションを行うことで、より深い理解が得られますのでお勧めしております。 一方で、ちょっと触ってみたいという方向けに、有償ハンズオンの資料部分のみを下記サイトで公開しております。 http://redhat.lookbookhq.com/rhdm_handson2019
また、オンライントレーニングとして、Red Hat Global Learning Serviceより下記のコースを提供しています。
JB731R
Decision Manager and Red Hat Process Automation Manager for Business Users
JB737R
Red Hat Decision Manager and Red Hat Process Automation Manager for Developers
下記サイトからお申し込みが可能です。 https://www.redhat.com/ja/services/training/learning-subscription オンライントレーニングを受講しての質問は、ラーニングコミュニティという下記サイトにて受け付けています。 https://learn.redhat.com/
RHへの支援要請は開発段階からでよいか？
いいえ。システムの要件定義の時点から必要になります。 ルールエンジンを導入することの目的は、業務要件の変更に柔軟に対応することです。そのためには、アプリケーション・アーキテクチャをサービス化・マイクロサービス化に対応させる必要があります。
一般的にルールエンジンを含むアプリケーションの設計開発では、何をルールとするのか、何をデータとするのかの整理が重要になります。この整理を早い段階で行うことで、データとロジックの分離構造がとりやすくなり、アプリケーション全体のシンプル化に繋がります。
また、既にあるアプリケーションを刷新する場合、ソースコードの解析から始めるケースが多いのですが、大概の場合は旧来のフレームワークの制約などにより構造が固定概念化してしまい、「多少整理されたけど今までと同じ構造」になりがちです。この場合、数年後には現状と同じ状況に陥りかねません。
Red Hat ではアーキテクチャを根本から見直して、メンテナンス性を向上させ品質良くプロジェクトを進める手法を提供しています。プロジェクトのなるべく早い段階から支援を要請いただくことで、リスクの低減と品質の向上が行われ、結果的にコストの削減につなげることが可能です。システムの要件定義の時点から要請いただくことを強くお勧めします。
設計手法はあるか？
Red Hat Decision Manager 特有の設計手法はありませんが、Object Management Group [1]で提唱されいている、Decision Model and Notation [2]をベースとした、データとロジックの明確化を行い、ルール間の関連性の整理を行います。その情報を元に、ルールの構成やサービスとしての実行単位の構成などを決定していきます。
また、Red Hat Decision Managerは「メンテナンス性の向上」を目的としたツールであり、ただ単に動けば良いというものを作るツールではありません。ルールを改変する担当者が、時間を掛けずに変更できる形式にする必要があります。このため、設計時においてもプロトタイプを作成し、担当者にレビューしてもらい、より良い形に再設計していく手法も合わせて必要になります。
[1] https://www.omg.org/index.htm [2] https://www.omg.org/dmn/
開発方法論は何を選択すべきか
ウォーターフォールからスクラムまで、世間では沢山の開発方法が論じられています。Red Hat Decision Managerの役割は、業務の変更に柔軟に対応できる仕組みとすることに他なりません。どういうことかと言うと、運用開始後の要求変更があった時に、短時間で改修が完了することを意味しています。つまり、ちょっと作って確認するような使い方がベストとなります。
初期の開発時から、「ちょっと作って確認」という開発をやってみるのはいかがでしょうか。アジャイルやスクラムのように聞こえますが、基幹システムのような箇所で使われるルールエンジンは、一部だけがリリースされても使えません。画面やデータベース等が揃って、はじめて基幹業務ができます。リリースするタイミングは全部揃ってからになるのですが、ルールエンジンをディシジョンサービスとして定義し、インターフェースを決めておくことで、ディシジョンサービスとしてのテストを繰り返しながら品質良く作ることが可能です。これをイテレーション開発と言います。大前提となることとして、アプリケーションアーキテクチャをしっかり策定しておくことが必要です。データ・プロセス・ルール・画面をサービス化し、それぞれが疎結合となるアーキテクチャを取ることを強くお勧めしています。
また、基幹システムの更改のような、アプリケーション・モダナイゼーションでは、ソースコードの解析から入りがちな現行要件確認をせず、既存のソースコードをほとんど見ずに業務要件から直接設計・実装する「ルール駆動開発」というものもお勧めしています。品質良く短期間で実装ができ、その後のメンテナンス性も向上する手法です。
業務テンプレートはあるか？
似たような業務をお持ちの会社は沢山ありますので、業務テンプレートがあると早く構築ができると思われる方も多いと思います。しかし、記述するルールはデータの形に依存するため、データの型が同じでないとテンプレートが利用できません。弊社でのプロジェクト経験からすると、データモデルが同じケースは一つとしてありませんでした。さらに、ルールとして定義している部分はその会社特有のポリシーであるため、全く応用が効きません。
お客様のポリシーを尊重してお客様の業務を伸ばすためにも、業務テンプレートを用いて業務を他社と同じにすべきではないと考えております。
パフォーマンスチューニングの観点は？
RETEアルゴリズムをベースとしたPhreakアルゴリズムは、パターンマッチング技術を利用しており、Fact(データ)とルールのマッチングを行います。この時に、複数のFactとルールにより、ルールエンジン内のAgendaという領域に複数の組み合わせができます。
Agendaにある実行待ち候補を優先順位に基づき一つ一つ実行するのですが、ある組み合わせを実行することで再評価が走り、先に作成した組み合わせが無効化されるケースがあります。その数が多いと、組み合わせを作成することが無駄になり、速度低下になる可能性があります。
再評価してくれるアルゴリズムは、for文等を書かなくとも条件にあうデータとルールの組み合わせを自動的に実行してくれるので、ソースコードの単純化には大きく寄与しますが、組み合わせが数百万もできるような場合は速度低下となるところがあります。
Phreakアルゴリズムでは、評価（組み合わせの作成）時にキャッシュで対応できるところは即反応し、そうでないところはキャッシュでの反応が終わった後に評価する「遅延評価」という仕組みを入れて、作成する組み合わせの数の削減を自動的に行うような仕組みを導入しています。
最終的には、ルールの書き方や評価の順序を見直したり、一度に投入するデータ量を調整することで、内部的な組み合わ作成の数を減らすようなチューニングを行います。
まだまだ続きます。明日もお楽しみに！
Chief Technologist 梅野
