メッセージ。 - diary
2005-07-04
# 「リアル・タイム・マシーン展」を見てきたよ
http://realtimemachine.dotimpac.to/
というわけで、行ってきました。dotimpactさんの「リアル・タイム・マシーン展」。
いやー。表参道ってお洒落っすねー。しかも画廊とか行くことなんて、普段ないじゃないですかぁ。非日常の極致ですよ。駅を降りても、できるだけキョロキョロしないよう、目が泳いで涙目にならないよう、頑張って歩きました。
それにしても、やっぱり表参道も邸宅多し。すごかった。目的の画廊自体はちょっと分かりにくいところにあるので、番地（4丁目17番地の3）までメモしていくほうがよいですね。ふじさわは迷ったので、郵便配達のおじさんに道を聞きました。でも、「こんなハイソな街で道を尋ねたら泥棒やと思われへんやろか？」とドキドキドキドキ。
教えてもらったとおり歩いて、やっと目的地に到着、小綺麗なコンクリートの階段を（ぬき足さし足）降りていって、そこに普段着のdotimpactさんを見つけたときはすげー安心しました。「仲間がいるー」って。
今回の展示自体は3つ。昔なつかしいゼビウス、スーパーマリオ、ピンポンゲーム（アルカノイドみたいなやつ）を題材に、「リアルタイムなゲームをちょっとリアルタイムじゃなくしたらどうなるか？」という遊びを盛り込んでいます。
少しずつリアルタイム性能が違うマシンを見ていると、「パラレルワールド」という言葉が浮かんできました。dotimpactさんの審美眼はそういうところに反応したのかなとか考えたり。オープニングパーティも、普段接触することのない人たち（ゲームクリエイターの人とか美大の学生さん（女子多し）とか）を見ることができて楽しかったです。
というわけで、行ってきました。dotimpactさんの「リアル・タイム・マシーン展」。
いやー。表参道ってお洒落っすねー。しかも画廊とか行くことなんて、普段ないじゃないですかぁ。非日常の極致ですよ。駅を降りても、できるだけキョロキョロしないよう、目が泳いで涙目にならないよう、頑張って歩きました。
それにしても、やっぱり表参道も邸宅多し。すごかった。目的の画廊自体はちょっと分かりにくいところにあるので、番地（4丁目17番地の3）までメモしていくほうがよいですね。ふじさわは迷ったので、郵便配達のおじさんに道を聞きました。でも、「こんなハイソな街で道を尋ねたら泥棒やと思われへんやろか？」とドキドキドキドキ。
教えてもらったとおり歩いて、やっと目的地に到着、小綺麗なコンクリートの階段を（ぬき足さし足）降りていって、そこに普段着のdotimpactさんを見つけたときはすげー安心しました。「仲間がいるー」って。
今回の展示自体は3つ。昔なつかしいゼビウス、スーパーマリオ、ピンポンゲーム（アルカノイドみたいなやつ）を題材に、「リアルタイムなゲームをちょっとリアルタイムじゃなくしたらどうなるか？」という遊びを盛り込んでいます。
少しずつリアルタイム性能が違うマシンを見ていると、「パラレルワールド」という言葉が浮かんできました。dotimpactさんの審美眼はそういうところに反応したのかなとか考えたり。オープニングパーティも、普段接触することのない人たち（ゲームクリエイターの人とか美大の学生さん（女子多し）とか）を見ることができて楽しかったです。
2005-07-02
# Gauche 0.8.5リリース！
Gauche 0.8.5リリース！
http://www.shiro.dreamhost.com/scheme/gauche/index.html
でもなんか、手元の環境（Slackware 10.1、Linuxカーネル2.6.12）だと「make install」でエラーが出る…。うーむ。
http://www.shiro.dreamhost.com/scheme/gauche/index.html
でもなんか、手元の環境（Slackware 10.1、Linuxカーネル2.6.12）だと「make install」でエラーが出る…。うーむ。
make[1]: Entering directory `/usr/local/src/devel/Gauche-0.8.5/libif test -f /usr/local/lib/slib/require.scm; then \/usr/local/bin/gosh -ftest -uslib -E"require 'new-catalog" -Eexit;\fi*** ERROR: unbound variable: with-load-pathnameStack Trace:_______________________________________0 (lambda () (apply *old-load* (cons <pathname> extra)))At line 205 of "/usr/local/lib/slib/require.scm"1 (slib:load (in-vicinity (library-vicinity) "mklibcat"))At line 79 of "/usr/local/lib/slib/require.scm"2 (catalog:get feature)At line 139 of "/usr/local/lib/slib/require.scm"make[1]: *** [slibcat] エラー 70make[1]: Leaving directory `/usr/local/src/devel/Gauche-0.8.5/lib'make: *** [install] エラー 2
# 「従来のEJBは存在自体が間違いだった」
http://itpro.nikkeibp.co.jp/free/NSW/NEWS/20050621/163065/
激しく脱線するけど。
「イノベーションがある分野は，標準化よりも市場での競争にゆだねるほうがうまくいく」かぁ。これはそうかもしれない（が、そう思いたいという気持ちがあるゆえ間違ってるかもしれない）。もしこれが本当だとすれば、変化の激しい分野では、変に上からコントロールしようとするより、勝手にやらせとくほうがいいんだろうな。
というのも、少し前の「ソフトウェア開発の生産性を上げたい」という話に関連するのだけど。どうもいまでも、「ソフトウェアを工場で作る」という発想を肯定的に捉えている人もいるようなんだよなぁ。いつまでも家内制手工業をやってるんじゃなくて、もっと大規模な工場制手工業、機械制大工業に進みたい、そのためにデータを取得する必要があるって。
でも、やっぱりぼくは、そっち行かないほうがいいと思ってる。根拠をうまく説明できないけど、ソフトウェア工場はうまくいきそうにない。ソフトウェアは純粋な工業製品というよりも、もっと芸術的な要素が強い。使いやすいソフトウェアを作ろうと思ったら、使う人によく合ったものでなくてはいけないし、作る人がきちんとエネルギーや哲学を込めたものでなくてはいけないと思う。
つまり人間的な力を発揮しなければいけないと思うんだ。少なくともいまは。だってそうでしょ？ まだ黎明期なんだもん。ルネサンス期の発展は、多くの天才によって生み出された。工場ができて平凡な人の時間を使ってたくさんの製品を作り、安定して稼働できるようになったのはずっと後のことだ。ソフトウェア産業はまだ若くて、どんどん変化しつづけてる。技術も文化も、ぜんぜんこなれていない。
どっちかというと群雄割拠の時代だと思うんだよね。そうしたらさ、いまはデータを集めて「開発効率向上のために」とか言うよりも、どうせやるなら「人」。元気にやってる人にフォーカスして、みんなのクリエイティビティを励起させるべきフェーズにあるように思うんだ。そのためには、外野の人は変に業界に力をかけないほうがいい。もしやるとしても、ちゃんとギークの話を聞くとか、人間的な方法で時代に対峙していくべきだと思う。
「TopLinkは（現在は米Oracleが提供しているため）ベンダーによる囲い込みという弊害はあるが，それでも動かないEJBよりはマシ。悪い標準は，標準がないことよりも悪い」（同）と切り捨てた。EJB以外では，Javaのデータベース接続用APIであるJDBCも標準化がうまく機能していない例だという。「標準化がうまくいくのは，トランザクションのような何十年も使われていてそれほど変化がない分野」とJohnson氏は語る。一方，イノベーションがある分野は，標準化よりも市場での競争にゆだねるほうがうまくいくという。「悪いアイデアが標準化されるとなかなか消えない。競争にまかせれば，悪いアイデアはすぐに駆逐される」（同氏）。
激しく脱線するけど。
「イノベーションがある分野は，標準化よりも市場での競争にゆだねるほうがうまくいく」かぁ。これはそうかもしれない（が、そう思いたいという気持ちがあるゆえ間違ってるかもしれない）。もしこれが本当だとすれば、変化の激しい分野では、変に上からコントロールしようとするより、勝手にやらせとくほうがいいんだろうな。
というのも、少し前の「ソフトウェア開発の生産性を上げたい」という話に関連するのだけど。どうもいまでも、「ソフトウェアを工場で作る」という発想を肯定的に捉えている人もいるようなんだよなぁ。いつまでも家内制手工業をやってるんじゃなくて、もっと大規模な工場制手工業、機械制大工業に進みたい、そのためにデータを取得する必要があるって。
でも、やっぱりぼくは、そっち行かないほうがいいと思ってる。根拠をうまく説明できないけど、ソフトウェア工場はうまくいきそうにない。ソフトウェアは純粋な工業製品というよりも、もっと芸術的な要素が強い。使いやすいソフトウェアを作ろうと思ったら、使う人によく合ったものでなくてはいけないし、作る人がきちんとエネルギーや哲学を込めたものでなくてはいけないと思う。
つまり人間的な力を発揮しなければいけないと思うんだ。少なくともいまは。だってそうでしょ？ まだ黎明期なんだもん。ルネサンス期の発展は、多くの天才によって生み出された。工場ができて平凡な人の時間を使ってたくさんの製品を作り、安定して稼働できるようになったのはずっと後のことだ。ソフトウェア産業はまだ若くて、どんどん変化しつづけてる。技術も文化も、ぜんぜんこなれていない。
どっちかというと群雄割拠の時代だと思うんだよね。そうしたらさ、いまはデータを集めて「開発効率向上のために」とか言うよりも、どうせやるなら「人」。元気にやってる人にフォーカスして、みんなのクリエイティビティを励起させるべきフェーズにあるように思うんだ。そのためには、外野の人は変に業界に力をかけないほうがいい。もしやるとしても、ちゃんとギークの話を聞くとか、人間的な方法で時代に対峙していくべきだと思う。
2005-07-01
# dotimpactさん個展
http://realtimemachine.dotimpac.to/
Wikiばなでお会いしたことのあるdotimpactさんが個展を開かれるらしい。すごいなぁ。ぜひ行きたいです！ 「一緒に行く人募集！」といきたいところだけど、この週は忙しいので時間を合わせられるかなぁ。オープニングパーティとか、突然行っちゃってもいいもんなのかなぁ。
dotimpact 田中孝太郎[リアル・タイム・マシーン]展◎日時：2005年7月4日［月］〜7月9日［土］12 : 00〜19 : 00［最終日は〜17 : 00］◎オープニングパーティ：7月4日［月］17 : 30〜◎会場：表参道画廊＋MUSEE F東京メトロ 表参道駅 A2出口より徒歩7分
Wikiばなでお会いしたことのあるdotimpactさんが個展を開かれるらしい。すごいなぁ。ぜひ行きたいです！ 「一緒に行く人募集！」といきたいところだけど、この週は忙しいので時間を合わせられるかなぁ。オープニングパーティとか、突然行っちゃってもいいもんなのかなぁ。
2005-06-29
# 実利のあるソフトウェアを作るために
それと、いま必要なのはニーズを発見しそれに応える力だと思います。
小さくて簡単に作れて安いものでいいから、強く人を魅きつけるもの。そういうものからスタートして、多くの人に使ってもらうこと。それが重要です。それに成功しているから、はてなもmixiもうまくいってるんじゃないかと。
ソフトウェアをちゃんと実利のあるものとして成り立たせていくには、ニーズを発見しそれを実現していくことです。そのために必要なのは、ハイレベルな技術力じゃない。技術力はそこそこでもいいからニーズを見つけること。そしてそれをプレゼンしていくこと。
ニーズを見つけられるのもプレゼンをできるのも、人間としての力や、コミュニケーションを恐れない力だと思います。「そういうデータが出ているから」、「これが流行っているから」じゃなくて、「ぼくはこれが面白いと思うから」。それでいいし、そうでなくては、人に使ってもらうサービスなど提供できないですよね？
小さくて簡単に作れて安いものでいいから、強く人を魅きつけるもの。そういうものからスタートして、多くの人に使ってもらうこと。それが重要です。それに成功しているから、はてなもmixiもうまくいってるんじゃないかと。
ソフトウェアをちゃんと実利のあるものとして成り立たせていくには、ニーズを発見しそれを実現していくことです。そのために必要なのは、ハイレベルな技術力じゃない。技術力はそこそこでもいいからニーズを見つけること。そしてそれをプレゼンしていくこと。
ニーズを見つけられるのもプレゼンをできるのも、人間としての力や、コミュニケーションを恐れない力だと思います。「そういうデータが出ているから」、「これが流行っているから」じゃなくて、「ぼくはこれが面白いと思うから」。それでいいし、そうでなくては、人に使ってもらうサービスなど提供できないですよね？
# ソフトウェア開発の生産性を向上させる1つの方法
「ソフトウェア開発の生産性を向上させるにはどうしたらいい？」って悩んでる人がいるけど、1つの答は、使ってくれる人を増やすことですよ。これは大きい。でもみんななかなか気づかない。
あるソフトウェアを作った場合、それを5人が使うのは、10人が使う場合と比べてコストが倍。つまり生産性が倍違うということです。たくさん使ってくれればくれるほどコストが負担しやすくなって、要はペイしやすくなります。だからこそマイクロソフトのWindowsなんかは成り立っていると。
とにかくたくさんの人に使ってもらうこと。これはすごく重要です。デファクトスタンダードってやつです。マイクロソフトもLinuxも、それで成功したと言って過言ではないでしょう。使う人がたくさんいれば、それが新しい顧客を呼び込んでくる。生産性拡大のサイクルを生むわけですね。
だから「日本のIT産業はどうしてうまくいかないのか」って悩んでいないで、四の五の言わずに輸出することですよ。使ってくれる人が増えれば生産性は上がりますから。「品質を高める」とか「見積もり精度を上げる」とか、そんなのが生産性に与える影響は微々たるものです。難しい割にうまくいかない。そんなのは後で考えればいいんです。
あるソフトウェアを作った場合、それを5人が使うのは、10人が使う場合と比べてコストが倍。つまり生産性が倍違うということです。たくさん使ってくれればくれるほどコストが負担しやすくなって、要はペイしやすくなります。だからこそマイクロソフトのWindowsなんかは成り立っていると。
とにかくたくさんの人に使ってもらうこと。これはすごく重要です。デファクトスタンダードってやつです。マイクロソフトもLinuxも、それで成功したと言って過言ではないでしょう。使う人がたくさんいれば、それが新しい顧客を呼び込んでくる。生産性拡大のサイクルを生むわけですね。
だから「日本のIT産業はどうしてうまくいかないのか」って悩んでいないで、四の五の言わずに輸出することですよ。使ってくれる人が増えれば生産性は上がりますから。「品質を高める」とか「見積もり精度を上げる」とか、そんなのが生産性に与える影響は微々たるものです。難しい割にうまくいかない。そんなのは後で考えればいいんです。
2005-06-28
# 辞める会社、辞めない会社
AERAの吊り広告、「辞める会社、辞めない会社」というのが気になった。
キャッチーな見出しだけど、本質的じゃないなぁと。というのも、辞める辞めないは、会社の「良さ」とは関係ないように思うからだ。ぼくの知り合いに、NTTの研究所に行った人がいる。その人はもう会社を辞めて別の仕事をしてるのだけど、ほかの同期はほとんど辞めずに続けているということだった。
ただ、辞めないでやっているにもかかわらず、その人たちは仕事を楽しんでいる風じゃないという。「仕事が嫌だ嫌だ」と言いながら、「でも辞めたくない」。そんな人たちが良い仕事をしているとは思えないし、そういう会社が良い会社だとも思わない。じゃあ、辞める辞めないはなんの役に立つ評価基準か？
構造変換を求められている日本において、変化が不要な会社はそう多くない。日本が変わらなければならないのと同じだけ、会社も変わらなければならないはずだ。とくに今後伸びるべき会社では、人の入れ替わりも激しいに違いない。変わらなければならないのに変わらない、変わらなくてもよいのに変わってしまう。もし会社の価値を評価したいなら、ただ辞める辞めないでではなく、そういう価値観で評価する必要があるだろう。
キャッチーな見出しだけど、本質的じゃないなぁと。というのも、辞める辞めないは、会社の「良さ」とは関係ないように思うからだ。ぼくの知り合いに、NTTの研究所に行った人がいる。その人はもう会社を辞めて別の仕事をしてるのだけど、ほかの同期はほとんど辞めずに続けているということだった。
ただ、辞めないでやっているにもかかわらず、その人たちは仕事を楽しんでいる風じゃないという。「仕事が嫌だ嫌だ」と言いながら、「でも辞めたくない」。そんな人たちが良い仕事をしているとは思えないし、そういう会社が良い会社だとも思わない。じゃあ、辞める辞めないはなんの役に立つ評価基準か？
構造変換を求められている日本において、変化が不要な会社はそう多くない。日本が変わらなければならないのと同じだけ、会社も変わらなければならないはずだ。とくに今後伸びるべき会社では、人の入れ替わりも激しいに違いない。変わらなければならないのに変わらない、変わらなくてもよいのに変わってしまう。もし会社の価値を評価したいなら、ただ辞める辞めないでではなく、そういう価値観で評価する必要があるだろう。