業務システムの見える化
本ブログのタイトルは「dbSheetClient千夜一夜」ですが、dbSheetClientについて具体的な内容の紹介がほとんどないですね＾＾；
今回は、少しだけdbSheetClientの中身について触れたいと思います。
ちなみに、Excelのブログは、モカさんの「Excelコーヒーブレイク」
https://www.newcom07.jp/EXCEL-database/blog/excel_coffee_break/
SQLのブログは、シュウさんの「DB & SQL 技術ブログ」
https://www.dbsheetclient.jp/blog/
どちらのブログも技術情報満載です。開発者の皆さんには大変参考になると思います＾＾
ボタン
まずは、dbSheetClientの代表的機能である「ボタン」の紹介です。
「ボタン」は、1つ以上の「ボタン」で構成される「ボタンセット」という形で管理されます。
「ボタン」には「タスクセット」を割り付けられます。
「タスクセット」は、1つ以上の「タスク」（処理）で構成されています。
下記は、経費精算業務をdbSheetClientにてシステム化した初期画面です。
月初めに仮払いして月末までに発生した経費（交通費、車両費、営業雑費等）を月末に精算する業務です。
表示されている３つの「ボタン」は、次のような動作を行ないます。
仮払申請ボタン → 仮払いを申請する。（詳細は後述）
仮払精算ボタン → 仮払いを精算する。（仮払い精算対象がある場合のみ表示される）
操作手順書ボタン → 操作手順書を表示する。
「ボタン」には業務内容を簡潔に表す言葉を割り付けることができるのでユーザーが直感的に機能を選択できます。
また、必要なタイミングにしか表示させないように制御できるため、ユーザーの誤操作を予防します。
操作手順書も常時ボタンから参照できるため、初めて利用するユーザーも業務の流れを把握できます。
いわゆるノンプログラミングツールでは、このようにシステムに手順を組み込むことができないために、ユーザーが戸惑ったり、開発者がいつまでもユーザーフォローに忙殺されたりします。（経験者は語る＾＾；）
タスクセット
次にユーザーが仮払申請ボタンをクリックした時の動作について、ご説明します。
下記の設定画面では仮払申請ボタンに「1100:仮払申請」という「タスクセット」が割り付けられています。
「1100:仮払申請」というタスクセットの内容は下記の通りです。
ご覧にように、12個の「タスク」で構成されています。
※()内は「タスクタイプ」を表し、dbSheetClientには、100種類以上の「タスクタイプ」が用意されています。
1～2 → まだ精算が済んでいない申請がある場合、新しく申請ができなくする仕組みです。
3 → 仮払い金額を入力します。（初期値や上限値を予め設定しておくことも可）
4 → 申請の最終確認（「いいえ」の場合、申請をキャンセル）
5 → 申請レコードの主キーを設定
6～7 → 申請管理Noを採番（詳細は後述）
8～9 → 申請基本テーブル、経費明細テーブルにレコード追加
10 → 通知メールのタイトルを設定
11 → 通知メール送信（宛先は経理部担当者、CCに承認者）
12 → 一覧表を更新
上記のようにdbSheetClientの「タスクセット」では動作概要をパッと見て認識できる構造になっているため、開発者はもちろん開発者以外の方にもプロジェクトの継承が確実にできる仕組みになっています。
採番台帳機能
申請業務で一番重要なポイントは、申請1件1件に管理番号を採番することです。
管理番号はユニークであることが重要で、決して重複してはいけません。
また、組織によって独特の採番ルールがあったりします。
その採番ルールに適用できないと現状の業務を電子化する障害になったりします。
KS20-HB00001
KS21-SZ50001
例えば、上記のような管理Noの場合
「KS」後の2桁の数字は西暦の下2桁、申請日が毎年4月1日になると新しい年度に替わる。
「-」後の2文字は申請部署のイニシャルを表す。（販売部は「HB」、製造部は「SZ」等）
年度が切り替わると部署ごとにスタート番号がリセットされる（製造部は50001番から採番開始）
dbSheetClientは、このような要求に応えるための機能が充実しています。
プロジェクト変数「年度開始日」に本日日付の3ケ月前をセット
変数演算タスクにて、変数「部署イニシャル」に部署に応じた2桁の文字列をセット
いずれも、Excelと同じ関数式で設定できることも特筆すべき点です。
Excelの関数式がわかる人は、開発者としての力量を持っていることになるからです。
ワークフロー
申請業務システムを開発する上ではワークフロー部分のハードルが比較的高いです。
なぜワークフロー部分のハードルが高いか簡単に説明します。
まず、申請システム起動時に最初に表示される申請一覧で考えてみましょう。
担当者の場合は、過去に自分が申請したデータが表示されれば良いです。
課長の場合は、自分の申請データと課員の申請データも表示されなくてはなりません。
部長の場合は、自分の申請データと配下の課長の申請データとなります。
経理部（出金担当）の場合、全部署、全社員の申請データとなります。
このように、ログインしたユーザーの部署や役職によって表示するデータの切替が必要となります。
電子化前ではペーパーが回り、それが次の作業の引き金になっていましたが、電子化すると次の作業者にメール等で通知する必要も出てきます。
その通知先も今まで人が判断していましたが、システムに判断させなければなりません。
例えば、仮払申請の場合、申請ボタンが押されたら、経理部担当に通知しますが、CCで承認者にも通知する時、申請者によって承認者が変わります。
申請者が担当者の場合は、同じ部署の課長になります。
申請者が課長の場合は部長、部長の場合はCCを省略等です。
このように、ログインしたユーザーの部署や役職によって、あるいはプロセスによって通知先の切替が必要です。
その他、申請に不備があった場合に申請者に差戻したり、申請後は申請データを編集不可にしたりと様々なコントロールが必要となります。
dbSheetClientは、「条件分岐」や「変数演算」等の「タスクタイプ」を利用して、シンプルでフレキシブルなシステムを開発することができます。また、その処理内容も可視化されるため、改良や引継ぎが容易です。
ログインユーザーの役職が課長の場合の一覧表表示条件
ログインユーザーの役職によって承認者を変える。
申請承認後に「上書き」ボタンを非表示にすることによって編集不可とする。
完全なるシステム化
今回は紙面の関係でご紹介できませんでしたが、経費精算業務システムには、他にも機能を持たせることが可能です。
例えば、申請データから全銀協フォーマットに展開して社員の口座に振り込む作業を自動化する。
あるいは、精算完了した申請データから仕訳データに展開して基幹システムに取り込む等です。
もちろん、申請者の経費明細データ入力作業負荷を軽減する様々な工夫や証憑書類となる領収書ファイル保管管理も盛り込むことが可能です。
ノンプログラミングツールでは、あるレベルを超えるとシステム開発に限界が出てきます。
開発ツールの優劣が、川上から川下までの一貫した業務改善に大きく影響します。
さて、本来のdbSheetClientの強みは、Excelとの親和性です。それはまたの機会にご紹介いたします。
皆さん本日もお疲れ様でした！
おやすみなさい（挙手）
