ケータイから家のエアコンが付けられるってこと？ＶＮＣ＋パソコンでリモコンのWinLIRC

　前に遠隔操作の話として、ＶＮＣのことを書きましたけど、日立システムが、μＶＮＣっていう、ケータイ（au）から、パソコンを操作できるアプリを出しています。

　まず、これが、前提条件。

　で、今日、こんなサイトを見つけてしまった。。

パソコンでリモコン　ＦＵＴＡＢＡ　ＨＯＭＥ
http://www.256byte.com/remocon/index.html

パソコンでエアコンやテレビなどのリモコンを操作するフリーウエアのドライバソフト、WinLIRCを紹介してあるサイトです。

うん、この２つを組み合わせると。。。。

---

暑い日、家のエアコンを入れて、涼しくしておきたいとき
（まあ、寒い日、家のエアコンをいれて、暖めておきたいときでもいいけど）

●家に着くちょっと前、ケータイから
μＶＮＣをつかって、
ケータイからパソコンを起動し、「リモコン操作プログラム」を立ち上げ、
エアコンのスイッチをオンにする

●そのころ、家では
μＶＮＣの上記操作により、
「リモコン操作プログラム」は、おもむろにエアコンの方向に、
ぎーんがちゃんとリモコンをむけ
WinLIRCで、リモコンから赤外線をエアコンへ発射！
エアコンがつく

●おうちについたことは
エアコンがつけてあるのですずしい！

とまあ、ユビキタスみたいなことが、実現できるってこと？

---

ただ、問題は、パソコンの「リモコン操作プログラム」。
ソフトはWinLIRCを使って、つくれば、いいかもしんないけど、
問題は、ハード。

きっと、棒みたいなのにリモコンがついていて、
あらかじめ、エアコンの場合には、棒を何センチのばして、どのくらいの位置に回転させる
っていうのが登録してあって
（たぶん、設定モードっていうのをやると、自由に棒を、回転収縮できて、登録ボタンをおすと、その角度、高さを登録できる。設定モードのときに、ためしにリモコンを操作してみることも可）
エアコンをいれるとなったら、リモコンが、あらかじめ設定してある高さまで、ぎーん、がっちゃんって動くわけなんだけど。。。

　それって、おばかっつーか、間抜けな光景だったりして（＾＾；）

　うーん、大手さんでは、だしてこないな、そんなみっともはずかしいの。。

　でも、中小企業なら、わかりませんぞおー

・家のそとからでも、リモコン操作可能
・一定時間になったら、テレビをつけたり、エアコンをいれたり。。。

　なーんつーかんじで、こんなソフト＆ハード（機械仕掛けで伸びる棒＆その棒についてる回転＆角度を変えるリモコン）が出てくるかも。。。

---

　でも、だからといって、この装置＋ロボットを用意して、「リモコンで離れた場所から車を監視＆動かします。顔認識がついていて、一定時間車を覗き込んでいる人がいると、知らせます。そして、まずいとなったら、車の外からロボットに急発進するように、操作できます。駐車禁止逃れに最適」とか売り出したら、駐車禁止は免れても、道路交通法のほかの条文にひっかかりそう（って、ひっかかるかどうかわかんないけど）なので、駐車禁止のがれには、つかえなさそうですな。。。

　。。。あたりまえか（＾＾；）

UMLでバグを減らしたり、自動生成するための必要条件

　以前に書いた、UMLでバグのないプログラムは作成可能なのか？、ＭＤＡは可能か？を考える。のアンサー編。

まず、自動生成可能というためには、以下の条件が必要ってことは、ここに書いた

・ユーザーにもわかる最小の動作単位
　（これに、産能大記号を利用することを以前書いた）で仕様を記述し、
　その最小の動作単位に対応するプログラムをライブラリで用意しておく

・この動作を、明確・かつ複雑にしないため、手順を状態に変換して記述する。

今回は、後者について、説明することで、ＵＭＬ周辺の理論との関連を書きたいと思います。

---

　この記述方法だけど、

　　　ある手順が終了したら、
　　　ユーザーにもわかる最小の動作単位を、
　　　　引数なになにで実行し、
　　　　結果なになにを得る

というように書く。

　ここで、あらかじめ、その最小の動作単位に対応するプログラムをライブラリで用意しておくのであれば、その入力（引数）と、出力結果は明確である（というか、これを、明確にしておく）。
　たとえば、受注先、納品先、受注品目、数量、単価を入力とし、帳票出力を実行し、受注票を出力する
だったら、
入力：受注先、納品先、受注品目、数量、単価
出力：受注票
最小の動作単位：帳票出力
となる。実際には、帳票出力でなにを入力とし、どういう出力をだすかによって、上記の入力と出力項目が決まる。ここの矛盾や入力項目の過不足、出力イメージの違いは、帳票出力ライブラリが実際に作ってあればきまる。

　なので、あとは、この動作をするタイミング、手順になる。

　ちなみに、以下の工夫をしなくても、手順がはっきりしていれば、シーケンス図に表し、そこから自動生成するのは、問題ない。

---

　ここで、動作タイミングを、直近の作業Ａ（Ｂ，Ｃ，と複数あるかもしれない）というように記述する。

　そうすると、これによって、データをハッシュマップとかにいれておいて、処理がおわったら、「おわったよ」情報をその中に入れておくと、そいつを見るだけで、次の処理は判断できる。

たとえば、

　受注データを入力する
　　｜
　受注票を作成する

という順番の場合、

　受注データ入力完了後で受注票を出力していない場合、受注先、納品先、受注品目、数量、単価を入力とし、帳票出力を実行し、受注票を出力する

っていう記述になる。
プログラムとしては、コントローラーが、モデル帳票作成（受注票のデータ）を起動するとき、結果が入っているところをチェックし、受注データ入力が完了、受注票出力が未完になっているものをチェックし、そういうものがあれば、モデル帳票作成（受注票のデータ）を起動すればいい。

---

　実は、ＩＰＡなんかの契約用の仕様書に書くときには、こんなようにかく。これは、最近風で言う、契約による設計DbCとおんなじはなしで、

事前条件：状態部分（動作タイミング）＋入力
事後条件：出力結果

　になる。

　じゃあ、契約による設計と、どこが違うかというと、契約内容にかかわる部分がちがう。

　契約による設計では、事前条件を利用して、事後条件を作成するという部分（ここを開発するわけだが）が、不明確（つまり、できるかどうか、作ってみないとわかんない）かつ、仕様を出す人と、仕様を聞いて作る人の間で、同じものをイメージしているかどうかわかんない（つくってない＝みてないので、想像でしかない）のにたいし、

　こちらのほうでは、そういうライブラリをつくっておいて、あらかじめ、ライブラリの範囲内で、開発を行うようにしている。なので、そのライブラリをみれば、結果はわかるし、なにが必要がもわかるってことになる。

　だから、契約による設計は、契約完了後、中身を作るのに対し、このしくみだと、契約ができた時点で、もはや、設計は完了している。むしろ、契約をつくる行為が設計といえるが、
　この契約をつくる

　　＝ライブラリの並び順をきめる
　　　　→ライブラリは業務の最小単位になっているので、
　　＝業務の最小単位レベルで、業務をきめる

　ってことになる。つまり、お客さんが設計することになる。

---

　実際の場合、ライブラリ＝業務の最小単位は、ＳＯＡみたいなサービスで提供されることも可能になる。

　この場合、業務の最小単位レベルで、業務をきめるってことは、そのＳＯＡの起動順番を定義することであり、これは、プロファイルなどに書かれ、マッシュアップされることになる。

　ってことは、このしくみは、まさしくＳａａＳっていうことになってくる。

---

　これ以上、周辺の話を説明してると、あまりにも長くなるので、ここできるけど、結局、今回書いたまとめとしては、

・ユーザーにもわかる最小の動作単位（これに、産能大記号を利用することを書いた）で仕様を記述し、
　その最小の動作単位に対応するプログラムをライブラリで用意しておく

・そして、仕様書は
　　　ある手順が終了したら、
　　　ユーザーにもわかる最小の動作単位を、
　　　　引数なになにで実行し、
　　　　結果なになにを得る

というふうにかくと、ここから、自動生成できるようになってくる。

この辺の話から、今度は形式仕様記述言語の問題点などの議論とか、自動生成の議論とかを、はじめてみたいと思う。

　ただ、このシリーズ、ものすごく不評で、こればっかり書いていると、見る人減っちゃうので、これ以外の話もかいて、覚えていたら、そういう話も書こうかなと思ってます。

ケータイで、ＪＰＥＧ画像が、メールの内容に応じて、喜怒哀楽を示すってことですか。。。

　まえに、ケータイで、表情を変えるって言う話を書こうとして、「また次回」みたいな形にしちゃったと思うんですけど？（気のせいかなあ。。）、今日は、その残務整理。

　そこで、書こうとしていたのは、これです。

MascotCapsule Face Edition
http://www.hicorp.co.jp/products/index.html

そこのサイトの下のほうに、説明があります。こんなかんじ
（以下斜体は、上記サイトより引用）

MascotCapsule Face Edition

　MascotCapsuleの機能拡張版であるFace Editionは、携帯メール・チャットでの、より人間的なコミュニケーションを可能にする携帯電話用アプリケーションです。特定フォーマット（JPEG、BMPなど）で保存された画像にある、目・眉・口など個を特徴づける部分を指定することによって、指定箇所にアニメーション効果を加え、平坦な画像に生き生きとした表情を加えることが可能となりました。Face Editionの機能を使用することによって、メール上の特定の文字に反応して、添付された画像が喜怒哀楽の表情を示すなど、多彩な表現力をメールに付加します。なお、本機能のご利用にあたっては、送り手、受け手ともに同アプリケーションが搭載されていることが必須となります。



ほー、メールの内容によって、画像の表情を変えられるんですね。
てーことは、TVML Miniみたいなのが、ケータイでできるってことだよね。
まー、メールより、もっと一般的に、キャラクタの表情を変えられる関数（メソッド）の法が便利そう＆応用広そうだけど

---

で、いまMascotCapsule Developer Networkみてたら、ウィルコム製の話が出てるだけでなく、Getting Startedに、MIDPでの、開発方法が載ってるみたいだ。。これは、チェックですな（＾＾）

遠隔操作は、今はＶＮＣだけど、将来的にはＷｅｂアプリかな？ＳａａＳの流れからすると

　以前のブログで、ＤＴＰの遠隔操作の話題を書いたけど、ＤＴＰにかかわらず、一般に、今、遠隔操作、とくに、お客さんが現在の状況をみて、修正もできるようにしたいとしたら、

・ＶＮＣを使って遠隔操作する
　→窓の杜の場合のダウンロード先は、ここ
・いっそのこと、ソフトイーサで接続し、シンクライアントとし、
　クライアントの１つを客先に（って、できるんかい？？）

なんかが、思いつきそう。

---

　でも、ＳａａＳが最近流行ってるってことを考えると、サーバーにアプリをおいて、お客さんも、作成する人も、ブラウザでみるっていう形になってくると思う。ＤＴＰの例だと、いっそのこと

・サーバーを自社におき
・必要な文章、写真、イラストをサーバーにおく
　　→これはべつに、Ｗｅｂで作成しても良いし、
　　　いままでのアプリを使って、サーバーにファイル転送してもいい
・Ｗｅｂサービスとしてレイアウトソフトを提供し、
　ブラウザから、レイアウトを行う
・完成したら、そのＷｅｂサービスを使って、お客さんも見て、
　修正もしたかったらしてしまう。

っていう感じになるかもしれない。
これだと、ＶＮＣの場合は、お客さんと、自社での操作の差などをつけるのは、アプリをいじることになるので大変だけど、ＳａａＳで提供すれば、プロパティ変更などでできそうだし。。。
　また、プリンタ出力したい場合、ＰＤＦで表示すれば、お客さんのほうで出せるけど、ＶＮＣだと、アプリから印刷をかけても、サーバーのあるところで印刷するだけで、クライアントのお客さんからは、印刷できないし。

---

　とくに、ネットの回線速度が上がれば、サーバーを、自社でなく、印刷会社においてしまうっていう手もあるかもしれない。そうすれば、すぐに印刷に回せるわけで、その場合、データが印刷会社にあるので、印刷上のＰＳ出力の事故がへり、ＰＳ出力後の印刷会社へのデータ送信の手間がはぶける（一般にＰＳ出力したものを送るとたいへんだけど、素材１つ１つを転送するならそれほどでもないし、そもそも、高精細のイメージデータは、印刷やさんでスキャンする場合は、素材転送の手間もはぶける）。

　唐突な話のように聞けるかもしれないけど、年賀状なんかは、Ｗｅｂから注文、印刷できるという話はあったと思うので、アプリ的に見れば、それが、雑誌や本、チラシなんかに広がっただけ（もっとも相手は個人顧客ではなく、編集、デザイン会社にかわるので、社会的にみれば、大きく違うけど、アプリ的にみれば、しくみは基本的に似たようなもんで、対象範囲が広がっただけ）とも見れるので、あり得ない話ではないような気もする。。

アメーバブログ、８月以降の拡充内容（が書いてあるんだと思う。たぶん）

　日本証券新聞７月３１日号（実際には、金曜日夕方に、すでに売られている）の１６面、

　藤井英敏の実戦株式投資　ズバリ！稼ぎの極意　第８回　
　「ウェブ２．０」時代到来　活躍する銘柄は・・・？

　に、サイバーエージェントの話として、以下のように載っていますね
　（以下、斜体は上記記事より引用）


　サイバーエージェント（４７５１・東マ・一株）は、ブログ事業を８月に拡充します。１ヵ月以内の再接続の場合、会員ごとに異なる専用トップ画面を自動的に表示し、記事の投稿や気に入ったブログの更新状況の確認を容易にします。会員の利用時間を増やし、広告収入を増やし、年内に同事業の単月黒字化を目指します。


　ブログ事業ってことは、アメーバブログですよね。
　うーん、なんか、前、藤田社長は　「アメーバ」事業は、リニューアルするが、誰も見たこともないものにする。と発言してたけど、個々人の専用画面を作る程度なのかなあ。。。

　ウィリアムのいたずらは、てっきり、はじめに
「おかえりなさい、ご主人様」って、メイドさんがでてきて、メイドさんがメニューを開くと、
新規作成とか、お話とか、いろいろ書いてあって、お話っていうのを選択すると、ニュースをまとめて、「今日は、こんなことがありました」って、いってくれて、メイドさんと一緒にゲームできたりとか、受験生の場合には、受験勉強できたり、そのくらい大きくかわるのかなーと思っていたのですが。。。うーん！

Ｐ．Ｓ　勉強ができたり、ゲームができると、利用時間長くなって、広告だせるよね。
　自分が勉強するってのもアリだけど、メイドさんが勉強してきて、お話するっていうのもアリかも。あとＳＰＩ高得点を目指して、メイドさんが問題出してくれるとか。。

ＡＳＰの発展形ＳａａＳにおけるプログラム連携のＡＰＩとしてもＸＭＬ－ＲＰＣはアリだと思うね

　日経ソリューションビジネスにのっていた、最近のことばといえば、
　ＳａａＳ（ソフトウエア・アズ・ア・サービス、読み方：サース）
だと思います。え、そんなことない、もう、古い言葉（＞＿＜！）


　ＡＳＰ同様、ネットワークで提供するけど、
　ＡＳＰとはちがい、プログラムは１本でも、各顧客ごとにプロパティファイルを切り替え、顧客ごとの設定にする。また、プログラムのマッシュアップなども行うといったもの。
（ＡＳＰの場合は、マッシュアップしないのがふつうだと思う）

　さて、ＳａａＳにおいて、プログラム連携（マッシュアップ）する場合だが、この場合、ＳＯＡＰも考えられるけど、簡単さでいえば、以前に書いたような、ＸＭＬ－ＡＰＩなんでしょうな。

。。。なーんて思った。

Web２．０開発方法のTopCoderとSun×RECRUIT Mash up Award

日経ソリューションビジネス２００６年７月３０日号（今の号）の５２ページにこんな記事がある

　　　　Ｗｅｂ２．０の成功モデルTopCoder
　　　　米大手も注目のプログラムコンテスト

　TopCoderとは、「賞金つきプログラムコンテストを開催する企業」と５２ページでは書いてあるが、５３ページで、TopCoder登録者数が類型８万人と、単位が「人」のため、多分、賞金つきプログラムコンテストに参加する人のほうが、正しい定義なのであろう。

　そして、TopCoderのコードを利用して開発していくそうだ。
　たしかに、これだと、コンテスト「参加者」が、システムを作っていくという意味でＷｅｂ２．０的な発想だろう。

　この記事は海外の話として出ていたが、日本のSun×RECRUIT Mash up Awardも、もし、リクルートが優秀なものを採用するとなれば、それに近い話といえるかもしれない。
　ただし、海外の場合は、プログラム開発部分を利用しているのに対し、リクルートのほうは、企画アイデア全体だから、もっと広い範囲と言えるであろう。

---

　でも、思いました。

　十年以上前は、上級ＳＥなど、システムエンジニアが重視されました。

　その後、プログラマの時代がきました。
　ＩＰＡでは、未踏のひとを、スーパークリエーターのほかに、
　　「天才プログラマー」
　といい、「天才ＳＥ」といわないことからもわかる。

　で、つい最近、テスターの時代が来た。イベントでテスティングをやって、競い合うみたいな。

　そして、今度は、トップ「コーダー」だ！！

　さあ、みなさん、さらに次の時代に、くるものは。。。もーわかっちゃいましたねー！！

　　　カリスマ・オペレーター（＾＾；）

　どんなオペレーターだ？？うーん、じゃあ、こんなのはどう？？

　　　アイドル・オペレーター

　アイドルのつづりは、ＩＤＯＬ、それともＩＤＬＥ？

　ウィリアムのいたずらは、この業界に入ったころにオペレーターしたことあるんだけど、たしかに、ＩＤＬＥオペレーターでした。ひまなのよねー。オペレーターって。忙しいときは、忙しいんだけどね（＾＾）Ｉ

ＸＭＬ－ＲＰＣを使ってＡＪＡＸでＰＣを遠隔操作に仕様変更「いもうとデスクトップ」ＡＪＡＸ版。

　いままで、「いもうとデスクトップ」ＡＪＡＸ版について、やってきたわけなんですけど、仕様変更して、受け渡しデータの形式を、ＸＭＬ－ＲＰＣに準拠しようかと思うんです。
　で、ＸＭＬ－ＲＰＣの仕様はこちら

XML-RPC Specification
http://www.xmlrpc.com/spec

これにもとづくと、送る命令は、こんなかんじになる

＜?xml version="1.0"?＞
＜methodCall＞
   ＜methodName＞imoto.doJob＜/methodName＞
   ＜params＞
      ＜param＞
	＜struct＞
	   ＜member＞
	      ＜name＞userName＜/name＞
	      ＜value＞＜string＞ユーザー名＜/string＞＜/value＞
	    ＜/member＞
	   ＜member＞
	      ＜name＞password＜/name＞
	      ＜value＞＜string＞パスワード＜/string＞＜/value＞
	    ＜/member＞
	   ＜member＞
	      ＜name＞serverName＜/name＞
	      ＜value＞＜string＞命令を行うサーバーの名前・ＩＰ＜/string＞＜/value＞
	    ＜/member＞
	   ＜member＞
	      ＜name＞commandLine＜/name＞
	      ＜value＞＜string＞実行する命令（DIRなど）＜/string＞＜/value＞
	    ＜/member＞
	＜/struct＞
      ＜/param＞
   ＜/params＞
＜/methodCall＞

（上記＜　＞　￥は、本当は半角です）

---

で、この命令を受けて、実施結果を返す場合、正常なら
こうなる

＜?xml version="1.0"?＞
＜methodResponse＞
   ＜params＞
      ＜param＞
         ＜value＞＜string＞処理結果＜/string＞＜/value＞
      ＜/param＞
   ＜/params＞
＜/methodResponse＞

（上記＜　＞　￥は、本当は半角です）

なお、処理結果のところは、実際には、結果に＜＞（半角）が入るので、ここは、
＜![CDATA[ 実際に送りたい処理結果 ]]＞
として、送る （ＹｏｕＴｕｂｅのＲＳＳが、このように送っている）か
この結果の部分をなにかの形でエンコードするかは、思案中

---

失敗のときは、こうなる

＜?xml version="1.0"?＞
＜methodResponse＞
   ＜fault＞
      ＜value＞
         ＜struct＞
            ＜member＞
               ＜name＞faultCode＜/name＞
               ＜value＞＜int＞9999＜/int＞＜/value＞
            ＜/member＞
            ＜member＞
               ＜name＞faultString＜/name＞
               ＜value＞＜string＞エラーメッセージ＜/string＞＜/value＞
            ＜/member＞
         ＜/struct＞
      ＜/value＞
   ＜/fault＞
＜/methodResponse＞

（上記＜　＞　￥は、本当は半角です）
９９９９のところは、実際のエラーコードが入ります。

---

ってすると、サーバーCGIも修正しなきゃ

２ちゃんねるのひろゆき氏が取締役のニワンゴが、エイベックスのa-nationに参加の皮肉！

２ちゃんねるのひろゆき氏が取締役の会社、「ニワンゴ」が、エイベックスの開催する夏のビックイベントa-nationに参加するそうです
ここ　http://niwango.jp/new/#news060724
（以下斜体は、上記ニワンゴサイトより引用）

７月29日より開催される「a-nation'06 powered by ウイダーinゼリー」に、ニワンゴも参加します。
ライブ会場に、ニワンゴもいるので見つけたら声をかけてくださいね。
さらにm@niwango.jpに【a-nation】と書いて送信すると、a-nation情報を随時配信していきます。


ほー、１年前には、かんがえらないよーなことだ（ここ）

---

では、なんで、そんなことをするのかというと、のまねこ問題で、エイベックスと知り合ったからというよりかは（ひょっとして、それもあるのかもしれないけど、いや、ないな　＾＾）、ここのニュースの関連のようだ。


ドワンゴ、「a-nation'06」と携帯サイトの連動企画開始
http://k-tai.impress.co.jp/cda/article/news_toppage/30373.html

つまり、ドワンゴの株を買い、エイベックスは、ドワンゴを関連会社にした。
→エイベックスとドワンゴは協力提携関係。
ニワンゴはドワンゴの子会社である。
→親会社がエイベックスと提携してる以上。。。（＾－＾）


　　うーん、なんちゅーか、ひにくっちゅーか（＾＾）

---

　え、人ごとのように読んでいるそこのあなた！
　あなたが会社員だったら、わかりませんぞー！
　いままで、敵視していた会社が、複雑に合併して、いつのまにか、自分の親会社！ってことは、あり得ない話じゃないかもよ（＾＾）

「ボーダフォンライブ！」が「Yahoo！ケータイ」になるだけでもダサいのに、このマークは何？

　ボーダフォンがソフトバンクになることは、きまったけど、具体的なサービス名がどうなるかとかについては、発表が無かったけど、ここのニュース

10月1日、「ボーダフォンライブ！」は「Yahoo！ケータイ」に
http://plusd.itmedia.co.jp/mobile/articles/0607/27/news060.html
によると、ボーダフォンはYAHOO!ケータイになるそうです。

　それだけでも、十分ダサいけど、もっとすげーと思うのは、マークです。

　こんなかんじ
http://image.itmedia.co.jp/l/im/mobile/articles/0607/27/l_sa_bb1.jpg

まあ、Ｙ！Ｋｅｔａｉは、しかたないにしても、
Ｓ！メールとかＳ！アプリって言うデザイン、ダサくないか？
そんなことない？？

うーん（＾＾；）

家のドアが、Ｓｕｉｃａで開いちゃうかもしれないってこと？

　ここのニュース
交換漏れか、カード式玄関錠が「Ｓｕｉｃａ」でカチャ
http://headlines.yahoo.co.jp/hl?a=20060727-00000315-yom-soci

によると（以下斜体は、上記ニュースより引用）

　錠前メーカー最大手の「美和ロック」（東京都港区）製のカード式玄関錠に、間違ってＪＲ東日本のＩＣカード「Ｓｕｉｃａ（スイカ）」を差し込んだところ、ドアが開いてしまうトラブルがあったことがわかった。


おお、
ってことは、大金持ちの人や、すんげー稼いでる会社の玄関が、カード式なら、
とりあえず、ＳＵＩＣＡいれてみようってことですか（＾＾；）

　なんか、これ、やばくない（＾＾；）？？

　カード式の家の人、会社の人は、とりあえず、ＳＵＩＣＡ入れて、試してみるでしょ。
　。。でもあいちゃったら・・・しゃれにならないよね（＾＾）

要求仕様書の書き方に従えば、本当に要求は記述できるのか？構造的に記述は不可能ってことはないか？

　UMLでバグのないプログラムは作成可能なのか？、ＭＤＡは可能か？を考える。シリーズで、前回、


・ユースケースの段階で、既知のユースケースを組み合わせるようにする


ってことを次に書くとかきました。

で、この既知のユースケースの基本単位となるのが、「産能大記号」だということは「前回のつけたし」で書いたのですが、組み合わせかた、これが基質特異性の話に関係するのですが、それについては、書いていません。

　きょうは、その話のもととなる、ＨＯＷをＷｈａｔに転換させる方法っていうのを、書きます。

---

　最近、形式主義ばやりで、じゃあ、Ｚっていうので、こんなお話（ＰＤＦ）をみていたら、89ページ目（ただしこのお話は８５ページ目から始まっている）に、こんなことが載っていた。
　要求仕様書の不統一の解消に、Ｗｈａｔで記述するところと、Ｈｏｗで記述するところの２つが記述されていて、要求仕様である以上Ｗｈａｔに統一すべきことは言うまでもないで終わっている。

　これって、一般的に、要求仕様で言われることで、Ｗｈａｔで書け！と言い切っているものがおおい（上記のお話のように）。

　しかし、このとき、Ｗｈａｔで、仕様書に出てくるすべての物事が表現できればＯＫだが、もし、Ｗｈａｔで表現できないものがあったら、
　「要求仕様はＷｈａｔで書け」
　といった時点で、要求仕様は記述漏れを導くことになる。これが、あるかないかを、今日は書いてみたい。

---

　なお、Ｗｈａｔで表現する場合、もうひとつ、致命的な問題があることは、すでに知られている。
　つまり、Ｈｏｗというやり方がある得ない方法でもＷｈａｔは記述することができ（例：ぞうを、冷蔵庫に入れた状態で保存せよ＝＞ゾウを冷蔵庫にいれる方法ＨＯＷは示す必要はない）、その場合、まったくできないことが、要求仕様にでてきてしまい、それをかなり下流になってから、気づいた場合、開発自体がとまったり、中止になったりする。

　ゾウを冷蔵庫に入れるケースでは、ありえないが、

　地図の検索条件に、地名検索、郵便番号検索を含む

　という仕様があったとき、Ｗｈａｔとしての要求仕様はＯＫだが、
　これを実現するＨＯＷを書かないと、これ、できそうに見えるので、物事はどんどん進んでしまって、最後に（＞＿＜！）ってことになる。
　（上記の場合、たしかに、地名検索、郵便番号と緯度経度の対応表があればできる。しかし、地名は、刻々と変わる（合併するから）したがって、地図をどんどん更新されて、地名緯度経度対応表を更新しないと、おかしなことになる（旧地名で検索し、新地名で表示される）。このようなことを防ぐには、マスタ更新プログラムをつくらないといけないが、マスタ更新が必要であるというのは、Ｗｈａｔだけからでは、考えにくく、Ｈｏｗまで考えて、この業務の流れを全部追っていったときに気づくことが多い）。

　このようにＷｈａｔだけ書いてしまうと、Ｈｏｗの部分でできないことがあるという問題は、ＳＤＬＣの断層問題といわれて、権威の人の中でも、佐藤氏などが指摘しているので、まあ、有名な問題なので、今回は省略する。

---

　さて、話をもどして、世の中のものを、すべてＷｈａｔで表現できるか？っていわれると、できないものがある。

　たとえば、手待ち時間というのを表現するとき、「手が空いている時間」のように状態で表現できる場合はいいけど、「うちの会社では、Ｂという加工をし終わったあと、倉庫Ｚに在庫がなく、Ａという加工がおわって、倉庫Ｚに搬入されて、Ｂという作業に入れるまでの時間」という定義のとき、これを正しく表現するには、
・ＡからＢへ処理が進むという、業務フローと、
・そのＡからＢへという流れが、コンピューター上で表現できるということが担保されている
状態でなければ、この定義は無意味になる。
　業務フローを示すこと自体、本来ＨＯＷだし、コンピューター上で表現できることの担保をとるってことは、まさにＳＬＤＣの断層問題、ＨＯＷにまで踏み込まないとできない。

　一般に、上記のような、動的な状態を表現する場合、静的な内容である、「何」というものでは表現できず、どうやってやるのかというＨｏｗの部分に踏み込み、動的な流れを表示することによって、動的な状態は表現できる。

　したがって、Ｗｈａｔだけでは表現できないということは、本来、ある。

---

　っていわれても、こまるだろう。
　実際、こんなことを考えている人はいないから、元請けがＷｈａｔだけで表示しろ！ということを言ってくることはありえるわけで（現に前出の話では、それを求めているわけで）、そのときに、下請けの人間が、いや、Ｗｈａｔでは表現できないものもありますっていったら、「オタク技術力ないよ、もおいい」っていって、切られるのがオチだ。
　元請けは、そこまで考えてないし、権威のひとは、Ｗｈａｔで表現できないものはないっていってないし、むしろ、権威あめーりかん！な人は、Ｗｈａｔで表現しろ！といってる。（いつもあげている本に、それはかいてあるけど、今手元にないので、証拠は省略）。

　で、どうするか。。。

---

　実は、Ｈｏｗを、Ｗｈａｔで書き表してしまう（ように見える）という、方法が存在する（なので、Ｗｈａｔで書けというのは、あんまし意味ない）。

　サ変名詞ということばがある。するをつけると動詞になる、名詞（処理する、受注する）
　これと、状態をくみあわせると、できる。

　さっきの例だと
Ｂという加工をし終わったあと、倉庫Ｚに在庫がなく、Ａという加工がおわって、倉庫Ｚに搬入されて、Ｂという作業に入れるまでの時間

・無在庫とは、加工処理Ａされた在庫がないこと
・作業Ｂ中断開始とは、作業Ｂ終了後、無在庫の状態だった場合
・作業Ｂ中断終了とは、作業Ｂ中断開始後に、加工処理Ａされたものが届いた状態
・手待ち時間＝（作業Ｂ中断終了－作業Ｂ中断開始）の総和

このように、
・Ａをする、Ｂをするを、サ変名詞Ａ，Ｂ（上記の例だと、加工処理Ａ、作業Ｂなど）と言い切る
・それぞれの状態にたいして、状態の名前をつけると
とすると、本当はＨＯＷを言い表しているものが、あたかもＷｈａｔになる。

---

　じつは、この効果があるので、イベントクラス（受注など）が、存在してしまうことになる。
　ＨＯＷっていうのは、方法＝メソッドで記述されるものである。
　ってすると、方法は、動作の流れなので、動作っていうのは、基本的にメソッドで定義されるものなんだけど、実は、クラスになっちゃうことがある。

　これが、イベントクラス。

　これが、おきるのは、上記のように、ＨＯＷをあたかもＷｈａｔみたいにかけてしまうっていうことに起因する。

---

　そして、このやりかただと、どこまでも、ＨｏｗのＷｈａｔ化ができるっていうのは、Ｓｔｒｕｔｓがしめしている。Ｓｔｒｕｔｓで、Ａｃｔｉｏｎは動作、本来メソッドにするようなもんだが、Ａｃｔｉｏｎはクラスになる。これで、つじつまが合う理由は、このＨｏｗのＷｈａｔ化ができるっていうことのためでもあるんだけど、そこまでは、元請けは、求めてこないので、言う必要はない。

　ってことから分かると思うけど、ＨｏｗとＷｈａｔっていうのは、実はあいまいだ。
　むしろ、業務フローをつくって要求分析することからもわかるように、要求分析段階から、かなりＨｏｗを意識して、Ｗｈａｔを書いている。これは、ある物事を定義するには、動的な側面をみないと定義できないからで、実際に思っている以上に、ＷｈａｔとＨｏｗは不可分だ。それをだれも、言い切っていないだけである。
（きょうここに、ウィリアムのいたずらが言い切った）

---

ってことで、

・既知のユースケースの基本単位は産能大方式
・業務フロー（Ｈｏｗ）は、状態と、サ変名詞で表現できる

ってことの材料はそろった。あとは、これの組み合わせの話だが、本当に長くなったので、今回は、ここまで。

カンプや校正紙を表示、操作結果をＷｅｂＡＰＩで送信、お客さんもレイアウトできるってのはアリかも。

　きのう、松丸アナのトレンドたまご（って、松丸アナだけがトレンドたまごやってるわけじゃないけど）で、Ｍｏｖｉｅ　Ｃａｒｄｓっていう、動画を部分的にきって、それをおいていって、編集するって言うのをやってました。
　これ自体では、あんまり利用価値ないとおもうけど、これを応用して、チラシや情報誌などで、

１．素材（小組でもＯＫ）をライブラリにいれ、番号をふっておきます
　　（小組＝こぐみってよみます。ＤＴＰ用語）
　　素材に番号をふっておく。

２．その素材のカードをレイアウト上に並べる
　素材に対応するカードの上に番号を振っておく。レイアウトシートにのせたとき、そのカードがおかれた位置と番号から、どの素材をどこに置いたらいいか、カメラで読み取る

３．そうすると、実際にＤＴＰでレイアウトしているところで、素材が動く

っていうふうに変わると、需要あるかも。。

---

とくに、おとといのトレンドたまごをあわせると。。

１．電子ペーパー、または、プロジェクター上に、レイアウトしたものと、素材を表示する
　→電子ペーパーなので、お客さんがいるところで、机の上に広げられる。
　　もちろん、まったくレイアウトしてなくてもＯＫ

２．素材を電子ペンで選択して、それをマウスのドラッグのように、
　　レイアウトの上にひっぱっていって、置きたいところで、電子ペンを離す
　→電子ペンからレーザーをだし、その軌跡をカメラでとる。
　　おとといのトレたまで、
　　　線を描くところが上述の「マウスのドラッグのように」に相当し
　　　線をとめるところが、電子ペンを放すところに相当する　

３．そうすると、そのレイアウティングの結果が、実際のレイアウトに反映される。

ってすれば、お客さんの目の前でレイアウト（校正も）できるようになるので、
もっと需要あるかも？？

---

　で、結局これって、

　　　電子ペーパーをディスプレイ
　　　マウスを電子ペン

　に置き換えただけなんだけど、（電子ペンからでるレーザーの動きを追うことで、
　マウスのドラッグ位置を判断する）そうすることによって、お客さんと、電子ペーパーを
　みながら、操作できるっていうか、カンプやゲラ、色校紙を電子ペーパー（プロジェクター）上に映して、お客さんが操作できるってことで、それはそれは、すごいかも。。

---

　とくに、これをクライアントサーバーにわけて、

　　サーバーは、クライアントに表示内容をわたし、電子ペンの操作結果を受け取り
　　クライアントは、その内容を表示し、電子ペンの操作結果をサーバーに渡す

　とすれば、クライアントはいくつでもいいので、

　カンプができた後や校正（色校含む）のときに、何百人もの人たちにマルチキャストし、
　その結果をみながら、いろいろ操作してもらう

　てこともできるかもしれない。もちろん、この場合、電子ペンのやり方にこだわらず、
マウスでも操作ＯＫにできそうだ（クライアントからサーバーに渡す電子ペンの操作結果をマウスでの操作結果と共通にすればよい）
　表示も電子ペーパー、プロジェクターにこだわらず、ふつうのディスプレイでもＯＫだ。

---

　なーんてことで、いろいろ応用範囲がひろいんだけど、Ｍｏｖｉｅ　Ｃａｒｄｓは、特許申請中っていうから、下手なことをやると、その特許に引っかかっちゃうので、この分野に他のメーカーは進出してこないかもしれないし、Ｍｏｖｉｅ　Ｃａｒｄｓを作った人たちは、未踏っていうから、そこまで話は広げないだろう。。。

　ってことで、このはなし、お客さんも参加して、校正（色校含む）が修正できれば、作業効率も上がりそうだし、紙にださないので、一瞬にして、お客さんの前にでてくれば便利そうだけど、特許に阻まれて、実現しそうはないな。。。

---

　うん、ちょっとまて、

　電子ペンじゃなくって、マウスでやって、表示も電子ペーパーじゃなくって、ふつうのディスプレイでもいいとすると、

・クライアントサーバーにして、レイアウトをサーバーから送り
・複数台（１台でも１００台でもＯＫ）はその結果を表示し、
・クライアントでは、その内容をマウスまたは電子ペンなどで操作、
・ネットを介して、サーバーにその操作結果を渡すことで、

校正とかするっていうだけなら、Ｍｏｖｉｅ　Ｃａｒｄやきのうのトレンドたまごとは関係ないので、こういうのは、出てくるかも。。

---

　その場合は、やっぱ、クライアントーサーバー間の表示内容と捜査結果はＷｅｂ２．０で、ＷｅｂＡＰＩで渡すと。。うん、そーすると、ひょっとしてこれ、ＡＪＡＸで、できるか？？

。。。いもうとデスクトップと同じ原理か？？

。。。って、この話、「やっぱ、松丸アナはすごいですう！」という話にしたかったのに、
　松丸アナと、なんにも関係なくなってきたんで、このへんで。。
　

韓国がらみの感情的なネタを書く！ＩＺＡブログで１位になる方法

　新手のランキング上位進出方法だね（＾＾）

　このＩＺＡブログが、今炎上中のようだ
現代自動車の足元にも及ばない日本車
http://izanagi.iza.ne.jp/blog/entry/18611/

内容は、「はあ？？？？？？なに考えてるの」っていう感じのことなんだけど、
問題は、このブログのランキング。
１位のままなのだ。

さらにミックス３位、ブログ２位は
先制攻撃は侵略戦争の始まり！
http://izanagi.iza.ne.jp/blog/entry/18743/

で、やはり、この人のブログ。

どーも、最近は韓国ネタで、感情的なことを書いて、
みんなに反論してもらうと
アクセス数が増え、１位になるようだ。。。

そこまでして、１位には、なりたくないが。。

でも、こんなブログばかりになってしまったら、
izaって。。。。（＾＾；）

。。。って、意外とこの手口、Ｇｏｏブログでも使えるかもよ（＾＾）
（ウィリアムのいたずらのブログは、コンピューターなので、関係ありませんが。。）

画面をカメラで撮って、ペンの動きを探るって言う手はあるよね。他にも。。

　きのうのＴＶ東京ＷＢＳのトレンドたまごは松丸さんでした。
　じゃなくって、こんなのやってました（以下、斜体はここから引用）

プロジェクターなどで映し出した画面に直接、レーザーペンで書き込めるシステム。パソコンにつないだネットカメラがレーザーの光の軌跡を撮影、それをパソコンが読み取って線を描画して、プロジェクターから画面に送り返す仕組み。書道のように筆圧を表現できる。カメラなどは市販品でＯＫ。


　なるほどね。カメラで、書いたあとを撮って、それを描画するっていう方法はありかも。
　これなら、画面をタッチペンで触らなくてもいいもんね。

---

　ちなみに、他にも、画面をタッチペンで触らなくてもいい方法っていうのは知られている。
　タッチペンの中にＣＣＤカメラをいれておいて、画面をそのカメラが読み込む。
　そーしてＣＣＤカメラから映し出された映像と、現在表示しているはずのパソコンの画像をもとに、そのうつっている位置関係から、タッチペンがどこにあるかを推測するもの。

　ただし、これは特許入ってるかも？入っていても期限切れかも
　（むかし、任天堂がファミコン出す前、電子銃っていうのを売り出していたんだけど、
　　それが、このほうしき。テレビ画面を電子銃の先が読み込んで、判断する）

---

　ただ、松丸さんの字が、いまいち下手だったんですけど、
　（１分３０秒前後の「書道」の字とか）

　あれは、松丸さんの字が下手なの、それとも、このソフトのせい？
　テレビ東京に龍田アナがいなくなり、オープニングベルの足立さんがアメリカに飛ばされてから（って、足立さんは日経か　＾＾；）、テレ東は、松丸アナでしょ！と思っている
　ウィリアムのいたずらの場合、絶対ソフトのせいだ！と思ってしまう、今日この頃なのでした。。
Ｐ．Ｓ　でも、最近龍田アナ、フリーででてるんだよね。