以前、オフシェア開発の先としての自動生成を考える必要性が早まった？最近の国際情勢で！！っていうブログをかいたとき、
具体的な業務のパターン化については、このブログの趣旨（オフシェア開発とカントリーリスク）に関係ないので、別の機会に（覚えていたら）
って書いたので、積み残しの残務整理ということで、その話。
そのブログの中ほどにデサインパターンのパターンじゃなくって、それよりも、もっと
大きな概念の”業務パターン”と書いているように、この業務のパターン化っていうのは、デザインパターンよりも、大きな概念になる。
そこで、まず、デザインパターンについて考えます。
デザインパターンで有名なのは、GoF本に紹介されているデザインパターンでしょう。
これには、２３種類ある。具体的には、以下のとおり
01 Iterator ― 1つ1つ数え上げる
02 Adapter ― 一皮かぶせて再利用
03 Template Method ― 具体的な処理をサブクラスにまかせる
04 FactoryMethod ― インスタンス作成をサブクラスにまかせる
05 Singleton ― たった1つのインスタンス
06 Prototype ― コピーしてインスタンスを作る
07 Builder ― 複雑なインスタンスを組み立てる
08 Abstract Factory ― 関連する部品を組み合わせて製品を作る
09 Bridge ― 機能の階層と実装の階層を分ける
10 Strategy ― アルゴリズムをごっそり切り替える
11 Composite ― 容器と中身の同一視
12 Decorator－飾り枠と中身の同一視
13 Visitor ― 構造を渡り歩きながら仕事をする
14 Chain of Responsibility ― 責任のたらい回し
15 Facade ― シンプルな窓口
16 Mediator ― 相手は相談役1人だけ
17 Observer ― 状態の変化を通知する
18 Memento ― 状態を保存する
19 State ― 状態をクラスとして表現する
20 Flyweight ― 同じものを共有して無駄をなくす
21 Proxy ― 必要になってから作る
22 Command ― 命令をクラスにする
23 Interpreter ― 文法規則をクラスで表現する
（上記斜体は、後述する「増補改訂版Java言語で学ぶデザインパターン入門」の見出し
から引用）
具体的に、どういうプログラムになるのかについては、
増補改訂版Java言語で学ぶデザインパターン入門
結城浩 著 ソフトバンクパブリッシング刊 ISBN4-7973-2703-0
を見ていただくのが、一番分かりやすいと思う。
ので、とりあえず、ここでは、それを紹介することが主題でははないので、このぐらいにしておく。
このデザインパターンを使ってユーザーと、業務の打ち合わせをするということはありません。
なぜなら、ユーザーは、わからないから。
ユーザーがヒアリングのときに、自分の業務を説明するのに、「Facadeにしてください」とは、いうとは、思えません。もし、言ったとしたら、それは、ぜーんぜん違う意味でしょう。
（Facade＝ファザードっていうのは、建物の正面の部分を指します。ちなみに、たしか、もともとはフランス語だったと思います。なので、よみかたが、ちと変です）。
業務レベルでは、契約時点、営業とかの間で話されるのは、おおきな取引上のイベントレベル、つまり、商業だと
受注
発注
入庫
出庫（出荷）
納品
あと、イベントの対象となるマスター、つまり、
売り手である自社、
買い手である顧客、
２人をつなぐ商品
と、これに付随する、銀行などさまざまなマスターの
作成・更新・削除処理
だと思います。
これは、お客さんも意識、理解していて、そのため、お客さんは、
「受注は、このようにやります」
「発注は、こうします」
っていうように説明します。
っていうことは、
＝＞受注の説明内容として、いきなりデザインパターンが説明されることはない
＝＞なので、デザインパターンを採用しても、
そこへの落とし込みは、プログラマーの恣意的な操作になる危険が大きい
＝＞プログラマーと発注者がわの共通言語ではないため、
勘違いや意味の食い違い、情報不足が起こるリスクが大きい
っていうことになります。
じゃあ、現実的に、この間をどうしているかというと、
ユーザーと、プログラマー（実質、手配できるのはワーカーさん）
の双方が理解できる言葉を使えば、お互いの誤解は少ないことになります。
これが、”業務パターン”（っていうかどうかは別として、かりにここではそう呼びます）
つまり、ユーザーの業務をモジュール化したもので、これを、コンピューター上に表現
することによって、そのパラメータを変えていくことで、ユーザーの業務を定義していきます。
たとえば、帳票出力とか、画面表示とか、電話をかけるとか、データチェックとか、
ソートとか。。きりないぞーー
なんかです。これは、どーいうプログラムにするかっていうのをパターン化しておけば、あとは、パラメータチェンジっていうことで、ワーカーさん作業に落とし込めます。
では、この業務パターンというのは、どのくらいのレベルか？っていうと、ヒアリング可能でお客さんと同意がとれるレベルっていうと、ＡＢＣ（活動基準原価計算：あのＰＯＳなんかのＡＢＣ分析や朝日放送や富士ソフトと合併した会社ではない）の業務プロセス位か、さらにそれを１段階下げたレベル程度かもしれない。
しかし、この業務パターンをどこに置くか？という明確な基準は無く、それは、属人的となっている。
この分野において、研究開発が進めば、安定的なソフト構築ができると思うかもしれないが、その可能性は、低いと思っている。理由は
・この分野は、ワーカーへの落とし込みという、アカデミック性の低い、アメリカでは研究されていない領域である。なので、この分野を研究しても、学者・研究者は名声を得ることは出来ないため、出世に不利な、この分野を研究することはないだろう。
・実はこれは、ユーザーのヒアリングをテープにとって、共通項をさがすと簡単に出てくるが、そのような、仕様をまとめる作業は、メーカーの仕事だ、メーカーやれえ！ということで、ユーザーはやろうとしない。それが証拠に、メーカーは要求仕様の標準化というのを考えているが、ユーザー同士があつまって、業務を表現する共通用語のとりきめなんていう作業をしようとはしていない（たぶん）。
・実は、この落とし込みは、何十人に１人かは、教えてもらわなくてもできる能力を持っている。
そこで、メーカーは
大量のワーカーを採用し、
その中で、その才能のあるものだけが残れば、
なんの問題もない。
ワーカーさんで、この手法が編み出せないと、大量の時間と労力をついやしてもシステムはできないので、うつ病になってしまう。実はこの業界、ワーカーさんで、これが作れない人は、うつ病になるか、こんなのにかかわらなくていい、御用聞きＳＥや、マネージャーなど上位職にいくしくみが出来ている。なので、現場的には、問題がおこらない。
（ＳＥは、本来知っておくべきだが、御用聞きに徹すれば、このしくみを知らなくてもＳＥはできてしまうのだ ＠＿＠！）
ただし、この分野の進展の可能性は、若干ある。
というのは、たぶん、このレベルの業務プロセスが、ロボットに対する教示内容になってくると思う。そうすると、ロボットの分野として、研究されるかもしれない。
アクセス
トータル
ランキング
