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

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

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

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

　つまり、
　　　ある場所で行う業務・サービス(ＳＯＡだと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によって、作業指示を電子化し、業務内容を柔軟に、さらには自動化して、印刷のさまざまな出力に対応しているといえます。


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

---

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