エンジニアの役割
技術評論社の WEB+DB PRESS に連載中のコラムが新しくウェブで公開されたので、ぜひとも読んでいただきたい。 エンジニアの魔法の手〜面白いプロジェクトの関るには このコラムで一番注目していただきたい部分は、以下の一節。 自分が関わっているプロジェクトの方向性がおかしいと思ったら，自分がどんな立場にいようと強く主張すべきだ。会社はそんなエンジニアを必要としているし，本当に会社のためになるのであれば必ず耳を傾けてもらえるはずだ。「そうは言っても，難しいんだよ」などと逃げを決める上司は怒鳴りつけてやればよい。 会社にとって最悪なのは，「こんなものを作っても誰も使わないんじゃないか，会社の価値を上げることにつながらないんじゃないか」と思いながらも黙々と仕事をするエンジニアだ。そんなエンジニアばかり集まっている会社は絶対に市場で成功しない。プロジェクトに関わるエンジニア全員が，「自分たちがど
１つめの封筒を開けたStephen Elop (CEO of Nokia)
こちら（米国）の携帯業界での今日の一番のニュースは、NokiaのCEOのStephen Elopの書いたメモ。全文がこちらに掲載されている。Nokiaの置かれている状況は、規模こそちがうが日本のガラケー・メーカーの置かれている立場ととても良く似ている。 Symbian Series 60を搭載したNokiaのケータイは、一応「スマートフォン」のカテゴリーには入れてもらえてはいるが、実際のところは日本のガラケー以下のものでしかない。利益率の高いハイエンド市場を完全にAppleに持って行かれ（300ドル以上のケータイの61%がiPhone）、Nokiaにとって稼ぎ頭だった低価格ケータイはいまや誰にでも作れる時代になってしまった。 Stephen Elopのメモで一番印象に残ったのは、この部分、 At the lower-end price range, Chinese OEMs are cra
Androidのアップグレード問題に関してひとこと
前にも似たようなことがあったと思うが、今度はモトローラがAndroid端末のOSのアップグレードに苦労していることが報道されている（CLIQ XT won't get Android 2.1 upgrade, Motorola's word as good as dirt）。この記事を読む限り、CLIQ XTのユーザーが新しいOSを手に入れることは現実的ではなくなってきているようだ。 パソコンのようにハードウェアのアーキテクチャが基本的に同じで、共通Biosのようなレイヤーもしっかりとあるものと比べ、スマートフォンの場合は、それぞれのハードウェアも大きく異なっているし、共通Biosのようなものも存在しない。それに加え、差別化の難しいAndroid端末の場合、ぎりぎりまでにコストを削る必要もあり、それも「バージョンアップとともに大きくなる」OSのアップグレードを難しくしている。 理由は何であ
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者
モバイルブラウザーのデファクトスタンダードになりつつあるWebkit
最近、なぜかいろいろなところでHTML5やら モバイル端末向けのブラウザーの話をすることが多いのだが、今年になってトレンドとしてはっきりと見えてきたのは、WebKitがモバイル端末のブラウザーのデファクト・スタンダードになりつつあるということ。 私自身、最初にAppleがブラウザーを作ると聞いた時には「なんでそんな大変なことを今更？片手間でできる仕事じゃないぞ」と思ったりしたわけだが、その予想に反してAppleが見せた本気度とリーダーシップには本当に関心してしまった。 世の中にすでに何百万とあるサイトとコンパチビリティを保つというだけでも大変な作業なのに（経験者語る）、CANVASやCSS Transform/Transitionなどの新しいコンセプトを次々に導入してHTML5の標準化でリーダーシップを取っている点は注目に値する。 「スタンダードを決める」立場に自分を置く事がどのくらい重要
AT&Tがモトローラ製のAndroid携帯を「時代遅れ」と拒否
今日、米国の携帯業界関係者の間で話題に上ったのが「AT&T rejects Motorola's Android smartphones」という記事。AT&Tから正式に発表された訳ではないが、たぶん真実に近いだろうことは容易に想像できる。 AppleがハードからソフトまですべてコントロールするiPhoneと比べ、GoogleはOSを提供するだけで、最終的な製品の仕上がりはハードメーカーまかせのAndroid携帯は「ソウル（魂）のない」中途半端なデバイスになりがち。 このあたりの事情はMicrosoftのOSを使ったWindows Mobile端末も同じで、「個別の機能を見る限りiPhoneに負けてはいないのになぜか魅力的でない」デバイスができてしまうのは、ソフトからハードまで一貫して責任を持って作り上げることが不可能だから。 この業界の歴史を見ると、古くはMicrosoftが旗ふり役だった
"Less is more"なもの作りと合議制と
ズバリ言ってしまうと既存機能に上乗せする企画は通すのが簡単だし、リスクが少ないからだ。【機能やボタンが多すぎ!! 使いにくいUIのデジタル家電が発売されてしまう本当の理由 - キャズムを超えろ！より引用】 こういった罠にハマらないためには、色々とすべきこと・してはいけないことがあるが、たぶん最も強く意識すべきは「合議制では良いものは作れない」という法則。デザインに関わる人が多ければ多いほど、「いろいろな意見」が寄せられてしまい、「せっかく有意義な意見を出してもらったのだから」と次々に意見を取り入れているうちに、機能だけはたくさんあるけど魂が無くて妙に使いにくいものが出来てしまう。 その意味では、37signalsの人たちが言うところの「less is more」は「単に機能を削って使いやすくする」というだけの話ではなく、「企画に関わる人の数を削って魂があるものを作る」というもの作りの過程そ
ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
できるかぎりエレガントな解法を見つけて「うっかりミス」を減らす
このブログでも何度か書いたことがあるが、ソフトウェアを書くのに高度な数学が必要なケースはマレで、ほとんどの場合は中学生程度の数学で十分である。ただし、中学生時代の数学を「公式の丸暗記」でしのいで来たような人ではなく、「難しい応用問題をエレガントに解くのが楽くてしょうがなかった」ような人が向いているというのが私の持論だ。 例として、以下の二つの数学の問題を見て欲しい。 例題１．時計の長針と短針は、１２時にちょうどピッタリと重なります。次にピッタリと重なるのは何時でしょう。 例題２．サイコロを２個、順番に投げることにします。１つ目のサイコロの目の方が二つ目のサイコロの目より大きい確率を求めてください。 どちらも、中学生の数学を使って解ける問題ではある。例題１は方程式を使って解くことができるし、例題２は順列組み合わせの考えを適用すれば解くことはできる。しかし、それで満足してはいけない。 プログラ
ブログパーツで遊べる自由度の高いブログサービス、ベスト１０
今までこのブログでも４つほどブログ用ミニアプリ（最近は「ブログパーツ」という名前が定着してきたようだ）を公開した来たが（参照）、色々と勉強になる。特に「今日のひとこと」はとても評判が良く、既に５０以上のブログで採用され、なお増え続けている。期待した通りバイラルマーケティングの効果が現れているようだ。 そもそも IFRAME を使ったブログパーツを、「以下のHTMLをブログのサイドバーに貼り付けてください」などという不親切な方法で提供して使っていただけるものか不安であったが、なんとか使いこなしているただいているようである。ただし、IFRAMEが使えるブログと使えないブログとがあるようで、その辺りは一度ちゃんと調査をしなければいけないと考えていたところである。 しかし、自分で調査をするとなると結構な手間なので、ここは wisdom of crowd （「みんなの意見」は案外正しい）の発想を利用
就職・転職活動にブログを利用すべき時代が来ている
はてなの近藤社長の「ブログで人材採用」というエントリーに、「最近はてなでの人材採用の中でちょっとした傾向が出てきているような気がします。それは、『興味深いブログを書いている人』の採用率がとても高いという点です。…インターネット企業に限らず、採用の際に自分のブログの提出が必要な企業がこれから増えてくるかもしれません。」という記述があった。 私の会社でも積極的に日本でリクルート活動を始めたのだが（参照）、東京とシアトルを行ったり来たりしている私としては、応募者全員に合うわけにもいかず、おのずと書類審査が重要になる。しかし、通常の「履歴書」だけではその人のことを知ることは難しいと考え、募集要項に「今まで書いてきたブログ、個人で運営しているウェブ・サイトなどは採用の際にかなり重視するので、ぜひとも積極的に利用してアピールしていただきたい」と書いてみた。 すると面白い現象が起こった。書類審査段階で集
UIEvolution Japan の設立宣言。そしてもちろん、人材募集はGoogle Baseで。
今まで、私の会社（UIEvolution Inc.）は主に米国でのみビジネスを展開してきたのだが、携帯端末・ブロードバンドの普及率、今後２～３年で本格的に立ち上がると予想されるVOD（ビデオ・オン・デマンド）サービス、ネットと繋がり始めるカーナビやデジカメ、などを考慮すれば、そろそろ日本でのビジネスを本気で立ち上げる必要があると判断した。特に、パソコン、携帯電話、セットトップボックス、カーナビ、ゲーム端末、携帯型メディアプレーヤー、などさまざまなデバイス・ネットワークにまたがった形でのパーベイシブ・アプリケーション（参照）という世界を実現しようとしている弊社としては、日本市場は絶好の実験場でもある。 そこで、UIEvolution Japan（UIEJ）を設立することに決定した。ただし、通常のソフトウェア会社の日本法人のように、米国本社で作ったものを日本語化して日本で売る、という代理店的な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
