菅直人 vs. 経済産業省の戦いが壮絶になって来た
福島第一原発での事故以来、私も含めてあまり一般の人たちに知られていなかった数々の問題点が見えて来たわけだが、一番注目すべきなのは、今回の事故の、そして事故後の政府と東電の対応のていたらくの諸悪の根源は東電でも管政権でもなく、霞ヶ関の官僚たちだ、という事実である。 そもそも日本の原発を中核においたエネルギー政策は、米ソの冷戦時代に、日本国民の「反核」感情が「反米→共産主義」という方向に傾きかけたとき、米国が「毒をもって毒を制す」と読売新聞の正力松太郎を利用して日本の世論をコントロールして無理矢理押し付けたもの（参照）。「保守＝原発推進、革新＝反原発」という日本特有の図式が作られたのもその時期だ。 最初は政治指導で原発を押し進めて来た霞ヶ関の官僚たちは、少しづつ「天下りの甘い罠」に陥り、電力業界と癒着し、星の数ほどの「天下りのための原発関連法人」を作り、「いまさら原発を辞めたら自分たちの将来が
ピュアAJAXアーキテクチャのススメ
先日、ここで発表したFacebookユーザーむけグループウェア「Fruence.com」。今年のトレンドになるであろう「ソシアル・アプリ」の実例という意味もあったが、私自身の中で少し前から形になりつつあった「AJAXを最大限に活用した新しい形にウェブ・アプリケーション」のアーキテクチャの実践という意味合いも大きい。 このアーキテクチャの特徴は以下の３つである。 サーバー側は、JSON over HTTPのAPIとHTML/CSS（およびそのテンプレート）をスタティックな形でのみ提供する（サーバー側では、ダイナミックなHTMLの生成はしない） クライアント側では、JavaScriptを使ってサーバーから取得したJSONとHTMLのテンプレートを組み合わせて（データ・バインドして）表示する。 ウェブサイトはあたかも独立したアプリのように動き、操作中はURLは一切変化しない もともとは、HTML
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
「au向けのiPhoneは作ってはいけない」という契約になっている（らしい）
UWで受講している"General Management & Strategy"という授業の課題の一つが「携帯電話事業」に関する"Five Forces Analysis" (新規参入の難しさ、業界内の戦いの厳しさ、などの５つの側面から業界を分析すること)。２０００年からこの業界で働いている上に、iPhoneやgPhoneに関しては誰にも頼まれてもいないのにブログで色々と書きまくっている私としては、「待ってました」という感じのテーマ。 とは言っても、何の資料も使わずに書いても説得力がないので、ネットで少し調べものをしてみたところ、思わぬ発見。今年の５月の記事(USAToday)だが、AT&TとAppleの間の契約について、公式発表には含まれていない条件が書かれている。 AT&T has exclusive U.S. distribution rights for five years —
ユーザー・インターフェイスの設計に大切なのはデザイン・ポリシー
何かの「ユーザー・インターフェイス」を決める時に大切なことは、自分なりのはっきりとした「デザイン・ポリシー」を持って、誰が何と言おうと最後までそれをしっかりと押し通すこと。そういう「柱」をしっかりと持たないで作ったものは、往々にして「妥協の産物」になってしまう。 私が常に心がけていること（つまり、私のデザイン・ポリシー）は、「ユーザー・シナリオを８０：２０ルールで切り分け、常に８０の方（つまり多くの人が使うだろう機能）を最優先にした設計にし、２０の方（あった方が良いかもしれない機能、一部の人が必要とするかもしれない機能）は思い切って犠牲にする」こと。 典型的な良い例が、Youtubeを見るためのサービス、Rimo と oreseg。 機能的には、カテゴリー分けはしてくれているし、サムネールから自分で見たいものを選べるし、oresegの方が上である。しかし、「ただだらしなく面白そうなビデオを
「Why?」と言えない日本
先日、たまたまティーンエージャー（13～19才）の子供を持つ親のための講習会に出る機会があったのだが、そこで『二つのWhy』という話を聞いた。日本語にも若干通じる部分があるので、今日はそれに関する英語うんちく。 その講師は、親はティーンエージャーの「Why」には二種類あるので注意すべき、と主張する。一つは単なる質問の「Why」で、この場合は普通に答えて良い。もう一つが、こどもが自分が何かを拒否したい気持ちを伝えたくて「Why」と言っている場合。この場合に、その気持ちを理解しておきながら、理屈だけで納得させようとすると泥沼にはまってしまう、と指摘するのだ。 良い例が登校拒否のこども。親が「学校に行きなさい」というと「なぜ学校にいかなければいけないの？」と言い返してくる。そこで親としてはつい「ちゃんと学校を卒業しなければ、ちゃんとした会社に就職できないんだよ」などと答えて説得を試みたくなるのだ
ビル・ゲイツの家のトイレは流そうとすると「本当に流しますか？」と警告してくる
今回のみずほ証券による株の誤注文事件は、１株を６１万円で売るところを、オペレーターが誤って「６１万株を１円で」と誤入力してしまったのが原因だが、その際に端末には市場価格との隔たりを示す警告が表示されたにもかかわらず、オペレーターが「（警告が）よく出るので慣れの中で結果的に無視してしまった」という点が注目に値する。 以前にも、「事故防止の難しさ」というエントリーで触れたことがあるが、「不必要な警告をしょっちゅう見ているとそれに慣れてしまい、本当に対応が必要な時にも無視してしまう」というのは人間の性である。この手のミスをした人を一方的に非難したり、「これはヒューマン・エラーでした、今後はこのようなことを繰り返さないように注意します」と謝るのは簡単だが、それでは根本的な事故防止はできない。 「不要な警告」と言えば、パソコンがその代表選手。ファイルを消去した時の「本当に消去したいですか？」という警
Life is beautiful: 大人になると誰も間違いを指摘してくれなくなる
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
Life is beautiful: Web2.0時代のリミックス文化は「２１世紀のルネッサンス」
最近リミックス（Remix）という言葉を目にする機会が増えている。はてなダイアリーの辞書に、「楽曲制作で、完成された曲の録音素材をもとに、編集したり、新たに素材を加えたりして、別のアプローチからその曲を再構築すること。または再構築されたその曲のこと。」と書かれている通り（参照）、一般には曲にのみ適用される場合が多いようだ。 しかし、リミックスという概念を、音楽に限らず、画像、映像、文章、ソフトウェア、なども含めた人間の創作活動全てに適用してみると、色々と面白いことが見えてくる。 １）既存の曲に画像や字幕をリミックスしたFlashアート（「恋のマイアヒ」、「もすかう」など） ２）他人のブログエントリーやニュースの記事を引用しつつ自分の意見をリミックスするブログエントリー ３）複数のプログラマーがそれぞれの変更・改良をコミュニティに還元するという形のリミックスで進化するオープンソース・プロジェ
Web2.0時代らしいエンジニアのクリエイティビティの引き出し方
Foxnews の "Lerning From Google" という記事を読んだ。特に目新しいことは書いていないのだが、その冒頭に書いてある、 The top executives at Google recently admitted that they kind of let their employees invent and develop whatever they think is cool and the company has no problem putting it online to see what happens. 【意訳】Googleの重役たちは、エンジニア自身がカッコいいと思うものであれば、何であれ（誰にも了解を取らずに）作ってしまって良く、会社としてもそれをそのままサービスとして公開してしまってユーザーがどう反応するかを試してみる、というやり方が全然かまわ
Life is beautiful: プロトタイプ作りの効用
私の関わっているプロジェクトの一つに、「全く今まで存在しなかった形のデジタル・エンターテイメントを実現しよう」というとても楽しいプロジェクトがある。この手の大きなプロジェクトを成功させるには、「大きな夢を共有しつつ、同時に一つ一つ着実に駒を進めていくこと」が大切なのだが、なかなか簡単ではない。特に、まだ「最終的に目指すもの」のイメージがちゃんと共有されていないので、各チームの動きがちぐはぐなのだ。 そこで、私が「プロジェクトメンバー向けに、目指すライフスタイルのイメージ・ビデオを作ろう」と提案しているのだが、なかなか理解してもらえない。「プロジェクトが立ち上がったばかりなのに、そんなものはまだ作れない」とか、「もう少し見えてきてからにした方が良いのではないか」という否定的な意見が出るのだ。今日は、そんな人たちへのメッセージ。 私がもの作りをするときは、常にユーザー・インターフェイスのプロト
NHKにこそやって欲しいiTunesによるコンテンツ配信
米国ではディズニーが先頭を切って乗り出したビデオ配信だが、日本で最初にそれをやって欲しいのは、そしてやるべきなのは実はNHKなのではないかと私は思っている。 スキャンダル続きでイメージをすっかり悪くしてしまい、受信料の不払い問題で苦しむNHKだが、私は正直言ってNHKのコンテンツが大好きである。古くは学生時代にお世話になった「通信高校講座」から、「NHKスペシャル」、「プロジェクトX」、そして私の妻が大好きな「大河ドラマ」と、NHKのコンテンツにはクオリティの高いものが多い。我々の受信料で作られたそういったコンテンツは日本国民の貴重な財産であるし、NHKには今後ともクオリティの高いコンテンツを作り続けて欲しいと願っているのは私だけではないはずだ。 そんなNHKに今必要なのは、「NHKは生まれ変わった」という姿勢を国民にはっきりと見せることと、受信料収入に代わるビジネスモデルの確立である。そ
「ロングテール的な地デジ批判」の呼びかけ
先日の「アップルにして欲しい次の革命」というエントリーで、「地デジが大変な税金の無駄遣いだということをおおっぴらに指摘する人は少ない」と書いたが、本当にそうなのか少し調べて見た。すると、２００２年の時点で、「通信と放送研究会」というかなりまっとうな組織が、「地上波デジタル放送への国費投入に反対する」という声明を発表していたことを見つけた。 …数万円の基地局でテレビ番組を流せる時代に、1兆円以上の経費をかけて行われる地上波のデジタル化は時代錯誤であり、民放連の氏家斉一郎会長も認めるように、事業としても採算は取れない。ここで既成事実を認めると、今後はデジタル放送設備への公的資金（財政投融資を含む）投入の要求が出て、さらに国民負担がふくらむおそれが強い。… 「まともなことを発言する人もいるんだ」と安心する反面、これだけ明白に間違っていることをストップすることが出来ない日本の官僚システムが本当に悲
任天堂の「肩すかし」作戦とXavixPORT
ここの所、ゲーム業界の話題は「PS3やXBox360がどこまでゲームを進化させるか」にばかり集まっているが、私にはどうしても、ゲーム業界全体が「イノベーションのジレンマ」に書かれていた通りのシナリオを歩んでいるように見えてしかたがない。今年の春にシアトルで開かれたゲーム開発者向けのカンファレンスで、中堅のゲーム開発会社が壇上でこんなことを言っていたのを思い出す。 私の会社では平均して、DSのタイトルに約４０万ドル（約４０００万円）、PSPのタイトルに約８０万ドル（約８０００万円）の開発費を費やしています。PS2向けのタイトルとなると１００万ドル（一億円）を越します。開発費が高くなれば高くなるほど事業リスクは高くなり、それだけでは会社の運営は出来ません。そこで私の会社では、開発費が約２０万ドル（約２０００万円）ぐらいで済むGBA向けのタイトルを作り続けて確実な利益を稼ぎ出すことにより、そうい
Life is beautiful: Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ
最近、「これからのウェブ・アプリケーションはAjaxだ」という声を良く聞く。ソフトウェアを生業としているエンジニアとしては、この手の「流行もの（hype）」に触れた時には、表面的なものに踊らされずに、その本質を自分なりにしっかりと捕らえて消化・吸収して自分のものにしなければいけない。今までも、「オブジェクト指向」、「マルチ・ティアー・アーキテクチャー」、などの言葉が一人歩きするたびに、「これからは○○だ」とか「○○の時代は終わった」などと、過激なことを言って読者の目を引こうとだけするマスコミや企業のマーケティング戦略に数多くの人が踊らされてきた。 そんなノイズだらけのメッセージに混乱させられた結果、「Ｃではオブジェクト指向のプログラミングは出来ない」と信じているエンジニアがいまだに沢山いることは全く嘆かわしいことだ。「オブジェクト指向のプログラミング」は、設計姿勢・プログラミングスタイルに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
