「締め切りは絶対に守るもの」と考えると世界が変わる
2011年にインプレスジャパンから「エンジニアとしての生き方」という本を出版して以来、書籍よりは「メルマガ（週刊 Life is Beautiful）」の執筆を優先して来た私ですが、この度、とある編集者に説得されて「時間術」の本を出版することになりました。 『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』（文響社） 「時間術」とは言っても、巷に良くある「どうやって時間を効率よく使うか」という話ではなく、実際の仕事の現場において「常に締め切り通りに仕事を終える人」になるための、私なりの「仕事に対する取り組み方」を解説した仕事術の本です。 「いつも締め切りに追われている」「締め切り間際にならないと本気で仕事ができない」という悩みを抱える人たちには是非とも読んでいただきたい本です。締め切りを守れるかどうかは、締め切り間際のラストスパートで決まるのではなく、もっと前の段階での、「
Life is beautiful: ビル・ゲイツの面接試験―私の場合
マイクロソフトの採用面接がユニークであることは、「ビル・ゲイツの面接試験－富士山をどう動かしますか」という本で一時話題になった。もちろん、私自身もマイクロソフト本社で面接官として数え切れないほどのエンジニアの面接を担当し、自分なりに工夫して作り出した試験問題を幾つも用意していた。今日は、その一つを披露して、得意のうんちくを展開しよう。 ［問題］ 二次元座標上に、それぞれの辺がX軸・Y軸と平行に置かれた長方形Aと長方形Bがあるとする。その時、長方形Aと長方形Bが一部でも重なるかどうかを判断する条件式を書け。フォーマットは、CやJavaなどのコンピューター言語でも良し、単なる数式でも良い。制限時間は３０分。ただし、考えていることを声に出し、ホワイト・ボードを使って自分の考えのプロセスを説明しながら解くこと。 もし、これからプロのソフトウェア・エンジニアを目指そうという理科系の学生がこのブログを
Python Hack : 噛めば噛むほどおいしくなるクロージャの話
最近 JavaScript を書く機会が増えているが、それに従って自分のコーディングスタイルが少しづつだが変化してきているのが分かる。もともと「コードの読みやすさ」や「実行効率」にとことんこだわるタイプだが、（JavaやC++になくて）JavaScriptやRubyにあるクロージャや無名関数が私のコーディングスタイルにとてもマッチしているからだと思う。 簡単な例を紹介しよう。Pythonで書かれた config.py というモジュール。config.yamlという設定ファイルを読み込んで Dictionary として返す config.get() という関数。普通に実装すると、以下のような感じになる。 import yaml _config = None def get(): global _config if not _config: data = open('config.yaml')
iOS8が加速する家電メーカーの新陳代謝
メルマガの読者に向けて、今回のAppleによるWWDCでの発表に関する解説を執筆中ですが、それを書きながら強く認識したのが、２００７年に登場したiPhoneが携帯電話機メーカーの勢力図を大きく変えたのと同じ様な大変化が、今度は家電メーカー全体に起ころうとしている、という事実です。 iPhone が証明したのは、ハードウェアの世界においても勝負の鍵となるのはソフトウェアであり、世界最高のプログラマー集団を抱えた企業しか、この業界では利益を上げられない、勝ち残れない、ということです。 日本のメーカーは、NTTドコモによる iモードで、世界で最初にインターネットに繋がる携帯電話を作っておきながら、iPhone の登場とともに市場から淘汰されてしまいました。 これに関しては、「日本は独自企画にこだわったから負けた」と思っている人が多いのですが、それは誤解です（日本の携帯電話市場のことを最初に「ガラ
放送と通信の壁に穴を開けたパナソニック
パナソニックが「テレビ放送と同時にネットから取得した情報を画面には表示しない」という放送業界と家電業界との紳士協定を破ったとして、新型テレビのCM放送を拒否されているそうだ（参照）。 一見何気ないニュースだが、これは既得権益を守るためのルールでガチガチに固められてイノベーションが起こりにくくなっている日本としては、非常に画期的なことである。 日本のテレビ放送には、BML(Broadcasting Markup Language)という仕様で文字を送る仕組みがついているが、これをわざわざ HTML にしなかった理由は、放送と通信の間に人為的な垣根をもうけて放送局の既得権益を維持しようという試み以外の何物でもなかった。 今回問題となっている「テレビ放送と同時にネットから取得した情報を画面には表示しない」という紳士協定も、テレビ放送にネットから取得してきたTweetや広告を重ねて表示されては、付
各種ブラウザーで Java (applet) を無効にする方法
こちら（米国）では、見つかった Java のセキュリティホール（＋それを利用した実際のアタック）が大問題になり、米国政府が「ただちに Java を無効にするように」と声明を出し（参照）、全国ニュースでも大きく取り上げられている。 実質的な危険があるのは Java applet なのだが、Java と Java applet の違いの分からない報道機関は、大々的に「Java が危険」と報道しており、Sun Microsystems を買収して Java を入手した Oracle にとっては大きなブランドイメージの損失だ。Oracle は火曜日には５６カ所のセキュリティホールを塞いだパッチを提供するそうだが、そんなパッチでは、今回作られてしまった「Java は危ない」というイメージは拭えない。 どのみち、Java applet にはほとんど価値がないので、これを機会に無効にする人も多いようだ（
丸投げ「エンジニアもどき」はGitHubの夢を見るか？
Facebook のタイムラインに、Wireless Wire News に「海外で食べて行けるエンジニア、食べられないエンジニア」という記事が流れて来た。 簡単に言うと、外でも食べて行ける人は「自分で手を動かして何かできる人」です。 コーディングできる、設計できる、管理の仕組みを考えられる、コストカットした機材の調達の仕組みを考えられる、人員管理がうまい、プロジェクト管理できる、監査の仕組みやドキュメントを作れる、戦略を作って実行できる、という様な「自分で何かができる」人です。 反対に、「これは食べて行けない」という典型例。それは、日本国内の大手ベンダやユーザー企業勤務で、下請けや孫請けへの「丸投げ」しかできない「エンジニアもどき」や「SEというなんだか良くわからない仕事をやっている人」「仕事が部長や課長」という人々です。 基本的には、私が以前、「ソフトウェアの仕様書は料理のレシピに似て
アップルはテレビ業界の黒船になりうるか
ファイナンシャル・タイムズの Japanese TV manufactures admint defeat という記事で取り上げられているが、ソニーとパナソニックがほぼ同時にテレビ事業の縮小をアナウンスした（これに関しては来週号のメルマガで少し解説する）。 それと同時に盛り上がってきたのが、アップルがテレビ市場に参入するという噂。普通に考えれば、「コモディティ化が進み、利益を出す事が難しくなっているこの市場に、何でいまさら？」となる。 特にアップルは価格競争を徹底的に避けて高付加価値商品に特化してきたからこそ、４０％近い粗利を維持し続けてこれたわけで、この路線から外れてまでテレビ市場に乗り出す意味は全くない。 「アップルはソフトウェアで差別化できるから」という意見もあるが、それならばテレビ本体には手を出さずに Apple TV のみを進化させれば十分なはずである。 そこから類推するに、もし
Google+Motorola: Microsoftは「当て馬」だった
先週、「MotorolaがWindows Phone陣営に乗り換える可能性を示唆」というエントリーに書いた通り、あの手のアナウンスメントにはだいたい何か裏の事情がある。 そして今日、GoogleがMotorolaの携帯電話部門を買収することがアナウンスされ（参照）、その裏事情が何であったかが明らかになった。あれは、MicrosoftとGoogleを競争させて価格をつり上げるための牽制球だったのだ。 Microsoftが実際どの程度Motorolaとの話をしていたかは不明だが、１ドルでも高く売りたいMotorola側としてはGoogleから買収の話が来た時点でわざわざMicrosoftを「当て馬」として引きづり出して競争させようとするのは当然。あのアナウンスメントは、Microsoftに向けたラブコールでもあり、Googleに対する「早く良い条件で結婚を申し込んでくれなきゃ、他の人と浮気しち
エンジニアから見た原発
典型的な「理科系少年」として育った私にとっては、原子力発電は宇宙旅行や人工知能とならぶ「人類の英知を集めた科学技術の結晶」であり、あこがれでもあった。ブルーバックスの相対性理論に関する本はすべて読んだし、アインシュタインの書いた e=mc2 という式は私にとってはまさに「人類の英知」を象徴するシンボルであった。高校時代の前半までは、自分は物理学者になると確信していたぐらいだ。ひょんなきっかけからコンピューターの世界に足を踏み入れ、ソフトウェア・エンジニアとしての道を歩むことになったが、科学技術全般に対する情熱は今でも持っている。 そんな私なので、今までは当然のように「原子力発電」の支持者であった。資源の乏しい日本にとって「石油が不要で、二酸化炭素を放出しないクリーンな原子力発電」こそ日本にふさわしい発電方法であると信じていたし、自動車・エレクトロニクスに続く輸出産業としての原子力に期待もし
これであなたも原子力安全・保安院
放射線量や被曝量がドラゴンボールのスカウターの数値のように一桁づつ大きくなるにも関らず、「健康には影響がない」と言い続ける原子力安全・保安院。何度も聞いているうちに、あるパターンがあることに気がついた。「被曝量を記者会見で話す時にはこうやって説明する」という虎の巻のようなものがあるに違いない。そこで、その虎の巻を彼らの過去の発言からリバース・エンジニアリングしてみた。 １μSv （マイクロシーベルト） 胸部X線検診１回に受ける放射線量（５０μSv）の５０分の１。健康には全く影響がない。 １０μSv（マイクロシーベルト） 胃のX線検診１回に受ける放射線量（６００μSv）の６０分の１。健康には全く影響がない。 １００μSv（マイクロシーベルト） 胸部X線CTスキャン１回に受ける放射線量（６.７mSv）の約７０分の１。健康には全く影響がない。 １mSv （ミリシーベルト） 放射線業務に従事する人
Nokia+Microsoftパートナーシップは、「３強３OS時代」の幕開けか
おおかたの予想通り、NokiaはGoogleではなくMicrosoftをパートナーとして選んだ（参照）。簡単に解説すると、 NokiaはWindows Phone7をNokiaのスマートフォンの唯一無二のプラットフォームとして選択する NokiaはMicrosoftのBingサーチエンジンとadCenterを全面的に採用する 低価格端末にはSymbianを使いつづけるが、これ以上のSymbianへの開発投資は行わない 開発中のMeeGoベースの機種は一応は出すが、これはWindows Phone7への「中継ぎ」でしかない 携帯電話、スマートデバイスを作っている部門を別々のビネスユニットとする（スピンアウトではなし） ソフトウェア（Symbian + MeeGo）の開発部門を大幅にカットする NokiaはMicrosoftにソフトウェアのライセンスフィーを払うことになるため粗利益率は下がる
日本のケータイが「ガラパゴス化」した本当の理由
「ガラパゴス」という言葉が今年の流行語大賞の候補に選ばれたということを聞いていたので、密かに受賞しないかと期待していたのだが、残念ながら大賞は逃したようだ（もし大賞に選ばれていたら、私が受賞することになったのかどうかの疑問はこれで解けずに終わってしまった）。しかし、この言葉をずいぶん前から使っている私としては、この言葉が一人歩きしているようでなんとも言えない気持ちなのでひと言。 まず最初に断っておくと、私が２００１年のCTIA（米国の携帯電話業界で一番大きなカンファレンス）のスピーチでこの言葉を使った時は、単に日本という「単一民族で、国民の大半の生活レベルが同じで、家電とか携帯電話のようなガジェットに流れるお金が比較的多い」という特殊な環境で、iモードを中心に「ケータイ・ライフスタイル」が異常なスピードで進化をとげていることを表して、「ガラパゴス現象」と呼んだだけのこと。決してネガティブな
「ガラパゴス問題」に対する少し前向きな一考察
昨日の「日本のケータイが『ガラパゴス化』した本当の理由」には沢山のコメントをいただいたが、その中には、「じゃあ、日本はこれからどうすれば良いのか」という質問があったので、私の考えを少し書いてみる。 まず、ケータイやテレビのように消費者向けのデバイスを作るのであれば、世界規模でビジネスをすること以外は考えない方が良い。先のエントリーで書いた通り、日本の携帯メーカーは、単に「ソフトウェアの開発能力・デザイン・おもてなし」で負けているだけでなく、ビジネスの規模の違いから、部品の調達コスト・製造コストでAppleに大きく引きはなされているのだ。「悪かろう高かろう」では勝てるわけがない。 もし、日本のメーカーがAppleやSamsungと本気で戦おうとするのであれば、（１）コスト面での徹底的な合理化をはかり（役員のお抱え運転手を廃止する、年功序列で給料だけが高くなってしまった人たちに辞めてもらう、系
ソフトウェア・パテント不要論
今日、家に帰ってみると、Georgia Institute of Technology （ジョージア工科大学）から、Inventors and Their Inventions: Understanding the Innovation Process というアンケート型の質問状が届いていた。過去数年間に、米国・ヨーロッパ・日本でパテントを申請した人の中からランダムに抽出したサンプルだという。 質問の内容は、なぜパテントを申請したのか・その発明にどのくらいの時間をかけたのか・その発明は実際の商品に活用したのか、などのありきたりのものだったが、最後に自由にコメントを書いてほしいという欄があったので、そこでソフトウェア・パテントに関して徹底的な批判を加えておいた。 前にもこのブログで書いたことがあるが、ソフトウェア、ユーザー・インターフェイス、そしてビジネス・プロセスに関してのパテントは認める
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
iPadのインパクト、私の予想８
iPadの米国でのローンチまで１０日となったわけだが、色々と思うことがあるので書いてみる。 予測１：４月３日のローンチは成功する これは99.9%確実である。この手のデバイスのローンチには、（１）開発者に魅力的なプラットフォームを提供してアプリを作らせ、（２）ブロガーの興味をそそって発売前からせっせとブログエントリーを書かせ、（３）アーリーアダプターの心をくすぐって注文予約させれば良いのだが、まさにその戦略に１００％ハマっている私がここにいる（笑）。 先日のエントリーで書いた様に、開発者としては、iPad用のクラウド本棚付きeBookリーダー「Cloud Readers」をすでにAppleに審査のために提出済みである。ブロガーとしてはこのエントリーも含めてiPadに関しては何度も書いて来ているし、当然アーリーアダプターとしてiPadはオンラインで注文してある。Appleから表彰状をもらいた
Life is beautiful: とある家電メーカーでの会話：クラウドテレビ編
ある日本の家電メーカーでの会話。まずは副社長室での会話から。 技術部長：副社長、来年度の予算の件はどうなりましたか 副社長：大丈夫だと言っただろう。台湾・中国からの追い上げは相変わらず激しいが、テレビは家電ビジネスの要だ、経営陣としてもここだけは手を抜けない。来年も君たちにがんばってもらわなければならない。 技術部長：もちろんです。そのあたりは現場のエンジニアたちも強く感じてると思います。ちなみに、メールに書いてあった「戦略の変更」って何ですか？ 副社長：そのことなんだが、経営会議でも持ち上がったんだが、台湾勢と戦うには、我が社にしかできない「差別化要因」が必要だ。価格競争では彼らにかなわない、消費者にとって目に見える価値を提供して、台湾製品よりも３割・４割増の値段でも喜んで買ってもらえるテレビを作らなければならない。私は、キーワードは「クラウド」だと思っている。 技術部長：え？「ク、クラ
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
