「ボーダフォンライブ！」が「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ページ目（ただしこのお話は８５ページ目から始まっている）に、こんなことが載っていた。
　要求仕様書の不統一の解消に、Ｗｈａｔで記述するところと、Ｈｏｗで記述するところの２つが記述されていて、要求仕様である以上Ｗｈａｔに統一すべきことは言うまでもないで終わっている。

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

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

---

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

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

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

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

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

---

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

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

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

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

---

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

　で、どうするか。。。

---

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

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

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

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

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

---

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

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

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

---

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

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

---

ってことで、

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

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

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

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

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

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

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

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

---

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

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

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

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

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

---

　で、結局これって、

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

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

---

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

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

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

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

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

---

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

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

---

　うん、ちょっとまて、

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

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

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

---

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

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

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