ディズニーランドはいつまでも未完成である。現状維持では、後退するばかりである。

ウォルト・ディズニー

昨日WBSでのサービス業におけるサービスのありかたについての特集がありました。サービスの基本は、お客様の視点に立ち、それを徹底して実践すること。それを実践している代表格がディズニーランドです。
WBSの中でもいくつか紹介されていたのですが、特に感心したのが、ディズニーランドの水飲み場の話。ディズニーランド内の水飲み場は、親用と子供用の二つがセットになっており、子供用のものは踏み台があるんだそうです。なぜ、そういう形をとっているかというと、親子で水を飲んだ後、ふと顔をあげた時に目線があうようにしているため。アイコンタクトを演出することで、水飲み場でさえもふれあいの機会に変えてしまうという発想には感動しました。ディズニーランドが、ユーザー体験をいかに大切に考えているかということを如実に表しています。

さて、その他、ディズニーランドには様々なこだわりが存在します。トリビアっぽい話ですが、少し紹介します。
※ よせあつめなので、もし誤りがふくまれていればご指摘下さい m(_ _)m

■ ミッキーは世界に一人?
やや都市伝説的な風もありますが、ミッキーマウスは同時刻に同じ場所に決して現れないという話が時々聞かれます。いろいろ調べると、実際、以前はそうなるように秒単位のスケジュールを組んでいたようですが、さすがに、全世界でそれを実現するのは難しいのと、ミッキーになかなか会えないという不満もあって、最近はそこまでは徹底されていないようです。特に、最近では、いつでもミッキーに出会えるミッキーの家・ミートミッキーというアトラクションもあるようですし。ちなみに、この件については、ミッキーは魔法使いの弟子なので、瞬間移動や分身の術が使えるからという説明がなされているそうですが ^^;)
ということで、完璧ではないものの、そこまで考えて夢をこわさないでおこうという徹底ぶりはすごいです。

■ 立ったまま掃除
ディズニーランドのカストーディアル(清掃担当のキャスト）は、地面の拭き清掃する際は、地面にふきんを置いて、それを足で踏んでふきます。正直行儀悪く見えますが、これは手で拭くためにしゃがんでしまうと、お客さんの視野から消えてしまい、ぶつかってしまう危険性があるためだそうです。
ディズニーランドではSCSEというキーワードで、SAFETY［安全性］、COURTESY［礼儀正しさ］、SHOW［ショー］、EFFICIENCY［効率］が重視されています。優先度はこの順。よって最も重要なのがSAFETY[安全性]です。足での拭き掃除はこの安全性追及を徹底した結果なのです。

■ いらっしゃいませは使わない
ディズニーランドでのお出迎えのあいさつは「いらっしゃいませ」ではなく「おはようございます」「こんにちは」「こんばんは」。この理由は、コミュニケーションを生み出すため。「いらっしゃいませ」といわれても「いらっしゃいました」とは返答できないからということだそうです。なるほど。
逆に、コンビニ等でよく明らかに形式的な「いらっしゃいませ」を聞くことがありますが、個人的にあれは非常に苦手です。形式的なものならないほうがいいです。あいさつはコミュニケーションの第一歩ですからね。

■ 日常的なものみせない
鏡や時計は現実を思い出させるのでなるべく目立たないように。スタッフの移動やバックヤードはゲストの目に付かないようにできるだけ隠す。ホテルの高さも視界を遮らないように高さ制限がある。迷子アナウンスも基本的になし (これはちょっと心配になる人もいるようですが、キャスト(従業員)が多いので、基本キャストに聞けば迷子センターにつれていってくれるので大丈夫なんだとか)。日常的に非日常を作り出す努力を惜しまないということが徹底されています。

■ 清潔へのこだわり
ディズニーランドの清掃へのこだわりはすごい。常時300人ものカストーディアルが働き、ゴミ箱も10m置きに設置。そのゴミ箱はポスト風でとてもきれい。人間、きれいなものを汚すにはやはり抵抗がありますから、きれいにすればするほど、自然とゲスト側も清潔さを保つよう気をつけるようになるんですね。

私の場合、組込みエンジニアという職業柄、直接お客様と出会う機会はあまり多くありません。しかし、ものづくりも「もの」を媒体としているだけで、一種のサービス業です。直接的ではなくとも、いろいろ考えさせられます。何より、その徹底ぶりに感嘆します。

いいわけなしは気持ちがいいですね。

【関連記事】
・先味・中味・後味

【関連書籍】
・ディズニー7つの法則―奇跡の成功を生み出した「感動」の企業理念　Tom Connellan 仁平 和夫
・東京ディズニーランド「継続」成長の秘密―“ディズニー的”教育訓練の底力　小松田 勝
・リッツ・カールトンが大切にする サービスを超える瞬間　高野 登
・商売心得帖 (PHP文庫)　松下 幸之助

仕事を追え。仕事に追われるな。

ベンジャミン・フランクリン

年々仕事量が増えてきて、どんどん忙しさは増してくる。原因は、次々とふってくる仕事。こなしてもこなしても、空いたスペースに仕事が入ってくる。。。

私自身そうですが、業界問わずよくある話だと思います。仕事がもらえるのはありがたいとは言えるのですが、こんな時は、ついつい「やらされている」という意識をもってしまいがちです。既に十分すぎるほど忙しくて余裕がない時に、新たにたのまれた仕事などは特にそうでしょう。しかし、仕事に対する意識が「受身」になると、モチベーションもさがってしまいまい、効率も非常に落ちてしまいます。

「やらされている」という意識の裏には「こんな仕事やりたくないのに」という思いがあります。やりたくないのだからモチベーションなんてあがるはずもありません。しかし、同じ仕事でも、その時自分に余裕があれば、積極的にヘルプにまわることだってあるのではないでしょうか。例えば、人のデバッグ手伝うとか、危機に陥ったプロジェクト立て直すとか。こんば時は、「やりたくない」というより、むしろ「やってやる」「面白い」という思いになります。

そう考えると、結局のところ、仕事のモチベーションを決定付けるのは、「仕事の内容」ではなく「気持ちの持ちよう」です。課題が「与えられた課題」「受動的な課題」であればしんどいが、「自発的な課題」「能動的な課題」であれば楽しい。なので、「受動的な課題」を「能動的な課題」として再定義できれば、モチベーションもあがります。「これこれをしないといけない」ではなく「これをやってやろう」。そうすると、そこに工夫もうまれ、面白みもでます。守りから攻めに。攻撃は最大の防御です。射撃しつつ前進あるのみ。

第一流されててはつまらない。自分発でないと面白くないですからね。

[後記] エントリ名長ったらしかったので変更 ^^;

【関連書籍】
・ピープルウエア 第2版 − ヤル気こそプロジェクト成功の鍵　トム・デマルコ ティモシー・リスター
・プロ論。 B-ing編集部
・プロジェクトX リーダーたちの言葉 今井 彰

【関連リンク】
・ルールを破る時のルール
・射撃しつつ前進 - Joel on software

紳士淑女をおもてなしする私たちも紳士淑女である。

リッツカールトンのモットーより

外食産業では、「先味」「中味」「後味」という３種類の味わいがあると言うそうです。
先味とは、食事の前に感じるお店の雰囲気だとか接客だとか。中味は食事の内容そのものと食事中の雰囲気。後味は食後の対応や記憶に残るもの。この中で何が一番大事かと言えば、「後味」がやはり一番大事だということ。最初は最も見えにくいものですが、最後には最も印象に残る部分ですもんね。

商品開発にあてはめれば、「先味」がプレゼンテーションやマーケティングによる「ほしい」「使いたい」「楽しそう」と思わせるアピール、「中味」は買ったとき、使っているときの楽しさ、「後味」は保守サービスやサポートにあてはまるでしょうか。
Appleなんかはこの中の「先味」がとっても上手。「中味」がいくら素晴らしくてもまずは手にとってもらわないとわからないですもんね。ちょっと毛色は違いますが、通販のジャパネットタカタも「商品によって生活がどうかわるか」を前面に押し出したセールストークになっていてなるほどと思わせるのが上手です。これに対して後味は商品購入前にはなかなか見えてこないものですが、実際のユーザー満足を決定付ける重要な要素です。

ソフトウェア開発に関してもそれは同じ。本当の品質は保守段階になってはじめて見えてくるものが多いもの。作り手としての責任でもありますしね。

【関連書籍】
・リッツ・カールトンが大切にする サービスを超える瞬間　高野 登
・なぜみんなスターバックスに行きたがるのか?
Scott Bedbury 土屋 京子

【関連リンク】
・ほぼ日刊イトイ新聞 - おいしい店とのつきあい方。

偉大な企業はすべてを正しく行うが故に失敗する

クレイトン・クリステンセン - 『イノベーションのジレンマ』

任天堂社長「ゲームの敵だったお母さんが買ってくれれば」
http://www.asahi.com/kansai/news/OSK200801030061.html

少し前の記事ですが、任天堂岩田社長がWiiやDSのヒットについて語ったインタビュー記事です。『誰からも嫌われない存在』をねらったDS、そして、『みんなで囲む』というスタイルを提案するWii。なるほど。。高い演算能力やグラフィック性能を進化させたPS3とは、本当に対照的です。
この対比を見るとやはりクリステンセン氏の「イノベーションのジレンマ」の話が頭をよぎります。「イノベーションのジレンマ」とは「顧客の意見に熱心に耳を傾け、新技術への投資を積極的に行い、常に高品質の製品やサービスを提供している業界トップの優良企業が、その優れた経営のために失敗を招き、トップの地位を失ってしまう。」そんな逆説的なコンセプトを論理的に解き明かしたベストセラーです。ブログをはじめ各所で絶賛されたり、引用されたりしていますので、ご存知の方も多いでしょう。詳しくはWebを調べるといろいろと情報が出てきます (例えばこちら)。私も始めて読んだ時は衝撃を覚えました。

さて、今更ですがWiiとPS3の関係をこの「イノベーションのジレンマ」に当てはめて考えて見ます(新しくもないですが)。この場合、いわゆる業界の先端を行っていた優良企業はSONYであり、商品はPlayStationになるでしょう。初代PSからPS2,PS3への高性能化はコアなユーザーニーズの声を真摯に受け止めて、それを実現してきた結果です。そして、それは成功してきました。それに対して、任天堂のDSやWiiは、演算能力で言えば、SONYのPSPやPS3からすると、一世代前になります。技術的にみれば時代遅れの代物です。しかし、DSやWiiには従来とは違う「ユーザーインターフェース」がありました。これも技術的には決して新しいものではありませんが、これをゲーム機としてパッケージングして、それに見合ったソフトとともに世に出してきました。そして、これが今までのゲームユーザーとは違った層に爆発的ヒットにつながりました。まだ、PS3を食い尽くすほどではありませんが、確実に従来のPSユーザーも大勢さらったでしょう。この場合「ユーザーインターフェース」というのが「破壊的イノベーション」の核になっています。

このような状況をして、よく「ゲームの概念を変えた」「ゲームの枠を広げた」という評価のされ方もありますが、個人的には、従来あったものを変えたというよりは、別のものを新たに作り出したという方が正しいと思っています。実際、このまま任天堂商品がPS3の牙城をも飲み込むことはないでしょう。土俵が違います。PS3のような高性能化路線を望むコアなユーザーは大勢いますし、それらのユーザーからみればWiiはおもちゃに見えるでしょう。少なくとも今は。しかし、その性能差が見えない大半の一般ユーザーにとっては、PS2->PS3の連続的変化よりは、PS2->Wiiの不連続な変化の方が刺激的で魅力的なものに見えるでしょう。

私もゲーム業界ではないですが、大勢の方に使われるような民生機の開発に携わっています。製品を使うお客さんは最新技術に精通した人からお年寄りまで様々です。そんな中、DSやWiiの成功の過程からは学ぶべきことは大変多く、自分達の置かれた状況を考えるに危機感を覚えます。しかしながら、PS3に見るような実直な進化もまた必要な要素ではあります。マスは少なくとも、コアなユーザーの声もやはり重要ですし、とがりをさらにとがらせるということは競争の激しい業界を勝ち抜くためには必要です。問題は、それがお客さんのニーズから薄利して技術競争・開発側の独りよがりにならないことでしょう。

多角的視野と深堀りのバランス、そして既成概念にしばられすぎないこと。改めて自戒をこめて。
イノベーションのジレンマの続編(『イノベーションへの解』、『明日は誰のものか イノベーションの最終解』)も出ているので読んで見ようかな。

【関連書籍】
・イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき クレイトン・クリステンセン
・イノベーションへの解 収益ある成長に向けて クレイトン・クリステンセン マイケル・レイナー
・明日は誰のものか イノベーションの最終解 クレイトン・M・クリステンセン スコット・D・アンソニー
・あの商品は、なぜ売れたのか 杉村 貴代
・プレステ3はなぜ失敗したのか? (晋遊舎ブラック新書 002) 多根 清史
・ニンテンドーDSが売れる理由―ゲームニクスでインターフェースが変わる サイトウ アキヒロ 小野 憲史

【関連記事】
・できることが増えると、できないことが増える

【関連リンク】
・図解、イノベーションのジレンマ - Life is beutiful

間違ったコードが間違って見えるコーディング規則を探すこと。

Joel Spolsky

プログラミングにおける変数や関数、クラス設計の命名というのは、そのプログラムの可読性を左右する最も重要な要素のひとつです。変数名や関数名が適切であれば、プログラムの流れも読みやすいですし、バグがあっても見つけやすいものです。
さて、このような命名規則(命名規約)といったものは、大抵それ読む人間のために設定されます。コンパイラにとっては、変数名がoldUserNameだろうがounだろうがxだろうが、関係ありません。変数名は単なる記号です。

しかし、考えて見るとこれは非常にもったいない。人間が、変数名からエラーを発見できるということは、このルールを(広い意味での)コンパイラに教えてあげれば、同じようにエラーを発見してもらえるのではないでしょうか。

例えば以前に次のようなバグコードを見たことがあります。

  ....
  len = strlen(name);
  strncpy(buf, name, sizeof(len));
  ....

ひとめで何がおかしいか分かるでしょうか。答えは、strncpyにsizeof(len)を渡しているのが間違い。sizeof(buf)のような与え方をすることも多いので、うっかり間違えたのでしょう。このようなコードは人間がよく見ればわかりますが、コンパイラにとっては何が間違いかはわかりません。C言語上の型チェックとしては、どちらもsize_tが渡るので問題ないと解釈されてしまいます。よって、この問題をコンパイラがコンパイル時に(静的に)発見することはできません。

ということで対策案。上の例でいえば、いたって単純な方法が考えられます。まず、lengthのようなものをsizeofでサイズ取得するというのは、あまりなさそうです。よって、sizeof(len.*)というパターンをソースでgrepしてみると。ものすごくピンポイントな対応ですが、このパターンでみつけられバグは結構ありそうに思います。

ようは、命名規則がきまっていれば、単なる記号論理だけでなく、意味論までふみこんだ静的解析ができるんじゃなかろうかと。アプリケーションハンガリアンと呼ばれる変数の意味的な側面に注目してプレフィックス等の命名ルール呼ばれる命名規則を決める手法(参考：間違ったコードは間違って見えるようにする - Joel on Software)がありますが、これも人間に臭うコードが見えるようにするというだけではもったいない。ある程度ルールを決めれば、コンパイル時点でCPUに検出させることもできるのではないかと思うのです。

例えば、次のようなものもうまくやれば検出できそうです。

/* database中のoldをnewに置き換え */
void replace(DB* db, const char* old, const char* new);
...
  replace(db, new, old);
  ....

プロトタイプでは、newもoldも同じ型ですが、プロトタイプの変数名を見ればold->newの順番だとわかります。ところが、通常のコンパイラでは、上のようにnewとoldがいれかわっていても検出することはできません。おそらく人間でも直感的には間違いに気が付きにくいと思いますが、これもせっかくの仮引数名を利用してやれば、何とか検出できそうです。

意味論の解釈というのは難しいとはいえ、発想自体は単純な話ではあるので、すでにいろいろツールありそうに思って探したのですが、見つかりません。CheckStyleのような命名規則をチェックしてくれるものがあるので、これをカスタマイズすればできるのでしょうか。単なる規約以上は無理なのか・・

ご存知の方おられたらぜひ教えてください m(_ _)m。

【関連記事】
・変数の命名規則
・テキストとしてのコーディング規約
・コンパイル時の静的チェック(STATIC_ASSERT)
【関連書籍】
・Joel on Software Joel Spolsky 青木 靖
・組込みソフトウェア開発向けコーディング作法ガイド[C言語版] SEC
・C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス ハーブ・サッター他
・リファクタリング―プログラムの体質改善テクニック
・プログラミング作法

【関連リンク】
・間違ったコードは間違って見えるようにする - Joel on Software
・ハンガリアン記法 - 悪態のプログラマ

デザインはわがまま→思いやり

川崎和男　『ドリームデザイナー』

最近はユニバーサルデザイン(UD)という言葉を良く耳にするようになりました。はてなキーワードの説明では、『ユニバーサル＝普遍的な、全体の、という言葉が示しているように、「すべての人のためのデザイン」を意味し、年齢や障害の有無などにかかわらず、最初からできるだけ多くの人が利用可能であるようにデザインすること。』となってます。つまり、全ての人にやさしいデザインということになるでしょうか。
この「ユニバーサル」つまり「全ての人に」という部分は非常に重要な考え方だと思いますが、やはり人によって得手不得手がありますので、ものによっては、どうしてもこっちを立てればこっちがたたずといった状態になります。こうなると、どこを立てるか、つまり、どんな評価関数でもって最適化をかけるかということが重要になります。

さて、こんなことを書いているのは最近Gコードの構成についてなるほどーっと思ったのがきっかけです。

Gコードといえばテレビ番組の予約等で使われる数桁の数字。新聞のラテ欄やTV雑誌でおなじみですね。といっても、最近は、EPG搭載のデジタルTVやDVD/HDDレコーダが普及して、あまり使われなくなった感がありますが。さて、Gコード、原理的には、数文字の数字に、番組の開始・終了日時、チャンネル情報を符号化したものになっています。ですので、この数字を対応のVHSビデオやDVDレコーダに入力すると、これら予約録画に必要な情報に変換して、予約録画ができるという仕組みです。

はてさて、このあたりまでは使われたことがある方ならご存知かもしれないのですが、今回私がなるほどと思ったのは、この数字の符号化方法にあります。Gコードの数字列は可変長コードになっているのですが、この数字列、ゴールデンタイムの番組、つまり視聴率の高そうな番組程短くなるように符号化されているのです。いわゆる、エントロピー符号化というやつです。時には、一文字のこともあるそうです(※1)。知ってました？
つまり、Gコードの符号化設計における評価関数はユーザーの予約頻度なんですね。

で、ここでふと思ったのは、「では、今のGコードの符号化って本当に使われ方に対して最適化されているの？」ということ。実際の仕様は公開されていませんが、個人で解析されている方の情報等をみると、結構こったことになっているようですが、そもそもいろんな趣向を持った人がいるのに、最適化ってどうするのだろうという疑問。
まず単純に考えると、時間帯や番組長、チャンネル等で予約頻度順に符号長も短くなるようにするという方法。つまり、世の中の全予約の平均長を短くするという方針。単純に考えるとこうなるのでしょう。多分Gコードもそういう考え方がもとになっているのだと思います。
しかし、よく考えれば、Gコードを使う人って機会慣れした若者から不慣れなおじいちゃん、おばあちゃんまでいろいろおられるはず。となると、「各番組の予約頻度」×「その番組の視聴者層の機械慣れ具合」といった重み付け後の値でもって最適化を考えないといけないのかとかも考えられます。
いやいや、そもそも機械慣れしているなら少々数字が多くても大丈夫だから、この層は一旦おいておいて、おじいちゃん・おばあちゃん層の番組の最適化を進めるというのもひとつの考え方としてあるだろうとか。。
考え出すとこれがなかなか奥が深い。

プログラミング時には、アルゴリズムの性能指針として、平均オーダーと最悪オーダーが使われます。平均と最悪、どちらが特に重要かは、ユースケースによってかわってきます。この考え方は、ユーザビリティを考える時もこれは同じ。先の例では、全番組予約頻度で符号化長を調整するのは平均値の最適化。おじいちゃん・おばあちゃん優先で最適化するのが最悪値の最適化といえなくもないでしょう。
自分自身ふりかえると、大抵の設計時には、ついつい平均値優先になっていたなぁという気がします。きっと、その方がわかりやすいからでしょう。

冒頭の「デザインはわがまま→思いやり」というのは、デザインディレクター 川崎和男氏の言葉。『考具―考えるための道具、持っていますか?』という本の中で紹介されていたので知ったのですが、とても大好きな言葉です。ユーザビリティは、単純に数学的に最適化できるものではありません。最後のまごころ忘れちゃいけませんね。

※1 2005年6月1日放送のNHKきょうの料理では、一部新聞でGコードが「1」と掲載されたため、同番組の出演者が珍しく「当番組をぜひ見てほしい」と宣伝した事もあるんだそう。

【関連書籍】
・誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)　ドナルド・A. ノーマン
・ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン　ヤコブ・ニールセン
・アフォーダンス-新しい認知の理論　佐々木正人
・暗号解読 上巻 (1) (新潮文庫) サイモン・シン 青木 薫

【関連記事】
・できることが増えると、できないことが増える
・プログラム+インターフェース=モジュール
・似て非なるインターフェース
・選択できない選択肢

【関連リンク】
・Ｇコード解析(analyzing VCR-plus code)
・ユニバーサルデザイン - コクヨ
・Webデザイン・Webデザイナーのまとめサイト | Webデザインに優れたサイトのリンク集
・ヤコブ・ニールセンの考えをまとめたユーザビリティガイドライン
・Jakob Nielsen博士のAlertbox
・楽天はデジタル家電の新製品を随時ご紹介

楽しい顔で食べれば、皿一つでも宴会だ。

ブルデンチウス

百式管理人さんのブログIDEA*IDEAでの企画『画期的な食器を考えた！』が面白そうだったので、参加してみます。募集の内容は以下の通りです。

あなたはフォーク、ナイフ、スプーン、箸に続く画期的な食器を思いついてしまいました。またたくまに全世界で広く認知されるようになったその食器について以下のことを教えてください。

■ 画期的な食器の詳細
以下のA、B、Cにあてはまる語句を考えてください（回答必須）。
その食器はみんなが食事中になんとなく感じている（A）という問題を、（B）することで解決していました。その食器の名前は（C)。

食事中になんとなく感じていること。。うーん、なんだろう。いろいろありますが、今回取り上げたのは「別のおかずにかけたソースが、となりのおかずを侵食してしまう」という悩み (^^)。一つの解として、区切りが入ったランチプレートのようなもの(例えばこれ)もありますが、区切りが固定されるために盛り付けの自由度がないという欠点があります。それに、あまりおしゃれじゃないですよね。ということで、盛り付け方の自由度や、盛り付け後の雰囲気を損なわないようにしながら、この課題を解決する方法はないものかというのがテーマ。

で、そのアイデアですが、上の文章にあてはめると、

その食器はみんなが食事中になんとなく感じている「ここにソースかけたらとなりのおかずまでソース風味になっちゃうかな」という問題を、「盛り付けられたおかず周辺のソースの流れをコントロールすることで、ターゲットのおかずにソースを集中させる」することで解決していました。その食器の名前は「低反発でおかずもあなたも快適プレート」。

以下がその図です。

従来のお皿との違いは表面の低反発層です。
図のようにこのお皿に盛り付けられたおかずは、表面の低反発層によってつつみこまれます。ポイントは、やわらかすぎず硬すぎない低反発素材を用いていますので、ソースが流れ出ないように表面を沈み込ませるものの、へこみ感はあまり目立たないので、見た目も損なわない。また、ソースをかけると、そのソース自体の重みによって、指数関数的に、ソースの流れができあがるあたりは。まさに重量場を彷彿させます。

ということで、つっこみどころ満載ですが、まぁ、頭の体操ということでご愛嬌。それにしても名前がいまいち (^^;)

おまけとして、簡単にボツネタも少し。

• ごはんとおかずの三角食べをサポートする「ほっとけない君」
  
  • ごはんだけ残ったりしないように、おかずがへると警告するためのもの。
    各食器にセンサーを搭載して、おかずの消費具合を通信して、バランスを監視。
• おいしさのピークをどこへもっていくかサポートする「食べごろ君」
  
  • 大好きなおかずを食べるべきタイミングをお知らせするお皿。
• 食事中の会話をもりあげる「ネタふり君」
  
  • 話題がとまったときのネタふりサポート。カニなべ等でついつい食事に集中してしまいがちな時や、気まずい雰囲気になった時の会話のきっかけ作りに大活躍。

食事のおいしさを決める一番の要素は、やっぱり「場」の雰囲気なので、対応案はともかく、やっぱりいかに楽しく食事するかと決めるのが一番大事だなとは思います。まぁ、上の案がいいかはともかくとして (^^)
考えて見ると、自分がいる業界に関して、こういったアイデア出しはするももの、食器とか生活に直結しているんだけど、仕事とはあんまり関係ないものって、結構考える機会が少なかったので、仕事のブレーンストーミングもたまには、こういうテーマでやってみようかな。

ちなみに最近の食のマイブームは、ミルクシーフードヌードルと卵かけご飯専用しょうゆ。どちらも新鮮 ^^)

[追記]
IDEA*IDEAさんの方で、結果発表がありました(ブロガーが考える「画期的な食器とは？」（百式ポイント企画結果発表）)。なんと! 3位に選んでいただきました。ありがとうございます!
他のみなさんの案もどれも面白いかったですし、さらに何より感心したのはみなさんほんとに図解が上手なこと！やっぱ図解力は大事ですねぇ。

【関連書籍】
・アイデア×アイデア 田口 元
・考具―考えるための道具、持っていますか?　加藤 昌治
・イノベーション・シンキング ポール・スローン
・DESIGN IDEA BOOK―すべてのクリエイターのためのデザイン・アイデアブック MdN編集部
・ネーミング発想法 横井 惠子

【関連リンク】 ・「介護施設にだまされるな！」ブロガー応援企画＆新企画・・・(IDEA*IDEA)
・『秘伝すごい会議』プレゼント企画！(IDEA*IDEA)

科学はやはり不思議を殺すものではなく、不思議を生み出すものである。

寺田寅彦

技術の進歩は、人々の生活を便利にしますが、必ずしも豊かにするとは限りません。言い尽くされたことですが、「便利」=「満足」とはいかないためですが、今回は、はこのあたりについてちょっと考えて見ます。

きっかけは、「便利になるとストレスが上昇する」という不思議なジレンマ (Life is beautiful)という記事です。携帯電話などの普及で、いつでもどこでも連絡がとれる環境が整ってきたものの、かえって連絡がとれないという不満を感じる機会が増えているという話です。電車や、パソコンの起動時間などの対する待ち時間に対する感覚も同じような話で、以前よりはよくなっているはずが、使う人の感覚のほうがより「せっかち」になり、かえってストレスが増大しているというデータがあるようです。おそらく大半の人が思い当たるふしがあるのではないでしょうか。私の場合、実家の田舎に住んでいたころは、バスが2時間毎とかなので、30分待ちなんて「おぅ、ぴったり」くらいにしか思っていませんでしたが、それが今や10分待ちでも、「ちぇっ」と思うようになっています。(^^;)

さて、ストレスというのは、「何ができるか」とはあまり関係なく、「何ができないか」によって感じるものだと思います。ですので、この問題は、表現を変えると次のように言えると思います。

• できることが増えると、できないことが増える
• できないことが増えると、ストレスが増える

前半部分は、矛盾しているような言い方ですが、もう少し分解すると、以下のようになります。

• 「できること」が増えると、「できそうなこと」が増える
• 「できそうなこと」 - 「できること」が、新たな「できないこと」として増える。
• 「できそうなこと」はどんどん増える。
• 「できることは」その内当たり前になって、「当たり前のこと」になる。
• その結果、以前より「できないこと」が増える

ちょっと、極論も入っていますが、こういったケースは多いでしょう。人が持っている要望というのは際限がありませんので、要望に答えることが、新たな枝葉の要望を生んでいくのです。

では、このような状況にならないように、もっていくことはできないものでしょうか。サービスや製品を設計する上で、考えておいた方がいいことはないのでしょうか。少し考えて見ます。

ひとつには、実際「できないこと」が「できそうなこと」に含まれていることです。メールの例で言えば、「いつでもメール送受信できるんだから、すぐに返信がくるはず」といった期待が「できそうなこと」ですが、実際そんなことはありません。つまり、できるはずのないものが「できそうなこと」として認識されてしまっています。では、どうすれば良いのでしょうか？例えばですが、メールを読んだかどうか確認できるもっとスマートな方法があれば、まだ相手が読んでいないのかどうか確認できるので、少しは不満もやわらぐのかもしれません (あくまで例です。そんな簡単な話でないのは分かっていますが・・)。ということで、まずは、必要以上の期待を抱かせないというのがまずひとつのポイントでしょう。

もうひとつは、「できそうなこと」が「できるはず」になっているということ。そのため、「できそうなこと」-「できること」が「できないこと」になってるんじゃないかと思います。ですので、「できそうなこと」を「できたらいいな」というかたちに置き換えられれば、「やりたいことができない使えないもの」ではなく「夢を与えてくれるもの」という位置付けになるんじゃないかと。。うまく表現できませんが、妙な期待を抱かせてはいけないとはいえ、将来の可能性は感じさせたいという感じです。(うーーん、表現がおかしい。。。)

無理やりまとめると、

• 実際にできるというような間違った期待を抱かせない
• ・それでいて、将来に対する夢はあたえてくれる

というかたちにもっていければいいなと。理想論かもしれませんが、意識としてもっておきたいと思います。とりあえず、デザインレビュー時のチェックリストに入れておこうかな。

【関連書籍】
・イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき クレイトン・クリステンセン
・ウェブ進化論 本当の大変化はこれから始まる 梅田 望夫
・誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)　ドナルド・A. ノーマン
・アフォーダンス-新しい認知の理論　佐々木正人

【関連記事】
・できそうでできない - 後だしジャンケンの心理学
・選択できない選択肢
・プログラム+インターフェース=モジュール

【関連リンク】
・【溶けゆく日本人】快適の代償（１）　待てない人々　数分間でイライラ

僕が生まれたこの島の唄を 僕はどれくらい知ってるんだろう
トゥバラーマもデンサー節も 言葉の意味さえわからない
でも誰より 誰よりも知っている 祝いの夜も 祭りの朝も
何処からか聞えてくるこの唄を

BEGIN - 『島人ぬ宝』

cd, pwd, ls, rm, mv, ln, du, df, man, grep, cat, ps, dd, sed, ....

UNIX系の代表的なコマンド(プログラム)達ですが、UNIX/LINUX系を使うプログラマやサーバ管理者以外の人から見ると、意味不明のアルファベット列ですよね。
さて、私も普段からお世話になっているこれらのコマンドですが、それぞれの名前の由来はと聞かれると、以外と知らないものです。または、知っていると思っていても、意外に間違っていたり、いろんな説があったり。。
例えば、スーパーユーザーになる時のコマンドsu。これも何の略かとか改めて考えたことはなかったのですが、以前にせつないぶろぐさんの記事でsubstitute userの略だと初めて知りました。多分、この記事読む前に人に聞かれたら、私もsuper userって答えていた口でしょう(^^;)。これって有名なのかな。(もう少し調べると、昔は確かにsuper userだったのが、途中で変わったらしいです(参考：what do you know 'su' means?))。

ということで、いくつかコマンド名の由来を挙げてみました(コマンド名じゃないのもありますが)。まぁ、名前の由来なぞ知らなくても何も困りませんが、知っておくと案外役にに立つこともあるかもしれませんよ :-P。

ls	wikipediaを見ると、list segmentの略となっていますが、多分単にlistの略がもとでしょうね。手持ちぶたさになると意味もなく打ってしまいます。。DOS窓でも打っちゃいますね (^^;)。 そういえば、lsのjokeコマンドでslというのがありますが、昔会社のサーバに入れて怒られていた人がいました ^^;
su	本文中でも紹介した通り、substitute userの略。私自身もsuper userと思い込んでました。調べると、昔はsuper userだったのが、途中で任意のユーザへの切り替えをサポートした時点で、語源までさしかわってしまったようです。(参考：what do you know 'su' means?) 語源が後付けされるというのは他でもよく見かけますね。
cat	concatinateの略。ファイル結合に使うより、小さいファイルの内容をダンプしたり、パイプ処理の途中でよく使われますので、元々の語源は知らない人もいるんじゃないでしょうか(私自身、最初はダンプコマンドだと思ってました・・)。
dd	「Convert and Copy」としたかったが、既にccはC-compilerにとられていたので、仕方なくddにしたという説が有力らしいです。回避方法がハッシュ値の衝突みたい。
grep	行指向のテキストエディタedのコマンド"g/RE/p"(Global Regular Expression Print)が由来。今や完全に一般名詞化してます。
less	moreの逆でless。こういうネーミング遊び心があって好きです。
ping	潜水艦のソナー音から来ているという説が有力なもよう。となると読み方は「ぴん」の方が正しいのかな。個人的には「ぴんぐ」ですが。
C言語	B言語の次だからC。この辺は有名ですかね。そういえば、D言語結局はやらなかったな。。
C++	Cの拡張ということで、Cにインクリメント演算子をつけてC++。ネーミングセンスは好きですが、何分読みにくい。普段は「しーぷらぷら」もしくは単に「ぷらぷら」と読んでますが、、、なんだかちょっとかっこわるい。とはいえ、C++大好きです。
X	MITで開発されていた「W」というWindow Systemの次ということで「X」。C言語と同じ発想。
awk	作者の、Aho, Weinberger, Kernighan の3人の頭文字をとったもの。このネーミングに開発者の頭文字をつなげるという方法はよく使われます。RSA暗号なんかもそうですし。 なお、発音しにくいですが「おーく」と読みます。awkは未だに時々使います。特にawkに詳しいわけでもないし、awkでないといかんというわけではないんですが何となく。
perl	The Practical Extraction Report Languageの略。その他、Perlの作者であるラリー・ウォール氏によれば､Pathologically Exlectic Rebbish Lister(異常に折衷主義的ながらくた生成プログラム）ということらしいです。どちらにせよ、pearl(真珠)とは関係ないようです。
ruby	perl(pearl:6月の誕生石)の次でruby(7月の誕生石) ということのようです。これもC言語やX Windowと同じ系統ですね。
/usr	誰しもまずは"USeR"の略と思うところですが、ところがどっこい、米国のユーザグループ UniForum が発行している機関誌 CommUNIXations(May/ June 1989) からの転載ということで、 JUS の /etc/wall No.8/1990/May に載っていた「UNIX Trivia -- UNIX に関するクイズ100問」によると、 "User Services and Routines" の略だそうです。これは意外!!
emacs	私も愛用のエディタ、というかIDEですね。語源はEdit MACroSというのが有力。その他諸説ありますが、詳細は$EMACS/etc/emacs.namesを参照。

もっといろいろ知りたい方には、新版 UNIX 由来/読み方辞書)等が詳しいのでそちらを参照下さい(本記事の中の多くはこちらを参考にしています)。また、UNIX系以外の一般的な語源については語源由来辞典のようなものもあるようです。
語源といっても今となっては、真相がはっきりしないものもありますので、中には都市伝説的なものもあるのかもしれません。まぁ、その辺はあまり気にせず、あくまでトリビアということで :-P。

■関連書籍
・Linux コマンド ポケットリファレンス 沓名亮典 平山智恵
・語源を楽しむ―知って驚く日常日本語のルーツ 増井金典
・英語の語源の話 - 楽しみながらボキャブラリーが増える 佐久間治
・トリビアの泉〈第1巻〉―へぇの本 フジテレビトリビア普及委員会
・プログラミングテクニック―UNIXコマンドのソースコードにみる実践プログラミング手法) 多治見寿和

■関連記事
・商標の話
・間違えやすい日本語

■関連リンク
・新版 UNIX 由来/読み方辞書
・カーソルの語源は？　意外と知らないパソコン用語 (ZDNet)
・Linux はリナックス、それともリーナックス？ (japan.internet.com)
・語源由来辞典

古人の跡を求めず､古人の求めたるところを求めよ。

松尾芭蕉

私の場合、電車の中では読書、駅までの徒歩時間はipodが通勤時のお供になっています。本は通勤時間以外はほとんど読まないのですし、速読ができるわけでもないですが、積もり積もれば結構本は読んでる方かもしれません。

さて、ちょっと前に話題に、これを読んでおくと読書スピードが速くなる。自己啓発書編。ついでに知的生産編 (俺と100冊の成功本)という記事が話題になっていました。
こちらの著者の方は、ものすごい勢いで本を読まれていますが、そのコツというか理由のひとつが、

• 大抵の本には引用等で重複するところがある
• すでにその話を知っていれば、その部分は読み飛ばせる。
• だから、多くの本で引用されるような書籍を押さえておくと、他の本も早く読める

という話。確かに一理ありますね。
ということで、ここでは、自己啓発書の定番書籍として「人を動かす」「7つの習慣」「思考は現実化する」他数冊が紹介されています。これらを読んでおけば、他の自己啓発書を読む時の基本知識になるということですが、何より良い書籍なので、とにかく読んでおいて損はないでしょう。私もいづれ読もうと思っていて結局読んでいなかった書籍なので、これを機会に読み始めました。

さて、私の場合、上のような自己啓発書も読みますし、小説やノンフィクションも読みますが、仕事柄ソフトウェア開発関連の書籍を読むことが多いです。では、ソフトウェア開発関連の場合、どういった本が定番なのでしょうか。私自身ソフトウェア開発本はいろいろと読んでいるので、いくつもおすすめしたい本はありますが、今回は「ソフトウェア開発の名著を読む (技評SE新書 003)」という本を紹介します。古今東西のソフトウェア開発の名著から８冊を選んで紹介している書籍です。新書なのですぐ読めますし、手軽です。
この本は古典を読む際のカタログ・道しるべとしても有用ですが、この本自体、名著とされる書籍の内容からかいつまんだエッセンスが書かれていますので、基本的な考えを知る上で非常に有益でしょう。

さて、この本で紹介されているのは８冊で、それぞれ概要は以下の通り。

■ プログラミングの心理学―または、ハイテクノロジーの人間学 ジェラルド・M. ワインバーグ
ソフトウェア開発の人間的側面に初めて正面から取り組んだ、ワインバーグの古典的作品。

■ 人月の神話―狼人間を撃つ銀の弾はない フレデリック・P. ブルックス
見積もりとスケジューリングの単位のしての「人月」の危険性を指摘した不朽の名著

■ ピープルウエア トム・デマルコ ティモシー・リスター
ソフトウェア開発における人間的側面を重視し、人間中心に考えることとの大切さを説く

■ デッドライン―ソフト開発を成功に導く101の法則 トム・デマルコ
人間中心のプロジェクト管理について、デマルコが小説形式で表現した異色の作品

■ ソフトウェア職人気質 ピート マクブリーン
ソフトウェア開発を「工学」ととらえることをやめて、「職人気質」という基本に回帰せよと提唱する

■ 達人プログラマー―システム開発の職人から名匠への道 アンドリュー・ハント
「割れ窓理論」「ＤＲＹ原則」など、実践的なプログラマーとなるためのアドバイスを網羅

■ Code Complete ― 完全なプログラミングを目指して スティーブ・マコネル
より優れたコードを書くためのガイドラインを提供する、プログラマー必読の書

■ プログラミング作法 ブライアン・カーニハン ロブ・パイク
プログラマーにとって基本的かつ不可欠なことが述べられているが、すべてマスターしている人は意外に少ない

どの本も、特定のプログラミング言語に特化した話や細かいテクニックについて書かれているようなものではなく、ソフトウェア開発あるいはプログラミングに共通した内容になっています。分野によらず、今からプログラマを目指そうという人はもちろん、経験を積んだ技術者にも非常に有用な内容です。「ピープルウエア」等は、現場のプログラマだけでなく、むしろマネージャレベルの人に読んでいただきたいものです。

ちなみに、実際、私が通読したことがあるのは、「ピープルウエア」だけで、他の本は、直接読んだことはありません。しかし、その内容はいろんな書籍で引用されていますので、この本で紹介されていたような内容は、直接読まずとも知っていました。そういう意味では、先にこれらの本を読んでいれば、他の本を読んだりするときの理解の助けになったのかなとは思います。

なお、当たり前ではありますが、別に「本を早く読むこと」自体に価値はありません。その内容を理解し、実践することが大切です。私自身もそうですが、「ふむふむ」というのは誰もが感じることですが、なかなか実行にまで移す人は少ないものです。まずは実践。多くの本を読むよりは、そのほうがよっぽど大切です。

ちなみに、プログラマの場合は、技術書だけでなくソースコードを読むことも大切なスキルアップの手段です。同じように、定番のソースコードなんかもあるとは思いますので、また紹介できたらよいなと思います。まずは、LinuxやBSDのカーネル、Apache/X Windowなんかの有名どころのオープンソースが定番なのかな。おすすめあったらコメントやTBででもぜひ教えて下さい。

【関連記事】
・C++関連書籍

【関連書籍】
・ソフトウェア開発の名著を読む (技評SE新書 003) 柴田芳樹
・改訂新版 コンピュータの名著・古典100冊 石田晴久 青山幹雄 安達淳
・SEの読書術―「本質を読む」力を磨く10の哲学 浅海智晴/荒井玲子/後藤大地/柴田芳樹 他
・Code Reading―オープンソースから学ぶソフトウェア開発技法 まつもとゆきひろ 平林俊一
・ソースコードリーディングから学ぶ Javaの設計と実装 WINGSプロジェクト 佐藤匡剛 山田祥寛

【関連リンク】
・これを読んでおくと読書スピードが速くなる。自己啓発書編。ついでに知的生産編 [俺100]
・人力検索はてな - あなたが読んでためになった、またはプログラマなら読んでおくべきだと思うソースコードはなんですか？

良い結果をもたらす嘘は、不幸をもたらす真実よりいい。

ペルシアの諺

すっかり暑くなってエアコンが恋しい季節になってきました。この季節になると、毎年話題にあがってくるのが省エネや環境問題、エコといった話。去年はクールビズがずいぶんとはやりました(私はもともとスーツ着る機会が少ないので、伝聞状態でしたが)。今年はどうなんでしょう。

さて、環境問題というと、少し前に「環境問題はなぜウソがまかり通るのか」という本が話題になっていました。関西のTV番組 たかじんのそこまで言って委員会でとりあげられたのがきっかけで、かなり売れたようです。その内容は、官主導のリサイクル運動が隠してきた非効率性と利益誘導の実態をあばくというもの。例えば、

• 地球が温暖化しても、海の水位は上昇しない
• 猛毒に仕立て上げられたダイオキシン
• 回収されたペットボトルはほとんどがリサイクルされていない

等など。実際に読んではいませんが、TVやレビュー記事なんかをみると衝撃の内容。聞いたことのある話もありますし、ちょうど最近「古紙100%再生紙は環境にやさしいはウソでした」のような話もありましたし、ある程度は真実なのでしょう。でも、この手の本の常として、扇動的で行き過ぎた論調になっている部分もあるのでしょうね。反論されている方もおられます。

・『環境問題はなぜウソがまかり通るのか』のウソ

常識をくつがえすような内容というのは読んでいて面白いのですが、手放しで信じるのは、結局危険かなと思います。でもまぁ、今の環境政策には何かしら問題はあるのは間違いなさそうですので、いいきっかけにはなったんじゃないかなとは思います。
ちなみに、この本の内容がどうであれ、環境について何も考えなくていいということはありません。日本が欧米に比べてましであっても、環境が確実に壊されているのはまぎれもない事実でしょう。そんな中で、ちょっとした意識をもって行動するだけでも、それが積み重なれば大きな効果になります。リサイクルなんていわなくても、ちょっと水を節約する、エアコンの温度をしぼるなんてことでも十分です。というのは、自分に言っているのですけどね ^^)

さて、前ふりだけで終わりそうですが、もともとはソフトウェア開発と環境問題について書こうと思ってました (^^)。ものづくりで環境というと、例えば、省電力だとか材料の選択だとかハードウェア的な話が中心で、ソフトウェアはあまり関係ないのかなと思われることもあります。
しかし、組込み機器等では、ソフトウェアのつくりによって、省エネになったり、材料がへったり、あるいは製品が長持ちしたりということにはつながります。例えば、次のようなもの。

• メモリ効率のよいプログラム設計により搭載メモリが減る
• ハードウェアアクセスを最小限にして、必要最低限の電源供給におさえる
• ソフトの起動速度を向上させて、電源をこまめにきれるようにする

このような製品自体の環境性能を向上させる以外にも

• 開発プロセスを改善して開発効率をあげる。これで作業時間が短くなり、開発にかかるエネルギーを削減する
• あるいは、それを実現するようなソフトや製品をつくって、ユーザの活動エネルギーをおさえる

なんていう考え方もありますね。特に、後者はものづくりを通じてユーザの利益を最大化する、と同時に環境にとっての利益も最大化するということで、エンジニアにとっての基本姿勢です。
嫌々仕事にせず、まずはいいものをつくる。これこそ一番のエコ活動なのかもしれませんね。

最後にひとつHPを紹介。去年も紹介したEcotonoha。今年もやっています。素敵です。

【関連記事】
・ペーパーレス - 電子化からもう一歩

【関連書籍】
・省メモリプログラミング―メモリ制限のあるシステムのためのソフトウェアパターン集 James Noble
・組込みソフトウェア開発向けコーディング作法ガイド[C言語版] SEC BOOK
・組込み現場の「C」プログラミング―基礎からわかる徹底入門 SESSAME
・ハッカーのたのしみ―本物のプログラマはいかにして問題を解くか Henry S. Warren
・環境問題はなぜウソがまかり通るのか 武田 邦彦
・不都合な真実 アル・ゴア 枝廣淳子

【関連リンク】
・Ecotonoha (エコトノハ)

過失は恥じるべきだが、過失を改めるのは恥じるべきではない。

ルソー

「ファイルが添付されてませんが。。」
メールの添付忘れは嫌なものです。私も時々しでかしていましたが、最近特に連続したので、今更ながら対策を考え始めました (^^;)。

「