ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

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

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

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




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

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

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

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

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

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

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

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

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

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




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

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

っていうことは

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

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




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

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

そうすればクラスは

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

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

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

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




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

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

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

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2005-03-25 11:48:33 | 開発ネタ
マクドナルドにいくと、最近、面白い光景を目にします。

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

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




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

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

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

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

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




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

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

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

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

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

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする