不在メールの日本語版にも対応しないと片手落ち、というご指摘を、組込みソフト界の最強の皮肉屋かつマンガ王の宿口さんから頂きましたので、ついでに掲載しておきます。
あまり美しくないので、どなたかきれいに書き直してくださいまし。
$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');
2007-11-02
続：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.';
};
#;
きちんと動く（と思われる）フィルタを再掲しておきます。
＃ついでに、不在メールも叩き落とすフィルタになってます。
$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.';
}
#;
さて拙い設定だが、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年かかるだろうが、辛抱強く直していきたい。
研究室のゼミだと問題点を指摘する役回りなので、どうしても改善すべき点を探してしまう。しかしこういう場では、最近、その研究の持つ発展性を考えて質問やコメントをするようにしている。人の研究を理解して発展可能性を想像するというのは難しいが、研究者として重要な役割だと思う。まぁ人のアラを探すのは簡単だからね。
もともと僕は目利きではない。なんとか直したいと思っているのだが、その原因の一つは、ついアラを探してしまって悦に入り、発展可能性に思い至らないからことがあるのかもしれない。このクセが直るには5年10年かかるだろうが、辛抱強く直していきたい。
2007-09-26
Starckの時計
休暇の時に結局買わなかったので、時計を衝動買いしてしまった。もともと持ち物に関してはあまり取っ替え引っ替えしない方で、今使っている時計はもう10年近くになる。これからも使い続けるつもりなのだが、それはそれとして、プライベートで使うようなユルい時計が欲しくなったのだ。そもそも普段から時間に追われるような生活をしているので、休日はあまり時間に追われたくない。そんなわけで、正確な時間が読み取れないくらいでちょうどよいのだ。そんなミニマルなデザインの時計が欲しかったわけで。そんなことを思っている時にみなとみらいのクィーンズスクウェアで別の買い物をしていると、TicTacに可愛い時計があった。もちろん、すぐに衝動買いしてしまった。ルフトハンザみたいな色づかいもキュートだ。
FOSSILのStarckモデルのようだ。Philippe Starckは、悪名高き浅草のアサヒビールのオブジェのデザイナーというと分かりやすいかな。ちなみにあのオブジェは炎がモチーフだそうで。しかしそれ以外は、シンプルでミニマルなデザインが多い。
しかしこの時計、いま何時なのか全然分からない。まぁ分からなくてもいいと思って買っているのだから良いのだが。何がおかしいって、長い針らしき棒が実は時間を示す針で、短い針のように見えるS+ARCKの文字列が実は分を刻む時計なのだ。逆の方がアフォーダンスに合っていると思うのだが、それはそれでデザインが普通っぽくなってしまってイマイチなのかもしれない。というわけで、気に入っている。
これで少しは休日に時間を忘れられるかしら。何もせず何も考えない時間が無いと、ビジョンもアイデアもモチベーションも枯渇しちゃうからね。
2007-09-20
カフェテリアの安全性解析
国際学会でドイツはニュルンベルグに来ている。SafeCompという組込みシステム（？）の安全性の学会だ。欧州中心の、とても由緒ある学会である。日本人は僕の他に、長岡技科大の平尾先生がいらしている。逆に言えば、日本からはそれだけだ（あとは東北大の留学生さんが一人）。まぁ韓国もインドもアメリカも少なく中国はゼロので構わないのかもしれないが、もっと日本でも組込みシステムの安全性の研究者が増えるべきだと思う。
さてそんなわけで、平尾先生とお昼をご一緒させていただいた。安全性の分野で最も大事なのは、言わずもがな安全性解析だ。平尾先生は「ハザード解析ですよ」と言いながら、道を渡る時でも左右に注意している。さすが安全性の専門家。
一方僕はと言えば、ランチルームであるカフェテリアで、かなり派手にソースをジャケットやシャツにこぼしてしまった。ちょっとした染みなんてレベルではなく、10メートル先からでもこぼしたことがはっきり分かるくらい。手提げカバンを持っているのでトレイを片手で持っており、かなり長い間こぼれていることに気づかなかったのだ。不覚。
しかし不覚なのは、こぼしたことそのものではない。片手でトレイを持つ際のハザード解析やFMEA、HAZOPができていなかったことを始め、安全性の学会に来ているのに安全性解析の基本がなっておらず事故が起きてしまったことだ。しかも、昨日あぶないなと思っていたのに、そのヒヤリハットも活かせてない。こぼしたことを検知する機構も備えていなければ、こぼれても大丈夫なようにトレイを離して持つという機能安全も達成できていない。これでは安全性の研究を始めましたなんて、口が裂けても言えないわな。
う～ん、精進が足りませんね．．．。頑張ります。
さてそんなわけで、平尾先生とお昼をご一緒させていただいた。安全性の分野で最も大事なのは、言わずもがな安全性解析だ。平尾先生は「ハザード解析ですよ」と言いながら、道を渡る時でも左右に注意している。さすが安全性の専門家。
一方僕はと言えば、ランチルームであるカフェテリアで、かなり派手にソースをジャケットやシャツにこぼしてしまった。ちょっとした染みなんてレベルではなく、10メートル先からでもこぼしたことがはっきり分かるくらい。手提げカバンを持っているのでトレイを片手で持っており、かなり長い間こぼれていることに気づかなかったのだ。不覚。
しかし不覚なのは、こぼしたことそのものではない。片手でトレイを持つ際のハザード解析やFMEA、HAZOPができていなかったことを始め、安全性の学会に来ているのに安全性解析の基本がなっておらず事故が起きてしまったことだ。しかも、昨日あぶないなと思っていたのに、そのヒヤリハットも活かせてない。こぼしたことを検知する機構も備えていなければ、こぼれても大丈夫なようにトレイを離して持つという機能安全も達成できていない。これでは安全性の研究を始めましたなんて、口が裂けても言えないわな。
う～ん、精進が足りませんね．．．。頑張ります。
2007-09-10
グァムは日本人ばかり
2007-09-07
評価開発
特に研究者に多いが、ソフトウェアテストと聞くとプログラムのホワイトボックステストを思い浮かべる人が多い。もちろん1970年代前半はそうだったのかもしれないが、現在は違う。
テストと似たような活動に、レビューやインスペクションがある。バグを見つけるという意味では、形式検証もあるだろう。この際、メトリクスを測定する活動も含めてしまおう。これらは、プロジェクトの様々なフェーズにおいて、様々な手段で、様々なソフトウェアの特性を調べる活動と考えることができる。これをここでは、評価と呼ぶことにしよう。
そう、テストとは、ソフトウェア評価のうち、ソースコードの出現後に実施される動的検証という、一つの手段を意味する。でもまぁ、この分類にはあまり意味はない。
意味があるのは、こうした評価の活動には全て分析・設計が必要だという点である。言い替えると、評価開発になるかな。プログラムを開発することと同じくらい、評価項目や評価手段の設計というのは難しいのだ。だから、頭を使って方法論を構築し“開発”すべきである。
仲でも、評価戦略の策定は重要だ。開発しようとしているソフトウェアにおいて評価すべき特性にはどのようなものがあり、どのような手段、どのような単位で測定できるのか。各評価手段は、どのように棲み分けて、補完しあうのか。それらが製品価値にどのようにつながっていくのか。こうした評価戦略を決めないといけないのだ。しかも上流でね。
ソフトウェア開発の現場では、評価活動全体を俯瞰的に捉えている場合はあまりないだろう。しかし開発項数の5割以上を評価に割いており、評価工数が足りない足りないと騒ぐのであれば、評価を俯瞰的に捉えて“開発”すべきである。そうしないから、評価工数が爆発したり、評価漏れで不具合が市場に流出するのだ。
テストの方法論は、最終的に評価開発の方法論に昇華すべきだし、しなくてはならないだろう。その第一歩として、テスト戦略を立ててテストレベルやテストカテゴリに分割してみるとよい。慣れてきたらレビューの観点を加え、形式検証、メトリクスと増やしていけばよい。
我々メソドロジストも、評価全体を視野に入れて方法論を構築しないとね。これはなかなかチャレンジングだが、楽しい作業だと思う。
テストと似たような活動に、レビューやインスペクションがある。バグを見つけるという意味では、形式検証もあるだろう。この際、メトリクスを測定する活動も含めてしまおう。これらは、プロジェクトの様々なフェーズにおいて、様々な手段で、様々なソフトウェアの特性を調べる活動と考えることができる。これをここでは、評価と呼ぶことにしよう。
そう、テストとは、ソフトウェア評価のうち、ソースコードの出現後に実施される動的検証という、一つの手段を意味する。でもまぁ、この分類にはあまり意味はない。
意味があるのは、こうした評価の活動には全て分析・設計が必要だという点である。言い替えると、評価開発になるかな。プログラムを開発することと同じくらい、評価項目や評価手段の設計というのは難しいのだ。だから、頭を使って方法論を構築し“開発”すべきである。
仲でも、評価戦略の策定は重要だ。開発しようとしているソフトウェアにおいて評価すべき特性にはどのようなものがあり、どのような手段、どのような単位で測定できるのか。各評価手段は、どのように棲み分けて、補完しあうのか。それらが製品価値にどのようにつながっていくのか。こうした評価戦略を決めないといけないのだ。しかも上流でね。
ソフトウェア開発の現場では、評価活動全体を俯瞰的に捉えている場合はあまりないだろう。しかし開発項数の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というハチミツ屋さんと、ル・パティシェ・タカギという深沢不動のところのケーキ屋さんとのコラボだ。高木さんは郁恵・井森のデリ・デリ・キッチンにも出演していたので、かなり有名だと思う。キットカットは不味かったけどね。
ここで最近お気に入りなのは、シンプルなはちみつのジュレだ。メープルかな。少しレモンの酸味があって、サッパリしているので駅弁・空弁のデザートには最適だ。保冷剤も入れてくれるので安心。
このジュレ、とっても優しい味がする。一般にジュレというのは、腕が悪く固めすぎてしまったり、技巧に走って果実味が強すぎたりと、意外にバランスが難しいスイーツだ。若いうちはたっぷりの果実味でもよかったが、最近はシンプルかつ優しいものに惹かれるようになってきている。タカギのこのジュレは、変な混ぜものの味もしないし、甘味が強すぎることもないし、鼻につく果汁臭も無い。何の変哲も無いといえば無いのだろうが、スッと身体に入ってきて、サッと消えてしまい、フワッとした後味が残る。それだけ。それだけなのだが、つい買ってしまう。
もう少し時間があれば外のカフェでお茶でも、と思うのだが、イートインなのにフォークはプラスティックだわ、詰め込んでるので席は狭いわ、禁煙じゃないので近くに喫煙者が座るとケーキやお茶の香りが台無しだわで、気が引ける。むしろ持ち帰りにして新幹線や飛行機の中で食べた方が、妙な期待をせずに済むだけよいだろう。
甘いものが好きな人は、レジ横にあるはちみつのキューブを買ってもよろし。パッケージの猫が可愛いのもあって、疲れた時は和みます。こちらもオススメ。
今日は夕方まで大学で仕事の後、明日の集中講義のため博多へ移動。品川経由で羽田へと急ぐ。
暑くなる前は羽田に笹巻きえんがわずしという名作があったのだが、夏になってからはトンと見かけない。ムチャクチャ好物だったので残念だ。早く復活してほしい。秋になったら食べられるかしら。6月だか7月だかは佐賀牛の弁当があり、こちらも美味だった。しかし現在は、それほど心を躍らせる空弁は無い。
そもそも羽田には、ウキウキしてしまうようなスイーツのお店が少ない。もちろんピエール・マルコリーニはあるが、僕はあまりチョコが得意でない。期待していなかったが、もちクリームもハズレだった。キハチに至っては、ソフトクリームなので持ち運べない。パステルがあるが、毎回では飽きてしまう。
なので羽田で買う前に、品川の駅ナカであるEcuteに寄る。そこそこマトモなものが買えるので重宝している。というわけで、沼津魚がし鮨でにぎりのセットを買う。
Ecuteはスイーツのお店も結構あるが、何となくいつもQBGタカギに行ってしまう。ここはQBGというハチミツ屋さんと、ル・パティシェ・タカギという深沢不動のところのケーキ屋さんとのコラボだ。高木さんは郁恵・井森のデリ・デリ・キッチンにも出演していたので、かなり有名だと思う。キットカットは不味かったけどね。
ここで最近お気に入りなのは、シンプルなはちみつのジュレだ。メープルかな。少しレモンの酸味があって、サッパリしているので駅弁・空弁のデザートには最適だ。保冷剤も入れてくれるので安心。
このジュレ、とっても優しい味がする。一般にジュレというのは、腕が悪く固めすぎてしまったり、技巧に走って果実味が強すぎたりと、意外にバランスが難しいスイーツだ。若いうちはたっぷりの果実味でもよかったが、最近はシンプルかつ優しいものに惹かれるようになってきている。タカギのこのジュレは、変な混ぜものの味もしないし、甘味が強すぎることもないし、鼻につく果汁臭も無い。何の変哲も無いといえば無いのだろうが、スッと身体に入ってきて、サッと消えてしまい、フワッとした後味が残る。それだけ。それだけなのだが、つい買ってしまう。
もう少し時間があれば外のカフェでお茶でも、と思うのだが、イートインなのにフォークはプラスティックだわ、詰め込んでるので席は狭いわ、禁煙じゃないので近くに喫煙者が座るとケーキやお茶の香りが台無しだわで、気が引ける。むしろ持ち帰りにして新幹線や飛行機の中で食べた方が、妙な期待をせずに済むだけよいだろう。
甘いものが好きな人は、レジ横にあるはちみつのキューブを買ってもよろし。パッケージの猫が可愛いのもあって、疲れた時は和みます。こちらもオススメ。
2007-08-27
2007-08-25
麻布十番縁日
週末は麻布十番縁日に行ってきた。正式な名前は、麻布十番納涼祭りだそうだ。へぇ。
小さい頃はそんなに行ってたわけじゃないのだが、中学生くらいから必ず毎年行くようになった。だからもう20年以上になるのかな。そんなわけで、僕の夏の風物詩と言えば、神宮の花火と麻布十番の縁日である。この2つが無いと、どうも夏を過ごした感じがしない。
しかし南北線と大江戸線の駅ができてからというもの、人が増えすぎて困る。以前は友達や知り合いに出会ったりしたものだが、皆よそに引っ越したからか、友達が減ったからか、視力が減ったからか、いや人が増えすぎて、ちっとも誰にも会わない。芸能人にも会わない。いや会っているのかもしれないが、朝の山手線のラッシュみたいになっており、人が多すぎて認識できないのだ。六本木ヒルズも出来たしねぇ。
まぁでも、行く価値のある夜店なんて限られているから、混んでいても構わないっちゃ構わない。十番の縁日の夜店は、大きく分けて3つに分けられる。1つは、他の縁日やお祭りでも出ている普通の夜店。2つめは、十番のお店が片手間にドリンクなどを供給する夜店。3つめは、十番のお店が本気で（？）食べ物や飲み物を振る舞うお店。あ、今回から、地方の特産品みたいな夜店カテゴリもあったかな。で、行く価値のあるお店は、3つめ。空いていれば4つめも面白いかもしれないが、この混みようだからなぁ。
普段から十番に来ていればすぐに分かるが、別に初めてでも一目瞭然だ。せっかく来たのだから、たこ焼きだのお好み焼きだの焼きそばだのは食べず、十番のものを食べた方がよいと思う（まぁ別に、食べたかったら食べてもよい。僕もお好み焼きを食べることもあるし）。もしかしたら僕が知らないだけで、絶品のたこ焼きがあるのかもしれないけどね。
また重要なのは国際バザールだ。一の橋公園の中にたくさんの国の夜店が開かれる催しで、十番の縁日ならではのイベントなのだ。もともと港区、特に麻布は大使館が多いので実現したのかもしれない。各国の料理が食べられるのでオススメだ。今年は十番の通りよりも若干空いていたしね。うちはいつも、ここで晩ご飯にしてます。北側（ローソン側）に座れそうなスペースがあるけど、風下のため煙いので注意。ちなみに僕は数年前、ここで煙を浴びすぎてコンタクトを一つダメにしてしまった。
お腹がふくれた後は、今はいないけど田代まさしの焼きそば屋を見に行ったり、デストロイヤーの電気屋さん（だったかな？）を見に行ったり、お化け屋敷（今は盆踊りのようだが）の方に抜けて一息ついたり、童謡赤い靴のきみちゃんの像の近くのステージをウロウロしたりする感じかな。大混雑の十番通りは下り（？）だけにして、上りは迂回するのが落ち着けるコツかも。
今年は、今まで近寄らなかったりスルーしていたフレンチの夜店の子羊とヴィシソワーズが美味しくて感動だった。十番通りから少し外れた方が、落ち着いて上手い夜店が見つかるかもしれない。合唱するアイスコーヒー屋とかあるし。
あとは、縁日の終了時刻である21時前後に投げ売りを始めるので、交渉して安く旨いモノを買うという楽しみもある。僕も以前、焼肉をこれでもかと盛ってもらったことがある。十番は山の手だが人情味のある下町風情もあるので、いろいろ親切にしてもらえるかもしれない。
一つ悲しいのは、昔ながらのラムネがほとんど見かけなくなったこと。プラスチックのビンでは気分が出ないし、何より美味しくない。縁日以外なら浪花屋さんに行けば呑めるのだが、縁日で呑めないとチト寂しい。これも時代の流れかしら。まぁゴロゴロ売っていたのだが混みすぎて見えなかったのかもしれないけどね。
ともあれ、来年はもう少し空いてる時間に行こうっと。土曜の19時なんて、一番混んでる時間帯だもんね。
小さい頃はそんなに行ってたわけじゃないのだが、中学生くらいから必ず毎年行くようになった。だからもう20年以上になるのかな。そんなわけで、僕の夏の風物詩と言えば、神宮の花火と麻布十番の縁日である。この2つが無いと、どうも夏を過ごした感じがしない。
しかし南北線と大江戸線の駅ができてからというもの、人が増えすぎて困る。以前は友達や知り合いに出会ったりしたものだが、皆よそに引っ越したからか、友達が減ったからか、視力が減ったからか、いや人が増えすぎて、ちっとも誰にも会わない。芸能人にも会わない。いや会っているのかもしれないが、朝の山手線のラッシュみたいになっており、人が多すぎて認識できないのだ。六本木ヒルズも出来たしねぇ。
まぁでも、行く価値のある夜店なんて限られているから、混んでいても構わないっちゃ構わない。十番の縁日の夜店は、大きく分けて3つに分けられる。1つは、他の縁日やお祭りでも出ている普通の夜店。2つめは、十番のお店が片手間にドリンクなどを供給する夜店。3つめは、十番のお店が本気で（？）食べ物や飲み物を振る舞うお店。あ、今回から、地方の特産品みたいな夜店カテゴリもあったかな。で、行く価値のあるお店は、3つめ。空いていれば4つめも面白いかもしれないが、この混みようだからなぁ。
普段から十番に来ていればすぐに分かるが、別に初めてでも一目瞭然だ。せっかく来たのだから、たこ焼きだのお好み焼きだの焼きそばだのは食べず、十番のものを食べた方がよいと思う（まぁ別に、食べたかったら食べてもよい。僕もお好み焼きを食べることもあるし）。もしかしたら僕が知らないだけで、絶品のたこ焼きがあるのかもしれないけどね。
また重要なのは国際バザールだ。一の橋公園の中にたくさんの国の夜店が開かれる催しで、十番の縁日ならではのイベントなのだ。もともと港区、特に麻布は大使館が多いので実現したのかもしれない。各国の料理が食べられるのでオススメだ。今年は十番の通りよりも若干空いていたしね。うちはいつも、ここで晩ご飯にしてます。北側（ローソン側）に座れそうなスペースがあるけど、風下のため煙いので注意。ちなみに僕は数年前、ここで煙を浴びすぎてコンタクトを一つダメにしてしまった。
お腹がふくれた後は、今はいないけど田代まさしの焼きそば屋を見に行ったり、デストロイヤーの電気屋さん（だったかな？）を見に行ったり、お化け屋敷（今は盆踊りのようだが）の方に抜けて一息ついたり、童謡赤い靴のきみちゃんの像の近くのステージをウロウロしたりする感じかな。大混雑の十番通りは下り（？）だけにして、上りは迂回するのが落ち着けるコツかも。
今年は、今まで近寄らなかったりスルーしていたフレンチの夜店の子羊とヴィシソワーズが美味しくて感動だった。十番通りから少し外れた方が、落ち着いて上手い夜店が見つかるかもしれない。合唱するアイスコーヒー屋とかあるし。
あとは、縁日の終了時刻である21時前後に投げ売りを始めるので、交渉して安く旨いモノを買うという楽しみもある。僕も以前、焼肉をこれでもかと盛ってもらったことがある。十番は山の手だが人情味のある下町風情もあるので、いろいろ親切にしてもらえるかもしれない。
一つ悲しいのは、昔ながらのラムネがほとんど見かけなくなったこと。プラスチックのビンでは気分が出ないし、何より美味しくない。縁日以外なら浪花屋さんに行けば呑めるのだが、縁日で呑めないとチト寂しい。これも時代の流れかしら。まぁゴロゴロ売っていたのだが混みすぎて見えなかったのかもしれないけどね。
ともあれ、来年はもう少し空いてる時間に行こうっと。土曜の19時なんて、一番混んでる時間帯だもんね。
2007-08-24
好きこそものの
山ごもり終了。帰りに特急を30分ほど待つ。中途半端な時間だ。同じグループの人々はアイスを食べたり、携帯を見たり、おしゃべりをしたり。僕はPHSで巨大なメールが取れずに四苦八苦。近くの高校生は、PSPで通信ゲームをやっている。キオスクのおばちゃんと話している観光客もいる。ちょっとしたヒマな時間なんて、みんなそんなもん。どこにでもある、普通の光景だ。
しかし隣に座っているTOPPERS軍の高田総統は違う。そんなほんの少しの時間にも、集中してコードを書いているのだ。多分TOPPERSのコードだろうが、凄い。僕がディスプレイを覗いているのも気にせず、書く、書く、書く。時々「う～ん、ここはどうするかな」とか言いながら、書く、書く、書く。
何というか、凡人と偉人の差をまざまざと見せつけられた気がする。これくらいやらないと偉人になれないのか、これくらいやったから偉人になったのか。いや違う。時間が空いたらコードを書きたくてたまらないくらい好きだったり、コードを書くことが空気を吸うようになっているのだろう。なるほど、TOPPERS軍の結束の堅さの理由が分かった気がする。
しかし隣に座っているTOPPERS軍の高田総統は違う。そんなほんの少しの時間にも、集中してコードを書いているのだ。多分TOPPERSのコードだろうが、凄い。僕がディスプレイを覗いているのも気にせず、書く、書く、書く。時々「う～ん、ここはどうするかな」とか言いながら、書く、書く、書く。
何というか、凡人と偉人の差をまざまざと見せつけられた気がする。これくらいやらないと偉人になれないのか、これくらいやったから偉人になったのか。いや違う。時間が空いたらコードを書きたくてたまらないくらい好きだったり、コードを書くことが空気を吸うようになっているのだろう。なるほど、TOPPERS軍の結束の堅さの理由が分かった気がする。
急制動体験
今日は山奥で急制動体験をしてみた。とはいっても別に事故を起こしたわけではなく、完全に安全が確保されている環境で、教官が横に乗っている状況での体験だ。
実は昔、明治通りと中山道の交差点で日曜日の早朝にフルブレーキングをかけて歩道に突っ込んだことがあったりして、懐かしい体験だ。ちなみにその時は早朝だったので人がおらず、特に被害は無かった。やっぱりムシャクシャしてクルマに乗るといけませんね。
不思議なもので、ABSの無いクルマだったのでタイヤがロックし歩道に向けて滑っている間、頭の中は妙に冷静で、流れている車窓の映像はスローモーションだった。もしかして走馬燈だったのかもしれないが、とにかくパニックにはならなかった。
今回はABS付きとABS無しで80Km/hくらいから急制動をかけるのだが、まず急制動をかけるために80Km/hまでスピードを上げるのに少しビビる。もう年なので最近はあまり飛ばさないせいか、及び腰。そしてフルブレーキングをすると、頭の中が真っ白に。安全が確保されていることが分かっていても、急制動をかけるという体験そのものがパニックを呼び起こすのかもしれない。もしくは年のせいで頭の回転が鈍っているのだろう。
いつまでも若いと思ってムリしちゃいけませんな、と思ったのが今日の収穫でした。隣に乗っていた教官には、ABS付きの方が制動距離が短いのは事実だけど、そもそも急制動をするような状況にならないことが大事なんだ、と注意されたしなぁ。皆さんも気をつけましょう。
実は昔、明治通りと中山道の交差点で日曜日の早朝にフルブレーキングをかけて歩道に突っ込んだことがあったりして、懐かしい体験だ。ちなみにその時は早朝だったので人がおらず、特に被害は無かった。やっぱりムシャクシャしてクルマに乗るといけませんね。
不思議なもので、ABSの無いクルマだったのでタイヤがロックし歩道に向けて滑っている間、頭の中は妙に冷静で、流れている車窓の映像はスローモーションだった。もしかして走馬燈だったのかもしれないが、とにかくパニックにはならなかった。
今回はABS付きとABS無しで80Km/hくらいから急制動をかけるのだが、まず急制動をかけるために80Km/hまでスピードを上げるのに少しビビる。もう年なので最近はあまり飛ばさないせいか、及び腰。そしてフルブレーキングをすると、頭の中が真っ白に。安全が確保されていることが分かっていても、急制動をかけるという体験そのものがパニックを呼び起こすのかもしれない。もしくは年のせいで頭の回転が鈍っているのだろう。
いつまでも若いと思ってムリしちゃいけませんな、と思ったのが今日の収穫でした。隣に乗っていた教官には、ABS付きの方が制動距離が短いのは事実だけど、そもそも急制動をするような状況にならないことが大事なんだ、と注意されたしなぁ。皆さんも気をつけましょう。
2007-08-23
ソフトウェアの価値と自動化
最近ご無沙汰のさかいさんからコメントを頂いたので、昨日のエントリの続き。
大森記者の最後の段落での主張は、きっと、ソフトウェアの自動生成により低コストでユーザに価値を提供できるようになる、だと思う。違うかしら。違ったらごめんなさい。
この主張が僕にとって気持ち悪いのは、きっとこんな理由だ。もちろん昨日のエントリにも書いたが、ドメインがあまり変化しなければ、自動生成は可能である。でもこのドメインが変化しないというところが気持ち悪い。
ソフトウェアは、我々の生活を豊かにしてくれる存在だ。その豊かさは、我々が既に営んでいることをスピードアップしたり、コストダウンしてくれたり、スケールアップしてくれるものかもしれない。しかしむしろ、我々が暮らしている世界を広げてくれる存在であって欲しいと心から思う。
例えばカメラ付き携帯電話を考えてみよう。携帯電話にカメラが付いて、我々の生活に何が変わったか。合わせればカメラ付き携帯電話の大きさになる程度の小さな携帯電話と小さなデジカメを別々に持つこととは、訳が違う。携帯電話を使ってカメラで撮った画像を友達に送ることで、きっとコミュニケーションの幅が広がったのだ。カメラ付き携帯電話が出現する以前に、もし携帯電話用のソフトウェア自動生成ツールがあったら、カメラモジュールを付加できるような設計になっているだろうか。きっと、ツールの開発者はそんなこと思いもしないだろう。
もちろん、スピードアップやコストダウン、スケールアップで質が変わることもある。量の変化は質の変化を生むからね。でももしソフトウェアが自動生成ツールで全て作られるようになったら、我々の生活の幅の広がりが、とても小さく制限されてしまうような気がしてならない。ツールの開発者が考えつく程度の世界の中でしか、我々は生きられなくなってしまうのだ。
だから僕は、汎用的なソフトウェアを手動で開発できる手段を確保しておきたい、と思うのだろう。もちろん部分的に自動化するのは大歓迎だし、実際にたくさん成功している。一部のドメインでは、全体的な自動化にも成功しているだろう。しかし多くのソフトウェア開発が自動化されたら、何だか夢の無い世の中になるような気がする。ソフトウェアが「柔らかい」から、思いもしなかった世界が出現するのだ。
自信を持って主張するけど、多くのソフトウェアが自動生成されているような世の中は来ないと思う。自動車だって家電だって、自動開発はされていない。もしそういう世の中が来るとするならば、ソフトウェアがコモディティ化して、手動で開発する価値を持たなくなった時だ。"IT doesn't matter"ということか。でもきっとその時には、手動で開発するだけの価値のあるソフトウェアを、人間は誇りを持って開発していると思う。そう信じたい。
大森記者の最後の段落での主張は、きっと、ソフトウェアの自動生成により低コストでユーザに価値を提供できるようになる、だと思う。違うかしら。違ったらごめんなさい。
この主張が僕にとって気持ち悪いのは、きっとこんな理由だ。もちろん昨日のエントリにも書いたが、ドメインがあまり変化しなければ、自動生成は可能である。でもこのドメインが変化しないというところが気持ち悪い。
ソフトウェアは、我々の生活を豊かにしてくれる存在だ。その豊かさは、我々が既に営んでいることをスピードアップしたり、コストダウンしてくれたり、スケールアップしてくれるものかもしれない。しかしむしろ、我々が暮らしている世界を広げてくれる存在であって欲しいと心から思う。
例えばカメラ付き携帯電話を考えてみよう。携帯電話にカメラが付いて、我々の生活に何が変わったか。合わせればカメラ付き携帯電話の大きさになる程度の小さな携帯電話と小さなデジカメを別々に持つこととは、訳が違う。携帯電話を使ってカメラで撮った画像を友達に送ることで、きっとコミュニケーションの幅が広がったのだ。カメラ付き携帯電話が出現する以前に、もし携帯電話用のソフトウェア自動生成ツールがあったら、カメラモジュールを付加できるような設計になっているだろうか。きっと、ツールの開発者はそんなこと思いもしないだろう。
もちろん、スピードアップやコストダウン、スケールアップで質が変わることもある。量の変化は質の変化を生むからね。でももしソフトウェアが自動生成ツールで全て作られるようになったら、我々の生活の幅の広がりが、とても小さく制限されてしまうような気がしてならない。ツールの開発者が考えつく程度の世界の中でしか、我々は生きられなくなってしまうのだ。
だから僕は、汎用的なソフトウェアを手動で開発できる手段を確保しておきたい、と思うのだろう。もちろん部分的に自動化するのは大歓迎だし、実際にたくさん成功している。一部のドメインでは、全体的な自動化にも成功しているだろう。しかし多くのソフトウェア開発が自動化されたら、何だか夢の無い世の中になるような気がする。ソフトウェアが「柔らかい」から、思いもしなかった世界が出現するのだ。
自信を持って主張するけど、多くのソフトウェアが自動生成されているような世の中は来ないと思う。自動車だって家電だって、自動開発はされていない。もしそういう世の中が来るとするならば、ソフトウェアがコモディティ化して、手動で開発する価値を持たなくなった時だ。"IT doesn't matter"ということか。でもきっとその時には、手動で開発するだけの価値のあるソフトウェアを、人間は誇りを持って開発していると思う。そう信じたい。
2007-08-22
2007-08-21
日経エレのブログ「プログラミングは『設計』か『製造』か」
最近忙しくて、いくつか来るメールニュースのタイトルさえ読めていない。なのでここのところ浦島太郎状態だ。しかも明日から週末まで、もしかしたら山の中に篭もる感じになるため、ネットにすらつなげないかもしれない。まぁ、なるようになれ、だ。
たまたま見たメールニュースに「プログラミングは『設計』か『製造』か」というタイトルがあったので読んでみた。書いているのは日経エレの大森記者だ。まぁ記者の眼にせよこのブログにせよ、日経BPの記者が書いているコラムはほとんどの場合宣伝込みなので、斜めに読まなくてはならない。日経ものづくりは別だけど。これもどうやら、SPLCやスターロジックの宣伝のようだ。別に宣伝をしても良いのだが、イマイチ何を言いたいか分からない。大森記者に限った話ではないが、記者なのだから支離滅裂な文章を書かず、宣伝とは悟られないような名文を書いて欲しいと常々思う。
この文章、本当に突っ込みどころが多い。
曰く「ものづくりの現場にいる方は『ソフトウエアといえどもモノなのだから，プログラミングはソフトウエアを製造する行為だ』と自然に考えていると思います。だから，ソフトウエア開発も自動化できるはずだ，と」。おいおい、ものづくりの現場にいる人は、ものが自動で勝手にできるなんて思っちゃいないよ。自動で作っているように見えるまでに大変な苦労をしているのだから。
曰く「「プログラミングは設計である」という考え方に大きな影響を受けて生まれたのが『アジャイル開発プロセス』という先進的なソフトウエア開発手法です」。そうなのか。そんな矮小な概念だったのか、アジャイルというヤツは。
曰く「組み込みソフトウエア開発の分野は，ソフトウエアの仕様が比較的はっきりしているので，IT系のシステム開発より製造に近いという面はあります」。えぇぇぇ、まだ完成もしていないハードとのすり合わせなんて日常茶飯事なのに。仕様がはっきりしていて作りやすい組込みソフトなんて、ほとんど聞かないけどなぁ。
曰く「ソフトウエアの要件さえ確定すれば，あとはコードの自動生成ツールを駆使してソフトウエアを完成させるというのです。ここにあるのはまさに製造の考え方です」。だから、製造というのは、要件が確定すれば後は設備が勝手に作ってくれるんじゃないんだって。生産工程の設計とか初期流動管理とか、山ほど色々知恵を絞るんだって。
とまぁ、色々と難の多い文章だが、では本当にスターロジックのツールを使うと、設計無しでツールがプログラムを自動生成してくれるのだろうか。僕はこのツールをよく知らないが、それは可能かもしれないな、と思う。事実、制御系のソフトウェア開発では、Matlabなどを使ってCコードを自動生成するモデルベース開発という取り組みが盛んになりつつあるからだ。ちなみに、モデル駆動開発ではありません、念のため。
ただし、そのためにはいくつかの条件が必要になる。まず、作ろうとするものの自由度が低いことだ。特にドメインに関する自由度が低い方がよい。自由度が高いコード自動生成ツールは、要するにフレームワークやライブラリ、コンパイラと何ら変わらなくなってしまう。次に、非機能要求を含む要求それぞれに対して、サブプログラムなどの設計要素が1対1で対応することだ。何らかの設計上の共通化は、コンパイラの最適化のようにアルゴリズム的に規定できるのであれば可能である。これはすなわち、メモリなどのリソース制約やスループットなどの性能要求を満たしにくいということにつながる。もう少し一般化すると、要求に対する設計のすり合わせが発生すると、かなり自動生成は難しくなるだろう。
要するに、ドメインがかなり限られていて、要求と設計要素が1対1で対応し、リソース制約や性能要求が緩いアプリケーションであれば、以前からコードの自動生成は可能である。コンパイラ（アセンブラもか？）が出現した時に、一部の人々はもうプログラムを書かなくてよいと喧伝しただろう。フレームワークも、そういう喧伝をされることがある。モデルベース開発に至っては、いまだにそう思っている人がいる。
しかし実際には、多くの場合、自動生成は難しいだろう。それは上述の条件が満たされないからだ。そしてもう一つ理由がある。パーキンソンの法則があるからだ。冷蔵庫が一杯になったので買い換えても、すぐにまた一杯になる。それがパーキンソンの法則だ。これは、自動生成についても同じことが言えるだろう。
コンパイラが生まれたことで、プログラミングは無くなったか。否。では何が変わったか。それは、開発者の知的リソースに対するアウトプットが増加したのだ。つまり、同じだけ頭を使ってできるソフトウェアが、より複雑になったり、高機能になったりしたのだ。一方、開発者の知的リソースそのものは変わらない。こちらはむしろ、ラインエディタからスクリーンエディタになったり、統合開発環境が出てきたりといったことの方が寄与しているだろう。
すなわちツールで自動生成が可能になったら、ほんの少しの間だけ開発者は頭を使わなくて済むようになるだろうが、すぐに開発対象の要求が高度になったり納期が短くなったりして、何らかの形で頭を極限まで使うようになるだろう。コンパイラによってメモリマップを書かなくて済むようになったがごとく、頭を使う対象は変化する。しかし頭を使うことそのものは、形は変わるものの、同じである。我々の欲望の進化は、技術の進化よりも常に速いのだ。
もちろん、コードの自動生成に意味が無いなんてことは全くない。歓迎すべきだ。これは、頭を使うことを減らしてくれるツールである。しかし同じくらい重要なのは、頭を使うこと、すなわち設計とは何かを考え抜き、頭を使うことをいつも楽にしてくれるツールや方法論を考え出すことだろう。設計という高度に知的な行為に対する洞察をすること無しに、ソフトウェア開発は楽にならないと思う。コンパイラが出ようが出まいが、我々が知的なミスをすることは変わらないし、クリエイティブな感覚を持つことが楽でないのも同じである。そういったことをきちんとソフトウェア工学で扱わなくてはならないのだろう。コンピュータに代行させることだけが工学では無い、と僕は固く信じている。
たまたま見たメールニュースに「プログラミングは『設計』か『製造』か」というタイトルがあったので読んでみた。書いているのは日経エレの大森記者だ。まぁ記者の眼にせよこのブログにせよ、日経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 - 研究論文投稿
日時：2008/3/16（日）～20（木）
場所：
締切：2007/11/2 - 研究論文アブスト投稿, 2007/11/9 - 研究論文投稿
登録:
投稿 (Atom)