0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【Workato】ネストした IF/ELSE 地獄を意思決定モデルで解消する。

0
Posted at

はじめに

レシピの中に if/else を何段も積み上げてしまい、「この条件、どこで効いてるんだっけ?」と毎回スクロールして探すことはよくあることです。意思決定モデル は、こうした条件分岐ロジックをレシピ本体から切り離し、テーブルとして一元管理するための新しいアセットです。

意思決定モデル とは

意思決定モデル は、複雑なビジネスルールを「判定表」という分かりやすい形式に集約する Workato のアセット種別です。入力と出力を一度定義すれば、同じモデルを複数のワークフローから再利用でき、ロジックの一貫性と保守性を確保できます。

全体像:モデルを構成する4つのノード

意思決定モデルは、ビジュアルなモデルビルダー上でノードをつないで組み立てます。登場するノードは次の4種類です。

ノード 役割
モデル入力 呼び出し元レシピから受け取る入力フィールドを定義する入口
決定テーブル 入力を評価し、ルールに従って結果を出力する判定表
条件分岐 入力や上流の結果に応じてデータを別の判定表へ振り分ける分岐
モデル出力 レシピへ返すフィールドを選ぶ出口

ノード間を流れる中間値は モデルフィールド と呼ばれます。判定表の出力を下流ノードへ渡す役割で、単一の判定表だけのシンプルなモデルでも必須です。

データは次の順で流れます。

  1. 呼び出し元レシピが入力フィールドの値を渡す
  2. 入力が、モデル入力ノードに直接つながった判定表・分岐へ渡される
  3. 判定表や分岐が、入力フィールドや上流のモデルフィールドを使って条件を評価する
  4. 判定表は結果をモデルフィールドに書き込み、下流へ渡す(分岐は受け取ったフィールドをそのまま True のブランチへ通す)
  5. モデル出力が、選択した入力・モデルフィールドを呼び出し元へ返す

具体例:所在地・会社名から地域を判定する

ここまでの説明をイメージしやすくするために、上の「地域特定」モデルを例に、入力から出力までの流れを追ってみます。

まずは単純なケースとして、所在地 = 「日本」 が渡ってきた場合です。

  1. 所在地 = "日本" を受け取り、決定テーブルへ渡す
  2. 決定テーブル が上から条件を評価し、1行目「日本」でマッチする
  3. 地域 = "アジア" を出力する

結果、「日本」という入力に対して「アジア」が得られます。

ここで注目したいのが、行の順序です。たとえば 所在地 = 「アメリカ」、会社名 = 「リックソフト株式会社USA」 が渡ってきた場合を考えます。所在地だけ見れば6行目「アメリカ」(→ 北米)にマッチしそうですが、それより上の4行目「海外子会社」(会社名 = リックソフト株式会社USA)が先にマッチするため、出力は 「アジア」 になります。

これを if/else で書くと「会社名がUSA子会社なら…そうでなく所在地がアメリカなら…」という入れ子になりますが、判定表なら例外行を上に置くだけで済み、優先順位も一目で読み取れます。
ルールを変えたいときも、修正するのは この判定表の行だけ です。モデルを呼び出している各レシピには手を入れる必要がありません。これが、条件ロジックをモデルに集約することの効果です。

ユースケース

単純な条件分岐の使い方だけでなく、以下のユースケースが想定されます。

  • 顧客スコアによる優先度判定
  • 問い合わせタイプによる担当者割り当て
  • 住所から地域を決定
  • 承認ルート・承認者の自動判定
  • 顧客ランク・購入数量・地域から割引率を決定

ポイント

  1. 再利用できる:1つのモデルを複数レシピから呼び出せる
  2. 一元管理できる:ルール変更はモデルを直すだけ。各レシピを触らなくてよい
  3. だれでも読める:表形式で誰でも読むことができ、管理の負担を減らせる
  4. 柔軟な条件設定:~で始まる、~を含む、以上以下...など様々な条件を組み合わせて指定できる

使い方

アセットとして作成して、レシピ内で呼び出すことで利用できます。

Before / After

観点 Before(ネスト IF/ELSE) After(意思決定モデル)
ロジックの所在 各レシピに散在 モデルに集約
ルール変更 レシピを開いて該当箇所を探す 判定表の行を編集するだけ
再利用 コピペ → マッピングがズレる 1モデルを複数レシピで共有
業務側の可読性 低い(条件式の塊) 高い(表形式)
管理の手間 各レシピごとに管理 アセット単位で管理

まとめ

意思決定モデルを使うと、レシピに埋もれていた条件分岐を「表ベースの再利用可能なアセット」として切り出せます。ビジネスロジックと条件ロジックが分離されることで、変更が速く・安全になり、業務側も読めるようになります。

ネストした IF/ELSE が3段を超えてきた、あるいは同じ判定を複数レシピにコピペしている、そんな兆候が出てきたら、意思決定モデル への切り出しを検討するタイミングです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?