higuchi.com blog

higuchi.com blog http://www.higuchi.com/ Looking on the digital side of life ja Nucleus CMS v3.41 Copyright 2002-2006, Osamu HIGUCHI Weblog http://backend.userland.com/rss http://www.higuchi.com/images/higuchicomsml.gif higuchi.com blog http://www.higuchi.com/ <![CDATA[Typo [純粋特殊会社]]]> http://www.higuchi.com/item/60 トーマツコンサルティング
（正しくは、純粋持株会社と思われます。）]]> VOW http://www.higuchi.com/item/60 Fri, 3 Jul 2009 15:31:02 +0900 <![CDATA[Confusing [中途半端なローマ字表記]]]> http://www.higuchi.com/item/61 Shiba 3-chome?最近はどこの街でも国際化が進んで、電車の駅名とかバスの停留所の案内が外国人のみなさんにも分かりやすいようにローマ字とか中国語とかハングルで併記してあったり、外国語でもアナウンスされたりすることが多いですね。
むかーし、ソウルの地下鉄でローマ字表記も漢字も無くって、とっさの乗り換えでおたおたした経験があるので、見知らぬ土地で少しでもヒントになる表記があるのはとってもうれしいというのはよくわかるんだけど、中途半端な外国語表記でかえって混乱させているんじゃないかというケースもあって、気になります。

例えば、右の写真は港区を走っているミニバスの中の表記。「芝三丁目」という停留所で、アナウンスも各国語で「シバ、サンチョーメ」と言っているのだけど、ローマ字表記は “Shiba 3-Chōme”。日本語を知らない人相手なのに「3」を「さん」と読めると期待してるのはどうかと思うのです。Shiba 3-Chome じゃ「シバ　スリー（いや、ドライかもトロワかもしれないけど）チョーメ」だ。

話変わりますが、外国語のアナウンスと言えば、香港。イギリスから中国に返還される前は広東語とイギリス風英語 (Mind the gap、とかね）の標識やアナウンスだったのですが、返還後はそれに北京語/マンダリン、というか普通話も追加されるようになりました。例えばおなじみの九龍も「ガウロン」と「カウルーン」に加えて「チュウローン」と三者三様。おもしろい。]]> ことば http://www.higuchi.com/item/61 Fri, 3 Jul 2009 13:00:35 +0900 <![CDATA[祝・復帰！ [iPhone用の最速・最強Twitterクライアント Fastweet 2K]]]> http://www.higuchi.com/item/548 Fastweet 2K支援先会社のひとつで非常勤の取締役として関与させていただいているグルコースの iPhone 用最速・最強 (当社比 :-) Twitter アプリ『Fastweet 2K』の待望の不具合修正版。開発は問題発覚直後に終わっていたのですが、App Store での3週間にわたる厳密な（皮肉です。念のため）審査プロセス待ちを経て、ようやくリリースされました。App Store へのリンクはこちら。

いやー。長かった。待ちました。よかった、よかった。Twitter の累計「つぶやき」数が 32 ビットで表現できる数を超えて桁あふれしちゃった Twitpocalypse 問題に見事にハマって、未読数が延々と増え続けてまともに使えない障害が起こっていたのですが、ようやく解消。これで朝の通勤中の Twitter チェックは、のどけからまし。

ご存じない方のためにちょっと解説しておくと、Fastweet 2K のウリ（私にとって重要な順）は、

反応待ちを感じさせない、さくさく高速動作。
最大4,000まで過去のつぶやきをローカルにキャッシュ、電波がつながりにくい地下鉄などでも接続を意識せずシームレスにオフライン閲覧。「あとで読む」機能つき。
「読む」だけじゃなく「書く」ほうもスイスイ。Retweet やリブログにもしっかり対応。
高速快適UIのカナメの50件分割表示と、横フリックでのページ送り

などなど。Always on でイラチな都市生活者に最適な Twitter アプリなので、Twitter 使いの iPhone ユーザーはみんな買うように。
230円が惜しい人は、ローカルで読めるつぶやきが 200 件までで広告表示がついている無料版 Fastweet をお試しください。お願いします（低姿勢）。]]> iPhone http://www.higuchi.com/item/548 Fri, 3 Jul 2009 10:56:35 +0900 <![CDATA[本日ひとり集中日 [株主総会]]]> http://www.higuchi.com/item/62
総会屋さんが各社の株主総会を荒らしていた時代。よその会社と違う日に株主総会を開催すると総会屋さんがこぞって集まってきて困っちゃうという防衛意識が各社に働いて、各社同じ日に総会を開くクセががあったんですね。
近年は総会屋さんもそれほど跋扈していないし、みんな同じ日に集中すると複数の会社の株主が出席しにくいからよろしくないというご指導もあって、東証の定時株主総会集中日の統計データによると、昔ほど同じ日に集中することはないようです。

総会が同じ日に集中すると、株主さんも困るけど、複数の会社の役員をやっている者にとっても困ったことになります。一昨年だったか、同じ日に総会が集中してどうしても移動スケジュールの都合がつかず、ある会社の総会が終わったらそのままその会社の部屋にこもって、Webcam の前に座って、Skype 経由で別の会社の総会会場のプロジェクタースクリーンの上にビデオ出席したことがあったっけ。

そんなわけで、総会の日程が分散するようになって、土日に総会を開くケースも増えてきて、めでたいことです。
と思っていたら、今年はどうしたことか、ひな壇側に座らないといけない上場会社の総会2社が、2社ともよりによって今日の土曜日に総会を開催することになっちゃいまして、結局今日は私ひとり総会集中日。
幸い、時間はずらしてもらえたのと、場所がとても近いのでビデオ出演もヘリコプター移動（笑）も必要ありませんが、大手町から神保町までタクシー飛ばして総会のはしごをすることになりそうです（株主総会って、終了時間が未定だから、後ろのスケジュールが読みづらいのです）。

去年に続いて、今年も壇上から Twitter でつぶやいてみます。フルに tsuda る余裕はないけれど。

さて、ここで豆知識。毎年の総会集中日はどうやって決まるのでしょう。Wikipedia の株主総会の項には「いわゆる集中日と呼ばれる6月最終木曜日」と説明されているけれど、これは東証の過去の統計を見てもあきらかに間違い。
真相はというと、ケーザイカイの誰かが後ろで糸を引いてみんなの意見をまとめて「今年はこの日！」と決めているとか、どこかの占い師が暦と方角を見ながら決めているとかいうわけではなくて、開催側事務方の消極的理由による消去法のルールベースで必然的に決まるようです。

日本に多い3月決算の会社の場合、6月末日までに有価証券報告書を提出しないといけない。これは決まりごと。
ところが、ぎりぎりの末日（最終営業日）に開催すると、万一総会でなにかがひっくり返ったりして有価証券報告書の書き換えをすることになった場合にその時間が取れないから、余裕をとって最終営業日の前日とか前々日に開くのが基本です。
さらに、総会の前日までに郵送で届いた議決権行使書の投票をとりまとめないといけないんだけど、総会を月曜日に開くと日曜日までに届いたハガキを集計しなければならない。議決権行使書はたいてい信託銀行気付で送られるけど、信託銀行さんが日曜日の夜にハガキを集計してくれることはたぶんないので、もし最終営業日の前日がたまたま月曜日（正確には休日の翌日）にあたってしまったときは、さらのその前の営業日を開催日にします。

まとめると、株主総会集中日は6月の最後から2日めの営業日で、その日が月曜日に当たった場合はさらのその前の営業日。6月の月末が週末にかかっていなければ6月29日なのです。]]> 会社 http://www.higuchi.com/item/62 Sat, 20 Jun 2009 09:34:19 +0900 <![CDATA[i18n と l10n の狭間 [文化の違いを説明すること]]]> http://www.higuchi.com/item/63
ソフトウェアの開発で、グローバルに、つまり世界中の言語で使えるように設計することを国際化 (internationalization = i18n)、それぞれの言語や文化に合わせてUIや仕様を変えることを地域化 (localization = l10n) なんて呼びます。このふたつ、並行して行われる作業だけど本質的には相反するもので、双方の利害がぶつかると経験的にはたいてい i18n が勝ちますね。

商用ソフトウェアでローカルの市場を担当していると、その市場向けの仕様をなんとかしてねじ込もうとして開発者に要求を出すと、i18n の錦の御旗の元に簡単に却下されちゃうことがよくありました。
実は却下される本当の理由は国際化とはあまり関係なくて、アメリカ人の開発者に日本の文化的背景に基づく日本固有の仕様を説明しても、なんでそんなものが必要なのか理解されないので優先度が低いんです。
そんなわけで、外資系ソフト会社の日本支社で日本市場向けのプロダクトマネージャーとかリエゾンみたいなことをやっていると、わりと日常的に日本の文化を予備知識のないガイジンに説明してなにかを説得することになります。

例えば、グループウェアで使うディレクトリ（ユーザー一覧の社内アドレス帳みたいなものと思ってください）を典型的な日本の大企業向けにカリカリにローカライズしたいときの説明。アメリカの会社、特にソフトウェア会社みたいなフラットな組織の人たちにとっては、社内アドレス帳なんて名前とメールアドレスと電話番号ぐらいがアルファベット順に並んでいれば事足りるもので、せいぜい First Name でソートするか Last Name でソートするかのオプションぐらいあれば十分です。実際、グループウェアのディレクトリとか国際的なメールソフトのアドレス帳はそんな UI ですね。

ところが、日本の大きな会社の紙の社内電話帳を見るとまず組織ごとに分かれていて（組織ごとにグルーピングしなければ）、ナントカ本部の中に部が分かれていて、部の中が課に分かれていて（組織構造の階層は柔軟に）、課の中は課長さんを筆頭に課長補佐さんとか役付きの人の名前が先に来て（役職のフィールドを作ってそれでソートしなくては）、その他の課員は入社年次の順番にソートされていて（入社年次のフィールドもいるぞ）、女性社員には下線が引いて区別されていたり（性別も入力できるようにしなくちゃ）します。

アメリカの会社だと、社員の誰かを特定するとき、例えば

A: Did you talk to John?
B: John who?
A: John Doe. International Marketing.

てな具合に、下の名前、上の名前、そのあとせいぜい所属部署名とか勤務地あたりという風に絞っていくけど、日本の会社だと

ほら、国内営業本部のオオカワ部長のところにいる、ウチのサトウ君と同期の女性、誰だっけ？彼女に話しといてよ。

みたいに組織からドリルダウンするケースがわりと普通で、日本の内線表はそういう思考パターンに適したレイアウトになっているんですけど、これが「普通」だというのは、アメリカの人にはまず理解できない。

で、これをいちいち説明しようと思ったら、日本ではGiven NameではなくてFamily Nameで呼ぶこと、名前は漢字とかなで表記するが、文字コード順でソートしたら辞書の順番にならないので、読みのデータを別に入れてそれでソートしないといけないこと、というあたりから始まって、日本の会社組織の典型的な構造がどうなっているかを説明して、社員はどこの部署に所属している誰々という風に組織に紐付いて認識されることが多いことを理解してもらい、日本のカイシャでは新卒社員はみんな同じ日に入社するしきたりがあって、同じ年に入社した人たちは「ドウキ」と呼ばれて横にひとからげにされることや、果ては雇用機会均等法以前の一般職と総合職について説明した上で、男女を識別して表示しても必ずしも性差別としてダイバシティプログラムとかの問題にハッテンするわけではないことなどを教えて、ようやく理屈の上では納得されるという手順を踏むことになります（もちろん、こんな仕様を「国際化」したコアのプログラムに入れるのはナンセンスなので、ローカルで独自のソリューションを作れるように必要最低限の部分をコアに入れてもらうわけだけど）。

ことほど左様に、文化の違いを本質的にどこが違うのかを識別したうえでロジックに落として、異文化の相手に分かるように説明するのは、けっこう面倒な作業なのだけど、ソフトウェアとかWebのサービスが国際化されればされるほど、丁寧なローカライズが大切になってきていると思うのですよ。誰とはなく。]]> ソフトウェア http://www.higuchi.com/item/63 Fri, 5 Jun 2009 01:30:34 +0900 <![CDATA[真夜中のキッチン [わらび、あく抜き中]]]> http://www.higuchi.com/item/66 わらび毎度お世話になっている大井沢方面から、見たこともないような立派なわらびがどっさり届きました。あく抜き用の灰までセットになっていて、至れり尽くせりです。

灰をまぶして、これから熱湯をかけるところ。]]> 食べる http://www.higuchi.com/item/66 Thu, 4 Jun 2009 23:59:05 +0900 <![CDATA[コラボレーションの再定義だ [Google Wave]]]> http://www.higuchi.com/item/513 こちら）。
グループウェアの新世代がやってきましたね。

昔話をします。

僕がグループウェアに興味を持ったのは1980年代の終わり頃、ソニーでワープロ専用機の設計とか企画とかをやっていたとき。Netnews とメールとFIleMaker を組み合わせて、なんとかしてお客様ご相談室へのお問い合わせと事業部側からのそれに対する回答を電子的に行って蓄積してあとから再利用できるようにできないだろうかと苦心した（結局挫折した）り、職場でその日のランチの仕出し弁当を注文する人のオーダーを机の上のコンピュータ（みんな黄色いイーサネットケーブルでつながった NEWS という UNIX ワークステーションや PC を持ってた）から出してもらって、それを自動的に集計してお弁当屋さんに FAX する仕組みができないかと夢想していた（これも頓挫した）とき。
コンピュータと通信を使って共働環境をつくる Groupware という考え方があって、学会もあるという話を USENET か何かで読んで調べ始めたのがきっかけでした。そのころ学会で議論されていた Groupware って大きく2種類あった気がします。ひとつは遠隔地にある施設を映像や音声やコンピュータ画面でつないであたかも同じ場所にいるように作業できる「同期型＝Synchronous」な共働環境の研究で、これは NEC とか日本の研究所の論文が多かった気がする。もうひとつはコンピュータネットワーク上で電子文書を蓄積したり共有したり送信したりする「非同期型＝Asynchronous」な通信による知識共有の環境の研究。海外の研究はもっぱらこちら。

で、僕はその後、ミイラ取りがミイラになるように、カスタマーサポートの知識蓄積システムとかお弁当発注システムなんかを簡単に作れるというふれこみのグループウェア環境の商品化にかかわることになったわけですが、そのグループウェアは上の分類で言うと「非同期型」のほう。蓄積した文書情報を、非同期に通信して、引っ張り出したり送り出したりするしくみでした。

その後20年近くの間、「グループウェア」というと、知識創造環境から、ただのスケジュール調整・会議室予約システムまで、たいてい非同期通信をベースにしたものだったんだけど、昨日、ついに同期通信をベースにした協働環境のインフラが華々しくデビューしたわけです。

同期通信ベースだと、ネットワークの上の他の計算機や他の人の力をリアルタイムに借りながら、リアルタイムに知識と作業の共有ができるようになる。リアルタイム翻訳チャットのデモはそのわかりやすい例ですね。この環境の上で、今までの非同期通信ベースとはまったく違う次元の協働アプリケーションが、いろんな人の手でもりもり作られる可能性を持っているはず。

これはすごいことだと思いますよ。]]> ソフトウェア http://www.higuchi.com/item/513 Sat, 30 May 2009 09:48:34 +0900 <![CDATA[ガチャポン [ネットで井戸を買った男の話]]]> http://www.higuchi.com/item/514 ガチャポン昔とてもお世話になった方が亡くなってしまい、今日が告別式。朝から袱紗もみつからず、文字通りとるものもとりあえずという感じで横浜・鶴見に平安時代から続くという古刹に行ってきました。
家族の方が中心のひっそりとしたお弔いに、昔の電器メーカーの同僚や部下、大学の同窓生を中心に20名弱が押しかけたような格好で、湿り気味の同窓会といった風情だったんですが、お弔いのほうはみなさんには関係ないので、「同窓会サイド」での立ち話。

最近までヒルズあたりのポータル会社の社長をやっていたりしたちょい悪系オヤジ。最近、群馬の月夜野あたりの、土間が20坪ぐらいあるような古い農家を買ってお百姓さんごっこのようなこともやっているようです。
お寺の井戸をずいぶん興味深げに蓋を開けたりして覗き込んでいるからどうしたのかと思ったら、こないだインターネットで井戸を買ったばかりなので、リアルな井戸がどうなってるのか観察していた、と。「ネットで井戸を買った」なんて言うから、最近は井戸を掘る権利もネットオークションで買えたりするのかと早合点して感心してたら、そうじゃなくて、買った農家にもともと掘ってあった古井戸につける、昔懐かしい手押しポンプをネットで買ったんだそうで、取り付け方を勉強していたらしい。

手押しポンプだけをネットで売ってるなんて、それはそれでびっくりしたんですが、意外なことに井戸の手押しポンプはいまだに現役バリバリで流通している商品なんですね。災害時なんかで電気が使えないときでも手押しポンプが整備されていれば水に困ることはない、と。都心のお店ではさすがにみないけど、地方の大きなホームセンターなんかでは、わりと普通に売っているものらしいです。なるほどね。

ちなみに、あの手押しポンプ、通称は「ガチャポン」だそうです。知らなかった。]]> フェティッシュ http://www.higuchi.com/item/514 Mon, 18 May 2009 21:49:49 +0900 <![CDATA[RT: @saitokoichi 後ろめたくないようなので…… [ストリートビュー撮影車へのナイスな提案]]]> http://www.higuchi.com/item/515 下のようなことを書いた後で、移動中に Twitter を見ていたら、@saitokoichi さんがこんなことをつぶやいてました。

後ろめたくないようなので、住宅地を撮影しているときは「いま撮ってます」を拡声器で叫びながらやってほしい。皮肉ではなくまじめな話 > グーグルさま

冷静に考えると、これはなかなかよい提案。前にも書いたけど、ストリートビューの場合、撮影されている側が撮影されていることに気がついていない非対称性も気持ち悪さの一因だと私は思っているのですが、これなら撮影されていることに気がつきやすいし、正々堂々と撮影しているという姿勢がはっきり表れていて、とてもフェア。

で、ひょっとして、万が一、ほんの１ビットでも「そんなことしたら問題が起こりそうだからやれない」とか躊躇する気持ちが湧いてきたのであれば、そこのところには改善すべきポイントがあるんだと思いますよ。
一度、思考実験だけでもいいから検討してみてはどうでしょう？＞誰とはなく]]> Google観察 http://www.higuchi.com/item/515 Wed, 13 May 2009 22:24:39 +0900 <![CDATA[本質はそこじゃないとは思うけど、がんばってね [ストリートビューの仕様変更]]]> http://www.higuchi.com/item/516 少し加担しちゃったという自覚はあるので、この話題には触れておきます。

報道等によると、ストリートビューを改良するそうです。改良点はざっくりと４つ（順不同）。

カメラの高さを245cmから205cmへと、40センチ下げる。撮影済みのところも、後から順次低いものに差し替える。
ナンバープレートにぼかしを入れるための機械処理を日本でも始める。
画像削除依頼などのお問い合わせのための専用電話窓口をナビダイヤルで設置する。
表札だけぼかして欲しいという要求にも応じる

ナビダイヤルでの電話窓口運営は人件費が固定費として必要だろうし、中の人によると表札だけぼかすのは機械じゃ無理なのでいちいち手作業らしいし、いつものグーグルのスタイルだったら「本質的ではないからコストはかけない」と判断しそうな部分に工数とお金をかける決断に思えます。このご時世、利益を直撃する固定費の増加は、経営的には少しでも避けたいはずですからね。

車道から3メートルと離れていないところに大きなガラス窓がある住宅に住んでいる者としては、それでもやっぱり我が家の前の写真が公開されたら（まだ幸いカバーされてない）やっぱり気持ち悪いし、たぶん削除依頼しちゃうと思いますけど、それはそれとして、今回の仕様変更について説明しているPMの河合さんのブログエントリーは個人的に応援姿勢。グーグル様って、人的リソースの制限なのか恣意的なのかは分からないけど、広報からのメッセージも何をやりたいのかできるだけ知らせないようにしていて、中に生身の人間がいることすらできるだけ感じさせないかのような木で鼻をくくったような対応が持ち味なんだけど、これですごく損をしているところがあるといつも思っているのです。
実際には中の人も人の子で、本当に情熱を傾けて「これを実現したいんですぅ」という思いに駆られていろんなサービスを作って提供しているはずなんだけど、それが見えないために「なにやらかすのかわからん」と思われている面があるんじゃなかろうか。
ま、昔のIBMとかMSとかもそんなころがあって、「Arrogant なのはいかん」みたいな反省があって、だんだん変わってきたと思うので、一過性のものかもしれないけれど。

で、上の河合さんのエントリーは、そんな会社のスタイルのなかで、せいいっぱい「やりたいこと」とか「思い」を伝えて説明しようとしている気がして、個人的にはちょっといいなと思ったのでした。こういうコミュニケーションスタイルは好きです。はい。

]]> Google観察 http://www.higuchi.com/item/516 Wed, 13 May 2009 17:35:04 +0900