静的業務と動的業務


 現状分析の作業は一般的に「業務棚卸」から始まる。

整理された業務をさらに細分化して「処理」を明確化し、問題点を浮き彫りにする。

それを基に、システム化構想を固めていく。

「業務」→「処理」→「機能」と詳細を決定していく。

 具体的に「総務部の業務」を見てみよう。

全体を大きく分けると、

人事管理(採用・自己目標・評価・昇格・昇給・研修・異動・退職)

給与計算(給与支給・賞与支給・年末調整・標準月額改定・申告)

福利厚生(保険・赴任・社宅・慶弔・財形・健康診断)

労務管理(制服・災害補償・各種証明・勤怠・通勤交通費・出向)

等の「業務」に分類される。

さらに「給与支給業務」は基本データ作成/変動データ作成/支給額算出/給与支給明細書作成/振込データ作成/経理伝票作成等の「処理」に分類される。

さらに「変動データ作成処理」は、登録/変更/削除/照会/一覧等の「機能」に分類され、ここからプログラム作成に進む。

並行して、プログラムを操作する「メニュー」が作成されていく。

出来上ってくる「メニュー」は階層化された内容をそのまま表示しているのがほとんどである。

 ユーザーは、その時の「事象」「条件」によって自ら判断して「メニュー」を選択して処理をする。

こうなると、ベテランと若手に大きな「差」が出てくる。

現実の仕事は上記のような階層化された「処理」「機能」を順番にやっていないのである。

何が足りないのか?

 具体的に現実の「新入社員受入処理」を見てみよう。

入社式前後に行われる作業はというと、

 新入社員登録/顔写真取込/住所登録/所属発令/保険手続/基本給・手当登録/家族登録/通勤経路登録/振込口座登録/制服貸与 等 になる。

 これらは「採用/異動/給与支給/保険/社宅/通勤交通費」業務等の「処理」を横断的に行っていることが分かる。

この処理方法は、明らかに階層的ではない。

もうひとつ例を挙げよう。

家族情報に関する処理も、登録/変更/削除/照会/一覧の機能に分類される。

これを現実の事象と対応させると

 

「登録」-本人が結婚した/出生した/扶養家族が増えた

「変更」-家族が改名した/扶養しなくなった

     扶養者の住所・学校の変更/障害者登録

     別居・同居/家族の死亡

「削除」-家族が結婚した/本人が離婚した/扶養親族が減った

 

となる。

 

「登録/変更/削除/照会/一覧」を「メニュー化」するより実際に発生する「事象」を「メニュー化」した方が 直感的に分かりやすいのは明らかである。

階層的に表現された業務は「静的業務」である。

現実的な事象に基づく処理の一群は「動的業務」である。(筆者の造語)

「静的業務」はシステムの考え方を整理または理解する時に必要とされる表現方法である。

このまま「メニュー」に適応できるのは「コード・テーブル登録」ぐらいである。

「静的業務」をそのまま移し変えた「メニュー」は、当然作り手(SE)にはよく分かる内容であるが、ユーザーにとっては使いにくいものになる。

「メニュー」はあくまで「ユーザー」のものであって「SE」が勝手に作ってはいけない。

「プログラムの機能に関する打合せ」ばかりしているSEが多すぎる。

反対に「打合せなくして作られたメニュー」は本当の本番(SEが横にいない)ではじめてユーザーの面前に現れ「ドエライ目」に遭う。

「何だ?コリャ~?」

「話が違うじゃないか!」

いよいよ狂争曲第一番「トラブル(序曲)」の演奏開始である。

 実はこの「メニュー体系」がユーザーの「システム評価」を大きく左右する最も重要な代物でなのである。

 

「メニュー構築論」「動的業務」にもっと目を向けて欲しいのである。