今日のWebの最適なビジネスモデルとはどのようなものだろうか? この問題を巡っては多数ある論説の中でも意見が分かれている。数週間前、Stan Schroederは、アプリケーションへのこれ以上の機能の追加は機会よりもリスクの方が大きいと主張した(リンク)。特定のニーズに対してあらゆる対応ツールを提供することは成功の鍵であるが、「すべてが常に拡大、縮小およびオーバーラップを繰り返す」インターネットによって展開される流動的で変化の激しい環境においては、通用するとはいえない。特にその後の変化に対応する必要がある場合には、そうした対応策は、実際、砂上に楼閣を築くようなものである。 当然ですが、周囲の環境がそれほど変化していない場合は、特定のグループのニーズを十分満足させることができます。[...] かつては、ヒットするアプリケーションを作成しようとする場合、成功の1つの鍵は他社が備えていないような
昨日MIJSのコンソーシアム内での技術発表会があり、理事会の方から「参加ベンダーの技術者が集まるイベントなので、技術者に元気を与えられるような人に講演をお願いしたい」という話があったので、はてな伊藤さんに講演をお願いした。 伊藤さんにお願いしようと思ったのは、伊藤さんなら、エンタープライズの世界にウェブの世界の元気な風を吹き込んでくれるのではないかと思ったからだ。 以下、私なりに講演の内容をまとめてみた。 ■「建物の建て方」 つくる対象がどのようなものかで、作り方は当然変わってくる。これは建物もソフトウェアも同じ。1階建ての格好良い小さなロッジを建てるのと、60階建ての安全で高品質な巨大ビルを建てるのとは方法も道具も異なる。ロッジを建てる時にはノコギリを使うが、巨大ビルを建てるにはクレーンを使う。 よくブログの世界でソフトウェアの開発について、ぜんぜん違うことをやっている人が同じ土俵で議論
Casual Thoughts - 一流企業の一流社員に求められる泥臭い馬力 このエントリに書かれている一流企業の実態は、細かいニュアンスも含めて私が見聞きしてきたことにとても近いと感じる。 私は幸いなことに「(本物の)一流企業の(本物の)一流社員」と仕事をする機会を頂いている。そういう方々は一流大企業の資本力、技術力などの各種のビジネスインフラと自分自身の知見、経験、スキルを卓越した思考力とハードワークによって組み合わせ、お客様、ひいては社会全体に高い価値を提供している。 バックオフィス部門の中には筋金入りのぶら下がり社員が多く、また性質が悪いことにそれを自覚していない人が多い。 大企業というのは一流の仕事をやり抜くためにはプラスアルファでタイヤを10個くらい引っ張って猛進する「泥臭い馬力」が求められるもの 私も多くの一流企業の一流社員と仕事をさせていただいた。そして、彼らが「タイヤを1
_ マルチキャストの歴史に学ぶ研究開発戦略 めずらしく，Atom でも microformats でも Senna でもない話題です． 6月に母校で行った講義スライドが公開されていたので紹介です．昔とっ た杵柄でマルチキャストや Peer-to-Peer を題材としていますが，なぜか Management of Technology (技術経営) っぽい内容だったりします． # そういう教育を受けたこともないのに，いいのかなぁ．． キーワードは，"イノベーションのジレンマ" とかでしょうか．ちなみに， イノベーションのジレンマについては，↓がわかりやすいです． Life is beautiful: 図解、イノベーションのジレンマ 概要はこんな感じ． マルチキャストの世界では，他分野で起きた破壊的イノベーションによっ てメインプレーヤが変わりつつある．マルチキャストは 20年にわたって 研究
私は基本的に会議はきらいだが、特にアジェンダがはっきりと決まっていない会議だとか、何も決定を下さない会議が大嫌いである。そんな中でも、もっとも許せないのが「提案を文書にする」「次のミーティングを設定する」などの一見建設的だが、実は単に意思決定を先延ばしすることを許容するだけの「助けにならない助け舟」である。 営業部長「こうなると選ぶ道はAかBしかありませんね」 社長 「そうは言っても色々と難しい面もある」 技術部長「ここで、決めるしかありませんね」 社長 「そんな簡単な話ではないだろう」 営業部長「そんな悠長なことを言っている暇はありません」 社長補佐「まあまあ。じゃあ、まずは営業部長に彼の提案を文書にしてもらうというのは、どうでしょう」 技術部長「文書にするって、今さんざん話したばかりで、もう分かっているじゃないか」 社長補佐「そうあわてずに。文書にしてもらえば見えてくることもありま
マサチューセッツ州ボストン発--検索業界の著名人らが米国時間6月28日、当地で開催のRed Herring Eastカンファレンスに集まり、次の良いアイデア探しに関心を寄せているベンチャーキャピタリストらに知恵を提供した。 同カンファレンスにパネリストとして参加したAsk.com、Answers.com、Truveo/AOL、Microsoft Searchの重鎮らには多くの質問が寄せられたが、彼らはそれらをうまくかわした。 彼らが浴びた質問の例としては、次に注目すべき大手検索企業はどこだと考えるか、株式を公開する見込みがあるのはどの企業か、ビデオ検索で利益を上げるにはどうすれば良いか、ビデオ検索エンジンに徹するべきか、あるいは検索したビデオをサイト上で視聴できるようにすべきか、などだ。 今週はじめに業界の専門家がモバイルビデオについても同様の発言をしたが、問題なのは、技術が事態を停滞させ
尾藤正人(a.k.a BTO)です 僕はウノウが株式会社化するタイミングでウノウに参画しました。 それ以来はずっと二年半程Webサービスの開発に従事してきました。 ウノウに参画した当初はWebサービスのことは全く分かっておらず、 単なるLinux好きのエンジニアにすぎませんでした。 ウノウ株式会社の創業時に参画することにより、 サービスの企画から開発、運用まで携わることができました。 最初はエンジニアが自分一人だけだっとところから、 現在のように数多くの優秀なエンジニアを抱える企業に成長するまでの組織作りにも関わることができました。 全く経験のないところから始めたので、それこそいろんな失敗を重ねてきました。 そこで今までの経験を元にベンチャーがWebサービスを開発するにあたって気をつけておいた方がいいことをまとめてみます。 Webサービスの開発を始めるには、何はなくとも企画から。 今回はW
UIEvolution の起業は私にとっては初の起業であった。今から思い直してみると、ビギナーだった故のたくさんの失敗をしてきたが、今の私から見て「良くそれなしで会社として成り立ったなァ」と言いたくなるよう恥ずかしいことを一つしている。 「User Experience Matters」、「Pervasive Application」など、会社の外に向けたビジョンやミッションははっきりと打ち出していたものの、どんな人を採用してどんなカルチャーの会社にしたいか、という会社作りにおいてもっとも大切な「企業理念」を目に見える形の言葉にしておかなかったのである。 そもそも「企業カルチャー」の大切さを私が理解していなかったこともあるし、私自身の中でも「どんなカルチャーの会社にしたいか」というイメージが固まっていなかったのもある。Google・Microsoft・Sony・Honda、どれもファウンダ
Google Videoに「 How Open Source Projects Survive Poisonous People (And You Can Too)」という54分のビデオがありました。 Subversionの開発者達が、オープンソースプロジェクトを運営上の注意点を解説していました。 面白かったです。 ボランティア開発者の集合体によって実現しているオープンソースプロジェクトを運営する方法を解説するという題目ですが、 最後のオチでは、「これはオープンソースに限らない」と言っていました。 確かに、一般的な開発でも参考になる部分は多いと思いました。 また、掲示板やブログのコメント欄でも一部は適用できそうなノウハウであると思いました。 要約してみましたが、結構いい加減で間違いなどがあると思うので詳細はビデオをご覧下さい。 「Poisonous People」は「有害な人」と訳してみま
Web2.0の次にどんな世界が来るのか――。 インターネットに携わる者なら誰でも、それを見据えて戦略を組むのと、ただ時代の到来を待つのとでは、将来大きな差が生まれることを知っている。Google然り、Amazon然り、来るべき次の世界にいち早く、かつ的確に備えた者が生き残るのだ。 今は「ページ」のみにとどまるナビゲーション 現在の情報産業の多くは、インターネットとウェブブラウザの誕生、そしてそれに続くウェブページの出現とともに発生した。そしてそれらの産業は、情報を出すことではなく、読者や視聴者にページのナビゲーションを与えることで収益を上げてきた。そういった産業が発達したために、検索したとき上位に表示されるにはどうしたらいいか、それをどうコントロールするか、という点が情報発信者にとっても重要となった。 現在はそこからさらに一歩進み、ソーシャルネットワーキングサービス（SNS）やブログが登場
失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント：デジタルワークスタイルの視点 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。これらを管理しようとすればするほど悪いスパイラルに落ち込みます。Appleやはてな、Googleなど、注目企業ではどのようなマネジメントを行っているのでしょうか。 「完璧に管理しようとすればするほど、プロジェクトは失敗する」という悪いスパイラルが存在します（2月21日の記事参照）。そこで今回は、どのようなプロジェクトマネジメントをすれば、プロジェクトを失敗させないようにできるのか考えてみたいと思います。 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。前回はそれぞれを完璧に管理しようとしていましたが、今回は考え方を180度変えてみましょう。それぞれの要因を最初からなくしてしまうのです。 失敗しない
2007年02月19日01:30 カテゴリCode プロ^2グラマーは社交が8割 趣味でプログラムをするシュミグラマーや、本職は別にあって、たまにプログラムするタマグラマーはとにかく、プログラミングそのものを職にしているプロプログラマー(以下プロ^2グラマー)の業務の8割は、実はプログラムを書く事ではない。 実感としては、顧客(社内顧客含む)との折衝が4割、学習が4割といったところ。残った2割が実際にコードを書いている時間。計算上は、週5日のうちコードを書いているのは1日しかないことになる。そして本当はそのコードを書いている時間も、コードを書く時間よりコードを読み返したり他のコードを読んでいたり、実のところぼけぇっとしていたりという時間が8割。 このプロ^2グラマーは、さぼっているわけでも無能な訳でもない。むしろ有能だとされるプログラマーほど、「オフタイム」が長い。そしてそのオフタイムの間
この記事はJohn Milanが執筆した。これは2回連続記事の前編となる。後編はこちら。 明日のソフトウェアソリューションはどんな姿をしているのだろうか。それは、次の4つの要素で構成されるだろう。インターネット、オープンソース、モバイルデバイス、そしてWeb 2.0だ。ここで、各要素のメリットについてそれぞれ議論することはできるが、むしろ全体として見たとき、明日のアプリケーションがどうなるかということについて、どのような青写真が作れるかが問題だ。 最近の投稿でわたしはIT産業における進化や地球温暖化を取り上げてきたが、今回は「突然変異」という対極的な話題が意味するものを考えてみよう。古くからあるソフトウェア界のリヴァイアサンたちは、次世代のソリューションを生み出そうと必死だ。これまで、大きさとスケールは企業にとって有利に働いてきたが、4つの大きな要素が、後戻りのできない一連の変化を引き起こ
ストーリー by mhatta 2007年01月22日 9時00分 FLOSS開発者への優遇税制という発想はなかなか面白いな 部門より enbug diaryで紹介されていましたが、タイトルを和訳すると「EUにおけるICT(情報通信技術)分野のイノベーションや競争力に関して、オープンソース・ソフトウェアが与える経済的影響力の研究」となる報告書が発表されました(PDF)。英文で300ページ近い大部のものですが、「オープンソースへの移行は中長期的にはコスト減につながる」「移行にはコストを要するが、一時的でかつそれほど多額ではない」といったオープンソース推進派の主張を豊富な調査で裏付けるものです。EUとは言いつつ北米やアジア・ラテンアメリカの状況にも言及しており、私達にとっても興味深いレポートになっています。 現場で経験的に感じている物であっても、こうやって報告書としてまとめてもらうとなるほど(
「ブログ」や「SNS」といったWeb 2.0的な情報共有ツールの社内利用が進んでいる。「利用の敷居が低く，従業員が持つ情報を呼び込みやすい」というメリットから，活用事例や社内利用向け製品が充実しつつある。日経コミュニケーション2007年1月15日号でも，「企業内ブログ/SNSの威力」と題した特集を組んだのだが，その取材の過程で記者はあることを恐れていた。それはユーザーやベンダーの口から，「内部統制」の4文字が語られること。「社内に埋もれていた情報を引き出す」というブログ/SNSの効果を削ぎかねない要素だからだ。 その懸念は，取材に着手した2006年11月に野村総合研究所が開催した「ITロードマップセミナーAutumn 2006」で耳にした亀津敦・副主任研究員の指摘（参考記事）に端を発する。亀津氏はこのセミナーで「社内SNSを導入しなければ情報漏えいのリスクが高まる」という見解を披露した。m
ITプロジェクトのマネジメントにおいて、本書はまさに宝の山といえる。 一回の探索では持ちきれないほどのアイディアがザクザクと手に入る。しかも、ひとつひとつの宝が、著者の経験に裏打ちされ、考え抜かれているため、一回読みでは消化不良を起こす。それぞれのフェーズで読み返すことで、順番にモノにしていくやり方が良いかと。 このエントリでは、自分の振り返り読みのために、読書感想文エントリの目次と、次に読むべき本・サイトのをまとめた。わたしだけでなく、誰かの参考にもなればイイナ！ その1 ・オーバービュー その2 1章「プロジェクトマネジメントの簡単な歴史」からの考察 ・PMにとっての最重要ツール ・アート ―― 技芸と呼ぶ理由 ・ホワイトボード地獄 その3 2章「スケジュールの真実」および、 3章「やるべきことを洗い出す」からの考察 ・何のための開発プロセスか? ・見積もり確度を上げる2つの質問
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
