2007-11-02

続々:fmlで開封確認メールが飛び交わないようにする

不在メールの日本語版にも対応しないと片手落ち、というご指摘を、組込みソフト界の最強の皮肉屋かつマンガ王の宿口さんから頂きましたので、ついでに掲載しておきます。

あまり美しくないので、どなたかきれいに書き直してくださいまし。

$USE_DISTRIBUTE_FILTER = 1;
$DISTRIBUTE_FILTER_HOOK = q#
$body_by_euc = $e{'Body'};
jcode::convert(\$body_by_euc, 'euc');

$target_for_filtering = 'I will be out of the office starting.*and will not return';
jcode::convert(\$target_for_filtering, 'euc');
if ($body_by_euc =~ /^[\r\n]*$target_for_filtering.*/) {
return 'This is an absence mail.';
};

$target_for_filtering = '\d*\/\d*\/\d*[ \t]*から不在にしております。.*\d*\/\d*\/\d*[ \t]*に帰社いたします。';
jcode::convert(\$target_for_filtering, 'euc');
if ($body_by_euc =~ /^[\r\n]*$target_for_filtering.*/) {
return 'This is an absence mail.';
};

$target_for_filtering = 'Return Receipt';
jcode::convert(\$target_for_filtering, 'euc');
if ($body_by_euc =~ /^[\r\n]*$target_for_filtering.*/) {
return 'This is a reply mail.';
};

$target_for_filtering = '受信確認レポート';
jcode::convert(\$target_for_filtering, 'euc');
if ($body_by_euc =~ /^[\r\n]*$target_for_filtering.*/) {
return 'This is a reply mail.';
};
#;

&DELETE_FIELD('Disposition-Notification-To');
&DELETE_FIELD('X-Confirm-Reading-To');

続:fmlで開封確認メールが飛び交わないようにする

結論として、昨日のフィルタでは上手く動きません。すみません。

きちんと動く(と思われる)フィルタを再掲しておきます。
#ついでに、不在メールも叩き落とすフィルタになってます。

$DISTRIBUTE_FILTER_HOOK = q#
$body_by_euc = $e{'Body'};
jcode::convert(\$body_by_euc, 'euc');

$target_for_filtering = 'I will be out of the office starting.*and will not return';
jcode::convert(\$target_for_filtering, 'euc');
if ($body_by_euc =~ /^[\r\n]*$target_for_filtering.*/) {
return 'This is an absence mail.';
};

$target_for_filtering = 'Return Receipt';
jcode::convert(\$target_for_filtering, 'euc');
if ($body_by_euc =~ /^[\r\n]*$target_for_filtering.*/) {
return 'This is a reply mail.';
};

$target_for_filtering = '受信確認レポート';
jcode::convert(\$target_for_filtering, 'euc');
if ($body_by_euc =~ /^[\r\n]*$target_for_filtering.*/) {
return 'This is a reply mail.';
};
#;

2007-10-31

fmlで開封確認メールが飛び交わないようにする

TEFのメーリングリストで、開封確認のメールが飛び交ってしまった。なにせ1400アドレス超のMLなので、ちょっとしたメール爆弾状態である。自分が開封確認などという極悪な機能のついたメールクライアントを使っていないこともあって、開封確認を付けないようにという事前案内も、開封確認が無効になるようなfmlの設定もしていなかった。完全にお世話係である自分の落ち度である。メンバの皆さん、スミマセンでした。 m(_)m

さて拙い設定だが、fmlのcfファイルに加えた開封確認フィルタをメモしておきたいと思う。どなたかのお役に立てば幸い。これは、開封確認ヘッダを削除することと、開封確認返信メールをたたき落とす役割のフィルタである。

&DELETE_FIELD('Disposition-Notification-To');
&DELETE_FIELD('X-Confirm-Reading-To');
$DISTRIBUTE_FILTER_HOOK = q#
if ($e{'Body'} =~ /^[\r\n]*Return Receipt.*/) {
return 'This is a reply mail.';
}
#;
$DISTRIBUTE_FILTER_HOOK = q#
$body_by_euc = $e{'Body'};
jcode::convert(\$body_by_euc, 'euc');
$target_for_filtering = '受信確認レポート';
jcode::convert(\$target_for_filtering, 'euc');
if ($body_by_euc =~ /^[\r\n]*$target_for_filtering.*/) {
return 'This is a reply mail.';
}
#;

2007-09-28

SIGSE

京都で情報処理学会のソフトウェア工学研究会(SIGSE)の研究発表会に参加してきた。残念ながら前後に仕事があり、学生さんの発表が2件とプロ研究者(?)の発表を2件聴いてきた。

研究室のゼミだと問題点を指摘する役回りなので、どうしても改善すべき点を探してしまう。しかしこういう場では、最近、その研究の持つ発展性を考えて質問やコメントをするようにしている。人の研究を理解して発展可能性を想像するというのは難しいが、研究者として重要な役割だと思う。まぁ人のアラを探すのは簡単だからね。

もともと僕は目利きではない。なんとか直したいと思っているのだが、その原因の一つは、ついアラを探してしまって悦に入り、発展可能性に思い至らないからことがあるのかもしれない。このクセが直るには5年10年かかるだろうが、辛抱強く直していきたい。

2007-09-26

Starckの時計

休暇の時に結局買わなかったので、時計を衝動買いしてしまった。もともと持ち物に関してはあまり取っ替え引っ替えしない方で、今使っている時計はもう10年近くになる。これからも使い続けるつもりなのだが、それはそれとして、プライベートで使うようなユルい時計が欲しくなったのだ。

そもそも普段から時間に追われるような生活をしているので、休日はあまり時間に追われたくない。そんなわけで、正確な時間が読み取れないくらいでちょうどよいのだ。そんなミニマルなデザインの時計が欲しかったわけで。そんなことを思っている時にみなとみらいのクィーンズスクウェアで別の買い物をしていると、TicTacに可愛い時計があった。もちろん、すぐに衝動買いしてしまった。ルフトハンザみたいな色づかいもキュートだ。

FOSSILのStarckモデルのようだ。Philippe Starckは、悪名高き浅草のアサヒビールのオブジェのデザイナーというと分かりやすいかな。ちなみにあのオブジェは炎がモチーフだそうで。しかしそれ以外は、シンプルでミニマルなデザインが多い。

しかしこの時計、いま何時なのか全然分からない。まぁ分からなくてもいいと思って買っているのだから良いのだが。何がおかしいって、長い針らしき棒が実は時間を示す針で、短い針のように見えるS+ARCKの文字列が実は分を刻む時計なのだ。逆の方がアフォーダンスに合っていると思うのだが、それはそれでデザインが普通っぽくなってしまってイマイチなのかもしれない。というわけで、気に入っている。

これで少しは休日に時間を忘れられるかしら。何もせず何も考えない時間が無いと、ビジョンもアイデアもモチベーションも枯渇しちゃうからね。

2007-09-20

カフェテリアの安全性解析

国際学会でドイツはニュルンベルグに来ている。SafeCompという組込みシステム(?)の安全性の学会だ。欧州中心の、とても由緒ある学会である。日本人は僕の他に、長岡技科大の平尾先生がいらしている。逆に言えば、日本からはそれだけだ(あとは東北大の留学生さんが一人)。まぁ韓国もインドもアメリカも少なく中国はゼロので構わないのかもしれないが、もっと日本でも組込みシステムの安全性の研究者が増えるべきだと思う。

さてそんなわけで、平尾先生とお昼をご一緒させていただいた。安全性の分野で最も大事なのは、言わずもがな安全性解析だ。平尾先生は「ハザード解析ですよ」と言いながら、道を渡る時でも左右に注意している。さすが安全性の専門家。

一方僕はと言えば、ランチルームであるカフェテリアで、かなり派手にソースをジャケットやシャツにこぼしてしまった。ちょっとした染みなんてレベルではなく、10メートル先からでもこぼしたことがはっきり分かるくらい。手提げカバンを持っているのでトレイを片手で持っており、かなり長い間こぼれていることに気づかなかったのだ。不覚。

しかし不覚なのは、こぼしたことそのものではない。片手でトレイを持つ際のハザード解析やFMEA、HAZOPができていなかったことを始め、安全性の学会に来ているのに安全性解析の基本がなっておらず事故が起きてしまったことだ。しかも、昨日あぶないなと思っていたのに、そのヒヤリハットも活かせてない。こぼしたことを検知する機構も備えていなければ、こぼれても大丈夫なようにトレイを離して持つという機能安全も達成できていない。これでは安全性の研究を始めましたなんて、口が裂けても言えないわな。

う~ん、精進が足りませんね...。頑張ります。

2007-09-10

グァムは日本人ばかり

休暇でグァムにいる。外国のはずなのだが、グァムに来てから見かけた人は日本人の方が圧倒的に多いぞ。レストランも9割は日本人だし。そもそも、ほとんどのところで日本語が通じるし。

というか、僕が日本人のいるようなところしか行ってないのか。 (^^;

これでは、高林哲さんの「いやな法則」だ。
曰く「世の中が狭いのではなく、自分の世界が狭いだけである」

けだし名言。

2007-09-07

評価開発

特に研究者に多いが、ソフトウェアテストと聞くとプログラムのホワイトボックステストを思い浮かべる人が多い。もちろん1970年代前半はそうだったのかもしれないが、現在は違う。

テストと似たような活動に、レビューやインスペクションがある。バグを見つけるという意味では、形式検証もあるだろう。この際、メトリクスを測定する活動も含めてしまおう。これらは、プロジェクトの様々なフェーズにおいて、様々な手段で、様々なソフトウェアの特性を調べる活動と考えることができる。これをここでは、評価と呼ぶことにしよう。

そう、テストとは、ソフトウェア評価のうち、ソースコードの出現後に実施される動的検証という、一つの手段を意味する。でもまぁ、この分類にはあまり意味はない。

意味があるのは、こうした評価の活動には全て分析・設計が必要だという点である。言い替えると、評価開発になるかな。プログラムを開発することと同じくらい、評価項目や評価手段の設計というのは難しいのだ。だから、頭を使って方法論を構築し“開発”すべきである。

仲でも、評価戦略の策定は重要だ。開発しようとしているソフトウェアにおいて評価すべき特性にはどのようなものがあり、どのような手段、どのような単位で測定できるのか。各評価手段は、どのように棲み分けて、補完しあうのか。それらが製品価値にどのようにつながっていくのか。こうした評価戦略を決めないといけないのだ。しかも上流でね。

ソフトウェア開発の現場では、評価活動全体を俯瞰的に捉えている場合はあまりないだろう。しかし開発項数の5割以上を評価に割いており、評価工数が足りない足りないと騒ぐのであれば、評価を俯瞰的に捉えて“開発”すべきである。そうしないから、評価工数が爆発したり、評価漏れで不具合が市場に流出するのだ。

テストの方法論は、最終的に評価開発の方法論に昇華すべきだし、しなくてはならないだろう。その第一歩として、テスト戦略を立ててテストレベルやテストカテゴリに分割してみるとよい。慣れてきたらレビューの観点を加え、形式検証、メトリクスと増やしていけばよい。

我々メソドロジストも、評価全体を視野に入れて方法論を構築しないとね。これはなかなかチャレンジングだが、楽しい作業だと思う。

SQiP Future Award

うちの研究室の博士課程の学生、いやもはや研究スタッフと言った方がよいだろう、の河野くんがソフトウェア品質シンポジウムでSQiP Future Awardという「将来役に立つ可能性を秘めた発表」を選ぶ観客からの投票による賞をもらった。とても頑張って研究していたので、こちらも嬉しい限り。よかった、よかった。

2007-09-06

ソフトウェアの開発技術がハードウェアの設計技術を進化させる?

今日はソフトウェア品質シンポジウムに参加。午前中はトヨタの重松さんの基調講演だ。クルマのエレクトロニクスの進化などを興味深く聞くことができた。

せっかくなので質問したところ、気になるフレーズを聞いた。「ソフトウェアの開発技術がハードウェアの設計技術を進化させるかもしれない」という一言だ。多分、こういう考えを持っている人は、ほとんどいないはずだ。僕は、僕と自分の指導教官以外でこのことを話している人を見たのは初めてだ。

ちょうど某連盟の広報誌に似たようなことを書こうと思っていたので、書き終わったらアップしようかな。

2007-09-05

Tech-On!:「あなたの行っているテストに戦略はあるか」

Tech-On!の記事で取り上げられました。僕はアロハで写ってますね。大森さん、ありがとうございます。

いろいろと改善点はありましたけど、このテスト戦略ワークショップを発展させて、全国行脚するつもりです。参加者の皆さんに当日書いていただいたテスト戦略は、ヒマを見て電子化してアップロードします。少々お待ち下さい。

ところで、テスト戦略をシーケンス図で描くなんて言ったかなぁ...。逆に考えれば、描けちゃうのかなぁ。少し考えてみようかしら。

2007-09-03

QBGタカギのジュレ

先週は忙しすぎてblogが更新できなかったのだが、色々他の人と話したり考えたりしたので、それについてはゆっくり書くことにする。とはいえ来週は休暇なので、いつになることやら。

今日は夕方まで大学で仕事の後、明日の集中講義のため博多へ移動。品川経由で羽田へと急ぐ。

暑くなる前は羽田に笹巻きえんがわずしという名作があったのだが、夏になってからはトンと見かけない。ムチャクチャ好物だったので残念だ。早く復活してほしい。秋になったら食べられるかしら。6月だか7月だかは佐賀牛の弁当があり、こちらも美味だった。しかし現在は、それほど心を躍らせる空弁は無い。

そもそも羽田には、ウキウキしてしまうようなスイーツのお店が少ない。もちろんピエール・マルコリーニはあるが、僕はあまりチョコが得意でない。期待していなかったが、もちクリームもハズレだった。キハチに至っては、ソフトクリームなので持ち運べない。パステルがあるが、毎回では飽きてしまう。

なので羽田で買う前に、品川の駅ナカであるEcuteに寄る。そこそこマトモなものが買えるので重宝している。というわけで、沼津魚がし鮨でにぎりのセットを買う。

Ecuteはスイーツのお店も結構あるが、何となくいつもQBGタカギに行ってしまう。ここはQBGというハチミツ屋さんと、ル・パティシェ・タカギという深沢不動のところのケーキ屋さんとのコラボだ。高木さんは郁恵・井森のデリ・デリ・キッチンにも出演していたので、かなり有名だと思う。キットカットは不味かったけどね。

ここで最近お気に入りなのは、シンプルなはちみつのジュレだ。メープルかな。少しレモンの酸味があって、サッパリしているので駅弁・空弁のデザートには最適だ。保冷剤も入れてくれるので安心。

このジュレ、とっても優しい味がする。一般にジュレというのは、腕が悪く固めすぎてしまったり、技巧に走って果実味が強すぎたりと、意外にバランスが難しいスイーツだ。若いうちはたっぷりの果実味でもよかったが、最近はシンプルかつ優しいものに惹かれるようになってきている。タカギのこのジュレは、変な混ぜものの味もしないし、甘味が強すぎることもないし、鼻につく果汁臭も無い。何の変哲も無いといえば無いのだろうが、スッと身体に入ってきて、サッと消えてしまい、フワッとした後味が残る。それだけ。それだけなのだが、つい買ってしまう。

もう少し時間があれば外のカフェでお茶でも、と思うのだが、イートインなのにフォークはプラスティックだわ、詰め込んでるので席は狭いわ、禁煙じゃないので近くに喫煙者が座るとケーキやお茶の香りが台無しだわで、気が引ける。むしろ持ち帰りにして新幹線や飛行機の中で食べた方が、妙な期待をせずに済むだけよいだろう。

甘いものが好きな人は、レジ横にあるはちみつのキューブを買ってもよろし。パッケージの猫が可愛いのもあって、疲れた時は和みます。こちらもオススメ。

2007-08-27

コメントフィード

右側のサイドバーに「最近のコメント」を表示させているのだが、数日前からbloggerの設定が変わったようで、コメントの内容が表示されなくなった。内容が表示されないのは良いのだが、いったいどこのエントリについたコメントなのか分からなくて困る。テクノラティで検索すると、この方しか書いていない。

コメントにコメントで返事をするポリシーでは無いので構わないっちゃ構わないのだが、何となく座りが悪いなぁ...。誰か対策を知っていたら教えて下さいませ。

2007-08-25

麻布十番縁日

週末は麻布十番縁日に行ってきた。正式な名前は、麻布十番納涼祭りだそうだ。へぇ。

小さい頃はそんなに行ってたわけじゃないのだが、中学生くらいから必ず毎年行くようになった。だからもう20年以上になるのかな。そんなわけで、僕の夏の風物詩と言えば、神宮の花火と麻布十番の縁日である。この2つが無いと、どうも夏を過ごした感じがしない。

しかし南北線と大江戸線の駅ができてからというもの、人が増えすぎて困る。以前は友達や知り合いに出会ったりしたものだが、皆よそに引っ越したからか、友達が減ったからか、視力が減ったからか、いや人が増えすぎて、ちっとも誰にも会わない。芸能人にも会わない。いや会っているのかもしれないが、朝の山手線のラッシュみたいになっており、人が多すぎて認識できないのだ。六本木ヒルズも出来たしねぇ。

まぁでも、行く価値のある夜店なんて限られているから、混んでいても構わないっちゃ構わない。十番の縁日の夜店は、大きく分けて3つに分けられる。1つは、他の縁日やお祭りでも出ている普通の夜店。2つめは、十番のお店が片手間にドリンクなどを供給する夜店。3つめは、十番のお店が本気で(?)食べ物や飲み物を振る舞うお店。あ、今回から、地方の特産品みたいな夜店カテゴリもあったかな。で、行く価値のあるお店は、3つめ。空いていれば4つめも面白いかもしれないが、この混みようだからなぁ。

普段から十番に来ていればすぐに分かるが、別に初めてでも一目瞭然だ。せっかく来たのだから、たこ焼きだのお好み焼きだの焼きそばだのは食べず、十番のものを食べた方がよいと思う(まぁ別に、食べたかったら食べてもよい。僕もお好み焼きを食べることもあるし)。もしかしたら僕が知らないだけで、絶品のたこ焼きがあるのかもしれないけどね。

また重要なのは国際バザールだ。一の橋公園の中にたくさんの国の夜店が開かれる催しで、十番の縁日ならではのイベントなのだ。もともと港区、特に麻布は大使館が多いので実現したのかもしれない。各国の料理が食べられるのでオススメだ。今年は十番の通りよりも若干空いていたしね。うちはいつも、ここで晩ご飯にしてます。北側(ローソン側)に座れそうなスペースがあるけど、風下のため煙いので注意。ちなみに僕は数年前、ここで煙を浴びすぎてコンタクトを一つダメにしてしまった。

お腹がふくれた後は、今はいないけど田代まさしの焼きそば屋を見に行ったり、デストロイヤーの電気屋さん(だったかな?)を見に行ったり、お化け屋敷(今は盆踊りのようだが)の方に抜けて一息ついたり、童謡赤い靴のきみちゃんの像の近くのステージをウロウロしたりする感じかな。大混雑の十番通りは下り(?)だけにして、上りは迂回するのが落ち着けるコツかも。

今年は、今まで近寄らなかったりスルーしていたフレンチの夜店の子羊とヴィシソワーズが美味しくて感動だった。十番通りから少し外れた方が、落ち着いて上手い夜店が見つかるかもしれない。合唱するアイスコーヒー屋とかあるし。

あとは、縁日の終了時刻である21時前後に投げ売りを始めるので、交渉して安く旨いモノを買うという楽しみもある。僕も以前、焼肉をこれでもかと盛ってもらったことがある。十番は山の手だが人情味のある下町風情もあるので、いろいろ親切にしてもらえるかもしれない。

一つ悲しいのは、昔ながらのラムネがほとんど見かけなくなったこと。プラスチックのビンでは気分が出ないし、何より美味しくない。縁日以外なら浪花屋さんに行けば呑めるのだが、縁日で呑めないとチト寂しい。これも時代の流れかしら。まぁゴロゴロ売っていたのだが混みすぎて見えなかったのかもしれないけどね。

ともあれ、来年はもう少し空いてる時間に行こうっと。土曜の19時なんて、一番混んでる時間帯だもんね。

2007-08-24

好きこそものの

山ごもり終了。帰りに特急を30分ほど待つ。中途半端な時間だ。同じグループの人々はアイスを食べたり、携帯を見たり、おしゃべりをしたり。僕はPHSで巨大なメールが取れずに四苦八苦。近くの高校生は、PSPで通信ゲームをやっている。キオスクのおばちゃんと話している観光客もいる。ちょっとしたヒマな時間なんて、みんなそんなもん。どこにでもある、普通の光景だ。

しかし隣に座っているTOPPERS軍の高田総統は違う。そんなほんの少しの時間にも、集中してコードを書いているのだ。多分TOPPERSのコードだろうが、凄い。僕がディスプレイを覗いているのも気にせず、書く、書く、書く。時々「う~ん、ここはどうするかな」とか言いながら、書く、書く、書く。

何というか、凡人と偉人の差をまざまざと見せつけられた気がする。これくらいやらないと偉人になれないのか、これくらいやったから偉人になったのか。いや違う。時間が空いたらコードを書きたくてたまらないくらい好きだったり、コードを書くことが空気を吸うようになっているのだろう。なるほど、TOPPERS軍の結束の堅さの理由が分かった気がする。

急制動体験

今日は山奥で急制動体験をしてみた。とはいっても別に事故を起こしたわけではなく、完全に安全が確保されている環境で、教官が横に乗っている状況での体験だ。

実は昔、明治通りと中山道の交差点で日曜日の早朝にフルブレーキングをかけて歩道に突っ込んだことがあったりして、懐かしい体験だ。ちなみにその時は早朝だったので人がおらず、特に被害は無かった。やっぱりムシャクシャしてクルマに乗るといけませんね。

不思議なもので、ABSの無いクルマだったのでタイヤがロックし歩道に向けて滑っている間、頭の中は妙に冷静で、流れている車窓の映像はスローモーションだった。もしかして走馬燈だったのかもしれないが、とにかくパニックにはならなかった。

今回はABS付きとABS無しで80Km/hくらいから急制動をかけるのだが、まず急制動をかけるために80Km/hまでスピードを上げるのに少しビビる。もう年なので最近はあまり飛ばさないせいか、及び腰。そしてフルブレーキングをすると、頭の中が真っ白に。安全が確保されていることが分かっていても、急制動をかけるという体験そのものがパニックを呼び起こすのかもしれない。もしくは年のせいで頭の回転が鈍っているのだろう。

いつまでも若いと思ってムリしちゃいけませんな、と思ったのが今日の収穫でした。隣に乗っていた教官には、ABS付きの方が制動距離が短いのは事実だけど、そもそも急制動をするような状況にならないことが大事なんだ、と注意されたしなぁ。皆さんも気をつけましょう。

2007-08-23

ソフトウェアの価値と自動化

最近ご無沙汰のさかいさんからコメントを頂いたので、昨日のエントリの続き。

大森記者の最後の段落での主張は、きっと、ソフトウェアの自動生成により低コストでユーザに価値を提供できるようになる、だと思う。違うかしら。違ったらごめんなさい。

この主張が僕にとって気持ち悪いのは、きっとこんな理由だ。もちろん昨日のエントリにも書いたが、ドメインがあまり変化しなければ、自動生成は可能である。でもこのドメインが変化しないというところが気持ち悪い。

ソフトウェアは、我々の生活を豊かにしてくれる存在だ。その豊かさは、我々が既に営んでいることをスピードアップしたり、コストダウンしてくれたり、スケールアップしてくれるものかもしれない。しかしむしろ、我々が暮らしている世界を広げてくれる存在であって欲しいと心から思う。

例えばカメラ付き携帯電話を考えてみよう。携帯電話にカメラが付いて、我々の生活に何が変わったか。合わせればカメラ付き携帯電話の大きさになる程度の小さな携帯電話と小さなデジカメを別々に持つこととは、訳が違う。携帯電話を使ってカメラで撮った画像を友達に送ることで、きっとコミュニケーションの幅が広がったのだ。カメラ付き携帯電話が出現する以前に、もし携帯電話用のソフトウェア自動生成ツールがあったら、カメラモジュールを付加できるような設計になっているだろうか。きっと、ツールの開発者はそんなこと思いもしないだろう。

もちろん、スピードアップやコストダウン、スケールアップで質が変わることもある。量の変化は質の変化を生むからね。でももしソフトウェアが自動生成ツールで全て作られるようになったら、我々の生活の幅の広がりが、とても小さく制限されてしまうような気がしてならない。ツールの開発者が考えつく程度の世界の中でしか、我々は生きられなくなってしまうのだ。

だから僕は、汎用的なソフトウェアを手動で開発できる手段を確保しておきたい、と思うのだろう。もちろん部分的に自動化するのは大歓迎だし、実際にたくさん成功している。一部のドメインでは、全体的な自動化にも成功しているだろう。しかし多くのソフトウェア開発が自動化されたら、何だか夢の無い世の中になるような気がする。ソフトウェアが「柔らかい」から、思いもしなかった世界が出現するのだ。

自信を持って主張するけど、多くのソフトウェアが自動生成されているような世の中は来ないと思う。自動車だって家電だって、自動開発はされていない。もしそういう世の中が来るとするならば、ソフトウェアがコモディティ化して、手動で開発する価値を持たなくなった時だ。"IT doesn't matter"ということか。でもきっとその時には、手動で開発するだけの価値のあるソフトウェアを、人間は誇りを持って開発していると思う。そう信じたい。

2007-08-22

目の高さにお月様

北の大地の某所でカンヅメになっている。夜になると星が降ってくるようで、都会生まれの僕にはいささか感動である。またお月様が目の高さに見える。周りにほとんど高い建物が無いからだが、とても新鮮だ。たまには、こういう大自然の中で仕事をするのもよいかな。

休暇で来られれば、もっといいけどね。

2007-08-21

日経エレのブログ「プログラミングは『設計』か『製造』か」

最近忙しくて、いくつか来るメールニュースのタイトルさえ読めていない。なのでここのところ浦島太郎状態だ。しかも明日から週末まで、もしかしたら山の中に篭もる感じになるため、ネットにすらつなげないかもしれない。まぁ、なるようになれ、だ。

たまたま見たメールニュースに「プログラミングは『設計』か『製造』か」というタイトルがあったので読んでみた。書いているのは日経エレの大森記者だ。まぁ記者の眼にせよこのブログにせよ、日経BPの記者が書いているコラムはほとんどの場合宣伝込みなので、斜めに読まなくてはならない。日経ものづくりは別だけど。これもどうやら、SPLCスターロジックの宣伝のようだ。別に宣伝をしても良いのだが、イマイチ何を言いたいか分からない。大森記者に限った話ではないが、記者なのだから支離滅裂な文章を書かず、宣伝とは悟られないような名文を書いて欲しいと常々思う。

この文章、本当に突っ込みどころが多い。

曰く「ものづくりの現場にいる方は『ソフトウエアといえどもモノなのだから,プログラミングはソフトウエアを製造する行為だ』と自然に考えていると思います。だから,ソフトウエア開発も自動化できるはずだ,と」。おいおい、ものづくりの現場にいる人は、ものが自動で勝手にできるなんて思っちゃいないよ。自動で作っているように見えるまでに大変な苦労をしているのだから。

曰く「「プログラミングは設計である」という考え方に大きな影響を受けて生まれたのが『アジャイル開発プロセス』という先進的なソフトウエア開発手法です」。そうなのか。そんな矮小な概念だったのか、アジャイルというヤツは。

曰く「組み込みソフトウエア開発の分野は,ソフトウエアの仕様が比較的はっきりしているので,IT系のシステム開発より製造に近いという面はあります」。えぇぇぇ、まだ完成もしていないハードとのすり合わせなんて日常茶飯事なのに。仕様がはっきりしていて作りやすい組込みソフトなんて、ほとんど聞かないけどなぁ。

曰く「ソフトウエアの要件さえ確定すれば,あとはコードの自動生成ツールを駆使してソフトウエアを完成させるというのです。ここにあるのはまさに製造の考え方です」。だから、製造というのは、要件が確定すれば後は設備が勝手に作ってくれるんじゃないんだって。生産工程の設計とか初期流動管理とか、山ほど色々知恵を絞るんだって。

とまぁ、色々と難の多い文章だが、では本当にスターロジックのツールを使うと、設計無しでツールがプログラムを自動生成してくれるのだろうか。僕はこのツールをよく知らないが、それは可能かもしれないな、と思う。事実、制御系のソフトウェア開発では、Matlabなどを使ってCコードを自動生成するモデルベース開発という取り組みが盛んになりつつあるからだ。ちなみに、モデル駆動開発ではありません、念のため。

ただし、そのためにはいくつかの条件が必要になる。まず、作ろうとするものの自由度が低いことだ。特にドメインに関する自由度が低い方がよい。自由度が高いコード自動生成ツールは、要するにフレームワークやライブラリ、コンパイラと何ら変わらなくなってしまう。次に、非機能要求を含む要求それぞれに対して、サブプログラムなどの設計要素が1対1で対応することだ。何らかの設計上の共通化は、コンパイラの最適化のようにアルゴリズム的に規定できるのであれば可能である。これはすなわち、メモリなどのリソース制約やスループットなどの性能要求を満たしにくいということにつながる。もう少し一般化すると、要求に対する設計のすり合わせが発生すると、かなり自動生成は難しくなるだろう。

要するに、ドメインがかなり限られていて、要求と設計要素が1対1で対応し、リソース制約や性能要求が緩いアプリケーションであれば、以前からコードの自動生成は可能である。コンパイラ(アセンブラもか?)が出現した時に、一部の人々はもうプログラムを書かなくてよいと喧伝しただろう。フレームワークも、そういう喧伝をされることがある。モデルベース開発に至っては、いまだにそう思っている人がいる。

しかし実際には、多くの場合、自動生成は難しいだろう。それは上述の条件が満たされないからだ。そしてもう一つ理由がある。パーキンソンの法則があるからだ。冷蔵庫が一杯になったので買い換えても、すぐにまた一杯になる。それがパーキンソンの法則だ。これは、自動生成についても同じことが言えるだろう。

コンパイラが生まれたことで、プログラミングは無くなったか。否。では何が変わったか。それは、開発者の知的リソースに対するアウトプットが増加したのだ。つまり、同じだけ頭を使ってできるソフトウェアが、より複雑になったり、高機能になったりしたのだ。一方、開発者の知的リソースそのものは変わらない。こちらはむしろ、ラインエディタからスクリーンエディタになったり、統合開発環境が出てきたりといったことの方が寄与しているだろう。

すなわちツールで自動生成が可能になったら、ほんの少しの間だけ開発者は頭を使わなくて済むようになるだろうが、すぐに開発対象の要求が高度になったり納期が短くなったりして、何らかの形で頭を極限まで使うようになるだろう。コンパイラによってメモリマップを書かなくて済むようになったがごとく、頭を使う対象は変化する。しかし頭を使うことそのものは、形は変わるものの、同じである。我々の欲望の進化は、技術の進化よりも常に速いのだ。

もちろん、コードの自動生成に意味が無いなんてことは全くない。歓迎すべきだ。これは、頭を使うことを減らしてくれるツールである。しかし同じくらい重要なのは、頭を使うこと、すなわち設計とは何かを考え抜き、頭を使うことをいつも楽にしてくれるツールや方法論を考え出すことだろう。設計という高度に知的な行為に対する洞察をすること無しに、ソフトウェア開発は楽にならないと思う。コンパイラが出ようが出まいが、我々が知的なミスをすることは変わらないし、クリエイティブな感覚を持つことが楽でないのも同じである。そういったことをきちんとソフトウェア工学で扱わなくてはならないのだろう。コンピュータに代行させることだけが工学では無い、と僕は固く信じている。

2007-08-20

SAC 2008

SAC 2008 (Annual ACM Symposium on Applied Computing)

日時:2008/3/16(日)~20(木)
場所:
締切:2007/11/2 - 研究論文アブスト投稿, 2007/11/9 - 研究論文投稿

2007-08-19

TAP 2008

TAP 2008 (International Conference on Tests and Proofs)

日時:2008/4/9(水)~11(金)
場所:Monash University Prato Centre, Prato, Italy
締切:2007/11/2 - 研究論文アブスト投稿, 2007/11/9 - 研究論文投稿

見込:欠席

Bertrand Meyerが仕切っているらしい形式手法とテストのカンファレンス。今回で2回目。しかしICSTが裏番組であるのに、テスト関連の研究者は出席するのだろうか。掛け持ちかしら。

2007-08-16

神宮外苑花火大会

夏の前半の休暇中。今日は毎年恒例の神宮外苑花火大会に行った。小さい頃からヤクルトファンだったり、チャリで来れる距離に住んでいたりしたので、花火といえば神宮だ。実家にいた頃は家の前から見えたしね。

神宮の魅力は、なんと言ってもその迫力に尽きる。隅田川や東京湾に比べて(多分)打ち上げの高さが低いせいもあるし、すぐ近くまで寄れるので、音圧を顔で感じることができる。特に神宮球場で見ると、ド迫力だ。うちのチビが1歳になってすぐに連れてきたら、泣いてしまってすぐに撤退せざるを得なかったくらいである。

昔は路上の穴場を探して見ていたのだが、もう年なので最近はチケットを買うことにしている。神宮球場はチビが泣き出すリスクがあるので、昨年から秩父宮ラグビー場から見ているのだが、音圧の具合と花火の大きさがちょうどよい。指定席だと正面では無く右を向かなくてはならないので首が痛くなるが、まぁご愛敬だろう。花火前のライブや仕掛け花火に興味がない向きにはオススメだ。それに、クルマで来て近くに駐車しようとすると、秩父宮が便利だ。

そんなわけで今年も行ってきたのだが、何というか、商業化され過ぎていてイマイチだった。もちろん花火は大きくて良かったし、花火前のライブは地味で気にならなかったのだが、他がいかん。

一つには、スポンサーの表示だ。DHCなどは大枚はたいているのだろうが、花火が消えたすぐ直後に電光掲示板で煌々とスポンサー名を表示するものだから、余韻も何もあったものじゃない。花火の魅力の一つはもちろん色と光の競演なわけだが、もう一つの魅力は、消えた後の余韻である。日本古来のわびさびというか、無常観というか、去りゆく夏を懐かしむというか、そういった気持ちを花火の消えた後の数秒の静寂と暗闇で感じ取ることで情緒の深い人間になると思う。しかし花火が消えたコンマ何秒で電光掲示板が光りナレーションが流れるようでは、情緒のかけらも育たない。実際、会場からは失笑が漏れていた。あれでは、せっかくのスポンサーフィーも逆効果だ。選挙運動のようでセンスのかけらも無い。

仕掛け花火も酷い。まぁ僕は仕掛け花火そのものがそんなに好きじゃないというのもあるのだが、スポンサーの名前を仕掛け花火で見せられて誰が嬉しいのだろうかと疑問に思う。ナイアガラの滝で十分じゃないのか。あれだけナレーションやら団扇やら電光掲示板やらでDHCと刷り込まれているのだから、上乗せして仕掛け花火で見せられるのは、もはやブラックジョークに他ならない。もしかしたら、アンチDHCなのではないかと勘ぐりたくなるほどだ。結果として我々に与えられたのは、DHCというのは、売らんかなの商業主義でセンスのかけらも無いメーカーだというイメージだけだ。まぁCMなんかを見てもそうなので、それで良いのかもしれないけどね。

もう一つ酷かったのは、ハッスルだ。花火の本編が終わってアンコールまでの間にハッスル軍団が出てくるのは良い。インリン様の熱演もあって、結構面白い。しかし肝心のアンコールがどうも短く、その後にハッスルの試合をやってしまうのは興ざめだ。アンコールまでの間に試合をやれば、ほとんどの人が試合を見てハッスルの面白さを感じ取ったかもしれないのにねぇ。どうも短いようなアンコール花火の直後にハッスルの試合が始まり、しかもアンコールの最後が地味だったのもあって、観客は花火が終わってしまった不満をハッスルに対する感想と誤認したまま帰ってしまうのだろう。もともとハッスルに興味があった人は良いだろうが、マーケットを広げるという戦略としては失敗だったと思う。

花火そのものは、1万発ということで例年にも増して良かったのだから、来年はもうちょっと運営を考えてもらいたいものだ。広告というものを、観客の満足度とのトレードオフもしくはゼロサムと考えるから、こんな運営になるのだ。確かにCMを減らして本編を増やせば観客の満足度は上がるからゼロサムだと考えがちなのだが、そんなことは無い。ゼロサムのように思われるものをノンゼロサムにするのが、広告屋の腕だと思うんだけどね。JaSSTは、聴衆とスポンサーの価値をノンゼロサムにしたいものだ。

2007-08-13

SEA関西「テスト観点に着目したソフトウェアテスト設計プロセス」

第29回SEA関西プロセス分科会
「テスト観点に着目したソフトウェアテスト設計プロセス」
2006/11/21@日立システムアンドサービス会議室(なんば)

講演資料

※ちなみに、以下のカンファレンスの資料と同内容です。
第6回クリティカルソフトウェアワークショップ
「テスト観点に着目したソフトウェアテスト設計プロセス」
2006/11/16@秋葉原コンベンションホール(秋葉原)

#考えていたことはJaSSTでの発表とほぼ同じなんですが、プロセスとして並べると使いやすいみたいですね。

2007-08-10

アテスウェイ

昨日は少し早めに帰ったのだが、高速が大渋滞のため一般道で美女木あたりまで走ることに。ギリギリで間に合いそうなので、前から行きたかった吉祥寺のアテスウェイに寄る。東京女子大学の斜め前にあるキレイなショップだ。

お店に入ると左側がサロンで右側がカウンター。サロンは土日になるとずっと満席とのこと。カウンターでは、ケーキやパン、焼き菓子、コンフィチュールなど色々並んでいる。閉店間際なのだが、パンから香ばしい匂いがして、お腹が鳴ってしまう。

いつもなら初めて行ったお店ではケーキにするのだが、暑かったのでジュレとブランマンジェにする。カミさんとチビが好きなので、ロールケーキも買ってみる。あとはパンを少し。会計をしようとすると、イートインだがソルベもあるようで。食べてみたかったのだが、閉店間際なのでガマンガマン。

家に帰ってロールケーキを食べてみると、普通のスポンジよりもしっとりしていて美味しい。バナナと桃とのバランスもよい。何よりバニラビーンズのようなものが入ったカスタードクリームが、濃すぎず、かといって水っぽさなどなく、主張しすぎず、絶妙の味わいになっている。ペロッと食べてしまった。

翌朝食べたグレープフルーツのジュレもなかなか。ただドラゴンフルーツは種が食感を損なうのでいらないかな。グレープフルーツのほのかな苦みが活きるように甘さを抑えた味わいが、真夏に合いますね。ゼラチンの量も多すぎず少なすぎず、チュルンといけます。

というわけで、吉祥寺近辺に行った際は必ず寄るお店が増えて嬉しい限り。また行こうっと。

2007-08-09

情報システムの信頼性向上のための緊急点検結果と今後の対応について

経産省から「情報システムの信頼性向上のための緊急点検結果と今後の対応について」というドキュメントが出ている。甘利大臣からの指示によるものだそうで。

内容を見てみると、いつもの経産省のアンケートだ。結局のところ設問は「十分かどうか」「一般的かどうか」を問う内容になっている。

これは何を意味しているのだろうか。“確信犯”的な品質事故を起こしている組織をあぶり出したいのだろうか。すなわち、自分たちで十分ないし一般的ではない、と分かっているのにリリースして運用している組織をあぶり出したいのだろうか。しかし、このアンケートで明らかになるのは、確信犯で信頼性リスクのあるシステムを作ったがやっぱりマズいと思っている組織だけであろう。いわば、危機感を持っている組織だけである。

本当に明らかにしなくてはならないのは、自分たちが信頼性リスクのあるシステムを作っているのに気づいていない組織、すなわち危機感を持っていない組織なのではないか。だからアンケートの内容ももっと具体的でなければならないし、アンケートに答えられるように「信頼性リテラシー」を向上しなくてはならない。そもそも、信頼性基準や出荷基準の決め方について、もっともっと議論しなければならない。

しかし信頼性基準のようなものは、なかなか企業の外に出てこない。だからこそSECなどで国家プロジェクトとして実施すべきなんだろう。ただ気をつけないと、何か数値的な基準を集めて統計処理をすれば適正な信頼性基準が求められるなどという絵空事的アプローチになってしまう。

信頼性基準や出荷基準というのは、開発の集大成的な評価である。だからこそ、開発のレベルも、テストやレビューのレベルも、プロセスのレベルも、組織のレベルも、開発対象のレベルも、全てが重要となる。すなわち国家として信頼性基準の議論をするというのは、日本のソフトウェア開発のレベルという壮大な議論に真っ向から取り組むということに他ならない。それでいて現場目線から離れると意味が無くなってしまうという、難しい議論だ。

実はNGT/VSTPの隠された狙いは、そこにある。テストのモデリングをし、観点から網羅基準までシームレスに展開し、品質リスクの確定を行うことで、テストから見た出荷基準の策定を可視化するのだ。現状ではモデリングにトライする組織が増えてきた段階だが、最終的にはテスト設計から出荷基準の策定をシームレスにつなぎ、かつ開発で把握すべき品質リスクを全V&V工程でヘッジしながら出荷基準と品質リスクのバランスそのものを明示したい。でもまぁ、ここまでやるには、10年かかるかな。札幌で少し話そうかしら。

と、ここまで書いて読み返してみると、ハゲタカな文章になっている気がするなぁ。ちょっと反省。確かに、出荷基準はテストだけで決めるべきものではなく、他に色々な側面を十分に考慮しなくてはならない。書いてあるけど、再度強調。

あ、そうか。NGTでテスト観点そのものをモデリングしたように、出荷判定を決めるために着目すべき観点そのものをモデリングすればよいのか...。どこかの企業で一緒に考えてくれませんかね。もしくはJaSST東京で議論するのもよいかも。

2007-08-08

学者さんへの自己紹介

先ほど、近くの学科の先生が僕の顔を見に来た。何でも、来年ある分野でテストも少し関係する国際会議を開くとのことで、同じ大学でテストを専門にしている人がいるから顔を見に来たとのこと。

で、された質問がこちら。「テストのどんなことを研究しているのですか?」

困るんだなぁ。手広くやってます、じゃ分からないだろうし。テストの設計もマネジメントも両方研究してるし。テストアーキテクチャなんて言っても分からないだろうし。アンチデザインパターンに基づくテストだと、少しは分かっていただけるのかしら。

といっても、話せば長くなるしなぁ。時間無さそうだし。

結局聞きたかったのは、フォーマルアプローチなのかどうか、どんなドメインなのか、だったみたい。でも最近は(言わなかったけど)こっそりフォーマルアプローチも少しやってるしなぁ。ドメインも組込みからエンプラまで問わないしなぁ。

「文脈をしなやかに飛び越える研究をしてるんです」なんて言ったら、余計分からないし。

今度、パンフレットでも作りますかね。

ゼロサムとノンゼロサム

国立大学法人にいると、しばしば官僚組織との闘いになる。国立大学というのは基本的に、我々教官と事務方の2者で構成されている(技官さんもいらっしゃいますけどね)。彼ら事務方は元々公務員だし、今でも公務員気分の人が多い。自分の組織が赤字になることの恐怖も知らないし、M&Aされる可能性もリアルに想像できないだろう。

例えば、本来予算で支払うべき支出が支払えない、過去の実績が無いので客先への依頼状が発行できないなど、たった5年しか大学にいないのに、色々とすったもんだしてきた。でもまぁ5年もいると、こちらも闘い方を覚えてくる。

一番スカな闘い方は、こちらがヒートアップした状態であるべき論を振りかざし、相手の官僚的姿勢を罵ることだ。これは別に、相手が官僚組織で無くったって上手くいくわけがない。でも自分が昔やっていたのは、この闘い方。そして敗れ去り、捨て台詞を吐くわけだ。

もう少しマシになると、ルールの解釈について議論を始めるようになる。ここにこう書いてあるからOKなんじゃないんですか、それはどこに書いてあるんですか、という感じ。しかしこの闘い方も大概は上手くいかない。水掛け論になるからだ。

ここで発想を変えてみよう。向こうは向こうで、仕事を円滑に進めたいし、我々現場の役に立ちたいと思っている。下っ端だとそう思っていないような言い方をするので腹が立つが、そこはガマン。まずこちらから相手を信じる。

その仮定に立つと、向こうが何故官僚的態度を取るかが見えてくる。彼らに与えられているのは、権限というよりも責任なのだ。この責任というのはポジティブな意味、すなわち責任感といった単語で表されるような意味ではなく、ミスしたから責任取りますのようなネガディブな意味である。そうすると、何事も自分が責任を取らないように判断をするようになる。自己防衛本能だ。しかも彼らは、彼ら自身に関して言うならば、現場に優しい判断をしても全く利得が増えない。つまりゼロ利得とプラスのリスクだ。その構図では、ぜったいに官僚的判断を改めることはない。現場に優しい判断をすると、現場はプラスの利得とゼロのリスク。これは、ゼロサムゲームだ。

ゼロサムゲームで交渉を続ける限り、どちらかが折れるしかない。最終的には、お金を握っている方が勝つ。もしくは、より権力に近い方が勝つ。いずれにせよ、どちらかが損をする。

であるならば、この構図をゼロサムゲームで無くせばよい。利得を得る人がリスクも背負うようにすればよい。すなわち、現場が得をする場合は現場がリスクを背負うようにする。例えば何かを支出してもらう場合は、その支出の正当性について現場が責任を背負うような文書を書いて捺印し提出するとか。そうすれば向こうは、ゼロリスクだ。しかも現場に優しい判断をしたので、気分も良くなるだろう。プラス利得だ。対して我々は、プラス利得にプラスリスク。合計すると、ノンゼロサムゲームになる。

このゼロサムからノンゼロサムへの、問題の構図の転換というのは、実はソフトウェアの改善の現場でも見られる。スタッフと現場が対立して改善が進まない組織というのは、どこかがゼロサムになっていて、そこがボトルネックになっていると思う。だからコンサルタントは、ゼロサムになっているボトルネックを分析して、そこをノンゼロサムに変えるのが仕事なのだ。

ゼロサムからノンゼロサムへの転換業務は、別に何かしらの技術が必要なわけではない。鉄に磁石を近づけると、てんでばらばらな方向を向いていた内部の磁性体が同じ方向を向くようになるがごとく、ゼロサムで対立している現場とスタッフを同じ方向に向かせる思想が必要なのだ。しばしばその思想は、皆の利得をグルグル回るスパイラルになっていたりするのだが。

よく言うことだが、経験だけのコンサルタントは3流だ。一般化した技術を知っているだけのコンサルタントも、せいぜい2流にすぎない。ゼロサムからノンゼロサムへの転換など、組織全体を同じ方向に向けられるコンサルタントこそ1流と呼ばれるべきだ。そして、その思想がスパイラルになっているために、そのコンサルタントがそこにいるだけで組織が良くなっていく思想やエネルギーを持つコンサルタントは、超1流だ。

さて、僕はいつになったら超1流のコンサルタントになれるのかしらね。

2007-08-07

Re: ThinkVantage Access Connections

Access Connectionsの不具合のせいで、大学に来ても無線LANがつながらず四苦八苦。これで都合3時間は無駄にしてしまった。何度かAccess Connectionsと無線LANデバイスドライバを削除したり再インストールしたりしたら、やっとつながるようになった。

Windows95じゃないんだから...。

空港ラウンジでのマッサージサービス

伊丹空港で飛行機待ち。海外出張が多いのでマイルが貯まっており、ラウンジが使えるのはありがたい。そりゃ欧米便を年間に4往復もしてれば、貯まるよね。まぁ来年からは少し減らしたいと思っているが、仕事柄無理かしら。

ANAのラウンジには以前からマッサージサービスがある。現金を払わなくてもマイルでOKという魅力的なサービスだ。まぁ10分1500マイル、60分7500マイルなので、1マイル=1円だとすると相場よりも高いのだが、空いた時間を使えるという意味では有り難い。しかし時間にルーズな僕はいつも空港にギリギリで飛び込むため、そもそもサービスを利用する時間が無い。それでも、使えるチャンスを虎視眈々と狙っていた。

今回の出張は少し余裕のある予定なので、行きの羽田で利用しようと思ったところ、残念ながら一杯。帰りの伊丹にかけるぞっ!と意気込んで来たら、マッサージサービスは12時からとのこと。フライトは12時なのに。グスン。まさかマッサージを受けるために後の便に振り返るのもバカバカしいしなぁ。

つくづく、このサービスには縁がない。

ThinkVantage Access Connections

泊まったホテルのLANが速かったので、調子に乗ってLenovoから提供されるThinkPad用のサポートソフトウェアやらデバイスドライバやらをアップデートしたら、Access Connectionsが動かなくなった。いや正確に言うと、Access Connections自体は動くのだが、無線LANデバイスと同期しない。そのため[Fn]+[F5]を押しても、無線LANがON/OFFしない。そう言えば、アップデートの時にイヤな挙動をしてたんだよね...。

別にハードウェアスイッチがあるので困らないのだが、[Fn]+[F5]は指が覚えているので、チト不便。そろそろ再インストールの時期を示唆しているのか...。お盆だしなぁ。

2007-08-06

てふかん


今日は某社で講演の後に、てふかん勉強会に参加。東の池田・西の新美のうちの西の横綱の仕切りで、皆さんとっても熱心に参加されてました。仲さんは今日も絶好調。というわけで、勉強会の感想を「べつやくメソッド」で描いてみました。JaSST札幌のパネルも、いっちょこれでやってみっか。

2007-08-02

某社での講演のアンケート

先日の某社での講演についてアンケートが来た。SEPG向けだったので、いつもより少し踏み込んで話すことができた。全体としてはまぁまぁ、という感じのようで少し安心。でも有効回答数135のうち、3名は「あまり良くない」「良くない」という感想をお持ちだったようで、反省。というわけで、いくつか自由回答のコメントから抜粋してみよう。

「各ページでの説明が長い(くどい)」
う~ん、確かに。ごめんなさい。 m(_)m

「組込みソフトでしか活用できていない手法が多い。」
こういう取り組みに工数を割く余裕のあるSIerは少なくてねぇ...。
確かに例は組込みが多かったですね。反省。

「現状の短納期、他コストでここまでできる余裕が無い。」
できるところから始めましょう。無理をする必要はありません。別に大げさなことを全てやることは無く、身の回りの気がついたところから始めればよいのですよ。ディレイ分析とかね。

「スライド文字が多いのに書かれていない事の説明が多い。行間ばかり話している。」
書いてあることばかり話すのなら、講演する必要は無いと思うんですが...。

「抽象的な内容だったので、やや理解しづらい点あり。」
そうですねぇ。その通りですねぇ。でも具体的事例はNDAの関係でなかなか出せないんですよ...。

「ちょっと早口かな。」
全面的にごめんなさい。 m(_)m

「ちょっと難しかったかなっと思いました。」
そうですかぁ。頑張って分かりやすく話したつもりなんですが。反省します。

「テストの改善においてどこから着手すればいいかが良く分からなかった。」
自分たちが困っているところ、手を付けやすいところからで構いませんよ。改善の順序まで指示して欲しいのかしら。

「新しいネタも、もう少し仕込んで欲しかった。」
厳しいなぁ...。頑張ります。

「改善しようとするモチベーションを上げる話が欲しかった。」
そ、そういう方もいらっしゃったんですね。失礼しました。でもそれは、僕が話すことが最適なのかしら。

「タイトルと話の焦点がよく分らない。」
ちょっと気張ったので、ぼやけてしまいましたかね。すみません。

「私の勉強不足かもしれないが、初めて聞く専門用語が多く、専門用語については一段掘り下げた説明が欲しかった。時間がなければ専門用語の辞書のようなものがあるとありがたい。」
そうですね。ちょっとずつblogで。

「もうちょっと具体的な話を聞きたかった。」
「やや専門的な領域に入っていた気がします。」

どっちなんだぁ~。


しかし、最近「新しい話が聞きたい」とか「どこかで聞いた話だ」と言われることが多い。エバンジェリングが上手くいってるということで喜ぶべきなのかもしれないが、ちょっと辛いなぁ。もう少し新ネタができるまで、少し講演は控えようかしらね。

2007-08-01

JSQC/品質「製品品質の決定要因としての組込みソフトウェアと組込みソフトウェア・クライシス」

品質管理学会(JSQC)学会誌「品質」
「製品品質の決定要因としての組込みソフトウェアと組込みソフトウェア・クライシス」
品質,Vol.34,No.4,pp.45-51(2004)

原稿

#すり合わせ論にカブレてた頃ですね。

2007-07-31

SPI Japan2006「テストの改善、テストによる改善」

ソフトウェアプロセス改善カンファレンス(SPI Japan)2006
「テストの改善、テストによる改善」
2006/10/13@つくば国際会議場(つくば)

講演資料

#改善そのもののレベル、という話が初出でした。

2007-07-30

経営情報学会情報システム工学研究部会「ソフトウェアテスト技術」

経営情報学会 第3回情報システム工学研究部会
「ソフトウェアテスト技術」
2007/2/17@川崎市産業振興会館(川崎)

講演資料

#非常に気持ちの良いコミュニティでした。

2007-07-29

クレモン・フェラン

甘いものが好きだ。今風に言うとスイーツかな。小さい頃は代官山ヒルサイドのレンガ屋と目黒のモンドールでケーキを食べていたはず。両方とも今は無いみたい。味はさすがに覚えていないが、ケーキが好きだったのは覚えている。

その後ずっと特にケーキが好きという風には思わず、次にケーキ好きを自覚したのは大学に入ってからだと思う。朝来野という大学の友人にケーキ本を紹介され、むさぼるように色々なお店に行ったものだ。まだイル・プルー・シュル・ラ・セーヌが代々木上原にあった頃である。

その頃から良く行っていたお店が、広尾のクレモン・フェランだ。店のカウンターの後ろには、お子さんが酒井シェフを描いたような絵があり、とても微笑ましいお店だった。ケーキの味は絶品だが、どこか優しく懐かしい、そんなお店だった。坂上という小中高の友人の結婚式の参列者へのお返し(?)がクレモン・フェランのプチマドレーヌだったこともあり、一時期は顔を覚えられるほど行ったものだ。誕生日など、うちの記念日ケーキはいつもあそこだった。22年も営業したそうだが、そのうち18年くらいは通ったことになる。

そんなクレモン・フェランが、昨年の12月に突然閉店した。いや突然なのではなく、忙しかったりしてご無沙汰だった隙に閉店になってしまったのだ。その日のmixiには「大好きだった親戚のおじさんの訃報を聞いたような、そんな気分。当分、立ち直れないかも。」と書いてある。とにかく、ショックだった。

一体、なぜ閉店になってしまったのか。イル・プルーがWebサイトまで出すご時世なのだから、やはりケーキ業界は厳しく、資金繰りに行き詰まってしまったのか。いやあの味で人気が出ないわけがない。しかし良心的な価格だったし、最近は結構空いてたしな。いやそれはオレが行く時間帯が閉店間際だからだ。など色々と考えながら店の前を通るが、やはり復活はしていない。今日も前を通ったが、なんだかメキシコ料理か何かになっていた。見る度にショックだ。

しかし、ふと思い立ち検索してみると、酒井シェフは広尾のお店を閉めて(多分ご自宅かな)アトリエを開き、奥さんとのんびりお菓子作りを楽しんでおられる模様。息子さんは海外にいらっしゃり、リヨンのコンテストで4位に入賞したとか。もう誕生日にクレモン・フェランのケーキが食べられないのは同じだが、何だか嬉しい。少し涙が出た。

ほのぼのしたら元気が出た。でも、自分が作るものがこんなに愛され、自分の去就をこんなに心配されるなんて、本当に凄いと思う。ここのところ悲しいことがあって内心はあまり元気がなかったのだが、明日から少し元気に頑張れそうだ。

2007-07-28

マインドマップから始めるソフトウェアテスト勉強会のマインドマップ


先日技術評論社さんのテストプレスVol.5の企画で、池田さんと鈴木さんの書いた「マインドマップから始めるソフトウェアテスト」の勉強会に顔を出した。帯を書いた手前もあり冷やかしのつもりだったのだが、せっかくだからとマインドマップを書いてみた。ちなみに、生まれて初めてのマインドマップ。

このマインドマップは、勉強会の講評のために作ったものである。テストにマインドマップを使うことの利点を、マインドマップでまとめている。皆が勉強会をしている裏で、せこせこホワイトボードに描いてたのよね。でも、楽しかったなぁ。

mixiでは、秋山さんに「マインドマップじゃなくて連関図だよね」と言われたが、生まれて初めてなので仕方がない。この後マインドマップに目覚め、アイデア出しと一次整理はマインドマップを使うようになった。MindManagerも買ったしね。

内容については、他のエントリでまったり解説する予定。期待はしないこと。

2007-07-27

測定無くして改善無し、なんてことは無し

「測定無くして改善無し」という言葉をよく聞く。一見、正しい。しかし本当は、違うと思う。厳密に言うと、組立機械産業における生産工程のように測定しやすいドメインで、かつ非常に改善レベルの高い組織であれば成立する。しかしソフトウェア開発のように測定しにくいドメインで、かつそんなに改善レベルが高いわけでない組織の場合は成立しないと思う。

そんなに改善レベルが高いわけではない組織の場合、「測定無くして改善無し」の原則を貫こうとするとどうなるか。まず問題点を把握するために測定を行う。しかし把握するために測定するのだから、問題点は分かっていない。いや現場は分かっているのだが、測定を推進する人は分かっていない。するとイキオイ、結果系のメトリクスばかり測定するようになる。バグ密度とか。少し気が利いている人だと、レビュー密度とか。で、統計解析を行うわけだ。

統計解析というのは怖いもので、何かデータを入れれば、何か式が出てくる。すると、何かが分かった気になる。「レビュー時間が少ないから、不具合が多いのだ。ほら、この式とグラフを見よ。一目瞭然だ」。

このセリフに違和感を感じた人は、正常だと思う。そんなことは、言われなくても現場は皆分かっている。一目瞭然どころか、見なくても知っている。それをわざわざコストをかけて測定し分析しても、ありがたみは無い。むしろコストアップになって有害である。

改善レベルが高いわけではない組織には、問題点がたくさんある。しかもその多くは、現場が肌感覚として認識している。であれば最初にすべきことは、何も分からない状態で測定することではない。

最初にすべきことは、どんなトラブルがどれくらい起こっているかを棚卸しすることだ。次に現場の開発者が寄り集まって、無理ならキーマン達だけでも集まって、現場で起きている問題点からトラブルまでを丁寧に紡いでいくべきだ。この作業に、測定はいらない。必要なのは、トラブルを見つめ直すこと、自分たちが普段感じている問題点を吐き出すこと、そして論理的にそれらをつないでいくことだ。落ち着いて、腰を据えて、時間をかけて、取り組むことだ。

そうやって「トラブルのモデル」を作ったら、次に改善策を設計する。ここで改善策をブレーンストーミングなどの“思いつき”で挙げてはならない。良いトラブルモデルは、適切な改善策を示唆するからだ。もし適切な改善策が示唆されないのであれば、頭を抱えてう~んと呻るよりも、トラブルモデルを見直した方がよい。もし余力があれば、その改善策が形骸化する状況まで推察するとよい。

そこまでできて始めて、測定の登場に相成るわけだ。トラブルの根本原因となっている悪さを示すメトリクス、トラブルの起き方を示すメトリクス、改善策が有効に機能していることを示すメトリクス、改善策が形骸化することを示すメトリクスを定義し、測定するのだ。これらのメトリクスは、トラブルモデルがきちんと組まれていると容易に決められるだろう。

こうやって決めたメトリクスは、結局のところトラブルモデル通りにトラブルが発生しているかどうかを確認するためのもので、何だか分からない問題点をあぶり出すために測定するものではない。測定で何か新しいことを把握する前に、やるべきことがたくさんあるのだから。

そうやって改善策を実施していくと、測定しなくても改善していることが現場の開発者には実感できるはずだ。改善効果を実感するために測定せよ、なんてことを言う人がいるが、良い改善策であれば、改善策を実施していると改善できていることが測定しなくても実感できる。測定はあくまで、その実感を追認するためのものだ。

この文章は別に、測定そのものを否定しているわけではない。測定は改善のための強力なツールであることは全く同意する。だからこそ、この強力なツールを最大限に活かさないといけないのだ。あまりに強力であるがゆえに、測定すれば何か新しい問題点が分かり、測定すれば改善されると誤解してしまうのである。しかし本当は、強力なツールだからこそ、使う側の我々が現場をよく知り、よく考えねばならないのだ。測定は目的ではない。知恵を絞って現場の問題を考え抜くための道具なのである。ソフトウェアの開発を改善しようとしている人達には、そこを誤解しないで欲しいと強く思う。

Just enoughな品質

JaSST関西のパネルを聞いていたら、アジャイルプロセス協議会岡島さんが「Just enoughな品質を作るべき」みたいな発言をしていた。話の流れは確か、網羅テストをするのは時間的にも難しいとか何とかだった気がする。違ったかな。顧客満足をジャストに追求するという話だったかな。顧客が望んでいない余計な機能は実装するな、という話だったかな。うろ覚えで申し訳ないので、誰か教えてください。いずれにせよ、以下の話は岡島さんに対する批判ではない。だって発言のバックグラウンドを覚えていないのだから。

さて、そこかしこで話題になる"Just enough quality"論。僕も色々なコンサルの依頼の際に「うちはオーバークォリティ気味なんだよ。もっと効率的に製品を出荷したいんだよ」と宣う方を見たことがある。まぁ気持ちは分からないでもない。

かく言う僕も、日経BPの依頼で「品質とスピードを両立させる」というテーマのセミナーで話したことがある。まぁ僕の講演タイトルは「品質とスピードを両立させるなんてオイシイ話はあるのか?」でしたが、多少迎合気味なのは反省点。

最近思うのは、"Just enough quality"を口にする組織のほとんどは不具合や納期遅延の多発に苦しんでいるということだ。一方では不具合や納期遅延によるトラブルを撲滅したいと言い、舌の根も乾かぬうちに"Just enough quality"の話をする。もちろん背景にあるのはお客様のためとかなんとか。

彼らに興味があるのは、顧客満足度ではない。もちろん開発者満足度でもない。ただ財務指標を良くすることだけだ。だからトラブルも撲滅したいし、余計な品質も作り込みたくない。財務指標を良くする手段としての"Just enough quality"なのだ。

その財務指標というのは、いつからいつまでの財務指標のことなんだろうか、と思う。直近の1年、よくて2~3年なのではないか。これもまた一般論だが、品質トラブル撲滅と"Just enough quality"の両方を口にする人は、中長期的視野に欠けていると感じることが多い。

僕の経験というか感覚では、"Just enough quality"を目指している組織は、ひ弱である。技術的なしっかり感というか、要求や設計をあらゆる角度から眺める視座というか、トラブルの時の復旧力というか、そういった能力が低いと思う。ある条件でたまたまトラブルが無い開発ができても、次に同じ品質を達成できるような気がしないのだ。いつもギリギリ。いつもフラフラ。

そういう組織は「最適な開発」ができているのだろうか。成功したプロジェクトでは、そうかもしれない。しかしソフトウェア開発組織を中長期的に維持していくために必要なのは、ある程度条件が異なっても、品質の良いソフトウェアを安定して開発できることだ。統計用語で言うと、ロバストネス。ダーウィン的に言うと、適者生存かな。だから、"Just enough quality"を目指すということは、短期的には優位だが、中長期的には劣った戦略だと思う。

結局のところオーバークォリティというのは、技術力向上の機会なのである。それも、セミナーなどの座学や演習で得られない、様々な条件のプロジェクトへの対応力向上のトレーニングなのだと思う。開発と改善、教育をまとめて進められる、得難いチャンスに他ならないのだ。"Just enough quality"論者は、そのあたりのことを理解していないのであろう。きっと、開発は開発、改善は改善、教育は教育で分けて実施しているとか何とか主張するのかな。でも、それは効率が悪いし、別物として扱うと現場は改善や教育に時間を割かない。要するに、間違いなのだ。

こう主張すると必ず「オーバークォリティのソフトウェア開発はコストがかかるので、そもそも受注できないか、赤字になる」などと言う輩がいる。では、そのコストアップや赤字、納期遅れの原因は何だろうか。不具合やマネジメントトラブルへの対応のせいではないのか。そうした組織が今やるべきことは、"Just enough quality"を狙って組織をひ弱にし、不具合やマネジメントトラブルが起こるリスクを高めてしまうことではない。オーバークォリティを狙って組織を鍛え上げ、不具合やマネジメントトラブルそのものを減らすことでコスト削減や納期短縮を狙うことだ。

だから我々は、胸を張って「オーバークォリティを実現しろ」と言うべきだと思う。オーバークォリティを狙うことこそが、自社のスキルを本当の意味で(最も効率的に)向上させ、中長期的に優位に立ち続ける戦略なのだと。さもないと、ひ弱な組織に成り下がり、いつも品質トラブルにビクビクしなくてはならないのだと。

2007-07-26

自分が考えたことを他人が論ずるのを聞くこと

JaSST関西に行ってきた。今回はASTER理事長としてではなく、純粋に聴衆として参加だ。目当ては、島津の吉澤さんの「テスト観点に着目したテスト設計の実践事例」の発表である。

内容については他の考察も含めてそのうちゆっくり書くとして、ミーハーな感想を。やっぱり、自分が考えたことを他人が論ずるのを聞くのは、照れくさいけど、嬉しいね。吉澤さんは僕がマンツーマンでコンサルをしたわけではなく、僕の発表を聞いただけで実践してくれている。これがまた、嬉しい。

クリエイティブな快感というのは、自分が生み出したいものを生み出した瞬間に得られる快感しか知らなかったけど、他にも快感があるというのを感じた次第です。しかし、こそばゆいね。

ネットと論文

昨日はJaSST関西だったのだが、水野先生と有意義な議論ができた。最近クオリア的テストにかぶれているが、そのヒントとなるような話。

しかし投稿前なので、blogに書いてはいけないとのこと。う~ん、学会というのは昔は自由な議論の象徴だったと思うのだが、今ではネットでの自由な言論を阻害する存在なのだなぁ、と思う。特許も同様。知的所有権を軽んずるつもりは無いが、タイムリーで自由な議論を阻害するインフラや仕組み、法規制があると、創発的な議論が難しくなるなぁ、と感じた次第。クリエイティブな議論って、ワクワク感が心を満たしている時にできるものであって、そのワクワク感が消えるとクリエイティビティも消えるような気がするのよね。残念。

エバンジェリストとパクリ

僕はテストエバンジェリストを最近まで自称していた。今でも、仕事の一部はエバンジェリングだ。国内外から日本の現場に役立つパラダイムや概念、方法論、技法、ツールを紹介する仕事である。学者というのは、ある意味エバンジェリストだ。確信犯的に輸入商社的研究スタイルを採っている人もいるし、オリジナルな研究のためのサーベイが実はエバンジェリングだったりする。

エバンジェリストというのは、とても聞こえの良い職種だ。しかし僕らは、エバンジェリストの立場である限り、新たなパラダイムや概念、方法論、技法、ツールの創造はあまり行わない。福音を伝えるのがミッションだからだ。これは、発展途上産業にとって、とても意味のある仕事である。

エバンジェリストがどこかの組織に属しており、その組織の都合によって福音をバラまいている場合、話は簡単である。どんな福音を伝えればよいかは決まっており、福音を創造した人もそれを許可しているからだ。そして、福音を聞いている人も、エバンジェリストが創造した福音で無いことを十分に理解している。

しかし自称エバンジェリストは違う。福音を聞いている人は、他の人が創造した福音を伝道しているのか、自分で創造した福音を分け与えているのかが、あまりよく分からないからだ。未開の地に行って伝道した結果、神父そのものが神だと思われるようなものだろうか。

一般に、オリジネイターの評価は高い。創造に対するリスペクトが上乗せされるからだ。一方、エバンジェリストは(その役割において)オリジネイターではない。しかしエバンジェリングそのものには、オリジネイターだと誤解されるリスクがある。

このリスクを分かりやすく言うと、パクリである。他の人が考えたことを、さも自分が考えたように、もしくは創造者の名前を出さないことで暗黙的に自分のアイデアのように話すわけだ。だから知的所有権という制度があるのだが、全てに法の網がかけられるわけではない。だからアカデミックな世界では引用というマナーがある(査読可能性の確保が第一義だが)のだ。

しかしコンサルタントやエンジニアのような、アカデミックな素養を積む必要が必ずしも無い職業の場合、そのマナーを持っていないことがある。例えばセミナー資料を作る際などに、さも自分がオリジネイターのように書いてしまうわけだ。ただこれは、その事項が周知の事実だとして書いた場合も同じような誤解を生むから始末が悪い。

実は昨日も、あるエンジニアさんからそんなような相談を受けた。JSTQBのシラバスの一部をセミナー資料に引用したいから許可をくれというのだ。もちろん誰かから指摘を受けて反省の色を見せながら来たのだが、何とも返答に困った。彼らがJSTQBに金銭的損害を与えるようなら、ASTERとして法的手段に訴えなければならない。しかしシラバスは公開されている資料であるし、元々ISTQBのシラバスの翻訳であるし、何よりもそもそもJSTQBというのは皆にテスト技術の勉強を促す仕組みであって儲けるための仕組みではない。だとすれば、色々なところで引用してもらうのは喜んでこちらからお願いすべきである。

なので、ASTERの理事長およびJSTQBのステアリング委員長としてではなく、全く個人的な意見として意見を言っておいた。セミナーの講師というエバンジェリストにとって、パクリは甘美な罠である。自分たちがほとんど知的リソースを投下せずに、オリジネイタープレミアムを受け取ることができるからだ。しかし、自分たちのレベルが上がれば上がるほど付き合う顧客のレベルを上げないといけないのだが、レベルの高い顧客はそのパクリ行為を見抜き、付き合ってくれなくなる。そうすると、自分たちの知的リソースを「消費」するだけの顧客としか付き合えず、仕事をすることで自分たちの知的リソースを「蓄積」できるような顧客とは付き合えない。また知的リソースを獲得もしくは洗練するために必要な外部コミュニティとの付き合いも、パクリがバレるとできなくなる。そうすると、コンサルタントやエンジニアのような知的職業はジリ貧になり、単なる顧客の手足の域を出なくなる。そこまでのリスクを冒す必要があるのだろうか。一つ一つ丁寧に引用すればよいだけなのに。

とまぁ、偉そうに述べたが、気をつけてはいるものの、僕も気がつかないうちにパクリをしていると思う。最近はエバンジェリストを主な職業とせず、オリジネイターやビジョナリストになりたいと思っているが、まだまだエバンジェリングも必要である。偉そうに説教を垂れたのだから、自分でも気をつけたいと思う。もし僕が何かをパクッっていたら、すぐに知らせてくださいませ。

2007-07-25

AQCtion! 2007

AQCtion! 2007 (Alternative Quality Conference)

日時:2007/9/12(水)~14(金)
場所:NOT(Polish Federation of Engineering Associations), Wrocław, Poland
締切:締切済み

見込:欠席

ラジカルで面白そうなカンファレンスだ。Hans Schaeferなんかが関係している。3日目はTest Management Summitとのこと。

European Test Centre

福井さんから"European Test Centre"というWebサイトを紹介される。厳密にはAQCtion!という一風変わったカンファレンスを紹介してもらったのだが、ともあれ面白そうなドキュメントが掲載されているのでメモ。Bogdan Bereza-Jarocińskiという人がやっているみたい。

2007-07-24

大阪のホテル


JaSST関西のため、大阪のホテルに宿泊。キレイなホテルなのだが、色々と間が抜けている。例えばルームキーはカードなのだが、ホテル名が印刷され、マジックで部屋番号が書いてある。う~ん、落としたらアウトだよなぁ。

部屋にはいると、テレビには上のような画面が。部屋の掃除の報告用の画面なのだろう。ふ~ん、こうやって報告しているのか。こんなところもIT化されて効率化されるのね。

2007-07-23

ムダ遣い

我が電気通信大学は、国立大学法人である。国民の皆さんから、税金から運営補助金なるものを頂いて運営されている。昨今の国の財政状況の悪さなどから、我が大学も財政的には楽ではない。効率化係数の名の下に運営補助金も減らされることもあり、定年退官した教官の補充がなされないほど厳しいようだ。

そもそも、これまでのビジネスモデルやオペレーションの方針をほとんど変えずに(もちろん小手先レベルでは変えているが)、財政状態を良くしようという魂胆が間違っている。いや、企業経営も無い経営の素人である大学の教官が、選挙戦術だけによって学長になり、大学の経営をするというのがおかしい。そんな学長、すなわち経営者に率いられているので、我が大学も一向にまともな経営戦略が出てこない。財政状態が悪いから教官、すなわち利益を生み出す人間を減らす(増やさない)というのは、ダメ会社のリストラに良くあるパターンだ。すぐに縮小のスパイラルに陥り、競争力を失っていく。このままでは、早晩文科省に目を付けられ、農工大あたりと合併させられてしまうだろう。

経営レベルでもおかしいのだが、運営レベルでもおかしい。そもそも財政状況が厳しいのだから、支出を厳しくしないといけないことは自明だし、さまざまな経営施策に反映されている。しかし国家公務員根性が抜けないのか、倹約するという発想からはほど遠い。

いや、紙の質を上質紙から中質紙に落とすなどという小手先の策は得意だ。それから、教官を増やさないなどという競争力も同時に削いでしまう策は得意だ。しかし、何というか、決めた方針は見直さず、割いた予算は全て使わないと気が済まないという根本的な問題点は何ら是正されていない。ちなみに年度予算は全て使い切らないと怒られるので、余った研究室は無駄な買い物をしている。

さてうちの大学のWebサイトのトップページ近辺がリニューアルされたそうだ。昨日までのページはこちら。別に昨日までのページに愛着があるわけではないが、このタイミングでこのデザインに変更する理由が何なのか、全く分からない。ちなみに、その前の世代のページはこちら。この変更はさすがに理解する。酷いよね。でも、今回の更新は、全く意味が分からない。

この変更には、いかほどのコストがかかるのだろう。数十万円か、百万円を超えるのか。こんなムダ遣いをしている限り、うちの大学の財政状態は改善しないだろうね。もっとまともな経営陣にならないかしら。はぁ。

ASTA 2007

ASTA (Asian Software Testing Alliance) 2007 International Software Testing Conference

日時:2007/10/10(水)~11(木)(8~9:チュートリアル)
場所:COEX, Seoul, Korea
締切:締切済み

見込:出席

韓国のテストカンファレンスに日中韓のセッションがくっついたもの。ISTQBの委員をやっているコンサルがチュートリアルをする。日本からも発表者が出る。

2007-07-21

ICST 2008

ICST 2008(International Conference on Software Testing,
Verification and Validation)


日時:2008/4/9(水)~11(金)
場所:Radisson SAS Lillehammer Hotel, Lillehammer, Norway
締切:2007/10/5 - 研究論文アブスト投稿, 2007/10/12 - 研究論文投稿

見込:微妙。入学式がいつになるか...。

IEEEのテストのカンファレンス。2008が第一回。

ISSTA 2008

ISSTA 2008(International Symposium on Software Testing and Analysis)

日時:2008/7/20(日)~24(木)
場所:Seattle Hilton Hotel, Seattle, USA
締切:2008/1/31 - 研究論文投稿

見込:行けないですね、きっと。

ACMのテストカンファレンス。伝統がある。

組込みシステムの安全性向上の勧め

深夜のファミレスで、SQuBoKの原稿を泣きながら書いている。テーマは安全性だ。僕が安全性について書くなんて僭越極まりないので、参考文献としてIPA/SECの「組込みシステムの安全性向上の勧め」(以下「勧め」)と、Design Wave誌の2006年12月号(特集1が「組込みシステムの信頼性と安全性を高める」である)を持ってきている。

前者はイマイチな出来である。無料で配っていると思っていたら、この薄さと内容で税別571円だそうで。ちょっとボリすぎだ。DW誌が税込1,320円なのだが、この12月号の特集1の半分の内容も無い。税金で運営しているのだから、PDFで配ればいいじゃないか。何というか、お役所的だと思う。一方後者は、よく出来た特集だ。安全性に興味がある方はぜひご一読を。

さてこの「勧め」だが、どうも内容がチグハグだ。要するに、機能安全をソフトウェアに適用するという知的作業をほとんどやっていない人達が、機能安全を宣伝するために書いた書籍になっている。まぁ機能安全部会のメンバを見れば仕方がないとも思うのだが。もう少し何とかならんものかね。

例えば「近年の組込みソフトウェアは、非常に規模が大きく、複雑に進化して」いるから、いろいろな機能は「大局的に見るとあたかも『ランダムに実行される』という形に限りなく近くなって」いるため、故障は「限りなく『ランダム故障』に近い」とか書いてある。規模が大きく複雑になっても、ユーザが良く使う操作とあまり使わない操作はある程度予想できる。またバグは偏在する。だとするならば、絶対にランダム故障になどならない。そう扱う方が機能安全のフレームワークからすれば扱いやすいのかもしれないが、手段と目的を履き違えている。

また機能安全を実現する実装技術の章では、再利用とコーディング作法が書いてある。しかし再利用は別に機能安全を実現する手法ではないし、「勧め」にもその辺の関係は書いてない。コーディング作法は言語仕様などに起因する人間の間違えやすさを防ぐようルール化したものだから、機能安全の実現ではなくて、本質安全の実現だ。機能安全的開発プロセスではあるが、そういう意味で書いてないだろうし。SECの成果の宣伝をしたいのは分かるが、正直、他に書くべきことは一杯あるだろうに、と思う。

さて「勧め」にはテストの説明も書かれているのだが、この説明が古くさい。今どきテストの設計と実施を分けずに、まとめて「開発の後半で適切なテストを実行して、システムの動作上の問題点を早めに洗い出しておくことはきわめて重要」と書いてしまうなど化石的だ。気の利いたテストの専門家ならWモデルの重要性くらい説明すると思うのだが。

もっとおかしいのが、テストと対比させる形で「検証技術」という概念を提示し、その中にレビューやインスペクションを入れている点だ。何でも、レビューやそんな対比をして何になるのか。気の利いたテストの専門家は、テストもレビューも似たような活動であり、いずれにせよ上流から品質をおさえるのが重要だと思っているのにね。変なの。

もっとおかしいのは、形式検証だ。テストもレビューもインスペクションも、メリットとデメリットが述べられている。それは当然だ。どんな技術もメリットとデメリットがあるのだから。しかし形式検証はメリットしか述べられておらず、しかもテストは膨大になるが形式検証では大丈夫、というようなトーンで書いてある。ちょっと待って欲しい。モデル検査が悩んでいるのは、状態爆発問題であろう。これって、テストが膨大になるのとどう違うのか?テストは項目数が爆発しないように様々な仮定を置いたり割り切りを行って間引きや剪定を行うが、モデル検査だって様々な工夫をして状態爆発を防いでいる(らしい)。同じじゃないか。こんな欺瞞的で現場を知らない書き方になっているのは、日本では機能安全の推進者の一部が、形式検証の推進者だからだろう。誰が何を書いてもいいが、技術的にフェアな、もっと言えば現場のエンジニアをミスリードしない書き方をして欲しい。

安全性や機能安全は、消費者にとって、そして日本の産業にとって非常に大事な概念である。ソフトウェア産業にとっても、極めて重要な概念になっていくだろう。だからこそ、ハゲタカの喰い物にされてほしくないと思う。この冊子が書かれてから1年近く経つので、この部会の内部ではもっとまともな議論ができているであろうことを祈りたい。

2007-07-20

JSQCシンポ「なぜソフトが組み込まれると品質が悪化するのか?」

品質管理学会 第114回シンポジウム
「なぜソフトが組み込まれると品質が悪化するのか?」
2007/7/3@日科技連(千駄ヶ谷)

基調講演の資料
パネルの資料

#パネルではもう一歩踏み込みたかったなぁ...。

2007-07-19

有名人

某社の講演が終わって、仕事のため浜松町の貿易センタービル前のタリーズにいた。すると、おすぎが登場。普通に食べ物を買って隣の隣に座り、一言も喋らず(一人なんだから当たり前か)出て行った。そう、ここは文化放送が隣なので、芸能人が多いようだ。

少しすると、おすぎの座っていた席で打ち合わせが始まる。あの席は文化放送御用達なのか?耳に入った情報によると、女子プロレスラーの吉田万里子選手とのこと。実は寡聞にも知らなかったのだが、耳に入った情報をググッって検索し、画像から本人と確認。いや、便利な世の中になった。

タリーズに4時間いて、腹が減ったので六本木に移動。いつものように天鳳で夕食を取ろうと歩いていると、「行列のできる法律相談所」の丸山弁護士の選挙事務所を発見。本人もにこやかに握手している。

1日に3人も有名人に会うのは久しぶり。でも何というか、得したようなそうでないような。ビミョーな感じでした。

最近のコメントとGoogle

最近のコメント欄がどうも上手く動かない。最新のコメントが表示されなかったり、削除したコメントが表示されたり、FirefoxとIE6で動作が異なったりする。う~ん、謎だ。フィードのメカニズムが知りたいところ。

そうそう、やっとGoogleでも検索可能になったようで。Google八分で無いことが分かって安心です。テクノラティでも検索可能なんですか。今度やってみよ。

2007-07-18

修悦体


/.経由。「君は修悦体を知っているか」。新宿駅の工事による一時的な行き先案内表示のフォント。

確かにストリートアートに他ならない。アールがキレイに出ているし、そこはかとないユーモラスさと控えめさが何とも言えない。アメリカ的合理主義だと、こういうテンポラリなものについては、どうせすぐ無くなるからと手抜きをするのだと思う(別に根拠は無いので、そうじゃないかもしれない)。でもこういうところに手を抜かないのが、何となく日本的で、技術者魂をくすぐる。その姿勢そのものが美しいと思うのは、僕だけだろうか。

ブログにフラグを設定

ん?bloggerの「ブログにフラグを設定」ボタンの横のフラグが立っているぞ。う~ん、訳も分からずさっき自分で押したからなんだが、何か悪いことが起きるのかしらん...。

ヨガ

咳さんのコメントを読んで「ん?」と思い、Engineer Mind誌のヨガのページを見てみる。すると、確かにヨガのページが。今週は上半身を捻るストレッチの模様。確かに、こりゃメインだ。

この時間まで大学にいるので、早速トライ。身体がバキバキ音を立てているが、確かに気持ちヨイ。高校の時にバスケの練習前にやっていたストレッチなので、そのイメージからか今までは床に座ってやっていたが、椅子に座ってもできるなぁ。なかなかいいですね。

というわけで、皆さんもトライしてみましょう。

2007-07-17

ハゲタカ

なぜかEngineer Mind誌が送られてきたので、読みながら遅い昼メシを食べる。特集1は「ソフトウェア経済学」だ。日経BPでの松原さんの記事以来、この手の話題は多い。非常に興味深い話題なので、ちょっと読んでみることに。

ソフトウェアの価値をきちんと測定し、(特に受託や請負の)ソフトウェアの取引を適正なものにしようという活動のようだ。その意義は非常に重要で、産業界を挙げてすぐにでも取り組まなければならないだろうし、取り組んでいるという話もよく耳にする。非常によい特集だ。

ところが読んでみると、何のことはない、半分はゲーム理論だのアジャイルセル生産だのの宣伝に過ぎない。「セルは一定の生産性と品質を持つ」という仮定から「開発の生産性や品質が平準化され効率的に開発できる」だの「生産性や品質が一定であるので効率的な投資が行える」といった効果を謳っているが、そんなもの効果でも何でもなく、単なる仮定の言い換えに過ぎない。そもそも、その仮定を成り立たせるのが難しいから皆苦労しているのではないか。

そもそもこうしたムーブメントというのは、一つの旗に過ぎない。その旗の下にさまざまな知見を持った人が集まり、議論し、動機付けされることで、世の中に役立つ活動に昇華していく。そうした活動はソフトウェア開発以外にもたくさんあり、それぞれ尊敬すべき活動である。

しかし旗を掲げると、その旗を自分の利益のために活用しようという輩が出てくる。政治家などはその最たるものだ。一言で表現するならば、ハゲタカである。ハゲタカはまだ屍肉を喰らうからまだマシな方で、こうした輩は育とうとするムーブメントを喰らって殺してしまう分、始末が悪い。ハゲタカ以下である。

別にソフトウェア経済学とゲーム理論、アジャイルセル生産プロセスは本質的に関係ない。確かにソフトウェア経済学を発展させるツールとしてゲーム理論やアジャイルセル生産プロセスは有効なのかもしれないが、雑誌の特集なのであればそんなバーター取引のようなことは止めて、(特にテーマ記事に)ソフトウェア経済学の全体像を丁寧に記述することに力を注ぐべきである。いい加減な図を載せてお茶を濁している場合ではない。

ハゲタカは別にコンサルタントだけではない。大学の研究者もハゲタカになりうる。例えばDependabilityという概念があるが、こうした社会的に重要であり、かつ広く解釈されうる概念はハゲタカの良い標的になる。日本の情報系の分野ではDependabilityという概念が流行っているが、自分の研究がDepentabilityに関係すると広言している研究者の多くはDependabilityの基礎すらも分かっておらず、単に「高信頼性」的な概念が自分の研究のアピールポイントの一つであるから群がっているだけだ。本当の意味で、日本の情報系分野にどのようなDependabilityの活動が必要なのかを議論しているとは思えない。

こうしたハゲタカコンサルタントやハゲタカ研究者は、産業のことや日本のこと、世界のことなどはどうでもよく、自分のビジネスが上手くいくことや自分の研究が注目されることにしか興味が無いのだろう。いや興味はあるのかもしれないが、そうした広範な問題点をフェアに議論する能力を備えていないだけかもしれない。だから自分の分野という(問題そのものに比べて)矮小な範囲でしか解を提示できないのかもしれない。

また、そういうコンサルタントや研究者を重宝する政府機関も困ったものだと思う。本当に国のこと、産業のことを考えて発言する権威を選べばよいのに、決してそうはしない。自分たちにニコニコするハゲタカと付き合っていた方が居心地がよいだろう。本当に国のことを考えるのであれば、容赦なく政府機関を批判する岸田孝一さんのような一言居士に、土下座してでも手伝ってもらうべきだろう。

我々は票のために屍肉に群がる政治家をハゲタカと批判する。また企業救済を謳いながら実のところは解体による利益を狙っているファンドをハゲタカと批判する。しかし、周りには規模の小さなハゲタカがうようよいるのだ。こうしたハゲタカに瞞されないように、情報の取捨選択を行いたいものだ。

2007-07-16

探索型テストを紹介する理由

ちょっと探索型テストを日本に紹介してみようと思う。まぁLessons Learned in Software Testing(邦訳:ソフトウェアテスト293の鉄則)に紹介されているが、例えば次回のJaSST'08東京で改めて紹介してみてもよいかな、と思っている。というわけで、関連するWebの翻訳や要約でもしてみるか、と思う次第。とりあえずWikipediaのエントリを翻訳。

訳してみて思うが、とても誤解を導きそうな技法であることは間違いない。この技法(というか思想)は、James BackやDanny Faughtのようなスゴ腕のテスト技術者だからこそ成功するものであり、テストの基礎すらも分かっていないテスト作業者では単なるアドホックテスト、もしくはモンキーテスト以下のものにしかならない、という点をしっかり理解しておく必要がある。Wikipediaにも書かれているが、記述型テストでガッチリ設計し、さらに突っ込みたい部分を探索型テストで補うという使い方以外はあり得ない。全て探索型テストで済ませるというのは、自殺行為である。各レベルのテスト工数のせいぜい20%以下に留めておかないと、品質の保証からはほど遠い結果になるだろう。

そんなリスキーな技法であるにも関わらず紹介したいと思っているのは、テスト技術者に職人的なキャリアパス、もしくは憧れがあってもいいのではないか、と思うからである。記述的なテスト設計をきっちりできる一級建築士もクールだが、探索型で短時間に重大なバグをバンバン見つける腕の良い棟梁もカッコイイではないか。そんなイメージで読んで欲しい。

2007-07-15

Exploratory testing: Wikipedia

適当訳シリーズ。WikipediaのExploratory testing

Exploratory testing is an approach in software testing with simultaneous learning, test design and test execution. While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run.

探索型テスト(Exploratory testing)は、ソフトウェアテストの設計と実施、そして学習を同時に行うアプローチである。テスト技術者は、テストを実施しながら、経験や創造性と共に新たに良いテストを思いつける能力を身につけていく。

History: 歴史

Exploratory testing has been performed for a long time, and has similarities to ad hoc testing. In the early 1990s, ad hoc was too often synonymous with sloppy and careless work. As a result, a group of test methodologists (now calling themselves the Context-Driven School) began using the term "exploratory" seeking to emphasize the dominant thought process involved in unscripted testing, and to begin to develop the practice into a teachable discipline. This new terminology was first published by Cem Kaner in his book Testing Computer Software. Exploratory testing can be as disciplined as any other intellectual activity. thats it

探索型テストは、昔から行われてきた。アドホックテスト(ad hoc testing)に似ている。1990年代前半、アドホックテストはいい加減で注意の足りない作業のことだと考えられることが非常に多かった。それに対し、"Context-Driven School"と称するテストメソドロジストのグループが「探索型」という用語を用いるようになった。あらかじめテスト項目を決めておかないからこそ必要となる思考プロセスを強調し、かつ勘や経験から伝承可能な技術にするのが目的である。この新しい用語はCem Kanerの"Testing Computer Software"(邦訳:基本から学ぶソフトウェアテスト)が初出である。探索型テストは、他の取り組みや技法と同じように、いい加減なものではない。

Description: 内容

Exploratory testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The testing is dependent on the testers skill of inventing test cases and finding defects. The more the tester knows about the product and different test methods, the better the testing will be.

探索型テストは、ソフトウェアが実際のところどのように振る舞うのか、ソフトウェアが複雑なテストケースや単純なテストケースをどのように扱うのかを調べるために実施する。探索型テストの良し悪しは、テストケースを作り不具合を見つけるテストエンジニアのスキルに依存する。テストエンジニアがテスト対象について知っており、また様々なテスト技法を使うほど、探索型テストは良いものとなる。

To further explain, comparison can be made to the antithesis scripted testing, which basically means that test cases are designed in advance, including steps to reproduce and expected results. These tests are later performed by a tester who compares the actual result with the expected.

もっと説明するのであれば、探索型テストと対照的な存在となる記述型テストと比較するとよい。記述型テストは、基本的には、再現するために必要な操作手順と期待結果をテストケースとし、事前に設計しておくテストを意味している。設計と同時に実施されるのではなく、設計した後に実施され、期待結果と実際の動作結果が比較される。

When performing exploratory testing, there are no exact expected results; it is the tester that decides what will be verified, critically investigating the correctness of the result.

探索型テストを実施する際には、きちんとした期待結果は必要ない。実施しているテストエンジニアが、実際の動作結果のどこを検証すべきなのかを判断し、特に重要だと思われるところは不具合が無いかどうか、しっかり調査する。

In reality, testing almost always is a combination of exploratory and scripted testing, but with a tendency towards either one, depending on context.

実際のところ、テストというものは、ほとんど必ず探索型テストと記述型テストの組み合わせとなる。しかしどちらに重きを置くかは状況によって異なる。

The documentation of exploratory testing ranges from documenting all tests performed to just documenting the bugs. During pair testing, two persons create test cases together; one performs them, and the other documents. Session-based testing is a method specifically designed to make exploratory testing auditable and measurable on a wider scale.

探索型テストのドキュメントは、実施したテストを全て記録するような場合から、見つけたバグだけを記録する場合まで様々である。ペアテスト(pair testing)を実施する場合、テストの設計は2人で行い、片方が実施しつつもう片方がドキュメントを作成する。セッションベースドテスト(Session-based testing)は、探索型テストできちんと測定し監査するためのテストプロセスである。

Benefits and drawbacks: メリットとデメリット

The main advantage of exploratory testing is that less preparation is needed, important bugs are found fast, and is more intellectually stimulating than scripted testing.

探索型テストの主なメリットは、記述型テストに比べ、準備が少なく済み、重要なバグが早く見つかり、かつ知的な刺激が得られることである。

Disadvantages are that the tests can't be reviewed in advance (and by that prevent errors in code and test cases), and that it can be difficult to show exactly which tests have been run.

デメリットは、事前にテストケースのレビューができないこと(およびソースコードやテストケースの誤りが予防できないこと)と、どんなテストケースが実施されたのかを正確に表すのが難しくなりうることである。

When repeating exploratory tests, they will not be performed in the exact same manner, which can be an advantage if it is important to find new errors; or a disadvantage if it is more important to know that exact things are functional.

逆に正確に同じ方法で探索型テストを繰り返せないということは、新しいバグを見つけることが重要な場面ではメリットになりうるし、機能的に正確な記述がより重要な時はデメリットになる。

Usage: 使い方

Exploratory testing is extra suitable if requirements and specifications are incomplete, or if there is lack of time. The method can also be used to verify that previous testing has found the most important defects. It is common to perform a combination of exploratory and scripted testing where the choice is based on risk.

探索型テストは、要求や仕様が不完全だったり、時間が無い時には極めて有用である。また、それまでのテストで検出しておくべき重大なバグを見つけられているかどうかをチェックしたい場合にも用いられる。探索型テストと記述型テストの組み合わせは、品質リスクを基にして判断するのが普通である。

An example of exploratory testing in practice is Microsofts verification of Windows compatibility.

探索型テストは、MicrosoftがWindowsの互換性テストに使ったという実例がある。

The Seven Basic Principles of the Context-Driven School

The Seven Basic Principles of the Context-Driven Schoolのサイト。テストに限った話ではないが、背景や流れをきちんと考えないと色んな取り組みや技法は意味無いよ、という宣言。Cem Kaner周りの活動ですね。これが発展してASTになるという感じかしら。ついでに、意訳してみました。ご参考まで。
  1. The value of any practice depends on its context.
    背景や流れによって、取り組みや技法の価値は変化する。
  2. There are good practices in context, but there are no best practices.
    背景や流れが同じであれば、取り組みや技法の間に良し悪しはある。しかしどんな背景や流れでも最適な取り組みや技法(ベストプラクティス)はありえない。
  3. People, working together, are the most important part of any project's context.
    どんなプロジェクトでも、プロジェクトを一緒に進めている技術者の人間的側面こそが、最も重要である。
  4. Projects unfold over time in ways that are often not predictable.
    プロジェクトはというのは、予測できない様々な理由で延びてしまうものだ。
  5. The product is a solution. If the problem isn't solved, the product doesn't work.
    プロダクトというのはソリューション、すなわち問題解決の表現である。問題を解決せずにプロダクトを作ってしまっても、動くわけがない。
  6. Good software testing is a challenging intellectual process.
    よいソフトウェアテストは、知的で挑戦的なプロセスである。
  7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
    判断力や技術力が備わっていなければ、プロジェクト全体が調和するように気を配りつつ、効果的にテストできる時期や方法を適切に選ぶことはできない。

2007-07-14

TDDのアンチパターン

TDDのアンチパターン。大田さんのmixiから。元はオレンジニュースとのこと。

普通のテスト実施に当てはまるアンチパターンも多い。

次世代ロボット安全性確保ガイドライン

経済産業省から「次世代ロボット安全性確保ガイドライン」がリリースされた。
「次世代ロボット安全性確保ガイドライン」のとりまとめについて
「次世代ロボット安全性確保ガイドライン」の取りまとめについて(ニュースリリース)(PDF)
次世代ロボット安全性確保ガイドライン(PDF)

委員構成を見れば分かるが、ソフトの専門家がいないような気がする。SECの機能安全部会が絡んでいないのか、単に名前が出ていないだけなのかは分からないが、本文に機能安全のキの字も出てきていないので絡んでいないのだろう。まぁ向殿先生は機能安全部会の委員のはずだが、偉すぎるのだろうし。もしくは、このガイドラインの担当部署が情報系でないという縦割りの事情なのかもしれない。

さて内容を見てみると、やはりソフトの信頼性確保や安全性解析については触れられていない。危険源を見ると、わずかに「制御システムの故障/混乱」「ソフトウェアのエラー」が取り上げられている。もともと参照している規格がISO12100/JIS B 9700(機械安全)なのが理由だろう。

さてロボットの安全性確保のガイドラインを定める際に、ソフトの信頼性確保が難しい点、ソフト主導での安全性確保の経験のある開発組織が非常に少ない点などを検討しなくてもよいのだろうか。ソフトは単なる一つの部材という認識なのだろうか。それとも、追って検討という位置づけなのだろうか。

現状の組込みソフト開発組織の場合、ソフトの開発やソフトの信頼性について、単なる一つの部材という認識しか持っていなかったり、別途検討という位置づけであると、多くは品質事故で苦しんでいたりする。願わくば、組込みソフトのバグによってロボットが人を傷つけるなんてニュースは聞きたくないものだ。

某会合にて

須田さん、面白すぎ。

某会合で、腕のよいテストエンジニアには、特有の「鼻」が備わっているという話になった。要はExploratory testingのことだが、バグを出す勘の鋭い人は存在する。

そしたら、ある会社にいた「鼻」の利くテストエンジニアさんは「端(はな)さん」という人だったそうな。何とビックリ。

2007-07-13

Google

こっそりblogを再開したので誰も気づいてだろうし、Googleではまだ引っかからないようなので安心していた。すると秋山さんから、見つけたとの連絡が。う~ん、どうやって見つけたんだろう?

2007-07-12

テストと心もしくは脳

僕にとって、なぜテストは魅力的なのか。もともとプログラムを書くのが3度のメシより隙だったし、プラモデルのようなモノづくりも大好きだった。今でも、ちょっとしたツールをperlで書くときは、妙にワクワクする。そんな僕が、なぜテストを生業にしているのだろう。

もちろん競走戦略的には、僕の持っているリソースと世の中の状況を考えると、テストを生業にするのが一番理にかなった戦略である。しかし、それ以外にテストは僕の心を引きつけてやまないものがあるのだ。

テストを上手に設計するには、2つの意味で人間の心もしくは脳を深く理解しなければならない。それは、人間が何かを良いと感じるのはどういうことなのか、という点と、人間が間違いを犯すのはどういうことなのか、という点である。

テストは最終的に、ステークホルダーが全て満足するかどうかを評価しなくてはならない。もちろんその一部はビジネス上の明確な数値で表せるだろうが、テストで一番大事な部分は、ユーザがテスト対象を「よい」と感じることである。であるならば、テスト設計で考えなくてはならないのは、ユーザはどんな人なのか、ユーザはどんな使い方をするのか、そしてユーザはどんな時にどんなことを「よい」と思うのか、である。そういったことを当のユーザ以上に理解していないと、質の高いテスト設計はできない。

その中で最も難しいのは、ユーザはどんなことを「よい」と思うのか、を理解することであろう。そもそも人間は、何を「よい」と思うのだろうか。物理的な特性で記述できることも多いだろうが、大事なのはそこではない。コカコーラは嫌いでペプシは好き、レクサスは嫌いでベンツは好き、それは多分、物理特性の違いではない。そのユーザが生きてきた文脈において、様々な明示的関連を持たない特性が主観的に認知されることによって、よいとかよくないとか判断されるわけだ。テストを極めるのであれば、そこまで到達すべきだと思う。それは心理学、社会学、認知科学、脳科学など、もっと人間をダイレクトに研究対象とする分野とのコラボレーションが必要である。

同様に難しいのは、ユーザはなぜ「間違う」のか、を理解することである。そもそも人間は、何を正しいと認識するのだろう。もちろんヒューマンエラーの研究などはあるが、もっと踏み込んだ何かが必要だと直感している。人間が(多くは物理的な)何かを操作する時に間違うという狭いものではなく、人間が何かを考えるときに間違うとはどういうことなのか、を研究する必要があるのだ。

だから我々の研究室では、最初の一歩として、頭の中の論理的構造物に対するアフォーダンス、名付けてロジカル・アフォーダンス(以前はプロダクト・アフォーダンスと呼んでいたが、この方がよいと思う)を研究している。ソフトウェア開発者は、それが機械語であろうがCであろうがUMLであろうが、プログラムもしくはソフトウェアを頭の中に3次元/多次元の構造物として認識しているはずである。その論理的構造物に対するアフォーダンス把握や応力計算ができれば、ある種の間違いは指摘可能になる。

梅田望夫さんとの対談をきっかけに、最近茂木健一郎さんの本を読み始めたが、彼の言うクオリアのようなものだろうか。1行1行は単なる命令に過ぎないソフトウェアが、様々な脈絡(茂木さんは偶有性と呼んでいる)を持つことによって、頭の中でありありと多次元の構造物となって立体的に存在するのである。開発者はその構造物に触ったり、グルグル回したり、いろんなところから眺めてみたり、中に入ってみたり、柱を叩いてみたりしながら、ソフトウェアを分析・設計・実装し、レビューしていくのだ。

もっと言うと、テスト設計も同じである。僕にとって、テストケースの集合体であるテストスイートは、頭の中で多次元の構造物になっている。それを2次元の平面に記述するツールがNGTであるし、その構造物には何らかの品質特性もあるだろう。我々の研究室では、そんなことも研究している。我々にとってテストとは、頭の中の構造物を評価するための観点の集合だが、その観点そのものも頭の中で構造物になっているのだ。

つまりテストとは、人間を理解することそのものに他ならない。人間であるユーザが何を「よい」と感じ、人間である開発者が何を「間違う」のか。その2つを理解するからこそ、本当に素晴らしいテストが可能になる。頭の中をこじ開けて、人間がものを捉える時にどのような構造物を頭の中に構築しているのか、を把握しないといけない。そのためには、テスト設計の時にもっと人間について深く考察することが必要だし、もっと心や脳の分野と一緒に研究していかねばらならないだろう。

人間だもの。だからこんなに面白いことは無いのだ。

2007-07-11

グラフ網羅のツール

ふとグラフ網羅のツールが欲しくなった。最近MindManagerでマインドマップを書いているからだろうが、あんなフィーリングでグラフを描いたら経路(パス)を探索してくれると便利だろうな、みたいな。C0(ノード網羅)とかC1(リンク網羅)とかC∞とか指定できたら、とってもクールだ。海外のツールにはあるのかなぁ。

というわけで、同僚の組み合わせ論の先生に聞いてみた。一般のものは無いらしい。う~ん、残念。もし知ってたら、教えて下さい。

Googleのテストエンジニアにならないか

Googleがテストエンジニアを募集してるのは知っているだろうか?アメリカのテストのカンファレンスにはGoogleがスポンサーしているし、CASTに来ていたHarry RobinsonやLydia Ashは、2人ともMicrosoftからの転職組のようだが、スゴ腕である。

彼ら(彼女ら)が、Google mapsやGoogle talkをテストしているわけだ。何となくGoogleのコードにはバグなんて無いだろう、テストなんて不要だろう、という思いこみがあったが、凄まじい量のテストをしているはずである。結構可愛いバグがあるのを紹介してもらった。経路探索のバグとかね。

例えばGoogle talkのテストというのは、開放型で漸化型の状態遷移テストに帰着できる。では、その状態モデルを書けるテストエンジニアが何人いるだろうか。いや、Google talkのテスト設計をこなせる(テスト以外の)エンジニアが日本には何人いるだろうか。

2人のチャットのテストなら書けるかもしれない。片方が待機中、呼び出し中、通話中、切断中の4状態くらいかな。もう片方も、状態としては同じ。イベントとしては、呼び出し、切断、ブラウザ終了だとしよう。さて、テストケースは何件になるでしょう。

マルチユーザチャットなので、これがどんどん増えていくわけだ。2人の場合はできましたか?これは頑張ればできるでしょう。3人の場合は?これも何とかできるでしょう。では4人は?5人は?100人は?

このテスト設計は、手動で行うと死ぬ。だからテスト設計をモデル化して自動生成しないとやってられない。だからHarry Robinsonの出番になるわけだが。CATSのツールでできるのかなぁ。今度穴田さんに聞いてみよう。

さて日本では、モバイル系のQAエンジニアというタイトルで、テストエンジニアを募集している。腕に覚えのある方はいかが。知り合いがGoogleでエンジニアやってるなんて、格好いいなぁ。

SoftwareTestingWiki

SoftwareTestingWikiというのがあるようだ。メモメモ。

CAST: Exploratory testing

出張に来たのはCAST(Conference of the Association for Software Testing)の出席が目的だ。今年も色々海外に行くが、一番楽しみにしているカンファレンスである。AST(Association for Software Testing)のカンファレンスだが、いわゆる学術系の学会ではないので、非常にプラクティカルである。

ASTは日本でも有名なCem Kanerが創立したもので、アメリカの有名なコンサルタントが多数参加している。ただしSQEとはつかず離れずといった感じのようで、Rex BlackやRick Craigはいない。まぁRexがいないのは資格制度に関するCemとの抗争のせいで、今頃イスラエルにいるからなのだが。CASTをISSTAやISTQBミーティングとぶつける(ISTQBが後に決まったのだが)あたり、欧米は欧米で色々大変なのね、という感じである。一応Lee Copelandが基調講演なのだが、そそくさと帰ってしまった模様だ。

CASTはJames BachやHarry Robinson、Danny Faught、Doug Hoffman、Robert Sabourin、Michael Boltonなど、スゴイ顔ぶれが揃っている。カンファレンスチェアのJon Bachは、James Bachの弟のようでビックリ。でも性格はあまり似ておらず、兄はラジカル、弟はジェントルで面白い。まぁチェアだから神経を使っていたのかな。見た目はブルーザー・ブロディみたいだけど。

どうもこの辺の人達の好みは、Exploratory testingとAutomationのようだ。テストエンジニアとしてプライドがあるので、Prescriptedな人手のテストをバカにする傾向がある。まぁ言われてみればそうだが。でも我が日本には、そんな偽装派遣のテストオペレータが多いのも事実であり、とても悲しむべき状況である。

Exploratory testingとは、テストエンジニアの高度な「鼻」を駆使して、テストを実施しながらバグの出そうな方向へどんどんシフトするというものだ。Ad hoc testingと混同しないように。ランダムではなく、あくまで高度な「鼻」を駆使する点が特徴的だ。あくまで雰囲気のことだが、アジャイルっぽい。

というわけで、日本のテストエンジニアを元気づけるべく、次回のJaSST東京ではExploratory testingの紹介でもしてみようかしら。Exploratory testingをマネジメントするために、Session-based testingというのもあるようだし。といっても、単に2時間くらいで区切るだけです。はい。

細かい定義ややり方については調べていくので、随時blogにアップします。するつもり。あくまで、つもり。

個人的には、Systematic testingとExploratory testingをどう融合してマネジメントするか、がポイントだと思う。Harry Robinsonに質問した時には、「Model-based testingのモデルをExploratoryに改善するんだよ」と言っていたが、単にExploratory testingをするだけでは品質保証はできない。Systematic testingでは、最高速かつ最高精度でバグ出しはできない。そのバランスが必要で、それが難しいのだ。

去年のJaSST東京ではModel-based testingの紹介をしたので、同じようにやればよいかな。でも、もう一人の事例発表はどうしよう。日本一のテストエンジニアって誰だろう...。多分、アジャイル風な雰囲気(決してアジャイル方面という意味ではない)がいいんじゃないかな。

そういう人、いませんか。心当たりがあったら、紹介してくださいまし。

2007-07-10

ジェットラグ

時差ボケに完全にやられた。こうならないように、いつも飛行機に乗った瞬間に現地時間に合わせ、朝便の場合は前日はほぼ徹夜にし、現地では早く寝るようにしているのだが。やはりフライト時間が短かったのが敗因か。機内食なんぞ食べずに寝てればよかった。

というわけで、凄まじく眠いので、Tester's Challengeという演しものはキャンセルして離脱。ちょっと残念。

ベルビューはとても良い天気だ。寒くもなく暑くもなく、散歩日和。会場からホテルまで歩いて10分くらいなので、ちょうどよい。緑が多いって、いいなぁ。

帰りに水を買おうとショッピングセンターに寄ったら、美味しそうなアイス屋があったので寄り道。Moraという、いわゆるアメリカ風ではない高級感あふれる店構えだ。どうも地元の店らしい。4ozで$3.5だから、そんなに安くはないが、アメリカらしい不自然な甘さが無く、結構イケる。ベルビューにお越しの際はお試しあれ。

2007-07-09

シャワーヘッド


CASTに参加するため、シアトルの隣町のベルビューに来ている。トランジットのSFOでボ~っとしていたら乗り遅れたのはともかく、スムーズに到着。

会場に一番近いホテルを取ったのだが、なぜかシャワーヘッドが2つ付いている。こんな感じ。もちろん、うちの部屋にはシャワーブースなど無く、バスタブのところに付いているのだが。

使ってみたが、何かビミョー。目的もメリットも分からない。我々日本人には、シャワーが壁に据え付けでない方がありがたいのだがなぁ。

よいサービスって、何だろうね。

2007-07-07

不注意

さすがに疲労が溜まったのか、不注意ばかり。おかげで、停めたクルマのギアをニュートラルにしたまま、サイドブレーキだけかけて家族を迎えに行ってしまった。

戻ってみると、クルマが動いており、前のクルマにオカマを掘っていた。

う~、前のクルマの方には本当にご迷惑をおかけした。すみません。 m(_)m

皆さんも、疲労時の注意力減退には気をつけましょう。
それにしても、大事故にならなくて不幸中の幸いです。

カレンダーとアクセス解析

カレンダーとアクセス解析つけてみました。
どうかしら。

2007-07-06

タイムマネジメント

今日は京都でSESSAMEセミナ。やはり現場の技術者さんに思いを伝えるのは楽しい。真剣に聞いてくれる(と思う)し、きちんとうなずいたりしてくれるからだ。

でも最近は、前段の「品質が重要だ」的な説教が多くなってしまい、持ち時間をオーバーすることが多い。一つは自分自身の品質危機意識の高まりだが、もう一つは潜在的な恐怖感かもしれない。

まだ修士の頃、まだ読み原稿を作っていたのだが、間に合わずに学会発表したことがある。まだスライドがあっても、読み原稿が無いと頭が真っ白になる程度の実力だったので、それはそれはヒドい出来だった。会場での質疑応答の時間に「よく分からない」と、指導教官から追い打ちをかけられたのもキツかった。

その時のトラウマで、どうも壇上で空白が空くというのが怖い。別にスライドが無くても1時間以上しゃべれるのだが、どうも怖い。結果として前段でスライドを無視して超過分しゃべっているのだから同じなのだが、どうも怖い。

この恐怖感を克服しない限り、時間の超過は治らないかもしれないなぁ。タイムマネジメントの問題ではないのかしら。いや、年取って説教臭くなっただけか...。

少女ファイト

いろいろ好きなマンガはあるが、最近のイチオシは「少女ファイト」だ。イブニングに連載しているので、隔週が待ち遠しい。

で、今週のセリフ。
「どうにもならない他人の気持ちはあきらめて 、どうにかなる自分の気持ちだけ変えませんか」

辛くなった時は、このセリフを思い出すようにしよう。あぁ、泣ける。

2007-07-05

コンピュータリテラシー

学部1年生向けに、コンピュータリテラシーという講義を受け持っている。PCなどに触れたことの無い学生向けにコンピュータの使い方を教える授業だ。

うちの大学では、どうもUNIXを教えるのがデフォルトになっているらしい。研究室のサーバ管理をやっている関係でUNIXも分からないではないが、そもそも何故UNIXなのだろうか、という点は疑問だ。もちろんパイプ&フィルタを駆使すれば色々便利だという話や、UNIXの方がコンピュータの仕組みを意識する必要があるので学習効果が高いという話はあるが、イマイチ説得力に欠ける。Windowsでもいいのではないか。以前担当の情報系の先生と議論したのだが、結局のところMicrosoftがキライという程度の見識でしか無く、がっかりしたことがある。それは単なる宗教だ。僕は別にMicrosoftが好きなわけではないが、UNIX信者には呆れることがある。

特定の講義を批判するつもりは無いが、ある講義ではWebページを作らせているようだ。でも、今どきWebページを自分でデザインするなんてやらないんじゃないか、と思う。だってblogやSNSで十分自己表現できるではないか。何というか、手段が目的化し、それを習得させられることの無意味さといったら無い。これが大学というところなのかもしれないが。

コンピュータリテラシーというのは、何なのか。それは鉛筆の握り方を教える講義では無いはずだ。鉛筆を握ることによって、文字でコミュニケーションをし、思考を発展させることを教えなくてはいけないはずだ。それがコンピュータであれば、UNIXのコマンドを教える講義ではなく、コンピュータを使ってネットにアクセスすることによって可能になるコミュニケーションであり、思考の発展や創発ではないかと思う。コンピュータを使って、もっとクリエイティブに思考し「分かる」ことの楽しさ(アハ体験)をしてもらうことが目的だろう。そうでなければ、その辺のコンピュータ教室と変わらない。

もっと言えば、Web2.0的な講義であるべきかもしれない。学生が問題を提起し、学生が自然にグループを組み、学生が解決策を抽出し、学生がプレゼンテーションし、学生が評価する。学生の、学生による、学生のための講義だ。では、教官はそれに何ができるのだろう。

それは「正しく考えること」の補助に他ならない。本質的な問題を提起させられるように、適切なグループを組み上手にマネジメントできるように、問題を深く洞察し無理のない解決策を抽出できるように、上手にプレゼンテーションできるように、そして適切に評価できるようにしてあげることではないか。逆に言えば、決して答えが用意されている課題を出して、記入すればよいようになっている帳票を用意してあげることではない。これには、本当の意味での「正しく考える力」が教官に必要である。

そういう体験は、ゼミならできるけど、講義では難しい。でも、そういう風な講義ができるといいな。後期の大学院の講義でやってみるか。

さて、学生は期末試験にどういう解答を書いてくるのだろう。僕の講義をどう感じてくれたのだろう。毎週出したレポートの意味をどう咀嚼してくれたのだろう。授業評価のアンケートに興味はないが、学生が賢くなってくれたかどうかは、とても気になる。願わくば、僕の講義を聞いて一人でも多くの学生が賢くなって欲しいなぁ。

批判される権利

最近、縛られているような気が時々する。テストについて専門家がほとんどいない状況で色々とアドバルーンを上げたせいで、なんだか実力以上に権威だと思っている人がいるようだ。こんなことを書くのは口はばったいのでイヤなのだが、ここのところ何人かから言われたので、事実なんだろうなぁと思う。

そりゃ僕も好きなアーティストや作家がいたりするので、自分のやってきたことに対して、何というかその憧れのような感情を持ってもらうことは、別にイヤではない。僕だって、画伯(注:西村しのぶ)のサイン会があった時に、整理券がもらえなかったのに覗きに行ったもの。そういう感情があることは理解するし、自分にもたくさんある。

でも、そのことと、僕の発言を絶対視することは違うと思う。違っていてほしい。最近swtest-mlに投稿しても、あまりレスがつかなくなった。メールが長いからか。文体が脂っこいからか。いや、多分、違うと思う。これは、「批判される権利」を奪われたのだ。

批判される権利というのは、誰しもが生まれながらにして持つ知的な基本的人権である。我々人間が学び、考え、成長していく過程において、批判されることはとても有益、いや必須である。批判されなければ、自分の考えは成長していかず、結果として茂木健一郎言うところのアハ体験も得られない。批判される権利が奪われるというのは、激烈な知的快感を奪われることと同義なのだ。

学生だった頃、研究室で研究がうまく進まず悩んでいると、僕の恩師が通りかかり、「にしくん、批判される側になれよ。世の中の8割以上の人は、批判されるものを創ることすらできないんだ。君は、それを創る側の人間なんだよ。」と言ったのを今でも思い出す。今思うと先生はその頃、多分、自分の所属する学会にパラダイムシフトを起こすべく、守旧派から猛烈な批判を受けていたはずだ。それまで、批判される人はダサく、バカだと思っていた。でも今は、批判されうるものを創りだし、甘んじて批判を受ける人間でありたい。一生、そうでありたい。

だから、批判される権利を奪われるというのは、非常に悲しいのだ。もしかしたら批判されうるものを創りだしていないのかもしれない。だとすれば、もっと悲しい。いつもビジョナリーにクリエイティブでなくてはならない。頑張って、もっと批判されるものを創っていこう。

ScrapBookと電話会議

今日は終日自宅作業。未対応の仕事が溜まっていて移動時間が惜しいのと、出張明けで風邪気味なのと、今朝寝たのが7:30だったから。

こないだからずっと大西さんに「本書け、本書け」と言われているし、ミッキーさん・いけどんコンビや秋山さんが本を書いているのを見て、執筆欲が湧いてきた。コメントスパムやトラックバックスパムがウザくてswtest.jpのコラムを中断しているのもあるし。

というわけで、いっちょ頭の中を整理してみようと、こないだダウンロードしたMindManagerを使ってマインドマップで構造化してみた。いや、これは面白い。朝方で一人だったのもあって、ガソリンが切れるまでほぼずっとゾーンに入って思考を続けられた。もう少し続けると、本の章立てくらいにはなりそうかな。マインドマップ、おすすめ。

というわけで、このblogにネタの文章を少しずつ上げていこうと思う。というか、そのために始めたようなもので。ある程度まとまったらswtest.jpに出します。平鍋さんのblogに対するmixiのようなものかな。まさに備忘録。

午後は少しチビの相手をしたりカミさんと話したりしながら仕事。青木さんに秘書で来てもらっているので事務作業は激減したが、それでも最低限しなきゃいけないことはある。面倒だが、仕方ない。あと、溜まっているメールニュースから興味深そうな記事をクリップ。

ここで、クリップしたWebページをローカルにキャッシュするためのソフトを探して試す作業にシフトしてしまった。う~ん、ある意味現実逃避だが。で、本当はWeBoxを使いたかったのだが、元のページがローカルだと上手く処理してくれずエラーになるので、断念。紙なども試したが、イマイチ合わず。というわけで、firefoxのアドオンであるScrapBookに落ち着きつつある。果たして、手に馴染むかしら。

チビに号泣されながら風呂に入った後、明日の研究室内の中間発表のために学部4年と電話会議。年度末に松下のスピーカーホンを買ったが、まさか学生が使うことになるとは。まぁでも、快適。こちらも携帯にヘッドホンなので両手空くしね。さてさて、明日はまともな発表会になるのやら。例年そうだが、今年も根性と伸びしろのある学生が入ってきている。卒業の時が楽しみだ。

2007-07-04

アクセス解析

ふ~ん、こんなアクセス解析があるのね。
http://www.google.com/analytics/ja-JP/

ついでに、Bloggerの入門ページもリンク。
http://blogger.kuribo.info/

2007-07-03

再開

コメントスパムがウザかったので研究室のサイトに書き込むのをあきらめてみたが、ちょっと試してみることにした。さて、どうかな。