HOME    BRMSブログ  No.11 Corticonで有給休暇日数を求めてみよう【前編】

BRMS徹底活用ブログ

No.11 Corticonで有給休暇日数を求めてみよう【前編】

2017.02.02 Progress Corticon

本エントリーは株式会社アシスト様が寄稿したエントリー(https://www.ashisuto.co.jp/product/category/brms/progress_corticon/column/detail/brmstech11.html)を転載したものとなります。

No.11 Corticonで有給休暇日数を求めてみよう

Corticonを使用してモデリング(ルール化)する場合、作り方は1パターンだけではありません。コラムを2回にわたって、1つのお題から、2つの方法でモデリングし、その途中過程と、ルール変更時の柔軟さと簡単さ等について、一緒にみていきましょう。

お題:従業員に付与する有給休暇日数を求めるルールを作成します。

有給休暇日数は、年齢と勤続年数によって異なり、その規定はつぎのとおりです。
全ての従業員に、最低22日間の有給休暇があります。さらにつぎの条件で特別休暇を加算します。

1)18歳未満または60歳以上の従業員、または勤続30年以上の従業員は、5日間の休暇を加算します。
2)勤続30年以上の従業員、および、60歳以上の従業員には、他の休暇に加えて、さらに3日間の休暇を加算します。
3)勤続年数が15年以上30年未満の従業員の場合、2日間の休暇を追加します。この2日間は、45歳以上の従業員にもまた付  与されます。この2日間の加算は、1)の条件と組み合わせることはできません。

有給休暇算出ルール = 方法1 =

1つ目の方法

お題にある条件では、従業員の年齢と勤続年数で休暇日数が決まるため、Corticonでは、それぞれの条件をつぎのように、1つのデシジョンテーブル(ルールシート)で表せます。

画像1

詳細について

業務要件をモデル化する(ルールとして書く)前に、各要件についてルールの意図を明確にすることが重要です。既にお気づきかもしれませんが、本来ルールとしたいことが、規定集等に明確に書いてある通りとは限りません。
このあとの説明を読むと分かりますが、同じ要件であっても読み手によって解釈が異なることがあります。要件を文章で書くと、多くの場合、何かしら間違いが起こります。これを避けるために、最初からデシジョンテーブルを使用することをお勧めします。

では1つ1つみていきましょう。

1つ目の条件(ルール): 18歳未満または60歳以上の従業員、または勤続30年以上の従業員は、5日間の休暇を加算します。

条件だけを見るとつぎの2つのルールが考えられます。
さて、勤続30年以上で60才を超えている場合、60才以上で5日間追加し、更に、勤続30年以上で5日間を追加してよいのでしょうか?(下図の左側のルール)

画像2

ここでは、5日間の休暇の加算は1回だけと想定しました(上図の右側のルール)

2つ目の条件(ルール):勤続30年以上の従業員、および、60歳以上の従業員には、他の休暇に加えて、さらに3日間の休暇を加算します。

この条件(ルール)では、つぎの3つの組み合わせが考えられます。
勤続30年以上で3日間追加し、60歳以上で更にもう3日間追加するという意味でしょうか?
それとも、両方の条件を満たす場合に3日間を追加するという意味でしょうか?
または、いずれかの条件を満たす場合に3日間追加するという意味でしょうか?

画像3

ここでは、両方の条件を満たした場合の1回だけ、3日間を追加すると想定しました(上図の中央のルール)

3つ目の条件(ルール):勤続年数が15年以上30年未満の従業員の場合、2日間の休暇を追加します。この2日間は、45歳以上の従業員にもまた付与されます。この2日間の加算は、5日間の加算と組み合わせることはできません。

画像4

2日間の追加休暇を2回付与するのでしょうか?勤続年数に対する1回と、45歳以上に対する1回、この両方を追加してよいのでしょうか?
「~にもまた」はこのルールの重要な条件になります。
この「~にもまた」の部分が「かつ(AND)」であれば、2つの条件を持つ1つのルールになるところです。しかし、「~にもまた」書いてあることで、年齢と、勤続年数による2つのルールになります。
従業員には2種類の2日間の休暇を追加されます。ただし、5日間の休暇と併せて追加することはありません。従業員がこのルールにより2日間の追加休暇の資格があり、さらに、1つ目の条件(ルール)による5日間の追加休暇の資格がある場合、従業員は5日間と2日間のどちらを取得できるのでしょうか?ここでは、5日間を追加すると想定しました。

曖昧性チェック

曖昧性とはデシジョンテーブルに書いたルールとルールに矛盾があるかないかのことです。ここで、Corticonの機能を使って曖昧性をチェックしてみましょう。すると、Corticonが書いたルールに曖昧さがあることを検出します。従業員が2日間と5日間の両方を追加可能であることを曖昧性として検出し知らせます。
要件として、2日と5日の両方の休暇を許容する場合はこのルールを変更する必要はありません。

画像5

しかし、今回は、3つ目の条件(ルール)「これら追加の2日間は、追加の5日間と組み合わせることはできません。」を採用するため、これらの曖昧性を解決しなければなりません。Corticonではこの曖昧性を解決する、つぎの2つの方法があります。

1.曖昧なルールを明示的に上書き(オーバーライド)する方法

つぎの例では、1列目のルールは、4列目のルールを上書きしています。2列目のルールは4列目と5列目のルールを上書きしています。3列目のルールは5列目のルールを上書きしています。
Corticonでは、要件の詳細な条件の把握が困難な場面等に、この上書き(オーバーライド)を使った方法をしばしば使います。

画像6

2.ルールを正確に記述する方法

2つ目は多少手間がかかりますが、上の手法(オーバーライド)よりも、こちらの方法をお勧めします。
なぜならば、ルールの上書き(オーバーライド)よりも明確なルール/ロジックのほうが、後の確認が簡単だからです。
また、上書き(オーバーライド)はルール上のことでしかないため、デシジョンテーブルとして、この記述の方が適切です。

画像7

2 の方法で条件をさらに明確にすると、ルールはつぎのようになります。

画像8

ルールの矛盾を無くした後、もう一度、曖昧性チェックを行ってみます。すると、Corticonの曖昧性チェック機能は、2列目と4列目のルール列に潜在的な曖昧性があることを検出します。しかし、今回は、3日間の追加休暇は5日間の追加休暇と一緒の組み合わせ可能という要件のため、ルールに問題はないためこのままとします。

画像9

完全性チェック

完全性チェックとは、デシジョンテーブルに定義したルールに抜けている条件がないかを確認することができる機能です。Corticonで完全性チェックを行うと、デシジョンテーブルに次の条件の組み合わせが抜けていることを検出します。

画像10

検出したルールは、ここまで記述したルールの元となった条件にも指定がないため、このルールは無視することが可能です。しかし、この条件を書くことで追加の日数は0であることを明示しておくと、誤解や誤判断を防ぐことができます。また、このルールによって追加の休暇がないことを明確にする従業員へのメッセージを生成することができます。適格性の有無を判断するルール作成時にはよく使われる方法です。
このルールが出力するメッセージとして、「勤続年数15年未満で、18~44歳の従業員には、追加の休暇はありません。」を設定します。

この条件は元々の要件に記載されていなかったものです。今回は、この条件の場合は加算休暇日数に0を設定しますが、実際の業務では、この完全性のチェックを行うことで、この条件に対して何らかのアクション(追加加算等)が必要であることに気が付くこともあります。

画像11

テストケースについて

お題の条件をすべて書き終えたらCorticonでは、Corticonのみでのルールのテストを行えます。
アプリケーションなどとの統合テスト前にルールの矛盾や誤解を排除することができるためテスト工程を短期間に確実に行うことができます。

今回のルールのテスト結果はつぎのようになります。
条件に必要な年齢と勤続年数の組み合わせを自由に設定してテストすることができます。

画像12

要件変更に対する柔軟さ

ルールの実行結果として求められていることが決まると、そのデシジョンをモデル化(ルールとして実装すること)はそれほど難しくはありません。時に、要件が変更になれば当然ルールにも変更が入ります。その場合でも、このCorticonのデシジョンモデルであれば簡単にそして確実に間違いなく変更を行えます。
たとえばつぎのような条件の変更があるとします。

1.18歳未満の基本休暇日数は15日で、60歳以上の基本休暇日数は25日です。
2.勤続年数が30年未満の18~45歳までの従業員には、4日間の追加休暇を付与します。
3.勤続年数が15年未満で45歳を超えている従業員には、1日間の追加休暇を付与します。
4.全ての追加の休暇を組み合わせて使用することが可能です。

画像13

この新しいルールでは、全員に追加の休暇が付与されます(完全性チェックを実行し、ルールの抜け漏れがないことを確認します)。

ここまで1つのお題について、Corticonを利用したデシジョンのモデル化をお話ししてきました。
今回のデシジョンテーブルはパソコンの1画面に収まる程度の条件数なので、見栄えは気にしなくてもよいですが、これが多数の条件を書いていくとExcelと同じように視認性が下がっていきます。
どの単位で1つのルールシートにするかは要件内容によって変わりますが、1つにまとめ過ぎず、複数のステップ=ルールシートに分けることも含めて、考えてみてください。

次回は、そのルールシートを分けるポイントについて、同じ題材を基に見ていきますのでご期待ください。

今回ご紹介したお題とそれに対するサンプルルールは、Progress社のMichael Parish 氏がDecision Management Community (https://dmcommunity.org/challenge/challenge-jan-2016/)に寄稿した内容をベースにしています。このコミュニティではデシジョンマネージメントに関する最新の動向を知ることができます。是非そちらもご覧ください。

著者紹介

毛井さん

株式会社アシスト 情報基盤事業部 製品統括部プログレス推進部

株式会社アシスト入社以来、5インチFDを使うソフトウェアやメイン
フレームの簡易開発言語の時代から現在のProgress Corticonまで、
製品の日本語化や技術サポート、研修などを行う。

download close

閉じる

[2月16日(木)]

「Progress Corticon」ハンズオンセミナー

詳細はこちら