なのにwebサービス、SOAP関係の本って、やたらむずかしく書いてませんか？

　前のブログで、SOAとかwebサービスとか書いたので、ちょっと自分でもやってみようと思って、Laox　コンピューター館の３階にいってみて、本を見てみたのですが、うーん、やたらに難しく書いてないか？それも、書き方が、同じなのだ！

　まず、SOAPエンベロープとその中身、WSDL、UDDIの説明をえんえんと、難しく書いていて、さあプログラム！というところで、書いてなかったり、お茶を濁す程度にしか、載ってない。。。

　なんか、やったらむずかしく、書いてある気がする。

---

　だって、ですよ、たとえば、インターネットを見る場合、インターネットエクスプローラーを使いますが、だからって、

　じゃあ、インターネットエクスプローラーで、なんのデータが流れているか、ながめてみてみましょう！

とかいって、HTTPプロトコルの中身

　　GET / HTTP1.0

　とか、そういうものを書いてある本って、あんまり無いと思うんですよね。

　だけど、ＳＯＡＰの本って、
　じゃあ、中身が、なにが流れているか、みてみましょう！
　って、SOAPエンベロープの中身が延々と書いてあったりする。

---

　JAVAで、ＳＯＡＰを使う場合、結局、そのへんは、javaのクラスで隠蔽されているので、知る必要は無い。っていうことは、知らなきゃいけない情報は、結局、
（１）サーバー側インストール
（２）クライアント側のインストール
　　　eclipseの場合、プロジェクトを作ったときの設定（ビルドパス設定等）
（３）サーバーとクライアントのプログラムの書き方
（４）クラスを置く場所
（５）デプロイ方法
ということになると思う。
（あと、パブリッシュという作業も、やろうと思うと必要になるらしい）

　なので、まず、その作業の流れとサンプルプログラムを提示し、それを説明した後で、ＷＳＤＬとかＵＤＤＩについて、必要な部分だけ、説明してくれればいいのに。。。そういう本は、みあたらなかった。。。

---

　その一方で、デプロイの部分について、apache SOAPを使った場合の詳しい説明が無かった。

　たとえば、JAVAでHello World SOAP編のように、帰り値が、Stringならいいんだけど、これが、自分で定義したクラスなどの場合、apache SOAPのadminのページで、下のほうも設定しないといけない（すみません、いま、出先で、どこを設定しないといけないのか、資料がないので、あとで修正します）んだけど、その設定方法については、書いていない。


ってことで、結局、どの本も、買ってこなかったぞ。

---

　最近は、axisを使うからかな。。。いやいや、そうではあるまい！
　なんか、最近の本って、難しく書きすぎているか、萌え本にするかで、やり方だけを、ストレートに書いている本が少なくなってきている気がするぞ。
　これも、出版事情？

　そのうち、ＳＯＡＰも、萌え本がでてきて、きっと、その初めのほうのページに、「ＳＯＡＰって、石鹸？」というオチが載るのであろう（コンパイラ関係をやっていた場合、「ＬＲって、歌手？」っていう、オチと同様）

webサービスをJavaで行いたい場合って、結局、これでいいんだねえ、きっと？

　WEBサービスを行いたい場合、Apache SOAPを使って、ＪＡＶＡでプログラムを組むとしたら、結局、これでいいんだよねえ？っていうやり方、書いておきます。
　なんで、これを書いたのかは、次（今日中か明日になるかわかんないけど）のブログで書きます。

以下、説明です

---

(Apache)SOAPをJavaで行う手順

（１）ダウンロードして、適当なところにコピーする

SOAPのダウンロード
　　　　WebServices - SOAPのホームページの（左側にある）Downloadをクリックすると、ミラー先が出てくるので、テキトーに選ぶ（私は明星大学のものにした）。
　　　soap-bin-2.3.1.zipをダウンロードして解凍すると、soap-2_3_1の下、webappsの下にsoap.warがあるので、これを、TOMCATのwebappsの下にコピーする

あとで、クライアント側で必要になるので、JAFとJavaMailもダウンロードしておく
　　　JavaMailは、ここ解凍したフォルダの中にあるjavamail-1.3.1の下のmail.jarをとっておく

　 JAFは、こここのページの、下のほうにダウンロードボタンがある。
　　feel freeなんとかかんとか（レジスタレーションしないほう）とかいうのが書いてあるページがでてきたら（けっこう小さい字なので見落としやすいが）、そちらのほうをクリック、ダウンロードしたら解凍して、jaf-1.0.2の下のactivation.jarをとっておく

なお、Xercesも必要なはず。
　　ここにあるが私は、すでに他のプロジェクトで使っているので、クラスパスが通っているので、今回は入れなかった。
　　なお、クライアントに必要なことはたしかだが、サーバーに入るかどうかは不明。
　　TOMCATをインストールするとTOMCATのcommon\libにXerces.jarが入っているので、いらないかも。xalan.jarもいるって、書いてあるサイトがあるけど（ここ）いるかどうか不明。

（２）TOMCATを再起動

　ここで、soap.warが解凍され、Tomcatのwebapps\soap以下のフォルダができる。

（３）サーバー用のプログラムを作って、そのクラスをコピーする

　コピー先：Tomcatのwebapps\soap\WEB-INF\classesの下にコピーする

（４）TOMCATをまた再起動

（５）デプロイする

　　　http://localhost:8080/soap/admin/index.htmlでdeployをクリック
　　　IDと、 Methodsと 、Java Providerの Provider Classを設定する

（６）クライアント側のプログラムをつくる（soap.jarが必要）

　　　eclipseの場合、作る前に、
　　　　　ダウンロードしたzipファイルを解凍した
　　　　　フォルダの下にあるsoap-2_3_1\lib\soap.jarと、
　　　　　ダウンロードしてきたmail.jarとactivation.jarを
　　　　　プロジェクトのプロパティのJava Build Pathで、パスが見えるようにする
　　　eclipseでなければ、コンパイルのときに、soap.jarが参照できればいい

（７）実行する

　mail.jarとactivation.jarが参照できる必要がある。
　eclipseの場合は（６）で設定してあるが、それ以外は、クラスパス指定する必要あり。　　

COBOLからJAVAへの変換試案 No３ システム設計編

　今回の話は、あんまり、多くの人に関係ありません。
　というのは、ふつう、分析の際、論理的な業務で作ったクラスと、
　実装したjavaのクラスの対応関係が取れなかったとしても、
　そのことで、文句を言うユーザー、発注者は、ほとんどいないと思うんです。
　ある１事業体（会社と、あえて書かないところがみそ！）を除いて。。。

　ということで、今回は、（独創的な、創造的な、まだだれも踏み込んでないような(^^)v）ＣＯＢＯＬからＪａｖａ変換のプログラムを考えちゃって、その事業体からお金（売上と書かないところがみそ！）をもらっちゃったんだけど、検収する人が、うるさくて、「これ一致してないじゃん」！などといわれたときに、逃げる、逃げ口上を考えてみましたあ！

---

COBOLの１プログラムって、たとえば、「受注表作成」のような、業務手続１個分が、１本のプログラムになるケースが多いです。この業務手続は、メソッドにあたるのが普通です。

　そこで、これをそのまま、１クラスにしてしまうと、１メソッド１クラスとなるため、分析のとき作ったクラス図に合いません。

　「メソッドがなぜクラスになるの？」

　あの事業体から出向いてきた、検査官がつっこみそうなところです。
　（出向いて・・・「でむいて」と読んでね。「しゅっこう」とよむと、「あの事業体に！でしょ」っていう話になり、意味が変わる）

---

　実は、その現象、ほかでも起こります。

　それは、サーブレットを利用したとき（strutsも当然、含む）。
　たとえば、そういうのだと、画面のボタンを押されたら、サーバー側のあるクラスのdoPost,doGet（strutsだとexecute)にはいります。
　ここで、画面のボタンって、たいてい、「保存」とか、「終了」とかのメソッドです。
　その一方、画面の１まとまりがクラスになっていたりします。

　つまり、クラスにある、「保存」とかいうメソッドが、なぜ、サーバーにいくとクラスになるのか。。。おなじ現象です。

　「メソッドがなぜクラスになるの？」

　あの事業体から出向いてきた、検査官がつっこみそうなところです。

---

　で、この説明ですが、無理やりの説明をします。

　受注とか、発注っていうのは、クラスになっていると思います。
　でも、これらのクラスも、「商品」というクラスのメソッドにもできると思います。
　そこで、
　　「商品」というクラスのメソッドである「受注」がクラスとして独立できるなら
　　「受注」というクラスのメソッドである「受注表作成」がクラスとして独立
　することは可能だ！と主張します。
　言い切っちゃえば、こっちのモンです（なのかなあ？？）

---

　で、次に、クラスには、２つの側面があると主張してしまいます。
　それは、業務の意味的な側面（たとえば、受注とか発注とか）と、
　形式的な側面（クライアントの画面としてある、サーブレットとしてあるなど）がある
と主張してしまいましょう。
　継承には、この場合、意味的な側面を書く場合と、形式的な側面を書く場合、両方を継承させる場合(extendsとimplimentsを書く場合）があると主張します。

　サーブレットやstrutsのActionクラスの継承（ extends Action)は、この形式的な側面が記載されているとします。
　そうすると、COBOLでも、パターンを使っている場合、extends そのパターンクラスとなると思うけど、これは、形式的な側面が記載されているものだと言い切れます。

---

　ということで、この事業体から、仕事を受けても、言い逃れできそうです(^^;)
　（ほんとーかよ！）

　さあ、だれか、国のお金をつかって、COBOLからJava変換をやりましょう！
　そうすれば、２００７年問題、解消。。。するのかなあ？？
　
　といって、自分ではやらないウィリアムのいたずらなのでした

　（これにてCOBOLからJavaへの変換試案　完）

むしろインターネットが進むほど、テレビの良さが分かる（ホリエモンの言ってるのの逆？）

　昨日のブログで、３つの方法を挙げて、１つのクラス（あるいはプログラム）で、複数画面があるときの書き方を説明しましたが、この方法、実は、（放送局のように）サーバーからのデータをたれ流す場合にも同じことが言えます。

つまり、インターネットのWebを利用して、サーバーが情報を送りたいときに、クライアントにおくるには、以下の３つの手法が考えられます（以下の（１）、（２）、（３）は、昨日のブログの（１）、（２）、（３）に対応しています）

（１）それでも、webの技術を使いたいあなたへ
　　　→これが、push技術にあたります。

（２）そういう動きをするプログラムをつくってしまう

（３）サーバーのプログラム（データ）をクライアントに持ってくる
　　　→実際に、サーバーのデータをすべてクライアントに置くのは非現実的なので
　　　　現在は、必要なデータを、ダウンロードして、その後、再生します。
　　　　今の主流ですよね。

---

　（１）は、しかし、クライアントから定期的に情報を取得するのが主流なので、リアルタイムな情報取得ができません。たとえば、津波情報など、一刻をあらそうような情報は、すぐに表示したいけど、１０分毎にサーバーに見に行くとか言う設定では、最大１０分も待ってしまうわけで、下手したら、津波、来ちゃいます。

　っていうことは、やっぱり、（２）のように、サーバーからの情報をリアルタイムで流すプログラムを開発しなければいけません。そういうプログラム、有線放送や、ケーブルテレビ局が、視聴者をふやすには、有効かもしれません（作る価値有り？？）

---

　でも、そんな面倒なことをしなくても、いま、放送局は、まさに、この方式です。

　放送局というサーバーから、みなさんのご家庭のテレビというクライアントに、ずーっと情報をながしてます。テレビは情報を選択しなくていいので、「ながら族」などというものを生み出しました。そういう便利なシステムです。

　っていうことは、今のwebでできないことをテレビがやってるわけで、インターネットが発達しても、（上記（２）のようなプログラムだ出来ない限り）放送は、方式が違うのですたれない、むしろ、インターネットの面倒さ（自分で選択したりしなくちゃならない）を補完するものとして、インターネットが、発達すればするほど、放送の重要性がわかるかも！

　これって、ホリエモンの言っていることの逆？それとも、放送とインターネットで言ってることは一緒？？

３月３０日に出す、「コピーされるほど儲かるシステム！開発日記」第１５号について

３月３０日に出す、「コピーされるほど儲かるシステム！開発日記」第１５号は、ウィリアムのいたずらが行った場合の見積もり例です。実際に何を作るのかについて書いてあります。

----------

内容は、要求仕様についてです。

具体的には、以下のブログのまとめです。

要件定義は何からはじめるか－世代の断絶が、業界の病理と開発の教祖を生み出した
http://blog.goo.ne.jp/xmldtp/e/424e7be149d7577ae9f06f8444bf612e

FrontPageでHTMLファイルで保存すると、Excelで開いてもExcelファイルで保存不可
http://blog.goo.ne.jp/xmldtp/e/8b69771d2146b7b29664e6ce288931f3

ただし、例が、夕飯支援システムでなく、確定申告の例（ブログには無い）になっています。


ということで、以下、いつもの決り文句です。

（決り文句）----------

　１５号のメルマガについての、感想などはここの「コメント」にどうぞ！

　メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム！開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参照してください

COBOLからJAVAへの変換試案 オンライン(JAVAの１つのクラスで複数回画面表示)No2

　さきほどのブログのつづき

---

■■問題

　以下の、問題があるときの話です

・１つのプログラムの中で、何回も画面入出力が可能で、その間、セッションが切れない
　　　　→Ｗｅｂでは１プログラムでだいたい１画面、画面間でセッションがきれる

・場合によっては、write（出力）からread（読む）の順番になる
　　　　→Webの場合doGet()などで、データを読んでから処理、出力と、逆になるケースあり

■■　対応策

（１）それでも、Strutsとかで、実現したいあなたへ
（２）そういう動きをする画面表示用のプログラム（ユーティリティ）をつくってしまう
（３）荒業で、サーバーのプログラムをクライアントに持ってくる

前回のブログで、（１）は説明しました。今回は、のこり

---

■■（２）そういう動きをする画面表示用のプログラム（ユーティリティ）をつくってしまう

以下のプログラムをつくってしまいます。

クライアントとサーバー側で、ソケット間プログラムをするプログラムで
（だから作るプログラムは、クライアントとソケットそれぞれ）

・サーバーをたちあげ、

・クライアントが立ち上がると、ソケットと通信して、コネクションを貼る

・サーバー側からwrite命令を発行すると、クライアント側に、そのデータを送る

・クライアントでは、指定されたデータをもとに、画面を選び、値をセットして表示する
　　→したがって、画面のクラス（または元になるもの）は、クライアント側に置きます

・クライアント側では、画面入力され、イベントが発生すると、
　　　sendを行い、サーバーにデータ送信します。

っていうプログラムをつくると、サーバーからread writeするだけで、通信が出来ることになります（ただし、どの端末にどのメッセージを送るかとか、もうちょっと詰めないといけないことがあるけど）。
　ソケットを利用したプログラムなだけで、たいして難しいもんではないでしょう。


■■（３）荒業で、サーバーのプログラムをクライアントに持ってくる
　別に、サーバープログラムを、クライアントにおいちゃってもいいじゃん！という発想です。
　その場合，データベースと、（場合によっては）ファイルだけは、サーバーにおいておきたいかもしれません。

・そこで、データベースは、データベースサーバーとして、サーバーにおき、
　　ODBCかなんかで、アクセスする
・サーバーに置きたいファイルがあれば、サーバーにおき、
　　クライアントと、共有する

　とします。そうすれば、クライアントに、サーバープログラムがあってもいいじゃん！となります。

そのとき、画面の入出力は、（たとえば、Swingを使うなら）こんなかんじ。

OPENのところで、画面を生成し、(JFrame g1 = new JFrame() )
writeのところで、可視化し(g1.setVisible())
Readのところは、ループしておいて、画面からイベントが上がったら、フラグをセット、
　　そのフラグが上がったら、画面から値を取得してぬけるようにする
　　（もちろん、ループしているとき、sleepして、ある程度寝かせておきながらループ）
closeで画面をクローズする(g1.close())

---

なかんじだとおもいます。

COBOLからJAVAへの変換試案 オンラインNo1(またはJAVAの１つのクラスで複数回画面表示)

　今回は、COBOLからJAVAプログラムへの変換の話、オンライン編なんですけど、この話は、それだけでなく、JAVAの１つのクラスで複数回画面入出力をさせるには？という話も含みます。

---

COBOLからJAVAのプログラムへの変換は、まず、昨日のブログで書いたように、バッチと同じようにすすめていくわけですが、そうすると、壁にぶちあたります。

　それは

・１つのプログラムの中で、何回も画面入出力が可能で、その間、セッションが切れない
　　　　→Ｗｅｂでは１プログラムでだいたい１画面、画面間でセッションがきれる

・場合によっては、write（出力）からread（読む）の順番になる
　　　　→Webの場合doGet()などで、データを読んでから処理、出力と、逆になるケースあり
　
です。

　このため、単純に、そのＣＯＢＯＬプログラムを、JAVAのwebを利用したプログラムに変換できません。
　実は、これは、JAVAでも、
・バッチプログラムの入出力を画面上から行わせるように変えた場合
・入出力が複数回ある画面プログラム
を、webのサーブレットやStrutsを利用しようとしたときにも、おきます。

　今日は、その対処法試案

---

　まず、各社固有のプラットフォームで、そういうものへの対応ができているのであれば、そちらを使えばいいと思います。
　例えば、フォームがBeanになっていて、そのbeanに値をセットすると、画面表示する。
　そして、画面でイベントが起きたときBeanから帰ってくるなんていうものが、用意されていれば、それを使えば、いいと思います。

　今回は、そういうものが無いケースを考えます。方法は３つ
（１）それでも、Strutsとかで、実現したいあなたへ
（２）そういう動きをする画面表示用のプログラム（ユーティリティ）をつくってしまう
（３）荒業で、サーバーのプログラムをクライアントに持ってくる

---

■■（１）それでも、Strutsとかで、実現したいあなたへ

cobolのプログラムのPROCEDURE DIVISIONで、以下のようになっていたとします

OPEN 画面1
PERFORM A-SET TRUE A-SET-RTN ここで、画面の値をセットしている
WRITE 画面1
READ 画面１
PERFORM A-GET TRUE A-GET-RTN ここで、画面の値をセットしている
CLOSE 画面１

OPEN 画面２
PERFORM B-SET TRUE B-SET-RTN ここで、画面の値を受け取るセットしている
WRITE 画面２
READ 画面２
PERFORM B-GET TRUE B-GET-RTN ここで、画面の値を受け取るセットしている
CLOSE 画面２

(JAVAで書くとこういうクラスです Gamenが、画面のクラス)

Gamen g1 = new Gamen();
g1.setter();
g1.write();
g1.read();
g1.getter(); // ここで、g1の値をどっかにセーブしたとする
g1.close();

Gamen g2 = new Gamen();
g2.setter(); // ここでg1の値をもとにg2の値をセットしたとする
g2.write();
g2.read();
g2.getter(); // ここで、g2の値をどっかにセーブしたとする
g2.close();


こんなとき、どうするか

---

こういうとき、COBOLでは、

　　 ・READの直前で、むりやりモジュールをきって、わける。

　　　そうすると、こうなる

　　　　PERFORM BUBUN-A THRE BUBUN-A-RET
　　　　PERFORM BUBUN-B THRE BUBUN-B-RET
　　　　PERFORM BUBUN-C THRE BUBUN-C-RET
STOP RUN

BUBUN-A
OPEN 画面1
PERFORM A-SET TRUE A-SET-RTN ここで、画面の値をセットしている
WRITE 画面1
BUBUN-A-RET
EXIT

BUBUN-B
READ 画面１
PERFORM A-GET TRUE A-GET-RTN ここで、画面の値をセットしている
CLOSE 画面１

OPEN 画面２
PERFORM B-SET TRUE B-SET-RTN ここで、画面の値を受け取るセットしている
WRITE 画面２
BUBUN-B-RTN
EXIT

BUBUN-C
READ 画面２
PERFORM B-GET TRUE B-GET-RTN ここで、画面の値を受け取るセットしている
CLOSE 画面２
BUBUN-C-RTN
EXIT

・BUBUN-Aは、メニューからこのプログラムを呼び出すところのサーブレット
(Strutsなら、Actionクラス、*.doにあたる）になる。つまり、Strutsだと、

public class A extends Action
{
execute(なんとかかんとか）
{
BUBUN-AからBUBUN-A-RETのことをかいてね
}
}

・BUBUN-Bは、画面１で、ボタンを押されたところのサーブレット
public class B extends Action
{
execute(なんとかかんとか）
{
BUBUN-BからBUBUN-B-RETのことをかいてね
　　　　　ただし、 A-GET TRUE A-GET-RTNは、たぶんActionFormで
　　　　　吸収してると思うぞ
}
}

・BUBUN-Cは、画面２で、ボタンを押されたところのサーブレット
public class C extends Action
{
execute(なんとかかんとか）
{
BUBUN-CからBUBUN-C-RETのことをかいてね
}
}

となる。

---

　でも、これだと、データの受け渡しは、どーしてくれるんだ！となる。

　そこで、Data Divisionに入っているデータ全部を、セッションの中にいれ、

各クラスのexecuteで入ってすぐで、
　　　　request.getSession();session.getAttribute();で値を取得、
各クラスのexecuteの抜けるところで、
　　　　session.setAttribute();で値を設定する。

ちなみに、セッションの使い方は、ここに、まとめました。

---

この話、長くなりすぎたので、別の記事にして続けます。

COBOLプログラムをいきなりJAVAへ書き換える方法 試案

　ＣＯＢＯＬプログラムをＪＡＶＡに直す方法を知りたいケースは２つある。

　１つは、ＣＯＢＯＬプログラマがＪＡＶＡを覚えるときに、（あるいは逆のケース）対応が知りたい場合、

　もう１つは、ＣＯＢＯＬやＰＬ／Ｉのプログラムを、ＪＡＶＡに直す場合、設計しなおすと、プログラムの動きから変わってしまって結構危険（また、既存のドキュメントがあるのに、それを全部作り直すには時間的・金銭的費用がかかりすぎる）ので、前のプログラムとドキュメントからなおしたい。

　しかし、ＪＡＶＡとＣＯＢＯＬの両方わかるＳＥを用意すると、単価が高い。

　そこで、ＣＯＢＯＬソースとドキュメント（があればそれも）をもとに、ＪＡＶＡに、ある程度機械的に変換できないか？ということを、「仮に」思いついた場合。

　で、そんなとき、どうするか？についての試案を、ふと、思いついたので、書いて見ます。
　酔狂としてみてください（まちがってるところもあるかもしれないが、それはまあ。。大目に見てやってくらはい）

　ちなみに、COBOLの言語説明とサンプルについては、ここのサイトがわかりやすそう

---

　COBOLからＪＡＶＡへの変換ポイント３つ

（１）バッチのＣＯＢＯＬプログラムの変換　
　　　→これが基本

（２）オンラインのＣＯＢＯＬプログラムの変換
　　オンラインの場合、以下の問題がある
　　　・１つのプログラムの中で、何回も画面入出力が可能で、その間、セッションが切れない
　　　　→Ｗｅｂでは１プログラムでだいたい１画面、画面間でセッションがきれる
　　　・場合によっては、write（出力）からread（読む）の順番になる
　　　　→Webの場合doGet()などで、データを読んでから処理、出力と、逆になるケースあり

（３）設計上の問題
　　メソッドとなるようなものが、１本のプログラムとなっている。これを設計と、どう折り合いをつけるか？


ここでは、まず（１）から

---

■■　バッチからＣＯＢＯＬプログラムへの変換

　一般的に、ＣＯＢＯＬプログラムをＪＡＶＡに変換するには、

・COBOLの１本にプログラムをJavaの１つのクラスとしてしまう
・IDENTIFICATION DIVISIONは、プログラム名をクラス名にしてしまうほかは、
　コメントでＯＫ
・ENVIRONMENT DIVISION
special_namesは、置き換えなので、Javaプログラムにするときに、置き換えてしまう
FILE-CONTROLの、SELECT ASSIGN　は、JCLの値を受ける。
　　　　ここについては、（あ）で説明する（後述）

・Data Division
　COPY句で、ファイルのレコード構造を読み込んでいるとき
　　　まず、ファイルのレコード構造をクラスにしてしまう。
　　　（これは、Working-storage sectionで、方法を記述）
　　　そのクラスを、importしておくことで、copy句と同じにする
Working Strage Section
77のように、PICで型を指定している変数の場合には、クラス内に、変数を定義する
　　　01,03。。。など、レコード構造になっているものは、innerクラスとして定義する。
　　　（copy句でimportした場合は、別にクラスを用意する）
　　　ちなみに、こんなかんじ

COBOL側
　　　01 HEADER1 CHARACTER TYPE IS N-TYPE.
03 FILLER PIC X(19) VALUE SPACE.
03 H-01 PIC N(1).
　
JAVA側
　　　public class HEADER1
{
String fil1 = "";
String h-01;

}

・PROCEDURE DIVISION
　もし、パターンを使っている場合は、そのパターンを別クラスで用意しておき
このクラスを定義するところでextendsする

　でパターンを用意してなかったときや、最上位のパターンで、初めの行から
Stop RUNまでを１つのメソッドとして書くが、そのメソッドに関して、
　　　 public static void mainに書く方法と、
　　　１つの特定のクラス（たとえばexecute)とかに書く方法がある
　これについては（あ）で説明する（後述）

　その中で呼ばれる　perform ラベル１　THRU ラベル２　で定義される
　ラベル１からラベル２までを１つのメソッドとおく。

　GO TO 文で飛ばしている場合、エラーで抜けているならJavaの場合、exception
　としてthrowしてしまう。っていうので、いけるかも？？

---

■■（あ）２つの実装の方法とFILE-CONTROLのASSIGN
　ここで、実装方法は２つある

（Ａ）PROCEDURE DIVISIONのstop runまでを、public static void mainに記述してしまう場合
　このときは、ＪＣＬの部分を、バッチ（Linuxだとシェル）にして、javacで起動するようにかく。この場合、ＪＣＬで、ファイル名を指定し、ASSIGNでプログラムに渡す部分は、
　　　・起動するプログラムの引数として渡し、ファイル名を入れとくところを
　　　　変数でとっておき、そこに、設定する
　　　・JCLで、javaプログラム起動前に、プロパティファイルを（自動でも、手作業でもＯＫ）
　　　　作成しておき、プログラムはプロパティファイルを読み込み、ファイル名を入れとく
　　　　変数に設定する

（Ｂ）PROCEDURE DIVISIONのstop runまでを、特定のメソッドにいれる
　　　JCLはJavaのクラスとして作成する。
　　　ＪＣＬ部分をpublic static void mainのなかに記述する。
　　　このとき、JCLでは、newしたあとに、その特定のメソッドを呼び出すことになるが、
　　　その間に、クラスに対し、ファイル名の変数に、ＪＣＬで指定したファイルパスを
　　　いれてもいい。

（Ｂ）の方法だと、ＪＣＬのないプログラムは動かせない。そう考えると（Ａ）のほうが無難？

---

次回、オンライン編につづく

マクドナルドから、ＳＯＡとシステム開発の未来を考える(２８日修正）

　ＳＯＡには、詳しくないんだけど、マクドナルドで思ったこと。その４。

　（２８日注：この時点で、ＳＯＡＰでプログラムを組んでない時点で書いてます。
　　組んだ後は、ぜんぜん違う印象を持ってます。今度、機会があったら書きます）

　マクドナルドって、制作の人と販売のバイトの人は、入り混じるんだけど、制作場所は、同じで、食材はきまったところのあるので、作業する場所は同じなんですよね。

　つまり、
　　　ある場所で行う業務・サービス(ＳＯＡだとwebサービス）は決まっていて、
　　　その内容はマニュアルに記載されてる（ＳＯＡだとＷＳＤＬに記述されている）。
　　　そして、バーガーの作成指示（作業指示書）に応じて、その業務を行っていく。
　　　（ＳＯＡだと、クライアントで業務内容からＳＯＡＰのメッセージを
　　　　　自動的に生成していって、起動していくことになるが、ここの発想はない）。

　こうすると、マクドナルドの場合、柔軟なセットに対応できる
　（ＳＯＡの世界で言うと、すでにやっている業務の組み合わせであれば、
　　ＳＯＡＰメッセージの自動生成部分を切り替えることにより、
　　サーバー側のサービスを変えずに、柔軟に対応できるし、
　　新たな作業だとしても、その部分だけのサービスの入れ替えで済むということになる）。

　ＳＯＡの世界だと、このやり方を社内でやることによって、全社的な業務の状況の内容の検索とか管理が、やろうとおもえばできる。

---

　いままで、Ｗｅｂサービスというと、社外とのやりとりとか、公開されたものについての考えが中心だったけど、実は、クローズドな社内ベースで行ったとしても、効果があると思う。

　さらに、今後、Ｍ＆Ａが盛んになった場合、ＷＳＤＬによる、各業務記述があることによって、業務の比較、理解はよくなるし、合併企業における業務の乗り入れも、ネットワークの公開とクライアント側のＳＯＡＰメッセージ自動生成部分の変更で対応できるかもしれないというメリットがあるよね。

　っていうことで、ある意味、ＥＪＢを利用したシステム構築より、社内システムでもＷｅｂサービスベースで作ってしまったほうが、いいのかもしれない。

（２８日注：この時点では、そう思っていた）
　

---

（２８日注：ここ以下、記述がおかしかったので、大幅に直しています）

　しかし、この場合問題になるのは、ＷｅｂサービスとＵＭＬなんかの業務分析ででてくる、（受注とか発注とかの業務ごとに分けている）クラスとの関係はどうなるんだってこと。

　ひとつの考え方としては、MVCのモデルの部分をWebサービスとし、モデルのクラスをProvider Class、メソッドは、そのProvider ClassのMethodsとする方法などがあるとおもう。

　そうすると、先ほどの作業指示書の自動生成というのは、コントロールの自動化になる。
　ただし、モデルの部分の単位を大きくとりすぎてしまうと、あまり公開している意味がなくなってしまう（共通利用できなくなるので）。

　そこで、もっと、細かく考えて、Strutsの、Actionレベルと同じくらいにする方法もありだと思う。
　Strutsの場合、ボタンを押されたときの処理１個が、１つのActionクラスになる。したがって、Actionクラスは、メソッド１個分くらいになっている。
　webサービスでも、このぐらいの単位で公開したほうが、利用度が高いのかもしれない。

　ただし、これは、論理レベルでありといっているのであって、実務上、速度的にどうなの？という問題はある。

---

　こまった。内容を修正したら、「COBOLプログラムをいきなりJAVAへ書き換える方法試案」の要素技術を説明できなくなってしまった。しかたないので、その要素技術の説明は、「COBOLプログラムをいきなりJAVAへ書き換える方法試案」の第三ポイントで説明します。

　次回、書きたかった内容、「COBOLプログラムをいきなりJAVAへ書き換える方法試案」につづく。

　（実は、別に、マクドナルドについて、書きたかったんじゃないんです。っていうか、修正したら、本当にマクドナルドの話は、まったく必要なくなってしまった ＞＿＜！）

マクドナルドとMacの共通点、社長以外の話

　昨日、マクドナルドの話を書きました。

で、そこで
・注文を受けて作業指示書を作成するクラス
・作業指示書
・ディスパッチャ
・作業クラス

だけで、世の中の、すべての業務って、完結してしまうんじゃないの？

　って書き、そして、その「作業指示書」に相当するのが、バーガー類をつくるところの商品を表示する電子掲示板っていう話でしたけど、実は、コンピューター業界では、すでに、作業指示書に相当するものを作成し、それに基づき各業務を動かすというシステムを利用していて、さらにそれを標準化しようとしている分野があります。

　それが、Ｍａｃ（マッキントッショのほう）を利用するＤＴＰや印刷の世界の話。

---

　作業指示書を電子化し、自動化しようとする考え方は、adobeのJob Ticketによる、印刷工程などで、以前、ＤＴＰ（というより、プレスの世界で）話題になりました。
　最近では、さらに、ＣＩＰ４によるＪＤＦによって、印刷全工程の指示書を共通化するという話があります。

　プリプレス、印刷においては、さまざまな機械と工程が用意されています。
　ところが、製品によって、利用する機械が違ってくるわけです。
　たとえば、印刷会社では、１万部以上印刷する場合の輪転機と、それ以下の印刷を行う枚葉機の両方を用意していますし、さらに、編集したデータをそのような印刷機にかけるためのＲＩＰという装置（インターネットには、関係ないよ！ラスターイメージプロセッサ）に関しては、いろんな種類のＲＩＰを持ってます（ＤＴＰソフトによって、書き出すＰＳファイルが微妙に違い、その微妙な違いのために、ＲＩＰの相性というのがあるため、いくつものＲＩＰが必要になる）。

　なので、モノによって、どういう工程にするかというのが違い、それによって、必要な情報も違ってきます。そこで、各工程の指示（作業指示）を電子化し、これらのインターフェースを標準化する必要が生じて、このようなことになってきたようです。

　でも、結果として、この流れができると、作業指示書が電子化できるので、それによって、作業を自動的に流すことが（将来的には）できる方向になってきています。

---

　っていうことで、マクドナルドも作業指示の電子化によって、業務内容をある程度柔軟に組替えることが出来、それによって、機動的なメニュー構成が組めるようになったけど、同じように、印刷の世界も、CIP4 JDFによって、作業指示を電子化し、業務内容を柔軟に、さらには自動化して、印刷のさまざまな出力に対応しているといえます。


　って、無理やりな話でした。
　つぎも、無理やりな話が続いて、
　そのあとの話が興味深いと思うぞ！

---

　どうでもいい話だけど、作業指示書作成で、業務に展開する、自動化の部分って、部品表展開に似てる気がする（順番と並列作業を考慮するところが違うと思うけど）。

マクドナルドが、システム開発論の問題の解決策を示していることは、もっと知られていない

　さて、前のブログで、現在のオブジェクト指向の開発論における、アクターとその振る舞いや、担当者とその業務等を、固定的なものとして分析すると、マクドナルドのような、業務が人に固定的には結びついていない（緩やかな結びつき）の場合に表現が難しいことを指摘しました。

　この方法論の打開策を、
　　アナリシスパターンの「問題領域横断的なパターン」と
　　ＢＰＲという古典的な手法と
　　マクドナルドのバイトのおねーさま
　が提示しているとウィリアムのいたずらは考えます。
　
　以下、「マクドナルドのおねーさまがいかに偉大か」をいきなり書くと、「この人はメイド趣味か？制服フェチ？秋葉原に、いそうだよね！」と思わぬ誤解を招きそうなので、現行のシステム開発論をアナリシスパターンの問題領域横断的なパターンによって考慮しなおすと、ＢＰＲで語られた考え方にたどり着き、そのＢＰＲの手法が、マクドナルドのおねーさまがたによって実践されているから、偉い！ということを示します。

---

　とか書いたけど、じつは、ウィリアムのいたずら、お金ないです。
　アナリシスパターンの本なんて、買えないっす(;_;)!

　なので、このページに書いてあることからウィリアムのいたずらが勝手に推測して書いてしまいます。
　なので、まちがってるかもよ！

　このページの考え方で、すごいのは、部署なんかをパーティ型という抽象型に飛ばしてしまうことと、その関係を、責任関係として、切り分けちゃうことだと、勝手に理解しています。

　マクドナルドの例でいうと、もし、制作の人とか、売り子とかを、人という概念で抽象化させ、その制作の人がやっている仕事、売り子の仕事を切り離して、責任関係として定義してしまえば、結構柔軟に表現できるよね（人と仕事の関係の組替えですむから）。

　これは、システム開発現場でもよくやる手だと思うけど、つまり、従業員と仕事を切り分けてしまい、いろんな仕事をそれぞれのメソッドとしてコーディングしちゃって、担当者は、それぞれの仕事を起動するクラスとしてしまう手。

　で、そうすると、「問題領域横断的なパターン」じゃないけど、仕事って、結構、まとめられるます。ある考え方でまとめると。その考え方が、いまや古典になったＢＰＲ。

　ＢＰＲでは、顧客に提供するものから、本来必要な仕事を考えます。
　でも、そう考えると、世の中の仕事って、
　　・注文を受ける
　　・その注文を実現するための作業指示を作成する（考える）
　　・その作業指示を実行する（ディスパッチする）
　に、まとまりませんかあ？

　つまり、注文から作業指示書を作成できて、その作業指示に書かれた作業を理解して、実行すればいいわけです。

　そこで、システム開発としては、
１．（担当者にかかわらず）必要な作業（プロセス）を片っ端から作っていく
２．注文を受けたら作業指示に展開し、それをどっかに保持する（ものを用意する）
３．２．の内容をもとに、１をディスパッチ（起動して処理）する

っていう仕組みで済んじゃうわけですよ。

---

　で、マクドナルド（のバイトのおねーさまがた）は考えた（のかなあ？）。

・商品によって、作業はきまっている。
・ってことは、作業現場に商品さえ表示すれば
・そこで、みんな、どの商品が来たら、なにをしなきゃいけないかを知っていて
・自分はなにをしていいかの権利だけ決まっていれば、
・担当者なんか決まってなくっても、商品さえ表示されて、その現状さえわかれば
　　　　次の作業は分かるし、
　　　　その作業を（権利がある人のうちの誰が）実行しても支障が無いし、
　　　　早くできるじゃん！

っていうことは

・商品に対応する作業マニュアルと、
・商品を表示する機械さえできればいいじゃん！

っていうことで、あのバーガー類を製作するところに、注文と商品の一覧が出てるんだと思う。

---

っていうことはですよ、クラスにわけるとき、いままで受注とかいろんなクラスをつくってたけど、

・それらを全部抽象化して、作業っていうクラスをつくり、
・その中に、全部の業務をメソッドを入れてしまい、
・出力対象によって、作業指示書をつくって、
・作業指示書に基づき、作業クラスのメソッドをディスパッチすればいいじゃん！

そうすればクラスは

・注文を受けて作業指示書を作成するクラス
・作業指示書
・ディスパッチャ
・作業クラス

だけで、世の中の、すべての業務って、完結してしまうんじゃないの？
っていうことを、アルバイトのおねーさまがたは、全国的に同時に気づいた！

すばらしすぎる！
この考え方、昔あるＳＥに話したことあるんだけど、理解してもらうのに１ヶ月かかったぞ！
それを実践で、やってしまうとは、偉大だ！

って、アルバイトのおねーさんが偉大なのではなく、たぶん社長が偉大なんだろうけど。。
というのは、マクドナルドの社長が変わってから、作りおきから、いまの体制に変わったから。

---

ということで、この話のオチは、本家につづきます。（ここです）

　で、この話、コンピューターの話としては、まだまだ続きがあります。
　というか、この話、話したいことは、ぜんぜん違うことで、今日は、前座の、どーでもいい話です（「なら、書くなよ！」って、ツッコミがきそうですが ^^;)

　その話は、次回（明日か月曜日）に続きます。

マクドナルドが、ＵＭＬ等のオブジェクト指向の問題点を指摘していることは、あまり知られてないが、

マクドナルドにいくと、最近、面白い光景を目にします。

　注文して、バーガー類をつくるとき、
　・忙しくないと、作成担当の人が、作っています
　・忙しいとき、売っているおねーさん（じゃないこともあるけど）が、一部手伝っています。
　・店長以外のミドルクラスのおねーさんがいるお店が多く、
　　　　その人は全部やりかたを知っているらしく、
　　　　指示を出すと同時に
　　　　いろんなところを手伝っています
　　　　このおねーさんは、長時間いて、一つのお店に何人かいます。

　以前のマクドナルドは作りおきで、ハンバーガーの制作と、売っているおねーさまたちは、別々の仕事をしていました。いまも、基本的には別れているのですが、忙しくなると、もう、入り乱れて作っているのです。

---

　以前のマクドナルドであれば、現在のオブジェクト指向の考え方で分析可能です。

ユースケースでは、アクターを作成者、売り子のおねーさんなどとして表現できます。
　アクティビティ図を作るにも、　制作の人とおねーさんをスイムレーンでわけて表現できます。
　ＬＦＤで表現する場合も、制作部、売り子部？などとわけて表現できます。

　でも、いまのマクドナルドだと、問題です。
　制作部と、売り子部は、いまだに分かれていますが、制作に関して、売り子のおねーさまがたが、いろんなことをやる権利がどうもあるようです。
　そして、売り子のおねーさん中心に自律的に動いているのです。
　もはや、部署や、アクターとしての担当者が、どの業務をやるかという固定したものは無いです。そうすると、いまの現状をＵＭＬやＬＦＤで、どう表現するのか？
　売り子も制作部も従業員として抽象化して表現することは可能なのですが、制作と売り子の間に、一部制約があるようなのです。

　さらに、マクドナルドは、クーポン券を発行し、その商品セットを自由に組替えています
　（メニューに存在しないセットも、クーポン券では、存在する）。

　じゃあ、業務が混乱しているか？というと、ちゃんと、セットが出てきますよね！
　なぜか？

---

　つまり、マクドナルドの今の体制は、オブジェクト指向が出てきた根本的な問題を指摘しているんだと思います。
　歴史を紐解くと、

　８０年代　　　業務プロセス（手続き）を中心に分析
　　　　　　　　→業務はよくかわることで問題
　９０年代　　　ＤＯＡの出現
　　　　　　　　→データ構造は変わらないことに着目
　９０年代後半　オブジェクト指向
　　　　　　　　→業務をカプセル化した
　で、ここで問題なのですが、カプセル化する際、業務をカプセル化（イベントをクラスにするケース）するとしたら、８０年代の業務プロセスがよく変わるという問題を解決したのか？ということになります。
　ここで、データ、とくにデータのエンティティをもとにカプセル化（リソースをクラスにするケース）するとすると、本当に、リソース（たとえば従業員）と、メソッド（業務）の対応は、分析可能なほど固定的なのか？という問題に突き当たります。

　じつは、ビジネスモデルを作る場合、提供する物やサービスに対して、お金が発生し、そのものの提供とお金の授受に関して、業務が発生しますが、それを誰がやるのか？というのは、決して固定して考える必要は無いです。
　でも、（ＬＦＤが分かりやすいと思いますが）現状のオブジェクト指向における分析段階において、アクターや部署など、その業務をする人と行う業務に着目して分析し、最終的に、それがクラスにまで反映してしまうことも多いです。

　そうすると、現在のＵＭＬのような、従業員の役割とその業務を固定的に捕らえて分析している仕方では、従業員の役割が固定的でなくなるビジネスの分析はできなくなってしまいます。
　でも、今後は、効率性を考えると、従業員の役割が固定的でなくなるが、弱い制約がある、マクドナルドのようなビジネスが増えてくると思います。

　じゃあ、そういうビジネスを分析するには、どうしたらよいか？
　それは、今のマクドナルドのバイトさんの動きに隠されています。
　つまり、世界のシステム分析論を救うのは、マクドナルドのアルバイトかもしれない？？
　
　っていうことで、この話つづく。

Excelから書き出したHTMLファイルがジオシティーズでは表示されない場合の対処法

　昨日のブログ、「FrontPageでHTMLファイルで保存すると、Excelで開いてもExcelファイルで保存不可」の続きです。

---

　Excelを開き、１のＨＴＭＬファイルを読み込もうとしたら。。。
　読み込めない！
　FrontPageが開いちゃうんです。
　なので、ここで保存してももともとのファイルが保存されるだけでExcelファイルに変換されないのです。。。。

　というところで終わりました。

　で、どうするか？
　はじめから(Front Pageでなく）Excelファイルで作成し、「webページとして保存」すると、ＨＴＭＬファイルで保存されますが、次回から立ち上げたときも、Excelで開け、操作できます。
　ということで、はじめから、Excelファイルで作成し、webにアップしたいときは、ＨＴＭＬ形式にする（webファイルとして保存する）ということにしましょう。

---

　ちなみに、なぜ、Excelで読み込もうとしても、Front Pageが立ち上がるかというと、
　FrontPageでＨＴＭＬファイルとして保存すると、
＜meta name="GENERATOR" content="Microsoft FrontPage 4.0"＞
＜meta name="ProgId" content="FrontPage.Editor.Document"＞
　というタグが書き出されてしまいます。
　このタグをみて、Excelは、FrontPageを立ち上げているようです。
　だからこの２行を削除すると、Excelから読み込んだとき、Excelに変換されて、１シートとして読み込めます。

　また、なぜ、HTML形式なのに、Excelが立ち上がるかというのも、Ｅｘｃｅｌから「Webファイルとして保存」を実行して保存したＨＴＭＬファイルは、Excelで作成した旨のタグが書き出されるので、それで判断しているようです。
（どれを削除すれば、解釈されないか、までは、実験してないです）

---

　じゃあ、Ｅｘｃｅｌで、webファイルとして保存を実行したＨＴＭＬを、ジオシティーズにアップしようとすると。。。

　できないんだな、これが！！

　まず、Excelファイルをwebファイルとして保存すると、ファイル名.filesというフォルダができます（たとえば、Book1を保存するとBook1.filesというフォルダが出来る）
　この.を含むフォルダは、ジオシティーズでは、作成できません。
　そこで、.を_に変え、ファイル名_filesというフォルダにしましょう。
　（例だとBook1.filesをBook1_filesにする）。変えるとき、たぶんメッセージが出ると思うけど、無視っす。

　で、そうすると、もとのＨＴＭＬファイル（例の場合Book1.htm)のほうと矛盾してしまうので、元のＨＴＭＬファイル（Book1.htm)を開いて、ファイル名.filesをファイル名_filesに置換します（例だとBook1.filesをBook1_filesに変える）

　こうすると、ファイル名_filesのフォルダを、作成することはできます。
　で、ファイルを転送すると、表示しないんだな。これが！

---

　ところが、ロリポップのサーバーにアップして表示させると、表示するんだなこれが！

　理由は、リンク先のチェックをしているからみたいです。
もとのＨＴＭＬファイル（例の場合Book1.htm)中に、
＜link rel=Edit-Time-Data href="./Book1.files/editdata.mso"＞
＜link rel=OLE-Object-Data href="./Book1.files/oledata.mso"＞
という記述がありますが、editdata.msoというファイル等はありません。
そこで、この２行を削除します。

　そうして、もう一度ジオシティーズにアップすると、やっと表示できます。

アンニュイな午後、きれーなおねーさまと語る、汎用と最近のシステムのテストの違い

　昨日の午後のことです。コーヒーでも飲みながら、きれーなおねーさまと語らう、アンニュイな午後を過ごしておりました（＝ひまで、お仕事もらってる会社に最近入社したＳＥさんと、話してました）。
　
　そのきれーなおねーさま（＝ＳＥさん）は、汎用のほうをやっていたそうなのですが、会社に入社してから、ＪＡＶＡで組むようになったそうです。そこで疑問があると。。。
　汎用のときは、プログラムのホワイトボックステストを主流にやっていて、分岐ごとにチェックしていたのに、この会社のスケジュールにホワイトボックステストがないのはなぜ！？

---

　ご説明いたしますです。

　汎用機のシステムの多くは、９０年代前に作られました。
　そのときの仕様書（詳細設計書）は、プログラムの分岐にいたるまで、書かれているのが主流でした。
　また、当時＆その後に流行ったＤＯＡにおいても、最終的にはミニスペックに落とされるため、ミニスペックに、分岐の内容まで記述されていることが主流でございました。

　ここで、問題です。テストを行うには、どうしたらよいでしょうか。
　SLCP(特にSLCP-JCF98）における、設計とテストの関係の話題を持ち出すまでも無く、仕様書がなければ、その仕様を満たしているかどうかのテストは行えません。

　つーことはですね、結局できるのは、仕様書が存在するところまで、でございます。

　つまり、ＵＭＬにおいて、クラス図があって、インターフェースがテキトーにきまっていれば、「あとはよろしく」でプログラムを書かされてしまうわけですが、
　その場合、クラス図のメソッドにかかれた引数で、思った帰り値が帰ってくるかまでしか、テストできないっす。
　分岐までのドキュメントがあれば話はべつですが、そのドキュメントを作らない場合（さいきん、つくらないなあー）、そのクラス図レベルなのでございます。

　さらに、ＭＶＣに分けた場合、モデルとなる、クラスの引数と帰り値、こいつはテストするんですが、ビューとコントロールはたいてい、決まった作り（ドキュメントからＪａｖａのクラスを自動生成なんていうこともありますよね。そういう自動生成プログラム作成の仕事、ウィリアムのいたずらは、多いんですけど）をしているので、そのへんは、ブラックボックステストでいいんじゃない！ということになってしまうのでございます。

　つまりですね、単体のホワイトボックスをやろうにも、そこまで細かいドキュメントを作らないことが多いので、ブラックボックスっぽいテスト中心になってしまうのでございます。

---

　という説明をしたら、そのきれーなおねーさま（＝ＳＥって、くどいね！）いわく

「そんなんで、いいんですか？」

　いやー（ことば、ございません）

　うーん、こんなんで、品質とか、本当にいいんだろうか？
　クラス図で止めるのって、結構やばい気がするんだよねー。
　でも、実際、それよりも細かく書くのであれば、実際プログラム書いちゃったほうが早いし。
　うーん(^^;)。

人の流れのうち、インセンティブの流れと、業務の流れを分けた気持ち（多分）

昨日のお話のうち、

今回のエントリにあります、
>４．人の流れのうち、業務の役割の流れ
>５．人の流れのうち、インセンティブの流れ
が分かり難かったので、もう少し詳しくご説明いただけないでしょうか？

というコメントがありました。

するどい！

この分け方、放送大学大学院の、この先生「だけの」分け方だと思うんですよ！
で、そこに感動したんですけど、なんにも説明してないでした。
実際、その講座（経営システム１）でも詳しくやってなかったんだけど、
たぶん、こういう意味と、私が感じていることを説明します。

---

　分析するとき、人、物、金の分析は、すると思うんです。

　つまり、ユースケースで、業務を描いた後、その業務が、成立するかどうか（情報不足とかが、ないかどうか、物が流れてるかどうか）を確認します（この確認には、ＤＦＤを書くと図形的に分かるけど、ＵＭＬでは、かかない）。

　で、そこで、ユースケースのアクター（実際には担当者になると思うけど）を持ち出して、担当者の観点から、その業務をまとめなおすという行為をする、これをアクティビティ図で表現したり（スイムレーンを部署とか、担当者にする）、シーケンス図にする（アクターを１つのクラス、オブジェクトと捕らえて表現してしまう）とか、清水建設が提唱するLFDとか、古来から、いろんな表現方法があるので、何で表現してもいいんだけど、そういう表現方法で記述し、実際、担当者レベルで見て、なにをやっているのかを作成し、それを担当者にヒアリングで確認するということは、やると思います。
　っていうか、ここまでなんですよね。

---

　ここで分類しているのは、物と人の業務の流れと、それに付随する情報の流れだけです。

　でも、実際には、ビジネスなら、物が流れる時、ふつう、お金も流れているので、このあと、お金の流れを確認する必要があります。

　つまり、それぞれの物に対して、このお金は、どういう形で支払われるのか？ということを確認するという作業です。

　この辺について、ＵＭＬも、それ以前の考え方でも、（お金の回収も業務だから）あまり強調されていないので、効率的な確認方法は無いと思います（知らないだけかも）。
　地道に確認するしかないかも。

　で、今までは、ここで終わりなんだけど、ちょっとまって、って考えたのが、放送大学の先生の偉いところ！

　アクターは、業務を行ったんだよねえ。
　っていうことは、そのアクターに、お金払わなくっていいの？っていう考え方。

　これは、社会的に考えると、「学歴社会から成果主義」とかいう話から入るんだろうけど、まあ、そこは省略。最近の場合、アクターが働いた分に対して、お金を払うというケースが出ている。

　社外の人に対してなら、キックバック（リベートっす）とか、割引、マルチ商法とか（って、いいのかな？まあ、それまがいのもんとか）
　社内の人に対してでも、成績によって、インセンティブを払うとかいう場合がでてきた。

　そうすると、そのアクターごとに、

１．行われた（全ての）仕事に対して、インセンティブを与えなくていいのか？って考える必要がある。

２．そして、インセンティブを与えるとなったら、そのインセンティブの管理方法
　　（記録方法、支払方法）を考える
　　　→（これは動的な側面、ＵＭＬなんかが得意）

３．とともに、インセンティブだけをまとめて考え（データ構造のような静的な側面）、
　　そのインセンティブが成立するかどうか、矛盾がないかを確認する必要がある

ここまで考えないと、最近の成果主義に基づいた、ドライな社会でのビジネスモデルは成立しない。

---

　たぶん、こういうことが、言いたかったんだと思います。

　しかし、インセンティブをめぐる管理方法と、そのインセンティブの整理、矛盾の発見方法は、まだあんまり考えられていないと思います。

　実務上では、

（１）ラダー（ある量を販売すると、上のステージにいき、有利なインセンティブになる）制度がある場合、今月分を集計してからラダーに照らし合わせるのか？先月の成果を元にラダーを決めてから計算するのか？とか、

（２）対象が二重にかかっていいのかどうか？
　　（この商品を売ったら、１０％のキックバック＋合計１億円の売上の人は５％割引っていったとき、１億円販売し、かつ対象商品を売った人は、どっちの割引？それとも合算？）とか、

（３）インセンティブの支払い時期と方法、カウント時期など

で、部分的にはＯＫなんだけど、全体で見るとおかしいという矛盾が起きることがあります。
　（ＳＥに指摘されるまで、気づかない営業もいるほど）
このへんを、効率よく見つけられる手法って。。。ないんですよね。
（私が知らないだけかも）、成果主義や会計でもＡＢＣ分析が入ってくると、問題になると思うけど。