特許庁のシステム開発が破綻した本当の理由
特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には（１）コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、（２）霞ヶ関から流れて来るお金にたかる IT ゼネコン、（３）そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた９９億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ
JavaScript HTMLテンプレートエンジン SNBinder 公開
先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。 ９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は（MVC
Life is beautiful: Androidタブレットはヨドバシカメラの「Androidタブレットコーナー」に横並びにされた時点で負けだ
今年のCESについてだが、すでに「感心した商品」と「自分も関係していてうれしかった発表」に関しては書いたので、今回は「これはだめかな」と思ったもの。 まずその筆頭は「３Dテレビ」。これ以上大きくすることも薄くすることも解像度を高くすることもできなくなってしまった「成熟しきった」デバイスであるテレビに何とか付加価値を付けようという気持ちも分からないでもないが、正直言ってこれはいらない。CESに出品されている最新の３Dテレビを見てもあまり感動しないし、そもそも目が疲れる。今年の末あたりになって、「結局３Dテレビって何だったの？」という話になると私は見ている。 二番目は「Android」。前にも書いたが、これから家電やスマートフォンの市場に新規参入しようというアジアのメーカーにとっては、Androidを活用して短い開発期間と低コストで「安かろう悪かろう」のデバイスを薄利多売で売りまくるという戦略
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
PhotoCanvas
本日、Big Canvasとしては６本目となるアプリケーション、PhotoCanvasをリリースした。去年の７月にPhotoShareをリリースして以来、PhotoShareのアドオン的な存在のアプリを４本リリースしてきたわけだが、それを通じて学んださまざまなことの集大成が今回のPhotoCanvas。 カテゴリーとしては、SmallCanvas、PhotoArtistなどと同じく「写真加工アプリ」だが、ポジショニングとしては、PhotoShareとならぶ会社の「看板アプリ」として本気で「iPhone向けのPhotoShop」の座を取りに行こうという試みだ。 私が「iPhone向けのPhotoShop」の話をすると、ほとんどの人から「それはいくら何でも無理でしょう」という反応が返って来る。その思考プロセスには「iPhone上でパソコン上のPhotoShopと同じ機能を提供することは技術的に
OilCanvas作品集
PhotoArtistをリリースした直後にも言った気がするが、この手のソフトをリリースした後の一番の楽しみは、PhotoShareに投稿されるユーザーの方々の作品を見ること。OilCanvasをリリースしてからわずか２日だが、すでに数百枚の作品が投稿されており、目を通すだけで大忙しだ。
「デッサン力」がない人が「絵を描く楽しみ」を味わえる時代
上の三つの絵は、私がiPhone/iPod touch向けのお絵描きソフトSmallCanvasで描いた絵だが、パッと見てどう感じるだろう。「結構絵が上手な絵じゃないか」と思った人も多いかもしれない。 実は上の三つの絵は、SmallCanvasの発売に合わせて、私自身がサンプルとして書いたもの。絵心のない私が苦肉の策で作り出したのが、SmallCanvasのundo/redo機能を駆使して写真のトレーシングをするという裏技（アプリの作者が「裏技」を発明してどうするんだ、とうツッコミはなしで^^;）。下に置いた写真をトレースするために、基本的なデッサンがしっかりとし、これだけで「そこそこ見られる絵」になってしまうから不思議だ。 これで再認識したのは、「絵の上手さ」は、「ちゃんとした構図でデッサンが描けるか」という「テクニック」の部分と、「描き手オリジナルの表現ができるか」という「センス」の部
黒船iPhoneを通じて日本のケータイ文化を逆に世界に広めることができるか？
日本のiPhoneユーザーにはとても高い評価をいただいているPhotoShareだが、それもこれも「ケータイで日常的に写真を撮る」「通勤・通学途中には常にケータイで何かしている」という文化・ライフスタイルが既に浸透しているから。そんな文化のない米国のユーザーにちゃんと使ってもらうためには、まずはユーザーにそんなライフスタイルの価値を理解してもらわなければならない。 そのためのプロセスとしてPR会社数社に提案書を作ってもらっているのだが、そのうちの一社が書いて来た資料にこの問題点が的確に指摘してある。 Americans typically don’t use their camera phones as much as other cultures around the world such as the Japanese. PhotoShare’s value proposition h
Cult of Macのインタビューを受けた
WIRED blog networkの一つである、"Cult of Mac"のインタビューを受けた（Cult of Mac - Microsoft’s Windows 95 Architect Is a Happy Mac Convert）。 もちろん目的はPhotoShareのマーケティングのためだが、私が元Microsoftで今はMacばかり使っていることに気がついたインタビュアーがそこばかり話たがるので、PhotoShareの話があまり出来ずに、結局「PhotoShareはiPhone向けのFlickrみたいなもの」ととんだ的外れなことも書かれてしまうし（PhotoShareはFlickrのような写真のストレージ・サービスではなく、日々の経験や出来事をiPhoneのカメラを使ってリアルタイムの他の人と共有するソシアル・ネットワーク・サービス）。 まあ、それでも少しでも宣伝になれば良し
「iPhone開発者支援プログラム」と進化圧と
先日の「iPhone開発者支援プログラム」に関するエントリーに対しては、予想以上のたくさんのフィードバックをいただいた。やはり「もっと日本のエンジニアが活躍する場があるべき」という進化圧のようなものが高まっているのだろう。 支援プログラムに関しては、まだまだ詰めなければならないことがたくさんあるのだが、形としては純粋なNPOでは息が続かないし（そもそも資金が集められない）、かといっていきなり人をたくさん抱え込むのもの得策ではない。やはり受け皿として小さな事業会社を用意して、そこから私が外部のスタッフを交えたいくつかの開発プロジェクトを見る、という形が良いのではと考えている。 ちなみに、最近の私だが、UIEvolutionには週に一日ぐらいしか顔をだしておらず（CEOは去年の１０月に辞任、今は単なる取締役）、他の時間はmasuidriveの増井くんと４月に設立したBig Canvas Inc
WSJからiPhoneに関して取材を受けた
Wall Street Journalの記者からiPhone向けのアプリの開発に関しての取材を受けた。来週のWWDCに向けた下準備らしく、全文がWSJに乗ることはまずないので、私なりにインタビュー記事を起こしてみた。 WSJ：なぜiPhone向けのアプリを作っているのか？ 私：OS+開発環境という意味で他のモバイルプラットフォームより圧倒的に優れているから。私は、Windows Mobile、BREW、Symbian、J2ME/MIDP、J2ME/DojaなどのさまざまなモバイルOS/VMの開発に関わって来たが、iPhoneの開発環境ほど開発効率の良いプラットフォームに出会ったことはない。 WSJ：開発環境に関してはMicrosoftがマーケットのリーダーだと思っていたが 私：Visual Studioはすばらしい開発環境だが、モバイルに限って話で言えば、Xcode上でiPhoneアプリを
プラットフォームを選ぶということ
この業界で仕事をしていると、しばしば迫られるのが「どのプラットフォームに向けて商品開発をして行くのか」という決断。会社としての経営判断の場合もあれば、個人のスキルアップやキャリアパスのための判断の場合もあるが、いずれにしろ限られたリソース・時間をいかに有効に使うか、という点ではとても大切。 パソコン用のソフトウェアであれば、「Windows向けに作るのかMac向けに作るのか」というOSレベルでの選択肢もあるし、「Windows Vista独自の機能を使って差別化を図るのか、それともWindows XPでもちゃんと動くように作ってまずは大きな市場をとりに行くのか」というOSのバージョンレベルでの選択肢もある。もちろん「そもそも特定のOS向けのアプリを作るべきか、それとも、すべてウェブ・アプリケーションとして作るか」というアーキテクチャ・レベルでの選択肢もある。 「少なくともここ数ヶ月はiPh
Life is beautiful: Microsoft／Yahoo：買収はたぶん成功するだろうけど、問題はそれからだ
今回のMicrosoftによるYahooの買収のオファー。ウェブの世界ではどうしてもGoogleに勝つことができないMicrosoftとしては、Yahooのビジネスはのどから手が出るほど欲しい存在。Googleに追い越され、成長に陰りが見え始めた結果株価が安くなったYahooは今がお買い得。WindowsとOfficeというドル箱を抱えながらも、そのドル箱が稼ぎだす莫大な現金をどこに投資すべきかがいまいち見いだせてないMicrosoftとしては、Yahooを買うことによりその価値を買収価格より高くする、というストーリーは説得力がある。 一方、Yahooの株主にとってみればこれは朗報。ずるずると下がり続けていた株に対してこれだけのプレミアムを付けてもらえば喜んで売るのが大半の株主。 少し悩ましい立場にいるのが、Yahooの現行の経営陣。株主利益を最大にするのが役割の経営陣とすれば、このプレミ
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
Life is beautiful: 図解、イノベーションのジレンマ
私がマイクロソフトをやめるキッカケを作ったのが、「イノベーションのジレンマ」という本だということは、以前にも書いた。IT業界でビジネスをしている限り、大きな会社にいようと、小さなベンチャー企業にいようと、この本に書いてあることを日々意識しながら仕事をするかどうかは大きな違いを生むはずだ。 このブログでも何度も引用しながら、一度もちゃんと解説を書いたことがなかったことに気が付いたので、今日のエントリーは、この本に書かれているコンセプトの解説。 そう思っていつもの様に書き始めたのだが、文字だけではとても伝えにくいコンセプトだ。しかし、図解と言えばパワポ、というのもありきたりすぎるので、会社の廊下にあるホワイトボードに手書きで描いた図を、携帯電話で撮影したものを使うことにした。通りがかった社員にも見てもらえるので、一石二鳥である。 上の図は、この本に書かれたコンセプトを一般化したもの。ブルーのラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
