anti-computer

Don't put the cart before the horse.

　
　論理設計に先立って、概念設計として、（システム化の対象となっている）業務を記述するのであれば、業務の記述図（アウトプット）は、網羅性を保証していなければならない。

　前回（５月１６日）、業務そのものを対象にして、粗い構造図を描くことが無意味であることを述べたが--仕事の最小単位とされている「task」自体の範囲をきめることがむずかしいので、いきおい、構造図は、作成した人の価値観が混入するから--、それでも、エンドユーザの仕事（の中身）を、どうしても知りたいのであれば、エンドユーザが「作業日報」を作成すればよい。
　作業日報とは、エンドユーザ１人１人につき、（１週間を単位にして、）３週間ほど、実際にやった仕事および実際の労働時間を記述してもらうレポートである。作業日報の形式は、以下のとおり。

仕事	月	火	水	木	金	土	日	合計
受注伝票作成	３		２	・・				５
：	：							：
合計	８							３０

　

　作業日報になかに記述された労働時間に対して、縦計と横計を計算する。作業日報には、１週間単位の労働時間合計が記述される。したがって、作業日報を、３枚、記述するなら、３週間の労働時間を基礎にして、平均労働時間を計算すればよい。

　記述から漏れた仕事がなかったどうか、という点は、標準労働時間（たとえば、４０時間/週）と実際労働時間を対比すればよい。たとえば、前述した例では、実際労働時間が３０時間/週であるから、比率は７０％になる [ ３０ ÷ ４０＝７０％ ]。
　この比率が７０％以下であれば、記入漏れがあると推測できる。いくつかの実例から判断すれば、比率は、たいがい、８０％前後になる--実際の労働時間のなかで、会議のために移動していたとか、新聞を読んでいたとか、タバコを吸っていたとか、コーヒーを飲みながら仕事仲間と世間話をしていた、というようなことを作業日報のなかに記入しないので、８５％を越える比率になることは、まず、ない。

　比率が７０％を下回るようであれば、エンドユーザと再確認しなければならない。
　比率が７０％を越えていれば、まず、記入漏れがないので、作業日報のなかに、以下のように、「ＥＤＰ化」欄を追記して、コンピュータ化する仕事を検討すればよい--「ＥＤＰ化」欄のなかに、○ をした仕事がコンピュータ化の対象となる。

仕事	月	火	水	木	金	土	日	合計	EDP 化
受注伝票作成	３		２	・・				５	○
：	：							：
合計	８							３０

　

　作業日報の「仕事」欄のなかに記入される中身は、エンドユーザごとに、まとめかたが区々（まちまち）となる。粗いまとめかたもあれば、事細かな記述もある。しかし、まとめかたは、そもそも、統一できない--逆に言えば、そういうことを対象にしてＤＦＤなど作図できる訳がない。
　大切な点は、「記入漏れがない（網羅性が実現されている）」ということを検証する点である。それでも、業務の体系をまとめたい、というのであれば、「通論」の文献を参考にしながら、作業日報のなかに記述されている仕事を体系化すればよい--ただし、体系化の作業は、ゆうに、２ヶ月以上を費やす作業になることは覚悟したほうがいい（笑、そして苦笑）。

　以上に述べたように、現状の記述は、システム・エンジニアがやる仕事ではない。（責任もって仕事をしたことのない）システム・エンジニアが、エンドユーザから仕事の中身を聴取して的確に記述できる訳がない。前回（５月１６日）も述べたが、実地の仕事が的確に記述されていれば、形式的体系の上位階層は、概念のまとめなのだから、もし、どうしても、事業の体系化をしたいというのであれば、（エンドユーザが作成した作業日報を基礎資料にして、）概念のまとめをシステム・エンジニアがやればよい。ただし、小生は、そんな作業は無意味だと思っている。
　なぜなら、近代の事業経営は、事前報告（計画）・経過報告・事後報告という管理過程のなかで、事業が統括されているので、報告（情報）を観れば、事業の中身を判断することができるから。業務分析をやりたがるＳＥは、自らが事業に関する知識がないので、業務の流れを記述しながら、事業に関する知識を得ようとしているのか--そんなことは、馬の前に馬車をつなぐような愚考であって、事業の知識がなければ、事業の体系化など、できる訳がないのだが--それとも、事業を、まったく、最初からやり直そうとでも考えているのか、、、（謎）。

　
　（2004年5月24日）

▼ このウインドウを閉じる