米マイクロソフト本社で目の当たりにしたビル・ゲイツの決断力
６月１日発売の『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』には、いくつかマイクロソフト時代のエピソードが書かれていますが、これもその一つです。この「シカゴ対カイロ」の社内抗争はマイクロソフト時代の思い出の中でも、筆頭のものです。 ◇ ◇ ◇ ビル・ゲイツの意思決定は光速 ビル・ゲイツが仕事で重要視していたのは、＂光速＂と言っても過言ではない迅速な意思決定です。これについては、どのくらい迅速だったかを象徴するエピソードを紹介します。 あれは忘れもしない1995年1月、シアトルの冬らしい小雨の降る昼下がりのことでした。米マイクロソフト本社内にはＯＳの開発に関する派閥争いがありました（ＯＳとはマイクロソフトで言うWindows Vistaだったり、アップルでいうところのOS Xなどのパソコンやスマホを動かすための基本ソフトのこと）。＂カイロ＂というグループと＂シカゴ＂という
「締め切りは絶対に守るもの」と考えると世界が変わる
2011年にインプレスジャパンから「エンジニアとしての生き方」という本を出版して以来、書籍よりは「メルマガ（週刊 Life is Beautiful）」の執筆を優先して来た私ですが、この度、とある編集者に説得されて「時間術」の本を出版することになりました。 『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』（文響社） 「時間術」とは言っても、巷に良くある「どうやって時間を効率よく使うか」という話ではなく、実際の仕事の現場において「常に締め切り通りに仕事を終える人」になるための、私なりの「仕事に対する取り組み方」を解説した仕事術の本です。 「いつも締め切りに追われている」「締め切り間際にならないと本気で仕事ができない」という悩みを抱える人たちには是非とも読んでいただきたい本です。締め切りを守れるかどうかは、締め切り間際のラストスパートで決まるのではなく、もっと前の段階での、「
「ファミレス型ソフトウェア開発」ではアップルには勝てない
私のWEB＋DB PRESS向けのコラム「Appleのビジョンと日本のハードウェアメーカーの将来」が公開されたので紹介する。私が一番強調したいのは、 他社と横並びでスペック競争をする時代は終わった。総合家電メーカーというビジネスモデルはもう成り立たない。ハードウェアは自分たちで作り，ソフトウェアの開発は外注に丸投げするのでは世界で戦えるデバイスは作れない。 という部分。 自らバリバリとソフトウェアを開発したことがないメーカーの正社員が仕様書を書き、実際の開発は子会社や関連会社に任せる上に、その子会社においても実際のコーディングは派遣社員が行うというゼネコン型ソフトウェア開発。これでは、本社から送られて来たレシピどおりにパートの人たちが料理をしているファミレスと同じだ。 一流シェフたちが腕を競う高級レストランのように、シリコンバレーのトップクラスのソフトウェア・エンジニアたちが、自ら仕様を決
SNBinderと「混ざり物のないコンソメスープ」と
先日オープンソース化したSNBinder（参照）、たくさんの人たちから色々なフィードバッックをいただけてとても感謝している。ブログの記事として書かれたものは私が知る限り以下の三つ。 penultimate diary: SNBinderを試してみる js do.it: SNBinderを試したよ！ a2c.get.diary: SNBinderに目からウロコ 小さなMVCが今現実に 当初は、最新のjQueryと動かないというバグがあったり、READMEにタイポがあったりとご迷惑をおかけしてしまったが、こうやってフィードバックをいただくことによって、励みになったり改良したり、というのがオープンソースの醍醐味である。とてもありがたい。 ちなみに、SNBinderは原型のようなものは１年前以上前からあったのだが、ViewとControllerの切り分けに部分がなかなかすっきりせず、公開を控えてい
もし日本のメーカーが iPhone を発売していたら..
iPhoneは会社から支給されて使っていますが、非常に使い勝手がいいです。 ただ、これでは、いまほど欲しくならないことはたしかですね。 他の機種と同じ土俵の上に上がってしまっているので、「なんかいろいろ機能がごてごて付いてる中の携帯の一つ」というところでしょう。 つまり、「売れるモノも売れなくなる」、「売り方次第」ということを今更ながら思い知らされました。
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
Google App Engine入門：実行効率を犠牲にせずに開発効率だけを上げるテクニック
一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
「富豪プログラミング」もいいけど「けちな大富豪」になるべき
Ruby on Railsに代表されるDRY（Don't Repeat Yourself）スタイルのフレームワークは、手っ取り早くサイトを立ち上げるのにはとても便利だ。特にRailsのActive Recordの様に、ランタイムにダイナミックにコードや設定ファイル（もしくはそれに相当するもの）を生成してくれる仕組みは、情報を一カ所のみに記述することによりミスを減らすという意味でもアジャイルな開発という意味でも重要である。 ただ、この手のフレームワークを使う場合に一つ気をつけなければならないのは、それがスケーラビリティの面で商用に耐えられるものか、という点である。特に、その手のダイナミックなコードや設定ファイルの生成（Railsの場合だとデータベース上のテーブルのスキーマに基づいたActive Recordクラスのダイナミックな生成）が、最初にサイトにアクセスが来た時に一度だけ実行されるもの
１２月３日にAndroidに関して講演します
久しぶりに日本で講演をすることになったので、ここで告知させていただく。詳しくは日経エレクトロニクスのアナウンスメントを見ていただくのが良いと思うが、今回は「Android家電の衝撃」というテーマのいくつかの講演＋パネルディスカション。 技術的に突っ込んだ話というよりは、ビジネス上の意味だとか、Googleの戦略という話になるとは思うが、UIEvolutionの創設者としてモバイル・組み込み業界でいろいろとビジネスをして来た経験や、iPhoneディベロッパーとしてiPhoneアプリを開発・販売して来た経験を通したいろいろな話ができると思う。 それにしても、最近は色々と試したいもの・勉強したいものが多くて困る。ここ一年ばかりどっぷりと浸かって来たのがiPhone SDK、それに最近はHTML5、CSS3、Google App Engine、Pythonが加わり忙しくてしかたがない。 まあ、この
Google App Engine入門：Entity Groupとトランザクション処理
今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
デザイン・パターンとは何か
先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、（業界に蓄積されたノウハウに立脚した）何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな（場合によってはお互いに矛盾する）要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
"emoji" (絵文字) の "emo" が "emotion" の "emo"だという誤解
日本のケータイに「絵文字」という独特の機能があり、これが今や「絵文字文化」と呼べるところまで進化していることは、これまれ国外ではあまり一般的に知られた話ではなかった。 しかし、今回iPhoneが絵文字を全面的ではないとは言え採用したことは、「絵文字文化の輸出」という観点からはとても重要な意味を持つかも知れないと密かに期待している私である。 その中で生まれつつある面白い誤解が、"emoji"の"emo"の部分が"emotion"の"emo"から来ているという誤解。 確かに「日本人はなぜ絵文字を使うか？」という説明をするときには、「平坦な文章にアクセントをつけて色々な感情（emotion）を込めるため」などと私でも言うわけで、その過程でこの誤解が生じるのは仕方がないとも言える。 まあ何にせよ日本の文化がこうやって世界に広がって行くというのは何とも楽しい。"emoji"がWebster'sに乗る
マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
なぜオープン系開発者の間でMacへのシフトが急速に進んでいるのか
先日のRails Conference 2008に関するレポートでも書いたが、米国のオープン系の開発者の間でのMacへのシフトが急速に進んでいる。たまにWindowsマシンを持っている人がいても、そんな人たちは口を揃えたように「うちの会社は.Netの案件もあるので、Macは買わせてもらえないんですよ」と本当は彼らもMacに切り替えたいことを告白する。 いろいろな事情・環境がからみあってこうなっているのだが、簡単にまとめると、そもそも、 アップル製品に対する昔からある漠然としたあこがれ ９０年代にソフトウェア業界の富を独り占めにしたマイクロソフトに対する恨み iPodの成功で一躍元気を取り戻したアップルという企業自身の魅力の上昇 という潜在需要があったところに、 意味もなく重くなっただけのVistaに比べて完成度の高いOS-X Unix系OSをカーネルに持つが故に整った開発環境 バーチャルマ
iPhoneアプリを作る際に注意すべき５つのポイント
毎日のように「iPhoneアプリでApple Design Awardを取るぞ！」と騒いでいるので、知り合いに「それって（現実が分かっていない）大学生のノリですよ」と指摘されてしまった私だが、マイクロソフトを２０００年に退社してからは、ひたすらモバイル・組み込みの世界で仕事をしてきた私としては「俺が取らなくて誰が取る？」という気分。その超楽天的な態度が彼が言うところの「大学生のノリ」なのだろう。 市場に受け入れられるアプリを作るためには、もちろん「誰にどんな価値を提供するのか」が一番大切。しかし、そこには残念ながら成功の一般方程式はないので、今日は比較的に一般化しやすい「どう作るか」という部分に関して、まとめることにした。 1. ユーザーの利用シーン・使用パターンを良く考えて作る パソコンやゲームコンソール向けのソフトと大きく違うのが、ユーザーの使用パターン。iPhoneに限らず、携帯電話
Life is beautiful: 「へんな会社」と「出るクギを打つ」社会の話
へんな会社を貫くために、普通の会社のやり方をよく理解しておくというのは必要なんじゃないか、とこれははてなに限らず思う次第。【Kousyoublog | はてな移転で中の人が言うべきことと言ってはいけないことより引用】 この手の発言こそが、まさに「出るクギを打とうとする」行動。近藤さんに関してはそんな心配をする必要は全くないが、他の若い人たちが「やっぱり『普通の会社のやり方』をちゃんと勉強しなきゃ」などと誤解してはいけないと思い一言。 上場している企業と違い、はてなのように、ごく少数の株主が所有している会社の場合、株主・取締役の了解さえ取れれば、大幅な経営方針の変更は自由にしてかまわない。それが非上場であることの大きな利点だ。 今回の場合、「米国からは一時撤退し、多少会社の規模が小さくなっても良いから、京都にもどって落ち着いた環境でもう一度もの作りに専念する会社としてやりなおす」という決定は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
