スティーブ・ジョブズに学ぶプレゼンの秘訣
ベスト・セラー「スティーブ・ジョブズ 驚異のプレゼン」の著者で、Business Week のコラムニストでもある Carmine Gallo が書いた "10 ways to sell your ideas the Steve Jobs Way!" という資料を手に入れたので、簡単に内容を紹介する。 1. 最初は手書きで考えをまとめろ いきなりパワポの資料を作らず、まずは紙やホワイトボードなどで（訳注：neu.Notes+ でももちろんかまわない^^）、プレゼンの大まかな「流れ＝ストーリー」を作るべき。つまらないプレゼンでは、観客はすぐに飽きてしまう。語るべき「ストーリー」がないうちにパワポの資料を作っても意味がない。 2. Twitter 向きの短いフレーズを使え Twitter の「口コミ効果」に関しては、いまさら強調するまでもないが、それを最大限に活用するには、１４０字以内に収まる
そしてスティーブ・ジョブズは伝説の人となった
CNetにGuy Kawasakiの "What I learned from Steve Jobs" という文章が出ているので一読をおすすめする。１２項目のメッセージを簡単に解説するとこうなる。 評論家と呼ばれる人たちは実は何も分かっていない。彼らに耳を傾ける必要はあるが、振り回されてはいけない 顧客に何が欲しいかをたずねても答えは見つからない 不連続な変化を起こせ 難しいことにチャレンジするからこそすばらしい仕事ができる デザインへの徹底的なこだわりが違いを生み出す プレゼンの時には大きなフォントと大きな画像を使え 間違いに気がついたら恥じらいもなく方向転換をしろ 「価値」は「価格」とは違う 優秀な人材は自分より優秀な人材を雇いたがる。だめな人材はもっとだめな人材を雇いたがる 本当のCEOは、自分自身で商品のデモをする 会社に必要なのは「研究者」ではなく「エンジニア」だ 「個性的」でか
教育の現場で使われはじめた iPad
リリースしたiPadアプリへのフィードバックやレビューを読むと、実際のユーザーがどんな場面でiPadを使っているかが良く分かる。neu.Annotateの場合だと、見積書だとか申込書だとかに必要な項目を書き込んでからサインして送り返す、という用途に使っている人が米国には多いようだ。日本と違ってすべてがサインで済んでしまう米国社会ならではの現象だ。下のビデオもその典型的な例。 もうひとつ良く見るのが教育現場での使用例。"Pros and Cons of Digital Workbooks(デジタル・ワークブックの利点と欠点)"は、生徒全員にiPadを持たせ、練習問題をPDFの形で渡して neu.Annotate で答えを書いてメールで提出させるという教育方法を実践している先生の書いたブログエントリー。無料だからこそこんな使い方がしてもらえるわけで、開発者の私としては喜ばしいばかりだ。 こんな
パーソナルメディアとキュレーションと
私がブログを本格的に書きはじめたのは２００４年からだが、当時はブログに代表されるパーソナル・メディア（もしくはソシアル・メディア）がこれほどの影響力を持つ物に成長するとは想像もしていなかった。エジプトやリビアでの革命はまさにそれを象徴する出来事であり、「独裁政権が情報のコントロールにより政権を維持する」ことはもはや不可能に近いと言える。 そんな中で私が注目しているのは、まぐまぐとBLOGOSである。 まぐまぐの方は私自身がメルマガを始めたこともあり（参照）、別途その意味するところを詳しく書いてみたいと思うが、メルマガというある意味で「枯れたテクノロジー」がパーソナル・メディア時代のコミュニケーション・ツールとして再浮上して来た、というのは非情に興味深いと思う。 BLOGOSのホームページには、「２００万人が読む、ウェブ上の論壇紙」と書いてあ。実際に見てみると、原発事故、円高、政局、などのホ
私が事故後、脱原発派に転向した一番の理由
先日のエントリーに、「論理的に考える力のない人が、 『放射能は危険』→『原発は不要』→『脱原発』 となっているのは理解できます。 普通に論理的に考える力のある人は、 『脱原発したときのリスク』を考え、 脱原発をしないほうがよいのでは？という意見の方が多いと感じています。 中島さんのような方が、なぜ、脱原発一直線なのかが理解できません。 脱原発について書かれるのはよいのですが、 一度、なぜ脱原発を訴えているのか？についても、この場に書いていただけないでしょうか？」というコメントをいただいたので、今回はその質問に答えてみる。 実は、福島第一原発での事故の第一報を聞いた時に最初に私の頭に浮かんだことは、「この事故は、日本だけでなく、世界全体の原子力技術の発展に大きなブレーキをかける事になる。１０００年に一度の津波のためにたまたま起こった事故のために、日本のエネルギー政策を変更したり、原子力発電を
「今の日本の若い人たちには元気がない」は本当か？
最近、「日本の若い人たちの元気がない」という声を聞く。「若い人たちはすぐ辞めてしまう」とも聞く。本当に若い人たちに元気がなくなってしまったのだろうか？今の若い人たちは、高度成長期の「企業戦士」のように努力する事ができなくなってしまったのだろうか？ 私は決してそんなことはないと思う。一番の問題は、そんな若い人たちを雇う企業、そしてそこの経営者たちにある。グローバル化が大きく進む中で、過去の成功体験にしがみついて旧態依然とした体質のままの大企業。自分が退職金をもらうまでだけは会社が存続してくれれば良いと、リスクを避けて問題を先送りにする「逃げ切りメンタリティ」の経営者。「雇用を守る」との名目で競争力を失った大企業を無理矢理存続させる日本政府。不要になった人員を整理する事を禁じ、日本企業の国際競争力を奪う雇用規制。その雇用規制が故に出来上がった、「終身雇用が保証された正社員」と「使い捨ての派遣社
日本人の価値観にまで踏み込んで原発問題を考えるべき時が来たのだと思う
「候補者のエネルギー政策を知りたい有権者の会」を見ると、さまざまな候補者のある意味で優等生的な答えが見られるが、今、問われているのは、「脱原発とクリーン・エナジーのどちらを選ぶか」なんて小手先の話ではなくて、「日本をどんな国にしたいか」というもっともっと大きな話だと思う。 戦後、日本は欧米に追いつけ追い越せと国民全員が一眼となって勤勉に学び・働き、世界２位のGNPを持つ国にまで成長したのだが、８０年代終わりのバブルの崩壊後は「失われた２０年」に突入し、２０１１年に入った時点ですでに、財政赤字、少子化、地方の過疎化、高い失業率、正社員・派遣社員の二極化、などのさまざまな問題を抱えていた。 ３月１１日の大地震と巨大津波は、まさに天変地異ではあったのだが、それに続く福島第一原発でのスリーマイルを超える原発事故は、「過疎化で苦しむ地方に金と雇用というエサで危険な原発をおしつけた結果得られる、豊富で
これであなたも原子力安全・保安院
放射線量や被曝量がドラゴンボールのスカウターの数値のように一桁づつ大きくなるにも関らず、「健康には影響がない」と言い続ける原子力安全・保安院。何度も聞いているうちに、あるパターンがあることに気がついた。「被曝量を記者会見で話す時にはこうやって説明する」という虎の巻のようなものがあるに違いない。そこで、その虎の巻を彼らの過去の発言からリバース・エンジニアリングしてみた。 １μSv （マイクロシーベルト） 胸部X線検診１回に受ける放射線量（５０μSv）の５０分の１。健康には全く影響がない。 １０μSv（マイクロシーベルト） 胃のX線検診１回に受ける放射線量（６００μSv）の６０分の１。健康には全く影響がない。 １００μSv（マイクロシーベルト） 胸部X線CTスキャン１回に受ける放射線量（６.７mSv）の約７０分の１。健康には全く影響がない。 １mSv （ミリシーベルト） 放射線業務に従事する人
JavaScript HTMLテンプレートエンジン SNBinder 公開
先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。 ９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は（MVC
CDMA iPhone の登場でますます重要になるアジア市場
米国では、VerizionがCDMA版のiPhoneを出すということで大騒ぎになっている。今までiPhoneが買えずに我慢していたVerizonのユーザーからの注文が殺到することは目に見えており、しばらくは品薄の状態が続くだろう。Verizonが今年Appleに払う販売奨励金だけで$5billion（日本円で４千億円）にのぼるとの予想も出ているぐらいだ（参照）。 それよりもっと注目に値するのは今までiPhoneを独占してきたAT&T。２６％の現iPhoneユーザーがVerizonに切り替える予定だと答えたというアンケート結果も出ている（参照）ぐらいのインパクトのある話だ。たった一つの端末が、通信事業社の業績に大きく影響を与えるというのもすごい話だ。 ちなみに、Verizonはau(KDDI)と同じ通信方式（CDMA）を使っており、Verizon向けのCDMA版 iPhoneを日本に持って来
なぜ横並びで展示されるAndroidタブレットを作ってもだめなのか
先日のエントリー「Androidタブレットはヨドバシカメラの『Androidタブレットコーナー』に横並びにされた時点で負けだ」には、例によって賛否両論のさまざまなフィードバックがよせられたが、否定的な意見の大部分は以下のようなもの。 何故負けなのかがあまりイメージ出来ないなあ。描かれている様子はAndroidが盛況を博しているものにしか見えない。 PCメーカーが「何のためにWintel」と考えてるとは思えないし、スマホやタブレットで「何のためのAndroid」って問いに意味があるとも思わない。 すでにそんな現状の Windows PC でも一定の利益は出ているのだから、Android タブレットも負けではあるまい。 歴史に学ぶとするなら、iPhone/iPad が Machintosh だとすれば、Android機はPC/AT互換機なんだと思う。ただ、「Windowsなのでどれも使い勝手は
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
言語対決：JavaScript 対 Objective-C
ここのところ、サーバー側（Google App Engine）のコードはPythonで書き、クライアント側のコードはiPhone/iPad 向けはObjective-Cで、ブラウザー向けはJavaScriptで書く、という毎日が続いている私である。 それぞれの言語は難しくないのだが、さすがにこの３つを頻繁に行き来していると、pythonのコードに間違ってセミコロンを付けてしまったり、PythonとJavaScriptのどっちがTrueでどっちがtrueだか混乱したりする。 ちょうど昨日は、以前JavaScriptで書いたコード（写真をアップロードするコード）をObjective-Cに移植する機会があったのだが、とても分かりやすい結果が出たので、ここで比較してみる。 まずは元の JavaScript のコード。 SNBinder.get("/blob/create_upload", {},
またまたお世話になってしまったアップルストアのGenius Bar
先日、日本から帰国する際に、持って行った Mac Book 二台のうち一台を間違ってボストンバッグ（それもソフトタイプ）の外ポケットに突っ込んだままチェック・インしてしまうという失敗をしてしまった。一度荷物室に積み込まれてしまってのだが、飛行機に乗り込んだ後ですぐに回収をし、かろうじて破損は免れたのだが、その後１週間ほどで充電が不可能になってしまった。 しかたがないので、近所のアップル・ストアのGenius Barに持って行くと、保証期間だということで無償で修理してくれることになった。「水没とかしていた場合、保証がきかなくなりますが」というジニアス・バーの店員に「水没はしていません」と強調してしまった私。「ボストンバッグに入れたままチェックインとかしていませんよね」と聞かれれば正直に答えたのに...＾＾； ちなみに、最近は iPhone や iPad ばかり注目されているが、それと同時に
Life is beautiful: WEB+DBコラム「なぜ日本のソフトウェアが世界で通用しないのか」
私がコラムを書いている「WEB+DB PRESS」の最新号が発売されたので、ここで宣伝させていただく。今回のコラムのタイトルは、「「なぜ日本のソフトウェアが世界で通用しないのか」。 ...(前略)...そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること、そして、日本のソフトウェア・エンジニアの境遇が悪すぎるということ。そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。 詳しくはコラムを読んでいただくとして（宣伝だと言ったでしょう）、この問題はいまやソフトウェア業界だけにとどまる話ではないから始末が悪い。世界で一番進んでいるはずだった日本の携帯電話メーカーが、今や袋小路に追い込まれているのもこれが原因。 通信業界にはもちろん、携帯電話メーカーにもソフトウェアを自分で書ける人がいない今の日本の状況を考えれば、世界の
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者
誰にでも分かる「クラウド」
ここの所、「クラウド」という言葉が一人歩きしているようなので、言葉の定義を明確にして業界関係者間のコミュニケーションをスムーズにすることを試みてみたい。 クラウド・コンピューティング もともとは、すべての計算をクライアント側で行う「デスクトップ・コンピューティング」に対して、（しばしば雲の形で図式化される）ネット上のサーバー側で計算してしまうことを表すために生まれた言葉。しかし、後述の「クラウド・サービス」の普及とともに狭義・広義・誤用・バズワード化が進み、今や「ユビキタス」と同じぐらい使っている人によって意味が異なる言葉になりつつあるので要注意。 クラウド・サービス アマゾンのec2、GoogleのApp Engineのようにサーバーの能力を従量課金方式で提供するサービスのこと。自社サーバーやレンタルサーバーと比べて、初期投資の面でもスケーラビリティの面でも優れていることが特徴。 クラウ
GoogleはなぜAndroidやChrome OSを無料で配布するのか？
先週「Androidと家電」というタイトルで講演をさせていただいた私だが、そのプレゼンのキーポイントは、「なぜGoogleはAndroidを無料で配布するのか？」。それを私なりに説明するための資料として作ったスライドが以下の二枚。 まずこれは、MicrosoftとIntelがパソコン・ビジネスを育てるためにした「コモディティ戦略」を図式化したもの。IntelとMicrosoftで協力してCPUとOSを部品化・規格化することにより、誰でもパソコンを作れる様にしたのがそれ。これにより、パソコン・ビジネスへの参入障壁が減り、パソコン・メーカーが乱立。差別化がしにくい部分（つまりIntelとMicrosoftがほぼ独占的に提供するCPUとOS以外の部分）で激しいコスト競争が起こり、パソコンのコモディティ化が一気に進んだのは皆さんの記憶にも新しいはず。 特筆すべきなのは、MicrosoftもInte
Python入門：デコレータとは
前から常々思っていることだが、何かについて勉強する一番効率的な方法はそれを誰かに教えること。人に教えようとすると、それなりに準備をしなければならないし、自分の頭の中を整理しなければならない。また教える過程でするどい質問をされたり間違いを指摘されて、さらに勉強を強いられることもある。 私がこの手の「入門編エントリー」を書くのは、ほとんどの場合「自分自身の理解をより深めたい」ことが一番の目的であるが、ブログの場合、教室などと違って「その道の達人」みたいな人たちがツッコミを入れてくれるケースもしばしばあるので、そのメリットは何倍にもなる。 先日のクロージャに関するエントリーなどは良い例で、「そんな用途にはmemoizeというデコレータが便利」などの指摘がいただけだけであれを書いた価値があるというもの。 そこで、今日はPythonのデコレータに関して。デコレータがPythonという言語に導入された
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
