システム・エンジニアは、いかにして、業務を記述できるのか。

　業務を記述する作図作法 （ＤＦＤやＥＲ手法やＵＭＬ） を知っていても、業務を記述できる訳ではない。業務を記述するためには、当然ながら、「反・コンピュータ的断章」のなかで、先に述べてきた （会計学・生産管理・経営学・マーケティングなどの） 「通論」の体系および基礎知識を習得していることが前提である。そういう知識がないというのは、論外である。

　「通論」の知識を習得していたとしても、業務を記述することは、きわめて、むずかしい。そのむずかしさを理解してもらうために、以下の事態を例にする。

　（１） 受注形態には、以下の２つがある。
　　　　- ウェッブ上の受注
　　　　- ウェッブを使っていない受注 （電話受付、郵便受付や訪問セールスなど）
　　　　ウェッブ以外の受注を、以下の記述のなかでは、「通常受注」ということにする。
　（２） 通常受注は、商品を出荷したあとで、請求する。
　　　　ウェッブ受注は、画面上、クレジット・カードを使った決済とする。

　さて、受注と請求に関する業務を記述する際、以下のいずれの「構造」が正しいのか。

　（１） 受注には、通常受注とウェッブ受注の２つの形態がある。
　　　　それらに対応して、請求には、出荷後代金回収と入金確認後出荷がある。
　（２） 事業として、通常受注とウェッブ受注は、べつべつの事業形態である。

　以上のいずれの考え方が「現状」を示しているのか、ということを、或るエンドユーザに訊いたら、「受注は事業として１つであり、通常受注やウェッブ受注は、受注手段の違いに過ぎない。ウェッブは、電話や郵便や訪問と同列の手段である。」という返事であった。しかし、他のエンドユーザは、それとは違う意見を述べた--「ウェッブは、新しいビジネス・メソッドとして考えている。したがって、通常受注と切り離して、ウェッブ受注を考えている。」

　以上の２つの意見では、業務の「構造」は違っている。はたして、いずれが「正しい」のか （あるいは、現状の事業形態なのか）。いずれが「正しい」という判断を、だれが下すのか（営業部長か、取締役常務か）。いずれかを選ばなければ、業務を記述することはできないし、データ構造を作ることはできない。

　かりに、営業部長が、「ウェッブは、通常受注と切り離して、１つのビジネス・メソッドとして考えている」と判断した、としよう。そして、その意見を前提にして、ＤＦＤを使って業務を記述した、とする （「通常受注--->出荷後代金回収」と「ウェッブ受注--->入金確認後、出荷」を、べつべつの事業として、記述した、とする）。 　しかし、ウェッブから入力された受注データは、大型汎用機のほうに移送されて、通常受注のフォーマットと同じレコード形式に変換されていた、とする。

　さて、システム再構築プロジェクトが設置された際、「システム再構築の目的」のなかには、ウェッブを１つのビジネス・メソッドとして扱うとは明示されていなかった、とする。それでも、営業部長の意見は、「システム再構築の目的」の１つとして扱っても良いのかどうか。

　しかも、事業のなかで実地に使われているデータを確認したら、通常受注のなかで、受注形態区分コードが使われていて、受注形態区分コードの１つとして、ウェッブが記述されていた、としよう。とすれば、ウェッブは、受注手段の１つとして考えられていて、通常受注とは切り離したビジネス・メソッドとして考えられてはいないので、受注に対する考え方が矛盾していることになる。

　さて、ユーザのあいだですら意見が一致していない事業の体系を、ユーザを代表する数人を相手にして聴取しながら記述して、さらに、その事業記述と現状のデータ項目のすべてを照らして、データ構造やプログラム構成を考えることが、ほんとうに、効果的・効率的な やりかた なのか、、、、[ 否 ]。

　たとえば、前述の例では、事業のなかで実地に使われているデータを観れば、ウェッブは、受注形態区分コードの１つとして扱われていることが明示されているので、逆に、ユーザに対して、以下のように「確認すればよい」。

　　　ウェッブは、今後も、受注手段の１つで良いですか。
　　　通常受注とは切り離して、１つのビジネス・メソッドとして考えなくても良いですか。

　そして、「システム再構築の目的」のなかに、「ウェッブを新しいビジネス・メソッドとして扱う」という明示がされていないかぎり--言い換えれば、ユーザのあいだで「合意」が成立していないかぎり--、現状のまま、ウェッブは受注手段の１つとして扱うほうが良い。ただし、ウェッブを、通常受注と切り離して扱うことができることを、ユーザに示唆 （確認） したほうがよい。
　この やりかた のほうが、（業務そのものを対象にして、業務の構成図を作成しながら、業務を理解することに比べたら） 効果的・効率的である。
　データを読むというのは、現実の事業を理解することである。そして、事業実態のなかに潜んでいる潜在的な問題点を感知するために、「通論」の知識が役立つ。

　事業を記述するモデル作法に対して興味を抱いているＳＥの多くが、「通論」の知識さえないことを小生は観ていて、愕然とする。いったい、彼らは、ほんとうに、事業実態を理解して、問題点を感知できるのかどうか、、、。

　
　（2004年5月9日）