「マーケティング」という言葉を聞くと「商品に関する情報を顧客に向けて発信する」だけと考える人が多いが、マーケティング部門の役割として同時に重要なのは、顧客のニーズをきちんと探り出して「何を作るべきか」という部分に反映させること。 ちょうど今読んでいるHarard Buisness Reviewにとても良い例が出ていたのでその紹介。 米国のペンキ会社が、競争相手に安売り競争を仕掛けてられ、「利益を削ってでもマーケットシェアを維持すべきか」という厳しい選択に迫られていた。その時にその会社のマーケティング部門が調べ出したのが、主な顧客である塗装業者が何にお金を使っているかというデータ。 そのデータによると、ペンキそのものは経費の１５％にすぎず、大半は人件費だという。それも、ほとんどのケースで、一度塗ったペンキを十分に乾かすために、次の日にもう一度現場に足を運んで二度塗りをしているためによけいな人

これを読んで、「SIerの仕事って『工事』だったのかあ」と思った人は私だけではないはず。 これまでSIerは、工事進行基準ではなく、開発終了時に売り上げと原価を一括計上できる「工事完成基準」を取るケースが多かった。一般的に日本のシステム開発は要件定義やユーザー企業との契約が明確でなく、開発中の手戻りや期間の超過が多い...【デスマーチがなくなる？ IT業界に義務付け「工事進行基準」ってなんだ − ＠ITより引用】 さらに「工事進行基準」と「工事完成基準」の定義を読むとますますそう思える。 工事進行基準 長期請負工事契約に関する会計上の収益認識基準の1つ。工事期間中、目的物が完成に近づくにつれて徐々に収益が発生するものと考え、工事の完成度合いに応じて工事に関する収益と原価を計上し、各会計期間に分配する方法である。“発生主義”に基づく収益認識法とされる。【工事進行基準 − ＠IT情報マネジメン

ズバリ言ってしまうと既存機能に上乗せする企画は通すのが簡単だし、リスクが少ないからだ。【機能やボタンが多すぎ!! 使いにくいUIのデジタル家電が発売されてしまう本当の理由 - キャズムを超えろ！より引用】 こういった罠にハマらないためには、色々とすべきこと・してはいけないことがあるが、たぶん最も強く意識すべきは「合議制では良いものは作れない」という法則。デザインに関わる人が多ければ多いほど、「いろいろな意見」が寄せられてしまい、「せっかく有意義な意見を出してもらったのだから」と次々に意見を取り入れているうちに、機能だけはたくさんあるけど魂が無くて妙に使いにくいものが出来てしまう。 その意味では、37signalsの人たちが言うところの「less is more」は「単に機能を削って使いやすくする」というだけの話ではなく、「企画に関わる人の数を削って魂があるものを作る」というもの作りの過程そ

シアトルの新聞社Seattle PIにVenture Blogというベンチャー企業をテーマにしたブログを書くJohn Cookという人がいる。その人とたまたま話す機会があったので、以前から聞きたかった質問を投げかけてみた。 私「せっかく良いアイデアを持っていたり、すばらしい技術を持っているのに、投資家からお金を集められずに消えて行くベンチャー企業って沢山あるよね。何とかしてあげることはできないのかな？」 John「それは必要ないと思うな。ベンチャー企業の経営者に一番大切な能力は、『必要なものは何とかして手に入れてしまう能力』だよ。起業資金ぐらい自分で集められない起業家に、ベンチャー企業が経営できるとは思えない。」 確かにJohnの言う通りである。ベンチャーの生き残り合戦は、ダーウィンの適者生存の法則がそのまま当てはまる世界。自然淘汰のプロセスは資金集めの段階から既に始まっている。だから手を

先日、梅田望夫さんと対談（月刊アスキーに掲載予定）したときに、「なぜGoogleは通信インフラにまで投資をするのか理解しがたい」という話題が出たが、その一つの答えがこれ。 After a couple rounds of stalled bidding, the C Block's provisionally winning bid is now at $4.7 billion, about $100 million over the reserve price that the FCC set for the block of spectrum. Since the reserve price was met, the FCC will not have to re-auction the block and its special rules: open access for any

Appleが最近申請した特許出願には、iPhoneユーザーを対象にした未来におけるキラー機能のヒントが垣間見える。コーヒーショップやその他小売店舗での商品注文をiPhoneから行うことで、（店舗内の）順番待ちの行列をバイパスできる、と言ったものだ。【TechCrunch Japanese アーカイブ » Apple、長い行列での順番待ち回避方法を特許申請より引用】 この特許そのものに有効性があるかどうかはいささか疑問だが、この特許やアップルが現在スターバックスでしていること（「店の中で流れている曲」を購入できる機能）を良く見れば、今後iPhone（iPod touchを含む）を利用したラテの注文および電子決済に進むのはほぼ間違いないだろうことが分かる。 スターバックスとアップルは、わずか数ヶ月前にスタバという実店舗とiTune Storeを連携させることを発表したばかりだが、「スタバのiT

アップルがiPod+iTunes+iTunes Storeというハード・ソフト・サービスを巧みに組み合わせてネット時代にふさわしいコンシューマ・エレクトロニクス・ビジネスモデルを見せてくれたことに関しては、ここでもさんざん書いて来たが、反面教師として注目すべきなのは、ソニーになぜそれができなかったのか？ということ。 自分自身がメディア産業を持ち、ウォークマンというブランドを持ち、ネットビジネスに抜群のセンスを持つ出井氏を社長に据えたソニーはアップルよりははるかに良い立場にいたはずだが、なぜこんなことになってしまったのだろうか。 メディア産業を持つことが逆に足かせになった、ソフトウェア開発力の差、たまたまラッキーだっただけ、天才スティーブジョブズがいたから、イノベーションのジレンマ、などのそれぞれの側面から考察を加えることは可能だが、あの時代のソニーに特有の問題として特に注目すべきなのは、あ

先日の「習作UI: 縁日の金魚を再現してみた」というエントリー。特に深い意味もなく作ったのだが、ソフトウェア・エンジニアを目指す学生さんのためにひとこと付け加えておきたいのは、この業界で本気で成功しようと思ったら、この程度のプログラムは、シミュレーションの専門家でなくともサクッと作れるように自分を鍛えておかなければいけない、ということ。 この業界で働きはじめると、担当した仕事によって、データ解析・Java・３D・シミュレーションなどのある特定の分野のプログラミングの経験を積むことになる。そういった経験を通して特定の分野を深堀りしてエキスパートになるのはおおいに結構なのだが、往々にして落ち込んでしまうのが「ボクはJavaのエキスパートだからRubyではプログラムは書かない」、「シミュレーションのことならそれに詳しいエンジニアがいるんだからその人に頼んで」、「今からFlashを勉強している時間

アップルの作る製品のデザインがなぜあれほどにすばらしいかを熱く語った文章を発見。一番気に入った部分を引用してみる。 "The businessman wants to create something for everyone, which leads to products that are middle of the road," says Brunner. "It becomes about consensus, and that's why you rarely see the spark of genius." "Critical to Apple's success in design is the way Jobs brought focus and discipline to the product teams," ­Norman says. "[Jobs] had a s

１．とにかく分かりやすく書くこと ２．難しい言葉の使用をできるだけ避けること ３．何を伝えたいのかはっきりと意識して書くこと ４．伝えたいことをできるだけ一つに絞ること ５．視点・立ち位置がぶれないようにすること ６．一つのエントリーをあまり長くしないこと ７．できるだけ明るく・ポジティブに表現すること ８．ユーモアを交えること ９．無理せずに自然にまかせて書くこと １０．既存の枠組みにとらわれずに書くこと 糸井重里の「ボキャブラリーというのは『どれだけむずかしい言葉を知っているか』ではなく、『どれだけやさしい（人に伝わりやすい）言葉を知っているか』という意味なんです」という言葉は本当に正しいと思う。 どんな文章にも言えることだが、分かりやすくなければ読んでもらえないし伝わらない。せっかくブログを書くのだから、読んでもらいたいし伝えたい。それがブログの「おもてなし」。 【同時に読んでいただ

最近の梅田さんのエントリーを読んでいて、何やら言いたくなったことがあるので、ここに書いておく。それは、 「自分がやりたいこと」と「会社にとって必要なこと」のベクトルを合わせることができた時に大きな力が出る という私自身の仕事に対するプリンシプル。 私自身のキャリアを振り返ってみると、会社と私のベクトルをシンクロさせることができたアスキー出版やマイクソロソフトでは、好き勝手なことをやっていて会社の成長に貢献することができたが、どうしてもシンクロさせることができなかったNTTの研究所は長続きしなかった。楽しければ徹夜も苦ではないが、楽しくなければ一日８時間会社にいることすら辛くなる。 別の言い方をすれば、「楽しんで、かつ、会社の業績に貢献する」ために自分が何をしなければならないかを常に意識していて働いた方が良いということ。今やっている仕事が会社にとって何の役に立つのかが理解できなかったり、やっ

アメリカの法律では、未成年との性交渉はたとえ双方の同意のもとに行なわれたものでも「レイプ」とみなされて実刑判決は免れない。未成年の少年・少女には「まだ判断能力がないから」というのが理由だ。 実刑判決を受けた人は、氏名も顔写真も公開されてしまうので、ほとんど「社会的に抹殺」された状態になる。少女売春を援助交際などという言葉のオブラートに包んでなかば放置している日本とは大違いだ。 ほとんどのケースが、大人の男性と少女の間の話だが、まれに大人の女性と少年の間の話になるとメディアが大騒ぎをする。今朝のニュースでも、女性教師と関係を持った少年がインタビューを受けていた（左の写真は、その女性教師）。 このニュースを見ながら、「男性ホルモンが体中にあふれている思春期の少年が、こんな先生にセマられたら『判断能力』をなくすよなァ」と私が茶化すと、「じゃあ、大人になったらちゃんと「判断」ができるようになるわけ

先日の従軍慰安婦問題に関するエントリー、少し言葉が足りなかったようなので補足する。 まず、私が「政治家と軍人の『あやまち』」と言っているのは、「従軍慰安婦の強制的連行に軍が関与したかどうか」などの個別のあやまちの話ではなく、負けるに決まっているアメリカに戦争をしかけたこと。その「大きなあやまち」が数々の不幸や狂気を生み出した事実は否定のしようがない。 そんな「戦争の狂気」の中で、究極の状況に置かれた人間の弱さゆえに、軍規を破って武器を持たない一般人を殺害したり・強制連行したり・レイプしたりということは、日本軍・アメリカ軍に限らず実際に色々とあったことはほぼ確実なわけで、そんな人間の弱さから目をそむけて「先祖の名誉のためにも疑いを晴らす」と言ってしまう発想は、かなり甘いし偏っていると私は思う。 クリント・イースト・ウッド監督の「硫黄島からの手紙」がすばらしいのは、自分たちの先祖ばかりを美化し

何かの「ユーザー・インターフェイス」を決める時に大切なことは、自分なりのはっきりとした「デザイン・ポリシー」を持って、誰が何と言おうと最後までそれをしっかりと押し通すこと。そういう「柱」をしっかりと持たないで作ったものは、往々にして「妥協の産物」になってしまう。 私が常に心がけていること（つまり、私のデザイン・ポリシー）は、「ユーザー・シナリオを８０：２０ルールで切り分け、常に８０の方（つまり多くの人が使うだろう機能）を最優先にした設計にし、２０の方（あった方が良いかもしれない機能、一部の人が必要とするかもしれない機能）は思い切って犠牲にする」こと。 典型的な良い例が、Youtubeを見るためのサービス、Rimo と oreseg。 機能的には、カテゴリー分けはしてくれているし、サムネールから自分で見たいものを選べるし、oresegの方が上である。しかし、「ただだらしなく面白そうなビデオを

週末に作ったシオレットに関して、自分で解決できなかった二つの問題点を書いておいたのだが、読者の方からのコメントで解決することができたのでここで報告。 一つは、Firefox上でFlashのバナーを持つページを見ているときにシオレットを起動すると、メニューの一部がバナーで隠れてしまう問題点。rakuto氏からの「position:fixedにして絶対配置にすることでFlash上に配置することが可能」という指摘どおりに変更を加えて解決。 もう一つは、Safariでシオレットがさっぱり動かないという問題点。こちらは、iwasaky氏の「siolet.jsの110行目に全角のスペースが入っているためにSafariでは動かないようです」という指摘どおりに全角スペースを半角スペースに置き換えて解決。 本当にありがたいものだ。ここを借りて感謝の意を表する。 これで思い出したのが、以前、梅田望夫に聞いた「

はてなの人気エントリーに見つけた「頭のいい人が成功できるかどうかの境目」というanonymousなエントリー。ちょっと彼（そのエントリーの作者）の将来が心配になったのでひと言。 そもそも「頭が良さ」が一つのものさしで計れると思っている点が大間違い。百歩譲って、「旧帝大の大学院にトップクラスの成績で入れるぐらいの学力がある」＝「頭がいい」という彼のものさしを認めたとしても、「俺はこんなに頭がいいのになぜ成功できないのだろう＝頭がいい人は成功して当然」という発想はあまりにも甘すぎる。子供のころから、「東大に入りさえば幸せになれるのよ、○○ちゃん」という母親の一途な価値観だけに踊らされて塾に通い続けた学歴社会の被害者、とで言えば良いのだろうか。 これを読んで思い出したのが、大学時代の同期の一人。成績は文句なくクラスでトップ。ものすごく頭の切れる男で、修士号取得後に霞ヶ関の官僚になったのだが、彼が

息子の大学で授業参観をする機会があったので聴講したのが「Corporate Finance」の授業。わずか７０分の授業であったが、とても分かりやすかったので復習の意味も兼ねてここに解説してみる。 まず、会社として採用することを考慮している二つのプロジェクト、「S」と「L」があったとする。プロジェクト「S」は、一年目に５０万ドル、二年目に４０万ドル、三年目に３０万ドル、四年目に１０万ドルのキャッシュフロー（＝会社に入ってくるお金）を生み出すが、プロジェクト「L」は、一年目に１０万ドル、二年目に２０万ドル、三年目に３０万ドル、４年目に６０万ドルのキャッシュフローを生み出す。 それぞれのプロジェクトに１００万ドルの資金が必要で、調達した資金には１０％の利息がかかると仮定したとき、会社としてはどちらのプロジェクトを選ぶべきか、というのが今回の課題である。 「投資した資金を回収するのにどのくらいの期

昨日のエントリーで、「人は一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する」と書いたが、「パンを焼く」という仕事を例に取れば、こんな風になる。 １．イーストを３０℃のお湯と一つまみの砂糖とまぜて１５分間予備発酵させる ２．ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる ３．こね板の上で生地をこねる ４．ボールにラップをして室温で１時間発酵させる（一次発酵） ５．適当な大きさに生地を分割し、丸めて形を作る ６．オーブンに入れ、３０分発酵させる（二次発酵） ７．オーブンの温度を２００度にして１８分焼く これは、ソフトウェアで言えば「手続き型のプログラム」であり、人間が一連の作業を把握するのに最も適した記述の仕方である（その証拠に、実際のどのレシピブックを見ても、レシピは必ず「手続き型」で書かれている）。 興味深いのは、このレシピにおける、「１５分予備

ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、

先日の「スティーブ・ジョブズの面接試験、iPhone編」には、たくさんの方々にコメントをいただき、まさに双方向性のコミュニケーションの楽しさを満喫させていただいた。出題の際にも述べたが、この手の問題には特に決まった正解があるわけでもないので、出来るだけ多くの方から、さまざまな意見が出てくることそのものにとても価値がある。 しかし、出題者の私が皆さんの意見を読んでいるだけでは双方向性が不十分なので、今日は私なりの解釈を書いてみる。 結論から先に言えば、新生アップルの経営戦略が「パソコン上で走るiTunesをホーム・エンターテイメントにおけるメディア・ハブおよびメディア・ゲートウェイのデファクト・スタンダードにし、それにスポークとしてつながるさまざまなデバイスを開発し、同時にiTune Storeからそういったデバイス向けのさまざまなデジタル・コンテンツをiTunesを通して流通させる」という