最近、都営地下鉄の1日乗車券というのを買うことがある。この乗車券は700円で一日乗り放題なのだが、単独で切符を買うと300円程度の移動距離になると、行って帰ってきたらそれで600円。あと1行動あればトク、ということだ。

そんなに地下鉄に乗ることがあるのかというと、実は最初のうち見落としていたのだが、この乗車券、都バスも乗れるのである。都バスに1回乗車すると200円だから、何度でも都バスに乗れるというのは結構意味があるのだ。例えば、六本木から渋谷まで行こうとすると、都営地下鉄だけだとちょっと厳しいのだが、都バスで行けばいいのである。

さて、この1日乗車券を買おうとして先日ハマった話。500円玉が2枚あって、それで買おうとしたら、どうしても2枚目が入らないのだ。何回か失敗してから分かったのだが、この券売機は、500円玉が1枚しか使えないようになっているのだ。

しかし、持っているお金は500円玉2枚。ということで、駅員がいるところまで行って、両替してもらって問題解決したわけだが、最近は両替機なんてものは駅には存在しないらしい。

もちろん、500円以上の券が買える以上、その券が買えるだけの金額はどのような組み合わせでお金を入れても買えるようにしておくべきだが、それは今回はおいといて、問題にしたいのは、500円玉が1枚しか使えないという表示である。こういう所にあるのだ。

20050929-01

これがなかなか気づかない。ユーザーは切符を購入する操作中は、画面を見るのに集中しているからだ。もっと細かくいえば、コインを投入しているときは、画面の中でも、金額が表示されている箇所を集中してみているはずだ。画面以外では、コインの投入口もユーザーが見るはずの場所なのだが、なぜか、500円玉が1枚しか使えないという表示は、そこから少し離れた所にあるのだ。

画面上の金額表示箇所に「500円玉は1枚しかお使いになれません」と表示することができたらベストだし、タッチパネル+液晶画面、というユーザーインターフェースを選択した以上、そうするのが常識的な判断だと思うが、急場しのぎで何とかしようというのなら、もっとコインの投入口の近くに表示した方がいいと思う。

AD

JRの切符は、ちょっと長距離になると、目的地まで自動販売機で買うのが途端に難しくなる。かといって、みどりの窓口で買おうとすると、やたら待たされるので、結局 130円の切符を買ってとりあえず乗ってから、後で清算することが多い。

さて、先日乗ったときの清算金額が2810円。これを手渡したときに、500円玉が座席の隙間に転げ落ちてしまった。

途方にくれていると、隙間から座席の隙間の神様が出てきて、「お前の落とした500円玉は、金の500円玉か、銀の500円玉か、それともこの普通の500円玉か?」

ということがある訳でもなく、何とか指を突っ込んで取り出したのだが、これはこれで結構危険な話である。車掌さんが取ろうとしたのだが、うまく途中でひっかかっているのがこちらから見えていたので、勝算十分ということで自分で取り上げた。これで指でも怪我をしたらかなりヤバい話で、客にそういうことをさせないような指導があるのかもしれないが、今回はそれはどうでもよい。

考えてみると、電車の中で何か落としてしまって、それが取れなかったり、取るのに苦労したり、という経験が結構よくあると思う。電車の構造として、落としたものを取りにくいデザインになってしまっているのである。

もともと、電車というのは走行中はかなり揺れるものだから、そこで何か受け渡しするときに落とす確率も高い。そのような状況があらかじめ分かっているのだから、物を落とすということも想定しておくべきなのだ。できることなら、さらに、落としたものがすぐに拾えるように設計してあれば、なおよい。

特に、硬貨のやりとりは頻繁にあるから、それを落とすということも、結構あるはずだ。硬貨を落としても拾えるかどうかは、例えば、硬貨をわざとばらまいてみて、すぐに全部拾えるかどうか、というテストをしておくとよいと思う。

もっとも、JRに限らず、スーパーやコンビニのレジ周りとかを想像すると、もしかして、このテストに合格するような所は滅多にないかもしれない。逆に、コインを落としたら隙間に入ってしまってどうにもならない、という経験は、かなりよくある。実は先日も、某カメラ量販店で1円玉を落としてしまって、拾えないところにハマってしまったのだ。これを回収するコストを考えると、どうみても1円の価値はなさそうだから、そのまま捨て置くことになってしまったのだが、こういうのは、隙間がどうしてもできるのなら、わざと大きく隙間をあけておいて、拾いやすくするという手もあるはずである。

AD

20050925-01

自宅では VAIO Z というノートpcの Wireless LAN の機能を使っているのだが、外ではこれはあまり使わないので、セキュリティ絡みの余計なトラブルを避ける意味でも、WIRELESS のスイッチを off にすることになる。ノートパソコンを持ち運ぶときは、ハイバネーション機能を使って、現状をハードディスクに退避しておき、使うときにそこから復帰するのだが、退避時に無線LANを使っていて、復帰時に WIRELESS のスイッチを off にすると、起動後、「ワイヤレス ネットワーク接続 に 接続しました」というポップアップメッセージが表示される。

電源は切ってあるはずなので、接続できるわけがないと思うのだが、もし接続していたらおかしな話だし、しかも、シグナルが非常に強いというのが謎。多分、メッセージの表示処理のバグだろう。とにかく、いつもこういうメッセージが出ていると、「接続しました」といわれても本当に接続しているかどうか判断できない訳で、これはこまったことである。

もっとも、ハイバネーションという処理自体が、かなりやっかいなものだ。電源を切る前の状態ではワイヤレスネットワークが動作していたのだから、まず、その状態に復帰しようという動作をしてしまうのは無理もない。しかし、ノートパソコンの場合は、電源をoffにした前後で場所が変わっていることは確実にあり得る状況だから、それは当然のごとく想定すべきである。このような処理はきっちり実装していてほしいものだ。

とはいっても、最初は違和感があったが、最近はこういうメッセージが出てもどこ吹く風、というか、慣れきってしまった。これが出ても普通だと思ってしまっている。慣れというのは恐ろしいものだ、というか、そちらの方が怖い現象なのかもしれない。

AD
最近というわけでもないかもしれないが、高速道路のETC対応料金所での死亡事故が増えている。22日には、首都高でこの種の事故があった。

ETC 対応の料金所入り口は、停車しなくても通れるというのがメリットとされている。また、高速道路というのは、人が歩いていないという先入観がある場所である。こういう所で人が歩いていても、とっさに対応できないのは仕方ない。むしろ、運転手が「人は歩いていない」と想定しているような所は、人が歩くことができないような工夫をしておくべきである。そうでないと、いつまでたってもこの種の事故が続くのではないか。

どうしても人が歩かないといけないというのなら、その前に信号を付けるとか、人が歩かなければいけないときには車が入れないようにする、という手もある。

赤は警戒色と呼ばれている。注意を喚起したい場合に使うと効果的なのだが、そのため、何か間違いがあったときによく使われる。ユーザーはそのような場面に使われることを無意識のうちに学習しているから、それを踏まえて赤を使う必要がある。

20050922-01

これはとあるサイトのアンケートに回答したときの画面なのだが、赤で表示されている文章に惑わされて、何か選択し間違ったのかと思って、一つ前のページに戻ってやりなおしてしまった。しかも、このサイトの場合、戻ったときにクッキーの有効期限が云々ということになり、ややこしいことになってしまうので大変である。

このように表示されていたら、間違って2つ以上選択してしまったか、と思うのは別に不思議なことではなかろう。もともと、1つしか選択できないような選択肢なら、複数選択できないようなユーザーインターフェースにすればいいのであって、このような警告文は必要ないはずだ。

2割の処理が8割を占める

テーマ:

愛知万博は入場者制限を行ったそうである。せっかく行ったのに、どこにも入れずに帰ってきた、というような人もいるらしいが、お祭りだから、そういうのもアリなのかな、とか思ったりする。

ソフトウェアの世界でよく言われている法則に、2対8の法則というものがある。呼び名はいろいろありそうだが、要するに、全体の2割の処理が、実際に呼び出される処理のうち8割を占める、というようなことを言っている法則だ。

ネットワークの負荷などを想定するときに、この法則を使えば、必要な性能が簡単に計算できる。たとえば、1日に1万人がアクセスするシステムを考えてみよう。単純に考えると、1万人÷24÷60 だから、1分あたり約7人が処理できればいい、…というのは発想が安直すぎる。これでは簡単にシステムは破綻するのである。2対8の法則を使うと、次のように計算できる。まず、1日の2割は、24×60×0.2 = 288分。この時間に、1万人のうちの8割、つまり8000人が使うのである。ということは、8000÷288 、これは1分あたり約28人。この程度の性能が必要だということがわかる。

もちろん、これはあくまで目安であって、こうやって想定すれば問題がないという話ではない。ただ、単純に割り算するよりは、現実に近い状況が想定できるというだけのことだ。予想はあくまで予想に過ぎないのだ。

では、愛知万博の入場者数はどうか。愛知万博自体、ソフトウェアではないわけで、2対8の法則を当てはめるのは無茶なのだが、話の種のつもりで計算してみよう。

目標の1500万人というのをさばくためには、どの程度の人数が入れないといけないのか考えてみる。1500万人を185日間でさばくのだから、185日のうち2割は37日、この日数に1500万人の8割、1200万人が来るとすると、1日約32万人、ということになる。この程度を想定すると、混雑したときでも大丈夫、ということになりそうだ。

もっとも、実際に会場展示を行う場合には、いろいろ別の状況も考えることになる。たとえば、輸送能力を超えた人数は絶対に来るわけがない。また、Webサイトの場合には、ピーク時にも大丈夫という設計が必要になるのだが、展示会場が必ずしもそうすべきだとは限らない。実際、10万人を超えない日が半分ほどあったわけで、1日に30万人入れるようにするのはコスト的に無駄だ、という考え方もあるのだ。実際は、会場内に17万人というのが full になる目安らしい。多分、この種のイベントに適切なモデルを使って計算したのだろう。

まあもう一つだけ一般論としていえそうなのが、終了間際は混雑する、という法則である。最終日は30万人を超えるのではないか、と想像してみたのだが、さて、実際はどうなるだろうか。

「情報の私物化の禁止」「情報の取捨選択は閲覧者が行う」という標語にはピンと来るものがある。私がNIFTY-Serve にプログラマーズフォーラム (FPROG) というコミュニティを立ち上げたのは、1988年のことだ。パソコン通信というサービスがあった時代のことだ。今月末で、@nifty 上でのプログラマーズフォーラム は消滅するが、このフォーラムというのは管理者にとって、「情報の私物化」との日々の戦いの場だったのである。

(※ なお、ここで言う「私物化」というのは情報を誰にも使わせない、という意味のソレではなくて、公共のスペースを私用に使ってしまうという方向の話なので、紹介したブログの話とは微妙なずれがあるのでご注意いただきたい。)

掲示板に来る人達は、基本的に、自分の興味のあることを自分の扱える範囲内で書こうとする。大勢が共有する場所だから、できるだけ多くの人に興味を引くことを書いてもらえるとベストなのだが、世の中そう甘い訳がない。話題が一般的なものになるとは限らないし、むしろ、内輪話になることが非常に多い。

今でこそ、インターネットに常時接続で固定料金という時代になったが、当時は1分いくらという制度で料金が取られるシステムが当たり前だったのだ。コンテンツにどの程度の有益な情報が含まれているかは、オーディオの用語を流用して、S/N比と呼ばれている。内輪話が多いというのは、S/N比が低いということになる。その場合、「金を払ってゴミを読ませるのか」と管理者が怒られる程度ならまだいいのだが、最後は誰も見に来てくれなくなる、というのが一番怖い。つまり、「ここは見る価値がない」と利用者が判断するのである。

では、どうやって掲示板を私物化させないか、多くの人に興味のある状態を保つにはどのように電子会議をリードすればよいか、というあたりが SYSOP のノウハウなのだが、それはおいといて、今回書きたいのは、今はインターネットが普通にある時代だということである。今のような時代では、むしろ、どんどん好きなことを勝手に書いてしまうというスタイルもアリではないか、ということが言いたいわけだ。

これはある意味、ネットの私物化なのである。結果的には私物ではなくて共有物に間違いないのだが、共有スペースだというのを意識するのではなく、インターネットに出ている情報は全部オレのもの、という感覚で使ってしまうのがミソである。

もちろん、公共性の高い掲示板でそういうことをすると、いくら情報の読み書きのコストが低くなったといっても、顰蹙を買うことは間違いない。そういう常識が必要な場では、それなりのネチケットが必要なのだ。逆に自分で開いたブログなんかだと、自分しか読まないメモ帳のつもりでどんどん書いてしまった方がお互いのためになることもあるんじゃないか、という程度の話をしているのである。今更言わなくても、こういうのは前世紀から言われていたことだが。

そういうことで、近藤氏がブログで「どうすれば興味のある話だけを読む仕組みが作れるか、と考えるべきで、どうしたら興味の無い話を書く社員の口をふさげるか、を考えてはいけない」と主張しているのはもっともで、激しく同感なのだが、ただ、そのためにどういう戦略を使えばいいか、と考え始めると、これは難問どころではない。

ちなみにフォーラムではそれをどう解決していたかというと、当時はネットで情報を探すにしても、対象となる場が少なかったから、まず場を決めておいて、そこからノイズを除くという戦略で何とかなったのだ。Web の場合、場の広さが尋常じゃなく広大なので、ノイズを除くよりも、有効なコンテンツを探す方が大変になる。まずそこから何とかする必要があるのだが、google のような検索エンジンであれ、はてなのような人が介したシステムであれ、やはり「必要な情報がなかなか見つからない」というのが現状のような気がする。

一つはっきりしていることがある。この難問を解決するためには、コンピュータは絶対に必要だ。そして、よいソフトも必要になる。それだけは間違いない。

CNET Japan Blog に「近藤淳也の新ネットコミュニティ論」というブログがある。割と面白いと思って読んでいたりするのだが、今回は、その中から「情報の私物化を禁止する」という記事に関して思ったことを書きたい。

前半は読んでいて結構びっくりした。どこにびっくりしたかというと、要するにコードを再発明するな、というようなことが書かれているのだ。これを最初に読んだとき、今は1970年なのか、と思ったのだ。

コードの再利用なんて話はパソコンがなかった時代から問題になっていた話で、どうすればいいのかという方法論も、専門家が熱く議論し尽してきたのものであって、当たり前というか、先人の知恵を拝借すれば今更考える必要もない話なのである。ただ、当時と違うのは、ブロードバンドで世界中が接続されているという現時点の環境だ。これによって何が変わるのか、という話が出てくるのかと思ったら、そうでもないので、かえってびっくりしたのである。思わず「はてな?」と考え込んでしまった。

北風と太陽という話をご存知だろうか。というと「失礼な」と言う人もいるだろう。この話を知らない人は日本では殆どいないと思う。では、その話を活かしているかというと、私は自信をもって「はい」と言うことができないのだが、この話の教訓は要するに「力で片付けるのでなく問題を解決しろ」ということだろう。

例えば、「自分のパソコンにコードが全て入っている」という状態には、確かになりがちである。ただし、それには原因がある訳だ。履歴管理用のサーバがないというのは論外としても、仮にソース管理のツールを入れておいても、コードは check out してローカルファイルを作業したりすると、その中間物が他から見えないということがある。意外とこの中間物に宝があったりするものだ。

では、ファイルシステムを共有して、ローカルにはファイルを置かせないようにすれば問題は解決するのか?見かけ上は解決するかもしれないが、それが北風流のやり方にならないように気をつけるべきだ。共有できないからしていないのか、それとも「したくない」という別の理由があるのか、ということである。

例えば、作業中のコードは見せたくないという人もいるのである。極端な話すぎるかもしれないが、「他の人が見るのならこの書き方はやめておこう」というような判断もあるかもしれない。実際、こう書いたらアノ人が何か言ってくるだろうからヤメ、みたいなことはない訳ではない。共有を意識して、コードがアグレッシブになれないとか、チャレンジングな処理が書き辛い、程度で済めばいいが(よくないけど)、おかしなフィルタがかかってしまうと、チームが妙な雰囲気になったりすることもあって、なかなか一筋縄ではいかないような気がする。

「ソフトウェア開発 = プログラミング + コミュニケーション」であると思う。

プログラミングのスキルは、プログラムを書きまくればある程度身につくが、チーム開発の場合は、プログラミングがうまいだけではゴールにたどり着けない。このコミュニケーションのスキルの一つが「情報の共有化」なのだ。今「スキル」と書いた通り、まさにこれは技能であって、誰でも最初から簡単にできる性質のものではない。まず、情報をどうやってうまく共有するかという技術を身に付ける必要がある。

近藤氏いわく、「情報共有に対する前向きな姿勢や理想像が必要」ということで、これは全く同感なのだが、問題は、どうすればそれが得られるか、ということなのである。実際は、そこが非常に難しい。

情報共有のシステムを作ることはもちろん重要だが、それだけにこだわりすぎて、何か本質的なことを見失ってしまわないように、気をつけなくてはいけないと思う。ツールはコミュニケーションの助けにはなるが、ツールがあればうまくコミュニケーションできる、というような安直なものでもないのである。

(つづく)

訂正 200メガ → 2メガ

テーマ:

U「違うファイルに自動的に同じ名前をつけてはいけない、というアレに、200メガピクセルというのはスゴイぞ、という趣旨のコメントをいただきましたが。」

ふ「はい、スゴイです、FOMA ですから…って違う罠。」

U「こっそり直しておきました。まあそれはそうとして、なぜ2メガと200Mを間違えたのか、というのが気になりますね。「メガ」と「ギガ」を間違える、というのは結構あるのですが、2と200を間違えるというのは?」

ふ「200万画素、というのを間違って200メガ、と書いたのかな? という可能性が高いです。」

U「ところで、コメントには、ハッブルに積まれているのより解像度は高そうだというご指摘【謎】があったのですが。」

ふ「流石に200万画素だとスゴイので、というか、ハッブルの公式サイトで調べてみました。当たり前のように英語なのですが、Glossary のところに、Charge-Coupled Device (CCD)、という項目があって、640,000 pixelsのCCDを4つ使っている、と書いてあります。」

U「ということは2,560,000 pixels ですから、FOMA のソレと実はそんなに変わらないんですね。」

ふ「getしたデータを画像処理して見かけ上の解像度を上げたりしているのかもしれませんが、意外と普通なのですね。」

U「当時としては最先端だったのではないかと思われます。ハッブル宇宙望遠鏡の後継が、もっとスゴイのを積む予定らしいです。」

20050915-01

昼飯を食べるために、とある店に入った。初めての店なのだが、味とかは結構気に入った。食べたのはカレーうどんである。辛口を頼んだら本当に辛くて涙が出るというレベルだったが、味はよかったので吉。

カレーうどんだけでは物足りないので、ついでに白飯を頼んだ。というか、セットメニューとして用意されている。ラーメンライスというのは割と定番のメニューだと思うが、うどんとライスとか、そばとライスというと違和感のある人がいるらしい。焼き蕎麦とライスとか。私は大阪育ちのせいか、そういうのはごく普通の現象として自然に受け入れているのだが、まあその話はおいとく。

このセットが、Gセットなのである。セットはAからGまであるのだ。ということで「Gセットください」と行ったのだが、3回か4回「Cセットですか、Gセットですか」と質問された。しつこい。Gセットというのはセット系では一番安いので、間違ってCを買わせるという作戦なのかと勘繰った位だが、これは単にCとGが聞き分けにくいだけの話だと思う。

聞き分けにくいから聞き返すというのも間違いではないが、こういう場合は、聞き分けやすいようにメニュー項目を選択するものである。例えば G は欠番にして H にしておけば、まず聞き間違いはないはずなのだ。

コンピュータのプログラミングでは、I と 1 とか、0 と O とか、間違ったら大変困ったことになるので、こういうのは間違いそうな所では使わないのが基本である。パスワードやID にも、この種の文字は使わないようにすることがある。電話でID をたずねるときに、ゼロとオーを間違った、というようなことがあると人件費が無駄になるばかりである。