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

再開

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