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)

原稿

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