FeedMeterとは、あなたのBlogの人気度を測定してくれる
面白いWeb上のサービスです。

今日は、京都の五山の送り火ということで、
FeedMeterもご先祖様をあの世へ送る、
水先案内の役をしてくれるようですよ。

ほーら、明々と…まだ午後8時ではありませんが(^^;)、
おっきな「大」の字が。

CAMUSの実家からは、大文字が見え、
妙法 までは、チャリンコ導入すれば確実に見ることができる、
結構よいロケーションだったりします。
今年はどんな送り火になるのかな～…。

ちなみに、コチラは普段は星2つの
デジモノに埋もれる日々さまのFeedMeterです。

えーと、おんなじ形ですが、
一応、大文字山と、左大文字ってことにしておきましょう。(笑)

と、お楽しみはココまでのようで、星3つクラスになると、普通の星でした…。(残念)
三つ大が並ぶと…マヌケだよなぁ。
間に船とか妙法とかあるので、その辺うまーくしてくれると面白かったのに。
あ、そうすると、鳥居が仲間はずれになっちゃうねぇ。(困)

さて、あなたのサイトは、大文字の送り火でしょうか？それともお星様でしょうか？

【今までのFeedMeterのお遊び】
　あなたのBlogは☆いくつ？
　Feed Meter クリスマス仕様！ ～あなたのBlogは☆いくつ？続報～
　FeedMeterからのバレンタインプレゼント ～あなたのBlogは☆いくつ？続報～
　FeedMeterからホワイトデイプレゼント ～あなたのBlogは☆いくつ？続報～
　feedmeterもエイプリルフール？～あなたのBlogは☆いくつ？続報～
　　…など、これら以外にも正月には門松とか、check*pad記念とかがあったようです…。

私は、幼いころ、夏になったら薩摩川内市・甑島で過ごすことが多かった。
大体お盆の時期をはさんで3週間程度、この南国で過ごすことが年中行事となっていた。

昔ながらの風習を大切にする場所なので、
お盆の時期になると、盆提灯を出し、仏壇をお供え物などで飾る。
今でこそ電動の灯篭付の盆提灯だったりするが、
私が甑島によく行っていた頃は白くて細い蝋燭に火をともしていた。
蝋燭の火の熱で灯篭がくるくるまわり、子供心に目をきらきらさせてその様子を眺めたものだ。

夕方になると、そのきらきらしたものやお供え物をもって、山のふもとにある墓場にいく。
お盆の挨拶で、知り合いのお墓を回るのだ。
南国なので、昼間に外で動くとえらい目にあう(CAMUSは火傷するw)ため、
こういった外向けの行事は夕方からなのだ。

みんな、茣蓙などを引いて出迎えてくれる。
初盆のところは、みんなが来るので料理などでもてなしてくれる。

そのあいさつ回りが終わったら、子供たちも大人たちも、
里中学に足を向ける。
そこで、盆踊りが開催されるのだ。
(当時)島に1つしかない信号(笑)を渡ると、中学校はすぐそこだ。

大きな櫓と櫓からつるされた明々と照る提灯がめじるし。
流れる民謡のラインナップは島独特のものから薩摩のものが中心。
メジャーどころはドラえもん音頭ぐらい。(笑)

　♪まるーに　じゅのじーは　しまーずーのぉぉぉお　ごもーん　ちぇすと　ちぇすと♪

そんな「薩摩」な感じの民謡が多い。

はじめのうちはぱらぱらとしか踊っている人はいないが、
そのうち、どんどん人が寄ってくる。
友達同士が「踊ろ」「一緒に行かんね」と手を引っ張り合って、輪に入っていく。
私は、地元の従姉妹に手を引かれて輪に入る。
里帰りの若い人たちも、ずっと地元にいるじーさんばーさん達もワルガキ共も、
親の帰省でつれてこられた子供たちも
みんな一緒になって、輪になって。

振り付けは、簡単なものや難しいものもあるので、適当。
そのうちに何とか形になってくるような単純なものが多いので、踊りやすい。
踊りやすいから、子供だってすぐに輪に入れる。
都会の盆踊りは難しい踊りのものを選ぶ人が多いよ、と思う。

どんどん輪は膨らみ、
最後には4重ぐらいの輪になるほどの人が踊る。

疲れたら横でかき氷を食べたり、提灯の明かりに誘われるセミやトンボを追いかける。
トンボはともかく、セミは反撃してくる。激突されると、痛い。
カブトムシやカミキリなんかはもっと痛い。
たまにでっかい蛾がやってきてびっくりすることも。

おひらきにして帰る頃には、空には満天の星。
澄み切った空なので、はるかに星の数が多く見える。
吸い込まれそうな…と表現する人もいるけど、
あまりに星の数が多くて｢吸い取られそうな｣というほうが私にとっては自然かも。
…正直、星の数は多すぎると気持ちが悪いものだ。

すでに消灯してしまった信号(笑)を渡り、
足元にいるかえるやかにを踏まないよう気をつけながらも、星を眺め、漁火を見、
懐中電灯の明かりを頼りに、海の音を聴きつつ家路に着く。

今度の盆踊りには、もうちょっと上手に踊れるといいな、と思いながら。

…私には、そんな｢盆踊りは楽しかったな｣と思える、
幼い頃の夏休みの思い出があります。

[■TBカフェ：トラックバックBINGO SUMMER ]　より、お題は「盆踊り」を頂戴しました。
jinさん、いつも楽しい企画ありがとう。

ある日、保育園に子供を迎えに行ったときのことです。
なんだか、その日の子供はぐずぐず甘えんぼモードで、

　○○ちゃんが△△もってたから、私も買ってちょうだい

とか平気で口走っていました。
はじめは

　△△でどうやって遊ぶの？
　△△はどこに片付けるの？

と訊ねて、本当に欲しいのかどうかを試してみたのですが、
子供はロクに答えもせず、ただただ買って買ってというばかり。
あんまりしつこく言って来るので、ついつい

　そんなにほしいんやったら、自分で働いて銭稼いで買わんかい

と、しかりつけてしまいました。
ええ、もう、4歳の子供に言うセリフじゃあないっていうのはわかっていたんです。
でも、「買う」という行動を、エラくかるーく考えている子供に
プチっときてしまったんですよ。(汗)

すると、どーでしょ。
同じ時間にお迎えに来ていたほかのママさんたちから

　そうだそうだー！

と声がかかりましたぞ。(笑)

　お金手に入れるの大変なんだぞー！
　働かざるもの食うべからずだぞー！
　お金が沸いて出てくると思ってんじゃないぞー！

なんだかいろいろ声が出てきます。(笑)
皆、相当たまっているものがあったようですヨ。

言い方は悪かったとは思うものの、
　・「買う」という行動には「お金」が必要だということ
　・「お金」を手に入れるには、労働が必要だということ
　・「お金」を手に入れられるような労働をするには、
　　いろんなこと勉強(頭脳でも体でも)しておかないといけないこと
は、すごく小さいころからでも、教えていかなきゃならないことの一つだと思うのです。

大きくなってから教えても遅いと思います。
「金銭感覚」は小さいころからこつこつと育て、
育てた年月が長ければ長いほどよく研ぎ澄まされるものなのだと思っています。

体はって、こうやってこういうときに使うもんなんだよ、とこつこつと教えていく。
その行動が将来の子供を、子供自身が助けられるようになる為の知恵になってくれれば
と思います。

以前、携わったプロジェクトのお話です。

客先の要望で、WebのシステムをJavaで作れとの命令が下りました。

ナゼお客はJavaを要求したのか。
それは、CGIではなWebのシステムで、Javaでの導入事例が過去にあったからです。
お客は過去の導入事例が成功していたら、
それを習い続けようとする風習がありました。
そのため、有無を言わさずJavaで作れとのお達しがでたのです。

ところが、その仕事を請け負うチームには、当時Javaをベースに設計ができる人がいませんでした。(爆)
いや、いるにはいたのです。2人。
一人は、別プロジェクトで大わらわ。他の仕事に手を割くことができない状態でした。
もう一人は、病気で戦線離脱(休職)中でしたが、もうすぐ戻ってくるというウワサが立っていました。
チーム長は、後者のもうすぐ戻ってくる病人に白羽の矢を立てることにして、
とりあえず仕事を請けた模様です。

その病人が私なんですが。(爆)

ともかく、プロジェクトは進んでいました。
要件定義は半分以上終わっていて、ツメの段階になって、ようやく私は復帰＆参戦。
同時に、訳の分からんまま(爆)、即、クラス設計に入らなくてはならない状況でした。

このプロジェクトの特徴は
　・旧システムのリプレイスである
　・改修が頻繁に入る可能性がある
　・運用とメンテナンスを引き受ける必要がある
　・納期までが短い…(涙)
　・爆速レスポンスを要求される…(滝涙)
そのため、
　・「ここの仕様は前と同じ」といわれる可能性があるので、調査時間が必要
　・Javaを使える後輩を育てる時間がない
　・私がいなくても誰かが改修ができる工夫が必要
　・Javaのチューニングはなるべくプロジェクト期間中に
という制約ができてしまいました。(汗)

ここで、一番の問題は、
　・改修が頻繁に入る可能性がある
　・Javaの設計ができるやつがいないと想定する必要がある
の条件を同時にクリアする工夫が必要になっていることです。

幸い、HTML＆JavaScriptに関しては、達人がいましたので、
その人中心に後輩の育成＆作業をお願いできました。
ついでに、その方中心にXMLの作業もできるという環境ができましたので、
私はXMLをばんばん使うということが許される状況になり、かなり助かりました。
この状況を大いに利用させてもらい、
私自身はJavaに注力することが可能になりました。

◆問題点克服のキーポイント
改修をするということは、データのやり取りの方法が変わるということです。
　Webシステムのサーバから、ユーザ側に送るデータ(出て行くデータ)
　Webシステムのユーザから、サーバ側に送るデータ(入ってくるデータ)
大きく分けると、この2種類のデータのやり取りの部分を
Javaに影響なくやる方法を考える必要があります。

◆出て行くデータ
出て行くデータは、Webの画面上に表示するデータの事を指します。
Webの画面上に表示するデータは、増えることも減ることもあります。

表示するデータが減った場合は、
表示しないという工夫をすればいいだけですので、比較的簡単です。
　HTMLを作成するのにXML+XSLを使えばいいのです。
JavaのプログラムからXMLを吐き出させ、XSLを使ってHTMLに変換する。
XSLという静的なファイルをメンテナンスしてやるだけで、
Javaには一切触れることなくデータを見せないようにすることができます。
Java側には、
　ある画面を表示するにはどのXSLを使えばいいのか
の情報が書いてあるメタデータ(これも外部ファイル)を渡してやればいいようにしてやります。

表示するデータが増えた場合は、
データが減った場合と同様、XSLを改修する必要がありますが、
その元になるデータをストックして吐き出してくる場所…
即ち、データベース(DB)とその呼出のSQLをJavaの中に埋め込まないでおく必要があります。
Java側には、
　ある画面を表示するための元ネタとなるデータを拾うSQLはどれを使えばよいのか
のメタデータ(外部ファイル)を渡してやればよいようにしてやります。

◆入ってくるデータ
入ってくるデータは、Webの画面上に入力したデータの事を指します。
Webの画面から入力するデータは、出て行くデータと同様増えることも減ることもあります。

入力するデータが増えた場合、増えた分のデータが何かをJavaが知る必要があります。
しかし、Javaのコードを変えることなくJavaにその辺構文を知らせるには、
はやりここでもメタデータ(外部ファイル)を利用します。
　ある画面から入力されるデータは、これとあれとそれだよ
ということをメタデータに記録しておき、そのメタデータをJavaに渡してやるようにします。

入力したデータをストックしておかなければならない場合、
出て行くデータと同様、DBを利用することになります。
方法は、出て行くデータとまったく同じ方法になりますので、割愛します。

◆その他
出て行くデータと入ってくるデータだけが重要なデータというわけではなくて、
例えば、人によってコンテンツを見せる・見せないという選択が必要になることもあります。
そんな場合も、迷わずメタデータ(外部ファイル)を作成して、
Javaに渡してやることにします。

……………

こんな状態で、外だしにできるデータはすべて外出しにし、
Javaはデータを統合してコントロールするためのエンジンとしての役割をになわせることにした。
ただし、上記のパターンでは収まらない仕様の画面もあるだろうので、
　Javaの継承＆オーバーライドの機能を使ってしのいでくれ…
という遊びの部分は多少なりとも残しておく必要はあった。
Javaを採用できたから、こういう遊びが作れたのかもしれないけど…。

ともあれ、Javaを使って一人で牙城(？)をくみ上げ、
いろいろなすったもんだもあって火を噴かせてしまった(爆)ものの、
もう一人のJava使えるヒトも投入し、
メタデータ読み込みのオーバーヘッドを何とかチューニングし、
ついでに、コンマミリ秒単位のSQLのチューニングもして、
ようやく、プロジェクトは完了した…。

今も、このプロジェクトで作ったWebのシステムは、某企業で稼働中です…。
心配していた運用や改修も、なんとかできているようです…。

めでたし、めでたし。
…つーか、そのときのプロジェクトでたいそうなご迷惑をおかけしました。
非常に反省しております…。[参考：反省の内容と、所信表明]

…所信表明が実行できる状況になってないぞ…＞CAMUS

探し物をしていたら、
お目当てのものは見つからず、
それ以外の楽しげなものに目を奪われてしまい、
挙句の果てには遊んでしまおう♪
なんて思ってしまうこの浮気ゴゴロ、是如何に？(^^;)

私がRSSアグリゲータとして主に利用しているBloglinesが
なんとも不調な雰囲気が漂っている今日この頃、
そろそろ見切り時という言葉が頭をよぎったときに

　FEEDBRINGER

なんて似たようなサービスのα版がスタートしたとの情報が
Web界隈で踊っているではありませんか～♪

コレは是非是非チェックせねばと、早速登録してきましたよ。(笑)
ええ、仕事そっちのけで…。(さすが給料泥棒の会・会員)

FEEDBRINGERは、
　・RSSフィードの登録 (階層管理可能)
　・記事のクリップ機能 (タグ付き・メモ書きOK)
　・人気フィードの検索・共有
　・登録フィードのバックアップ・リストア
　・RSSフィードのメンテナンスが容易
あたりの機能と特徴があるようです。

それらの中でCAMUSがコレは便利かも♪などと思った部分について
ピックアップしてご紹介してみましょう。

■記事のクリップ機能

FEEDBRINGERで気になる記事が見つかった場合、
その記事をクリップしておくことができます。
そして、その記事に対してのメモも同時に残しておけます。
　(右の画像は、そのクリップの編集画面です)

このあたりはBloglinesでもできちゃうことなんですが、
さらに嬉しいのはそのメモにタグを付けることができること。
さらに、そのタグも複数つけることができるということ。
タグをつけられるということは、Doblogでいうところのジャンルわけができるということ。
そのタグで情報を振り分けることができるし、
タグから情報を見つけやすいということですよ。

クリップを山もりしてしまいがち(^^;)で、
あの情報どこいったっけ～なんて探してしまいがちなCAMUSにとっては、
かなり嬉しい機能であります。

■登録フィードのメンテナンスがしやすい
登録したフィードのメンテナンスがしやすいと思ったのは、以下のような点です。
　・登録フィードのバックアップ・リストアがしやすい
　・ドラッグアンドドロップでメンテナンス可能

登録フィードのバックアップ・リストアについては、
　OPMLインポート
　OPMLエクスポート
という機能がユーザから見えるところにリンクとしてついているので、
簡単ということです。(^^;)
OPMLというのは、そういう形式で作られたファイルなんだ、という認識でいいと思います。(^^;)
　OPML → [解りやすい(と思える)解説] [公式サイト]

リストアができるというのは、いいですね。
他のサービスからの移転がしやすいということです♪
ちなみに、Bloglines から移転する場合、Bloglines にログインした状態で
　http://www.bloglines.com/export
にアクセスすると、OPML形式のファイルがゲットできます。
それを一旦手元にダウンロードしてから、FEEDBRINGERにエクスポートしてやると
簡単にできました。(^^;)
　→ [BloglinesのOPMLゲットの情報源]

あと、登録したフィードを整理・整頓するときに、
　クリックする→何か入力などして体裁を整える
という方法だけでなく、
　ドラッグアンドドロップで好きな位置にフィードを移動する
という方法をとることができます。
ただ、CAMUSはどんくさいので、うまくドラッグアンドドロップができませんが。(爆)

【結び】
とまぁ、まだ使いはじめで使い倒す！までは行っていませんし、
α版も出たばかりのものですので、
どうなっていくのかを見ていきたいなーなんて思っています。

もし、気になる方がおられるようでしたら、
お試しでゲスト用のアカウントが用意されていますので、
遊んでみてはいかがでしょうか？

■FEEDBRINGER■
　http://feedbringer.net/
　・ゲストユーザアカウント guest
　・ゲストユーザパスワード feedbringer

【追記】 ◆2005/07/29
メニューの一部であるはずの「フィード追加」などが、
いちばーん下までスクロールしないと使えない
記事を読もうとしてどんどんスクロールしていくと、
左ペインのフィードのツリーがいなくなる
というUI(ユーザインターフェース・操作感覚って感じ？)の悪さが気になっていたのですが、
FireFox限定で解消されるようです♪

　Greasemonkeyプラグイン
　mizzy.org - feedbringerをremixin' #2

上記、先のプラグインをインストールした上で、
あとのリンクの記事に紹介されているユーザスクリプトをインストールすると
あら素敵なUIではありませぬか♪
ちょっと使う気が湧いてきました。(笑)

2005年6-7月度のCAMUS宛のコメント受付窓口はこちらです。

メイン・サブともブログを放置しています(汗)
結構仕事急がしなってきてしまいますた…困ったね
【CAMUSの生態】
├ ジャンルINDEX …当Blogの範囲
└ Doblogステータス …Doblog所属倶楽部など

【企画中！】
├ 数学倶楽部 数学好きなヒトよっといで！ 参加者11名！
├ 頭ソング同好会 頭の中でぐるぐる回る曲を教えて！ 参加者23名！
├ そふてくちゃんv あなたのソフトウェア奮闘記を是非TB！
├ 5月生まれのBloggerを募集 参加者36名！
└ 穴 …CAMUSにつきもの(笑)

【参加中】
├ cell computing βirthのdoblogチーム参加中！
├ ジョジョの奇妙などぶ部…シャボン玉担当って事で(笑)
├ どぶろぐ同期会・桃組…3月にDoblogに入会した人の会です
├ お遊び占い愛好会…なんか名誉会長になってます(汗)
├ 卍（万字）同好会では、あなたの１字を募集中
├ 給料泥棒の会で、給料泥棒にいそしんでいます。(？)
├ Doblog総合病院の病院web開発開発サポートやりまーす。
├ 地域リンク　関西、関西、関西に名前を連ねさせてもらってます。
├ 肩こり部…肩こりはながーい付き合いです。
└ ママ・パパりんく参加中です。

【CAMUSの1行日記(不定期)】
06/01 新人君ご挨拶…誰だ、「熱烈歓迎！」なんて中国ちっくな横断幕作ったやつは(笑)
06/06 サブタイトル変更 「－通算500記事達成－」
06/07 サブタイトル変更 「－おうちでぶびぶび かいしゃでじゃばじゃば－」
06/08 サブタイトル変更 「－おうちでぶび かいしゃでじゃば－」 Bloglinesの文字数制限が…orz
06/10 otologなるものを渦さまがやっておられたので、まねしんぼしてみる → [CAMUSの]
06/11 今日の笑いのツボ → [ロマンシングガイル]
06/21 小娘かぜっぴき…。
06/28 しばらく、お休みします。ゴメンネ。
06/30 誕生日リンク 7月 アンカー変更。たんたんたぬきさまごくろうさまです。
07/07 最近の笑いのツボ →[お絵かき弁当イロイロ]
07/08 どぶろぐ同期会は桃組さんに決定していたので、表示を変更。相変わらず、びみょーに多忙。orz
07/12 おまけでSTARWARSアイテムGetするも、どういうわけだかチューバッカばっか。なぜ？
07/21 サブタイトル変更 「－反省文 板書中－」 …変更前何かいてたっけ。(爆)
07/26 昨日からのツボ → [ブログバトラー] CAMUSはけちょんけちょんｗ

かわゆいバナーはcell computing βirth・Doblogチーム用に357さまが作ってくださったものです。
頑張れDoblogチーム♪

あへあへうへはぁ

過去のコメント受付窓口：
2004年3月度　2004年4月度　2004年5月度　2004年6-8月度　2004年9月度　2004年10月度
2004年11月度 2004年12月度 2005年1月度 2005年2月度 2005年3月度 2005年4月度
2005年5月度

2005/05/29にβ版がリリースとなったテクノラティジャパンが
6月に正式リリースとなって(なったんだよね？)、1ヶ月ほど経ちました。
はじめのうちは、何ができるんかなーなんて思ってぼけーっと見ていたんですが、
あらあら、なにやら便利な機能があったんですね…なんていまさらながら気がつき、
ちょいとレポートしてみるのでありました。

■テクノラティとは？
テクノラティは、Blog用の検索エンジンです。
今、話題になっていることは何か、話題の本は？ゲームは？などといった、
Blog回の動向を見ることもできます。
BlogNaviやURLランキングなども、同じような機能を持っていますよね。

さらには、お目当てのキーワードを登録しておくと、
そのキーワードをもとにBlogの記事をピックアップしてくれる、
という、便利な機能があります。
この辺は、GoogleアラートのBlog版といったところでしょうか。
勿論、検索精度や検索オプションなどはGoogleの足元にも及ばない…
というか、検索オプションが全然わからないので、検索がうまく使えていないのですが…。(^^;)
# つーか、オプションあるなら、教えて、えろい人。

Googleアラートでは、ピックアップした記事を電子メールで配信しますが、
テクノラティRSSで配信してくれます。
私にとっては、RSS配信してくれるほうが嬉しいかな。

■テクノラティに登録
そんなわけで、キーワードによるRSS配信をしてもらいたい人は、
テクノラティに登録してみましょう。
テクノラティに登録するには、
自分の氏名以外に自分の住所(会社とかでもいいと思いますが…)の郵便番号が必要です。
仮登録が完了すると、
本人確認のためのHTMLソースをBlogの記事に貼り付けるよう、要求されます。
いろんなブログツールからは嫌われる仕様のDoblogですが、コレは大丈夫。

例えば、CAMUSの場合は、↓のリンクを貼り付けることで登録完了できるとのこと。
テクノラティプロフィール

上記のリンクをBlogの記事に貼り付け、
さらにテクノラティからアクセスすることで、登録完了しました。

■テクノラティのウォッチリストを使ってみる

●いきなりウォッチリストに登録
「ウォッチリストに追加」にあるテキストボックスに、検索キーワードやURLを入力すると、そのキーワードやURLを含むBlogをピックアップしてくれるRSSFeedを作成してくれます。

例えば、CAMUSのBlogにリンクを張っているBlogをピックアップして欲しい場合、
　www.doblog.com/weblog/myblog/7562
　("http://"部分は省略できるようです)
というキーワードを登録しておくとよいようです。

あとは、テクノラティが生成してくれたRSSFeedを
自分の使っているRSSアグリゲータに食わせてやれば、
RSSアグリゲータが勝手に情報をゲットしてくれるのです。

●検索→検索結果表示状態からウォッチリストに登録
いろいろ検索した結果、継続してその検索結果(の動向)をWatchしたい場合、
その結果をそのままウォッチリストに登録できるようです。

●RSSアグリゲータに登録
右図に「www.doblog.com/weblog/myblog/7562」をキーワードにして作成したテクノラティのRSSFeedをRSSBanditに登録してみた結果をさらしてみました。(^^;)
検索キーワードに相当する部分をピックアップした状態で、
記事を拾ってくれるようです。

全体は見えないので、結局はそのBlogに訪れて
確認する必要はあるかもしれませんが…。(^^;)

■今後、こうあって欲しいなーなんて…徒然
●検索オプションを公開して欲しい
たぶん、検索オプションはいろいろあると思うんですよ。
「キーワードまたはURL」で、「日本語のブログ」「すべてのブログ」という選択肢がありますから、
これ以外にも、きっとあるはず！なんて勝手に期待しております。
もっと増えてくれると、検索効率がよくなっていいなぁ…と思うのですよ。

●検索対象のブログがもっと増えてくれるといいなぁ
登録しているところだけを拾っている…とは思ってはいないのですが、
まだ日本語のブログはそんなに蓄積されていないのかな、という気がします。
…まぁ、まだ日本で立ち上げてそんなに間が経っていないというのも理由かもしれませんが。

今後に期待！カナ？

ともあれ、しばらく使ってみます。(^^;)
どこの情報を使ってどんなふうに回っているのか、なぜこの情報が必要なのか、
などなど、よくわかってない状態で使っているんですが…。(危)

人に対して過度なマルチタスクを導入すると、人を壊すかもしれない　－前編：マルチタスク黎明期－
人に対して過度なマルチタスクを導入すると、人を壊すかもしれない　－中編：マルチタスク継続期－
の続きで、最終回です。

<<ダイジェスト>>
人に対して過度なマルチタスクを導入すると、どうなるかを、自己の事例を元に記述していくシリーズ。

前編では、時間の節約のため、家事をターゲットに、マルチタスクを試みていた時期のことを振り返ってみる。
　1．洗濯機を回すのは20時まで
　2．食事を食べ始めるのは19時までに
という制約のもと、2つのタスクを同時に、かつ、時間通りに行動するためのスケジュール方法と、タイムキーピングのための手法について、例を挙げて解説。

中編では、マルチタスクを実行するために必要な3つの技能
　1．記憶能力
　2．割り込み処理に対する処理能力
　3．リスケジューリング(再計画)
についての解説。
中編の最後に、上記の三つの技能を維持するための大切な技能があると書いた。
その大切な技能とは、ずばり、集中力である。

◆集中力が必要である理由
マルチタスク実行中は、マルチタスクの作業と同時に、
　1．記憶能力
　2．割り込み処理に対する処理能力
　3．リスケジューリング(再計画)
の3つの作業を脳内で行う必要がある。
単独でそれぞれの作業をする場合には、さほど集中力は必要ではないとしても、
同時に作業をする場合、それぞれの作業能力を落とさない and 維持するため、
集中力が必要になる。

集中力は、いろいろな技量や作業を繋げるための、
潤滑油の役割を果たしてくれているといっていいと思う。

◆集中力にも種類がある
上記の集中力が必要になる場面では、集中力の出し方に差が出ることがある。
例えば、マルチタスク中にリスケジューリングをする必要があった場合、
瞬時に作業を行う必要があるため、集中力にも瞬発力が要求される。
また、作業を行っている最中に、他の作業状況を忘れないようにするには、
集中力には持続力が要求される。

要は、集中力にも、陸上における「短距離選手」と「長距離選手」のような違いを
要求されるということである。
　短距離選手 = 瞬発力
　長距離選手 = 持久力(ペース配分能力付き)
という感じであろうか。

しかも、瞬発力と持久力をバランスよく配分した上で集中力の使い分けをしないと、
マルチタスクはうまく働かないことがある。

例えば、リスケジューリングの最中に本来のスケジュールの行動ポイントが来ているかを知るには、
本来のスケジュールがどう動いているのかを察知しておく必要がある。
前者には、集中力の瞬発性が必要であるが、後者には持久性が必要になるはずである。
この場合、重きをおくのは瞬発性ではあるが、
持久性を0にしていては行動ポイントを察知することができない、
ということになる。

◆集中力は用法・用量を守って正しくお使いくださいｗ
個人ごとに集中力の瞬発性と持久性には個性が出ると思われる。
個人の集中力にも短距離選手向きと長距離選手向きという「特性」があると思う。
長距離選手向きの集中力を出すのが得意である人に瞬発性を何度も求めると、
普段より疲労しやすくなると思う。

さらに、個人ごとに集中力の「持続力」も差があると思う。
ずーっと永遠に集中力を発揮していると、それはそれは疲弊すると思う。

自己の集中力の種類と、それぞれの持続力をあらかじめ知っておくと、
自分がどういう種類の作業に向いているのかの自己判断の材料になるであろう。

マルチタスクをするにも、
瞬発性を多く必要とするマルチタスクの方法と、
持久性を多く必要とするマルチタスクの方法があると思う。

自分の集中力の種類によって、
マルチタスクをする場合のスケジュール方法を変更する必要があるだろう。
集中力を切らせてしまったり、
無理に集中力を出さなければならないようなスケジュールであっては、
スケジュールを実行することができなくなってしまうからだ。

マルチタスクを実行する前に、
自己の集中力の種類や強度・耐久性などを超えない範囲で、
正しくスケジューリングすること。
　集中力は用法・用量を守って正しくお使いくださいｗ
ということを、胸に抱いて(？)、自身に合ったマルチタスクを見つけていただきたいと思う。

…ってか、別に集中力の種類によっては、
マルチタスクをしないほうがいいんですが。(^^;)

【結び…というか、私自身の反省点】
私自身は、日々の行動から、
　持久性のある集中力の持ち主
であると判断できる。
ただ、瞬発性がないかといえば、そうでもない。
何かトラブルが起こったとしても、比較的早急に対応したりすることはできている。
では、マルチタスクを実行するに当たって、何が問題であったかというと、
　持久力と瞬発力を同時に発揮することができない
という点ではなかろうか。

そんな集中力の持ち主が、あのスケジュールを1年近くも続けていたのでは、
体を壊すのも当然と言えば当然…なのかな、と思える。
先に私が例をあげた、洗濯と料理のマルチタスクのスケジュールは、
集中力の瞬発性も持久性も共に極端に必要になるスケジュールの組み方であったと
今になっても思うからだ。
ついでに言うと、家の作業だけではなく、会社でもかなりの集中力で仕事していたのも、
体を壊すことになった一因になっていると思う。
残業ができないので、昼休みを潰すことが非常に多かったので…。

そして、集中力の蓄電池を使いきり、充電が行えない現在、
私はどうしたらいいんでしょう？って感じの日々を過ごしております。(涙)
ちゅーワケで、現在、CAMUSはかなり壊れています。
修復予定はありません。復旧の見込みは立っておりません…。
ご迷惑をおかけしますが、今しばらく復旧の見込みが立つまでお待ちください…。

◆関連する記事
マルチタスクで人間の知力が低下する？--情報化時代のアイロニー By CNET Japan

人に対して過度なマルチタスクを導入すると、人を壊すかもしれない　－前編：マルチタスク黎明期－の続きです。
<<ダイジェスト>>
人に対して過度なマルチタスクを導入すると、どうなるかを、自己の事例を元に記述していくシリーズ。
まずは、マルチタスクのやり方から解説。

時間の節約のため、家事をターゲットに、マルチタスクを試みていた時期のことを振り返ってみる。
　1．洗濯機を回すのは20時まで
　2．食事を食べ始めるのは19時までに
という制約のもと、2つのタスクを同時に、かつ、時間通りに行動するためのスケジュール方法と、タイムキーピングのための手法について、例を挙げて解説。
前編では、どうやってマルチタスクを実行していたかを具体的に解説してみた。
今回は、このマルチタスクを実行しつづける際に必要な技量について、
徒然なるままに書いてみたいと思う。
# いきなり結論に持っていこうと思ったら、それは無理だと気が付いた…
# なんて、マヌケなことになっていたのはナイショにしておいてください。

マルチタスク用にスケジュールを立て、それを実行するために、
自分に課せられる「技量」がある。
それは、記憶能力と割り込み処理に対する処理能力、そしてリスケジューリング(再計画)である。

◆記憶能力
まずは、とにもかくにも記憶能力は必要である。
記憶能力は、
　・スケジュール
　・どこまで自分が実行したのか
を覚えておくために必要である。

そして、リスケジューリングが必要になった場合、過去のスケジュールを消去し、
現在どこまで実行したのかをリスケ後のスケジュールにマッピングする能力もここに含む。

なぜ、スケジュールを自分で記憶しておく必要があるか。
それは、スケジュールを確認する作業というものは、
かなりの時間を潰す要因になるからである。

なぜ、どこまで自分で実行したのかを自分で記憶しておく必要があるか。
それは、実行した内容をチェックする作業というものも、
それなりに時間を潰す要因になるからである。

実際、紙にスケジュールを書き、
それに対してどこまで実行したかをチェックしていくとすると、
具体的には、こういうことが起こる。

　1) 紙を確認するタイミングは、行動ポイントごとに付く確率が高い
　2) 紙を確認する時間は、確認したい点の前後を見る時間も必ず含まれる
　3) 紙にチェックを記入するタイミングは、行動ポイントごとになる
　4) 紙にチェックを記入する時間は、チェックを入れる場所を探索する時間も含まれる

それぞれの時間は秒単位のほんのわずかなのかもしれないが、
すべて合算すると、それなりに時間がかかっているものだ。

そして、この確認やチェックをする時間というのは、
元のスケジュールには含まれていないため、
スケジュールの遅延などを起こさないためには、
確認やチェックの時間を極力取らない、あるいは、一切取らない
ことが望ましいといえる。
記憶しておくということは、脳に負担をかけることではあるが、
時間の節約としてはかなり理想的な方法なのだ。

もし、確認やチェックの時間を取るのであれば、
確認やチェックの時間も盛り込むようリスケジューリングする事をオススメする。

◆割り込み処理に対する処理能力
スケジュール以外の処理が入らない、などのような理想的な環境であればよいが、
実際はそうはいかない。
　・訪問者関係
　・子供の相手
　・電話対応
のような、ランダムな割り込みがはいることは考慮しておかねばならない。

さらに、余分なタイムロスを防ぐために、
スケジュールに沿って、ランダムな割り込みの種類によってどう対応するか
をあらかじめシミュレーションしておく必要がある。

例えば、訪問者関係。
訪問者関係は、大きく2種類に分けることができる。
　・歓迎してよい訪問者
　・歓迎したくない訪問者
前者は、宅配や集金などが相当する。
後者は、訪問販売や勧誘員などが相当する。

前者の宅配を例にシミュレートしてみると、
　1) ピンポーン (インターホンがなる)
　2) インターホンに応答 (5秒程度)
　3) はんこを持って玄関へ (はんこの位置と現在地との関係によりかかる時間が変わる)
　4) 荷物受け取り応答 (1分程度)
　5) 元の位置に戻る
の順で、こなせばよい。

それぞれのポイントでの対応時台詞も、標準化しておくと、
考えなくてよいので楽だ。
例えば、インターほんの対応などは「はい」「お待ちください」の2点セットでよい。

　(ピンポーン)
　私　「はい」
　相手「宅配便でーす。○○からのお届けです」
　私　「お待ちください」

また、はんこのセッティング位置は、玄関のすぐ近くなど、
余分な導線を取らない位置に決めておくと、
スムーズにことは運ぶ。

後者の訪問販売を例にシミュレートすると、
　1) ピンポーン(インターホンがなる)
　2) インターホン応答
これだけで終わらせるように持っていくようにスケジュールを立て、
そのスケジュール通り終わらせるには、インターホン応答に工夫をする。
# 工夫というまでもないけど…。

　(ピンポーン)
　私　「はい」
　相手「私、このへんで○○をやっている…」
　私　(話をさえぎり)「ご用件は？」
　相手「あ、すみません。○○について…」
　私　(キーワードが聞こえた時点で)「結構です」
　(がちゃんｗ)

ともかく、早急に用件を聞き出し、用件のキーワードが見えた時点で断り、
即、インターホンを切る。
新聞屋の場合、「○○新聞ですが…」とはじめの時点で切り出してくれることが多いので、
その時点で、即「結構です」が言えるので楽だ。(^^;)

と、このように、思いつく限りの事象について、時間のロスを最小限にするようシミュレートしておく。
優先順位の基本は、マルチタスクを実行している「スケジュール」なのだから。

本番は、そのシミュレートどおりに行動すればよい。
大概、うまくいくし、うまくいかなければシミュレートしなおせばよい。

ただ、シミュレートしなければならない事項はかなり多く、
一つの事項に対していくつかのパターンを用意しておかなければならない。
場合によっては、シミュレート対象の事項を減らす努力もしなければならなくなる。
# 例えば、契約している新聞社にお願いして、
# 他の新聞の勧誘がこないようお願いするとか…。

余談。
一番困った事象は、これだったりするのだが…。(^^;)
こうなると、腹を括ってキッチンタイマー、火の元を消して、
事後処理にいそしむのです。

◆リスケジューリング(再計画)
要は、計画の練り直しである。
計画を練り直さなければならない時期というのは2種類ある。
　・割り込み処理が入った場合
　・料理の種類が変わった場合
前者は、その場で早急に行わねばならないリスケジューリング、
後者は、毎日、献立が決まったら行うスケジューリングである。

前者は、先ほどの割り込みが入ったときに、行う必要が出てくる可能性がある。
割り込みの内容によっては、リスケが必要でない場合もあるが、
さすがに痛い話や臭い話になった場合には、
キッチンタイマーや火の元を閉めるようなスケジュール外の行動が必要になり、
リスケが必要になる。

スケジュール実行中にリスケをする必要があると、優先順位を変更するなどして、
瞬時に元の目的を遂行するになるべく近い状況になるよう、
脳内で組換えを行う。
場合によっては、リスケしながら、作業を行うこともザラにある。
場合によっては、スケジュール内容をごっそり捨て去り、
全く違うスケジュールを立てるだけの切り替えも必要になる。
リスケジューリングは、比較的コストの高い作業である。

後者は、いつ献立を決めるかによって、スケジューリングするタイミングが変わる。
前者に比べると非常にゆったりしているように見えるが、
献立を立てるタイミングが帰宅時の買い物時であった場合、
買い物時間が長くなると、帰宅してからのスケジューリングが大変になるため、
かなり焦る状況下で献立を考えつつ、スケジューリングしなければならなくなる。
…献立を考える時間は気をつけないと、
全体を見通した場合に以外にコスト高なのである。

【中編の結び】
今回は、マルチタスクを実行するのに、必要な技量の紹介をした。
　・記憶能力
　・割り込み処理に対する処理能力
　・リスケジューリング(再計画)
それぞれ、比較的、自己に負荷のかかりやすい作業だということが、
おわかりいただければ幸いである。

これらの技量なくしては、マルチタスクはなりえないが、
これらの技量を維持するための、もう一つの大切な技量がある。
次回は多分最終回の予定なのだが、その大切な技量について解説したいと思う。
…って、長すぎだから。(>_<) ＞CAMUS

◆関連する記事
マルチタスクで人間の知力が低下する？--情報化時代のアイロニー By CNET Japan

マルチタスクは、時間を節約するために使う方式と言っていいだろう。
少しの時間の隙も許さず、前倒し、前倒しに作業を進めていく。

しかし、それを突き詰めていくと、その場の作業効率はよくはなるかもしれないが、
作業効率をよくするためのスケジュールを立てる時間を別途確保する必要があり、
作業が完了した時点では、通常の何倍も疲労がたまる。

結局、その場の作業効率をよくしようとして、
全体を見ると、膨大な時間の無駄を費やしている。
そして、必要以上に疲労する。

…人に対して過度なマルチタスクを導入すると、人を壊すかもしれない。
そう思ったのは、自分の体の調子が悪いと感じ始めてからのことだった。

そう感じ始めた具体的な時期は、白血病だと診断される少し前のこと。
そして、咳が止まらなくてかかった医者に「喘息」と診断された、少し後のこと。

その頃の私は、とにかく時間が欲しくて、焦っていた。
　子供と触れ合う時間を多くとりたい。
　家で仕事の準備の時間をとりたい。
そういう思いから、なるべく家で家事をする時間をとにかく早めに切り上げようと、
考えうる限りの努力をしていた。

努力とは、まず、タイムキーピング。
そして、マルチタスク。

◆タイムキーピング
時間を区切ってここまでに完了する！という目標を決めておく。
具体的に言うと、例えば
　1．洗濯機を回すのは20時まで
　2．食事を食べ始めるのは19時までに
と決めることである。
すると、それにあわせて、どういう行動をとればいいか、
事細かにスケジューリングしなければならなくなる。

1．の例から、事細かにスケジューリングしていくと、こんな具合になる。
00:00 (この時間を基準とする) 帰宅 → 帰宅直後の後始末(着替えとか)
00:05 風呂場から洗濯機に残り水のくみ上げ
00:07 洗濯対象物の選別
00:10 風呂場の残り水くみ上げ完了→洗濯機起動→干していた洗濯物を取り込む
00:15 干していた洗濯物の取り込み完了
00:25 1回目すすぎ：風呂場から残り水のくみ上げ2回目
00:30 風呂場の残り水くみ上げ完了→1回目すすぎ
00:50 洗濯完了 → 洗濯物を干す
01:00 洗濯物干し完了

帰宅してから、洗濯物を洗い、干し終わるまでに1時間程度で済むことがわかる。
帰宅時間が18：30ごろであれば、19：30には終わる算段である。
余裕はある。

しかし、実際には、
2．の「食事を食べ始めるのは19時までに」というタスクも割り込んでくるので、
上記のスケジュールどおりにはことは進まない。
そこで、マルチタスク作業が発生する。

◆マルチタスク
時間を有効に使おうという手口。
その精神は、少しの隙間も許さない、そんな感じ。
その隙間を作らない、あるいは効率よく隙間を認識するためには、
このようなことに気をつける。
　a．時間をおく必要があるが、完了までは放っておけばいいことは先にやる
　b．タスクの完了を知らせる手立てを作る
先の洗濯の例で行くと、以下の部分には隙間時間ができていることになる。

　・風呂場から洗濯機への水のくみ上げ中
　→ お湯取りホースを使えば、自動的にくみ上げが可能
　・乾いている洗濯物の取り込み後から、1回目すすぎ時のくみ上げまでの間
　・1回目のすすぎ以�