編集 |
編集(管理者用) |
差分
なんとなく普通の新年月。
ヒューザー、ライブドア、東横イン、防衛施設庁。大きなニュースに事欠かない日々ってのも嫌だなぁ...。
本話で、昨日飲み中にも出たのだけど、nijimuさんからこんなご意見が。
本を買ったらその本のデータも付けて欲しいよな。 本で読みたくはあるのだけれど、いかんせん本は検索性がひどく悪い。 あの言葉、どこで出てきたっけ？というのをデータで検索してページ数を特定させたい、という欲求に駆られたことのある人は沢山いると思うんだけど。
貸し本業はありえるか？ - Mint Julep(2006-01-31)
それに関しては前々から思っていて、以前にRFID話とからめて「my Web本棚を始めよう。」という話を書いたことがある。この話の要点は、
...ということ。もちろん、購入者証明ができれば、RFIDじゃなくても良い。今だと、リーダとして使える携帯電話が普及してるから、QRコードが良いかも知れない。実現させるとしたら、こんな感じかな。
購入者には、こうしたデータが手に入る特典もある、となると、貸本との差別化と共存にもさらに具合が良さそうだ。...ってのは実はどうでも良くて、僕も持ってる本のデータが欲しいです。技術書なんかは、出張先で見たくなることがあって、でも出張に携行できるサイズや量じゃないんだよね。
Web本棚というかデジタル本棚というかもそうだし、貸し本業もそうだし、書店と中継ぎと出版社が歩調を合わせないとできないのだけど、でもやってくれないかな。
そう言えば貸本屋と同じく、貸しレコード屋なんてのも古くからあったはずだけど、こっちは今のレンタルCD・DVDショップを見るとまるで世界が一新。
そう思えば、こんな形かわからないけど、デジタル化じゃなくて何かリアルの世界で、貸本屋もまるで一新な可能性はあってもおかしくないと思う。いや、本当に。
唐突ですが、僕は紙媒体、活字媒体が好きです。ブログを読む暇があったら活字を読む、というと言いすぎだけど、正直に言って画面でテキストを追いかけるのはあまり好きじゃない。
活字＋紙のテキストには、持ち歩きやすいし、すぐに開けるし、上から順番にではなくて適当にあっちこっちに視点を移せる良さがある。話がなんか難しくなってきたな、と思っても、ここにつながる話が前のほうに書いてあったな、とちょっと目をやると理解できたり、ここにあの伏線がつながるのかと前に戻って楽しんだり。多分僕の読書スタイルは、紙の特性に縛られてる。
そんな訳で、出版業が元気であり続けてくれないと困るんだけど、今日も飲んでる最中に出版不況がどうとかって話が出たりして。「返本までに次のを出しての自転車操業」「回転が上がりすぎて出版タイトル氾濫」なんて話は少なくとも5年前には嫌というほど聞いていた気がするのだけど、どうやら突き進んだだけで変わっていないとか。他にビジネス・モデルってないのかな、と思ったときに、貸し本業というのが出てきた。
酔っ払いのたわごとだけど、出てきた話をまとめておきます。
■ なぜ「本」と「本屋」にこだわるのか。
多分、ここが話の中で一番古臭いところだと思う。そして、それが好きだから、ということにとどまってしまう。でも、そこが話の原点。
まず挙げられるのは、紙媒体の良さ。持ち歩きやすいし、すぐに開けるし、上から順番にではなくて適当にあっちこっちに視点を移せる良さがある。話がなんか難しくなってきたな、と思っても、ここにつながる話が前のほうに書いてあったな、とちょっと目をやると理解できたり、ここにあの伏線がつながるのかと前に戻って楽しんだり。多分僕の読書スタイルは、紙の特性に縛られてる。個人差の大きい話だけど、僕にとっては、ニュースはまだしもテキストはやっぱり紙媒体じゃないと読み込めない。
じゃあamazonなどのネット書店で買えれば良いかというと、そうでもない。いや、それはそれでとても良いのだけど、それだけで満足できない。大量に出版される本を、等価に見せられたって選べないからだ。例えば紀伊国屋のWebで2006年1月に出た文庫を検索すると634件ヒットする。作者買いとかテーマ買いする時ならともかく、こんな数の中からどうやって「この本読んでみよう」なんて思える一冊に出会えばいいんだろう？
僕の場合、初めての作家、初めてのカテゴリの本を読む機会というのは、本屋さんに並んでいる本にふらふらと惹かれてということが多い。表題と表紙、厚さと大きさ、表題がどんな活字で書かれているか、ジャケ買いならぬ装丁買いだ。もちろんamazonなんかも表紙写真を載せたりはしてるけど、こんな風にひとしなみに同じ小さな写真で見せられたって全然雰囲気は伝わってこない。情報量が少なすぎて、ウィンドウ・ショッピング的な楽しさは半減どころじゃない。
やっぱり、本が、本屋さんに並んでいるという光景がとても好き。だから、本屋さんとか出版社とかがうまくやっていけて欲しいな、と思う。それで何か新しい形態ってないのかなとか、そこが話の原点。
■ 本を借りるニーズはあるのか？
装丁買いの話をしたら、「装丁に惹かれるとかなら、買って持っておきたいんじゃない？内容を読みたいだけなら、電子書籍で良いんじゃない？本で、しかも借りるだけってどうなの？」と突っ込まれた。
例えばレンタルCD屋さんって新譜までレンタルに入れてる。今時は普通に、これを借りてきてデータ化して、iPodとか携帯とかパソコンで聞く。それがWebに馴染んだ人になると、レンタルの代わりにオンライン・ミュージック・ストアで、最初からデータで手に入れる。それでコンテンツとしては十分そうなのに、CDも売れる。それは、ジャケ買いだったり、アーティスト買い（応援とかコンプリートとか）だったり、あるいはデータが壊れたとき対策に音源確保だったり、要するに気に入ったからモノとして持っておきたい。コンテンツ・ビジネスでのモノの需要って、最後は買いたい心理なんじゃないの、という話。
でも現状で、音楽や動画と、テキストは同じようには語れない。音楽はCDでもデータでも、音はスピーカーやイヤホンから出てくるのに代わりはない。でも、テキストの場合、データで手に入れたらディスプレイで読むことになるけど、紙媒体で手に入れたら紙面で読むことになる。コンテンツは一緒でも、受け取る側のスタイルが違うんだ。紙で読みたいという人はやっぱりいるし、それは所有することと別の話だ。新聞なんかが良い例で、朝日新聞を買う人がみんな、asahi.comにアクセスできないとか、朝日新聞をコレクションしてるって訳じゃないよね？
ところで逆にレンタルCDには、「聞きたいだけなら、いずれオンライン・ミュージック・ストアに駆逐されるのでは」という考え方もあると思う。いずれ、そうかもね。でも、まだデータ購入（と販売）が身近じゃない、レンタルCDほど安くない、という差がニーズになってるんだ。だったらテキストの、「読みたいだけなら、電子書籍に敵わないんじゃないの？」に対する答えはもっと強固だ。ディスプレイや小型デバイスで読むのか、紙面で読むのかっていう差はもっと大きい。
やっぱり、一読するだけでも紙が良い、一読するだけだから借りられれば良い、というニーズってあると思う。
■ 貸本にメリットはあるのか？
じゃあ翻って貸す方の話。借りる人がいるとしても、それで貸本ってペイするのか、という突っ込みですが、難しいです。難しい上に、仮定に仮定を重ねる砂上の屋上屋って感じだけど、「貸本屋」じゃなく「貸本業界」という形で何とか考えたことが。
まず、本屋さんが貸本をするとする。例えば一冊1,500円の本を、150円で貸出し、つまり定価の一割を貸出料とする。これぐらいなら、買う気になった本以外はまずは借りて読もうかって気になりますよね？でも、これだと10回貸し出さないとペイしない計算になっちゃう。太洋社のサイトにある実践書店開業講座（ちょっと古いけど）によれば、卸値は「雑誌77％、コミック75.8％、書籍78％」だけど、これでも8回。同じ本が何回借り出されるかとか、本の傷みによる寿命を考えると、8回というハードルをもう少し下げたいところ。
ハードルを決めてるのは、貸出料と卸値。じゃあとりあえず、卸値を定価の半額。だから、書籍で少なくとも今より35%引き（78%×0.65＝50%強）で。ちょっと無茶な気はするけど、ただし、この価格で仕入れた本は貸出しに使うことが前提。当然その分だけ傷むわけで、返本が利かないのが前提。この返本について、日本著者販促センターのサイトが出版年間の統計を引いて説明している。
返本になった場合は、出版社がお金を出して破棄します。 しかも、返本されてきた送料までも出版社負担だそうです。すごいリスクですよね。 また、ここ数年の返本率を見ると
・2000年 39.4％
・2001年 39.1％
・2002年 37.7％
・2003年 38.8％
・2004年 36.7％
となっている。
返本について
元々の卸値って、当然、返本リスクを折込済みだよね。ここ5年で改善された2004年を前提にしても、36.7%は返金。プラス送料と破棄費用。じゃあ、書店が「何冊は返本しない」って前提で発注したら、その分は定価の50%以下で卸すことって、不可能かな？その分は本屋が貸さずに売っちゃってもいいのかって問題は出てくる。売れれば本屋丸儲けだけど、良いと言うしかない。返本率を低く見積もれる本なら、出版社丸損ってことになるって問題は出てくる。それも、良いというしかない。
でも、出版社側も、委託販売を一部でもやめられ、そのリスクを軽くして、委託販売から生まれた自転車操業体質もちょっとぐらいは抜けるかもしれない。それに、新人作家の第一作みたいなものを小部数で発行する場合などは、返本されない部数がある程度カウントできるとリスクが減るかも知れない。貸本をアンテナにして、売り本にまとめなおすみたいな新しいフローも作れるかもしれない。大きな儲けになるとは思わないけど、リスク・テイクとか、体質改善とか、チャンネル拡大にはなるかも知れない。
■ どこまで本気で言っている？
どこまでと言われても、まったく本気はないかも知れない。
だいたい最後に数値を上げて現実感出そうとしてるくせに、実態はとても雑い計算をしているよね。それに平均5回も借りてもらえるのか（怪しい）とか、書店側のコストは（これは低いと思う）とか、なんのマーケット・リサーチもしてない。そのくせ、「貸し本屋さん」どころか「業界改革、貸本業界創造」みたいな大掛かりな話になってる。本気かと聞かれても困るし、そもそも出版とか書籍流通と何の縁もないし。
でも、どういう形であれ、どういうビジネスを取り入れていくのであれ、本を流通させるバック・ヤードに元気であり続けて欲しいな、と思っているというのは、本気です。それでなんでこんな話を考えたかというと、出版業界なんて瀕死とか発言が出て、そんなに行き詰ってるのかな、可能性って出尽くしてるのかな、というのが発端で。だから「何かまだ可能性あるんじゃないの」と思えたので、本読み側としてはとりあえず満足。
本当に、本とは長く付き合っていけますように。
「なぜ『業務にPerlは使えない』のか？」だけどなんかある？での「Perlのメンテナンス性が問題では？」の項で午後が終わっちゃいました。非生産的だなぁ...。
Internet Watchに「Opera Mini、『W-ZERO3』『Vodafone 702NKII』など日本の端末でも動作」という記事が。 もうちょっと、導入方法なんかの詳細を...。
Opera miniがWX310SAで動いたという話が。動くんですか。うーん、W-ZERO3はどうなんだろう。どうやって導入すればいいんだろ。
シン・クライアント・ソフトの救世主はAtomではなくBinaryに書いたOpera miniでの転送データ形式「OBML (Opera Binary Markup Language)」というのが良く分からない。分からないなりにWebで漁ってみると、ベータテスト開始時期のいくつかの記述が。まず、「Hacking the Opera Mini - Online Diary」より。
You see, Opera hasn't really made a browser at all, they've made a small image viewer client that talks to a central proxy server that does all the handing for you. The server only sends a small stub of information back to the client describing it's complete pixel layout. This stub is what Opera call OBML - Opera Binary Markup Language, and is part of Operas patented small screen rendering.
Hacking the Opera Mini - Online Diary
どうやら、Opera miniはぶっちゃけプロキシと通信できるイメージ・ビューアであるとのこと。このプロキシ・サーバは、完全なピクセル・レイアウトを記した小さな情報スタブを送ってくるとのこと。このスタブが、OperaがOBMLと呼ぶもので、Operaのパテントであるスモール・スクリーン・レンダリングの一部であるとのこと。
次に、Operaによるプレスリリース「Have WAP but want WEB? Introducing Opera Mini for mobile phones」より。
Opera Mini, a J2ME (Java 2 Mobile Edition) Web browser for virtually all mobile phones. Opera Mini enables Web access on more than 700 million low- and mid-tier Java-capable phones around the world, finally bringing mobile Internet into the mainstream.
Have WAP but want WEB? Introducing Opera Mini for mobile phones
Opera miniはJ2MEアプリケーションであるらしい。700,000,000のJava-capable、つまりJava対応携帯電話で動くとのこと。J2MEサポートというより、そもそも自身が動くのに必要な環境がJ2ME。実際に上で引いた「Hacking the Opera Mini - Online Diary」では次のように書いている。
I was able to pull out the jar file and got it running under the j2me emulator on my laptop.
Hacking the Opera Mini - Online Diary
ラップトップのJ2MEエミュレート環境で走らせることができた、ということだ。
そうすると、あんな携帯とかこんなPDAでもほぼ無改造で利用できそうな気がする。重い処理を外出しにしてほぼ画面描画だけということだと、J2MEの分の負荷を考えても軽いかもという期待も持てる。で、僕らが利用できるのはいつなんでしょうね。
LinuxDevicesによれば、スモール・スクリーン・レンダリング等の技術やJ2ME MIDP 1.0/2.0をサポートしながら、実行ファイルのフットプリントは50〜100kbの組込みデバイス向けブラウザ、Opera Mini Browserがリリースされたとのこと。ポイントは...
The Opera Mini browser works through proxy servers that are currently hosted by Opera. The proxies translate Web pages into OBML (Opera Binary Markup Language) before sending them to the phone. OBML includes compressed images, and eliminates the need for the Opera Mini client to do error handling -- since HTML is not a parsed variant of SGML, much of a normal browser's workload involves handling non-well-formed HTML. The scheme compresses Web pages by up to 80 percent, according to Opera, resulting in both faster browsing and "dramatically reduced" data transfer charges.
Free Mini browser lures 700 million mobile phones - LinuxDevices.com
...Opera社の提供する専用のプロキシサーバを介すること。このプロキシサーバが、画像を圧縮し、HTMLデータをブラウザ側で解析しやすいきちんと整ったものにし、まとめてOBML (Opera Binary Markup Language)形式に変換してブラウザにデータを送り出す。これによりOpera社によればWebページは最大80％も圧縮され、データ量と転送負荷は「ドラマティカルに軽減される」という。
The proxy servers run a large number of copies of Opera's Web browser technology, which process the Web pages on behalf of the mobile phones. The scheme makes use of Opera's small screen rendering technology to improve Web-page usability on low-end displays, the company says.
Free Mini browser lures 700 million mobile phones - LinuxDevices.com
また、このプロキシサーバは、数々のOpera社のWebブラウザ・テクノロジを適用し、スモール・スクリーン・レンダリングを実現する、という。よくある携帯向けプロキシの説明と良く似ているんだけど、プロキシとセットでブラウザを設計していること、そしてOBMLというバイナリ形式(？)でのデータ転送が新しいところと言えそうだ。
そう言えば数年前には、XHTMLやAtom、Atom PPといった整形式のデータとシンプルなコール・アンド・レスポンスがシン・クライアントの福音になる、と言われていたような記憶がある。それが昨年には、例えば11月のXML開発者の日で垣間見てきたAtom（というかREST）の世界ではCode on demandなどのスタイルが生まれていたりして、それに対応しようとするとクライアント側はリッチにファットになることを求められるばかり。
でも、iPodや携帯電話などの小型デバイスがポストPC時代を築きつつあって、これらがファット・クライアントになるまでには時間が要る。きっと時間が（ニーズがファットからトンに進まなければ）解決するけど、2006年の小型デバイスはまだまだシン・クライアント。そうすると、むしろ12月にあったBinary 2.0カンファレンスのオープニングで高林さんが話されていたように、Binary 2.0こそがシン・クライアント時代の「Web 2.0を底辺で支える」技術で、まずは「時代はBinary 2.0」になるのかもしれないな、と思った。
僕もPerl屋さん、それもテキストレベルにとどまってちゃいかんのかも！ ...いや、多分僕は、そのレベルにとどまり続けると思いますが。
Wiki小話Vol.5終了〜。早速次のネタを練りこんでたりして。
昨日はdotBARでWiki小話Vol.5でした。なんともお酒の進まない集団で店を占拠すること4時間。20時から23時ぐらいまでイベントが続いて、その後24時ぐらいまではまったり飲んだり、帰る人は帰ったり。
今回はたつをさんプロデュース「Wikiプレゼン会」ということで、参加者全員が、一人5分のプレゼン。私のネタは、WikiのbackronymとWikiwygで個人的に旬なWikiwyg。WalWikiに組み込むところまでいければ良かったのだけど、そこまで持っていけなかったので、Wikiwyg体験環境としてのKwiki＋Wikiwyg構築ガイドでした。以下は、今回の資料9ページのうち、1、3、7、8ページ目。
準備時点では、Windows＋Active Perl環境でワン・ステップずつ構築作業。Kwikiが動いたあたりから、その手順をKwiki上に書きつつ、さらに構築を進める、という感じでWikiwyg導入までこぎつけました。Wikiwygで編集できるところまで来ると、なかなか凄いことをしている気がします。
このKwikiですが、非常に良くできていて、モジュールインストールさえできていれば、設置からWikiwyg導入まであっという間にできます。 5分のプレゼンの間に実際に設置デモもできたぐらい。 ...それをやらんがために非常に気が焦って、しゃべる方はかみまくりでしたが。
資料は以下にあります。ぜひ試してみて下さい。そして、資料の8枚目の通り...JavaScript?の分からない身には組み込みが非常に大変そうなのです。"Please, please help me!"ということで。
雪！雪！雪！やっぱりWiki小話Vol.5に向けて、おとなしくハッキングの方向で。
今週末はいっそう冷え込むそうですね。Wiki小話Vol.5に向けて、おとなしくハッキングの方向でいこうかな。
ライブドア関連ニュースを読んでいると、個々の問題にいちいち堀江さんが検討を加え承認を出していたとは思えないのだけど、それでも責任を問われるのが社長のお仕事なんだな、としみじみ思います。他の事件でも同じはずなのだけど、いっそうそう感じるのはホリエもんのキャラクターのせいかも。
もっとも、だから会社がおかしなことをしないように、社長は社風作りに力を入れなきゃいけないわけだけど。
Tech総研の「エンジニア的超緻密計算☆ウォームビズって効果ある？」が面白かったです。どこまでホントか分からない仮説で、できる限り緻密な計算式とか計算値を用意して科学してみるって楽しくて好き。しかし、このすさまじい数式に、ちょっと気になるところが。
(67.4×M+53.8×F)×1.5 -- 人が発生する熱量
M : 男性の人数 F : 女性の人数
男性は一律、女性より25%ぐらい、いるだけで暑苦しいってこと？
ちょっと前の話になってしまうけど、Inteligent Enterprise Magazineに「Wikis: Enabling Effective Knowledge Sharing Across the Organization」という記事が掲載されている。記事中の紹介によれば、著者のGraeme Fouxは生産性向上のためのコラボレーションとコミュニティ形成に豊富な経験を持ち、ホンダなどでそうした業務に携わっているコンサルタントのようだ。内容は技術的に新しいところはないけど、良くまとまっていて、企業での利用についてとても示唆的だと思う。
"Wiki" is currently one of the most popular new buzz terms in business discussions. Unfortunately it is also one of the most incomprehensible for many people. But what are wikis, are they important, what benefits do they provide and are they being used successfully within large corporations?
記事は「"Wiki"は現在、ビジネス・ディスカッションにおいて最もポピュラーな新しいバズ・タームだ。残念ながら現在のところ、これは多くの人にとってもっとも不可解なモノのひとつでもある。」とはじめられている。 Wikiが日本でも「ビジネス・ディスカッション」の場でバズ・タームであるかというとちょっと疑問だけど、Webに興味を持つ人の間では確かにバズ・タームだし、それが「しかしよく分からない」と思われている点でも同様だろう。
■ Wikiのもたらす価値と機能
話はWikipediaを紹介した後で、Wikiのもたらす価値と機能に移る。ここでWikiのもたらす価値として、次のようなものも挙げられている。
・Helping distributed teams work together seamlessly and productively
・Eliminating the one-webmaster syndrome of outdated intranet content
「分散したチームがシームレスに、生産的に働くのを助ける」点を上げているのは面白い。チーム・メンバーの分散は、実際に良く見られるが、あまり想定も考慮もされていない状況だ。元々Wikiは分散したWeb利用者が協働するためのもので、当然その役に立つのだけど、確かに企業の急所の一つかもしれない。「時代遅れなイントラネットでの一人Webマスタ・シンドロームの排除」の言は辛辣で、確かにそれだから、情報はイントラWebではなく共有ディレクトリに集まり、埋もれる。
一方で機能としては、次のような点が含められているのが目を引く。
・A simple (and free) way to build and manage content
・Easy to track and constantly up-to-date
「コンテンツを構築・管理する簡単な（そして無料の）方法」「捜索とコンスタントなアップデートが用意」つまり、あくまでコンテンツ・マネジメント・システムであるとしている。Wikiは、たんなるコンテンツ・マネジメント・システム。でもWikiにより、各所から、各人がコンテンツ・マネジメントに参加できるようになるだけで、これだけの効果がある、ということだ。
■ Wikiを使う企業、供する企業
Wikiを実際に利用している企業、WikiをASPで提供している企業の紹介もされている。まず、利用企業だ。
Organizations that have leveraged Wikis include Disney, Dresdner Kleinwort Wasserstein (DrKW), Yahoo, IBM, Lufthansa , New York Times Digital and Motorola.
ディズニー、ドイツ銀行（DrKW）、Yahoo、Yahoo、IBM、ルフトハンザ、ニューヨク・タイムス・デジタル、そしてモトローラ。どこかで見た名前が多いと思ったら、「Confluence - もう一つの企業向けWikiサービス」で紹介したConfluenceのプレス・リリースだ。
このConfluenceの名前も出てくる。
Some organizations are already adding wiki-like features to their existing systems to support collaborative efforts, resulting in combined systems promising great updatability and optimised sharing of knowledge and information. We have also seen the emergence of commercial, wiki-based collaboration software, like Socialtext and Confluence (“the Enterprise Wiki”), which offer an improved, user-friendly interface with wiki capabilities.
いくつかの企業は既に、Wikiライクな機能を既存システムに付加している。また、Wikiの能力と、より改善されユーザー・フレンドリーなインターフェースを持つ、SocialtextやConfluenceといった『エンタープライズWiki』と言えるコラボレーション・ソフトウェアも登場してる、ということだ。もちろん、このリストには年明け早々にTrackerで話題をさらったJotSpotも加えられるべきだろう。
■ 「できる」Wiki構築術
また、実際的な話として、成功したWikiサイトの構築では、以下のようなポイントとキーファクターが見られた、と紹介している。
・Make it relevant, encouraging usage and personal involvement
・The leaders should be identified and encouraged
・The leaders of the Wikis should also be editors, spotting mistakes and changing them automatically
・Show who is the content provider
・Include meta-content to encourage and engage (individual user homepage, statements about the goal or culture, instructions, pages with jokes, best or funniest contributions, etc.)
・Communicate the value of joint ownership of the wiki’s content. The most convincing way is for the manager to contribute valuable content himself/herself
・Provide incentives in the form of praise, respect by one’s peers and influence. Continuous participation with the wiki should be a reward in itself
リーダーを定める、コンテンツ提供者を明示する、貢献を評価し貢献者を賞賛する、といった指摘は、ちょっとWiki界隈での一般例と異なる。しかし確かに、企業内に限らず、成功したWikiサイトではサイトオーナが非常に活発なコントリビュータで、他にも名前を出すコントリビュータ、コメントが多い。特に企業内では、成果が評価されることはとても大事で、匿名性の有効性は限られる。こうした点はむしろ意識して行われるべきところかもしれない。
そういえば「ジョークページを用意すること」などは、たださんが実際に行って、効果を上げておられる。また、Wikiサイトごとのアクセスランキングなどを、サイトオーナ名つきで提示するlivedoor Wikiは、貢献者を賞賛している実例と言える。
■ Wikiをどう捕らえるか。
記事の内容はこうしたところで、最後は次のように締められている。ちょっと長いが、一段落、丸々読んでも損はないだろう。
There are always challenges when dealing with new technologies, but Wikis represent a relatively simple and compelling addition to the collaborative capabilities available for your organization. However, using Wikis in isolation will significantly limit the potential for knowledge sharing and collaboration. Instead, they should be considered as one of a number of tools supporting internal communities. In turn, those communities also need to address key issues such as providing compelling content and the need to change behavior, in order to unlock the real benefits of collaborative working.
「一段落、丸々読んでも損はない」と言ったからには、ここはそのまま訳すことにしよう。
新技術への対応はいつもチャレンジではあるが、Wikiはあなたの組織の発揮しうるコラボレーション能力に、比較的シンプルで無視できないだけの寄与を示す。 しかしながら、Wikiを単独で使用するのでは、ナレッジ共有とコラボレーションの可能性を著しく制限されるだろう。 そうではなく、内部コミュニティをサポートするいくつものツールの一つとみなすべきだ。 また、コミュニティはコラボレーション・ワークの真価を解き放つために、無視できないコンテンツを提供し、習慣を変えることを必要とする。
「内部コミュニティをサポートするいくつものツールの一つとみなすべきだ」は重要な指摘だと思う。企業内でWikiが使われるようになるには、まずワークフローの一部としてWikiが組み込まれることではないか、と思っている。もちろん「ワークフローの一部しかサポートしないシステム」では役には立たなくて、それを考えればWikiはさまざまなワークフロー・システム、ナレッジ・ベース、その他の情報システムの一部として組み込まれるようになるのだろう。
ざっと紹介してきたが、省略してきた部分も多い。気になることがあった方は、元の記事も参照していただくと良いと思う。
昨年PR1がClub Newtonで報じられ、Linuxザウルス界隈でも話題になったNewtonOSエミュレータ「Einstein」ですが、開発者のPaul GuyotがWorldwide Newton Conference 2006でLinuxザウルス上で動作するところをお披露目したとのころ。やはり同カンファレンスプレゼンターでもあるAdam Towが、blog上で数枚の写真とともにレポートしているのを、Slashdotが報じています。
...と思ったら、既にこれもClub Newtonで報じられていますね。早い、早い。ここに書かれている通り、Einsteinのサイト上にスライドのPDFファイルと、Einstein 2006のtar+gzファイルがあります。スライドによれば、これはSL-5500上＋Open Zaurus ROM＋X11環境で動作し、「まだバグも残っている。でも全体としては、こいつは動作している。」とのこと。
最後の（少なくとも現時点で最後の）Newton OS PDAは、Linuxザウルスに変わったわけです。シャープデバイスである、Newton OS機。何だか感慨深いところもあって、楽しい話です。
tarボールを取得してみたところ、インストール方法などを記したPDFファイル（UserManualPlatform2006.pdf）が同梱されていました。まず、必要な環境は以下の通り。
それから、開発者自身は、Zaurus SL-5500＋OpenZaurus 3.5.4-rc ROM＋X系を中心にいろんな新しいライブラリ（ドキュメントには詳細が書いてあります）で動作させたとのこと。 NewtonOS 2.1 ROMというのが難物ですね。
ふと思ったんだけど、「サンと心中」ってIT企業としては結構長生きじゃないかな。 どれぐらいの割合の会社が、サン・マイクロシステムズより長生きできるだろう？
mixiのPerlコミュニティのトピック「業務経歴書にPerl案件を書くと馬鹿にされる件」より。
「うちは Javaで飯食ってるので、そういう低レベルな言語を得意げに話されても困ります」
「Perlはインタプリタを介するから遅い。Javaサーブレットは一度コンパイルしてしまえば早い」
こういう発言をする会社があればちょっといただけないのは確かです。後者は、僕も自社の講習でそんな発言を聞いたけど。 しかしそれはそれとして、このトピックで発言しているPerl使いさん達の一部が、Webしか知らないように感じるのも否めない気が。
■ IT業界のお仕事
IT業界での開発案件には、Webサービス開発と同じくらい（あるいはそれ以上）のシステム・インテグレーション（SI）案件があります。そのSIのメイン・ストリームはオープン・システム、次のようなものです。
様々なメーカーのソフトウェアやハードウェアを組み合わせて構築されたコンピュータシステム。（略）各社がOSやアプリケーションソフトの外部仕様を公開することで実現されている。
オープンシステムとは 【open system】 ─ 意味・解説 ： IT用語辞典 e-Words
つまり、IT業界のお仕事の少なくとも半分は、ざっくり言えば汎用のパッケージを組み合わせて、つなぎこんで、システム化することです。IT業界での開発案件も、半分は特定のシステム（パッケージ）へのアクセスを必要とするもの、ということになります。
■ オープン・システム
ここで「オープン」という言葉がSIer以外には誤解されがちなのですが、SIで使われるパッケージの多くは商用です。「外部仕様を公開することで実現され」るものですが、オープン・ソースなどの「内部仕様やコードまで公開する」オープン文化とは無関係のものです。IT Proの記事が端的な説明でよいと思います。
あるシステムがオープンかどうかは大きく言って次の2点で決まる。
一つはアプリケーション・ソフトをシステム間で移動できること。あるシステムの上で動かしていたアプリケーションを別のシステムの上で動かすことができれば何かと便利である。もう一つは，あるシステムと別のシステムとの間で簡単に会話ができること。会話とは曖昧な表現だが，あるシステムのデータを別のシステムに送信したり，あるシステムに入っているデータを別のシステムから利用できることを指す。
「オープンシステム」って何？：IT Pro
ありがちな状況として、使用予定のパッケージのデータ構造は独自バイナリや、ある顧客の情報が10ものテーブルに分割された正規化されたDB。APIや通信プロトコルは独自実装。もちろんこれらは非公開で、逆コンパイルなどは禁止。そして公開されている「外部仕様」というのは、しばしば、特定言語用のライブラリやAPIのことです。
Web開発の世界では不特定の利用者や様々なクライアントで利用できる、XMLやRSS、RPC、SOAP、ATOMといったオープン・スタンダードな技術で構成し、それらをを活用することが重要です。一方のSIの世界、オープン・システムでの開発の世界ではしばしば、まるでスタンダードがない技術分野のオープンでもない技術を抜きには「やってられない」ことがあります。
■ ベンダ・サポート
つまりSI案件には、開発元によるAPIや開発環境の提供に頼らざるを得ない部分が大きい一面があります。そして、こうしたサポート対象になりやすいのが、Java/C++/COMオブジェクトだという現状があります。例えば、ERPの分野では、以下のような状況があります。
SIerであればERP、CRM、SCM、SFA、EAIといったパッケージを無視することはないと思うのですが、こうした分野でのベンダ・サポートに格段の差を感じます。そしてSIでのJavaの優位は、こうした標準化とは逆向きの「低レベル」な開発でも、ベンダ・サポートによってやっていけるところにあります。
■ 情報システムの寿命
もう一つ、システム・インテグレーション（SI）について押さえておきたいことがあります。SIは、次のように説明されています。
企業内情報システムの立案から導入・保守まで、単一の業者が一括してサービスを提供すること。
システムインテグレーションとは 【system integration】 ─ 意味・解説 ： IT用語辞典 e-Words
SIerは、導入フェーズで使用した技術を、保守フェーズでも必要とします。こうしたシステムの寿命は、一般的なところで5年、ハードウェア・リプレースなどの延命を施された場合で10年という長期にわたりますが、SIerはその間、その技術が分かる技術者を抱え続けます。SIerがある分野からの撤退を決めた場合、新規案件による収入のない中で、時には保守費用収入よりも高い人件費、あるいは教育費用を賄い続けます。
■ なぜ「業務にPerlは使えない」のか？
そろそろ最初の話に戻りましょう。ここで見てきたように、まず「PerlよりJava」と言われてしまう場合、その背景にはしばしば商用パッケージ・ベンダのサポートの差があります。「PerlもJavaも」と言ってもらえない場合、その背景にはしばしば技術保持費用の問題があります。
あるIT企業がJavaを選ぶのか、Perlを選ぶのか、JavaとPerlと両方採用するのか。それは会社戦略のレベルの話です。ここまでの話（だけ）を元に乱暴にまとめてしまえば、次のような選択肢があるでしょう。
| マーケット戦略 | リソース戦略 | 狙い | |
| (a) | Web開発案件に絞る。 | オープン・スタンダードに強いPerlに絞る。 | 選択と集中（最小限の人件費、高い収益率） |
| (b) | SI案件を重視する。 | オープン・システムに強いJavaに絞る。 | 選択と集中（最小限の人件費、高い収益率） |
| (c) | Web開発案件もSI案件も積極的に手がける。 | Perl、Javaの両技術を保持する。 | 規模効果（大きな人件費を上回る、大きく安定した収入額） |
その会社の体力や営業力、各分野での受注につながるコネクションや実績など、会社ごとに違う答えを選ぶことになるでしょう。SIというマーケットにそれなりの規模がある以上、答えが(b)になる会社も少なくないはずです。そうした会社で「当社の業務ではPerlは使えない」と言われることがあれば、それはその通りだと思います。
■ あるBloggerの直観。
この話の発端となったトピックに触れた、あるブログ・エントリから一説を引用します。
どっちが良いとか悪いとかは関係なく、世の中のオープン技術で開発をしている会社は、
・Java + Oracleを主流とする会社
・Perl + MySQL、PHP + MySQLを主流とする会社
と、完全に二層に分かれてるなと思っている。
F's Garage：Java圏とPHP,Perl圏の断絶について。
おそらくこの方が直観されていることは事実で、そうなると考える理由もここまでで述べました。もちろん、ある会社がビジネス戦略としてJava技術へのフォーカスを選択したとして、それが正解かどうかは分かりません。ただし選択肢を選択肢と認めて検討することができず、リスクしか見ずに切り捨てるのであれば...例えば
「会社としてJavaだけでいく！」 そんなプロプラエタリ言語に全てを托すのは企業として危機管理意識が全然足りないですね。 サンと心中する覚悟があるのはアシタカだけで結構。
業務経歴書にPerl案件を書くと馬鹿にされる件 - mixi「Perl」コミュニティ
と言ってしまうのであれば、ビジネス・プレーヤとして見てもらうのは難しいかもしれません。きっと、「危険だから避ける」どころではなく「その日が来たら会社を終わらせる」と積極的に決めて、それまで効率よく稼ぎ、良く社員を遇するという選択すら、ありえます。これを「選択しない」人はビジネス・プレーヤとして、ビジネス・メンバの一人として雇われるかも知れませんが、「検討もしない」人は単なるコーダー、単なる作業者として以外は不要でしょう。
Javaが使われてPerlが使われない会社があるとしても、それはPerlを使わないことを選択したのであって、多分、言語の優劣だとかじゃないと思います。
W-ZERO3購入者向けに「インテル×W-ZERO3 スマートグッズプレゼントキャンペーン」というのが始まったようです。1GBミニSD、W-ZERO3専用スタンドが白眉ですね。ちょっと気になった点を挙げておくと...
...という感じで。POSTの盗聴を暗号化で防いでると主張されても、このエラーページが盗み読みされたら名前や電話番号丸見えってのは嫌な感じ。キャンペーンページの出来がちょっとスマートじゃないなぁ。
Wiki小話/Vol.5の参加者募集が始まりました。...という話を、「Wiki・ばな・うら・ばな」の方で。
皆様、奮ってご参加ください！
被はてなブックマークページなどを見ていると、W-ZERO3に引っ張られてかLinuxザウルス関連のページがまた見られている様子。 うまく相乗効果になると良いですね。
CNETの「wiki--集団による編集が変える報道のあり方」がWikipediaから引用として「wikiの由来」というミニコラムで、次のように説明している。
一説によれば、wikiは「what I know is（私が知っているのは・・・）」の頭文字を取ったもので、知識の貢献、蓄積、交換などを示している。
wiki--集団による編集が変える報道のあり方 - CNET Japan
「これのソースはどこにある話だろう」というyomoyomoさんの呟きに釣られてWeb上をうろちょろ。Twiki Javapedia（java.net）のGlossaryまでは行き着いたのだけど、これの記述者とかこう書かれるまでの経緯とか、誰かご存じないですか？特にJava側の方々。
ところで、本家WikipediaのWikiの項をあたると確かに以下のような一文がある。
Wiki is sometimes interpreted as the backronym for "What I know is", which describes the knowledge contribution, storage and exchange function.
Wiki - Wikipedia, the free encyclopedia
この「backronym」という単語が分からなくて、Backronymの項も引いてみた。もう、釣られまくり。これを「一説によると」とするとニュアンスが微妙に変わってしまうようで、どうやらBack＋Acronym、後付の略語をさす造語らしい。次のようなケースが挙げられている（と思う、僕が読み間違えてなければ）。
こうしてみると、Backronymって命名者の思想とか遊び心とかが良く現れるものだということが分かる。「WIKI is "What I Know Is".」というのはやっぱり後付の最たるものじゃないかとは思うけど、話としては面白い。
ちょっと話がずれるけど、これで思い出したのはWikipediaを評した「DIY Internet encyclopaedia」というフレーズで、とても秀逸だったと思う。Wikiサイトで特徴的な点の一つは「訪問者にとってDIYなサイト」というところだよね。こうしたフレーズと同様に、よくできたAcronymとかBackronymとかはシンプルな表現で、気付きを促す点でとても強力。もし良くできたWiki関連のAcronymを知っている（あるいは思いついた）人がいたら、ぜひ聞かせてほしい。
そう書いていてふと気がついたのだけど、Wikiが「What I Know Is」の略語だとすれば、WIKIWYG」は「What I Know Is What You Get」になるよね。この7語は、DIYなところも、知識をシェアするという性格も、ちゃんと盛り込まれている。「WikiがこうならWikiwygはこうなる」なんて考えてWikiのBackronymを付けたわけじゃないだろうけど、Wikiwygがこうした略語だとすれば、これほどWikiをうまく言い表せる略語ってなかなか無いかも知れない。
実家で誕生日を祝ってもらってきました。 誕生日がおめでたい年ではないですが、お節とか鍋とか家でしか食べたれないものを食べられたのはありがたいです。
昨日、年末年始のお休み中に試験環境がDBインスタンスごとざっくり消えたことを知らされました。2ヶ月かけた試験データがっ！
...ということで、手作業はもうあきらめてデータ登録ツールをUWSCで作ろうかと思ったのだけど、いっそ開き直って腰を据えて、Win32::GuiTestにチャレンジしてみようかと翻意。とりあえずインストールあたりまでのメモをDigit:Perlメモ/Win32::GuiTestモジュールにまとめてみました。
今日が仕事始め。三が日と今日で、Net::POP3とMIME::Parserの顔を見なくてもPOP3でのメール受信が簡易的にできるラッパを作ってました。だって、MIME::Parse、難しいんだもん...。
できたんだけど、表に出すのがめんどくさいなぁ。
明けましておめでとうございます。今年もよろしくお願いいたします。
三十路にも新居にも慣れ、去年とはうって変わってなんだか心静かにお正月です。今年も皆様、よろしくお願いします。
