騒がしい未来

サッカーやインターネット、旅行、日々のお仕事など、普段思ったことををつらつらと書いていく、高須正和のブログサイトです。 さいきんはtwitterばかり。

 DSCN1089
チームラボがサイトを制作している、Design Channelのイベント、東京デザイナーズウィークに行ってきました!
世界中のデザインが5日間、東京の神宮外苑に集まりました。

 

DSCN1091  DSCN1090
チームラボは今回、ケータイとQRコードを利用した事前登録システムも作りました!企画から開発まであまり時間がなく、ケータイ機種やキャリアによる規格の違いにも悩まされ、かなり大変だったとか。
会期中もラボのメンバーが受付ブースの中で待機していました。

DSCN1104
各ブースにはQRコードが置かれ、事前登録者は、会場で見たデザイナーをそのままDesign Channelの「お気に入りクリエイター」に登録していくことが出来ます。(僕はiPhoneなので試せませんが…)

DSCN1088 DSCN1119
会場はそれほど広くない(野球場ぐらい?)なのですが、ブースの密度が濃く、1ブース1ブース見て行くと1日でも足らないぐらい。駆け足で回っても3-4時間ぐらいはかかります。

 

DSCN1092DSCN1096
入り口すぐのところ、ドイツ館。国内ではまだ発売が決まっていないデザイン家具・カバンや、おなじみのルフトハンザ航空などがブースを出してました。
今年のデザイナーズウィークは、ドイツ・オランダ・韓国の展示が目立ちました。

DSCN1105 
オランダブースのsenz unblera.風速100mにも耐える独特の形状です。

DSCN1124
椅子の特集コーナー。

 

DSCN1106
クリエイターや美大、メーカーの展示が多いのですが、その中で目立ったのはこの「日蓮宗」ブース。

DSCN1109 DSCN1108
上質のお香の匂いを感じながら、厳かにお経が流れるブースでした。コンテナを使った展示ながら、まるで名刹のような雰囲気。

 

DSCN1115 
学生の展示ブースの中では、この照明器具と兼用のスピーカーが面白かったです。ベッドサイドに置きたい。ただ、ブースのせいかもしれませんが、音はあまり聞こえなかった。

 

 DSCN1125DSCN1128
会場内は物販もありした。左側の、畳をリサイクルしたベルトはドイツのデザイナー、右側の、看板をリサイクルしたトートバッグはインドのデザイナーでした。インドのデザイナーは国内で販売予定はたっておらず、飛行機でたくさん持ち込んだとか。

 

DSCN1129
自分もトートバッグを買いました。

他の写真はこちら(flickr

先週のお話ですが、第2回マネタイズHacksに参加してきました。

今回は各人がくじ引きでチームをわけて、チームごとにtumblrのマネタイズを考える、とのこと。

自分はGチームで、ほかに

はてなの川崎さん

ライブドアの佐々木さん

paperboy&coの谷脇さん

と、全員前回参加者の、何とも濃いメンバーとなりました。

なんとも難問なtumblrのマネタイズ。バナー貼るとか、通常の広告的なアイデアはあまり出ず、「tumblrが好きでたまらない人々がお金を出し合うアイデアはないか?」と言いあって出してきたのが、この「tunoblr(たのぶらー)」
IMG_0191 

tumblrユーザーの間で使える仮想通貨を発行して、ユーザー間で「俺の好きな画像を100枚探してきてくれ」みたいな依頼ができる、というマネタイズ方法でした。ほかに、「ニコニコ市場」のtumblr版で、ただしアフィリエイトスパムの対象にならないよう、貼り付けた人には1円も入らない、みたいなマネタイズ方法も考えたのですが…

残念ながら2位に終わってしまいました。

image image
Gチームメンバー 写真は佐々木さんのブログから

トップを取ったチームは、なんとびっくり「ネーミングライツ」。tumblrの名前を期間限定で売る、と。

たしかに、サグールはともかく、twitterやtumblrが今から名前を変えても、ユーザー数が減るとは考えづらいし、しかも一挙にネットジャンキーの間で知名度を上げることができます。
実現可能性はともかく、これまでに出てこなかったような面白いアイデアでした。

その後の懇親会も面白く、ぜひまた次回も参加したいと思います。
次回はまた、第1回同様、ややキツくても、自社のエピソードを話し合う会にしたいところですが…
(今回は、楽しかったけど、自社サイトでないぶんだけ、やや現実離れしたアイデアが多く出てきた気が..)

 

主催してくださったみなさん、場所を提供してくださったネットイヤーさま、ありがとうございました!

 

Livedoorニュース
http://news.livedoor.com/article/detail/3882199/

Livedoorディレクターズブログ
http://blog.livedoor.jp/ld_directors/archives/51119658.html

はてな川崎さん
http://d.hatena.ne.jp/kawasaki/20081031/1225447953
ライブドア佐々木さん
http://blog.livedoor.jp/sasakill/archives/50210592.html

ペパボ 谷脇さん
http://biz.kulop.com/?eid=157

今回は、とにかく一大イベントでした。

 

大賞のChamap

IMG_0150 
土地情報を利用したチャットで、すごく作り込んであるサービスです!

 

IMG_0154

今回特別審査員として参加させていただいた、弊社猪子の、乾杯の音頭
「開発者万歳!みんなヒキコモっていいサービスを作りましょう!」というあいさつで会場が微妙に沸きました。

ちなみに猪子特別賞は

猪子寿之審査員特別賞

  1. みんなの電車ツアーズ

作り込みがすばらしいです。
電車の速度に合わせて周辺情報が表示されることで、ついついいろいろな情報を知りたくなるアイデア、電車の音や「警笛」みたいな遊び心も楽しい。

 

IMG_0152
受賞者皆さんの様子

 

その他すべての結果発表はこちらです!
http://mashupaward.jp/winner/

 

来年もチームラボは参加します!ぜひマッシュアップの開発願います!

サグール賞につづいてワッカ賞です。

 ワッカ賞はフィールドビジョン様のフォカッチャが選ばれました!

「フォカッチャ」は、フラッシュを利用したスライドショームービーです。
ブラウザでアクセスするだけで簡単に作成できるのが特徴です。
また、作成したフォカッチャは自動的に保存されます。フォカッチャのアドレスを教えてあげる事で、どこからでも、みんなでフォカッチャを楽しむ事ができます。
完成したフォカッチャのサンプルを見る。(別ウィンドウが開きます)

とのことで、すでに授賞式の様子がフォカッチャになってます!

http://dividia.sakura.ne.jp/mashup4th/playfocaccia.cgi?t=pc&id=1081021082744qudkngmkrn

 このスライドショーの音楽として、waccaが使われています。

 

 受賞したフィールドビジョンの長田様はその後ラボにも遊びに来られて、ラボの様子もフォカッチャにしてくださいました。

http://dividia.sakura.ne.jp/mashup4th/playfocaccia.cgi?t=pc&id=1081030184858trbdkfbtie
 
 ちなみに、ワッカ賞の賞品はチームラボTシャツでした!
IMG_0025 ←チームラボTシャツを着るチームラボ社員

  もう2週間も前になってしまいますが、第4回のMashup awardに行ってきました。

チームラボは第2回から参加しているのですが、回を重ねるごとに規模が大きくなってきています。
今年は400近くの応募作品、50社を超える企業参加で、プレスの数も多い一大イベントになってました。

 

さて、気になるサグール賞の発表は…

Prism でした!

prism

Prismについて

Prismはウィキペディア (Wikipedia)、企業が提供している様々なAPIを「汎用連想計算エンジン GETA」を用いてユーザーに有益な情報を一括で提供する検索システムです。

ユーザーが求める情報から連想される情報を提供し、コンテンツ同士の繋がりから検索行動を抑えることで、知的探究心をくすぐり「新しい何かを発見する」がコンセプトとなっています。

wikipediaの情報のまわりに、youtubeの動画やAmazonの関連商品、YAHOO知恵袋の関連情報などが表示されるのですが、同じ用語でweb検索の結果を出すことができ、エンジンの一番最初にSagoolが出てきます!

prism2

Prismで麻生太郎を検索

受賞者の方とお話したのですが、「他の検索エンジンと違う結果が出てくるので、このサービスにマッチしている」と
ありがたい評価をいただきました!

ぜひアクセスしてみてください!

 

ちなみにサグール賞の賞品はサグールTシャツです。

DSCN0908 ←サグールTシャツを着る私

チームラボにて、CEATECにサグールテレビを出展してきました。
 他のブースを見て回る時間はあまり取れなかったのですが、目についたものをいくつか。

2008 CEATECアルバム(Picasa)

全体的には、写真にはあんまり残ってませんが、各ブースでデバイスやロボットの展示が目立ちました。パーソナルコンピュータの普及もあるていど頭打ちでしょうし、今の最先端はこのあたりなのでしょうね。
 会場でいちばん人を集めていたのは、ムラタセイサク君/セイコちゃんロボットのブースだと思います。

チームラボブースの感想もブログにいくつか上がっています。

[CEATEC08]TEAM LABさんの実力の片鱗が見えた気がした。
http://yasuyuki.vox.com/library/post/ceatec08team-lab.html

しーてっく
http://infibility.net/blog/2008/10/04/%E3%81%97%E3%83%BC%E3%81%A6%E3%81%A3%E3%81%8F/

オモロ動画検索「サグールテレビ」
http://cpg.buzzlog.jp/e97784.html

各企業がAPIを提供して、開発者によるマッシュアップを促進するMashup award

チームラボは第2回からSAGOOLWACCAでAPIを提供しています。
第4回にを迎えた今回は、さらにサグールテレビのAPIも、Mashup awardをきっかけに提供することになりました!
動画検索のAPIなので、いろいろと面白いサービスに使えると思います。
今年はチームラボ社長の猪子も審査員として参加し、より、Mashup awardを盛り上げていきます!

6/26に、参加企業(API提供企業)の懇親会がありました。もちろんサグールTシャツを着て参加してきました。
Mashup awardにはいろいろな会社が参加していて、BtoBのツールベンダーなど、普段自分たちがあまり話す機会がない人も多く、去年意気投合した知り合いと会うことも出来まして、とても面白い時間を過ごすことが出来ました。

DSCN0908
リクルートメディアテクノロジーラボ 川崎さんと

7/12にマッシュアップキャラバンとして、チームラボのAPIの使い方を、ラボのエンジニアが紹介します!
◆Mashup Caravan in TOKYO :7月12日(土)14:00〜

マッシュアップアワードの締め切りは9/16。サグール賞の選考には、自分も参加します。
面白いサービスの登場を期待しています!

チームラボのAPI一覧はこちら

今回は、8冊の本がプレゼンされ、うち

BEST SOFTWARE WRITING 
発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法
ダメな議論―論理思考で見抜く (ちくま新書)  
「分かりやすい表現」の技術―意図を正しく伝えるための16のルール (ブルーバックス)

 の4冊が、同数票でした。決選投票で、
BEST SOFTWARE WRITING 
発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法
ダメな議論―論理思考で見抜く (ちくま新書) 
 の3冊を購入することに決まりました!

 ちなみに読書会で購入した本を置いておく本棚も作成しました。
できてまだ2週間ほどですが、5-6名の利用があります。

 今回選ばれた本も、ぜひたくさん貸し出されるといいですね。

 今回プレゼンされた本は以下の通りです。
「読んでみたい!」という投票が多かった順に並べてあります。

————————–

BEST SOFTWARE WRITING
BEST SOFTWARE WRITING
posted with amazlet at 08.04.04
翔泳社
売り上げランキング: 6436

投票 3
決選投票 4  購入決定!

ポール・グレアムなど、ソフトウェア業界に働く人の名言(あくまでジョエルが選んだ)が並んでいる。
ジョエルらしく、辛辣だが的を射た話が、一つのテーマについて5-6ページで並んでいる。
一つ一つのコラムについていろいろな読み方ができるので、味わい深く、読むのに時間がかかる
————————–

————————–

発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法
トム・ケリー Tom Kelley ジョナサン・リットマン Jonathan Littman
早川書房
売り上げランキング: 3155

投票 3
決選投票 4 購入決定!

 この本はIDEOという、デザインをコンサルティングする会社の社長が、「問題を解決するデザインとは何か」と、「どうすればデザインする発想ができるか」ということが書かれている本です。
 発想力の強い人、論理的思考能力がある人など、いろいろな人がいる会社を、どうやればマネージメントできて、会議が回せるか、という本です。
ラボだと、デザインの会議をしていても、デザイナーが無理矢理論理的に話さないと、議論が成立しづらい。頭の中にあるトンガったものが、形に見せないと説得できない。結果、話し合って無難なものになってしまう。
 この本に書かれているような点に気をつければ、よりクリエイティブな仕事ができるようになるのではないか。
————————–

————————–

ダメな議論―論理思考で見抜く (ちくま新書)
飯田 泰之
筑摩書房
売り上げランキング: 16583

投票  3
決選投票 4 購入決定!

世の中の本、特にビジネス本はダメ本だらけです。新聞もデタラメばかりです。

大学で何かを専攻した人なら、そのジャンルに関する新聞記事を読むと、デタラメばかりに見えます。そういう経験をした人は多いでしょう。しかし、自分の専門以外の記事についてはそれなりにもっともに見えるはずです。しかしそれらのジャンルにも専門家はいるはずで、彼らからはその記事はデタラメに見えているだろうことは想像に難くないでしょう。つまり、専門家が見たらデタラメに思えることの集合体が新聞なのです。

この本は、そういう新聞のデタラメ、ウソを、予備知識なしで見分けることができるようになる本です。そのために、この本は5つのチェックポイントを提供しています。

(1)単純なデータ観察で否定されないか。
「反社会学講座」で有名になった、「少年犯罪の増加」という嘘とか。

(2)定義の間違いがないか。
 たとえば、デフレ脱却はよく言われるが、よくよく彼らの主張を聞いてみると、経済学で一般的に使われるデフレという語と違う定義を使っていたりする。

(3)無内容または反証不可能な言説
 「生きる力」とか、「国際競争力」とか。こういう言葉は定義できないし、反証もできない。こういう記事を信用するとムードだけに流されることになる。

(4)難解な理論の不安定な結論
 最先端の理論は、逆に言えばまだ歴史の検証を経ていない不確かなもので、必ずしも信用できない。「最先端の理論では、地球の温暖化が進んで人類は滅びる」などの類。

(5)比喩とたとえ話に支えられた主張
 もう、何も言わなくても多く出ると思います。「軍靴の音」とか。しかし、自分の考え方と一致する内容だと、意外にそのまま受け入れてしまうものです。

この5つを抜くと、実は新聞記事は読むところがほとんどなくなってしまいます。

最初のうちは、その新聞記事のデタラメを指摘する部分をゲラゲラ笑って読めるのですが、そのうち、常識と思って信じていたことがガラガラと崩れていく(「食糧自給率の危機」だとか)ので、不安や不快感を感じるかもしれません。
そのめまいのような感覚こそ、この本が単なる娯楽ではなく、読者に本当に役に立つ情報を提供している証拠ではないかと思います。

ちなみにこの本の第1章では、占い師がどうやって当てるのか、もっと正確には客の望むような答えを言うことができるのか(コールドリーディングとか)といった、(1)-(5)のそれを悪用して実践する方法が紹介されています。

————————–

————————– 

投票3
決選投票 2  購入見送り!

 「意図を正しく伝えるための16のルール」ということで、道路標識やコンピュータのマニュアル、駅の路線案内などを例に、「誤解をなくし、スッとあたまに入ってくるようなアウトプットを作るにはどうするか」をわかりやすく書いてあります。
 情報デザイン的な配置やカテゴリ分けの話だけでなく、文章の書き方などにも対象は及びます。
 具体例、「なぜそうなったか」という抽象的な話、実践するためのチェックポイントと、内容を身につけ、応用するための本になっているのがよいところだと思います。
————————–

————————–

暗号解読―ロゼッタストーンから量子暗号まで
サイモン シン
新潮社
売り上げランキング: 12499

投票2

ロゼッタストーンに書かれた最古の暗号から最新の量子暗号まで、人類が触れてきたいろいろな暗号が紹介されている。

この手の本は、技術に詳しいが面白みのない専門書か、ストーリーは面白いが技術部分は曖昧な読み物のどちらかになりがちだが、この本は両者の良いところが両立されている点が素晴らしい。多くの暗号の詳細解説とともに、その暗号が開発された時代背景やそれが破られた経緯などが語られているので、呼んでいて引き込まれる。この本を読むと、今では当たり前のように使われている公開鍵暗号方式がいかに大きなブレイクスルーであったかがわかり、感動する。

著者のサイモン・シンは、他にフェルマーの最終定理や宇宙のビッグバンを扱った本も書いており、これらも同様に面白い。
————————–

————————–

デザインの生態学―新しいデザインの教科書
後藤 武 佐々木 正人 深澤 直人
東京書籍
売り上げランキング: 77147

投票 2
建築家の後藤 武さん、アフォーダンスの研究者 佐々木 正人さん、デザイナーの深澤 直人さんが書いた本です。
アフォーダンスというのは、環境自体が情報を持っていて、どうやって人間がそれを把握できるのか(たとえば、掴めるものを掴むとか)について書いてある。
 本全体として、「どうやれば説明なしでモノが使えるようにできるか」というテーマに書かれている。
 たとえば、無印良品の換気扇みたいな形のCDプレーヤーとか。プレーヤーについているひもを引っ張れば再生されるのだが、誰でも説明抜きで「ひもを引っ張れば再生される」ということが理解できる。
 特に定義に終始しているわけではなくて、「どうすればそういうデザインが実現できるか」の実践的な内容で、おもしろくてためになる。

今、webはデザインの地位が低い(たとえば、工業界における工業デザイナーの地位に比べると)と考えているが、こういう本で理論武装することで、デザインの地位を上げた方がいいものが作れると思う。
新しいモノを作るときにはモックアップだ、ということがこの本からはわかる。
モックアップを作るためにどうすべきか、ということが、「発想する会社」からわかる
————————–

————————–

教育を経済学で考える
教育を経済学で考える
posted with amazlet at 08.04.04
小塩 隆士
日本評論社
売り上げランキング: 35980

投票 1
 みなさん教育には一家言ありますが、たいていの教育論はムードやスローガンに頼ったデタラメです。
 この本は、そういうムードやスローガンに頼らず、教育を”投資”と”消費”の2つに分析して、過去の教育について投資と消費について分析していく、すごくおもしろい本です。
————————–

————————–

人を動かす
人を動かす 新装版
posted with amazlet at 08.04.04
デール カーネギー Dale Carnegie 山口 博
創元社
売り上げランキング: 26

投票 0
戦前からある本です。あらゆる自己啓発本の元祖とも言われています。今は自己啓発本などいくらでもあるわけですが、当時は全然なかったのです。

自己啓発本というだけで読む気が失せる人も多いと思いますが、どうかちょっと待ってください。私もそう感じる性質なのですが、この本については、自己啓発とはちょっと違った点で興味があるのです。

この本は、人間がいかに非論理的で、怒りっぽくて、うぬぼれ屋で、話が通じないものか、そしてそういう人間を説得するためにはどう振る舞えばいいかが延々と書いてあります。ポイントは、いかに相手の自尊心を満足させるかです。
そこを踏まえて行動すると、取り付くしまのない敵と思っていた相手が、頼もしい見方になってくれたりするのだそうで、そういう逸話や事例が山ほど載っています。

これは特に「自分は論理的に話しているのに、人に通じない」と悩んでいる人には福音のように感じられるかもしれません。実際、Amazonではこの本で人生が変わったといった絶賛するレビューが150件以上も載っています。

しかし私見なのですが、この本は必ずしも、読んで手放しで喜べるような本ではないと思うのです。実際、私はこの本を読んでかなり落ち込みました。それがこの本をここで取り上げたくなった理由です。

同じく私見なのですが、この本の著者は、ある1点については周到に避けています。それも最も重要な点です。その一点とは何か、ここでは書きません。みなさんに先入観を持たせたくないからです。

この本を読んだ人がいたら、ぜひその点について話を聞かせてもらいたいです。
私の受け取り方と人の受け取り方を比較してみたいのです。
————————–

チームラボ読書会、第2回です!今回は7冊の図書が推薦され、3冊の本をラボで購入することになりました!

 

ご冗談でしょう、ファインマンさん〈上〉 (岩波現代文庫)
ご冗談でしょう、ファインマンさん〈下〉 (岩波現代文庫)
仕事を加速する技術

今回の本7冊の紹介はこんな感じです!

———————————————

ご冗談でしょう、ファインマンさん〈上〉 (岩波現代文庫)
リチャード P. ファインマン Richard P. Feynman 大貫 昌子
岩波書店 (2000/01)
売り上げランキング: 130

 

ご冗談でしょう、ファインマンさん〈下〉 (岩波現代文庫)
リチャード P. ファインマン Richard P. Feynman 大貫 昌子
岩波書店 (2000/01)
売り上げランキング: 336

 読もうと思った人 4(ラボ読書会棚に置きます)

 物理学の天才、ファインマンさんは、世界一の天才のすべてを人をおちょくることに費やした人でした。
 この本にはそのようなオチョクリの話がいっぱい書いてある。

 ただ、その手の面白いエピソードが詰まった伝記本はいっぱいあるが、この本とほかの本を分けるポイントは、ファインマンが人をおちょくる・権威を否定することで、既存の学説の間違いを見つけ、新しい学説を立ち上げた人だったことを書いてあることにある。
 文中で、かつてずっと信じられていた学説が間違いだったことを実証する話がある。物理学はその学説から大きく外れた実験結果が出ると、結果のほうを否定していた。「それは物理学の恥の歴史である」と活写してることにある。
 権威を否定すること、アタマを使うことで、どのような価値を生み出せる人生が歩めるか、にあります。

———————————————

仕事を加速する技術
仕事を加速する技術
posted with amazlet on 08.02.26
梅津 信幸
ソフトバンククリエイティブ (2007/09/26)
売り上げランキング: 91875

 読もうと思った人 3 (ラボ読書会棚に置きます)

「あなたはコンピュータを理解していますか」、と同じ作者が書いたもので、
原理を把握し、それぞれを分析するという「あなたはコンピュータを理解していますか」と同じ手法で、仕事が分析されています。
 具体的には、情報のやり取りであるホワイトカラーの仕事を、同じく情報処理の機械であるコンピュータの処理になぞらえて要件把握(フェッチ)・手順の立案(デコード)・処理(実行)・報告(ストア)のフェーズにわけ、特に・無駄なデコードをなくすことで仕事全体の効率を上げるやり方が書かれています。
 これは、通り一遍の心構えやだれでも「わかってるけど、できない大事なこと」が書いてある、多くの仕事本とは一線を画す出来です。
 ログをとって問題点を洗い出してチューニングするなどの効率アップ方法、具体的にどんな道具を使うかなどが書いてあるのもオススメで、内容
がわかりやすいのもオススメする点ですが、「伝達可能であり、習得可能な、仕事能力の向上技術」という本はほかに読んだことがなく、オススメ
です。

———————————————

 読もうと思った人 1
 コンピュータは1930年代に根本の原理が発明されてから進化していない、情報を扱う機械です。
 その「情報」とは何なのか、コンピュータがどうやってその「情報を処理」しているのか、
「情報量が多い・少ない」、「情報が伝わる・伝わらない」ということはどういうことか、
 情報を研究する理論である計算機科学の考え、シャノンの定理やオートマトンという考え方など、そうした情報の根本が、非常にわかりやすい図で説明されていて、誰でもわかるように書かれてあります。
 ラボの言う、「情報化社会になって、アートもコンピュータも同じく情報を扱っている」という言葉の意味が、この本を読むと理解できたように思います。

 深いことを書いているにもかかわらず、説明がわかりやすくて例と図が適切なので、非常に読みやすく、いつ読んでも新しい発見があることも魅力です。

———————————————

メディチ・インパクト (Harvard business school press)
フランス・ヨハンソン 幾島 幸子
ランダムハウス講談社 (2005/11/26)
売り上げランキング: 49743

 読もうと思った人 1

中世ヨーロッパのメディチ家は多くの芸術家や学者などを集めて交流を奨励し
た。これが様々な文化の交流を呼び起こし、ルネサンスの隆盛の一因となった。

こんな歴史から、”優れたイノベーションは異文化が交わる「交差点」から生ま
れる”ということを解説した本です。単なる成功事例の説明だけではなく、連想
のバリアを壊すために意図的に交差点を作り出す「交差点ハンティング」の手法
の紹介や、失敗にくじけないための心構えなども解説されています。

「イノベーターは成功したから多くを生み出すのではなく、多くを生み出すから
成功したのだ」というのは本書の中の一文で、アイディアの量がアイディアの質
を生むことが述べられています。天才と呼ばれる人たちが生涯で最高の仕事をし
た時期は、最も多くの作品を生み出した時期であり、結果として不出来な作品を
最も多く出した時期でもあるそうです。

新しいことに挑んだ末の失敗は、一般的な慣習に従った結果の失敗よりも冷たい
目にさらされがちです。そんな社会のなかでイノベーションを目指す人にとっ
て、この本に書かれていることは大きな力になるかもしれません。

———————————————

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)
クレイトン・クリステンセン 玉田 俊平太 伊豆原 弓
翔泳社 (2001/07)
売り上げランキング: 649

 読もうと思った人 1

 技術には
 持続技術(もともとの技術の性能を上げるもの)と、
 破壊的技術(今あるものの性能が下がる代わりに安くとか速くとかできる)
 があるとする。

 最初にまず、持続技術として性能が高いものが出てくる。そのころの破壊的技術は、価格が安くても、顧客が求めるところにいかないので、意味がない。
 ところが、顧客が求める水準はあまりあがらない。
 そのうち、破壊的技術の水準が、顧客の水準に届く。そうなると、一気に安価なものが売れてしまう。

 こうした、持続的技術と破壊的技術の追いかけっこをいろいろ調べて分析したところが、この本の前半。

 本の後半は、持続的技術を作っていた人間も、作ろうと思えば破壊的技術をつくれたはずなのに、なぜ作らなかったか?の、研究を記してきている。

 それは、ハイエンドの製品を好む顧客の話をずっと聞いてきたマーケティングが原因であったり、ハイエンド製品のもたらす高い利益率を前提にした経営であったりする。その事例研究は非常に興味深いし、市場にあるほとんどのものに応用できて面白い。
 ここ数年のデジカメ、ゲーム機などは、ほとんど発展した持続的技術がまさに破壊的技術に取って変わられる段階にある。

———————————————

ブルー・オーシャン戦略 競争のない世界を創造する (Harvard business school press)
W・チャン・キム レネ・モボルニュ 有賀 裕子
ランダムハウス講談社 (2005/06/21)
売り上げランキング: 589

 

 読もうと思った人 1

 前職でIBMのコンサルタントから進められました。
 この「ブルー・オーシャン」ですが、これは競争のない市場を指します。
それに対して、価格競争、性能競争などの激しい市場をレッドオーシャンと表します。
どうやって、競争のないブルーオーシャン市場に行くか、という方法や事例が書いてあります。

 この本を読んで、しばらくは目の前のものが青くなったり赤くなったりするほど影響を受けました。

たとえば、美容室は一時期、「長い時間居心地よく過ごす」のがテーマの場所になり、
とはいえ床屋は「オッサンがやっていて、流行の髪型にしてくれない」場所でした。
QBハウスは、髪を切ることに専念すれば、10分ですむことを発見した。
ここで、10分ですむことで、
・予約が要らない
・マンガ本などがいらない
 という価値が生まれ、シャンプーを節約することで
・狭い場所で、水回りがなくても出せる
 という価値を生み出した。

 これによって、ほかの床屋が絶対出店できない場所で出店出来る、ブルーオーシャンに出て行くことができるようになった。
「ライバルよりも良いもの」という発想だと、レッドオーシャンにハマってしまう。

 自分が考えるに、Wiiもゲームの価値を考え直して、新しい価値を生み出すことで、ブルーオーシャンにたどり着いた事例だと思う。

 ラボはいかにブルー・オーシャンを生み出すかに価値がある会社なので、この本を読んで、ブルーオーシャンをいかに探すかを考えるのはいいん
じゃないか。

質問:
 その手のビジネス本は、毎回毎回、たとえば先行者利益とか規模の拡大とか、もともとの商売の優位性を言葉を変えて解説しているにすぎないの
ではないか?

 議論:・商売の本質が変わらないから、内容が似通っていてその時々の流行の考え方で
     分析した本がでることはあると思う。
    ・絶対儲かるような意思決定・フローがあるわけではないから、
     言葉や説明の仕方が違ういろいろな本を読むことで、成功事例失敗事例を
     深く考えることは必要だと思う

     などなど

———————————————

入門 GNU Emacs 第3版
入門 GNU Emacs 第3版
posted with amazlet on 08.02.26
Debra Cameron James Elliott Marc Loy Eric Raymond Bill Rosenblatt 半田 剣一 宮下 尚 新井 貴之 鈴木 和也
オライリー・ジャパン (2007/03/12)
売り上げランキング: 17547

読もうと思った人 0

Emacsはエディタではありません!OSです!
Emacsはどこのプラットフォームで走ろうが、その上にEmacsという環境を作っているものです。
たまたま、エディタの機能が多く含まれるからエディタと言われているだけです!
 EmacsはLispで構築され、Emacsで動くアプリはすべてLispによって構築されています。
 当時マルチウィンドウやカット&ペーストを実現するのはEmacsしかなかったため、今でも熱烈なユーザーがいます。
この本はEmacs愛好家・Emacsに興味を持った人にはお勧めです。

———————————————

計算機プログラムの構造と解釈
ジェラルド・ジェイ サスマン ジュリー サスマン ハロルド エイブルソン Gerald Jay Sussman Julie Sussman Harold Abelson 和田 英一
ピアソンエデュケーション (2000/02)
売り上げランキング: 28119

 現在開催中のSICP勉強会のため、会社で買うので、投票はしませんでした

これはアメリカの Structure and Interpretation of Computer Programs(SICP)の邦訳で、MIT の新一年生用の、計算機科学の教科書です。「計算機のすべてが書かれている」との呼び声のあるくらい、その網羅性と水準は高く、計算機科学の世界最高の教科書と呼ばれることもあります。コードはすべてLISP の方言 Scheme で書かれ、コンパイラ、OS、CPUの設計までを含んでいます。

しかし、それだけにその難易度は高く、当のMITでも多くの学生にはなかなか歯が立たなかったそうです。「喉の渇いた人に、消火栓で水を飲ませるようなもの」と表現する人もいるくらいでした。そのためもあって MIT では現在、この本は一年生の教科書としては使われておらず、授業は Python で行われているそうです。

今、大学教育は大きく変貌しつつあります。かつては、専門的な研究をするために必要な知識を網羅することを主目標としており、ついていけないのは学生の側に問題があるという考え方でした。そのため、どんな学生も、難易度の高い網羅性の高い本に取り組まざるを得ませんでした。

この SICP もまさにそういう思想の本で、序文のアラン・パーリスの言葉が如実にそれを表しています。「『この本は MIT にいるような人間にだけしか理解できない』などという幻想に捉われてはいけない。LISP プログラミングに関するまともな本なら、誰が生徒だろうとどこで使われようと、このような内容でなければならないのだ」

それに対して今は、学生がどれだけ理解できるかを重視するようになり、教科書も読みやすく理解しやすいものに変わりつつあります。すべての学生が高木貞治の「解析概論」で数学に入門するような時代は過ぎ去ったのです。

しかしそれとは別に、職業プログラマの間に、きちんとした計算機科学を身につけようという動きが広がっています。IT産業には次々新しいものが生まれますが、実は計算機科学の世界では古くから知られていたものを再発見している場合が多いのです。そのため、計算機科学の基礎を身につけて、車輪の再発明の繰り返しから脱したい、経験則で進めてきた技術開発に、理論的裏づけがほ
しいという機運が高まりつつあるのです。

そんな中でSICPは、この一冊で計算機科学の大半を網羅できることから、設定しやすい目標として、プログラマから熱い視線を浴びることになりました。

とは言え、MITの学生でも家庭教師なしでは脱落するような内容ですから、これを仕事の間に読みこなすことは容易ではありませんし、すべての人に薦められる本ではありません。

しかし、計算機について本当にきちんと理解したい人には、これはまさに最高の本でしょう。意欲と決意を持って、時間をかけてでも何とか読みこなしたいものです。

ちなみに、かのジョエル・スポルスキは、ペンシルベニア大学でこの本を元にした授業を受けましたが、見事に脱落し、「こんなのフェアじゃないと、長い泣き言のメールを私は教授に書き送った」そうです。

その声が聞き入れられたのか、今はその授業はJavaで行われているそうですが、ジョエルはそのことを後悔しているそうです。
http://local.joelonsoftware.com/mediawiki/index.php/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA

———————————————

その他議題

■参加者が減ったのはなんでだろう?また増やすにはどうすればいいだろう?
 ・日付が変わったのはよくない
 ・8時スタートだと、終わると10時になってしまう。遅いからでは
 もう少し参加者が増えるように、メーリングリストなどで意見を出しましょう

いよいよ最終回。今日のテーマはデバッグです!

 

■Rubyにおけるデバッグの特色…
 Rubyは型のない言語で、スクリプト言語なのでコンパイルもない。
なので、コンパイル時の型チェックによってバグが見つかることも無い。

 ただし、Rubyのオブジェクトには型があり、これが実行時にバグを発見する大きな手がかりになっている。Rubyには他言語のような自動型変換があまり無く、型が異なるオブジェクト同士の計算はエラーになる場合が多い。

 型がない言語の割に、バグが多いわけでもないのは、前回発表されたテストや、今回発表されるような豊富なデバッグツールで、バグを少なくする工夫がいくつもあるから。

とくに、書いてる最中にprintf やpなどを送り込めば、その場で出力ができるのはとても手軽。
型によってバグを減らすのではなく、バグの修正をしやすくすることにより品質を上げようというものがRubyの文化です。

——————-
トリビア..printf
これは Rubyの関数名だが、C の同名、ほぼ同機能の関数がオリジナル。Cのデバッグで本体コードにprintf を埋め込むことが多かったことに由来。
Rubyでは printf ではなく、p や puts を使うことが多い。
——————-

例:
>> 1 + “1″
TypeError: String can’t be coerced into Fixnum
    from (irb):1:in `+’
    from (irb):1
>> 1 + “1″.to_i
=> 2
>> 1.to_s + “1″
=> “11″

■デバッグ実演
Rubyに標準で付属するデバッガを使う場合など
最初にプログラムのブレークポイントを設定して、プログラムを途中まで走らせるようにし、ステップ実行ができるようにします。
しかし、普段はデバッガを使う必要はありません。
たいがいはprint -f で足ります。
というか「print -fで実行できないようなコードは書くな!」
(複雑で終えないようなものを作るのはRubyらしくない)

——————-
トリビア..Rubyの開発環境

そもそも統合開発環境があまりないこともあって、正直、デバッグ自体はJavaとEclipseのほうがやりやすい。統合開発環境としてはNetBeansが最近有名だが、さほど普及していない。
またはemacsやvi上で開発支援ツールを使うことになる。

自動でリファクタしてくれるツールもあるが、値や型名が変わって、setされることが多いRubyでは、どういう修正が加えられるのかわからず、怖くて使えない。EmacsやViは、今開いているウィンドウの中(Emacsは開いている複数のウィンドウ)だけで補完をしようという考え方
——————-

ユニットテストを使うようになると、そもそもデバッガの出番は減ってくる。プログラムをもっと細かく して、常々ユニットテストするようになると、デバッガを使わなくてもバグを追いかけられるようになる。

テストをテストするコードはないので、重複しようがなんだろうが、テストコードはあとで読めてバグが入り込まないように、ダラダラと長く書いたほうがよい。

参考URL
JUnit 実践講座 -
プログラミングスタイルガイド
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/junit/programming-style-guide.html
(JavaのJUnitだが、基本は同じ)

RSpecという、仕様書を書くかのようにテストを実行するツールもあります。
http://jp.rubyist.net/magazine/?0021-Rspec

みんなでテストコードを書きましょう!

 

■デバッグのやりかたについて

Ruby Debugで検索するといくつかサイトが出てきます。

特にこのサイト
Ruby で debug する7つの方法 - 川o・-・)<2nd life
http://d.hatena.ne.jp/secondlife/20061010/1160453355
のデバッグのやりかたは参考になります。

ppというコマンドがあり、デバッグ時の出力を見やすくしてくれます。
べったり表示するのではなく、見やすくインデントして表示してくれます。

実行中に表示する値についてもp callerで実行すると、それぞれの値について、どういうメソッドを経由して到着したかがわかり、追いやすくなっています。

set trace_funcで実行すれば、プログラム内のすべての関数をtraceつきで実行してくれるので、非常に詳細に追いかけることができます。

railsではloggerの実行もあるていど準備されていて、使いやすくなっています。

また、profilerを実行すると、どのメソッドが何回呼ばれたか、それぞれの実行時間などがわかるので、高速化のチューニングに役立ちます。

 

■先週紹介できなかった、テストに使うメソッドassert_selectの補足

assert_select
テストの成功条件をCSSのセレクタの構文を使って簡単に記述することができるので、これまで難しかったviewのテストが簡単にできる。

Railsでのプログラミングは、基本的に一人ですべてのコード(本体もテストも)書くことが前提となっている。

——————-

以下、テストの方法についての議論が続きました。

 テストドリブン開発方法の功罪とか、
 仕様理解とテストの役割とか、
 グループで開発する際のテストの役割とか、
 テストコードは誰が書くべきか
 (プロジェクトマネージャーか、プログラム書いた本人か、
  テスターかなど)

■JRuby
オマケとして、普段Javaを使っている人のために、JRubyを紹介しました。
JRubyは、JVM上で動作しますが、Rubyと同じインタプリタでコンパイル不要、
文法もRubyそのものです。そしてJavaのライブラリをそのまま使うことができ
ます。サンプルとして、Javaで書かれたオープンソース検索エンジン Lucene
のインデックスを生成するスクリプトを紹介しました。

Read the rest of this entry »

第8回 Ruby勉強会
 1/24  20:00-

チームラボのRuby勉強会も、第8回となりました。

今回はテストのコードレビューです!

■テストはRuby on railsの特徴
 テストの便利さはRuby on railsの大きな特徴で、テストの準備が最初から用意されています。
アプリケーションの雛形と同時に、テストの雛形も自動生成されます。

今回は、先週のプログラムを元に、テストのコードをレビューします!

あるシステムにユーザーを登録する・削除するという部分のテストで、モデルのテストを行います。
DBの構造を変化させた時などに、正しくない変化が及ぼされる範囲を、簡単に判断することができます。

 Railのいいところは、最初から
・開発環境(ローカルPC)
・テスト環境(ローカルPC)
・本番環境(本番)
の3つを使うように想定されています。テストをするとDBが荒れるので、専用の
DBを用意させるのです。これで繰り返しのテストも気軽に行えます。

実際にコードを書いたエンジニアから、
 「本体のコードよりテストコードの方が2-3倍も多く必要になる。これはだいぶつらい。またどこまで細かくテストを書くべきか、判断が

付かない。このノウハウは、本体プログラミングとまったく別の習熟が必要になる。」

Rubyに慣れたエンジニアからは、
 「どんな開発環境でもテストは大事だが、Railsはテストとセットで提供されているフレームワーク。だからプログラムのコードを書く時

点で、テストがしやすいようにコードを書くことを心がけたほうがいい。
 バグが発生したときにも、すぐに直してしまわず、まずバグを再現できるようなテストコードを書くこと。
またテストのしやすさのためには、メソッドを細かくすること。
 理想は1メソッド1行(笑)」
(これはタダのジョーク。1メソッドが1行では、コードをまとめて関数化する意味がない。現実的には10行、上限は20行というところか。

「メソッドを細かくするメリットは?」

 →メソッドを細かくすることでテストが容易になり、それぞれのメソッドの影響範囲が明確になる。パフォーマンスはある程度犠牲にな

るが、Rubyではさほどパフォーマンスが要求されないことが多いし、テストドリブン開発の基本でもある。

などの解説が出ました。

■Modelテスト開始!
 テスト用のコードをすでに書いてあるプログラムを使って、Ecripse上でUnittestを実行します。

テストは、コードの上から順番ではなく、テスト用メソッド名のアルファベット順に実行されます。

 テストランナーが、テスト用にデータの初期化など、準備をやってくれます。
 Railsでは、rake というツールを使って、テストコード全体を実行することができます。

 テスト用のDBが、デモ用の環境ではできてないなど、いくつか問題がありましたが、修正して無事テスト終了。

■Contollerテスト開始!
 ある程度はControllerのテストコードが生成されています。
また、テストに便利なライブラリが豊富に用意されています。コントローラをgetで呼ぶ、postで呼ぶ、その結果のHTTPステータスの判定、

リダイレクト先の判定、コントローラのインスタンス変数の値の取得、etc…
 これがRuby on Railsの大きな特徴で、JavaとRuby両方書く開発者からは、
「ここはもうホントに便利!」「ヤバい!」という声が飛びます。

「便利かもしれないが、いくつか独自な部分があるので、ここから入門した人はちょっと影響はあるかも..」

get,postを使って、パラメータがどうなっているかチェックするテストをしてします。

「今回のテストコード生成にかかったのはだいたい1日ぐらい」

 という声に、速い!という声が飛びました。

 実行して初回のエラーは1件。

追加の紹介:
インテグレーションテスト
 「ひとつのControllerであれば今のテストでいいんだけど、Railsにはインテグレーションテストというものがあって、複数のController

を使うシナリオテストみたいなものも書くことができる」

mocks
 「たとえば本番環境でしか用意できないデータ(たとえば、本番環境でないとインターネットに接続できないとか)をこのディレクトリ

においておくと、テスト時に自動で読んでくれる」

■コードレビュー1段目!
次は、勉強会でコードを書いた新人のレビューです。

例題として、サイコロプログラムを構築されました。
 サイコロプログラムは、コードが実行されると

・1秒待って
・1-6の数字のどこかを選択し、
・数字に対応する文章を順番にif elsif elseで
 呼び出す(3=「サンざんなお話!」とか)

 というプログラムです。
これを先輩社員がリファクタリングしていきます。

 「この場合はcase文を使うと、numを繰り返さずにすむので簡潔になります。」

 「イチから書き直すなら、文章と数字をハッシュに入れて、ランダムの数字をdata.lengthで6以外も対応できるようにします。」

会場から「ここはハッシュよりリストの方が」というツッコミが入り、コードはさらに洗練されていきました。

■コードレビュー2段!
 実際に業務で使ったちょっとしたプログラムで、
 「任意でエラーコードを出してくれるhttpサーバー」
 を作りました。

 httpのURLが、/数字 だったら、数字をHTTPのステータスコードとして返します。
http://localhost/300だったら300番とか。

たった50行程度でテスト用ウェブサーバが作れること、それが単なるWindowsマシンで動くことに、会場からはどよめきの声が上がりました

■コードレビュー3段!
 wordのテキスト(docファイル)内をマルチファイル検索するスクリプト
 (日本語も正規表現も使える)

Windows の OLE経由で、MS-Wordを不可視で起動して呼び出すことで、Wordで書かれたファイルを検索する。

■コードレビュー4段!

BMI計算スクリプトのページ。
IEの中で、RubyがJavaScriptのように動く!

HTML(HTA)ページをGUIとして使えるので、バッチではない対話的プログラムを作るのに便利。

Windows環境で、ActiveScriptRubyをインストールした場合だけ動作する。

 デバッグについては今回できなかったので、勉強会はもう1回追加で行われることになりました!

これ、面白いですね。

コード面接 - jkondoの日記

先週、今週と続けて技術者採用面接が続いている。最近はこうした面接の際に、「コード面接」とでも言うべきものを始めている。今までも、社員と一緒に人生ゲームとかをやってもらうゲーム面接をやっていたんだけど、今年からはこれの代わりにより実際の業務に近いことを社員の前で実演してもらうようになった。

エンジニアの場合にはやはりコードを書いてもらうのが一番、という事で、いくつか用意したお題の中から好きなものを選んでもらって、30分から1時間くらいでコードを書いて動かしてもらう。大型の液晶テレビパソコンディスプレイを映してもらって、それを他の社員が見守る中コードを書いてもらっている。

おんなじことをマーケ・企画でやったらどんな風になるだろう。提案書作成面接とプレゼン面接かな?

 新年最初のRuby講習会です!

01/10 第7回 Rails 実践道場(1)
        ~ まずは基本の型から ~

     プロジェクトコードレビュー(I間)
20:00-22:00

 今回は、あるクライアント様が見学に来てくださいました。
社内でRubyの利用を検討しているそうです。

 今日は昨年の新卒で今はマネージャーをしているI間君が書いた、
チームラボのプロジェクトで実際に動くコードを、みんなでレビューします!

 ある社内プロジェクトの管理画面用に書いたコードを、みんなでレビューしていきます。

 機能としては、
・利用者IDの発行
・ログイン/ログアウト
 の部分をレビューします。

 動作は無事にしたのですが、ソースを表示したとたんに、

「三項演算子の中ではあまり複雑なことをしないほうが…」
「その作成したclassの元ソースを見せてくれ」

 など、先輩社員からのチェックが入ります。

 チェックに対してもほかの社員から、
「for loopが多いけど、ブロックは使わないの?」
 →「それはどっちでもいいんじゃないか?」など、ほかのツッコミが入ります。

 「”必須チェック”,”よく変更するようなポイント”
 などを、うまく設計してコーディングしている」など、誉めるコメントが多々出ました。

 出た質問・アドバイス
 アドバイス:
 「migrateを使いにくい場合、executeを使えば、慣れてるSQLがそのまま通る」

 質問「Validetionはどこでかけてる?」
 回答「valid_kana等、チェックとエラーメッセージを出すアプリをmodule化して、
    共通して使えるようにしている」

 アドバイス:
 「JAVAのfor ループとRubyのfor ループはそれぞれ違い、
  Rubyのforループ は名前空間が独立していない。
  ループの中で宣言、変更した変数が、
  ループの外に影響を与えてしまうことを
  考えると、ブロックを使った方が良い」

 アドバイス:
 「組み込み変数で、$:ではなく、$LOAD_PATH を使うように。
  Perl的な短い変数名は可読性を下げる。」

総評:
 正直、Rails初めて1ヶ月ということでもっとひどいコードがでてくるかと
思ったが、細かい拡張が入っていたり、ずっとRubyっぽいコードが出てきていたので