日本の大学生はなぜ勉強しないのか
今週号のメルマガ「週刊 Life is Beautiful」に向けて、「日本の大学生はなぜ勉強しないのか」という文章を書いたのだが、特に冒頭の部分はぜひとも多くの人に読んで欲しいので、引用する。 NHKニュースで「日本の大学生が予習復習のために費やす勉強時間は一日平均３９分」というデータが発表されていました。まさに「ぬるま湯大学」です。私が大学（早稲田大学）に通っていた時も似たような状況でしたがが、これが日本の国際競争力をなくしている原因の一つであることをより多くの人が強く認識すべきだとつくづく思います。 私は米国の大学（University Washington）でも勉強した経験がありますが、日本の大学とは全く異なっていました。まず第一に、予習をしていかなければ全く授業について行けません。授業にもよりますが、９０分の授業の準備に１〜３時間の予習が必要です。 例えばビジネス戦略の授業の場合
特許庁のシステム開発が破綻した本当の理由
特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には（１）コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、（２）霞ヶ関から流れて来るお金にたかる IT ゼネコン、（３）そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた９９億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ
誰も言いたがらない「Sony が Apple になれなかった本当の理由」
Sony や Panasonic が家電のコモディティ化で大赤字を出して苦しむ一方で、今や株価総額が日本の大手家電メーカー８社の株価総額の３倍以上にもなった Apple（参照）。 この差に関しては、私も含めて、リーダーシップの欠如だとか、ゼネコン型のソフトウェア開発スタイルが悪いとか、ソフトウェアの重要性を理解しない経営者、などのさまざまな考察がされているが、その根底にあるのは、「大企業は一度正社員になった人は会社が倒産の危機にでもさらされない限り解雇してはいけない」という日本特有の雇用スタイル。 家電業界の成り立ちは、日本の家電メーカーが業績をのばしていた高度経済成長期とは大きく変わってしまった。ソフトウェアがものすごく重要になったのはもちろんのこと、ハードウェアに関しても、中国を含む東南アジアが「世界の工場」となった今、「何を自分で作り何をアウトソースするか」がコスト削減の上でも差別化
AppleとSharpの提携
Apple Insider に Apple と Sharp の提携について二つの記事が掲載された。 一つ目は、Appleが次世代 iPhone/iPad のディスプレイに Sharp の IGZO 技術を使うという話（参照）。Appleが iPad の解像度を二倍にするためのディスプレイ技術を探していることは前から伝えられていたが、高解像度で、かつ、同時に消費電力が抑えられる IGZO を採用するというのはかなり信憑性のある話。 二つ目は、Apple が２月からHDテレビの本格生産に入り、その生産を委託する先が Sharp だという話（参照）。Appleのテレビ市場への参入に関しては、私も少し前に書いたばかりだが（参照）、コモディティ化の進むテレビ市場であえぐ家電メーカーにとってみれば、気になってしかたがないところだろう。
Amazon Fire がタブレット市場の１５％を確保するとの予想
「Amazon が２０１２年にはAmazon Fire １２００万代を売り、タブレット市場の１５％を確保するだろう」との予測が出されている。 この数字は私の予想とほぼ同じ。２０１２年に関して言えば、AppleのiPadが相変わらず強くてタブレット市場の７０％近くを占め、さらに残りのマーケットの半分以上を Amazon Fire が取る、というのが私の読みだ。 消費者から見れば、iPadが一番魅力的だが、値段が半分以下でコンテンツも充実しているAmazon Fireにも捨てがたい魅力がある。 AppleはiPadで３０％強の粗利を稼ぎ出す一方、AmazonはFireを一台売るたびに２０〜３０ドルの赤字になると予想されているが、一気にシェアを確保して、後からコンテンツで儲けるビジネスモデルのAmazonとしては正しい戦略だ。 間に立たされて苦しい思いをするのが他のタブレット・メーカー。iPad
テクノロジー・ベンチャーにはなぜソフトウェア・エンジニアが不可欠なのか？
WEB-DB PRESSに連載中のコラム、「第10回 アイデアを目に見える形にしてこそのエンジニア」が公開されたので、エンジニアの方たちにはぜひとも読んでいただきたい。 この文章で、私が一番強く訴えたかったメッセージは下の一節。 注目すべき点は，この「プロトタイプという叩き台を作って企画を煮詰めていく」というアプローチは，エンジニアにしかできないということだ。ソフトウェアのことがまったくわからない人から企画を丸投げされて閉口した経験は多くの人が持っていると思うが，そんな無駄なことを避けるためにも，企画の段階からリーダーシップを発揮するためにも，エンジニアはプロトタイプを作るべきだと私は考えている。 シリコンバレーでベンチャー投資家をしている Guy Kawasaki が、「私がアーリー・ステージのテクノロジー・ベンチャーに投資をする時は、ざっと見積もって、優秀なエンジニア一人あたり５０万ド
なぜ横並びで展示されるAndroidタブレットを作ってもだめなのか
先日のエントリー「Androidタブレットはヨドバシカメラの『Androidタブレットコーナー』に横並びにされた時点で負けだ」には、例によって賛否両論のさまざまなフィードバックがよせられたが、否定的な意見の大部分は以下のようなもの。 何故負けなのかがあまりイメージ出来ないなあ。描かれている様子はAndroidが盛況を博しているものにしか見えない。 PCメーカーが「何のためにWintel」と考えてるとは思えないし、スマホやタブレットで「何のためのAndroid」って問いに意味があるとも思わない。 すでにそんな現状の Windows PC でも一定の利益は出ているのだから、Android タブレットも負けではあるまい。 歴史に学ぶとするなら、iPhone/iPad が Machintosh だとすれば、Android機はPC/AT互換機なんだと思う。ただ、「Windowsなのでどれも使い勝手は
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
無名関数を使った非同期通信のススメ（JavaScript）
ここ最近はブラウザーの上で動く思いっきりRIAなアプリケーションを書いている私。こと通信の部分になると JavaScript での開発効率が、C++/Java/Objective Cなどと比べて格段に高いことをつくづく感じている毎日なので、今日は、そのあたりを少し解説してみようかと思う。 サーバーのAPIにアクセスするプログラムを書く方法は色々とあるが、「サーバー上の特定のURLにHTTPでアクセスして結果をXMLやHTMLやJSONで受け取る」というケースに限定すれば、基本的に３つのパターンに分けられる。 1. 同期通信 result = urlfetch.fetch("http://www.google.com/") if result.status_code == 200: doSomethingWithResult(result.content) その書きやすさのために、実務経験の
アップルの３０年ロードマップ
昨日、日経BP主催のAndroidに関するセミナーで講演＋パネルディスカッションをしたのだが、パネルディスカッションを一緒にさせていただいた、日本通信の福田尚久氏との話（特に、楽屋に戻ってからの非公開の話）が興味深かった。 福田氏は、スティーブ・ジョブズがAppleに戻り、Microsoftからの資金調達、iPodのリリース、アップル直営店の展開、という今のAppleの成功の基盤となる「奇跡の復活」を遂げた時期にジョブズの側近として活躍した人。 彼に言わせると、今のAppleのビジネス戦略は、倒産寸前だった９７年当時に作った「３０年ロードマップ」に書かれた通りのシナリオを描いているという。 もちろん、具体的な内容は企業秘密でもあるので直接聞き出すことはできなかったが、ここ１２年の間にアップルが出して来たもの（iPod, iTunes, iPhone, Apple TV, Safari, O
GoogleはなぜAndroidやChrome OSを無料で配布するのか？
先週「Androidと家電」というタイトルで講演をさせていただいた私だが、そのプレゼンのキーポイントは、「なぜGoogleはAndroidを無料で配布するのか？」。それを私なりに説明するための資料として作ったスライドが以下の二枚。 まずこれは、MicrosoftとIntelがパソコン・ビジネスを育てるためにした「コモディティ戦略」を図式化したもの。IntelとMicrosoftで協力してCPUとOSを部品化・規格化することにより、誰でもパソコンを作れる様にしたのがそれ。これにより、パソコン・ビジネスへの参入障壁が減り、パソコン・メーカーが乱立。差別化がしにくい部分（つまりIntelとMicrosoftがほぼ独占的に提供するCPUとOS以外の部分）で激しいコスト競争が起こり、パソコンのコモディティ化が一気に進んだのは皆さんの記憶にも新しいはず。 特筆すべきなのは、MicrosoftもInte
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
