分子の位置と運動量は両方同時には測定不可能なんです。
ちなみに、ここでいう「測定不可能」ってのは実は技術的な限界じゃなくて、
根本的な原理なんだよね。
「誰にも見られてない状態のアナタを見せてください」
っていう要望と一緒。
詳細は「不確定性原理」でググれ！
たとえ時間を戻して過去に戻っても、アナタの状態も当時と全く同じ状態に戻るので
今までと完全に同じことを行って、結局「全く同じ現在」に戻ってきます。
同じ失敗を繰り返して
彼女と別れて
惰性で毎日を送って
メタボになって
「タイムマシン欲しいなあ」と呟いて・・・
自分だけが「現在の状態」なんていう都合の良い状態なんか有るわけがない。
「過去」の状態に「現在」の記憶を持ったアナタが存在するだけで、
それはもう「正しい過去」じゃないです。
だからタイムマシンは存在しないし、意味がないです。
全ての分子の位置と運動量を保存するデータベースを作って、それを再現すればよい。
動いてる全ての分子の向きを１８０度反転させれば良い。
ぎょうざの持ち帰り専門店「宝永」の餃子がうまい！！！
http://www.shokunodaichi.com/元々は音更にある「宝永」という食堂の餃子が美味しいと評判を呼んで、
口コミで広がっていったんだそうな。
冷凍ですが、家庭でも上手に作れます。
外をパリッと焼くと、中から肉汁が溢れます。
にんにくの香ばしさが食欲をそそります。
薬味好きの我が家には堪らない味です。
そして、キャベツの甘みがやさしく包み込みます。
餡自体に味がしっかりついてるので、酢だけをつけて食べるのがオススメ。
ビールが進む進む！！！！
ちなみに上記サイトに載ってませんが、
栄町にも店があります。
というわけで、今週は３回も餃子食べました。
また買いに行かなきゃ！！！
JaSST'10 Tokyoで「スープカレー方式」というソフトウェアテスト方法を
発表させていただきました。
スープカレー方式は、要するに
顧客観点と機能観点をマトリクスで考えてミックスする
方法です。
しかも、「ただ混ぜる」と訳が分からなくなるので、
どちらかを基に片方をくっつけていこうと。
スープカレーって言ってるけど、
「きなこもち」の方がイメージつきやすい気がします。
「もち」というある「単位」に「きなこ」をくっつけて、
「きなこ」がまとわりついた何かしらの新たな「単位」が生まれる。
こうすると二つの観点がミックスされた「単位」ができるので、
粒度がそろって扱いやすいですよね。
が、どっちを基にするか。
これは常に議論された内容でした。
これは普通に考えるならば、「顧客観点」をベースに
機能をくっつけていく方法になりますよね。
つまり、、、「顧客観点」を整理して「シナリオ化」すれば、
いわゆる「シナリオテスト」になりますよね。
でも、スープカレー方式では、機能観点を基に
顧客観点をくっつけていきます。
なんでか？
・・・なんでそうしたんだっけな？
元々は
「何とか２枚のマインドマップを１枚にできないか」っていう発想でした。
そのために、粒度がそろっていた「機能整理マインドマップ」に
顧客観点をくっつける方が扱いやすかったんだと思います。
つまりメインブランチ＝機能
そこから顧客発想を伸ばしていく。
これが逆だと発想が伸びにくいかなと思ったんですね。
さらに、まだこの時点では「顧客観点」での整理法が固まっていなかったので、
メインブランチにするには粒度がそろってなくて扱いづらかった。
そして、その後にWCATE同人誌の「Maniax Vol.1」にてHAYST法の「FV表」の記事を見て
自分たちの方向性は大きくは間違っていないことを確信して、、
「FV表」特に「目的機能」をターゲットにスープカレーを考えていきました。
特に「機能のカプセル化」という単語は「きなこもち」と同様のイメージだと認識しました。
んで、結局この議論は最後まで続きました。
シナリオを立てて、そこに機能を当てはめていくのか、
機能にシナリオを当てはめていくのか。
たぶんですが、、、前者が常套だと思います。
つまりスープカレーじゃない方。
顧客要望を達成していることを確認するのがシステムテストなんで、
顧客要望はかならずシナリオになっているからです。
でも、僕はシナリオテストをやるときに
「全ての機能を網羅できない」と感じていました。
「システムテストなんだから機能網羅はいらないんじゃない？」
と考えることもできますが、実運用環境で全ての機能が
顧客要望どおりの動作をすることの確認は必要だと思うのです。
ただ、逆（後者）だと機能は網羅できますが、必ずしも
顧客の要求するシナリオが満たせるとは限らない。
（シナリオがブツ切れになるから）
プロ野球に例えましょうか。
チームの目標は「優勝」のただ一つです。
優勝に向けて何をするべきか。
二つ方法があります。
Ａ．優勝に向けてやるべきことを考えて、それに選手や指導者をアサインする
Ｂ．個人ごとに優勝への目標設定を行い、それを積み上げて実施
Ａは、たとえば「センターラインの強化」「打撃力の向上」「送りバントの精度向上」などをあげて、
「センターラインの強化」＝参加メンバー：ショート、セカンド、キャッチャー、センター
「送りバントの精度向上」＝参加メンバー：投手、二番打者、下位打者
・・などとアサインして練習に取り組みます。
・・・・が、この方法の弱点は
「どこにもアサインされない選手が存在するかもしれない」
「アチコチにアサインされてる選手も存在するだろう」ということ。
選手単位で見ると、バラツキがあるんですね。
Ｂの方法をみてみましょう。
たとえば
１番打者（センター）：優勝への取り組み⇒出塁率の向上、盗塁の成功率の向上
２番打者（セカンド）：送りバントの成功率向上、出塁率の向上、併殺の精度向上
３番打者（サード）：打率３割以上、得点圏打率４割以上
・・・など、個人単位での「優勝に対してどう取り組むか」を決めていきます。
つまり「個人の優勝への取り組み」が達成できれば「全体の優勝」が達成できると。
この方法だと選手一人一人の目標がカバーできます。
が、もちろん弱点もあります。
たとえば、同じ「送りバントの成功率向上」という目標を複数の人間が立てたとしても、
それを個人でバラバラに行うことになります。
あと、チームとして必要な目標が満たされないかもしれない。
たとえばチームは「右方向への打撃の向上」を求めていたとしても、個人レベルで
誰もその目標を立てていないかもしれない。
・・・言うまでもなく「優勝」は「顧客満足」＝「システムテストの目標」、
「選手」は「機能」。「チームでやるべきこと」や「個人の取り組み」は「シナリオ」
ですね。
つまりＡはシナリオテストで、Ｂはスープカレー方式。
「機能」は「顧客満足」を達成する「メンバー（選手）」であって、
個々の機能（メンバー）に課せられた「目的」を完全に果たしていれば、
顧客の満足（優勝）は達成できる
・・・ハズなのです。
結局どっちも一長一短だなと。
ただ「シナリオテスト」の方法論はあるのですが、
逆の方法論がまだ余り見受けられなかったので、あえて
そちらの方を採用しています。
正しいのか正しくないか、
有用かそうでもないのか、
それは、これから実践にて確認したいと思っています。
・・・
両方必要ならば、その「重複」部分をいかに省くか。
これが成功の秘訣なんじゃないかと密かに考えています。
というわけで。
終わりましたよシンポジウム。
発表してきましたよ！数百人の前で、、、
１年前には、まさか自分がこんなところで
発表することになるとは思わなかったなあ。。。
「スープカレー方式」についての発表でした。
前回のJaSST北海道の発表をさらに進化させて
「スープカレー表」なるものを引っさげての登場。
FV表やFL表への理解も更に深まり（たぶん・・・）
渾身の発表でした。
・・・たぶんねｗ
いや、自分の精一杯は出せたと思います。
それにしても東京は規模がでかいわ。
聴講者は数千人規模、セッション会場も４〜５に分かれてて、
スタッフも膨大な数。
内容も濃い！
「テスト技術の標準」である「TEST.SSF」は、相当詳細な分類になってました。
テストフェーズを「テスト要件分析」「テストアーキテクチャ分析」「テスト詳細設計」
「テスト実装」「テスト実行」「テスト報告」「テスト評価」にわけて、それぞれが
第五階層まであるという！！！！！
しかし、コレは素晴らしい取り組みです。
「テストエンジニア」という職種が認められてないのは、
「何ができればテストエンジニアなの？」という基準がないからです。
そして、テストエンジニアの「ランク」もわかります。
これで公平な評価ができます。
期待してますわ！
そして智美塾。
アツイ激論が交わされてました。
議論に夢中で、メモを取ってないんですがｗ
お題は「テスト要求分析のアウトプットを考える」
だったと思います。
インプット⇒アクティビティ⇒アウトプット
と議論は展開されますが、それぞれの関連性が
難しいところだと思いました。
要はインプットとアクティビティって１：１になるとは限らないから。
ｎ：ｎになるなら、どうやってインプットからアウトプットまでを
繋げていくかが非常に難しくなりますね。
確か、途中の議論で「次のフェーズを簡単に定義して、そこからアウトプットを考えていく」
という考えも提示されました。
ところで、どうなんでしょう。
プロセスは、アウトプットから考えるのがいいのか、インプットから考えるのがいいのか。
自分のプロセスのインプットは前のプロセスのアウトプットになりますね。
つまり、自分のプロセスのアウトプットは後のプロセスのインプットになります。
インプットって、なにかしらの「要求」があるから集めるものなのかなとも思うわけです。
「要求」ってのは後のプロセスから「こんなのが欲しい」って言われたから「アウトプット」するわけで、
アウトプットから逆にたどってインプットを決めるのもいいのかなあと思ってます。
・・・でもこうやって考えるとプロセスの最後。。。つまり「テスト評価」から逆にたどる必要があるので、
まったく今回の議論とは方法が逆ですね。
西先生はその方法を「建設的ではない」とおっしゃっていましたね。
確かに。
きっと僕の方法だと、ありきたりのモノしか出てこないのかもしれません。
、、、考えがまだまとまってないですがｗ
基調講演と招待講演とパネルディスカッションに関しては、
かなり重要な内容が含まれていたので、あとでキチンとまとめます。
というわけで、非常に楽しい時間をすごせました。
とても刺激的でした。
打ち上げでも、超大御所のみなさまとお酒を飲むことができて
大変光栄でした。
JaSST東京のスタッフの皆さん、お疲れ様でした。
発表者の方々、お疲れ様でした。
そして、TEF道のみなさま。
僕一人の力では当然何もできなく、みんなの力が結集したからこそ
僕があの場に立たせて貰えたのです。
本当にありがとうございました！！！
-------------------------
んで東京にまつわるその他のハナシ。
昼飯は謎の「タイ・インド料理」という店でした。
・・・何故一緒にした？？？ｗ
ちなみに店員はインドの方。だけど店名は「バンコク」ｗ。
両国は基本的にヒンズー教と仏教だから、店のオブジェもまさにカオスｗ
土曜日はひとり東京ツアー。
「坂東太郎」という鰻を美味しくいただき、未来科学館へ。
いやあ、
科学館は楽しい！
リモコンのロボに乗った気になれる巨大なシミュレーターや、
生ASIMOや、インターネットを物理的に表現した展示物や、
人間の感覚を狂わす展示の数々や、、、
時間足りないべや！！！！！！！
是非、みなさんも行ってみて下さい！
ちなみにワタクシ、
楽しみすぎて、飛行機に乗り遅れそうになりましたｗ
というわけで、ひと段落。
また次に向かって頑張ります！
これから登壇
もっとニセモノ。
「ガンガル」
「量産型ズク」
「モビルフォース」ってｗｗｗ
