放送と通信の壁に穴を開けたパナソニック
パナソニックが「テレビ放送と同時にネットから取得した情報を画面には表示しない」という放送業界と家電業界との紳士協定を破ったとして、新型テレビのCM放送を拒否されているそうだ（参照）。 一見何気ないニュースだが、これは既得権益を守るためのルールでガチガチに固められてイノベーションが起こりにくくなっている日本としては、非常に画期的なことである。 日本のテレビ放送には、BML(Broadcasting Markup Language)という仕様で文字を送る仕組みがついているが、これをわざわざ HTML にしなかった理由は、放送と通信の間に人為的な垣根をもうけて放送局の既得権益を維持しようという試み以外の何物でもなかった。 今回問題となっている「テレビ放送と同時にネットから取得した情報を画面には表示しない」という紳士協定も、テレビ放送にネットから取得してきたTweetや広告を重ねて表示されては、付
私なりに Apple が次に出すべきウェアラブル製品を考えてみた
エンジニアtypeに「『Google Glass』わたしならこう売る～ウエアラブル・コンピュータが超えるべき壁」というインタビュー記事を書いた。 主旨としては、「スカウタースタイルのデバイスを売るのであれば、消費者向けの汎用デバイスではなく、まずはニーズがはっきりとある医療や警察や整備などのバーティカル・マーケット向けに専用デバイスとしてハードウェアとソフトウェアの両方を使用目的に特化した形で作るべき」というものだ。 ある意味、今は「汎用パソコン」を作るタイミングではなく、「専用ワープロ」を作るタイミングなのだ。 日本のメーカーにも多いにチャンスがある。ガラパゴス化などは恐れる必要は全くない。とにかく特定のマーケットにはっきりとした価値を提供することに集中すべきだ。１０年後には、人々が「昔はこれなしでどうやって仕事をしていたのか想像できない」状況を作り出すことを目指すのだ。 ちなみに、アッ
Andy Rubin が Android の開発責任者から降りた件について
２月の終わりにスペインで開かれた「Mobile World Congress 2013」で、「Tizen」「Firefox OS」という二つのモバイルOSの発表が注目を集めたが、これらに絡めて「モバイルOSの動向」に関しての記事を執筆して欲しいというリクエストが複数のところから来た。 それはそれで書いているのだが、私がもっと注目しているは、Andy RubinがAndroidの開発責任者のポジションから外れた件だ。 Googleのことなので多少違う意味合いがあるのかも知れないが、これがMicrosoftであれば99.9%降格人事だ。 合議制でものが決まる日本とは違い、米国の場合、「何をどんな目的で作るか」という product vision に関しては開発責任者が全責任を追う。そのため、責任者が変われば、作るものも大きく変わってしまう。 優秀な人であればあるほど、上からあれこれと指示される
特許庁のシステム開発が破綻した本当の理由
特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には（１）コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、（２）霞ヶ関から流れて来るお金にたかる IT ゼネコン、（３）そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた９９億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ
node.js と thread hog の話（１）
ここ数日、 node.js で色々と作りはじめているのだが（node.js が一番力を発揮するのは、xmpp server や、push notification server のようにソケットを開きっぱなしにして非同期通信をするケースだと思うのだが、それについては来週のメルマガで詳しく解説する）、これで思い出すのが Microsoft 時代の「"thread hog" 退治」だ。 "thread hog" とは私が作った造語で、"memory hog" （メモリをやたらと使うプログラムのこと）と同じように、thread を不必要に作るプログラムのこと。 最初に出会った thread hog は、Microsoft が作っていた proxy server だった。コネクションが１０００を超すとやたらと遅くなり、しまいには落ちてしまうという欠点を持っていたため、一時は「出荷出来ないところか、
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
パナソニック経営陣への５つの提言
日本の家電メーカーのソフトウェアの作り方や、人材の活用方法の問題点関しては、このブログでもメルマガでも何度も指摘したが、その問題を浮き彫りにするブログエントリーを見つけたので紹介する。 パナソニックを退社しました ...私の部署では、絵に描いたような昔ながらのソフトウェア開発が行われていました。 単価計算は人月とステップ数。仕様書を書く上流工程が重要で、コーディングは単純作業という価値観のもとでの開発です。当然正社員はなかなかコーディングに携わることができませんでした。 また、単純作業とみなされがちなコーディングを効率化しようとするモチベーションが少なかったのか、いくつか作業環境で疑問に思うところもありました。例えば、メモリ 1GB ぐらいの遅いマシンでビルドしている、ディスプレイが17インチ、きちんとしたソース管理がない、などです。PCスペックやディスプレイなどは入社の時期によってはそこ
最新の研究で「低線量被曝にしきい値がない」ことが明確に
福島県放射線健康リスク管理アドバイザー・山下俊一長崎県大学教授は、就任以来「100ミリシーベルトは『しきい値』以下なので安全。毎時10マイクロシーベルト以下なら外で遊んでも大丈夫」と言い続けて来た。 実際のところは、「100ミリシーベルト以下の低線量被曝をした場合の癌による死亡リスクの増加が統計データにつきものの誤差にまぎれてしまい、測定できていなかった」というのが科学的に見て、もっとも客観的な表現であったにも関わらず、「100ミリシーベルトは大丈夫」と主張し続けた山下教授の無責任さは科学者にあるまじき姿だ。原子力ムラの住人、御用学者と批判されても仕方が無い言動だ。 しかし、１年前の話をいつまでもしていても意味がない。注目すべきは、この分野における最新の研究結果だ。 先週、放射線影響研究所から、広島・長崎の被曝者たちを５０年以上わたって追跡調査した結果、低線量被曝には「しきい値」などなく（
福島第一４号機プールのリスクに関する海外メディアの報道
下にビデオを貼付けてあるが、簡単に要約すると、 ４号機のプールは補強されているとは言え、地震で崩壊する可能性は十分にある 水がなくなった使用済み核燃料は自らの熱で発火し、チェルノブイリの１０倍のセシウムを環境中にばらまく すると、発電所の作業員は全員退去せざるをえなくなる その結果、他のプールの使用済み核燃料も冷やすことが出来なくなり、結果的にチェルノブイリの８５倍のセシウムが放出される こうなると放射能汚染は日本だけにとどまらず、グローバルなスケールでの人類の経験したことのない被害をもたらす 米国政府が、「東電などに任せず、一日でも早く燃料をプールから取り出してほしい」と日本政府に要求しているのは、まさにこれが理由である（参照）。 ４号機の使用済み核燃料プールが崩壊してメルトダウンしてしまったら，まさに「日本終了」になります．原発というのは国防上，極めてリスクの高い施設だということが政府
Facebookに学ぶソフトウェアを重視するカルチャー
日本のメーカーがソフトウェアを長年軽視してきたことは、ここで何度も指摘しているが、では「ソフトウェアを重視するカルチャー」とは、どんなものだろう。 Mark Zuckerberg が IPO に際して株主に書いた手紙にそれを象徴する文章があるので、ぜひとも読んでいただきたい。 To make sure all our engineers share this approach, we require all new engineers — even managers whose primary job will not be to write code — to go through a program called Bootcamp where they learn our codebase, our tools and our approach. There are a lot of
可視化された Android OS アップデート問題
先日、ここでも触れた Android OS のアップデート問題。Android 端末がどのくらいの勢いで「陳腐化（OSのアップデートから見放されること、セキュリティ・パッチの配布が止まること）」するかをとても分かりやすく表現しているブログ・エントリーを見つけたので紹介する。 Android Orphans: Visualizing a Sad History of Support iPhoneの場合（上から４つ）は、新機種が発売されてから３年間は陳腐化することはない（緑色）が、Android 端末の場合、大半がすぐに陳腐化（黄色から赤）してしまっていることが良く分かる。 特に問題なのは、発売当初から１〜２世代前のバージョンを搭載した「生まれた時から陳腐化」している端末。中でも Motorola Cliq XT が最悪で、発売された時から２世代遅れており、発売後３ヶ月で３世代遅れになり、その
福島第一にはメルトダウンした核燃料よりももっと危険なものがある
菅政権の内閣官房参与で、福島第一原発事故対策や原子力政策のアドバイザーだった田坂広志・多摩大学大学院教授が原発事故の教訓や今後の課題について語った講演「パンドラの箱」が公開されているので下に貼付けておく。 原子力発電を利用するというのは、その国全体にとって何を意味するのかをとても的確に表しているので、原発に賛成の人も反対の人もぜひとも見ていただきたい。特に使用済み核燃料の問題が技術的な問題ではなく社会的な問題であること、そして福島第一でもっとも危険な存在は実はメルトダウンしてしまった１〜３号機の核燃料ではなく、４号機のプールにあって取り出す事もままならない大量の使用済み核燃料であること、などが専門家の立場から的確に語られている（ビデオの40:00〜45:00あたり）。万が一４号機のプールがこれから起こる地震で壊れたりしたら、関東にも人が住めなくなるのだ。 １時間強と少し長いので、忙しい人は
「メインジョブ・エンジニア、サポジョブ・MBAというのが最強」の意味
偶然にも大震災と同時になってしまった３月１１日発売の「エンジニアとしての生き方」を読んだ読者の一人から、中で引用した「『メインジョブ・エンジニア、サポジョブ・MBAというのが最強』の真意が知りたい」との意見をいただいたので、ここで答えてみる。 まず最初に「メインジョブ」「サポジョブ」だが、これは私も一時期遊んでいたことのあるFFXI（ファイナル・ファンタジー XI）用語。このゲームを遊ぶには、まず最初に自分のキャラクターを作る必要があるのだが、その時に決めなければならないのが「メインジョブ」。体力と戦闘力はあるけど魔法は使えない戦士、戦闘力はないが攻撃的な魔法の得意な黒魔導士、などの選択肢の一つを選び、そのキャラクターを遊びながら育てて行くのだ。最初に選んだジョブがその後のキャラクターの育成に大きな影響を与えるだけでなく、異なるジョブのユーザーが協力してでしか達成することができないミッショ
マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
誰のための携帯電話か？
このブログでも、日本の携帯電話と比べてiPhoneがどう違うかという話をさんざんと書いて来たが、結局のところ一番本質的な違いを生み出しているのは、「誰のために携帯電話を作っているか？」という点。 日本の携帯電話メーカーが「NTTドコモに育ててもらった」ことに関しては誰も否定できないわけで、その意味では消費者よりもキャリアの意向を優先して作らなければならない。足並みがそろいやすい分「お財布ケータイ」みたいなことはやりやすいことは確かだが、iPhoneのような不連続的な進化はさせにくいのも事実。 これは、日本以外の国でも言えて、 "The larger handset manufacturers had gotten really good at developing products that the wireless carriers want," said Jonathan Hurd,
Life is beautiful: Google Chromeに関してひとこと
今回Googleが発表したウェブ・ブラウザー、Google Chromeは、ひと言で言えば、「安定度・安全度を高めるために、それぞれのタブを別プロセスで走らせるタブ・ブラウザー」である。 ９５年にIE3.0を設計した時には、タブのコンセプトも存在せず、セキュリティの問題もそれほど強く意識していなかったので、ウィンドウごとに１スレッドを割り当てたマルチ・スレッドを選択した訳だが、ここまでウェブ・アプリケーションが重要になってくると、マルチ・プロセスに移行するのは当然。特定のページ上でのJavaScriptの挙動がおかしくなったからと言って、ブラウザーすべてが落ちてしまう今までの設計が異常。 一つのウィンドウ下で管理させるそれぞれのタブにプロセスを割り当てる、一般的に一つのウィンドウに一つのプロセスやスレッドを割り当てる通常のGUIアプリケーションとは異なるが、ユーザー・モデルとリソース管理は
Googleのandroidは通信事業者にとって本当に正しい答えなのか？
５月に、「UIEジャパン、映像配信サービス「ひかりTV」において、GUIの“ユーザー・エクスペリエンス”を演出」という奥歯にものがはさまったようなアナウンスをしたUIE。その時に寄せられた「ユーザー・エクスペリエンスの設計だけで、UIEngineは採用されてないの？」という質問に対する答えが今回のプレスリリース。 UIEジャパン、映像配信サービス「ひかりＴＶ」のGUI開発に、「UIEngine™」によるIPTVソリューションを提供 ちなみに、一方では「ハードウェアに依存しない、サービス指向のGUI開発」をサポートするUIEngineを作っておきながら、iPhoneという特定のハードウェアに最適化したアプリケーションを作っている私の行動を不思議に思っている人もいるようだが、これは私なりの「来るべきハードウェアの二極化」に対する答えである。 つまり、ハードウェアは、Appleのように強いブラン
「iPhone開発者支援プログラム」と進化圧と
先日の「iPhone開発者支援プログラム」に関するエントリーに対しては、予想以上のたくさんのフィードバックをいただいた。やはり「もっと日本のエンジニアが活躍する場があるべき」という進化圧のようなものが高まっているのだろう。 支援プログラムに関しては、まだまだ詰めなければならないことがたくさんあるのだが、形としては純粋なNPOでは息が続かないし（そもそも資金が集められない）、かといっていきなり人をたくさん抱え込むのもの得策ではない。やはり受け皿として小さな事業会社を用意して、そこから私が外部のスタッフを交えたいくつかの開発プロジェクトを見る、という形が良いのではと考えている。 ちなみに、最近の私だが、UIEvolutionには週に一日ぐらいしか顔をだしておらず（CEOは去年の１０月に辞任、今は単なる取締役）、他の時間はmasuidriveの増井くんと４月に設立したBig Canvas Inc
「iPhone開発者支援プログラム」に興味がある人、この指とまれ
シリコンバレーのエンジニアと比べて日本のエンジニアがの労働環境や待遇の面で冷遇されているということは常々言って来たことだが、その原因の一つがベンチャー企業を支援する仕組みが日本に圧倒的に不足していること。私なりになにかできないかと色々と考えて来たのだが、やはり私としてできることはもの作り面での支援だと思う。 そこで、読者に質問だが、もし私が「iPhone開発者支援プログラム」のようなものを立ち上げたら、エンジニアとして参加することに興味のある方は何人ぐらいいるだろうか。漠然と考えているイメージはこんな感じ。 ステップ１：プログラミング・コンテスト 作ったiPhone用のプログラムを「投稿」していただく。審査に通った人はステップ２に進んでいただく。 ステップ２：開発支援 審査に通った人に対し、資金・企画・技術・デザイン面での開発支援を行う。必要であればウェブ・サーバーも提供する。 ステップ３
iPhoneがなぜそれほどまでに「革命的」なのか
iPhoneに関しては、まだ誤解している人も多いようなので、念のために解説しておくと、iPhoneがこれほどまでに通信業界で注目されているのは、マルチタッチのUIを採用しているからでも、NextStepの血を引く最先端のiPhoneOSを積んでいるからでもない。NTTドコモなどの旧来型の通信キャリアからみれば「単なるデバイスの調達先」でしかなかったデバイスメーカーがキャリアのビジネスに口も手も出している点にある。 私がAppleとAT&Tの提携発表で一番驚かされたのは、その料金体系であった。パソコン並にネットワークを使うiPhone向けの使い放題プラン（日本の「パケ放題」に相当する部分、ただし容量制限は一切ない）が月々わずか２０ドルというのは、本当に破壊的な価格である。この価格故にiPhoneは非常に魅力的なデバイスとなっているし、これだけ普及している。もちろん、それを実現するためにAT&
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
