さて、前のブログで、現在のオブジェクト指向の開発論における、アクターとその振る舞いや、担当者とその業務等を、固定的なものとして分析すると、マクドナルドのような、業務が人に固定的には結びついていない(緩やかな結びつき)の場合に表現が難しいことを指摘しました。
この方法論の打開策を、
アナリシスパターンの「問題領域横断的なパターン」と
BPRという古典的な手法と
マクドナルドのバイトのおねーさま
が提示しているとウィリアムのいたずらは考えます。
以下、「マクドナルドのおねーさまがいかに偉大か」をいきなり書くと、「この人はメイド趣味か?制服フェチ?秋葉原に、いそうだよね!」と思わぬ誤解を招きそうなので、現行のシステム開発論をアナリシスパターンの問題領域横断的なパターンによって考慮しなおすと、BPRで語られた考え方にたどり着き、そのBPRの手法が、マクドナルドのおねーさまがたによって実践されているから、偉い!ということを示します。
とか書いたけど、じつは、ウィリアムのいたずら、お金ないです。
アナリシスパターンの本なんて、買えないっす(;_;)!
なので、このページに書いてあることからウィリアムのいたずらが勝手に推測して書いてしまいます。
なので、まちがってるかもよ!
このページの考え方で、すごいのは、部署なんかをパーティ型という抽象型に飛ばしてしまうことと、その関係を、責任関係として、切り分けちゃうことだと、勝手に理解しています。
マクドナルドの例でいうと、もし、制作の人とか、売り子とかを、人という概念で抽象化させ、その制作の人がやっている仕事、売り子の仕事を切り離して、責任関係として定義してしまえば、結構柔軟に表現できるよね(人と仕事の関係の組替えですむから)。
これは、システム開発現場でもよくやる手だと思うけど、つまり、従業員と仕事を切り分けてしまい、いろんな仕事をそれぞれのメソッドとしてコーディングしちゃって、担当者は、それぞれの仕事を起動するクラスとしてしまう手。
で、そうすると、「問題領域横断的なパターン」じゃないけど、仕事って、結構、まとめられるます。ある考え方でまとめると。その考え方が、いまや古典になったBPR。
BPRでは、顧客に提供するものから、本来必要な仕事を考えます。
でも、そう考えると、世の中の仕事って、
・注文を受ける
・その注文を実現するための作業指示を作成する(考える)
・その作業指示を実行する(ディスパッチする)
に、まとまりませんかあ?
つまり、注文から作業指示書を作成できて、その作業指示に書かれた作業を理解して、実行すればいいわけです。
そこで、システム開発としては、
1.(担当者にかかわらず)必要な作業(プロセス)を片っ端から作っていく
2.注文を受けたら作業指示に展開し、それをどっかに保持する(ものを用意する)
3.2.の内容をもとに、1をディスパッチ(起動して処理)する
っていう仕組みで済んじゃうわけですよ。
で、マクドナルド(のバイトのおねーさまがた)は考えた(のかなあ?)。
・商品によって、作業はきまっている。
・ってことは、作業現場に商品さえ表示すれば
・そこで、みんな、どの商品が来たら、なにをしなきゃいけないかを知っていて
・自分はなにをしていいかの権利だけ決まっていれば、
・担当者なんか決まってなくっても、商品さえ表示されて、その現状さえわかれば
次の作業は分かるし、
その作業を(権利がある人のうちの誰が)実行しても支障が無いし、
早くできるじゃん!
っていうことは
・商品に対応する作業マニュアルと、
・商品を表示する機械さえできればいいじゃん!
っていうことで、あのバーガー類を製作するところに、注文と商品の一覧が出てるんだと思う。
っていうことはですよ、クラスにわけるとき、いままで受注とかいろんなクラスをつくってたけど、
・それらを全部抽象化して、作業っていうクラスをつくり、
・その中に、全部の業務をメソッドを入れてしまい、
・出力対象によって、作業指示書をつくって、
・作業指示書に基づき、作業クラスのメソッドをディスパッチすればいいじゃん!
そうすればクラスは
・注文を受けて作業指示書を作成するクラス
・作業指示書
・ディスパッチャ
・作業クラス
だけで、世の中の、すべての業務って、完結してしまうんじゃないの?
っていうことを、アルバイトのおねーさまがたは、全国的に同時に気づいた!
すばらしすぎる!
この考え方、昔あるSEに話したことあるんだけど、理解してもらうのに1ヶ月かかったぞ!
それを実践で、やってしまうとは、偉大だ!
って、アルバイトのおねーさんが偉大なのではなく、たぶん社長が偉大なんだろうけど。。
というのは、マクドナルドの社長が変わってから、作りおきから、いまの体制に変わったから。
ということで、この話のオチは、本家につづきます。(ここです)
で、この話、コンピューターの話としては、まだまだ続きがあります。
というか、この話、話したいことは、ぜんぜん違うことで、今日は、前座の、どーでもいい話です(「なら、書くなよ!」って、ツッコミがきそうですが ^^;)
その話は、次回(明日か月曜日)に続きます。
この方法論の打開策を、
アナリシスパターンの「問題領域横断的なパターン」と
BPRという古典的な手法と
マクドナルドのバイトのおねーさま
が提示しているとウィリアムのいたずらは考えます。
以下、「マクドナルドのおねーさまがいかに偉大か」をいきなり書くと、「この人はメイド趣味か?制服フェチ?秋葉原に、いそうだよね!」と思わぬ誤解を招きそうなので、現行のシステム開発論をアナリシスパターンの問題領域横断的なパターンによって考慮しなおすと、BPRで語られた考え方にたどり着き、そのBPRの手法が、マクドナルドのおねーさまがたによって実践されているから、偉い!ということを示します。
とか書いたけど、じつは、ウィリアムのいたずら、お金ないです。
アナリシスパターンの本なんて、買えないっす(;_;)!
なので、このページに書いてあることからウィリアムのいたずらが勝手に推測して書いてしまいます。
なので、まちがってるかもよ!
このページの考え方で、すごいのは、部署なんかをパーティ型という抽象型に飛ばしてしまうことと、その関係を、責任関係として、切り分けちゃうことだと、勝手に理解しています。
マクドナルドの例でいうと、もし、制作の人とか、売り子とかを、人という概念で抽象化させ、その制作の人がやっている仕事、売り子の仕事を切り離して、責任関係として定義してしまえば、結構柔軟に表現できるよね(人と仕事の関係の組替えですむから)。
これは、システム開発現場でもよくやる手だと思うけど、つまり、従業員と仕事を切り分けてしまい、いろんな仕事をそれぞれのメソッドとしてコーディングしちゃって、担当者は、それぞれの仕事を起動するクラスとしてしまう手。
で、そうすると、「問題領域横断的なパターン」じゃないけど、仕事って、結構、まとめられるます。ある考え方でまとめると。その考え方が、いまや古典になったBPR。
BPRでは、顧客に提供するものから、本来必要な仕事を考えます。
でも、そう考えると、世の中の仕事って、
・注文を受ける
・その注文を実現するための作業指示を作成する(考える)
・その作業指示を実行する(ディスパッチする)
に、まとまりませんかあ?
つまり、注文から作業指示書を作成できて、その作業指示に書かれた作業を理解して、実行すればいいわけです。
そこで、システム開発としては、
1.(担当者にかかわらず)必要な作業(プロセス)を片っ端から作っていく
2.注文を受けたら作業指示に展開し、それをどっかに保持する(ものを用意する)
3.2.の内容をもとに、1をディスパッチ(起動して処理)する
っていう仕組みで済んじゃうわけですよ。
で、マクドナルド(のバイトのおねーさまがた)は考えた(のかなあ?)。
・商品によって、作業はきまっている。
・ってことは、作業現場に商品さえ表示すれば
・そこで、みんな、どの商品が来たら、なにをしなきゃいけないかを知っていて
・自分はなにをしていいかの権利だけ決まっていれば、
・担当者なんか決まってなくっても、商品さえ表示されて、その現状さえわかれば
次の作業は分かるし、
その作業を(権利がある人のうちの誰が)実行しても支障が無いし、
早くできるじゃん!
っていうことは
・商品に対応する作業マニュアルと、
・商品を表示する機械さえできればいいじゃん!
っていうことで、あのバーガー類を製作するところに、注文と商品の一覧が出てるんだと思う。
っていうことはですよ、クラスにわけるとき、いままで受注とかいろんなクラスをつくってたけど、
・それらを全部抽象化して、作業っていうクラスをつくり、
・その中に、全部の業務をメソッドを入れてしまい、
・出力対象によって、作業指示書をつくって、
・作業指示書に基づき、作業クラスのメソッドをディスパッチすればいいじゃん!
そうすればクラスは
・注文を受けて作業指示書を作成するクラス
・作業指示書
・ディスパッチャ
・作業クラス
だけで、世の中の、すべての業務って、完結してしまうんじゃないの?
っていうことを、アルバイトのおねーさまがたは、全国的に同時に気づいた!
すばらしすぎる!
この考え方、昔あるSEに話したことあるんだけど、理解してもらうのに1ヶ月かかったぞ!
それを実践で、やってしまうとは、偉大だ!
って、アルバイトのおねーさんが偉大なのではなく、たぶん社長が偉大なんだろうけど。。
というのは、マクドナルドの社長が変わってから、作りおきから、いまの体制に変わったから。
ということで、この話のオチは、本家につづきます。(ここです)
で、この話、コンピューターの話としては、まだまだ続きがあります。
というか、この話、話したいことは、ぜんぜん違うことで、今日は、前座の、どーでもいい話です(「なら、書くなよ!」って、ツッコミがきそうですが ^^;)
その話は、次回(明日か月曜日)に続きます。