knolにはWikipediaとは別次元の専門性を期待する

常日頃から「Web上に『信頼できる百科事典』があればいいな。」と思っているので、このサービスの行く末は大いに気になる。
『信頼できる百科事典』が「Wikipedia」ではないと考えている私にとっては。

Google版Wikipedia？　知識共有ツール「knol」をテスト : ITmedia News

Googleがテスト中のknolでは、誰でも特定のトピックについて解説ページを作ることができる。執筆者は広告を載せて収入を得ることもできる。

但し、実のところは、何か調べ物をする際に「Wikipedia」の内容を信用する確率は90%以上である。
それでも、「Wikipedia」が百科事典の最終形かどうかとなると、そうは言えない。

それは、表現の大半がテキストに限られているからである。
表現手段に限れば、現在のWikipediaは紙の百科事典と何ら変わりはないとも言える。せっかくのWebなのだから、豊富な画像に加えて、動画や音声などを駆使することによってさらに理解しやすい百科事典が作られるべきだという発想はごく自然なことだと思う。

ならば、将来のWikipediaが動画や音声を採り入れて発展していくかと言えば、現段階では怪しい。テキストや少量の画像までは編集できても、動画や音声を自由に編集できる人はまだまだ少ないからである。誰でもが編集に参加できると言うには、現在の動画や音声の編集環境は追いついていない。

そのような、今後Wikipediaが苦労しそうな領域に対して、knolが新たな解を提示する可能性は大きい。

このサービスは「knol（unit of knowledgeを表す）」と呼ばれ、特定のトピックをよく知っている人に、そのトピックに関して信頼できる解説を書いてもらうことが目的という。

knolは実際には、特定のトピックについての解説が書かれたWebページ。そのトピックを初めて検索する人が最初に読みたいと思うような内容になるという。Googleは、科学や医療、地理、歴史、エンターテインメント、製品情報、ハウツーまで、あらゆるトピックをカバーすることが目標だとしている。

これらから予想できることは、まず、特定のトピックに熟知した執筆者が、本人の考える通りの内容で、公開できるということである。原則として、内容に関して第三者からの反論を受け付ける必要がないため、執筆者にとっては余計なノイズを気にせずに公開できる。
また、真に熟知した執筆者の中には、既に、動画や音声も含めた豊富なコンテンツを所有している場合も多いはずであり、表現力豊かな内容で公開するには理想的であると考えられるのである。
記事の最後もこのように締められている。

Googleは、このプロジェクトの主眼は執筆者にスポットライトを当てることだと説明している。書籍ならば執筆者の名前が表紙に載り、記事ならば署名欄 があるが、「Webは執筆者の名前を強調する強力な決まりがないまま進化した」と同社は指摘、執筆者を知れば、ユーザーがWebコンテンツをより活用する 役に立つとしている。「knolに、執筆者が名声を賭けた意見や視点が載ることを期待している」

すなわち、動画や音声の表現力の向上が期待できるだけではなく、いわば「本当の」専門家がknolを執筆する状況が生まれるということである。どんな分野でも、誰でもに編集されてしまう可能性のあるWikipediaにその分野の第一人者が書き込もうと思うだろうか。knolはそこに着眼しているのである。

GoogleはWikipediaの遥か上を見据えたものとしてknolを育てていくはずである。大いに期待したい。

Yahoo!ショッピングリニューアルに見る、サイト運営の教訓

大きな会社のわりにひどいなぁ、というのが、記事を見た時の感想。

いや、小さな会社ならいいというわけではなくて。
日本で一、二を争うサイトでも、現場の実態はこんなもんなんだなぁ、と。

「かき入れ時なのに」――Yahoo！ショッピングリニューアルで不具合続出 : ITmedia News

「年末商戦のかき入れ時なのに」――11月29日にリニューアルした「Yahoo！ショッピング」の出店店舗から悲鳴が上がっている。新サイト移行に伴い「商品が検索結果に反映されない」「画像が表示できない」など不具合が続出。売り上げが大幅に落ち込んだ店舗もあるようだ。

ちょっと驚きだったのは、状況から察するに、システムが外注だということ。
(社内にシステム部隊が居るならここまでひどくはないはず。)
こんな中核のサービスまで外注なのか…。
まぁ、グループ会社に外注しているのかもしれないけれど、
いずれにせよ、実体を感じられないサービスって気持ち悪いなぁ、と。

まぁ、いろいろツッコミたいところはあるけれど、
この事例は、特にサイトリニューアルの際の、サイト運営の教訓がいろいろ含まれていると思う。

サイトリニューアルとは「見てくれを新しくする」だけではなくて、

• 既存データをどのように引っ越すのか。
• 既存クライアント(この場合は出店者)をどのように誘導するのか。

等々、表面化しないToDoが山ほどあるということ。
そして何より、

• リニューアルのリスクの共有と備え。

が大事ということ。
新しくすることのメリットばかりに気を取られて、リスクがあることを意識しない、
あるいは、リスクがあるのを分かっていながら、あえて直視しない、そのことに触れないようにする、というひどい事態さえある。
だから、システムの当事者や経営者層は当然のこと、
可能であればクライアントまで巻き込むくらいの情報共有を行ない、
関係者のいずれにも無理なしわ寄せが行かないようにすること。

「誰のためのシステムか?」
いつでもこの自問自答を繰り返さなければならないと思う。

優秀な○○○がいるとシステムが改善されない

経営とシステム改善が切り離すことのできないものだということに改めて気付かされます。

優秀なナースがいるとシステムがなかなか改善されないという話 : Life is beautiful

ナースたちにとってみれば、システムの欠陥を指摘する・他人のミスを指摘する・ミスの原因を徹底究明する・経営陣に改善を申し出る、などは彼らの仕事ではなく、そんな暇があったら一分一秒でも患者のためになることをすべき。

だから病院の経営陣は、ナースの日々の活動に常に近いところにいてどんな問題を彼らが解決しなければならないのか、どんなところに余計な時間を費やしてい るのか観察し、積極的に手を差し伸べてシステムを改善しつづけなければならない。そして、他人のミスを指摘することが個人攻撃にならないような文化を作 り、誰もがオープンに自分や他人のミスを語り合える場を作るべき。

システム開発者と経営者、それぞれの視点で参考になるこの話が、病院以外でも適用できるのは明らかだと思います。

私の経験でも、「トップダウン&意識共有」によるシステム改善はうまく進むことが多いです。強引なトップダウンでは現場のモチベーションが上がりませんが、トップが整理した改善点を全員が共有できる場を設けてあげて、全体が改善の方向へ進み始めた時に、「このプロジェクトは成功するな」と確信できることが多いです。

トップと現場は、上下関係ではなくて役割分担でなければなりません。
システム改善そのものはトップと現場の共通のミッションであり、トップはその旗振り役という役割をしっかり果たすべきだと思います。

「ウェブ２．０は、まだウィンドウズ３．１の時代にある」

「提供する側」としては、少なくともこういう視点に立って、将来を見据えなければならないと思う。

ティム・オライリー：ＷＥＢ２．０提唱者に聞く----独占インタビュー : 毎日ｊｐ(毎日新聞)

印象に残るセンテンスをメモ。(元記事が消えるとイヤなので大量にメモ。)

ウェブ２．０は「モノ」ではなく、市場の段階を表す概念だ。パソコン（の基本ソフト＝ＯＳ）にたとえるなら、ウェブ２．０は、まだ（９２年に発売された）ウィンドウズ３．１の時代にあるといえるだろう。

今後５年以内にはウェブの世界の風景は大きく変わるだろう。

ネットバブルがはじけた時は、どの会社がネットワークを「プラットフォーム」だときちんと理解していたのかを見分けやすかった。これがウェブ２．０の本当 の始まりだった。なぜアマゾンやヤフー、ｅＢａｙは生き残り、多くの会社は生き残れなかったのか。成功者はインターネットユーザーに付加価値を提供するこ とで得られる利益についてきちんと理解しており、単に「ページビューを稼いで、広告でもうけよう」とは考えなかったからだ。

多くの人は、ウェブ２．０とは様々なアプリケーションの集合体、あるいはブログやソーシャル・ネットワーキング・サービス（ＳＮＳ）、（ユーザー同士が内 容を更新し合い、質を高める形式の）「ユーザー・ジェネレーテッド・コンテンツ」などのことだと考えている。しかし、私はもっと広い意味でとらえる。ウェ ブ上で動作する様々なアプリケーションを束ねた“じん帯”として、「『集団知』をけん引すること」だと思う。

ウェブ２．０の未来は多くの場合、データベースの奥に隠れている価値の蓄積を見つけ出し、利用者が使えるサービスに変えて行くことだろうと思う。重ねて言 うが、データをいかに解錠して利用者サービスにつなげていくかを学ぶことだ。データはどんどん自動的に生成されるようになってきている。大きな未来がこの 先にあると思う。

日本のウェブサイトは欧米のものに比べ、やや創造性に欠けるように思う。日本には保守的な技術文化があるし、多くの場合、革新の原動力となる若い技術者に 与えられる機会が少ない。彼らは「なぜ、そうでなければならないのか」と疑問を持ち、全く異なる新しいアイデアを生み出す。しかし、企業家文化が欠けてい るために、多くのサイトは既存の方法から脱却できていない。

(日本の携帯サイトについて：)
オープン・プラットフォームを許可していないし、「集団知」を生かせるアプリケーションを構築する機会もない。それが可能になるまでは、モバイルの可能性 は制約を受けるだろう。ただ、モバイル革命は、ウェブブラウザー革命より、さらに大きな潜在力を秘めているといえる。驚くべき革命につながるだろうが、今 はまだだ。

パソコンが世に出た時にハードウエア業界で起きたことと同様、ソフトウエア業界で何が起きていたのか、よく考えた。パソコンは新しいビジネスモデルだっ た。誰かがパソコンの仕様書を作れば、誰でも同じものをつくることが出来た。(中略)その結果どうなったかといえば、ハードウエアの価値は失われ、 価値はソフトウエアに移っていった。
オープンソース・ソフトウエアがウェブに登場した時、似たようなことが起きているのではないかと感じた。オープンソース・ソフトウエアは卓越したソフトウ エア理論だった。オープンソース・ソフトウエアは、ソフトウエア自体を売ることで収益を上げるのは困難になるが、ソフトの価値が失われるわけではない。価 値はどこか別の場所へ移る。では一体、どこに行くのか。

ウィキペディアは、誰かが書き込み、別の誰かが改良することで、より正確なものになっていく。新しい出版刊行の形だ。旧来の出版者は、それを理解しなければならない。グーグルもウィキペディアもエンサイクロペディア・ブリタニカも出版者だといえる。

(新聞やプリントメディアの将来について：)
生き残ることは出来るだろう。ただ、問題は成功するかどうかだ。楽譜が音楽をシェアする手段だった時代には、人々は楽譜を買ってピアノを弾いた。ところが、音楽が録音出来るようになると、人々は楽器を弾くのをやめた。そして、楽譜の市場は縮小していった。

(ウェブ社会のマイナス面、例えば、幼い子供がオンラインゲームにのめり込むなど、現実世界と仮想世界を区別することがますます困難になるのではという指摘に対して：)
そうかも知れない。懸念はいつでもあるものだが、インターネットについての懸念は、いつも大げさに語られる。では、テレビの影響はどうだったのか。 あるいは、読書の影響は。ルネッサンスの時代に、「乗馬や鷹狩りをするべきなのに、うちの子供は引きこもって本ばかり読んでいる」と嘆いた家族の姿が私に は容易に想像出来る。
世界は変わる。もちろん、悪者はいる。常に問題もある。子供のころ、母親に「ボウリング場には麻薬の売人がいるから近づいてはいけない」と言われたことがあった。しかし、ボウリング場と麻薬の売人の固有の連携があるわけではない。

(ウェブの将来について：)
私は極めて楽観的だ。

「ＷＥＢ３．０」についての具体的言及はなかったが、こればかりはまだ誰にもわからない、ということだろう。
でも、ＷＥＢの世界が大きく変化していくのはまず間違いない。

ＷＥＢ２．０の現在、我々が目指す新しいアプリケーションは、『集団知をけん引すること』を念頭に置かなければならないということ。これこそが最大のヒントだろう。
すなわち、ブログやＳＮＳをこねくり回すようなレベルではない、より革新的なアプリケーションが、ＷＥＢ２．０の世界でもまだまだ産まれ出てくるということだ。

プログラミングスタイルの参考になるエントリ

プログラミングには集中力が必要である。しかしそのことをクライアントに理解してもらうことは必ずしも簡単な作業ではない。

先日あるクライアントとの打合せの中で、プログラミングがいかに集中力を要する大変な活動なのかということを説明するために、
「1つの機能を実現するのに『固まりで2時間』くらい必要なんですよ～。」
と言ってみた。
すると、予想以上にクライアントの反応が良く、
「それは…本当に大変ですね～。」
という素晴らしい意識共有ができた。

また一つクライアントへのトークの術が増えたなぁと反芻しているところに、今日たまたま2つのblogエントリを見つけたので、ここにしっかりと記録しておく。

まず1つ目。
LiveCodingに学ぶプログラミングの三原則 : 404 Blog Not Found

1. コピペを恐れるな
2. いつも手元にリファレンス
3. 一つ書いては一つ動かせ

「少しずつ」「参考書を見ながら」「真似していいところは真似をして」というのは、プログラミング以外でも使える原則

突き詰めるとやはりこういうスタイルになるのか、と共感。

2つ目。
私のとっておきのプログラミングスタイル : Life is beautiful

1. スタートダッシュでできるだけはやくめどをつける
2. 仕事を「タスク」に細分化する
3. 一日の始めに、「今日やるマイクロタスク」のリストを作る
4. それぞれのマイクロタスクは「割り込み禁止状態」でこなす
5. マイクロタスク単位に丁寧にテストした上でチェックインする
6. うまく動かないマイクロタスクは、一度最後にチェックインしたところまで戻って書き直す

マイクロタスクの定義として、

大きさとしては、うまく行けば１５分ぐらいで、なかなかうまく行かなくても二時間ぐらいで完成できると思えるぐらいが適切。

と書かれている部分にいたく共感。

両blogのブロガーは現役のエンジニアであるとともにそれぞれ多忙な活動をされておられる。自らの仕事のスタイルを形作るために大いに参考にしたい。

nextの反対はprevかbackか?

英語に長けている人なら何も悩むようなことではないのだろうが…。

先日、制作したあるWebサイトの所有者から、
「検索結果ページの一番下の『prev/next』の『prev』は、文法的には『back』ではないか?」
というクレームが。
単なる修正依頼であれば特に考えずに「back」に変えていたかもしれないが、「文法的に間違い」みたいに言われたものだから、プログラミングを始めてかれこれ15年の人間に対してそれは言い過ぎじゃないかと少々カチンと来つつも、他方では「文法的には本当はどうなんだろう?」と思いながら、調べてみた。
その結果、次のように理解した。

「prev(previous)＝前へ」と「next＝次へ」のペアは、これで正解。
そして、「back＝戻る」の反対語は「go＝進む」である。
別階層間の縦移動に「back」と「go」を使い、
同階層内の横移動に「prev」と「next」を使う、と覚えておく。

調べてみると、日本国内のサイトでは、「prev/next」と「back/next」の両方が見受けられるようだ。
別にどっちでも意味は通じるからいいんだろうけど、私はこれまで通り「prev/next」を使うつもりなので、明日はクライアントとちょっとした議論をしなければならないかもしれない。

「右脳的なもの」と「左脳的なもの」

Webシステム開発におけるインタフェース制作は、Web上でのユーザの利便性を如何に高めるかという技術的作業であるが、別の見方をすると、如何にユーザの右脳に働きかけるかを、左脳をフル回転させて実現する作業とも言える…。
そんな想いを抱かせるコラムを読んだ。

メタデータによる“右脳の補完”で進む「ネットとリアルの融合」 - CNET Japan

Webの進化の過程を「右脳的なもの」と「左脳的なもの」で説明されている点が興味深い。
すなわち、人の左脳(記憶や計算など)を補完するために登場したコンピュータ上で進化した現在のWebは大いに「左脳的なもの」であるが、Webがコミュニケーションの手段になったことで、Webに「右脳的なもの」が必要とされるようになってきた、というわけ。

仕事でWebを使わされる方は世の中に数多とおられるはずだが、現在のWebインタフェースの表現能力を考えると、実際のところ、
「使いにくい」「疲れる」「見るだけでもイヤ」
という人が相当数おられるのではないだろうか。
開発の当事者でさえそう思うくらいなのだから。(苦笑)

「右脳を刺激するシステム開発」を、目指していきたい。

ネットコミュニティの正しくない作り方

最近、Webサイトの多機能化を目指す方から、SNSや口コミなどのいわゆる「コミュニティサイト」のシステム構築を望む声を非常に多く聞くわけだが、
私はその際、「システムより運営に多くのコストがかかりますよ」ということを説明(あるいは説得)して、少なくともそれを理解する気さえないクライアントのお仕事はお断りするようにしている。(あるいは途中で抜けている。)

その説明/説得に幾つかの根拠を示してくれる記事をGIGAZINEさんが上げてくれた。
ひとまず、コミュニティサイトを運営している方やこれから運営したいと考えている方々に御一読願いたい。

ネットコミュニティが崩壊するとき : GIGAZINE

大企業での失敗例も多く記されているこの記事からもわかる通り、これは単なる費用の大小の問題ではない。コミュニティをどのようなポリシー・文化で発展させていくのかを明確にすることや、それをコミュニティの参加者と「共に創り上げる」姿勢を長期にわたり継続させていく覚悟がまず必要であるということだと思う。

ちなみに、コミュニティサイトの構築を我々のような小さなシステム開発会社に依頼される場合、過去の経験上、案件遂行の観点からさらに幾つかの問題が現れるのだが、それはまた別の機会に書こうと思う。
#他の場所で何回も書いてるけれど…。

Googleのソフトウェア・エンジニアリング

へ～たさんのへ～たのめもより。へ～たさんに感謝。

開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同じ人)が全部やる

この辺りが既存のエンジニアリングとの最大の違いかな。

デザインに関するメモ

本日あるクライアントでの打合せで、デザインに関して興味深い議論ができたので、忘れないように自分用のメモ。順不同。

• まずはひたすら型を真似る。
• だからデザインは自我との格闘である。
• 「風姿花伝」世阿弥
• デザインの対象は、モノではなく行動。
• デザイン＝制作物＋見た人のイマジネーション。
• MacのWebサイトデザイン。
• A4の紙1枚と黒マジック1本でいかに伝えるか。
  
• 音階と同様、色にも段階がある。最強、最弱、その中間に1つあるいは幾つか。
• 無駄を省く。あるいは、必要なものだけ置く。
• 行間、空間の計算。

これくらいやったかな。

私はデザイナーではないけれど、今日の話はとても重要なことばかり。
「風姿花伝」はちょっと調べてみないとわからんな。
ちなみに、「黒マジック1本」だけは私からの話。残りは先人の皆さんからの話。

Google Analyticsの導入 on Blogger

これは簡単。
テンプレートにAnalyticsのコードを埋め込むだけで完了。

本日はここまで。

タイトルとURLの相関

どうやら、タイトルからURLが自動的に生成されるようで、

• 半角の英単語等が含まれていたらその部分だけがURLになり、
• 日本語オンリーの場合は一律に「blog-post」という名称になる。

みたい。

本当は自由にURLも変更できればいいんだけどなぁ。
やっぱりこれは、英語圏からやって来たブログゆえのことなんだろうな。

トラックバックの導入 on Blogger

エントリを1つ書いてみて、
「そう言えば、トラックバックって単語がどこにも見当たらんなぁ」
と思って調べてみたところ、Bloggerにはトラックバックの仕組みが付いていないらしい。
でもせっかくはじめてのブログなのでそれっぽい仕組みも使ってみたい。

すると、クリボウさんの「クリボウのBlogger入門」にドンピシャの方法が書いてあったので、参考にさせていただくことにした。

「Haloscan」というツールを導入すればよい、とのこと。
ほとんど上述のページに書いてある通りだったが、Haloscanも進化していて、
以下の手続きにより、ソースを触ることなく導入に成功。

1. Bloggerの現在のテンプレートをダウンロードしてファイルに保存して、
2. そのファイルをHaloscanにアップロードする。
3. するとダウンロードボタンが現れるので、
4. それをクリックすると新しいテンプレートがファイルに保存される。
5. その新しいテンプレートをBloggerにアップロードして、
6. 設定を保存したら完了。

ところがもう一つ問題があって、これだけだとトラックバックを打ち出せないとのこと。
どうやらHaloscanにて手動で打ち出すらしい。
これについてはHit Okanoさんの「How to send a trackback ping from haloscan.」のページが参考になりそう。

お2人のおかげでトラックバック対応が完了。
このエントリ書き終わったら試してみよう。
…って、2人ともトラックバックURLがわかんないや。
(Hitさんのところにはバックリンクがあるから、それでいいのかな?)

はじめてのブログ in Blogger

いろいろ実験的なことも含めて、ブログを始めようと決心。

これまではmixiなどで「日記」を書いてきたが、ブログと呼ばれるものを使うのは初めて。
そこで、まずはブログ選びから。
まぁ…どこでも良かったんだけど、何となくGoogleの「恩恵」が受けられるかな、と思って、今回はBloggerに決定。
#実はvoxも作ってある。そっちは別の用途で使うつもり。※エントリは準備中。

テンプレートやレイアウトをいじりながらこのエントリを並行作成。
エントリ本文の作成にはリッチテキストインタフェースが用意してあるので、適宜試してみよう。
日本語フォントの選択肢がないんだけど、そういうもんなんかな。

エントリを保存。
ページのURL(ファイル名)は自由に設定できないみたいで、勝手にネーミングされる様子。このエントリの場合は「in-blogger.html」で、タイトルから自動的に取ってきているみたい。
タイトルがオール日本語だとどうなる?ちょっと不満。

ブログパーツは今のところ極力使わない方針だけど、
まずは試しにGoogleものを置いてみた。手軽だったので。
記念すべきvideos第1号は「車屋のキクチ」。必見。

とりあえずここまで。