IT飽きてくと

朝っぱらから、ash.氏と「IT飽きたって言ってたんだよ」なんて話をメッセージでやりとり。

ITアーキテクト業がだんだん面白くなくなるのはなぜだろう。

ひとつには、「おれってもしかして天才？」と思える、「あの」瞬間を感じる頻度が減っていくからではないかな。上流工程のマネージメントにいけばいくほど、つまり、いわゆるシステム構造設計、あるいはプロジェクトマネージメントという職種では、あの感覚を得にくくなる。一般化してゆき、月並みになってゆき、その上、out-of-control マターが多すぎる割りに、成果もツマラナイのだ。ある程度儲かりはするが、ツマラナイ何か･･･。

そう、あれだ。

構造設計といえば、今話題の某建築士の事件を指差して非難できるITアーキテクトってそれほど多くないぞ。彼は、ちゃんとやる方法とコストもわかった上で、外圧で鉄筋を抜いた。もちろん不正は不正だが。一方、ITの世界だとそれが「不正」とも定義されていないから、ちゃんとやる方法さえわかっていなくても、現時点でつぶれてなければさらしものにされない。「工法が安定すればITの世界でもそうなっていく」との意見もあるが（紀氏）。

要はそれがないのをいいことに、外圧だろうが無知の設計だろうがITの世界はなんでもアリで、鉄筋を抜いてあるどころか存在すらしない設計が普通にまかりとおってしまう。でもって、「震度5強」のような、過負荷がかかって出た不具合を、サーバ、ディスクの「寿命」なんて呪文をとなえてさらに高額のリプレースを正当化し、投資をさらにひっぱる･･･。

ニコラス・G・カー著 DOES IT MATTER?（「ITにお金を使うのはもうおやめなさい」）という本は、HBRで、"IT Doesn't Matter."という論文として掲載されたものがベースになっている書籍だ。うまいタイトルだ。ITは役に立たない、というそもそも論を展開するものでも、情報そのものや使う人自身の有効性を否定しているものでもない。むしろ、多くの局面において、思い切って「金食い虫」のIT投資をやめてみろという。

ITの世界で喜びを見出そうとする人にとって、これは必ずしもマイナスにはならない。持ち家のメンテナンスが建替えに終始しないのと同様、ITの世界でも「ビフォー・アフター」はありえる。きちんとした設計とそうでないものはやがてはっきりする。今あるものを活用、改善することが不可欠になるからだ。設計だろうと、実装コーディングだろうと、きちんと作れる、直せるみたいな、その種の「快感」がよみがえってくる現場が増える可能性がある、匠の世界。そこがオープンソースの真骨頂かもしれないと思いきや･･･。

＞「だからいま binary 2.0 なんですよ。」（ukai氏）

はっ、そうくるかー。(@_@;　ソースコードのハックに飽き足らず･･･。
確かに、under control領域が拡がると、快感も増すものだよね。うむうむ、と、うなずきつつ、一週間続いている偏頭痛をlivepatchできないものかと薬局へ･･･。

GMail Trashメソッド

最近、メールはとにかく一切合切GMailで受け取るようになった。リアルの主なメールはGMailに転送しているし、さらに気が付く限り、ネットのサービスの「メールアドレス」欄をGMailのメールアドレスに変更した。すると、数々のニュース、メールマガジンなど、以前から購読しているものも含め、すべてGMailに集約される。

そういう環境の基本機能として、SPAM判別機能、Report SPAM機能は大変便利だ。SPAM判別情報が他のユーザとシェアされているかどうかわからないが、そこそこ学習してくれているようだ。体感的には、POPFileより少し落ちる程度の精度だ。購読申込した覚えのあるメールニュースと、メールニュース仕立てのSPAMを正確に判別してくれる。

しかし、業務メールと違い、これらメールニュースは溜まっていく一方では役に立たない。後者の賞味期限は短いのだ。そう、昔は、インターネット上に情報が十分ではなく、有料のメールニュース（?Watchなど）を溜め込んでおいて、それを検索することでリサーチに役に立ったこともある。しかし今は、Ask Google!で済むから個人が溜め込んでおく意味合いは低い。

当初、newsというラベルを作ってフィルターでラベリングしてみた。それでも、読まないメールはどんどん溜まる。news(256)のように、未読数カウントがみるみる増えていく。不思議と、未読数は多くなればなるほど見たくなくなる。読んだことにして消すのもかなり大変。

そこで、sakurayuta師匠曰く、「メルマガ系は、フィルターでTrash(ゴミ箱)に放り込んでしまえ」、というものだ。どんな効能があるのだろうか。

・Trashフォルダへのリンクの横には未読数の表示はない。
・30日で自動消去がすばらしい。無限に溜まっていくということはないからね。
・検索の対象だ！30日以内のニュースだけならピックアップ価値も低くないねー。
・SPAMとはごっちゃにはなっていないので、フォルダを開いたときの汚れ感も低い。
・GMail Notifier、Google Desktop2を入れていても、Skip inboxしていれば何も表示しない。
・デフォルトで捨てる、任意で見る、というのはいかにもポジティブセキュリティ風味だ。
・「リアルでゴミ箱の新聞を読む習性(sakurayuta氏談)」なんてシュール感もある。

ふふーん、スバラシイ。超整理法的だ。（コーヒーをずずっと

気が向いたときに、Trashをおもむろに見る。見たくなったものだけ見ればいいから、悪くない。毎日何通も来るのはわかっているが、仕事をトラップされないというのはむしろ快適だ。inboxに戻れば、現実の世界にすぐに戻ってこれる。

GMailで言うところの「ラベル」の属性として、expire指定ができればいいのにな。確かにソフトウエア原理的に削除系はリスキーだが、それでも、メーラーのフォルダの属性、フィルタの属性などにexpire機能があるといいなあ。是非メーラーに実装してほしい。メール単体に実装する、でもいいけどね。「このメールは自動的に消滅する･･･」みたいな（ｗ

そうそう、OSのファイルシステムにもそういう機能があればいいんだ。いやまてよ、そんな機能はこれまた悪用しがいがありそうだ･･･それに悪意のあるコードにもさくっと実装されそう･･･それに、コンプライアンス的にはSOX法と真逆の論理じゃないか･･･。悩ましい。

でも、それでも、Keep it simple and special.古い、使わないものは捨てるに限る。超整理法的機能なのだから、ぜひ実装してもらいたい。あれ、捨てるんならTrashでいいのか･･･。

てわけで、これ、すなわち「GMail Trashメソッド」と命名。

手帳のアーキテクチャー。

こういうことで悩むのは昔から好きだ。手帳は、毎日の生活の文化に影響するから、というだけの理由ではないと思うが、行動指針を見直すいい機会になる。

ほぼ日手帳
http://www.1101.com/techo/

2005年は「ほぼ日手帳」を使ったが、このリピートは残念ながら、ない。シンプルで書きやすかったが、わたしにとって手帳に求める意味合いは日記形式でクローズするものではなかった。書きなぐったタスクやメモなどは他の日程ともリンクした横断的なものであったし、それゆえに日次のTODOよりも、時系列を自在にまたぐものとして管理しなければならないことを痛感したからだ。

また、各プロジェクトは数日、数週間、数ヶ月と様々だが、それをごっちゃにして時系列で並べては混乱する。むしろそれごとにスレッド化して管理すべきである。いかに書きなぐりがしやすい手帳でも、製本として閉じてしまう方式はなじまないように感じている。

全ページがばらばらにでき、かつ任意の順番でオーソライズできるのであれば、それはそれでアリかもしれないが・・・、それでは、ほぼ日手帳ではなくなる。そこで、手帳を模索するプロジェクトが発足したのだ。


FlanklinPlanner
http://www.franklincovey.co.jp/

Tokyu Handsで見た、フランクリンプランナー。「7つの習慣」とか有名な本があるが、その実行ツールと言っていいだろう。最近はとうとう「8つ目の習慣」が出たんだそうだ。詳細なプロジェクトや思考のテンプレートや、「7つの習慣」の名言がちりばめられているのはそれなりに教訓的。

しかし、私に言わせればfortune　cookieと大差なく、それほどありがたいものではない。皮肉めいた言い方をすれば、自分の行動指針を持たず、朝のTV番組や安っぽい週刊誌の占いに頼っているような - そう日本人とは概してそういうものだが - そういう人の意識にはもしかすると教育的効果はあるかもしれない。

テンプレートは、プロジェクト管理の思考を身に付けたい人にはいいんだろうが、私にはウルサく感じられるし、むしろ窮屈だ。私には、軽い小話を書いているほぼ日手帳のほうが面白い。その部分だけ携帯に毎日配信してもらいたいくらいだ。


Time/System
http://www.timesystem.jp/c/catalog.html

伊東屋で、kumikumiが言及していた、TimeSystemを見てみる。ほほう、なるほど、たしかにFPほども鬱陶しくない。基本はA5。他のサイズもあるようだが、この大きさは書きやすそうだ。プロジェクトテンプレートは1年間ずどーんとあるにしてはデイリーは細かい。ウィークリーで十分な気もする。

マインドマップ、マトリックスなど、FPよりすっきりしたテンプレートがいろいろあるのは面白い。それに、FPと異なり、汎用性のあるリフィルがあるので、A5サイズを基本とした場合には「つまみ食い」可能だ。

ここまでくると、もう趣味の世界だな（ｗ　もちろん、脳内スイッチを入れるのにデザインは重要だ。しかし、やはり致命的なのは、これは（他と同様）TODOを時系列を越えて継承することができない。使わない欄がでてくるのはもったいない。


さあ、どうしたものか

まてよ･･･。とりあえず、やりたいことは、議事録、講義準備、プロジェクト計画、アイデアスケッチ、マインドマップ、マンダラート・・・。碁盤の目さえ下敷きとして書いてあれば、自分には十分なのではないか？ 大きさは、RHODIAの#16がちょうどよい。あれを持ち歩き、どんどん書いていき、開穴してA5のシステムファイルにスレッド化してオーソライズすればいい。

スケジュールはできるだけライトウェイトなカレンダーだけあれば十分なんじゃないかな。サイボウズやGoogle Calendarなどのサービスに依存しそうな気もするから、できるだけ単純なものを持ち歩いたほうが得策だ。TODO管理については、今のところRHODIA #11に勝るものはないし、これを携帯しなくなることはなさそうだ。

これでしばらくやってみようか。

フィッシングリスク軽減のためのヒント

「ポジティブポリシー重要！」といったそばから「べからず集」、すなわちネガティブポリシー的なのも何なのだが（苦笑）、こういう記事がでた。

日経BP ITPro 記者の眼「“フィッシング時代”のメール「べからず」集」。

紋切り型のセオリー集としてではなく、リスク軽減のヒントとして捕らえていただきたい。サイトによってリスクはさまざまだし、防衛方法もさまざまなので。かといって、「他社様」の選択が正しいわけでもないのに、ダメなほうに横並びなのはあまりに嘆かわしいしね。

こういうのは、ともすれば一人歩きしてしまいがちな「セオリー集」になってしまいがちだが、適用を自分で考えることができるよう、微妙なニュアンスを表現に加味してくださった勝村氏のご苦労に感謝したい。欲をいえば、やや過剰ギミな名前の連呼はご勘弁願いたいところだが。

ま、それもリスクヘッジなら仕方がないね ;-p

ネガティブポリシーからポジティブポリシーへの転換

6/29に第二回情報セキュリティEXPOの専門セミナーにてお話をさせていただく機会がありました。第一回のときは、OWASPの人とペアでしたので、「Webセキュリティ」の話一色でさせていただいたので、「フィッシングに利用されないようなサイト作りを」みたいなことを提言しました。今回は、アンチウィルスベンダーの方とペアで、どちらかというと企業がどのように防衛するか、という御題をいただきました。

Webにせよメールにせよ、セキュリティ防衛をする際に念頭におくべきことがあります。その一つは、「ネガティブポリシー(negative policy)」と「ポジティブポリシー(positive policy)」の違い。前者は、例えば「ブラックリスト」にのっとって受け入れられないものを排除する方式で、いうなれば悪いものをろ過する方式であり、前者と対照的に「ホワイトリスト」にのっとって受け入れられるものを厳密に定義する方式を解説しました。

ウィルス対策の場合、原理的に言ってウィルス定義ファイルはまさにブラックリストであり、それゆえにアップデートしつづけなければなりません。もちろん、ヒューリスティック検知方式などで補完することにより、ブラックリストに載っていないものも「それっぽい」ということで濾過することを可能にしています。SPAM対策でよく用いられる、ベイズ理論は、悪いものと良いものの両方の類推方法を学習していきますので、これら二つの方式の組み合わせと考えることができるでしょう。

WEBのフォームの入力データの場合、よく「サニタイズ(sanitize:「消毒」の意)」という言葉が用いられます。これは、ネガティブポリシーに基づく用語です。HTMLのタグや特殊記号などをフィルタリングするなり、クォーティングするなりという処理を行なうことを指します。しかし問題は、実際には入力データはそのアプリケーションの要件により毒にもなれば実にもなるわけですから、サニタイズという概念では完結しません。

また、危険の可能性がある文字なりパターンなりのすべてをプログラマーが知らない場合はどうでしょうか。見落としリスクがあるということです。そのアプリケーションは、そのプログラマーの腕に依存します。新たな脅威がでてきたら、そのプログラマーは直ちにサニタイズプログラムをアップデートしなければならないでしょう。それは現実的な方法ではありません。そういうわけで、WASForumのコンファレンスで高木さんが「サニタイズ排除キャンペーン」を発表されたのには全く同意です。

むしろ、正しいアプリケーション設計の観点から言うなら、本来すべきことはサニタイズではなく、入力の有効性検証(input validation)です。これはサニタイズに似ているようでも、実際には全く異なります。害のないデータでも無効なものはいくらでもあります。各々のフォームにおいて、「有効な(valid)」データを、桁数、文字種などに至るまできちんと定義し、そうでないものをすべて排除するという方式をとることです。

現場では、ポジティブリストの安全性を担保するため、あるいは、どんなリスクがすでに発生しているかを知るため、ブラックリストに該当する入力があった際にアラートを発生させるなどの方策を実装する場合などには、サニタイズプログラムは有効でしょう。しかし、根本的に、危険の可能性を知っていることだけを前提にした設計は、運用的にすぐに破綻しやすい、ということです。

今回の講演でこの話をしましたら、熱心に聴いてくださったメディアの方がサマリーを掲載してくださっていました。少しニュアンスが異なる部分もなきにしもあらずなのですが、シェイプアップしてサマライズしてくださっていますので、ぜひご覧ください。ご意見、ご感想も歓迎します。

ユーザを守る責任とスピード感

CNet Japanに、「カカクコム事件に見るセキュリティの本質とは」 という記事を寄稿しました。クラックされた他社の被害の手口に関する詳細情報は、セキュリティ維持の観点で不可欠だとはいえない。2ページ目では、EBサイトの攻撃から被害の拡散に至る情勢からすると、被害を想定した対応方針が必要で、そのポイントは「スピード感」 であることを示しました。最後に、WEBサイトの運営者の企業のCSR（社会的責任）に言及しました。

ご覧いただければ幸いです。

OSSプロジェクトの共感と意欲

「コードも書かない人に言われたくはない」 正直で、エモーショナルな言葉。それゆえに、共感、反発、共に大きな反響を呼んでいます。でもこの議論、「言われたくはない」、何を言われたくないのか、なぜ言われたくないのか、もっとそこを議論したいと思いました。

発言者の三浦さんの原文では、

「だからこそ、CodeFestを日本で開く応援をしたい、推進派になった。人材育成とか、日本発のＯＳＳとか、コードも書かない人に言われたくはない。一緒に取り組んでいる仲間を増やすこと、同じ空間と時間を共有して、フリーソフトウエアの世界を確かに広げた実感を共有すること、それこそが醍醐味ではないか。 」

人材育成と日本発のOSSが例に挙げられています。これはよく考え抜かれた指摘ですね、要するに誰と一緒に仕事をするか、そこで何を成果として作るか、これをコードも書かない人に言われたくない、と。 仲間と共感でき、そこで意欲的に成果がでることがサイコウにうれしい、と。ここは事実提示です。

すると、コードを書かない人に「言われたくない」ことがあるとすればそれは、開発組織における「共感」や、成果物への「意欲」が度外視されるケースだということでしょうか。(小飼さんの「コードだけでOSSの世界が回ると思ってんのか」は、そりゃそうなんですが突っ込みポイントはそこじゃない、という感想です。) 昨今の三浦さんのご活躍の現場で、何度となく彼自身が板ばさみに会い、まさに苦悩ゆえの発言だと連想されます。

さて、その「仲間との共感」と「成果物への意欲」は、ものづくりの立場にとっての軸と、要件を出す立場にとっての軸とは表現も価値観も異なります。けれど、そこの問題を提起するのであれば、「その溝はもう埋めたくありません」と言ってしまうと、そこの問題解決による発展の可能性を低めるというリスクがありますね。 共感や意欲を共有できるかどうかは主に、外的要因よりも内的要因のほうが大きいからです。内的要因でシャットアウトされると手の出しようがなくなります。

ですから、OSS開発では、開発者もユーザも一体になってはじめて意欲的な成果物に成長する、というシナリオを目指します。そして、成功しているプロジェクトに「コードを書かないプロデューサ」がいることは珍しくありません。OSSにおいては、なおのこと、「共感」と「意欲」がシンクロしている、あるいはシンクロさせる努力が必要だというわけです。

名前を挙げれば続々と、まさにそういうことをしてきた人たちが存在します。開発者、プロデューサ両方の側面ができる人もいます。マーケティングからやってきて、一生懸命理解しようとしてきた人たちもいます。そういう人たちは、自分ではなく、開発者を中心としたマンダラート、ユーザを中心としたマンダラートの両方を持っているゆえに、各ステイクホルダーとの調整ができるし、期待されているわけです。


OSS開発のステージの大きな変化

ところで、その対立構造とは異なるところで、不思議と同じ論点があり、そこでは相互に議論がものすごく盛り上がっているという動きがあります。 それは「コードを書く人」の中での話です。

いくつもの大きなベンダーやSIerがメインフレームの人間、ミッションクリティカル系技術者を駆り出してまでオープンソース開発セントラル組織を作り、実際にOSS開発を前提に基礎開発をばりばりやっています。この動きにより、OSSとは全く別のところにいた、よく訓練された技術者に新たなステージを与え、しかもこれが少なからぬ意欲を与えることに成功しつつあります。 これらが表面化するのは時間の問題でしょう。

最近、そういう方々を公の場でインタビューする機会がありました。（吉岡さんのレポート参照のこと）「メインフレーム屋」でありながら「OSS開発プロジェクト」をどうしていこうか真剣に考えている人たちです。 彼らの主な特徴としては、OSSの「自由な開発」「自由な意思決定」という部分はよく解らない。しかし、品質や時間の観念、障害解析に関するリテラシーはものすごく高い。これまで閉塞的なところから突然やって来たという意味で仙人のような人たちです。

一方、これまでの「みんなでふもとからコツコツ上がってきた人たち」は、そうした情勢の中で組織的に参入してくる「山から下りてくる仙人」とどのように共感し、分かち合っていくのかが大きなポイントとなります。Linux Kernel MLでのLinusのカーネルダンプ問題しかり、そこには大きなエネルギーがいります。 その議論をデフォルメして言えば、企業のミッションクリティカル要件にとって必要だから、壊れたときのための機能を作らなければならない、という集団と、壊れない良いものを作りたい、そういう作りたいものを作っていこうよ、という集団の議論です。 そこは、理屈よりも「共感」が必要な世界だし、目指す成果への「意欲」の問題でもあります。

それで、両者にある見解の違いを中心に、どうするのか議論が盛り上がっていることは、OSSの発展の歴史において、これまでにないすばらしいことです。この動きはソフトウエア開発モデルの歴史に残ることだと思います。 OSSプロジェクトにおいて新規に関係者が増えていく際に、とにかく議論のテーブルがあることは必須です。

まつもとゆきひろさんがおっしゃるスローガン、「コード書きの気持ちがわからないとオープンソース・エコシステムで成功できない」というメッセージは、孤立ではなく他者との関係で自分の目的を達成したい当事者においては、全員にひとしくあてはまると思います。俯瞰的に自分のポジショニングを確認するんなら、各立場からの観点で出されるメッセージを中心にマンダラートツールで思考をはじめていくと面白いですよ。開発者、ユーザ、支援者のどこをスタートとして書いていくにしても、最終的に大きな一枚の絵に描くにはなにが必要なのか思考する助けになるように思います。

いくつかの立場を理解できる人、客観的な目撃者として指摘できる立場にいる人間は、必然的に注目を免れない傾向があります。開発者自身、あるいはプロデューサ自身、ユーザ自身の意見よりも重く見られるために奥歯にものがはさまってしまう。そういう意味では、今回の件にまつわっては、皆さんストレートで、熱いメッセージが飛び交っています。吉岡さんしかり、きんねこさんしかり・・・、反応リンク集まで。発展を目指して語る以上、議論を恐れてはいけないですよね。これからも、臆せずにメッセージを出していって欲しいですね。

街中からスキムミルクが消えた！？

「スキムミルク」。どうも森永製のものが主に流通しているようだ。

3月17日放送にて最終回を迎えたTBS番組「スパスパ人間学」で、＜より効果を期待する方に「乳脂肪を最小限に抑えたスーパーやせるヨーグルト」の作り方＞が紹介されたためと思われる。

http://www.tbs.co.jp/spaspa/2005/03/0317/0317.html

ヨーグルトはともかく、材料にとりあげられているスキムミルク。最近では、栄養補給に少々、あとはパンを作る人がちょっと使う程度の需要。当然ながらそれにあわせた供給だ。放送当日の夜あたりから品切れが出始め、翌日には陳列棚から一通り消え、やがてスーパー、コンビニ、量販店、いずれも、奥から出してきた在庫でさえ、この連休中にすっかりなくなった模様。 尋ねるも、「次回の入荷は未定」という状態。

もともとそのような細い需要のものを、毎日大量に、2週間にわたって消費するアイデアだよ。それをインパクトたっぷりで情報提供すると、いろんなところが火の車だ。 需要の細い商品に人々が殺到してこういう状態になると、その情報で助かる人は少なくなる。連休中はもろもろ止まるのは必定としよう。しかし、連休明けはどうだろう。「街中から消えた」まんまだと、なんら売上がるどころか、クレームの嵐。（他の乳業系が補完できるのならそれはそれで良いのだろうね）

あわてて起こした増産ラインで需要をまかなえると思った頃にはもしかすると忘れられている。フォローできるはずの番組は最終回で終了しているし！おそろしや、需給悪化懸念は両刃の剣だね。吉と出るか凶と出るか。

スパスパも最終回にかこつけて、キラーネタに需給悪化起こしそうな商品の火種を撒き散らして終わりか？それはちょっといただけないよ。いや、もしや、こういう番組って、生産系との同意はとってあったりするのかな。 どうも健康系のノウハウを提供するテレビ番組って、生臭い。「煽り」だよね、「啓蒙」というよりは。観る側がわかってればいいんだが･･･。終わって正解ってことかな。

（連休明けの乳業系の株価でも眺めるかな。）

シフトダウン - downshifting

オーストラリアなどでここ数年、経済研究者たちが「シフトダウン」（翻字：ダウンシフティング downshifting)と呼ぶひとつの現象が観察されている。過剰消費生活をやめるという観点で、経済活動をいわばシフトダウンする傾向だ。「オーストラリアで最もエキサイティングな経済学者」と評されるらしい、クライブ・ハミルトン(Clive Hamilton)によるレポートは、Austiralia Institute (http://www.tai.org.au/)のサイトに見ることができる。

• Getting a Life: Understanding the downshifting phenomenon in Australia February 2004 [pdf]
• Downshifting in Britain: A sea-change in the pursuit of happiness November 2003 [pdf]
• Downshifting in Australia: A sea-change in the pursuit of happiness January 2003 [pdf]

Briton、Australiaときているが、日本については...まだまだだろうね。むしろ過剰消費熱は高まる一方だ。で、このクライブ・ハミルトンの本が邦訳、出版された。nikkei.jpのサイトにそのレビューが掲載されている。

http://nikkeibp.jp/wcs/leaf/CID/onair/jp/rep04/357826
根源的な問題として、「経済成長は人々の生活を豊かにするのか、人間を幸福にするのか」と問いかけ、「豊かさにも幸福にも結びつかないのなら、なぜここまで経済成長を追い求めるのか」と指摘。 「スローライフへのシフトダウン」を提示する。

本書には、「経済成長を遂げたものの、さほど豊かではなく、幸福でもない」事例として、たびたび日本が登場する。

日本のスローライフはとかく富豪系を連想させるが、その手の富豪系温泉暮らしだとか別荘暮らしだとか、いわゆるシフトアップの先にある高級嗜好ではない。むしろ、経済の追求をやめてしまうという意味でのシフトダウンというところにポイントがある。「清貧の思想」方向とも言えるかもしれない。

それにしても、シフトダウンとはうまい。自分の意志を感じるね。私はいまだにミッション乗りだが、峠は5速ではなく2速で走るものだよね。シフトアップよりシフトダウンのほうがドライビングポテンシャルははるかに高いじゃないの。人生のステアリングは低めのギアトルクでいけよということか。

運転はうまくてもヘタだも、スピードの出し過ぎは事故のもと。 もっとも、自分の運転をヘタだと自覚しているドライバーはそれほど多くないそうだけどね。

言い伝え「水引いたら高台に逃げよ」の有効性

年始早々、インドネシア・スマトラ島沖地震のニュースに対照的な2つの記録を見ることができた。

記事「インド洋大津波　生死分けた逃げ道選び　スリランカ・ヤラ国立公園」(Yahoo! News[産経新聞])によると、現場からの逃げ道はジャングルをかき分けた先の岩山と、川沿いの道だけだった。「高い所か、逃げやすさか - 瞬時の判断が生死を分けた」という。

「津波は濁流となって川沿いにジャングルを駆け上ったからだ。海岸から約三百メートルの岩山から見ると、車が浮き、低くなっている川に沿って津波がジャングルの奥深く流れ込んだ」 と同記事。狭くなっていく水路では水流の速度は増すはずだから、それでなくとも途方もない津波から逃れることなどかなうわけもなかった。 逃げやすいところには水も入りやすい。実に皮肉な結果だ。

対照的に、驚異の目で報じられている地域がある。時事通信社の報道によると、震源からわずか60キロのシムル島(Simeulue)では、住民約65,000人のうち津波による死者は、3日までになんと6人にとどまっている。他の地域の犠牲者数からしても驚異的な生存率だ。

なんでも、同島には「海水が引いたら高台に逃げろ」という教訓が伝統的な教えとして住民の間に語り継がれていたそうだ。 この教訓には「スモン」という名前がついている。「海水が引いたら次には必ず大きな波が来る、という教えが昔からある。･･･ 住民らはこの言い伝えに従い、水が引いた時、すぐに丘へ避難したという。」

大変驚いた。相当な人数がかなり早いアクションで行動できたことになる。
しかも水が引いたときに、疑わず、一斉に。

Wikipedia英語版の「2004 Indian Ocean earthquake」 のページからリンクされているニュースソースによれば、後の世代に教訓を残した、シムル島(Simeulue)を襲った1907年の津波は数千人の死者を出したようだ。それだけに、その教訓へのリスペクトは十分あったかもしれない。それでも、1907年の津波を経験した人なんてほとんどいないだろう。それで突然やってきた類例のない津波にそこまで機敏に対応できるだろうか。事実、島民は適確な行動の対価として命を得たのだ。

各新聞の社説、論説は、およそ「警告・警報の流布」か、「国際的救援」をうたうものばかりだ。本当に論じなければならないのは危険を感じた、あるいは警告を受けた時の人間の行動のあり方ではないだろうか。

教訓：
Speed means secure.
逃げやすいところは攻められやすい。