ＤＲＩ通信１３号 「業務アプリケーションプログラム」 １９９７．１０．１
９月の海は温かく静かで遠泳を楽しむのには絶好なのですが、今年は台風や長雨
で週末はいつも天気が悪く、寒さも早めに来てしまいました。今年の９月はやや
欲求不満のまま過ぎていきましたが、皆様はいかがですか。
今回はＤＯＡとＯＯＡについて考察する予定でしたが、ややボリュームが多くな
るので、その前段として、業務アプリケーションプログラムとはなにか、なぜ必
要なのか、について考えてみたいと思います。
アプリケーションプログラムというと、マイクロソフトでは、WORD、EXCEL、
ACCESSなどをいうことになりますので、受注処理プログラム、生産管理プログ
ラムなどと区別するために業務アプリケーションプログラム（以下業務ＡＰ）と
いう言葉を使うことにしました。
WORDなどは、対象業務を特定しません。販売、生産などの業務にはもちろん、
単なる個人の私信にも使われます。これをプラットフォームアプリケーションプ
ログラム（以下ＰＦＡＰ）ということにします。ＰＦＡＰは処理の形式を規定す
るだけで、意味を規定しません。
一方業務ＡＰは、受注など、業務を特定し、扱うデータを分析すると、受注番
号、顧客名、品名、受注数量などが特定されてきます。業務ＡＰは処理の形式と
ともに、その意味を規定しています。これを「セマンティックスを内蔵する」と
表現してもよいでしょう。
ここですでに私の言いたい事が分かったと言う人があるでしょう。アプリケーシ
ョンプログラムと言っても「セマンティックスを内蔵するもの」とそうでないも
のとでは、作り方がまったく違う。前者にはＤＯＡが決め手になる。しかもセマ
ンティックスはデータとして表現できる。これを１００％実現すれば、処理の形
式はＰＦＡＰとして規定できるので業務ＡＰはなくなり、プログラムレスが実現
できる。だからＯＯＡはＰＦＡＰ側には残っても、業務ＡＰには不要なのではな
いか。逆に「セマンティックスはデータだけでは表現されない。どうしても業務
ＡＰとしてプログラムが残る」との思い込みから、業務ＡＰへのＯＯＡが追及さ
れているのではないか（ＯＯＡシンパからの反論を期待した仮説）。
いまつぎのようなレコードがあったとする。
［社員＃］ー（社員名、性別、生年月日、所属部署ｃ）
［受注＃］ー（顧客＃、品＃、＠、受注日、数量）
これをアウトプットするとき、各々に対してプログラムを用意する必要があるで
しょうか。
かつての技法では２種類のプログラムを用意するのがあたりまえと考えられまし
た。しかし、リポジトリを用意し、個々のデータ項目について、長さ、フォーマ
ットなどを管理するようにすれば、凝った形式でないかぎり、汎用のアウトプッ
トプログラム（レポートライターと呼ばれるＰＦＡＰ）を用意することよってア
ウトプットが得られます。
これは最も単純な、リスト形式だったわけですが、たとえば
［受注＃］ー（顧客＃、（顧客名）、受注日）
［受注＃．行＃］ー（品＃、（品名）、＠、数量）
のようになっていても、（顧客名）は顧客＃（一つ前のＲＫＥＹ）を用いて結合
するものと解釈し、そのアウトプットの仕様が、ヘッダー明細形式であることさ
え記述してやれば、レポートライターとして処理することができます。
アウトプットには、このほか代表的なものとしてマトリックス型などがあるわけ
ですが、要するにアウトプットの形式をいくつかにパターン化し、データ項目の
仕様をデータとして記述できればアウトプットプログラムはＰＦＡＰ化できるこ
とになります。イスラエルのＣＡＳＥツールSapiensはこの方式をとっているもの
と思われます。
データ項目の仕様は、加工データやサブタイプが繁雑ですが十分可能です。
むしろアウトプットはユーザ要求であるため、特に日本のものには凝ったものが
あり厄介です。これはやや趣味に近いので、ＥＵＣの領域としてしまえば、例外
を除きＰＦＡＰ化できそうに見えるのですがいかがでしょうか。
インプットは、アウトプットよりはよほど簡単です。情報要求ではありませんか
ら、一般に、正規化されたレコード（エンティティ）ごとの扱いとすることがで
きます。加工データ、チェックデータ、サブタイプの仕様はデータ定義として記
述できますから、新規登録、変更、削除のＰＦＡＰを作れば、業務ＡＰは不要と
なるはづです。
処理にはインプット、アウトプットのほかに、加工があります。加工は給与、所
得税、年末調整金額など加工データ対応の処理が一般的です。給与は残業時間の
からむ一般社員給与と管理者手当のからむ管理職給与とを、サブタイプにわけた
処理として記述したくなるかもしれません。ただしデータ項目としては給与とし
て一つのものとしないと、今度は所得税のロジックの方が面倒になります。
加工の中には、ＰＦＡＰ化できるものがあります。たとえば
［支店ｃ、品＃、年月］ー（＜売上￥＞）
↓
［出荷＃］ー（支店ｃ、届先ｃ、出荷年月日、品＃、数量、＠、＜出荷￥＞）
における、＜売上￥＞のようなデータは、これを要約データ（データ機能コード
ＮＮＳ）と規定し、加工元データとして＜出荷￥＞を、また要約のＲＫＥＹとし
て出荷ファイルの支店ｃ、品＃、出荷年月を指定すれば、ＰＦＡＰとしてこれを
処理することができます。在庫データやコピーのデータも同様です。
こうして見るとＰＦＡＰ化できないのは、一般の加工データプログラムと特殊な
アウトプットプログラムとになります。加工データは、そのほとんどがデータ定
義の形式（最悪ＳＰＦチャート）で記述できますので、データ管理者による一元
管理が可能になります。プログラム仕様書としてしまいこまれ、ブラックボック
ス化する心配がなくなるわけです。このような加工処理記述は、データ定義とも、
またプログラムとも言えるもので、ちょうど光が波とも、また粒子とも言えるの
とよく似ています。
同じような、業務アプリケーションでも、会社によってＩＯの種類の数が多い場
合と少ない場合があります。数が多い方が良いのでしょうか。ユーザの要求にき
め細かく対応した結果かもしれませんが、車や洋服と違ってファッションではあ
りません。よりよい生産性を追及し創造的に取り組んで、高いモラールを生み出
しているいるのかもしれないし、単なる無統制で無駄な遊びをしているのかもし
れません。アウトプットプログラムのＰＦＡＰ化がどこまで可能かはもう少し先
に行って判断した方がよいように思われます。
私は業務ＡＰをデータ定義とＰＦＡＰに分解してプログラムレスを実現するのが
ＤＯＡの一つのねらいだと思っています（もう一つは次回）。これはさきに戸田
先生が、「工作機械をＮＣ旋盤とＮＣテープに分解する」と解説されたのと同じ
だと思います。
椿 正明
追伸
１）本文中ＰＬＡＮ−ＤＢの用語や記法を使っています。説明を始めると長くな
るので省略しました。正確な定義は、コマーシャルですみません、「概念データ
モデル」（椿正明著、オーム社）をご覧ください。
２）このＤＲＩ通信は、１９９６年１０月以来毎月１回発信しております。ＥＭＡＩＬ
アドレスを頂いた方にとりあえず送信しておりますが、ご不要の方は遠慮なく
ご連絡ください。すぐにストップいたします。またバックナンバーの欲しい方も
お申し出ください。すこし時間をいただくかもしれませんが、送信いたします。
« 【第12号】ＤＯＡとＥＲＰ【第14号】ＤＯＡとＯＯＡ »
