» 【第13号】業務アプリケーションプログラム

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第13号】業務アプリケーションプログラム

DRI通信13号 「業務アプリケーションプログラム」 1997.10.1
9月の海は温かく静かで遠泳を楽しむのには絶好なのですが、今年は台風や長雨
で週末はいつも天気が悪く、寒さも早めに来てしまいました。今年の9月はやや
欲求不満のまま過ぎていきましたが、皆様はいかがですか。
今回はDOAとOOAについて考察する予定でしたが、ややボリュームが多くな
るので、その前段として、業務アプリケーションプログラムとはなにか、なぜ必
要なのか、について考えてみたいと思います。
アプリケーションプログラムというと、マイクロソフトでは、WORD、EXCEL、
ACCESSなどをいうことになりますので、受注処理プログラム、生産管理プログ
ラムなどと区別するために業務アプリケーションプログラム(以下業務AP)と
いう言葉を使うことにしました。
WORDなどは、対象業務を特定しません。販売、生産などの業務にはもちろん、
単なる個人の私信にも使われます。これをプラットフォームアプリケーションプ
ログラム(以下PFAP)ということにします。PFAPは処理の形式を規定す
るだけで、意味を規定しません。
一方業務APは、受注など、業務を特定し、扱うデータを分析すると、受注番
号、顧客名、品名、受注数量などが特定されてきます。業務APは処理の形式と
ともに、その意味を規定しています。これを「セマンティックスを内蔵する」と
表現してもよいでしょう。


ここですでに私の言いたい事が分かったと言う人があるでしょう。アプリケーシ
ョンプログラムと言っても「セマンティックスを内蔵するもの」とそうでないも
のとでは、作り方がまったく違う。前者にはDOAが決め手になる。しかもセマ
ンティックスはデータとして表現できる。これを100%実現すれば、処理の形
式はPFAPとして規定できるので業務APはなくなり、プログラムレスが実現
できる。だからOOAはPFAP側には残っても、業務APには不要なのではな
いか。逆に「セマンティックスはデータだけでは表現されない。どうしても業務
APとしてプログラムが残る」との思い込みから、業務APへのOOAが追及さ
れているのではないか(OOAシンパからの反論を期待した仮説)。
いまつぎのようなレコードがあったとする。
 [社員#]ー(社員名、性別、生年月日、所属部署c)
 [受注#]ー(顧客#、品#、@、受注日、数量)
これをアウトプットするとき、各々に対してプログラムを用意する必要があるで
しょうか。
かつての技法では2種類のプログラムを用意するのがあたりまえと考えられまし
た。しかし、リポジトリを用意し、個々のデータ項目について、長さ、フォーマ
ットなどを管理するようにすれば、凝った形式でないかぎり、汎用のアウトプッ
トプログラム(レポートライターと呼ばれるPFAP)を用意することよってア
ウトプットが得られます。
これは最も単純な、リスト形式だったわけですが、たとえば
 [受注#]ー(顧客#、(顧客名)、受注日)
 [受注#.行#]ー(品#、(品名)、@、数量)
のようになっていても、(顧客名)は顧客#(一つ前のRKEY)を用いて結合
するものと解釈し、そのアウトプットの仕様が、ヘッダー明細形式であることさ
え記述してやれば、レポートライターとして処理することができます。
アウトプットには、このほか代表的なものとしてマトリックス型などがあるわけ
ですが、要するにアウトプットの形式をいくつかにパターン化し、データ項目の
仕様をデータとして記述できればアウトプットプログラムはPFAP化できるこ
とになります。イスラエルのCASEツールSapiensはこの方式をとっているもの
と思われます。
データ項目の仕様は、加工データやサブタイプが繁雑ですが十分可能です。
むしろアウトプットはユーザ要求であるため、特に日本のものには凝ったものが
あり厄介です。これはやや趣味に近いので、EUCの領域としてしまえば、例外
を除きPFAP化できそうに見えるのですがいかがでしょうか。
インプットは、アウトプットよりはよほど簡単です。情報要求ではありませんか
ら、一般に、正規化されたレコード(エンティティ)ごとの扱いとすることがで
きます。加工データ、チェックデータ、サブタイプの仕様はデータ定義として記
述できますから、新規登録、変更、削除のPFAPを作れば、業務APは不要と
なるはづです。
処理にはインプット、アウトプットのほかに、加工があります。加工は給与、所
得税、年末調整金額など加工データ対応の処理が一般的です。給与は残業時間の
からむ一般社員給与と管理者手当のからむ管理職給与とを、サブタイプにわけた
処理として記述したくなるかもしれません。ただしデータ項目としては給与とし
て一つのものとしないと、今度は所得税のロジックの方が面倒になります。
加工の中には、PFAP化できるものがあります。たとえば
 [支店c、品#、年月]ー(<売上¥>)
   ↓
 [出荷#]ー(支店c、届先c、出荷年月日、品#、数量、@、<出荷¥>)
における、<売上¥>のようなデータは、これを要約データ(データ機能コード
NNS)と規定し、加工元データとして<出荷¥>を、また要約のRKEYとし
て出荷ファイルの支店c、品#、出荷年月を指定すれば、PFAPとしてこれを
処理することができます。在庫データやコピーのデータも同様です。
こうして見るとPFAP化できないのは、一般の加工データプログラムと特殊な
アウトプットプログラムとになります。加工データは、そのほとんどがデータ定
義の形式(最悪SPFチャート)で記述できますので、データ管理者による一元
管理が可能になります。プログラム仕様書としてしまいこまれ、ブラックボック
ス化する心配がなくなるわけです。このような加工処理記述は、データ定義とも、
またプログラムとも言えるもので、ちょうど光が波とも、また粒子とも言えるの
とよく似ています。
同じような、業務アプリケーションでも、会社によってIOの種類の数が多い場
合と少ない場合があります。数が多い方が良いのでしょうか。ユーザの要求にき
め細かく対応した結果かもしれませんが、車や洋服と違ってファッションではあ
りません。よりよい生産性を追及し創造的に取り組んで、高いモラールを生み出
しているいるのかもしれないし、単なる無統制で無駄な遊びをしているのかもし
れません。アウトプットプログラムのPFAP化がどこまで可能かはもう少し先
に行って判断した方がよいように思われます。
私は業務APをデータ定義とPFAPに分解してプログラムレスを実現するのが
DOAの一つのねらいだと思っています(もう一つは次回)。これはさきに戸田
先生が、「工作機械をNC旋盤とNCテープに分解する」と解説されたのと同じ
だと思います。
  
                               椿 正明
追伸
1)本文中PLAN−DBの用語や記法を使っています。説明を始めると長くな
るので省略しました。正確な定義は、コマーシャルですみません、「概念データ
モデル」(椿正明著、オーム社)をご覧ください。
2)このDRI通信は、1996年10月以来毎月1回発信しております。EMAIL
アドレスを頂いた方にとりあえず送信しておりますが、ご不要の方は遠慮なく
ご連絡ください。すぐにストップいたします。またバックナンバーの欲しい方も
お申し出ください。すこし時間をいただくかもしれませんが、送信いたします。