ビジネスロジックのハードコーディングをやめ、ディシジョンテーブルを活用しましょう

[JunshuO]

ServiceNow で一定期間構築に携わってきた方なら、おそらく、あの フローのいずれかを継承した（または構築した）経験があるのではないでしょうか。ご存知のとおり、if-else 分岐が複雑に絡み合い、数十ものレコード更新アクションや、複数のワークフローにコピー&ペーストされたロジックが散乱しているようなものです。それは機能します...しかし、ビジネス部門の誰かがルールを変更すると、突然、同じ条件を更新するために5つの異なるフローを深く探し回ることになります
ディシジョンテーブルはこの問題を解決します。そして正直なところ、それらがどれほどの整理・改善をもたらすかにもかかわらず、十分に注目されていません。

ディシジョンテーブルとは何ですか？

これらは、構造化された再利用可能なロジックチャートと考えてください。入力条件 (左側の列) と出力結果 (右側の列) を定義し、行にビジネスルールを入力してから、プラットフォーム上のどこからでも (フローデザイナー、プレイブック、プラットフォームスクリプト、API連携など) そのテーブルを参照できます。

重要な点は、関心事の分離です。 ワークフローはロジックを実行しますが、保存しません。 ディシジョンテーブルは信頼できる唯一の情報源になります。テーブルを変更して公開すると、それを参照するすべてのワークフローが新しいロジックをすぐに取得します。

ディシジョンテーブルが解決する 3 つの問題

1) 開発者の依存関係: ビジネスロジックの変更に開発者の対応は必要ありません。ディシジョンテーブルを使用すると、ビジネスユーザーはロジックを Excel にエクスポートし、編集し、再度インポートして公開することが、すべて数分以内に可能です。

2) 分散ロジック: 同じルーティングロジックまたは承認ロジックが複数のフロー内に存在する場合、それらを同期させるのは悪夢のようなものです。ディシジョンテーブルはそれを 1 か所に一元管理します。

3) コラボレーションのギャップ: ビジネスルールを理解している人 (法務部門、運用マネージャー、コンプライアンス担当者) が、必ずしもフローを編集できるとは限りません。ディシジョンテーブルはそのギャップを埋めます。

 

ユースケース 1:インシデントルーティング

シナリオ:受信インシデントは、優先度、カテゴリ、VIP ステータスに基づいて、正しいエスカレーションレベルと SLA を持つさまざまなアサイン先グループにルーティングする必要があります。

従来のアプローチとは？複数の if-else 分岐と、すべての組み合わせに対する個別のレコード更新アクションを含む複雑に絡み合ったフローです。各分岐は、アサイン先グループ、エスカレーション、および解決時間をハードコードします。

ディシジョンテーブルを使用すると、フローは 3 つのステップになります。トリガー→意思決定 (アサイン先グループ、エスカレーション、SLA を返す) →レコードを更新します。それでおしまい。すべてのルーティングロジックは、フローではなくディシジョンテーブルに存在します。

 

ユースケース 2:カタログ要求履行

カタログアイテムの場合は、履行グループと、カテゴリ、サブカテゴリ、および価格のしきい値に基づいて承認が必要かどうかを決定する必要があります。

昔ながらの流れには 19 のステップがありました。ディシジョンテーブル版ではどうでしょうか？4ステップです。フローはカタログ要求でトリガーされ、ディシジョンテーブルを呼び出して履行グループと承認フラグを取得し、承認が必要かどうかを確認して、要求を更新します。クリーンで読みやすく、保守しやすいものとなります。

 

ユースケース 3:変更承認ポリシー

変更要求には独自の複雑さがあります。変更タイプ、リスクレベル、カテゴリ、サブカテゴリはすべて、どの承認グループが対応するか、どの承認レベルが必要か (マネージャー、ディレクター、自動承認)、そして SLA ターゲットに影響します。

24 ステップの従来のフローは、ロジックを処理するディシジョンテーブルを使用して約 4 つのステップに折りたたまれます。フローは、ディシジョンテーブルに出力を要求し、それらに基づいて処理するだけです。

 

Excel でのエクスポート/インポート機能

これは、技術者以外のユーザーでも意思決定テーブルに真にアクセスできるようにする機能です。ディシジョンテーブル全体を Excel にエクスポートしてビジネスステークホルダーに渡し、行を追加または変更させ、再度インポートすることができます。プラットフォームの専門知識は必要ありません。開発者チケットはありません。待つ必要はありません。

このエピソードの実例の 1 つは、法務部門が地域や期間によって異なる複雑な承認ロジックを管理していたことです。ディシジョンテーブルが登場する前は、すべての変更に開発者の関与が必要でした。その後はどうでしょう？法務顧問はロジック自体を維持し、完全なデータの機密性を確保し、変更をすぐに本番環境にプッシュすることができました。

 

他に検討すべきユースケース

上記の 3 つのディープダイブは出発点にすぎません。チームは、適格性とコンプライアンスルール (従業員の属性に基づいて福利厚生、ライセンス、認定を決定する)、セキュリティインシデントルーティング (重大度と資産タイプに基づいて専門のチームにインシデントを送信する)、承認しきい値 (金額、部門、要求タイプに基づいて承認要求をルーティングする)、割引と価格設定ロジック (顧客割引を動的に管理する)、統合ルーティング (条件に基づいて呼び出す API エンドポイントを決定し、適切なサブフローを動的に呼び出すこと) にディシジョンテーブルを積極的に使用しています。

 

まとめ

ディシジョンテーブルは、すべての ServiceNow サブスクリプションに含まれています。これらはプレミアムアドオンでも、個別のライセンスでもなく、いつでもフローを整理する準備ができています。現在、ワークフローにビジネスロジックをハードコードしている場合、これは最も ROI の高い改善プロジェクトの 1 つとなるでしょう。

ぜひお試しください。未来のあなた (そしてあなたのフローの変更を待っているビジネスユーザー) は感謝するでしょう。

---

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-advocate-blog/stop-hardcoding-business-logic-use-deci...。

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-advocate-blog/stop-hardcoding-business-logic-use-deci...。

[JunshuO]

ServiceNow で一定期間構築に携わってきた方なら、おそらく、あの フローのいずれかを継承した（または構築した）経験があるのではないでしょうか。ご存知のとおり、if-else 分岐が複雑に絡み合い、数十ものレコード更新アクションや、複数のワークフローにコピー&ペーストされたロジックが散乱しているようなものです。それは機能します...しかし、ビジネス部門の誰かがルールを変更すると、突然、同じ条件を更新するために5つの異なるフローを深く探し回ることになります
ディシジョンテーブルはこの問題を解決します。そして正直なところ、それらがどれほどの整理・改善をもたらすかにもかかわらず、十分に注目されていません。

ディシジョンテーブルとは何ですか？

これらは、構造化された再利用可能なロジックチャートと考えてください。入力条件 (左側の列) と出力結果 (右側の列) を定義し、行にビジネスルールを入力してから、プラットフォーム上のどこからでも (フローデザイナー、プレイブック、プラットフォームスクリプト、API連携など) そのテーブルを参照できます。

重要な点は、関心事の分離です。 ワークフローはロジックを実行しますが、保存しません。 ディシジョンテーブルは信頼できる唯一の情報源になります。テーブルを変更して公開すると、それを参照するすべてのワークフローが新しいロジックをすぐに取得します。

ディシジョンテーブルが解決する 3 つの問題

1) 開発者の依存関係: ビジネスロジックの変更に開発者の対応は必要ありません。ディシジョンテーブルを使用すると、ビジネスユーザーはロジックを Excel にエクスポートし、編集し、再度インポートして公開することが、すべて数分以内に可能です。

2) 分散ロジック: 同じルーティングロジックまたは承認ロジックが複数のフロー内に存在する場合、それらを同期させるのは悪夢のようなものです。ディシジョンテーブルはそれを 1 か所に一元管理します。

3) コラボレーションのギャップ: ビジネスルールを理解している人 (法務部門、運用マネージャー、コンプライアンス担当者) が、必ずしもフローを編集できるとは限りません。ディシジョンテーブルはそのギャップを埋めます。

 

ユースケース 1:インシデントルーティング

シナリオ:受信インシデントは、優先度、カテゴリ、VIP ステータスに基づいて、正しいエスカレーションレベルと SLA を持つさまざまなアサイン先グループにルーティングする必要があります。

従来のアプローチとは？複数の if-else 分岐と、すべての組み合わせに対する個別のレコード更新アクションを含む複雑に絡み合ったフローです。各分岐は、アサイン先グループ、エスカレーション、および解決時間をハードコードします。

ディシジョンテーブルを使用すると、フローは 3 つのステップになります。トリガー→意思決定 (アサイン先グループ、エスカレーション、SLA を返す) →レコードを更新します。それでおしまい。すべてのルーティングロジックは、フローではなくディシジョンテーブルに存在します。

 

ユースケース 2:カタログ要求履行

カタログアイテムの場合は、履行グループと、カテゴリ、サブカテゴリ、および価格のしきい値に基づいて承認が必要かどうかを決定する必要があります。

昔ながらの流れには 19 のステップがありました。ディシジョンテーブル版ではどうでしょうか？4ステップです。フローはカタログ要求でトリガーされ、ディシジョンテーブルを呼び出して履行グループと承認フラグを取得し、承認が必要かどうかを確認して、要求を更新します。クリーンで読みやすく、保守しやすいものとなります。

 

ユースケース 3:変更承認ポリシー

変更要求には独自の複雑さがあります。変更タイプ、リスクレベル、カテゴリ、サブカテゴリはすべて、どの承認グループが対応するか、どの承認レベルが必要か (マネージャー、ディレクター、自動承認)、そして SLA ターゲットに影響します。

24 ステップの従来のフローは、ロジックを処理するディシジョンテーブルを使用して約 4 つのステップに折りたたまれます。フローは、ディシジョンテーブルに出力を要求し、それらに基づいて処理するだけです。

 

Excel でのエクスポート/インポート機能

これは、技術者以外のユーザーでも意思決定テーブルに真にアクセスできるようにする機能です。ディシジョンテーブル全体を Excel にエクスポートしてビジネスステークホルダーに渡し、行を追加または変更させ、再度インポートすることができます。プラットフォームの専門知識は必要ありません。開発者チケットはありません。待つ必要はありません。

このエピソードの実例の 1 つは、法務部門が地域や期間によって異なる複雑な承認ロジックを管理していたことです。ディシジョンテーブルが登場する前は、すべての変更に開発者の関与が必要でした。その後はどうでしょう？法務顧問はロジック自体を維持し、完全なデータの機密性を確保し、変更をすぐに本番環境にプッシュすることができました。

 

他に検討すべきユースケース

上記の 3 つのディープダイブは出発点にすぎません。チームは、適格性とコンプライアンスルール (従業員の属性に基づいて福利厚生、ライセンス、認定を決定する)、セキュリティインシデントルーティング (重大度と資産タイプに基づいて専門のチームにインシデントを送信する)、承認しきい値 (金額、部門、要求タイプに基づいて承認要求をルーティングする)、割引と価格設定ロジック (顧客割引を動的に管理する)、統合ルーティング (条件に基づいて呼び出す API エンドポイントを決定し、適切なサブフローを動的に呼び出すこと) にディシジョンテーブルを積極的に使用しています。

 

まとめ

ディシジョンテーブルは、すべての ServiceNow サブスクリプションに含まれています。これらはプレミアムアドオンでも、個別のライセンスでもなく、いつでもフローを整理する準備ができています。現在、ワークフローにビジネスロジックをハードコードしている場合、これは最も ROI の高い改善プロジェクトの 1 つとなるでしょう。

ぜひお試しください。未来のあなた (そしてあなたのフローの変更を待っているビジネスユーザー) は感謝するでしょう。