より良い事務データ処理にする
この記事を読んでいただきたい方
* Excel で事務データ処理を行っている人
* 事務データ処理の手順を開発している人
* 事務データ処理のための基幹システムの責任者
* 事務データ処理のための基幹システムを開発している人
* ALZETA でのデータ処理に興味を持っている人
前回はガソリン会員割引額の計算を例に，ALZETA で JOB を作成して事務データ処理を行ってみました．前々月のデータと当月のデータを分けて処理していたり，割引単価を計算して当月データに結合する，という流れが視認でき，処理の内容が理解しやすいと思われますが，ALZETA で処理を作れば「フローで視覚的にわかりやすい」となるのは当然のことです．この JOB はもっと柔軟に運用できるように改善できます．それを見ていきましょう．
1. JOB はコピーしてから手を入れる
当たり前かもしれませんが，ALZETA の JOB は，いったん完成したものには手を加えず，コピーしてそれに手を加えることができます．あながち「当たり前」とも言えないのは，このようにデータを入力→処理→出力と動くプログラムを単にコピーして動かすと，「出力」が重なってしまい，完成して本番供用されているオリジナルプログラムの出力を壊してしまうケースがあるからです．ALZETA では，JOB にはそれぞれにデータ出力専用領域が自動的に設定されますので，コピーした JOB を実行しても，オリジナルには全く影響を与えません．
いずれにしても，まず JOB をコピーします．「JOB一覧」画面には，それぞれの JOB にコピーボタンが用意されており，任意の名前でコピーできます．
2. 割引単価設定を，データでコントロールする
現在の JOB で最も不満なのは，割引単価設定を「条件分類」PM で行っており，割引単価設定がこの「条件分類」PM の設定を開けてみるまでわからない（下図: 前回のものを再掲）ことです．
改善の方法は，「まずデータにする」です．以下のような簡単な Excel ファイル（割引単価設定テーブル.xlsx）を作成し，ALZETA にアップロードします．
そのデータを使用して，JOB を以下のように変更します（赤枠部が手を入れた部分です）．
(1) と (2) は前々月売上データに割引単価設定テーブルを結合するために，ダミー項目を追加しています．
(3) でその結合を行なっていますが，(3) の出力はどのようになっているか，中間ファイルプレビューで見てみると，「前々月利用額下限（以上） 」「前々月利用額上限（未満）」「割引単価」のフィールドが追加されるとともに，前々月売上１レコードにつき５レコードが生成されています（例えば，赤波線枠部分をご覧ください）．
次に (4) で，「売上金額」が「前々月利用額下限（以上） 」以上で，「前々月利用額上限（未満）」のレコードだけ抽出しています（例えば，上図で赤波線枠部分５レコードから，条件に一致する赤実線枠の１レコードだけを抽出しています）．
(5) では，不要なフィールドを削除し，オリジナルの JOB と同じく「顧客番号」「売上金額」「割引単価」の３フィールドだけを選択しています．
(5) の出力はオリジナル JOB の「条件分類」PM の出力と全く同じになりますので，この JOB 全体を実行すると，オリジナル JOB と同じ結果が得られます．オリジナル JOB よりもステップが増えて形も複雑な JOB になってしまいましたが，この改良版が優れているのは，割引単価設定を変更したいときには JOB を一切変更せず「割引単価設定テーブル」データの内容を変更するだけで良いということです．したがって，JOB の作成者／保守者が不在でも，割引単価設定を変更することが可能で，これはビジネスルールのアジリティ向上に大いに貢献するはずです．
3. コントロールデータは，保存しておく
アジリティの向上は結構ですが，今度はこの計算を行うたびに，どの割引単価設定を適用したのかわからなくなって不安になったりしないでしょうか？答えは簡単で，JOB 実行のたびに，割引単価設定テーブルもそのまま出力してしまえば良いのです．具体的には，下の図の通り「CSV出力」を「割引単価設定テーブル」に直結します．
こうして JOB を実行すると，「顧客別割引金額.csv」とともに「割引率単価設定テーブル.csv」が同時に（ALZETA サーバー上で同じディレクトリ上に）出力されますので，どのコントロールデータによってどの結果を得たかは自動的に記録されることになります．
4. 株主優待ルールを追加する
石油元売A社では，株主施策として，割引金額計算に株主優待ルールを採用することにしました．株主優待ルールでは，前々月の利用額によらず以下の割引を適用し，適用給油量制限はありません．
* ハイオク: リッター 8円
* レギュラー: リッター 7円
* 軽油: リッター 5円
株主の顧客番号は「株主顧客番号」データで与えられます．以下の通り，株主である顧客の顧客番号１項目から成るデータです．
株主優待ルールを追加した JOB の全体像は下図になりました．
赤枠内が株主優待ルールの則った割引金額計算部です．
(1) は前述「株主顧客番号」データです．
(2) が実はこのフロー追加部で最も重要な部分です．「当月売上」と「株主顧客番号」を内部結合しているのですが，これにより「当月売上」から株主顧客のレコードだけが抽出されます．以下のフローでは単に抽出されたレコードに対して所定の計算をしているだけです．これを「内部結合による処理対象の特定」と称します．
(3) では，二つのグループ項目 #1:「顧客番号」，#2:「品目」によって「数量」を集計しています．「品目」の要素が必要なのは，株主優待割引では，割引単価が油種によって違ってくるからです．
(4) では，今度は油種によって割引単価を定めるデータを用意しています．内容は，以下の通りです．
(5) で，このデータを (3) までで計算してきた顧客／品目別数量（給油量）データと結合します．ここで得られるデータは以下の通りです．
あとは
(6) で「数量」と「割引単価」を乗算
(7) で「顧客番号」「品目」の二つの項目によって集計されているデータを，「顧客番号」のみによって再集計
(8) で「備考」欄を新設しています．「演算」PM を使っていますが，実は何も演算などしておらず，"1_株主優待適用" という固定の文字列を入れています．
これに対し，(9) ではオリジナルの通常割引のデータに同じく「備考」欄を新設し，こちらは "9_通常割引適用" としています．（この "1_..."，"9_..." という内容が少しミソです）
(10) は「縦連結」PM で，複数のデータを単に縦に繋げます．複数データ間の共通項目は同じ項目として収容されますが，互いに存在しない項目については，ブランク値を表す "_" で埋められます．
次の (11) は「顧客番号」→「備考」という優先順位で項目を指定してソートを行なっていますが，この出力（下図）を見ると (10) の内容もよくおわかりいただけるかと思います．
同じ顧客番号 "00037707" についてレコードが二つあり，一つは株主優待，もう一つは通常割引による計算結果です．株主優待の方の「数量」〜「割引単価」がブランク値になっています．
さて，事務処理としては同じ顧客に対して割引が２パターンあっては困ります．ここではより優先されるべき株主優待を選択しますが，このために (12) 「先頭レコード」があります．(12) の設定内容は以下のようになっており，同じ「顧客番号」のレコードが連続していれば，最初に登場したものを採用する，というものです．
先のソートで，「顧客番号」→「備考」の優先順位でソートをしていますので，同じ顧客番号であれば「備考」の "1_株主優待適用" と "9_通常割引適用" があった場合，かならず "1_株主優待適用" の方が残ります．(12) の出力は以下の通りです．
実際のビジネスでは，こういった「特別ルール」は枚挙にいとまがありません．株主優待以外にも，「新規登録割引（３ヶ月）」「プロバイダ連携割引」「携帯連携割引」「xxx ペイ割引」… いろいろあります（最後の「xxx ペイ」については決済業社にお任せできると思いますが）．
通常のプログラムでこのような「特別ルール」の適用を繰り返していくのには限界があります．しかし，今見てきたように ALZETA の場合は，
1) 特別ルール対象を内部結合で切り出し
2) 特別ルールのロジックをつなげる
という公式で処理すれば，既存フローに影響なく処理が可能です．もう一つ大事なのは，「特別ルール」が廃止されれば，単に該当部分（先ほどの例ではフローの赤枠部分）をごっそり削除すれば良いということです．
通常のプログラムでは，「一旦機能追加したものを削除する」という行為はおそらく怖くてできないと思います．「最後に追加した機能」を削除するのは簡単ですが，たとえば「３年前に追加した機能」をその後に追加した機能を保持したまま削除する，ということはおそらくどのシステムでも行われていないと思います．こういうことが積み重なって，使用していない機能満載のスパゲッティコードが出来上がります．
まとめ
ALZETA での JOB の構造を工夫することにより，ガソリン会員割引の計算を，より柔軟にビジネス要請に応えられるよう作り替えることができました．
* 処理パラメーターの投入（割引率テーブルデータによる管理）
* 処理対象の特定（内部結合による処理対象（株主会員）の特定）
ということを通じて「データでデータ処理をコントロールするということ」をご理解いただけたと思います．特に，後者については，通常のプログラムでは IF-THEN ルール等を用いて間接的に処理対象を特定することが多いと思います．そのため，その特定操作そのものにバグや想定外の動きを生じがちですが，データを使用して直接処理対象を特定すれば，その不安がありません．また「処理対象を特定するデータの所轄部門」「特定されたデータに対する処理の所轄部門」というように，部門の責任範囲を明らかにする効果もあります．
次回は，この事務データ処理を経営企画にフィードバックしてみます．