タグ

ブックマーク / blog.japan.cnet.com (9)

  • 勝手にフィードバック:Feelimage編:江島健太郎 / Kenn's Clairvoyance - CNET Japan

    ちょっと思いつき企画で。 どんどん新しいサービスが登場する昨今ですが、個人的にもいろんなサービスをさわってみています。で、そのときにいろんな感想を持つわけですが、同業のサービス開発者としてどのように感じているかをブログにアップしたらどうなるだろうか、という実験をやってみようかと思います。 で、ポイントは ひとりの初訪問ユーザの視点で 5分だけ使ってみて あくまでユーザビリティ(使い勝手)に特化して サイト開発者に黙って勝手に評価 サービスの詳細紹介はしない&将来像にも踏み込まない でもサイト開発者に対するフィードバックのつもりで というあたりです。 来ならサイト開発者に直接フィードバックを送ればよいのですが、どうせだったら「デザインやユーザビリティに対する考え方」みたいな部分はより多くの人とシェアした方が意義があると思ったのがきっかけです。そんなわけで、開発者視点のかなり込み入った話が中

  • 上場にあたっての社内に向けてのメッセージ:江島健太郎 / Kenn's Clairvoyance - CNET Japan

    そうそう、ご報告がすっかり遅くなってしまいましたが、親会社のほうのインフォテリアがこの6月にマザーズに上場しました。 それで、多くの人にとって、企業が上場する瞬間に中でどのようなことが起きてるかを知る機会なんてほとんどないでしょうから、5月末の上場が決まったときにぼくから社員と経営陣に宛てて書いたレターをこちらで公開することにしました。 内容を一部伏せるかどうかでちょっと逡巡したのですが、どうせなら生々しいほうが世の中のためになるだろう、と思ったので、結局原文ママで載せることにしました。 なお、ディスクロージャのために述べておきますが、私は現在インフォテリアUSAに勤務していますが、100%親会社であるインフォテリアの株主であると同時にまだ社員としても籍は残しており、給与の一部とストックオプションをそちらで報酬として受け取っています。そういう立場の人間の発言とご理解ください。 こういうもの

  • もっと失敗しよう:江島健太郎 / Kenn's Clairvoyance - CNET Japan

    このへんを読んでいて思ったこと。 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む - 大迫正治 REPEDANT BLOG [ITmedia オルタナティブ・ブログ] HOW DO YOU LIKE SILICON VALLEY? | やはり受託からイノベーションは生まれない いやはや、まったくおっしゃるとおり。 ともかく、みんな「リスク」とか「不確実性」とか、そういう浄化されたビジネス用語をつかって説明しようとするからリアリティーがないんだ。 いまの日ITイノベーションに足りないのは、転んで生傷をつくりまくる失敗経験だよ。 「10のチャレンジのうち9の失敗をよしとする」ということは、それ自体、相当の覚悟と思考体系の適応力が求められる難しいテーマ。ハンパに受託をやりながら、そういうマインドを維持できると思ってる人がいるとは、いかにもおめでたい。 だいたい、国際交流試合や全

  • 人工無能ボット・ロイディと話そう!:江島健太郎 / Kenn's Clairvoyance - CNET Japan

    技術者以外の方にはあまり知られてないことだと思いますが、LingrではAPIを公開しており、チャットルームに色々なボットを住まわせることができます。 ボットというのは、参加者のひとりとしてチャットに加わり、人間の発言に応じて色々な仕事をしてくれたり、話し相手になってくれたりするプログラムのことです。が、こういう風に説明されても今ひとつ実感がわかない人も多いことと思います。じゃぁ、とにかく体験してみようよ!というのが今回の企画趣旨です。 そこで、人間の会話を学習してどんどん賢くなる人工無能(おしゃべり)ボット・ロイディと作者のGimiteさんをスペシャルフィーチャーして「ボットとチャットで遊ぼうイベント」をやりたいと思います。この機会にぜひロイディの毒舌をご堪能ください。チャットって何?人工無能って何?ていうかLingrって何?という感じの初心者大歓迎。匿名でも参加できますので、この機会にL

  • CNET Japan Blog - 中島聡・ネット時代のデジタルライフスタイル:時代にマッチした「サイト利用規約」を作ってみた

    ここのところ、「無断リンク禁止は悪なのか?」、「野村総研がリンクする際には文書で申し出よというので文書で申し出た」などの時代遅れの「サイト利用規約」に関する話題で盛り上がっている。 「前例にならって無難な道を選ぶ」サイト運営者が多い結果だとは思うが、彼らをいくら非難したところで、「悪例(=ウェブの黎明期に作られてそのまま継承されている利用規約)」がこれだけ氾濫している段階では、すぐには解決しないような気がする。 そこで、参考にしていただければと、私なりに「今の時代にマッチした『サイト利用契約』」の雛形を作ってみた(ちなみに、「いっそのことクリエイティブ・コモンズにのっとった規約を」、という意見もあるとは思うが、まずは無難に現状の著作権法にのっとって書いてみた)。 1.当ウェブサイトに記載されている内容(コンテンツ)の著作権は、特に明示していない限り○○○に帰属します。著作権法で定められた「

  • CNET Japan Blog - 中島聡・ネット時代のデジタルライフスタイル:YouTubeを使ったテレビ番組の『引用』の合法性に関する一考察

    私はWinnyなどのP2P型のファイル共有サービスを使って音楽映画をコピーすることは犯罪であり徹底的に取り締まるべきだと考えているが、YouTubeにテレビ番組の一部をアップロードする行動に関しては、「ある程度までは許容範囲として認めるべきではないか、必要であれば著作権法の方を変更すべき」と感じている(参照:見たい番組の存在は『放送後』に知ることが多い、だからYouTube)。 この違いを誤解を招かないようにどうやって説明しようかと悩んでいたのだが、ちょうど良い記事をITMediaに発見した。 ブログの主目的は『個人的体験の共有』 人々がファイル共有サービスを使う目的は、明らかに「来ならばお金を払って入手しなければならない音楽や映像を無料で手に入れること」であり、これは明らかに著作権法違反である。これに対して、人がYouTubeにテレビ番組の一部をアップロードする目的は、主に「こんな面

  • CNET Japan Blog - 近藤淳也の新ネットコミュニティ論:50%の完成度でサービスを出す

    はてなでサービスを出す時に心がけていることとして、「50%くらいの完成度でサービスを出す」という事があります。 普通に考えれば、サービスは「これで完成」と思う部分まで作り上げて出すべきものである気がしますが、ウェブサービスの場合、実際は半分くらいの完成度で出した方がうまく行く確率が高いと思います。 新しいサービス(例えばブログとWikiがくっついたようなダイアリー)の構想を考えたとして、そのサービスの機能は3種類ぐらいに分けて考えられます。 最低限必要な機能…ログインや日記を書く機能など。どんなシステムでも持ち合わせている機能 そのサービスを特徴付ける基機能…キーワードの自動リンクシステムや、それを実現するためのキーワード作成機能など。どのサービスにもあるわけではないが、サービスのコンセプトを表すために必須の機能 発展的機能…1.や2.を前提として考えた場合に必要となるであろう機能。コメ

  • 開発者が楽しく仕事できる環境とは:近藤淳也の新ネットコミュニティ論 - CNET Japan

    立って会議をするだけでなく、はてな社内では他にも色々なことを試みています。その中でも、開発者が楽しく仕事ができるように、という観点でいくつか紹介してみたいと思います。 まずはペアプログラミング。これは、2人1組になってプログラムの開発を行うスタイルで、XP(エクストリームプログラミング)のプラクティスの一つとしても提唱されているものです。 2人でプログラムを開発するというのは、1人がプログラムを書き、もう一人が横からそれを見ている、という方法です。この方法を聞くと、1人がそれぞれの作業を行うよりも作業量が2分の1になってしまいそうな気がするものですが、実際はそれぞれが別々の作業をするよりも効率が上がる、という興味深い逆説的な現象が発生します。 ペアプログラミングの様子。こういうときはなぜかコーラが似合います。 なぜ2人1組でプログラミングをする方が1人ずつでやるよりも効率が上がるのでしょう

    bunhiko
    bunhiko 2005/08/05
    偉くない管理職
  • CNET Japan Blog - 近藤淳也の新ネットコミュニティ論:情報の私物化を禁止する

    前回は各個人のコミュニケーション能力について触れましたが、社内での情報共有を活発に行うにあたって他にどういう問題が発生するかを、自分自身の起業からの出来事を振り返りながら考えてみたいと思います。 まず、はてなでかなり初期に表面化してきたのがプログラムのコードの共有についてです。特に、受託開発案件の開発を主に行っていて、各担当者が別々の案件を担当していた頃には、それなりに意識的に努力をしないとプログラムコードの共有は実現できませんでした。何もしなければ、各プロジェクトの担当者が自分のクライアントと直接やり取りして、自分のパソコンにコードが全て入っている、という状態になってしまいます。同じプロジェクト内でも、各開発者の担当箇所を別々に作り、お互いのコードがどうなっているかは知らない、という状態になってしまいがちです。 しかし、よくよくコードを見比べてみると同じような仕組みを別々のプロジェクト

    bunhiko
    bunhiko 2005/07/27
    必要か必要でないかは閲覧者の判断
  • 1