【BizRobo! Link】フィードバックをもらったので Decision Table の機能を強化しました

はじめに

とりあえず作ってみたものの、なかなかユーザーが得られず。。
そんな中、有志の社内ユーザーから率直なフィードバックをいただいたので、早速改善してみました！

下でも触れますが、ざっとこんな感じ。

• 設定した Decision Table にロジック・パターンの漏れがないか確認できる機能
• 設定した Decision Table 単体でロジックをテストできる機能。（業務ロジックを設定する人と、それを使ったロボットを作る人の分離が可能）
• 複数人でメンテナスする場合に、だれがいつ何を修正したかを追跡できる監査機能の追加
• UX向上のためのドラッグ＆ドロップによる「列」や「行」の並び順入れ替え
• 行並び替えによる、評価順の自動更新
• 列条件の「OR」評価の追加

機能性はもちろんですが、使用感もだいぶ上がっていると思います。

実際のユースケースに触れないとわからないギャップ

多くの開発者がそうであるように、私も「おぉ、これはなかなかいけるかも。」と思いながら機能を設計・開発していくわけですが、そこには実際のユースケースがなかったりします。

想定はしていても、自分が考える期待や振る舞いと、実際にその機能を遣おうとした人が抱く期待やその時点で持っている前提知識、振る舞いには多くのギャップがあり、やはり、実際に使ってもらっていただくフィードバックは大切ですね。

フィードバックをもらったうえで改めて同じものを見ると、全く違って見えることもよくあります。
作りっぱなしはよくないですね。

今回のアップデート詳細とポイント

1. シミュレーターで事前検証

• 入力JSONを使って、その場で判定結果を確認
• 一致した行を「評価順」で表示
• トレースで、各条件の一致/不一致理由を確認

トレース結果として表示されるボタンをクリックすると、該当の条件行が選択されるので対比してみたときにわかりやすいです。

シミュレーターの入力JSONとして表示される文字列をコピーして、ロボットからコネクター経由で実行する際のパラメータとして貼り付けると便利です。

「コネクターでは JSON 文字列を貼り付けないといけないが、その文字列を作るのがわかりにく」という要望には、いくらかこれで応えられているかなと思います。（BizRobo!自体のバージョンアップによってJSONの取り扱いはだいぶ楽になるので、今回の改善では特に触れずです。）

2. 品質チェックでルールの課題を可視化

• 重複ルール
• 未到達ルール（firstヒット時）
• 競合の可能性
• 空条件・不正条件

実際の業務では、当初想定していたものよりもより条件項目数もパターンの数も多いようで、設定値自体のチェックをするのが大変ということなので、動的にチェックする仕組みを組み込みました。

現実の世界では必ずしも１つの Decision Table 上にすべてのパターンを網羅するのではなく、多段階で階層的に Decision Table で判断することもあるようで、専用システム的にはDMNとかDRDとかいうのかな？
さすがにそこまでの実装は考えてませんが、Decision Table をいくつかに分けて組み合わせて使う¹ことに関しては、今後もう少しわかりやすくしてもいいかもしれない。（今回は疲れたのでそこまではやらない。）

3. 監査履歴で変更を追跡

• 履歴一覧と詳細差分を画面で確認
• 選択中ログをハイライト表示
• ローカル時刻で表示
• ページングで大量データにも対応
• 実行ユーザー情報（ID/名前）も確認可能

見やすさを考えると、監査履歴の詳細データもJSON文字列ではなく表形式の見やすい表示にした方がいいのでしょうが、監査履歴の対象利用者はシステム管理者なので、JSONわかるだろうし、一旦そのままでもいいかなと。力尽きました。

条件列の「OR条件」対応

条件列を AND だけでなく OR でも定義できるようになりました。

• 評価方式: 連続ORグループ方式
  • 例: A AND (B OR C OR D) AND E
• 列追加/列編集ダイアログの「OR条件として追加」で設定
• OR列はヘッダ上で小さな or 表示
• Excel入出力は列名の [or] 接頭辞で往復可能

UI調整

• OR列でも条件未設定は Any 表示（or Any にはしない）
• データセルの or 接頭辞は小さめグレー表示に統一
• 行並び替えはドラッグ＆ドロップで実施可能
• 並び替えは即時保存（保存ボタン不要）
• 行先頭にドラッグハンドルを表示し、ドラッグ可能であることを視覚的に明示
• 評価順ヘッダーはアイコン化し、表示密度を改善

運用面の改善

監査ログの保持ポリシー:

• 180日を超えるレコードを削除
• 10,000件を超えた場合は古い順に削除

定期バッチではなく、監査記録時に自動でクリーンアップを行います。
また、差分がない更新は監査ログを作成しないため、不要な記録を抑制できます。

活用例

例1: 料金ルール改定前の確認

1. 条件列・結果列を更新
2. シミュレーターで代表ケースを入力
3. トレースと品質チェックで問題がないか確認
4. 保存して反映

例2: 問い合わせ対応時

1. 受け取った入力値でシミュレーション
2. 一致した評価順を確認
3. 監査履歴で直近変更の差分を確認

例3: 定期メンテナンス

1. 品質チェックを定期実行
2. 重複・競合候補を整理
3. ルールを統廃合

まとめ

実際に業務で利用されることを考えると、「DataStand」の Garage 機能で実装したような、Decision Table 上のルール自体の履歴管理、切替管理も必要なのでは？と思い出しました。

ただ確信はないので、フィードバックや要望もらったら具体的に考えようと思います。

1. 例えば ID:25 のテーブルで算出対象の判定をしたうえで、結果によって ID:24～26 の別のテーブルを読ませて最終的なポイントを取得する。とか。対象によって判断の条件が違うので、全部一つのDecision Table内で行おうとすると、NULL値の多い、でかくて見にくいものになってしまいます。
   ↩