Twitterでフォロワーが何万人もいる人でも一万人以上フォローしている人はカッコ悪い。 そういう人は自動プログラムor人力による強制フォロー増加などなどのケースが多い。 フォロワーはWebからカネで買える。相場は１万人2万円代。 そもそも一万以上フォローするとTLがソーシャルとして機能しない。 フォロアー数は意味がない。その人の価値でもない。 「いいね！」もカネで買えるので実態と合ってない数は意味がない。 まぁ、ぶっちゃけ、みんな知ってるフォロワー数/フォロー数率論です。ネット業界はみんな知っている事ですが、Twitterやfacebookが一般に広まってきたので書いてみます。正直、今さら感満載なエントリーなんですけど、意外と知らない人も多いのであえて書きます。この前ネット業界の人にすら「****さん(アヤシイコンサルタント)ってソーシャル業界でスゴイ人ですよね！フォロアーが*万人います

10月12日、ソニーからGoogleTV(世界初)が正式発表される(関連記事)が、その革新的な機能の全貌がウェブページで明らかになったので速報したい。 詳細を閲覧できるのは、GoogleがローンチしたGoogle TV websiteだ。 ・ Google TV Website このページに、Quick TourやFeatures、Get Itなど詳細な情報があるので、ぜひチェックを。 ここでは "Features" から機能が紹介してある部分をイメージ抜粋したい。またそのポイントを下記にサマリーしてみた。 ■ 機能のポイント(上記イメージ内を上から順番に) テレビ番組(クラウド上にあるマイリストを含む)、ウェブサイト、Androidアプリを、検索窓から共通のユーザーインターフェースでサーチできる Flash10.1を含むブラウザで、ウェブをテレビチャンネルのように閲覧できる 多様なAnd

最近、アジャイル開発を「繰り返し型」の形として採用するのはいいが、そこで実際に開発活動をする人たちのスキルに、再度焦点が当たっている。つまり、プロジェクト管理手法としてのみアジャイルを取り入れても、破綻する、ということだ。ソフトウェア開発技術は、匠の技であり、この技術は職人の技だ。この議論は、 James Shore の「アジャイルの衰退と凋落」 Brian Marick の「What's missing from the Agile Manifesto」 Uncle Bob Martin の「Craftmanship over Crap」 などからの流れなのだが、ついに、「ソフトウェア職人宣言」が出現した。以下に、訳文とそのURLを書いておくので、同意する人は、サインをしよう！ ソフトウェア職人宣言(原文： http://manifesto.softwarecraftsmanship.o

Mac、iPhone、iPod、歌声合成、DTM、楽器、各種ガジェット、メディアなどの情報・雑感などなど NEW：20分で理解するSekai Camera〜セカイカメラ関連記事のまとめに、新たな関連記事まとめを作りました。 追記（2009-10-31）：仮想現実に関するTwitterアカウント「ar_onetopi」をOneTopiで始めました。セカイカメラをはじめとするAR関連の最新トピックを追いかけています。まとめページはこちら。 これはきょうのAppleの発表もぶっとぶほどすごいことなのかも。世界カメラ「Sekai Camera」。SekaiCameraとの表記もありCEOの井口氏はセカイカメラと言っているので、日本語表記は「セカイカメラ」かな？ まずはYouTubeの動画をどうぞ。 TechCrunch 50で、日本企業のTonchidot（頓智・）がプレゼンテーションして絶賛され

一昨日のエントリーでちょっと書いたHuluが大迫さんのブログで詳しく紹介されています。 中でもすごいと思ったのは、動画コンテンツを他のサイトで埋め込み表示するときに、開始点と終了点を指定して埋め込みができるところです。たとえば、ブログや掲示板で「昨日のHey!Hey!Hey!のかしゆか萌え～」（あくまでも例）と書くときに、まさにその「萌え～」の瞬間の動画映像をそこに貼り付けることができるわけですね。これってすごいエクスペリエンスではないでしょうか？これこそが放送とネットの融合のあるべき姿の一例だと思います。 ちなみに、この機能はニコ動よりもちょっと前から中国で動画コメント付けサイトを展開していたMojiti社をHuluが買収したことで実現できたようです。ゆえに、ニコ動式の動画コメント付けがHulu上で実現されることも充分考えられるでしょう。（なお、Mojitiの元々のサイトは既に閉鎖されて

ついに対応の検討をはじめました！ delegate、event、property など、難題はいろいろあるのですが、これをどう、JUDEらしく実現するか、がデザインの肝だと思っています。 私は、UMLの言語プロファイルを使って実現する、という方向でない、もっと自然なやりかたがいいのではないかと思っています。クラス図を描いても、そこに<<C#Language>>ステレオタイプとかあまり見えて欲しくない。言語特化したくないデザインもある。しかし、言語特化したいデザインがあると思うし。。。 と悩みはつきないのでした。要望のある方、ぜひこちらまで。 http://jude-users.com/ja/modules/weblog/details.php?blog_id=183

ソフトウェア開発における、資産とはなんだろう？単純に考えると、「ソースコード」というソフトウェア設計図そのものを中心に、それを開発するためのドキュメント、テスト、ユーザマニュアルなどを考えがちだ。人は、これらのまわりで、これらを作り出し、メンテナンスしている。 しかし、実際は「人、一人ひとりの頭の中」も、資産だと考えないといけない。すなわち、ソースコードになっていない思考過程、ノウハウなど。。。ソフトウェア開発は、壮大な伝言ゲームであり、脳の中で情報を加工し、その情報を別の脳に伝え合って開発している。 例えば、ドキュメントがしっかり整っていれば人は交換可能だ、と考える人もいるが、ぼくはこれはナンセンスだと思う。暗黙知も含めて、頭の中にある「スティッキー」な情報はすべてをドキュメントに書き出すことはできない。聞かれれば答えられる情報すべてを、聞かれる前に紙には書けないし、「こういう場いいどう

ボストンにて開催中の、SDBP 2007 にきています。昨日の基調講演は、「ソフトウェア開発のダイナミズム」(原著Dynamics of Software Development)で有名な、Jim McCarthy です。いつか見てみたい人だったので、偶然この機会に出会えてとてもうれしい。 彼のポイントは、「製品作りはチーム作りと同義である」ということ。製品は良いチームから生まれるし、悪いるいチームからは悪い製品しか生まれない（それぞれ、逆も真）。ビジョンを共有したチーム、の強さ、人のパワーについて、アクションを交えた語り口のとてもおもしろい講演でした。 講演中、会場を交えてこんな実験を。 「ビジョンを共有し、情熱あふれるチームに参加した経験がある人は起立してください。」 ⇒約８割が起立。 次に、「そのチームにいるとき、ビジョンを共有ていしないチームにいるときよりも、２倍よかった、と思う人

Mary Poppendieckのリーダーシップについてのセッションは、立ち見（というか地べた座り）で満席。とくに、ＴＰＳとアジャイルの中から、「人」についての共通の考えを導き出しています。 「標準化」とはなにか。Mary は「現場の経営」（大野耐一の唯二の著書の１つで、最近英訳された）から、以下を引用し、いま、ソフウェア業界、多くの大企業で行われている間違った標準化について、指摘しました。 標準は、カイゼンの最初のベースラインというだけで、変えることが前提なんだ、そして、それはかならず現場で書く。 現在のソフトウェア業界で、いかに多くの「標準」というものが、現場から離れて書かれており、かつ、変えるのが困難か。作るのに１・２ヶ月もかかったら、それはもうダメだ。他人が机の上でつくった標準ではなく、「自分たちが作った標準」でなければ、カイゼンのモチベーションはうまれない。こういう、「あたりまえ

思いやり駆動開発（ODD） ソフトウェア開発を成功させる、もっともシンプルな「こころがけベース」のアプローチである。オブジェクト倶楽部2007夏イベントで発表された。ここでは、ついカッとなって私なりにこのコンセプトを膨らませてみたい。 ソフトウェア開発はコミュニケーションでできている。ソフトウェアの欠陥が発生しやすいのは、人と人の境界、プロジェクトとプロジェクトの境界。そしてそこにはコミュニケーションが生まれている。コミュニケーションには相手があり、その相手を「思いやる」ことが、大切だ。読み手のことを思いやるコードを書こう。システムのユーザを思いやる仕様にしよう。そんなシンプルな「こころがけ」だ。 具体的には、こういうこと。 システムを実際に使う「ユーザー」を思いやろう。ストレスなく使え、「思った機能がそこにある」ようなシステムにしよう。そのユーザが普段使っている言葉のUIを提供しよう。製

何度か書いたニコニコ動画ネタであるが、ここ最近ニコニコ動画を見ていて感心しきりだ。それというのも、次から次へと新しい楽しみ方や遊び方が出てくるのだ。 特にここ最近私が凄いなぁと思うのがアイマス（IM@S）関係の動画。アイマス（IM@S）というのは、バンダイナムコゲームスの作ったTHEIDOLM@STERというゲームのことであるが、このゲームの中に出てくるアイドルの歌唱＆ダンスシーンにいろいろな曲を充てた楽しい画像がニコニコ動画にはけっこうあるのだ。 もともととかち祭りあたりでアイマスネタが多いことは知っていたのだが、先月にCDTVをネタにした素晴らしい出来の作品が発表されてこの分野の動画が非常に沢山あることを知った。更にその後このランキングは週刊で更新/発表されるようになっている。 ===2007/6/10 AM追記 アイマスランキングの前に「週刊ニコニランキング」というものがあったことを

TRICHORDの開発は、完全にアジャイル開発です。タイムボックスを区切ったマネジメントスタイルで、基本的に残業はなしです。っていうか、一日３コマのペア・プログラミングをやったら、へとへとで残業できません。ということを言ったら、記事になっていました。 残業ゼロの開発現場 http://itpro.nikkeibp.co.jp/article/OPINION/20070523/271904/ なぜ残業をなくせるかというと、それは（当たり前のことなんですが）開発のビジネスオーナーが自社だからです。受託型の開発だと、それはなかなか難しいのだと思います。つまり、ミッションとリスクをビジネスとITの間で分割してしまうと、そこでWin-Win関係と良好なコミュニケーションを確立することが難しくなってしまいます。 市場を「調査」し、仕様をまとめ、それを「発注」する。そして、それを開発し、「納品」し、市場

ネットワーク応用通信研究所(NaCl)さんと、Ruby + Agile で業務提携」というニュースをリリースしました。 永和システムマネジメント：http://www.esm.co.jp/news/newsrelease20070516.html NaCl：http://www.netlab.jp/news/2007/05/16/20070516/ ビジネスの変化をすばやく捉えて開発するアジャイル手法と、柔軟で人にやさしい言語のRuby。ともに、「人を中心にすえて、人が使いやすいシステムを、人が開発する」という視点にたった、顧客と共同チームでの開発を提案します。 このリリース文ですが、かなり「思い」がこみ上げてくる文章が一部入っていて（ここはかくたにが書いているのですが）、「リリース文ぽく」なくて気に入っています。 ソフトウェアは、『育てるもの』と捉え、顧客と開発者がひとつのチームとなって

先日、電話でインタビューを受けたものが、podcast されました。 Software Process and Measurements: http://spamcast.libsyn.com/ 一つの自慢は、このインタビューシリーズの中に、Capers Jonesがいることです。skype での録音なんで、ちょっと聞きにくいものもあるかも。 interview with Kenji Hiranabe on using mind mapping in agile projects.  Mind Mapping is a powerful technique to order information and concentrate communication.  The interview with Mr. Hiranabe includes a large number of practi

資料公開はじめました！ぼくの資料は、あの時、書画カメラに向かってフリーハンドで描いた絵の「下書き」も含めました。前のブログで書きましたが、 ソフトウェア開発は壮大な伝言ゲームであり、ソフトウェアはビットの塊ではなく、コミュニケーションの塊で出来ている。そして、このコミュニケーション場を広帯域に保つこと、そして、その場に流す情報を、できるだけ誤解が少ないもの（すなわち、見えるもの、触れるもの）にしていく必要がある。さらに、このコミュニケーションは鎖状になっていることから、TOC的には「最も弱い部分」（契約を跨ぐ部分、場所を跨ぐ部分）を厚くすることが必要で、厚くする方法は、そこにWin-Winを持ち込む、対面で話す環境を作る、などがあり、マズロー的なキラーソリューションとして、「一緒に食事をする」ということをお勧めしました。そして、もう１つの方法はこの鎖を「わっか」にして繋いでしまい、そこに要

継続可能なソフトウェア(sustainable software) というキーワードで、現在のソフトウェアを取り巻く技術や考え方を統合したいと思っています。以下に、メモ。 何がソフトウェアの品質の中心となるか。 ・保守性(EoM)＝テスト可能性(EoT)＋変更容易性(EoC) http://blogs.itmedia.co.jp/hiranabe/2005/08/post_353b.html このための技術がオブジェクト指向（部品再利用やコード再利用ではない）、という位置づけ。テストしやすい設計、リファクタリングしやすい設計にすること。そのために、言語要素として継承・カプセル化・ポリモフィズムを使う。さらに原則として、DMP(問題領域概念とのダイレクトマッピング）、SRP（問題領域の変更を閉じ込める）などを使う。また、シンプルで愚直な設計をよしとする。 また、プロセスとしてはアジャイルなも

プログラミングの問題（by C++設計者のStroustrup） http://www.techreview.com/InfoTech/17831/ をラフに訳してみる。（未完） どうして、ほとんどのプログラムは「よくない」のでしょううね？ いいソフトウェアもあります、火星探査ローバー、Google、人ゲノムプロジェクト、などなど、クオリティ・ソフトウェアです！でも、現実世界にある平均的なプログラムをみてみると、泣きたくなる。本当の問題は、ソフトウェアというものがまだまだ永遠につづく改良の繰り返しの創発段階にあること、動くソフトウェアをつくることに向けて、トライアル・エラーをしながら、ちっちゃな奇跡を起こしながら進んでいること。 ソフトウェア開発者は、「不安定な要素を組み合わせて、それなりに安定したシステムを作る」という困難なアートに熟達してきたい。ここで問題は、でも、それをどうやってやっ