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

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

ジャストシステムの社長交代に思う、日本のソフト流通

2009-06-22 17:36:21 | Weblog

 ほんとーだあー、ジャストの社長、代表権のない会長に退いてますね
 http://www.justsystems.com/jp/just/finance/j0906181.pdf(PDF)

 この件に関して、ここ(2009年6月20日)に(たぶん)パッケージ会社関連で「ない」先生からのコメントがあるけど、パッケージ会社の人は、きっと違った見方をするだろうから、ま、その呼び水ということで、パッケージ会社にいた、ウィリアムのいたずら様が、独断と偏見で、ちょっとコメントさせていただきますかね・・・




 まず、日本では、一般の価格帯(3万円以下)で、パッケージだけでは、ソフトウエア業は成立しません。

 そのからくりについて。

 小売価格の6割を、開発会社が受け取るとして、3万円なら、1万8千円。
 1万人が買ったとして、1億8000万が、開発経費です。
 かりに、CDただ、パッケージただ、ぜーんぶただで、その全額を人件費に渡すとすると、
 年収400万の人(製造間接費を200万として、計600万)の人を、30人雇えます・・・

 ・・・が、開発の人が、サポートをするのは、精神的に無理なので、
 (無慈悲な客が、俺は3まんだしたんだあ・・・客はかみさまだあ。。。という勢いで、
  サポセンの人間の精神をぼろぼろにさせる。そのため、さぽせん電話ウケを、ずっとさせるのは無理。
  ふつう、ローテーションを組むが、結局やめてしまう。そこで、この人たちは、派遣を利用するなどして、
  開発とは別枠で取る)
 サポセン要員+営業に10人とると、のこり、20人しかいない。

 パッケージソフトの開発スタッフの担当ステップ数は、10万行ぐらい、いけるので
 (「パッケージソフトの開発スタッフ」という限定つき、
  パッケージの連中と、ほかの下請けの人間と、両方のプログラム、システム作る人を見てきたけど、パッケージの人のほうが、
  優秀な人が多く、10万ステップくらい担当できる(=現象を言っただけで、どこがおかしいか瞬時にわかり、関係各位に、
  的確な指示が出せる、また、そのチームワークが組める)人も多いよね。。。)

 システム全体で200万行くらいかなあ。。。

 たった、200万ステップだよ、そんで、何がかけるというの(^^;)
 エラーとかチェックしてたら、Javaだって、1画面で、20000とか、そこら、いっちゃうでしょ・・・(1画面10イベントあったとすると、1イベント2000ステップ・・・くらい、モデルDB操作で行ってしまう)
 そしたら、100画面しかない。
 (どんなソフトにも、「ファイル」、「編集」、「表示」、「ヘルプ」に相当する機能は必要。このほかに、2、3の機能グループを追加する。この機能グループに対し、平均10個の機能をつけると、もう、6*10=60機能、これに、サブ機能をつけると、100機能ぐらいになり、各機能1画面で・・・)

 ちょっと大きなシステムを作ったら、それよりステップオーバー=開発人員必要=開発経費増大=赤字なわけよ・・・




 さらにだ、今のは、1万さばたとした話。

 そーすると、「いや、バンクに8000、Waveに2000さばけばいいんでないの?」
 (いま、バンクやWaveじゃないのかしら?卸の話)っていうのは、お偉いさんの見方。

 結局、末端の小売に流れるんだから、小売が何本引き取ってくれるか?って考えないといけない。

 ヤマダ電機2000,ビッグカメラ2000,ソフマップ2000、石丸1000、九十九1000、Laox1000、その他1000
 流して1万、大変でしょ。

 で、そのヤマダ電機に2000流したとする。ヤマダ電機の店舗が、297店舗ってことは、1店舗、7本。1店舗1年に7本売るって、結構力のあるソフトだよ・・・みんな、ソフトを並んで買ってるなんて様子、見ないでしょ?




 で、ここでソフト流通の問題。

 もし、返品ナシ(=バージョンアップによる交換なし)とすると、卸も怖いから、取ってくれる本数は少ない。
 そーすると、ソフトハウスは干上がってしまうので、返品というか、交換アリにしたとする。

 つまり、売れ残った場合、バージョンアップ品と交換する。

 この契約をしたとたん、バージョンアップ「しなければならない」

 じゃなかったら、売れ残ったものを、回収して、返品=返金しないといけない。これは、キャッシュ的に痛い。




 ってなことで、パッケージで、キャッシュがほしいなら、返品=交換を認めることになる。 

 となると、バージョンアップが必要だ。

 したがって、パッケージソフト会社は、常にバージョンアップ、開発が終わったとしたら、もう次期バージョン、開発要員をフル稼働させるのが普通(もっとも、リリースしたバージョンの修正もあるので、すぐにバージョンアップしなくても、稼動するんだけどね)

 ってことで、人は減らせない、っていう感じになる。とくに、1発でも失敗して、交換対象品が増えたら、アウトだ。

 次は、それを上回るほど、出荷しないと、採算合わなくなる。





パッケージソフト会社は、よくて、こんなかんじ。たいていはここまでうまくいかないので、結局、

・ものすごーく高価なパッケージをつくる(10万以上):ADOBE,SAP
・マシンにバンドルして、大量にさばく:Microsoft
・他の業務(受託など)をやる:管理工学研究所(松、桐)
・もっと、もーっと、利益が取れるまで小規模にやる
   プログラムを小規模に:ソースネクスト
   会社を小規模に:カタカナ7文字(あえて、書かないけど ^^;)

のどれか、ないしは2つ以上の組み合わせをおこなう。

 ジャストは、たしか、80年代後半、90年代前半もかな?、受託を受けること(=この戦略をとった管理工学)を非難していたので、受託戦略は、まあ、取れなかったであろう。高価なパッケージ作戦である、大地は、失敗した(DTPソフト販売は流通が違う。Tooをおさえることが重要なのに、そのような戦略をとらなかった?)、バンドル戦略は中途半端(Microsoft以外、この戦略をとるのは難しい)、上場したので、小規模にやるのは無理・・・

・・・となると、やっぱ、社長がやめて、キーエンスとともに歩むしかないか?
(キーエンスの受託はアリかも。。)




 というわけで、パッケージ会社は、いまの流通では採算が取れない。そこで、まあ、滅んでいった会社がおおいということだよね。

 唯一創業者が残っている(関根氏)管理工学研究所は、もはやパッケージソフト屋さんじゃないし(って、桐のファン、関係者がみたら、怒りそうだが ^^;)、Linuxのディストリも、結局残ったのって、redHatとturboなの?日本じゃないし・・・

 流通が変わらない限り、この状況は変わらないわけだけど、ただ、ネットによって、日本の流通が変わる可能性はあるよね。

 ま、これは別の機会に書くとしよう。。。



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

UML等各種ダイアグラムのエラーチェック体系化(その5:ドキュメントをどこまで詳細に記述する?)

2009-06-22 08:00:26 | Weblog

 シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
 前回は、Strutsの場合に使いそうなダイアグラムについてあげました。

 しかし、これらのダイアグラム、おおざっぱに書くこともできれば、詳細に書くこともできます。どのレベルでも書けます。

 たとえば、

  業務内容、
    受注する、納品する。
  いじょー

 もありえるし(ありなのか?)、受注を細かなステップに分けていくこともできます。

 どのくらいのレベルまで書けばよいのでしょうか?




 それには、いろいろな答えがあると思います。
 ただ、ここでは、

・ダイアグラムの入力に関するチェック
   →入力時矛盾チェック
     =入力データが前工程で作成されていて、利用可能になっているか

 という作業をやろうとしています。
 そこで、この作業に支障がない程度の記述が、前工程に対して必要だということになります。それは、どのレベルか?具体的に見ていきましょう。




 たとえば、ユースケース図と、アクティビティ図の場合、

 ユースケース図に書くのは、コンピューター化するユースケース、つまりコンピューター化する業務ってことで、それらの業務は、業務流れ図である、アクティビティ図のアクティビティに原則、書かれていなきゃいけなさそうです。
 じゃなきゃ、そのコンピューター化するユースケース、どの業務のどこで行うのか、分かんなくなっちゃいます。


 ってことは、ユースケース図に出てくるユースケースは、アクティビティ図のアクティビティとして、原則出てくるってことになります。

 原則ってしたのは、たとえば、「マスタ管理」など、業務ではなく、コンピューター化する上で、業務じゃないけど必要なものも出てくる可能性があるからです。




 いま、ユースケースとアクティビティ図の関連について書きましたけど、
 これから、同じように、

・後工程の入力になるために、前工程としては、どこまで記述しないといけないか?

 というチェックを、各ドキュメントについて行いたいと思います。


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

月と火星では、ロボットで遠隔操作するのでも、話が違う

2009-06-21 21:13:52 | Weblog

 さっき、夢の扉で、こんなことを言ってました。

 ロボットを火星に大量に送り、地球から遠隔操作して、建物を建設する

・・・???月の間違いでは??

月と火星では、ロボットで遠隔操作するのでも、話が違う

ここにあるように、月と火星では、電波の届く時間が違う(光が届く時間=電波が届く時間)。

 月は、1.3秒、往復しても3秒なので、地球からの遠隔操作も、可能と言える。

 でも、火星は、13分(最接近時4分だけど)、往復したら、26分、26分もたったら、現場の状況は変わってしまっているかもしれないので(火星は確かに大気は薄いけど、風が吹くこともあるらしい)、地球から直接操作すると、とっさの判断ができない。
 そこで、ある程度自律した機能が必要になる。地球から、画面を見ながら遠隔操作を行うというより、送られてくる映像を総合的に判断しながら、大まかな指示を地球から出すというかんじになるだろう。

 ってことで、遠隔操作といっても、イメージぜんぜん違い、人間の動作を読み取って、それで操作するみたいな、今回の夢の扉のような話は、月にロボットを送り込んで遠隔操作する場合の話であって、火星じゃ無理だろお・・・

 あ、あと、ほかにもこの番組について書きたいことあるんだけど、話題が大きく変わってしまうので、とりあえず、ここで切る。

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

日本のWebはGoogleとかじゃなく、「スナッコまこ」を目指しているってことよ!(その3)

2009-06-21 15:19:26 | Weblog

 梅田氏の日本のWebは残念を受けて、書いているこのお話

 日本の場合、梅田氏が語るような、上への利用は、利用しなければいけない人の間では、すでにネットを利用しなくても困らない状態になっているので、ネット利用は急には広がらない。
 その一方、日本では、横同士の情報交換のルートは、できかけていたんだけど(パソコン通信で)、それよりも、もっと広く、便利なものとして ネットが出てきたので、ネットを利用した、ホームページ、ブログが急速に広まったという話を書いた。

 でも、冷静に考えると、そーいう、普通の人の情報交換メディアというのは、すでにあったわけです。放送=ラジオ、テレビというものです。
 しかし、これらは、多くの人に同時に同じ情報を提供します。その上、交換という感じではないです。そこで、社会がまずしく、等質なものを求め、等質なものに憧れる(大量生産・大量消費社会)、昭和30年代~昭和50年代までは成功しますが、それ以降の、ある程度の収入を得て、等質でないものを求める、現代のメディアとしては、不十分なわけです。

 その先駆けが、1980年代中期に起こりました。このころから、アイドルが多様化(松本伊代、石川秀美、早見優などなど・・)、その後、アイドルというのが、矮小化していき、多様な価値観が生まれてきます。
 そーなってくると、多様な価値観を持った人たちに対する情報交換メディアが必要になり、その結果、アマチュア無線→パソコン通信→インターネットと発展していきました。

 そして、インターネットにおいて、ある人物が、その場にあった多様なコミュニティに属し(ただし、そのコミュニティ1つ1つは、あまり大きくないことも多い)、それほど高尚でもない情報を交換することによって、大きな利益を得るという、現在の日本のインターネットの形ができてきました。

 そして、このコミュニティは、作成することが容易になれば容易になるほど、(気に食わなければ新しいコミュニティを建てればいいだけなので)、同じ趣味の人が集まって、尖鋭化、過激化、まったり化?してきました。

そして、放送は、尖鋭化、過激化、まったり化していけばいくほど、ついていけなくなります。

今回は、ここまで。

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

ロボット検定って、今日あったの?

2009-06-20 23:32:25 | Weblog

ここのニュース
「ロボット検定」がスタート
http://event.media.yahoo.co.jp/nikkeibp/20090617-00000000-nkbp-bus_all.html

によると、きょう、ロボット検定っていうのがあったみたい??
(以下斜体は上記サイトより引用)

 ロボット技術に関する知識を出題する検定試験「メカトロニクス/ロボット検定(通称ロボ検)」が、スタートすることになった。第1回の個人向け本試験は6月20日(学校や企業での団体受検は6月15~26日)、東京・大手町で実施になる。理系学生や技術者、研究者を対象に、数学・物理学・エレクトロニクス・メカニズムなどのさまざまな分野を横断してロボットに関する総合的な知識を問う内容になるようだ。


どんなの?問題集とか、教科書とかあるのかなあ・・・??
きょうみしんしん(^^)・・・

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

どうしてコンピューターを小人さんに例えるのか?

2009-06-20 11:11:03 | Weblog

 よく、コンピューター等の機能を小人さんに例えることがある。

 プリンターの中には、小人さんが入っていてね、一生懸命色を塗ってるんだよ・・・
 ネットワークサービスは、小人さんが監視してて、データが来たってわかったら・・・

 デーモンなんてーのも、小人さんじゃないけど、擬人化っぽいし・・

 なぜ、小人さん、つまり人に例えるのか・・・

 人に例えると、話がうまくつながるから・・・かな?
 つまり、人ができないことは、コンピューターでもできない。

 人ができないっていうのは、100mを3秒で走るとか、そーいうことじゃなくって、
 人に処理を行う手順が話せないこと。

 手順が話せない=アルゴリズムがはっきりしない=コンピューターを動かせない。

 逆に言うと、

 コンピューター処理=アルゴリズムはっきり=人間の手順に置き換えて言えそう

 なので、人に例えて説明するのかな??

 ・・・って、ちょっと思ったので、書いてみた。

P.S ってことは、人間の究極の判断は2進法、YESかNOってことなのかな(^^;)

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

日本のWebはGoogleとかじゃなく、「スナッコまこ」を目指しているってことよ!(その2)

2009-06-19 16:49:26 | Weblog

 まえに、梅田氏の「日本のWebは残念」の話に関して、そもそも、日本の文化と、アメリカなんかの文化が違い、
アメリカは、文書なんか中心の分野だから、論文公開や議論のためにwebを使うということが広まるけど、
日本の場合、「会って信用する」という分野がまだ強い(メールで意思疎通より)っていう話を書いた

 日本の場合、そういった、論文とかの公開は、既存の学会、国際会議でよいと考える人が、多いと思う。
 素人が来て、いろいろ意見言っても、混乱するだけだしねえ。。。生産的ではない。
 知っている人が、生産的に活動するには、やっぱ、集まってやるのがよくて、そーいったメディアである、
学会、国際会議がある限りは、わざわざ、Webでやるのも。。。っていう部分があると思う。
 あるメディアがあると、新しいメディアのほうがよくても、一般にすぐには広まらない(地デジとか)

 一方、日本には、こーいった一般の人同士が、水平的な展開(=上ではなく、横のつながり)で、情報を交換する方法は、あったけど、乏しかった。たとえば、「ここのお店はおいしいです」、「このソフトのインストール方法」などは、学会で議論されることはなく、頭のいい人、上の人にとっては、不要な情報かもしれないけど、一般の人には、必要な情報で、このような情報を交換する場は、Web以前は、パソコンやネットの掲示板しかなかった。
 しかし、掲示板は議論になってしまうので、議論したくない、個人的感想を書きたい人は、そんな情報をかく場所がなかった。

 一般の人にとっては、学者の理論などは、まず普通の生活では不要で、多くの人に必要な情報は、このような「ここのお店はおいしいです」、「このソフトのインストール方法」だった。そこで、Web、ブログが出たとたんに、これらの情報が、Web、ブログで広まった。

 つまり、日本において、学者さんや頭いい人のメディアはすでに存在していたので、Webというメディアは、まだ浸透していない。
 一方、一般の人に必要な情報は、それを交換する手段がなかったので、ネットが出てきたとたんに広まった

 ってことになる。

 では、一般の人が必要とする情報を交換する手段はなかったのか?っていうと、あった。
 それが、放送だった。
 ところが、放送は、Webが出てきたことにより、いままでの展開をすることができなくなってきた。

 そのことについては、その3で書こうと思う。


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

UML等各種ダイアグラムのエラーチェック体系化(その4:Strutsによる開発のダイアグラム関係)

2009-06-19 12:56:11 | Weblog

シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
 前回ではダイアグラムの検証法について、UML→Strutsによる開発を例に話すため、まず、開発の流れを書きました。こんなかんじ。
(1)登場人物の整理

(2)登場人物にかかわる業務の流れを確認

(3)そのうち、コンピューター化する範囲を確認
     →ここで機能がでてくる

(4)機能ごとの入出力確認

(5)画面入出力から永続性項目取り出し(変換)→正規化→DB定義作成

(6)画面からフレームワーク決定→クラス決定

(7)画面遷移図、画面一覧→ActionForm,Action決定

(8)ActionForm,Action決定→struts-config.xml

(9)プログラミング

(10)テスト

(やっぱ、テストをいれました。その代わり、単体とか結合とか分けずに、単純にテスト)

今回は、この各工程で使われるダイアグラムの話。




■ま、結論から言うと・・・

こんなかんじかな・・・
(1)登場人物の整理
 ・組織図

(2)登場人物にかかわる業務の流れを確認
 ●アクティビティ図
 (または、・業務流れ図)

(3)そのうち、コンピューター化する範囲を確認
 ●ユースケース図
 ・ユースケースシナリオ
 (非機能要件まで考えるなら・i*など)

(4)機能ごとの入出力確認
 (・業務流れ図、・DFDなど)

(5)画面入出力から永続性項目取り出し(変換)→正規化→DB定義作成
  ・ER図
  ・DB定義書
  ・ファイル定義書

(6)画面からフレームワーク決定→クラス決定
  ●クラス図

(7)画面遷移図、画面一覧→ActionForm,Action決定
  ・画面遷移図
  ・画面定義書

(8)ActionForm,Action決定→struts-config.xml
  
(9)プログラミング

(10)テスト
  ・テスト仕様書

のちのちの理論を展開していくと、ダイアグラムも表も、抽象化して考えた場合、さほどの意味がなくなる。
(具体的には、表における正規化理論と、同じような正規系をダイアグラムでも行え、
 その結果、表も、ダイアグラムも同様のテーブルに展開できる)

そこで、図(ダイアグラム)や表について、
UMLで出てくるものについては、●、
そうでない図表は・
をつけてみた。なお、ソースコードに関しては、ここでは書かれていない。




次回は、これらの図表が、どのような関係を満たしていないといけないか、その2で記述した内容を元に、具体的に考えてみよう。



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

「本物のプログラマーなら、絶対にPHPは使わない」

2009-06-18 00:10:17 | Weblog

ここのいたいニュース
オタクをピクっとさせる10の発言
http://blog.livedoor.jp/dqnplus/archives/1275246.html

(以下斜体は上記サイトより引用)


一般論として、われわれ「ギーク(オタク)」はかなり穏やかな性質の人間が多い。物事を1人で徹底的に考えるのが好きで、他人と激しく意見を対立させることは滅多にない。だが、うまく挑発され、一旦議論のスイッチが入ってしまうと、もう止められない! 思いつく限りの言い分をとことん、最低2回は言い尽くすまで、話すことをやめようとはしないのだ。


ほー(^^)、


では、ギーク連中を正しく挑発するには、どんなことを言えばいいのだろうか?
よくぞ聞いてくれた!その台詞を10個紹介しよう。


ってことで、


第10位:「本物のプログラマーなら、絶対にPHPは使わない」


これが、10位っすか、レベル高!
これが正しいかどうかは別として、とっても議論を呼びそうだ。。。


第5位:「『Mac』に『Windows』に『Linux』?どれだって同じだろう?」


このまえ、なんか似たようなこと、言った気がする・・・(^^;)

そして、栄えある一位は・・・


第1位:「デジタル著作権管理(DRM)がそんなに悪いことだとは思わないよ!」


たしかに、「いっちゃらめえー」って感じだよね!




では、ウィリアムのいたずらも、ちょっと考えてみましょう
(念のために言っておきます。話題を呼ぶという話であって、
 正しいかどうかは別問題です)

10位
 Androidとか、iphoneとか、いろいろ出てるけど、
 ケータイアプリ開発は、MIDPに統一して、よくね?

9位
Ruby on rails(ほかのWebアプリフレームワークでもいいけど)
で儲かるサイト、簡単に作れるの?

8位
Strutsって、簡単にできることを、わざと手間掛けて作らせてるよね!

7位
わざわざ高いお金だして、Oracleにしなくても、MySQLで、よくね?

6位
このマシンに、Vistaじゃなくって、Windows98を入れたら、
すんげー、処理スピード速くなるんじゃね?

5位
これからは、Javaよりも、JavaScriptやったほうが、よくね?

4位
クラウドって、安全なの?

3位
Vistaとばして、Windows7って言ってるけど、
Windows7って、Vistaよりいいって、言いきれるの??

2位
Word,Excelいれなくても、OpenOfficeで十分だよね!!

1位
お前らの仕事見てたんだけど・・・
パソコンなんて、ゼータクだよ、
NetBookで十分だよ!!(From 社長 To 情シス)


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

UML等各種ダイアグラムのエラーチェック体系化(その3:UML等→Strutsでの開発の流れ)

2009-06-17 15:24:29 | Weblog

 シリーズ、 「UML等各種ダイアグラムのエラーチェック体系化」です。
 前回ではダイアグラムの検証法について、概要を説明しました。おおきくわけると、こんな感じ。

・ダイアグラムの入力に関するチェック
   →入力時矛盾チェック
     =入力データが前工程で作成されていて、利用可能になっているか

・ダイアグラムの処理に関するチェック
   →検証
     =入力データと出力データの変換の妥当性、正当性

・ダイアグラムの出力に関するチェック
   →出力時:成果物矛盾チェック
     =作成した成果物が、他の成果物の記述と矛盾してないかどうか

で、このうち、お手軽に出来るのが、実質、項目一致チェックである、「入力時矛盾チェック」。
そこで、この「入力時矛盾チェック」でどれくらいの効果があるのかを見てみようって
いうのが、これからのお話。




 なんだけど、その前に、開発で使われるダイアグラムについて考えたとき、
上記のチェックは、具体的に何を指すのかがわからないと、今後の話に支障を
きたすので、ここで、それを確認しておきましょうというわけ。

 で、さらにその前に、そもそも「開発で使われるダイアグラム」ってなに?
 ってことになりそうなので、UML等→Strutsを使った開発におけるダイアグラムをまとめますかにょ。

 っていうのが、今回と次回のおだい。




 で、考えると、開発の流れは、

(1)登場人物の整理

(2)登場人物にかかわる業務の流れを確認

(3)そのうち、コンピューター化する範囲を確認
     →ここで機能がでてくる

(4)機能ごとの入出力確認

(5)画面入出力から永続性項目取り出し(変換)→正規化→DB定義作成

(6)画面からフレームワーク決定→クラス決定

ここでStrutsを利用する場合
(7)画面遷移図、画面一覧→ActionForm,Action決定

(8)ActionForm,Action決定→struts-config.xml

(9)プログラミング

となっていく。あと、テストがあるけど、ここで話をきる。




で、次回は、この開発の流れと、図の関係を書きます。



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

任天堂、マリオで行き詰ったステージをコンピューターが自動でクリアする機能導入

2009-06-17 12:56:09 | Weblog

ここの痛いニュース
任天堂宮本氏、マリオで行き詰ったステージをコンピューターが自動でクリアしてくれる機能を導入
http://blog.livedoor.jp/dqnplus/archives/1274995.html

この「コンピューターが自動でクリアしてくれる機能」をDemo Playというそうなんだけど、

たぶん、任天堂としては、「公式クリア方式」として、このDemo Playで、クリア方法を示して、
ほかにも、クリアする攻略法を用意しておいて、「ヘビーユーザーさんは、他の華麗なクリア方法をみつけて、
自慢してくださいね!」って形にするんだろうな。。。

そーすると、ヘビーユーザーも初心者も両方たのしめる。
さらに、Demo Playも、はじめ1つのクリア方法を入れておき、あとでいくつものクリア方法を紹介していくということで、ずーっとそのゲームの鮮度を失わせず楽しんでもらえると・・・


・・・そーなってくると、任天堂が攻略法を示しちゃうことになるから・・・

・・・攻略本を出してる出版社は、どーするの??・・・

やっぱ、Demo Playの「みどころ」の紹介??

ゲームが、映画に、なっていくう・・・(^^;)


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

トヨタ生産方式(TPS)の中心は、手法ではなく、考え方のようだ・・・

2009-06-16 17:33:11 | Weblog

 このまえ、あるところで、トヨタ生産方式の話を聞いてきたんだけど(リンク先、はい、とかいいえを適当にクリックしてると、見れるようになる・・??)、それによると、よく、トヨタ生産方式というと、カンバンとか、手法に注目されることが多いけど、手法が大事なのではなく、その考え方が重要なようだ。

 手法から入ると、一時的うまく言っても、ものの見方が変わってないから、一過性でおわるそうな。
 見える化なんかもそうらしい。

 そうじゃなくって、考え方が大事で、「共通の価値観とベクトル」を持つって言うことが大切らしい。
 それにより、コミュニケーションも円滑に進むと。。。

 なるほどお。。。

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

UML等各種ダイアグラムのエラーチェック体系化(その2:エラーチェック体系)

2009-06-16 12:23:17 | Weblog

 昨日からはじめたUML等各種ダイアグラムのエラーチェック体系化(すみません、題名を短くしました。それと、ダイアグラム(図)と書くところを、ダイアログと何箇所か書いてました。すみませんm(__)m。直しておきました)。

 昨日も書いたように、はじめに「(1)まず、ダイアグラムにおける矛盾というものを考える。」から入りたいと思います。

 ダイアグラムのエラーチェックをするわけですが、そもそも、エラーはどんなところに起こりえて、どういうチェックになるのか?という話です。




■ダイアグラムの作成過程

 まず、UMLでもDFDでもなんでも、ダイアグラムを作るときには、

・ダイアグラムを記述するのに必要な情報をあつめて   (入力)
・それらを作成手順に従って作成し          (処理)
・作成結果(成果物)としてまとめ、配布、保存する  (出力)

という過程を通ると思います。つまり、ダイアグラム作成にも

     入力→処理→出力

があるわけです。




■作成過程とエラーチェック

 この過程において、どのようなチェックが可能であるか?ということを考えます。

・ダイアグラムの入力に関するチェック

 これは、前の工程から、本工程(対象ダイアグラムを作成する工程)に対して必要な情報を取り入れる部分に関するチェックになります。
 つまり、ダイアグラム作成のための必要なデータがちゃんと記載されているかどうか、前工程までに出ていない話を突如持ち出していないか(たとえば、誰も作っていない入力データが突如現れたり)といったことをチェックします。


・ダイアグラムの処理に関するチェック
 これは、入力値を事前条件、出力結果を事後条件として、検証していくことになります。
 処理としての妥当性をチェックするわけです。

・ダイアグラムの出力に関するチェック
 出てきた出力結果(成果物)が、他の成果物と矛盾してないかどうかチェックするものです。
 たとえば、DFDの上位プロセスで、あるファイルに書き出しすると書いておきながら、
 そのプロセスの詳細説明をしたDFDで、どのプロセスもそのファイルに書き出ししていないときが相当します。




■エラーチェックの体系化と補完関係

上記のエラーをまとめて体系化すると、以下のような感じになります。

入力時:入力時矛盾チェック
     =入力データが前工程で作成されていて、利用可能になっているか

  ↓

処理 :検証
     =入力データと出力データの変換の妥当性、正当性

  ↓

出力時:成果物矛盾チェック
     =作成した成果物が、他の成果物の記述と矛盾してないかどうか

そして、処理における検証が意味あるものになるためには、入力時のデータが正しいものでなければ意味ありません。
(例:毎月の売上合計額をだすとき、毎日の売上が間違っていたら、合計金額を出す手法は間違ってなくても、毎月の売上は間違い)
そして、検証結果が正しくないと出た場合、出力をチェックしても意味ありません。それ、まちがってますから。
さらに、せっかく出力しても、成果物が他の成果物と矛盾していたら、利用できません。
(前月の売上合計を元に翌月の発注量をきめるが、売上合計を出すのに3ヶ月かかる・・・とか)

ということで、「入力時矛盾チェック」、「検証」、「成果物矛盾チェック」は、どれか1つをやればいいというものではなく、補完関係にあります。

 ちなみに、「入力時矛盾チェック」、「成果物矛盾チェック」は、外部プロセスとの一貫性ということで、外部一貫性、
 検証は、そのプロセス内における一貫性ということで、内部一貫性と、いえるかもしれません。




■エラーチェックとコスト

ここで、これらのエラーチェックを吟味してみると、実現するためのコストが違うことに気づきます。

入力時:入力時矛盾チェック
     =入力データが前工程で作成されていて、利用可能になっているか
     →入力が、前工程に存在するかをチェックすればよい
  ↓

処理 :検証
     =入力データと出力データの変換の妥当性、正当性
     →検証を行う
  ↓

出力時:成果物矛盾チェック
     =作成した成果物が、他の成果物の記述と矛盾してないかどうか
     →成果物間の関連性を調べればよい

 「入力が、前工程に存在するかをチェックすればよい」というのは、仮に前工程のダイアグラムに関する情報が、すべてRDBに入っていたとしたら(この連載では、その方法を示します。ダイアグラムをRDBに入れる汎用的手法を)、これから使おうとする項目が、そのRDB内にはいっているか、SELECTをかければよいだけのことになります。

 検証については、いろんな検証法がでているくらいなので、結構大変です。

 成果物矛盾チェックは、成果物間の関係を調べるため、関係が簡単に調べられればいいですが、そうとは限りません。




 そこで、以下、簡単に出来る、「入力が、前工程に存在するかをチェック」について考えます。
 この簡単なチェックで、どれほどの効果があるのか、ということに関して調べていきます。

 ただ、その前に、抽象的な話が続いたので、次回は、ここまでの話を、UML+Strutsの例を出して、もっと具体的に説明したいと思います。



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

W3Cの「日本語組版処理の要件」だって!

2009-06-15 17:35:39 | Weblog

ここのスラッシュドット
W3C、日本語組版の要件文書を公開
http://slashdot.jp/it/09/06/15/0333256.shtml

で知ったんだけど、W3Cが、日本語組版の要件なんつーのを出しているらしい・・・

ここ
日本語組版処理の要件(日本語版)
http://www.w3.org/TR/2009/NOTE-jlreq-20090604/ja/


JISでも日本語組版ってあるけど、どーなんでしょー、詳しく中身を今見てないので、
どんなことかかれてるか、わかんないけど・・・
DTPエキスパート試験とかには、出るんですかね(^^;)

P.S あ、Unicodeの小林さんだ。(^^)


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

UML,ER,DFD等各種ダイアグラムのエラー・矛盾チェック体系化(その1:概要)

2009-06-15 16:07:03 | Weblog

で、昨日、はじめるといった、新連載のこと。
開発では、UMLなどでは、何種類かのダイアグラムが使われる。
そうでなくても、ER図やDFDなどのダイアグラムが使われる。

これらのダイアグラムにおける、矛盾・エラーチェックを体系化、自動化しようというのが、この連載の話。


で、どーいう話の構成になるかというと、こんなかんじ

(1)まず、ダイアグラムにおける矛盾というものを考える。
 ダイアグラムには、この図にこの記載があったら、他の図にも、同じ言葉が書かれていないとおかしい
といったものがある(DFDのコンテキストダイアグラムに外部から入力があった場合、そのコンテキストダイアグラムを詳細化したDFDにも、同じ入力がないとおかしい)。
 また、あるダイアグラムに書かれた結果が、他のダイアグラムと関係が合ったりすることもある。

 これらのダイアグラムにおける関係を整理し、その上で、ダイアグラム間の矛盾というものを考える。

(2)矛盾チェックとコストとの関係
 上記(1)の矛盾チェックは、大きく3種類にわかれるけど、それぞれ、コストが違う。
 これらのコストと、その効果について考える。
 そうすると、ダイアグラム間の項目一致をチェックするというのが、効果的という話になる。

(3)あらゆるダイアグラムをRDBに入れる方法
 もし、ダイアグラムの全内容がRDBに格納出来れば、項目チェックはselect文に帰着できる。
 そこで、あらゆるダイアグラムを、ノードとリレーションという関係で捉え、RDBへ格納する方法を
紹介する。




 話に興が乗れば、このあと、自動生成との関係なんかについても、書きたいと思います。

 次回は、まずは、第一章から・・・

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