生データを直接扱えるようになるメリットは何なのだろう?

by tanabe on June 30, 2005

ma.laさんの「XMLはメタデータというより生データとしての利用価値が高まりつつあり、AjaxによるUIの切り離しがそれを加速する」
http://la.ma.la/blog/diary_200506291043.htm

を読みながら、提供された生データと「最強に強まったユーザーインターフェース」がユーザーにもたらす価値を考えていたら、頭がモウロウとしてきた。

ウェブサービスはあらゆる情報をXMLで提供し、ユーザーはそれを自分の好きな形にレンダリングして表示するようになる。
AjaxはつまるところXMLビジュアライザーであり、ユーザーインターフェースの交換装置なのである。今すぐ急いでAjaxに対応、などする必要はない。APIを公開して生データにアクセスできるように開放することと、Ajaxに対応することは実は殆ど同じである。

この部分に特に強く共感する。なので、特にこの点を中心に疑問を挙げ、考えていた。

「ウェブサービスがあらゆる情報をXMLで提供」することで、ウェブのスケーラビリティを享受するのはどんなケースか?

「ユーザーが自分の好きな形にレンダリングして表示」することが可能になることで、ユーザーとサービス事業者の関係はどう変わるのか?

現状のインターネットで一番利益へ直結する「広告」というものは、データ提供者の利益へ貢献するのか、それとも表示側が主導権を握るのか?

それから、今のWebの姿がどこまでこの「生データとその見た目」という世界へと移っていくのか。すべてがそうなるのか、何かは現在のような姿を留めるのか。留めるとすれば、その境となるのは何なのか?

 

けっきょく、この話はREMIXの話の一部なのか、それともさらにWebのレベルでスケールするような可能性を秘めた何かの上辺なのか、それが今ひとつ判別がついていない。

ただ、ふと思ったのは、よりうまく提供されたXMLを利用できる環境が整えば、del.icio.usもはてなブックマークもどちらもデータ提供者として(もしくはWeb上にある巨大なデータベースとみなして)、アプリケーションレベルの処理を専門に扱うような存在が出てくると、また一つスケーラビリティの面で面白みが出るのかもしれないということだ。

データ(コンテンツ)、ファンクション、そしてビューという役割が生まれてくるのかな、という予想(という名の妄想)である。ただのMVCじゃんと言われるのは、まぁ、仕方ない。それでも、それがWebのサイズでスケールすると何かが起きるのか?あるいは何が起こせるのか?と考えるのはとても面白いと思う。

  

「RawDataとブラウザの世界」が見えますか?

by tanabe on June 29, 2005

ぼくは見えた気になって騒いでみたけど、言語化できてなかったし、具体的には 言及できなかった話。力不足を実感すると共に、そんなのちっぽけに見えるくらい、 ブログで情報を追うのがエキサイティングに感じる瞬間だ。

先日、ぼくはdel.icio.us direc.torについて、

そうか。Web Serviceの時代にはサービス提供者はエンジンであり、プラットフォー ムであり、データ保有者という役割になるのか!と無駄に未来絵図が浮かんでしまう ほどの衝撃だった。

と書いたのだけど、それよりもよっぽど端的に具体的に語られているのが、ma.la 氏のエントリ。

これは必読。

XMLはメタデータというより生データとしての利用価値が高まりつつあり、Ajaxに よるUIの切り離しがそれを加速する
http://la.ma.la/blog/diary_200506291043.htm

詳しいことは、帰宅後に書きます。

  

タイムマネジメントを考える(1)

by tanabe on June 29, 2005

 梅田さんのMy Life Between Silicon Valley and Japanでも言われていたが、タイムマネジメントは非常に重要な課題だ。

「The New Normal」時代の成功はすべてタイムマネジメントにかかっている。この時代の通貨は時間なのである。

ロジャー・マクナミーの講演「The New Normal - Career, Family & Personal Finance」を読む

たしかに学生時代にはあれほど呆れるくらいにあまっていた時間が、今はウソのように足りない。仕事をする、BloglinesでRSS Feedを読む、ブログを書く、移動する(兼・読書)、食べる、寝る、そしてそれぞれをしながら音楽を聴く。これで一日が終わってしまい、一週間はこの積み重ねで終わってしまう。

どうも、よろしくない。本当に大切なものに時間を費やせていないような危機感があるのだ。

 

 ということで、最近読んだ中からタイムマネジメントに関わる話、そしてタイムマネジメントを行うにあたって、事前にはっきりさせておくべき話をメモしておく。

DIAMOND ハーバード・ビジネス・レビューの2005年7月号から。

Harvard Business Review (ハーバード・ビジネス・レビュー) 07月号 [雑誌]

コミットメントの自己管理術 − Do Your Commitments Match Your Convictions? −

 だれにでも大切なものがある。たとえば、仕事、私生活、家計などだ。しかし、あらためて自分の日常を見てみると、いちばん大切なことと、現実に金銭や時間、労力を費やしていることが食い違ってはいまいか。

この冒頭の文だけで、どきっとする人は多いだろう。まさにこれがこの記事のテーマとなっている。ただし、コミットメントすべきことに優劣をつけるという記事ではない。

コミットメントの対象が何であれ、個人的なコミットメントの自己管理を改善されることが、我々の願いなのである。

最初のテーマは「私生活上のコミットメントとは何か」だ。この答えは明快である。

日常的に最も重要なコミットメントとは、金と時間と労力をどのように配分するのかというものだ。どれも小さな意思決定であるため、ついなおざりにしがちである。とはいえ、積もり積もると、大切なことと実践していることとのギャップはますます広がりかねない。

 

 ここから、コミットメントを自己管理する具体的な方法の説明に入る。

 コミットメントを自己管理する第一ステップは、自分にとって重要なことを総棚卸してみることである。
 最も大切なことは何か、だれもが漠然と思い描いているはずだが、時にははっきりさせることが必要である。その結果、金、時間、労力を本当に大切なことに費やしているかどうかをチェックすることができる。

4列のワークシートを作成し、各列の項目はそれぞれ「私にとって大切なこと」「金」「時間」「労力」とする。

「私にとって大切なこと」へ記入していく際の注意点は以下とおり。

  • なるべく具体的な言葉で書くこと。「子ども」よりも、「教養と道徳観を忘れない子どもに育てる」や「子どもと一緒に楽しく過ごす」など。つまり、そこに込める価値観をより詳細に言語化する。
  • とりあえず手を動かし、納得が行くまで何度でも書き直す。
  • 5〜10の項目を挙げる、あるいは絞る。
  • 善悪や是非を考えず、まずは正直に自分にとって大切なことを書き出す。

 

 そして、次のステップだ。

 第二ステップでは、左端に書き出した項目に、実際のところ、どれくらいコミットメントを傾けているかについて詳しく検討する。

 この作業に具体的に取り組むに当たっては、まず日常的に消費している金、時間、労力が、自分の価値観と一致しているかどうかを検討する。

「金」「時間」のそれぞれについて、リストアップした「私にとって大切なこと」に対して費やされた項目を挙げていく。さらに第三のステップとしてその全体に占める割合を「金」「時間」いついて書き出す。

「労力」は、「私にとって大切なこと」の中で最も高い集中力を傾けていることについて”+”を、最も集中できていない項目に”−”を記入する。

これらのステップを実行するにあたって重要なのは、極力事実に基づいた数値を使うことだ。記憶を頼りにしてしまうと、「こうだったらいいのにな。」という恣意が入り込みがちである。

そして、ワークシートが完成したら、

 ワークシートが完成したら、最後に大切なことと資源の配分方法が一致しているかどうか、公正に分析する。
 肝心なのは、大きなギャップを見つけ出すことである。

時と共にコミットメントと信念の間にギャップが生じ、拡大していく可能性もある。このようなギャップの原因を突き止められれば、いたずらに拡大するのを防ぐことができる。

ここでは、主なギャップの原因を抜粋しておこう。

  • 大切だが、金などを費やす気にならない
  • 過去のコミットメントが足かせになっている
  • 「忍び寄るコミットメント」の罠にはまる
  • 他人からの期待が依存へと変質する

「忍び寄るコミットメント」については、少々説明を加えておこう。

人はしばしば、自分が何を引き受けようとしているのか、じっくり考えないままコミットメントを傾けてしまう。
 言外の約束を果たさなければならない、あるいは現在コミットメントを傾けている課題との間にあつれきが生じうるといった代償について深く考えることなく、気軽に新たな課題へコミットメントを傾ける。したがって、たくさんのチャンスに恵まれた人たちは、コミットメントのオーバーフローという悩みを抱えることになる。

 

 ここまでで、分析の大枠は整っている。ただ、実はこの後が難しい。

自分の価値観を見出すのは比較的簡単だが、価値観と現実のギャップを分析するのは案外難しく、ギャップの理由を分析するのはさらに困難であることに気づく。しかし、最も難しいのは、ギャップを埋めるために何をするかである。

HBRの本文にはこの困難を克服するための注意が細かく指摘されている。コミットメント再考時の落とし穴などは参考になるだろう。

ちなみに、コミットメントの見直しを強く迫られるのは、危機に直面したとき、だそうである。そういえば、Steve Jobsも「人の時間には限りがある。だから他人の人生を生きて時間を無駄にするな」と語っていた。これは自身の膵臓ガンの体験から得た教訓だったようだ。

 

この管理術を参考にすることには大きなメリットが二つある。

一つめは、タイムマネジメントへ入る前に、「時間を金で買う」あるいは「労力を金で買って時間をつくる」という選択肢を広げておくことができることだ。金は増やすことが可能だが、時間はそうはいかない。

そして、タイムマネジメントをするにあたって、その目的をよりはっきりさせることができる。「時間を適切に配分する」という場合の、「適切」が何を意味するのか、それを吟味することができる。

「己の価値観と行動のギャップを管理する」という考え方は、これまで以上に重要なものとなるだろう。

  

ベルカ、読了。

by tanabe on June 29, 2005

先日、紹介した「ベルカ、吠えないのか?」を読み終わりました。

非常に味のある、いい小説でした。走り続けるイヌたちに負けないくらいの疾走感が文章に溢れています。

まぁ、ニンゲンの言葉で表現するのも無粋な気がするので、ぜひ体感してみてください。

アマゾンのステータスが、前回紹介時の品切れからユーズドのみの取扱いになってますね。ぼくの買った近所の本屋のように、今ならまだ置いているところもあると思うので、よかったら探して読んでみてください。この本には、文庫よりもこの重厚な装丁と厚みが似合います。

  

飽きちゃったそうです。

by tanabe on June 28, 2005

吹いた。最高だと思う。

http://d.hatena.ne.jp/umedamochio/20050627/p1

同世代以上の当事者たちと腹を割って話せば、最後にはいつも現実的な「逃げ切り」論になる。「自分の年齢くらいまでは、ギリギリ逃げ切れるんじゃないかと思うが、どうかな」的な議論だ。僕も何かの拍子で日本企業に勤め続けていたとしたら、今頃そういう計算をしているだろうと思うから、その感覚はとてもよくわかる。それも立派なサバイバル戦略だ。ただ、もうそういう話は飽きちゃった!

ここ数日の議論を眺めながら、「正直、生き延びたいんじゃなくて、ビジネス自体が好きだし、今一番面白いから、刺激的なことをしたいだけなんだよなー。300万か1000万かはどうでもいいや。」と思って読んでいたので、理解はできるけどピンとは来なかった。

今日、この文章にはピンと来た。そう、そういう梅田さんが好きなのです。飽きちゃったんだもの、しょうがない。

  

右も左もわかりませんが、トラックバック。

by tanabe on June 27, 2005

codemaniaxさんの「右と左」の話へトラックバック。

http://d.hatena.ne.jp/codemaniax/20050626/1119776208

そもそも給料をもらってるくせに「右も左も分かりません」と言ってのける、そしてそれを可愛がるという神経がおいらには分からない。

だけど、自分が給料をもらっていることを忘れちゃいけない。誰に対して価値を提供して給料をもらっているのか。

本音を言うと、まったく同感なわけですよ。それがプロの心意気ってもんだと思うし。

でも、実際には「右も左も分かりません」と言う新人が可愛がられるのだ。

ただ、その上で現実を見ると違うんであれば、あざとく「右も左もわかりませんが」って言っておけばいいとも思うわけです。

なぜかというと、それが一番万人にアピールできるから。

「右も左も」を受け入れる人は、その一言で「よし、いっちょオレがもんでやろう!」と思ってくれるわけだし、受け入れない人は、どうせ実務に入って実力示すのが、認めてもらう一番手っ取り早い道になるんですよね。口で言っても信じないから、そういう人は。(その方が正しい姿勢だと思うけど)

可愛がってもらうという姿勢がそもそも甘い!って意見もあるでしょうが、誰からもスキルを盗み、しかも仕事でやりたいことを通そうとする場合は、誰かれなく可愛がってもらっておいた方がいいというのは現実です。正論だけ吐いていれば会議本番だけで物ごとをひっくり返せるのはマンガだけ。どんな会議も根回しは重要です。そして、誰だって自分が可愛い人の意見をサポートしたくなるのが人情です。

顧客に一番価値を提供するため(しやすい状況を作るため)に、本当に許せないような人でなければ、とりあえず可愛がられておくのはプロフェッショナルに反しない。そう思うわけです。

口で「右も左も」と言って、本当に右も左もわからん状態だと話にならないわけですが、確信犯的に利用してやんのはそれはそれでオトナな対応かなぁ、と。汚れた発想でしょうか?

 

あ、面接の場とかで言っちゃう人は明らかにNGですけど。適材適所で使いわけです。(いや、それでも20代の中盤くらいだと、まだまだそういうカマトトぶった態度の方がウケが良いことはたしかにあるみたいだからなぁ。。)

* 確信犯はあえて誤用。わかってはいるけど、便利な言い回しなもので。
* 右も左もわからなくてもそういう部署にまわしちゃうという日本企業の文化的問題が根っこにある、というのは別の話ですが当然の前提。

  

del.icio.us上のキラーアプリ:DEL.ICIO.US DIREC.TOR !

by tanabe on June 27, 2005

ソーシャルブックマーク(というか、特にはてなブックマーク)が流行りだしてから、どこも紹介記事(百式さん的なやつ。あるいはネタフルさん的なやつ。)が減り傾向な気がする。

庶民派なうちとしても世間様と歩調を合わせて来たわけですが、これはあまりに美しいので紹介。

DEL.ICIO.US DIREC.TOR

どうやって使うの?

ブラウザの制限上、あなたはJavascript bookmarkletから呼び出して使用することになります。以下のステップで使ってね。

  1. このリンクからブックマークレットを作成する。
    del.icio.us direc.tor
  2. どこでもいいので、del.icio.us のどっかのページへ移動。
  3. そのdel.icio.usのページ上で、ブックマークレットを起動する。
  4. ログインプロンプトが出てきたら、ログインする。
    (del.icio.usのアカウントを持っていない人はデモで試用可能。)
  5. 検索ボックスへ文字を入力するか、タグをクリックする。列のヘッダをクリックするとソート。

注意:動作はFirefoxかIEのみ。SafariはJavascriptからのXSLT使用をサポートしてないから動かないよ。

(超適当訳)

これは本当にすごい。呼び出しにやや時間がかかるけど、一度読み込んだら感動的な操作性を体験できる。

何がうれしいって、コメントの日本語も完璧に拾って検索結果を出してくれること。これで、del.icio.usの一番の弱点がカバーされてしまった。しかも、これまた気持ち良い反応速度。del.icio.usというプラットフォームの上に最高のキラーアプリが登場したといっていいと思う。

そうか。Web Serviceの時代にはサービス提供者はエンジンであり、プラットフォームであり、データ保有者という役割になるのか!と無駄に未来絵図が浮かんでしまうほどの衝撃だった。

  

「すごい会議」の本質を読み解く。

by tanabe on June 24, 2005

すっかり大橋禅太郎氏の「すごい会議」にやられてしまった。

タイトルに騙されずに読み解けば、この本の本質は会議のハウツー本ではなく、マネジメントのフローを作ることにあるのがわかる。実践するマネジメントを会議によりドライブするのだ。

問題解決の方法には他にも有力なアプローチがある。当初仮説からスタートし、ファクトベース、MECEといったツールで問題を掘り下げるいわゆるマッキンゼー方式は有名だ。ただ、現実に企業で適用することを考えたとき、中々周囲の人間との折合いが難しかったりもする。特に事実を重視して問題を解決していく文化がない場合は障害も多い。また、日々現われる課題の一つ一つを徹底的に分析しきるのは物理的に困難だ。

そういった実情を踏まえて、「じゃあ、現実的にどうやって組織で問題へ立ち向かうか?」という重要な答えの一つがこの「すごい会議」には書かれている。

その基本信念は「成果の出ない会議は無意味であり、目の前の課題をマネージするのに必要ないことをやるのは無駄だ」という考えだろう。

これを、「それじゃあ、どうやったらすべての会議で成果を出していくことができるか?」と考えた結果が「すごい会議」なのだ。

だから、すごい会議を本の手順で徹底してやれば、必ず成果に結びつくようになっている。そして、その成果は会議室を出たらすぐにアクションへ移せるレベルへと詳細化されている。

会議自体がマネジメントの一環であり、会議を通して問題をマネージしていく。だから、会議そのものが成果になってしまう。これが、すごい会議マジックだ。

ここを見誤って、「会議を上手に運営するためのツール」を探してしまうと、いまいち本の価値がわからないかもしれない。この本は、その前提となる会議の意義を問い、覆すものだからだ。そんな人は、あなたがツールを探しているような「会議」は何をアウトプットするのか、それをもう一度考えると本質へ近づけるかもしれない。

すごい会議−短期間で会社が劇的に変わる!

私は「問題を解決する場」としての会議はあまり評価していない。しかし、このマネジメントの役に立たない会議をやるのは無駄なので、いっそ会議自体をマネジメントの一環にしてしまおうというアプローチには非常に共感する。

Amazonの書評で不評が目立ち、かなり不本意だったので援護射撃をしてみた次第。

  

はてなのかつてなさに期待

by tanabe on June 24, 2005

はてな・近藤氏の「社内会議を音声で公開する」を読んで。

こんな普通の神経の企業では絶対にあり得ないことをやれてしまえるところは、もちろんはてなのすごさなんだけど、それ以上にこれだけ「自分たちは愛される」と消費者に対して信念を持って動ける企業っていうのは物凄い希少種なのだと思う。

そして、今のところは現実にもこのようにはてなloverはネット界隈に増殖しているわけだ。このかつてない「見えない資産」を抱えた企業が起こせるムーブメントはきっと従来の常識では測れないものになると思う。

そういうはてなの”かつてなさ”には大いに期待している。(サービスはあまりメインで使っていないけど)

  

Googleの起こしたい「知の創出」

by tanabe on June 23, 2005

ひさしぶりに梅田さんのところからネタを持ってきてみる。

"My Life Between Silicon Valley and Japan"の『「知の創出」のコモディティ化への戸惑い』を読んで思ったこと。

「対人能力は陳腐化しないよね」と僕は「これからの10年飲み会」の冒頭で話したが、そのときにイメージした「対人能力」のベースっていうのは、Ringo氏の言葉である「人間に対する興味」と全く同義だ。それさえあれば「対人能力」は場数を踏んでいくと、どんどん磨かれていく。

という考えと比較して、Googleのそういったウェットな能力への思いが書かれている。

今のグーグルの技術陣ってのは、「対人能力なんてものは要らんのだ、頭さえよければ」というタイプのハッカーにとっての「最後の楽園」という感じがする。だから世界中から入社希望者の列ができているのではないか。グーグルが「狭き門」化していて、グーグルに入れなかったハッカーたちが「グーグルしか行きたいところないんだよなぁ」と言っている姿を見ると、これは何かを象徴しているのかもしれないなぁ、なんて思ったりする。

うーん、Googleって「対人能力は陳腐化しない」を百も承知で、「だからこそ、そいつを覆したらとんでもないパラダイムシフトを引き起こせるだろ?」っていう悪戯心があるのだとずっと(勝手に)思っていたのだけど、違うんだろうか?

この信念があるから、あれだけ偏執的に技術で全てを変えられるという世界を突っ走れるのだと思っているんだけど。

あれ、それともそういう前提で、それでもそう考えているのはGoogleだけしか今はいないよね、っていう話なのかな?

ちょっと時間がないので、理由を説明するような資料やインタビューを探せない。不本意だけどここでエントリ。

  

今さら、Firefox

by tanabe on June 22, 2005

昨日、すごいことに気付いた。

すごい便利なのだが、たぶん知らなかったのは自分だけなのだろう。というFirefoxの機能だ。

「リンクを新しいタブで開く」って、中ボタンのクリック(ホイールクリック)でできたんですね。

今まで一生懸命、Ctrl+左クリックとかしていたよ。

すごいよ、Firefox!(かなり今さら)

  

失礼しました。

by tanabe on June 22, 2005

そして、すっかりエントリしてから気付く。

http://d.hatena.ne.jp/kenyam/20050619/1119174408

さてさて、酔っ払っているので駄文御免。そして、友人からMusical Batonをもらったのだが、次に送る5人をどうするかね。

kenyamの日記:wah-wah pedalさんは受け取り済み!

大変失礼しました。

 

けっきょくただの「あなたのファンです」宣言になってしまった。恥ずい。

  

musical batonです。よかったら、音楽観を聞かせてください。

by tanabe on June 22, 2005

各所のmusical batonを見ていて思ったんですが、DEPAPEPE挙げている人多すぎ。そんなにいいのか。聴いてみようかな。

さて、musical batonのQAを書いたときに宿題で残したバトンの渡し先なのですが、この方たちで行ってみたいと思います。

一部の方を除いて、一回TBしただけだったり、まったくこれまで接点がなかったりした方ばかりなのですが、個人的に非常に好きなブログばかりで、勝手にROMっております。

よかったら、musical batonを受け取ってください。

musical batonの説明はこちら↓。

http://d.hatena.ne.jp/keyword/Musical%20Baton

ただ、基本的にはスパムなので、気に入らなければあっさりとスルーしてくださいませ。

  • "さんごハウス@東京"のようこさん
    http://blog.livedoor.jp/mimizun/
    ・・・大昔に写真がとても素敵なブログとしてTBさせて頂きました。今でもこっそり覗いてます。
  • "kenyamの日記:wah-wah pedal"の山路 憲さん
    http://d.hatena.ne.jp/kenyam/
    ・・・livedoor住いのときからROMってました。考え方とかとても好きです。この方もいつのまにやら本名になってました。
  • "東京奇文"のprince_of_curryさん
    http://bullshit.exblog.jp/
    ・・・(ぼくの中では)言わずと知れた東京奇文さん。なぜか職場で開くと制限に引っかかってNGになるブログ。bullshitがいけないんだろうか。
  • "さかなの寝言。"のま。さん
    http://hurdy-gurdy.air-nifty.com/tsukinouo/
    ・・・やっぱりZEPPET STOREファンの意見は聞いてみたいってことで。絶対にどこかのライブですれ違っていたはずな方。
  • "OMOIDE IN MY HEAD"のリコシェさん
    http://nowhere.jugem.cc/
    ・・・やっぱりnumber girlファンの意見は聞いてみたいってことで。無戒&Mr.曽我部氏のライブですれ違ってそうな方。

※ メールの宛先が分からなかった方には最新エントリへスパムトラバしてます。ごめんなさい。

  

* musical baton *

by tanabe on June 21, 2005

* Total volume of music files on my computer (コンピュータに入ってる音楽ファイルの容量)

600MBくらい。CD派なので。さらにiPodじゃなくて、MDユーザーなので。

* Song playing right now (今聞いている曲)

MATSURI SESSION AT OSAKA / ZAZEN BOYS

http://www.mukaishutoku.com/at_osaka_.html

* The last CD I bought (最後に買ったCD)

And All That Could Have Been

AND ALL THAT COULD HAVE BEEN. / NINE INCH NAILS. LIVE

With Teeth

[WITH_TEETH] / NINE INCH NAILS

* Five songs(tunes) I listen to a lot, or that mean a lot to me (よく聞く、または特別な思い入れのある5曲)

THE YELLOW MONKEY メカラ ウロコ・7 "SUBJECTIVE LATE SHOW"

メカラウロコ7

やっぱりTHE YELLOW MONKEYの真実はライブにしかない。
良くも悪くもこれほどライブとCDの違いが際立つバンドは見たことがない。
このSUBJECTIVE LATE SHOWの本当の姿を見るためには、メカラ ウロコ・7を頭から全部見て欲しい。
はっきり言って、CDで聴くとそれほどでもない曲が完全に化ける所を目の当たりにできる。
そこには間違いなくライブでしか生まれない”何か”が存在している。
歓びと生命力に満ちた最高のライブパフォーマンス。

ZEPPET STORE "LOOP"

LOOP

ここのURLにも使っているmost favorite album "716"とのデッドヒートの末、LOOPという曲にしてみた。

このLOOPは、ZEPPETらしい美しいコードを使いながらも疾走感溢れる曲になっていて、ライブ映えがする曲。"LOOP"の入っているシングルには他にもTHE GAMEやFLY HIGHというアップテンポの跳ね系の曲が詰まっていて、ZEPPETが現在のROCK ZEPPETへと変貌するきっかけになったシングルだと思う。

number girl "EIGHT BEATER" from "シブヤROCKTRANSFORMED状態"

シブヤROCKTRANSFORMED状態

我起立唯我一人やomoide in my head、それから後期の他の曲たちも散々迷ったけど、これ。

今のZAZENへと至る「よみがえる性的衝動 繰りかえされる諸行無常」のフレーズの魅力もさることながら、色々な時代のnumber girlの良さが満遍なくかんじられる、まさにnumber girlらしい曲だと思う。ちょうどその変化の過程の時期としては、このライブアルバム自体もとてもすばらしいタイミングのnumber girlを切り取っている。

くるり "ワンダーフォーゲル" from "TEAM ROCK"

TEAM ROCK

みんな大好きワンダーフォーゲル。向井秀徳も好き。いしのだなつよも好き。ぼくも好き。

最初の音が鳴り出してから、最後の音が消えていくまで、全部の瞬間が愛しい曲。
もうどうしようもなく参ってしまったときに、たった一人世間体も気にせずに頼れる友だちのような曲。
本当に大切で、口ずさむとなんだか切なくなる曲。  
これがあるためにくるり屈指の名曲・春風がここに挙げられなかったちょっと悔しい曲。

聴くと、なぜか中学の時の友だちが浮かぶ。
そして、Stand by meよろしく地元の駅へと線路を歩いていた光景が浮かぶ。
なんでだろう?岸田さんが鉄だからかな。(たぶん違う)

BUMP OF CHICKEN "Ending" from "THE LIVING DEAD"

THE LIVING DEAD

グングニル、ランプ、K、グロリアスレボリューションと、とてもインディーズ時代のリリースとは思えない完成されまくった怪物アルバムが、ここまで泣けるものになっているのはひとえにこの締めがあるからだと思う。

最初に聴いたときには「ええと、うん、大丈夫!君はまだ、君自身をちゃんと見てあげていないだけ」のフレーズでアルバムトータルのカラーが決まった気がした。そして、そのイメージは今に至るまで鮮明に思い浮べられる。あれから5年も経ってるのにね。音楽って偉大だ。

* Five people to whom I'm passing the baton (バトンを渡す5人)

これだけ、ちょっと明日へオアズケ。   

Musical Baton進捗報告

by tanabe on June 21, 2005

さて、Musical Baton。厳選に厳選を重ねた上で引っ張り出してきたアルバムですら、20枚。

ここから5曲に絞るわけですわ。まいったな。

一応、現時点での候補リストを書いておこう。順不同。

  • ZEPPET STORE "LOOP" (Single)
  • ナンバーガール "シブヤROCKTRANSFORMED状態"
  • PIXIES "Doolittle"
  • The Smashing Pumpkins "Mellon Collie and the Infinite Sadness"
  • The Smashing Pumpkins "siamese dream"
  • THE BEATLES "HELP!"
  • The Beach Boys "Pet Sounds"
  • RADIOHEAD "the bends"
  • THE WHO "LIVE AT LEEDS"
  • Cheap Trick "In Color"
  • superchunk "come pick me up"
  • Billy Joel "THE STRANGER"
  • David Bowie "THE RISE AND FALL OF ZIGGY STARDUST AND THE SPIDERS FROM MARS"
  • THE YELLOW MONKEY "SICKS"
  • BUMP OF CHICKEN "THE LIVING DEAD"
  • number girl "SCHOOL GRIL BYE BYE"
  • ZEPPET STORE "716"
  • TOMOYASU HOTEI "GUITARYTHM FOREVER Vol.1"
  • くるり "TEAM ROCK"
  • くるり "春風" (Single)

さあて、どうしたもんか。愛情の赴くままに行きますか。

  

ベルカ、吠えないのか?

by tanabe on June 21, 2005

向井秀徳日記で気になる本の話を読んだ。「ベルカ、吠えないのか?」という古川日出男の小説だ。

6月11日

文藝春秋の方から、面白いから読んで下さい、と送って頂いた本を読んだ。
古川日出男という人の「ベルカ、吠えないのか?」という小説である。
これ、最高に面白い。電気ビリビリ。ショック・ショック・ノリノリ。

第二次大戦からはじまる軍用犬の系譜を軸に壮大に展開される話。
文体が全部断定調でカッコイイ。「犬は疾走する。そして死ぬ。1958年。犬は死ぬ。」こんなカンジがずっと続く。それがイイ。それはとてもカッコイイ。ノっている。文章が。

ここ最近小説にコなかったが、コレには久々にヤられた。キた。

私はすべての職業人は芸人だと思っている。自分の秀でる一芸を披露して対価を得ているのだと思っている。なので、作品には芸を求める。芸となる何かがあれば、それで満足する。サービスとしての泣きも純愛も青春もいらない。ただその人物の生き様を感じる芸を求めるのだ。

そして、この「ベルカ、吠えないのか?」の紹介にはひさしぶりに芸を期待できた。タイトルがまたいい。

読みもせずにうだうだ言っていても仕方ないので、買って読むことにする。

それにしても、一目でジャケ買いしてもいいと思った本は本当にひさしぶりだ。

ベルカ、吠えないのか?

  

ばしっ!しんさい・ばしっ!

by tanabe on June 21, 2005

昨日紹介したZAZEN BOYSのライブ演奏の中で向井が叫ぶ「ばしっ!しんさい・ばしっ!」 にシビレた。企画外に鋭い言語感覚がびしびしと突き刺さる。

そして、CRAZY DAYS CRAZY FEELINGがほとほとあきれるほどにすばらしい。脳髄にびりびりとヒビク。これだけでもいい。聴いてほしい。

  

ZAZEN BOYSが無料でライブを公開中!

by tanabe on June 20, 2005

そうそう!大事なことを紹介し忘れてた!

うちのブログを見に来てくれる人はたぶんIT関係で読みに来てくれていて、音楽ネタはスルーされる傾向が強いのだけど、これは聴かなきゃ損ですよ。お客さん!

ZAZEN BOYS AT OSAKA

SHINSAIBASHI CLUB QUATTRO
5.10 2005

http://www.mukaishutoku.com/at_osaka_.html

なんと、公式ページでライブ演奏のMP3を無料配布中!

何も言わないので、とにかくリンク先へ跳んで聴いてほしい。ZAZENのMATSURI BEATを感じてください。

向井秀徳日記に本人も書いているとおり、あまり音質は良いものではないかもしれない。でも十分にライブ感は伝わる出来。

こいつを聴いて、ぜひライブにも。生だとこれよりさらに凄いですよ。

  

Musical Batonが来てしまった。

by tanabe on June 20, 2005

おそれていた事態がついに。

「なぜこのネタで自分にまわさない!」(それは知り合いが少ないから)だったり、「いや、ほんとまわして」と思っていたりしたMusical Batonなんですが、これ、実はけっこう回ってくるのを恐れてました。

雑食系音楽好きでNo Music, No Lifeな自分としては、好きな音楽絞るなんて拷問です。たぶんそれを考えるだけで、CDひっくり返して、仕事中もあれかこれかとモンモンとして、本を読んでいても延々と悩んで、となるのは目に見えてます。

ごちゃごちゃ言ってますが、嬉しくって仕方ないんで、ゆっくりと悩みたいと思います。はい。

ということで、ありがとう、コマチさん

先願制?のようなんで、先に回し先を考えておこうかな。

  

Rolling on Ruby on Rails - Japanese Translation - p3

by tanabe on June 18, 2005

Pages: 1, 2, 3, 4, 5

recipes テーブルを作成する

これから作るクックブックではレシピを作ることができる。そこで、レシピを保存するためのテーブルをデータベース上に作成してみよう。

MySQL-Frontの左ペインで、たった今作成したばかりのcookbookデータベースを右クリックする。そしてポップアップメニューからNew>Table... を選択。 (Figure 21)

creating a new table
Figure 21. テーブルの新規作成

テーブル名をrecipes にする。(Figure 22)

the Add Table dialog box
Figure 22. テーブル追加のダイアログボックス

重要!:MySQL-Frontは自動的にIdというプライマリキーを作成するが、Railsではid (すべて小文字)としておいた方がいい。詳細は後述するので、ここではとりあえず変更してほしい。左のペインで先ほど作ったrecipes テーブルを選択する。右のペインでId フィールドを右クリック、プロパティを選択する(Figure 23)、そして名称をidに変えよう。

renaming the primary key
Figure 23. プライマリキーの名称を変更する

レシピにフィールドを追加する

これでrecipesテーブルができた。レシピのデータを保存するフィールド(カラム)を追加していくことができる。まずはtitleinstructions フィールドを追加することから始めよう。後になればおそらくもっとたくさんのフィールドが必要だろう。でも、最初はこのくらいがちょうどいい。

recipeテーブルが選択された状態で、右のペインの何もないところで右クリックをし、New>Field... を選択しよう。(Figure 24)

adding a new field
Figure 24. 新しいフィールドを追加する

どのレシピにも必ずタイトルがあるものなので、レシピのタイトルのためのフィールドをvarchar(255) 、NOT NULL制約を付加で作成しよう。Figure 25がポップアップウィンドウに出てくるオプションだ。

adding the title field
Figure 25. title フィールドを追加する

上記の手順を繰り返し、instructions フィールドをtextとして作成する。Figure 26を参照。

adding the instructions field
Figure 26. instructions フィールドを追加する

これでrecipe テーブルはFigure 27のようになっているはずだ。

the modified recipe table
Figure 27. 作成されたrecipe テーブル

すごいことが始まる

ここまでにやってきたことは全部すぐにできるし、別に難しくもなかった。ただ、それほど面白いこともなかったと思う。けれど、それがここから一変する。あっという間にぼくたちは、ほんの最初のクックブックアプリケーションを立ち上げ、動かすことができる。

Modelを作る

まず、データベースのrecipes テーブルのデータを扱うRecipe modelクラスを作る。Figure 28のようなかんじだ。

the Recipe model class
Figure 28. Recipe model クラス

コマンドプロンプトを開きcookbookのフォルダ(c:\rails\cookbook)へ行って、コマンドを実行しよう。

ruby script\generate model Recipe

このコマンドがRecipe クラスの原型となる定義を含むファイル、recipe.rb を作成する。中を見るためにファイルを右クリックして編集(Edit)を選ぼう。(Figure 29)

the contents of recipe.rb
Figure 29. recipe.rbの内容

この一見からっぽのクラス定義はレシピのビジネスオブジェクトだ。これはRailsをデータベースのrecipesテーブルへとマッピングしている。この意味はすぐにもっとはっきりとわかるだろう。

さて、Railsの名前付けルールによって起こるちょっとしたプログラムのマジックをお見せしよう。単数形のモデルクラス(Recipe)は複数形のデータベーステーブル(recipes)へとマッピングされる。Railsは英語の複数形のルールをよく知っているので、Companycompaniesへと、Personpeopleへとマッピングされる。その他の単語についても同様に適切にマッピングされる。

さらに、RailsはRecipe クラスとrecipes テーブルの各行や各列のアトリビュートへアクセスするためのメソッドを動的に配置する。

つまりあなたは、このRecipe クラスとrecipes テーブルが動的に関連付けられるとんでもない様子を目の当たりにすることになる。

これであともう少しで、何かが起こる。あとは、レシピのcontroller (Figure 30)を作る必要がある。これは、標準的なCRUD(Create, Read, Update, Delete)を使ってデータベースのrecipesテーブルを操作するものだ。Railsではこれをあなたが考えているよりも簡単に実現できる。

the Recipe controller in its native environment
Figure 30. 標準の状態でのRecipe controller

コマンドプロンプトでcookbookフォルダ(c:\rails\cookbook)を開いて、コマンドを実行しよう。

ruby script\generate controller Recipe

これで、RecipeController クラスの骨組みを含んだrecipe_controller.rb というファイルが作成される。ファイルを右クリックして、編集(Edit)を選択し、Figure 31のようにscaffold :recipe という行を追加しよう。

one line of code in RecipeController
Figure 31. RecipeController のコード

このたった1行のコードがデータベースを現実の世界へ運んでくる。これだけですべてのCRUDを定義していて、すぐにcreate, read, update, deleteの各処理をデータベースのrecipesテーブルに使うことができるんだ。

ブラウザを開いて、http://127.0.0.1:3000/recipe/new を表示させよう。Figure 32のように表示されるはずだ。

creating a new recipe page
Figure 30. 新しいrecipe pageを作成する

ほら、すごいだろう?まだ何もたいしたことはしていない。なのにもうデータベースを扱うことができるんだ。でも、まだちょっと待ってほしい。先にrecipe テーブルにいくつかのフィールドを追加しよう。

MySQL-Frontを使ってdescription フィールドとdate フィールドをtitleフィールドとinstructionsフィールドの間に追加しよう。(Figures 33 と 34)

adding the description field
Figure 33. description フィールドを追加する

adding the date field
Figure 34. date フィールドを追加する

ブラウザを更新すると、Figure 35のようなページが現れる。

a new recipe page with the new fields
Figure 35. 新しいフィールドを持った新しいレシピページ

こりゃ、もうすごいなんてもんじゃない。とんでもない。

ちょっと落ち着いて、ためしにレシピを入力してみよう。各フィールドをFigure 36のように埋めたら、Createボタンをクリックする。

a new recipe
Figure 36. 新しいレシピ

Figure 37のようになるはずだ。

a listing of all recipes
Figure 37. 全レシピのリスト

もう一つ追加してみよう。"New recipe"リンクをクリックして、Figure 38のように入力しよう。

another new recipe
Figure 38. もう一つの新しいレシピ

Createを押すと、Figure 39のようになるはずだ。

a fuller list of all recipes
Figure 39. すべてのレシピが表示されたリスト

ほんの少しデータベースへ手を入れて、ソースコードを一行書いただけで、驚くほどの機能を手に入れてしまった。まだ見た目はあまりよくないけれど、それもすぐに良いものに直そう。

それまでの間、レシピを追加したり、削除したり、編集したりしてみてほしい。さあ、どうぞ。

ぼくは次のセクションで待っていよう。

Pages: 1, 2, 3, 4, 5

  

ぼんやりと見えてきたインターネットOSの姿

by tanabe on June 16, 2005

メモ。

「Googleはインターネット時代のOSとなる」という発想を実感してきた。

ただ、ちょっと違っているのはOSはGoogleではない。

 

家に帰る、PCを起動する。寝るまではほとんどの時間でPCを使っている。

やっていることと言えば、Gmail、Bloglines、del.icio.us、livedoor blog、Google、Wikipedia、FC2アクセス解析、はてなブックマーク、オンライントレード。

使うのは、ブラウザ。これだけだ。

 

GoogleOSではない。ただ、それでもインターネットOSということは十分できそうだ。

なぜなら、これだけのことなら別にPCでなくても良いし、Windowsでなくてもよい。

快適なユーザーインターフェースと画面、WWWへの窓があればそれで事足りてしまう。

たまたま今はそれがPCであるというだけだ。

 

そうやって考えると、中々興味深いサービスをGoogleが始めている。

CNET Japan 「グーグル、パーソナライズ可能な新ホームページを公開」 (2005/05/20)

このニュースが流れたときの受け止め方として、MyYahooのようなポータルをGoogleも始めたという受け止め方が主だったように覚えている。

ただ、私が考えているのは、上記で挙げたようなWeb2.0系の新しいサービスを統合するための土台、インターネットの入り口として、どうしてもこのサービスが必要になったということなんじゃないかということだ。

 

下記は、昔懐かしい梅田望夫氏の[梅田望夫・英語で読むITトレンド]から関連しそうな話題を集めてみた。

PCに残る仕事、残らない仕事 (2004年07月12日)

Desktop Linuxの可能性とGoogle (2004年06月24日)

「Google PC世代」という考え方 (2004年06月21日)

オライリーのインターネットOS論 (2004年01月20日)

GoogleはインターネットのOSになるか (2004年01月07日)

改めて読み返して、特に興味深いのは「GoogleはインターネットのOSになるか」のこのフレーズ。

こうして、新しいサービスと共に、Googleは、他の誰かのパイを少しずつ切っては持っていく。そういう行為の積み重ねが、この記事の冒頭に示された「an all-Google world」というわけなのである。

Googleはいたるところに遍在するミドルマンとなるゆえ、インターネット上で商取引を行なうすべての企業にとっての明確で目に見える危険になっている。この遍在するミドルマンというビジョンは、ヤフーだってマイクロソフトだってAOLだって、ずっと目指してきたことだ。そしてそのビジネスモデルは広告収入に頼るのも同じ。ではGoogleと他者の違いは何か。

Googleの特徴は、極めてシンプルな同じインターフェースですべてのことに処することだ。Googleは、ユーザ、カスタマーが、グラフィック・インターフェースやプルダウンメニューなどを使わずとも、シンプルなGoogleインターフェースでたいていのことをやってのけるに足るスマートさを持っているものだ、と仮定しているのである。

ちょっと忘れかけていた発想だったので、新鮮だった。偏在するミドルマンか。

 

ユビキタスな時代で、プラットフォームが固定されていない(かもしれない)としたら、”偏在する”チャンスはまだあるってことなんだろうな。

  

Greasemonkeyが実現するもの

by tanabe on June 16, 2005

メモ。

Greasemonkeyが実現するもの。

コンテンツとビューとファンクションの分離。

提供されるのはコンテンツとファンクション。

そして、ユーザーは好きな形のビューで利用する。

なんだかoo的だ。

  

求めているのはインターネット。他はただのプラットフォームだ。

by tanabe on June 16, 2005

メモ。

皆が求めているのはインターネット。

PCの爆発的な普及の契機となったのは、インターネットだった。

そして、人々が求めているのもやはりインターネットだ。

つまり、今はインターネットを満喫できるベストなツールがPCだ、というだけで、実際はプラットフォームはなんでもいい。

PCもプラットフォーム。OSもプラットフォーム。ブラウザもプラットフォーム。

シバリをなくして考えてみることにしよう。

  

Web2.0の課題−コンテンツの時間的な永続性

by tanabe on June 16, 2005

メモ。

Web2.0の課題の一つはコンテンツの永続性。

サービス倒れたらPermalink利かなくなりました、書いた当人が消したからPermalinkが利かなくなりました、では、せっかくの価値が生きない。

そういう意味で、Google Gmailの「Deleteはもう不要!」という謳い文句は正しいと思う。

書いた文章は書いた人のもの、という考え方がシフトする必要があるのかもしれない。

  

高橋メソッドのメソッド具合

by tanabe on June 16, 2005

ちょっとどうしても気になったのでエントリしてしまうんですが、高橋メソッドって、もしかして皆本気で注目をしていたのでしょうか?本気というのは、まともにプレゼンで使ったろーって意味で注目されているのでしょうか?

なんでいきなりそんな話かというと、fladdict.net/blogさんでマジ考察をされていたもので。

いや、今まで皆様ネタで喜んでるのかと思ってたんで気になってしまって。

あれ、もしかしてエントリ起こした時点で釣られてます?

 

まぁ、それはそれとして、

高橋メソッドの長所
・展開がスピィーデーィ
・常に注目すべき点のみを表示できる
・インパクトが強い(集中力を喚起できる)
・簡潔

高橋メソッドの短所
・視聴者のフォーカスが常に現在位置のみ集中する。
・ゆえに話の前後関係が見失われやすい。
・図がない
・ページ数がやたらと増える。
・パワポを配布資料にできない。
・ふざけてると思われる

その他
ノートのとりやすさは、ちょっと実際に体験したことがないので、よくわからん。

こういうのこそ、高橋メソッドでつらつらと流すのに向いてますよね。

読みながら、ついつい脳内で自動変換されてました。

  

A New Game, Ha?Certainly!

by tanabe on June 16, 2005

あー、もう今日は更新とかそんな気分じゃございません。

それもこれもすべてこいつのせいです。こいつが悪いんです。

http://game.goo.ne.jp/contents/game/OGMHOTD335/index.html

パズル的なゲームが得意な方、ぜひカタキをとってください。。

PS. 音が出るので、会社の方はご注意を。

  

すごい会議

by tanabe on June 14, 2005

読了。

正味、2時間くらいか。さて、どうやって実践していくかな。

  

「すごい会議」はすごすぎる

by tanabe on June 14, 2005

idea * ideaで紹介されていた「すごい会議」を読んでいる。 (羽生さんも紹介されていた

僕が教わったのはこの「すごい会議」のやり方である。自分なりにアレンジを加えているが、無敵会議、アカデメディアのすべての手法のもとになっているといっても決して過言ではない。

の言葉にやられ、その場でAmazonへ駆け込んだ。(もちろん実際は二三度クリックしただけだが)

で、その中からメモ。

「まずやってもらってから(体験したその中に入ってもらう=紙に書く)、
 そのメリットに関して質問する(疑問が起こって、答えを探そうとする)。
 深い洞察のアイデアを提供する(「紙に書いているときは人の意見が見えない」)。」
 この手順でやると、納得というか、落とし具合がとてもすとんと入る。
 要約すると、左のようになる。

  Aのやり方・・・・・・<洞察の提示>→<実体験>
  Bのやり方・・・・・・<実体験>→<質問>→<洞察の提示>

 Bの方が手間はかかるが、納得度は高い。
 彼はことあるごとに、このやり方で、彼の洞察を僕らにインストールしていった。

その後に下準備として書かれている、

  • 経営の中心となるメンバーが緊張感を持ってそろった(ランチでなく)
  • 人の意見を気にすることなく、それを発表するしくみを手に入れた
  • 参加させられている(特に僕)という感じから、「なにかやってやろう」という気分になった
    それも自分自身が一番それに貢献できるという感じで

の中の「人の意見を気にすることなく、それを発表するしくみを手に入れた」は深いなぁと思った。こうあるべきだ、という意味ではよく聞く話だし、当たり前の前提に思えるけど、意外とそこまで持っていくやり方まで書いてあることって少ないよな。

本質の部分とそれを達成するためのアクションはどっちが欠けても半人前ってことで。

ついつい感心しながら読んでしまう。。。

すごい会議−短期間で会社が劇的に変わる!

  

ユーザーニーズは聞いちゃいけない。

by tanabe on June 14, 2005

解決策志向型の思考をする人は、現象を追ってはいけない。頻出する問題というのは、色々な課題が出てくるように見えていても、実はそれは現象でしかなく、多くの場合はその根っことなっている原因があるはずである。本質的に問題を解決するためにはその根元を叩く必要がある。

大前研一氏の「企業参謀」ではこう述べられている。

私のいままでに見、あるいは聞いてきたかぎりでは、企業内でルーティン化している業務内容改善計画やプロジェクト活動というものは、えてしてこの抽象化のプロセスを踏んでいない。したがって、解決策と問題点が短絡してしまっているのである。たとえば

「問題」=事業部間人事交流の欠如
「対策」=事業部間人事の流出入を容易にし、人事交流を計る

といったたぐいの短絡した解決である。しかし、現象として現われている問題がなにに帰属する問題であるのか、なにに深くかかわりあいがあるのか、ということの理解なしには真の解決策は得がたい。

この前段では、問題から対策へと短絡的な結論付けをしないために抽象化のプロセスを経ることが大事だと述べられている。

私は、この段階で重要なことは、
「問題点のしぼり方を現象追随的に行うこと」
 であると思う。 よく用いられる方法としては、<図6>に示したような抽象化のプロセスがある。

problem_solving_aproach

この辺りの話は最近の著ではさらに明快になっているので、そちらも引用しておこう。「実戦!問題解決法」から。

PSAの原則3|原因と現象を混同するな

 私の経験では、ほとんどの場合、5割以上のウエートを持っている原因は1つだけ存在する。たくさん問題がありそうに思えても、1つの原因が現象としていろいろな形で問題として出てくるだけなのだ。原因と現象の区別がつかない人は、問題がたくさんあり過ぎて解決のしようがない、という言い方をする。だが、現象に1つ1つにいちいち対処しても、それこそしょうがない。原因をつぶさなければ、絶対に問題は解決しないのだ。

 このように、原因はたいてい1つに集約されるのだが、現象はいろいろなところに出てくるから、PSAを使わないと、現象と原因をはき違えて的はずれな対策を講じてしまうことになる。
 つまり、現象を原因だと思い込み、現象に対して対症療法を施し始めるのだ。しかし原因は直っていないから、また別な形で問題が出てくる。それに対してまた対症療法を施す。そうやって際限なく見当違いの対症療法を繰り返す羽目になり、コストばかりがかさんでいく。

具体例を一つ引用しておこう。

 たとえば、セールスマンに元気がなくて商品が売れない、という問題があったとする。この場合、典型的な現象に対する対症療法は、社長が各支店・営業所を回ってセールスマンを激励する、という方法だ。車座になって酒を飲んだら、みんな言いたいことを言って、明るくなった、元気が出たな、と社長は喜ぶ。ところが、すべての支店・営業所を回り終えたのに、売り上げはまだ落ちている。そのうちに誰かがセールスマンに元気がないのは固定給のせいで、いくら働いても報奨金が出ないことが問題なんです、と言い始める。分かった、じゃあ売り上げの多いセールスマンはボーナスを2倍にしてやろう、となって動機づけ、すなわちインセンティブ制度を作る。それでも売り上げは落ち続ける。すると、また誰かが、実はインセンティブ制度だと勝者と敗者に差がつきすぎるため、敗者がやる気をなくしているんです、と言ってくる。それはまずい、ということで、今度はみんな2割ぐらい増して固定給に戻す。しかし、やはり売り上げは落ち続ける。そこで再びインセンティブの議論に戻り、いくら働いても差がつかないから、できるセールスマンほど辞めていく、となる。ところが、セールスマンに同行してみると、車のトランクにゴルフバッグがあって、増えた給料がゴルフのプレー代や練習場代、クラブ代に化けていたことが分かる。

 現象に対する対症療法を頻繁にやっていく会社は全部これである。常にその時その時に最大の問題ですと言われた現象に対策を打っていくから、コストだけ高いものについて、結局、何も効果がない。

だが、そういう状況でも、売り上げが落ちている原因は1つ、最大で2つしかない。PSAを使って原因を探っていくと、問題は全く違うところにあることがほとんどだ。先ほどの会社の場合だと、製造部門は一生懸命やっているから、この2年で4回も製品が変わった。しかし、セールスマンは新しい製品に関する知識が不足している。そればかりか潜在的なお客さんを見つけるスキルもなければ、お客さんを説得していくスキルもない。つまり、セールスマンとしての基本的なトレーニングができていないことが原因だったりするのだ。

* PSA = Problem Solving Approachの略

 

さて、ここまでの話を踏まえて、システム開発の世界にはユーザーニーズというものがある。多くの場合、これは正解とニアリーイコールとして扱われ、システム開発のゴールの指標である。

しかし、あえて指摘したい。ユーザーニーズとは、多くの場合、現象でしかない。色々な問題を思いつくがままに語っているだけである。それを一つずつ潰していっても、それは対症療法なのだ。本来、情報システムが解決すべき問題というのはその延長線上には乗っかっていないことが多い。結局、経営には役に立たないシステム、効果の表れないシステム、という扱いを受けるのである。

以前、よしおか氏が「正しいものを作ることと正しくものを作ること」というエントリを書かれていた。「正しくものを作る」のは必要条件だ。ただ、それも「正しいもの」が理解できた上でのことである。

それでは、ユーザーニーズを聞いてはいけない状況の中で、「正しいもの」とは何なのか?

それはユーザーのミッションに沿ったシステムだ。ユーザーがその企業の中で求められているものは何か。そして、そのシステムが求められる価値は何か。それを徹底的に追求しなければならない。ユーザーインタフェースの使い勝手を上げるのは重要だ。ただ、オペレーター(=ユーザーである場合も多い)のためにシステムがあるわけではない。顧客である企業の戦略を支え、その企業が競合から一歩でもリードするためにシステムがあるのである。

システムを作るものはサービス業だという言われ方をすることがある。これは間違っていない。ただ、serveする相手を間違えてはいけないと思う。オペレーターへ親切なシステムを目指すのではない。serveすべきは企業なのである。この視点を忘れると、頑張って作って、よくできてはいるが、何の役にも立たないシステムになりかねない。

 

受けると思われる指摘として、それはコンサルタントの領域の仕事だろう、とか、仮にエンジニアがそれをやろうとしても現実問題できるのか、という指摘があると思う。顧客との関係にもよるが、難しいケースが多いのは承知している。大抵、システム開発の発注をかけるときにはシステムの開発をするということ自体は決定済みなのだ。それをそこから「そもそも論」で話を戻すのはよほどの裏付けがないと難しい。それが現実だ。

エンジニアでこれをできる人がどれだけいるのか、それも大いに疑問だ。いや、正直、ほとんどいないと思っている。ただ、問題の指摘はできるだろう。戦略が不在、ミッションを理解していない、というケースにはそちらを固めないとシステムへの投資は無駄になる、という指摘をすることはできる。問題提起をすれば、解決のために外部の専門家の手を借りるという選択肢も出てくるだろう。

情報システムへの風当たりが強まる中だからこそ、ここまで突っ込んでやる必要がある。なぜなら、これがシステム開発で問題となることの「5割以上のウエートを持っている原因」となっていると考えているからだ。

 

※念のため

途中、厳しめの表現となっていますが、「利用者に優しいシステムに意味がない」とは言っていないです。進む方向が間違っているときに、一生懸命オールを漕いでも仕方ないと言いたいだけです。方向を合わせたら、後は力いっぱい少しでも速くなるように漕げばいいと思います。

 

実戦!問題解決法 企業参謀 続・企業参謀

  

アルファギークに学ぶAjaxの本質(そしてビジネス上の価値)

by tanabe on June 13, 2005

奇しくも、同じ時期に同じテーマのエントリがあがっていた。

一つは、Adam Bosworth's Weblogの"Ajax reconsidered".

そしてもう一つは、Life is beautifulさんの「Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ

なんせ

実は、現在米国 Google で活躍している Adam Bosworth と Gary Burd と私は、マイクロソフトで Internet Explorer 4.0 を一緒に開発していた仲です。マイクロソフトが XML と DHTML の機能を初めて導入したブラウザーです。あの当時から、彼らとは「次世代ウェブ・アプリケーション」の話ばかりしていました。非同期通信の話とか、UIをブロックしないだとか、XML over HTTP の話はその時に始まった話です。ある意味で、Adam も私も、10年近く同じことを言い続けているわけですね。

なのだから、この偶然?だけでも歴史を感じてしまい楽しい。

 

まずは"Ajax reconsidered"の方を読んでみよう。

どんな話なのかは、del.icio.usのコメントできれいな紹介文があったので引用。

Adam Bosworth describes why Ajax is a succes now, as opposed to DHTML in the 90's, and what is required for it to become truly successful.

Adam Bosworthが、(90年代にDHTMLが成功できなかったのと対比して)どうしてAjaxが流行っているか?、そしてAjaxが本当に成功するためには何が必要となるのか、を解説しているわけです。

まずは1997年にDHTMLやXML over HTTP control 受け入れられなかった背景を解説。

They saw the web as a two edged sword. One the one hand it offered instant and universal access to all their customers which was an opportunity they couldn't afford to resist. On the other hand, they were terrified by the support costs of having millions or tens of millions of customers using their software. Accordingly, they wanted applications (aka web sites) that were as simple to figure out how to use as possible.

Webには二つの面があり、とても便利で強力なネットワークを持っている反面、利用者の数が膨大でサポートのコストがとんでもないことになるという難点もある。だから、webへ求められるのはとにかく使い方が分かりやすいアプリケーションなのだ。(”だった”)という指摘。

Webは顧客へアクセスするための一手段でしかなく、たまにしか使われないwebアプリを機能豊富なインターフェースで組み立てて、無駄にサポートコストをかけるのは避けたいというのが97年当時の企業の考えだったようだ。

そして現在、Ajaxは大きな注目を集めている。さて、なぜだろう?というのがここからの話。

Adamは三つの理由があると言っている。

First, the applications that are taking off today in Ajax aren't customer support applications per se. They are more personal applications like mail or maps or schedules which often are used daily. Also people are a lot more familiar with the web and so slowly extending the idiom for things like expand/collapse is a lot less threatening than it was then. Google Maps for example uses panning to move around the map and people seem to love it.

一つ目の理由は、そもそも顧客サポートが必要とならないような日常的で一般的なアプリケーションでAjaxが使われているということ。メールや地図、スケジュールといった普段から馴染んでいるソフトとして提供されているため、直感的に使い方が分かり、前述のサポートコストが云々という話にはなり難いという指摘。また、ユーザー自身がコンピュータのUIに慣れてきており問題となりにくいというのも理由だろうと述べている。

Secondly, the physics didn't work in 1997. A lot of Ajax applications have a lot of script (often 10 or 20,000 lines) and without broadband, the download of this can be extremely painful. With broadband and standard tricks for compressing the script, it is a breeze. Even if you could download this much script in 1997, it ran too slowly. Javascript wasn't fast enough to respond in real time to user actions let alone to fetch some related data over HTTP. But Moore's law has come to its rescue and what was sluggish in 1997 is often lightning quick today.

二つ目の理由として、1997年にはネットワークやクライアントのインフラが力不足だったのが、近年克服されているということ。動的に呼び出されるコードを含んだページを読み込んでもダウンロードが遅すぎたりもせず、動的に一部のコンテンツを呼び出してもそれがストレスとなることはなくなった。これがあって、初めてAjaxが本来の快適なUIの実現に貢献できるようになったわけだ。

Finally, in 1997 or even in 1999 there wasn't a practical way to write these applications to run on all browsers. Today, with work, this is doable. It would be nice if the same code ran identically on Firefox, IE, Opera, and Safari, and in fact, even when it does, it doesn't run optimally on all of them requiring some custom coding for each one. This isn't ideal, but it is manageable.

最後の理由として、ブラウザ間の互換性を保ったままwebアプリケーションを書くことができるようになった点が挙げられている。同じコードで動けばそれで良し、もし動かなかった場合でもそれぞれにカスタムコードを書くとかで問題を回避することはできるようになった。つまり、ブラウザによらず、とりあえずは役立つ物になるわけだ。(ブラウザ個別にコードを書くのは美しい解決策ではないかもしれないけど、ユーザーへ問題が表面化することにはならない)

以降は、Adamの息子、Alex BosworthのAjaxへのダメ出しエントリから漏れていたAjaxの弱点についての考察が述べられている。

ここは一つだけ、引用しておく。

Third, if you want the application to run offline, you are essentially out of luck. I've written about this at length before in this blog and don't need to repeat what is required in detail. To summarize what I said earlier, a local cache, a smart template model, and a synchronization protocol are required to build applications that run equally well connected and disconnected and the way that the Blackberry works is a role model for all of us here.

Webアプリケーションが良いって言うのはわかったけど、オフラインだったらどうすんの?って話である。誰でも気付ける問題だけど、誰でも気付けてしまうがゆえに根強い課題だ。Web側で情報をドライブしようとしたときに最後までしぶとく残る問題のような気がする。(切り替えられない人は置き去りにするっていう手もあるけど)

 

そして、ここでもう一つLife is beautifulさんの「Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ」の方を読んでみよう。これ、最近で一番感動したエントリです。明快でスマート。

Googleなどが進めている第二世代のウェブ・アプリケーションのアーキテクチャーの本質は、XHTMLやXMLやJavascriptにあるのではない。その本質は、

(1)アプリケーションの明示的なインストールが必要ない。
(2)サーバーとの通信を非同期に実行することにより、通信遅延によりUIをブロックしない。
(3)サーバーとのやり取りは、RPCではなく、メッセージで行う。
(4)データ・バインディングはサーバー側ではなく、クライアント側で行う。
(5)UIにインテリジェンスがあり、ある程度はサーバーに戻らずにユーザーとやり取りをする。

の5点にある。

日本語なので、読んだまま、です。各項目の補足説明も引用元にあるので未読の方はぜひご一読を。私のこんなエントリよりもはるかに価値のある濃い文章です。

 

この両エントリを読んで頭の中がすっきりと整理された。そして、Ajaxはやっぱり末端技術なんだよなぁと思う。技術的には面白いのだけど、それ自体が力を持つようなもの(例えばOpen Source Paradigm Shiftで指摘されるような内容)ではないということ。なんせ出自が現在のWebアプリケーションの弱点となる部分を打破するための”やり方”でしかないわけだ。”やり方”が思いつかれたことは偉大だし、それが実現できるようになったことも非常に重要なことであるけれど、一度思いつかれ、実現方法が周知されたらそれはもう競争力にはなり得ない。

つまり、面白いけど本質的に競争優位性を保つような強力なものではないよってことだろう。大雑把な言い方をしてしまうと、ビジネス上は「UIは大事だよね。より良いものを提供しよう」という方向性さえ合わせておけばいい。適切な時にはAjaxという”良いツール”を使うこともできる。ちょっとした外部要因でAjaxはまったく必要なくなるかもしれないしね。くらいの認識でいいのかもしれない。(とはいえ、現在の環境下ではUIを良くする強力な手段であることには何の異議もない。はてなRSSの「もっと読む」なんか、動きだけで気持ちいいと思うし。)