二人は昼も夜も聖書を読んだ。だが私が白と読んだところをあなたは黒と読んだ。

ウィリアム・ブレイク

久しく更新してなかったこのブログですが、久々に更新です。更新しなかった理由、、というわけでもないのですが、今年の4月から仕事でドイツにしばらく住んでます。ドイツは、ヨーロッパの中では日本と国民性も近いし、治安もいい、アウトバーンや鉄道も発達しているので、どこへ行くにも便利。料理は、、、まぁ南欧の国に比べたら落ちるかもしれませんが、素朴でおいしいです (^^)。ということで、非常に快適な国なのですが、唯一の問題は言葉の壁、つまり「ドイツ語」です。ということで、久々のエントリのテーマは「翻訳」です。

幸いにして、ドイツの方、特に都市部の人達の多くは、英語が結構堪能なので、英語さえ多少話せれば、ドイツ語はしゃべれなくても生活にはそれ程困りません。とはいえ、仕事柄、ドイツのニュースやネットを検索して情報をとったりする必要があります。この時、単語単位で調べてたら日が暮れますので、大抵翻訳ツールのお世話になります。市販ソフトもありますが、onlineで無料のものがありますので、そちらを利用します。有名なのは、Excite翻訳やGoogle翻訳でしょうか。使われてる方も多いと思います。

しかし、この翻訳サービス、残念ながら日本語版の翻訳精度はあまり良くなく、あまり評判は良くありません。全く使えないとまでは言わないものの、結構愉快な結果が得られます (^^;)。
特にgoogle翻訳での、日本語訳は、かなりとっぴなものになりがちですが、この理由は、Google翻訳が他の翻訳エンジンのようにルールベースではなく、統計的学習手法をベースにした手法のためです。

・Google翻訳 よくある質問
・Google翻訳が面白すぎる件 (Cozy Ozy)

しかし、この統計的学習手法は、逆にGoogle翻訳の強みでもあり、マニアックな単語や固有名詞、時事的な単語を、わりと正確に訳してくれることもあります。例えば、日本語と英語では、その代わり、相当マニアックな訳もしてくれます。いくつか例を挙げます。

(英) Yukio Hatoyama -> (日) 鳩山由紀夫 (漢字!!)
(英) Nobi Nobita -> (日) 野比のび太 (こちらも有名人)
(英) hanshin tigers -> (日) 阪神 (タイガースは冗長とのこと)
(英) Astro Boy -> (日) 鉄腕アトム
(英) miku -> (日) 初音ミク (全国のミクさん可哀想・・)
(英) karoshi -> (日) 過労死 (今や世界共通語)
(英) I'm sorry -> (日) ごめんね (ちょっとフレンドリー..)
(英) Hey! -> (日) おい!
(英) Hey!! -> (日) ちょっと! ("おい!" < "ちょっと!")

なんだか、前ふりが長くなりましたが、このGoogle翻訳は、決して誤訳を楽しむだけのものではありません。かなり実用性があります。
特に、実力を発揮するのが、二つの言語構造が似ていて、且つどちらもメジャーな言語の場合です。具体的には、英語、ドイツ語、フランス語、イタリア語、スペイン語、あたりでしょうか。特にドイツ語と英語だと、同じ西ゲルマン語群で文法構造も似ているので、学習精度も高いのでしょう。実際、ドイツ語のニュースや記事をGoogle翻訳で独->英翻訳して読んでいますが、だいたい意味は分かります。例えば以下のような感じです。

・ Wikipedia - Hanshin Tigers (独->英翻訳)
・ Wikipedia - Hanshin Tigers (独->日翻訳)

英訳時の精度の高さがよく分かります。もちろん不自然な言い回しはどうしても出てきますが、私はあんまり気になりません (自分の英語能力が高くないおかげもあると思いますが.. :-P)。 上の例でも分かるように、欲張って、日本語訳まで期待すると、かえって訳がわからなるので、英訳で止めておくのがポイントです。
他の言語のページもたまに読みますが、英訳までで止めておけば結構使えます。もし、英語以外の言語のページを参照しないといけないという方は、ぜひお試し下さい。Google翻訳の真の実力が分かりますよ。

(補足) よく使う方に向けには、ブックマークレット(bookmarklet)が (翻訳ブラウザ ボタン)

【関連記事】
・googleを電卓として使う
・検索力

【関連書籍】
・翻訳に役立つGoogle活用テクニック 安藤進
・Google Hacks 第3版 ―プロが使うテクニック & ツール 100選 山名早人
・Spidering hacks―ウェブ情報ラクラク取得テクニック101選 村上雅章

過ぎ去りしことは、過ぎ去りしことなれば、過ぎ去りしこととして、そのままにせん。

ホメロス - 『イリアス』

サンクコスト (sunk cost) という単語を耳にされたことはあるでしょうか。日本語では「埋没費用」と訳されます。Wikipediaを見ると、「事業に投下した資金のうち、事業の撤退・縮小を行ったとしても回収できない費用」と説明されています。マーケティング用語ですが、今回は、ソフトウェア開発におけるサンク・コストとその対応について少し考えます。

サンク・コストのわかりやすい例としてよく用いられるのが映画館の話です。これまた、Wikipediaからひっぱってきましょう。

ある映画のチケットが1800円であるとする。しかし映画が余りにもつまらない時、1800円払った映画を見るべきか、それとも映画館を出て残りの時間を有効に使うかが問題となる。

• 映画を見るのを止めた場合：チケット代1800円は失うが、上映時間を有効に使うことができる。
• 映画を見続けた場合：チケット代1800円に加え、約2時間（上映時間）を失う。

この場合、チケット代1800円が埋没費用となる。この埋没費用は、どの選択肢を選んだとしても回収できない費用である。そこで時間を浪費してまで、つまらないと感じる映画を見続けることは合理的な選択とはいえない。残りの上映時間を有効に使うことが合理的な選択となる。

あるソリューションの開発に巨額の投資をしてきたが、他社がそれを大きく上回るソリューションを提供してきた。今の開発を続けても勝ち目はない。それでもとりあえず開発を完成させるべきか、それとももう一歩のところとはいえ、ここできっぱりやめるべきか。こういう事業判断もそうですね。
ついつい「せっかくここまでやったのだから。。」という考えをしてしまいがちですが、どちらにせよ過去の投資は返ってこないのだから、それらはサンク・コストとして考えてはいけないはずです。冷静に考えて見ればあたり前の話ですが、人間心理としてついついサンク・コストとこれからの投資を混同してしまいがちです。今までやってきたことを「無駄」だったと認めることは、精神的にはつらいところですからね。しかし、それは仕方のないことなので、きっぱりあきらめることが肝心です。

先の例は、事業判断の話になりますが、開発の現場でも同じような話があります。で、よくある話としては、初期の設計がまずい、あるいは、担当者のスキル不足から「こりゃ作り直した方が早いな」というケースです。こういう場合、「せっかくここまで作ったんだから」あるいは「この人もせっかく慣れてきたところだし」ということで、結局そのまま作り直さないでいることがありますが、この時サンクコストに囚われていないか判断が必要です。本当にその判断が正しいであれば、「せっかくここまで」というサンク・コストは無視して、今を基準にした判断が必要です。

こう書くとと、「問題がでたらすぐにあきらめましょう」と誤解されるかもしれませんが、そうではありません。それまでに払ったコストは返ってきませんが、そこで得られた経験はあるはずですので、それは考慮すべきです。これらは今後の投資額に利いてきます。 それに、プログラマという人種は「作り直し」が好きなので、本当に作り直した方が早いのかは、よく考えた上で判断する必要がありますね。
また、方針転換でリソース再分配する際には、部分最適だけに走って、プロジェクト全体のクリティカルパスに影響を及ぼしたり、長期的に無理が生じるようなことのないようにもしないといけません。

何にしても「引き時」というのはほんと難しい。それを痛感する今日この頃でした ^^;

【関連記事】
・手堅い見積もりが遅れを生む - セーフティの弊害
・このバグ直しますか? - 原因療法と対症療法

【関連書籍】
・サンクコスト時間術 (PHPビジネス新書 66) (PHPビジネス新書 66) 斎藤 広達
・ソフトウェア開発者採用ガイドJoel Spolsky 青木 靖
・図解 実戦マーケティング戦略 佐藤 義典
・ソフトウェアプロダクトライン―ユビキタスネットワーク時代のソフトウェアビジネス戦略と実践 前田 卓雄

規矩作法 守り尽くして 破るとも 離るるとても もとを忘るな

千利休

人気blog「分裂勘違い君劇場」の記事「中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント」という記事が注目エントリになっています。ということで、ひさびさにコメントがてら投稿したいと思います。

• 分裂勘違い君劇場
  中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント

あげられているのは、次の三つ。

• 「変数のスコープは狭いほど良い」と妄信する
• 「同じロジックのコードを2度以上書くな」と妄信する
• 「プログラミング言語を極めるのが大切」と妄信する

いつもながらにいかにも議論を呼びそうな内容です ^^;。既に多くのコメントが寄せられていますが、一言で言えばケースバイケースということにつきます。何にでも例外がありますからね。この辺、言うまでもなく「適切な」判断が一番なのですが、そうはいっても、初心者にとってその判断はなかなか難しい。そこで、「スコープは狭く」とか「コピーはだめ」とかいうコーディングルールになってしまいます。
但し、あくまでこれは「基本」であるということを忘れてはいけませんね。それを忘れて妄信する人はたしかに多いです。そういう人の中では、手段と目的が入れ替わっています。「手段」を妄信するあまり、いつの間にか「目的」の方が「手段」を正当化するための「手段」になっています。まさに本末転倒です。

さて、この手の話でよく引用されるのが「守破離」とう言葉。茶道や武道で用いられる上達に至る経緯を表した言葉です。「守」は、師についてその流儀を習い、その流儀を守って一般的には、「守」の段階ではまず型に従うことに徹して技を磨き、「破」ではその型を破ることで自分の型を見出し、「離」の段階で、元の型から離れ独自の境地に達する。 本質を端的に表した言葉ですが、これを実践するのはなかなか難しい。特に、ステップ移行のタイミング。早ければ独りよがりになり、遅すぎればいつまでも進歩しない。そうならないためには、自分の得意分野をひとつは持ってそれを極めつつ、視野を広くもって周りにも目を向ける。局所最適を防ぐにはほどよいノイズがあるくらいが調度よいものです。

【関連書籍】
・プログラミング作法 Brian Kernighan Rob Pike
・チェンジ・ザ・ルール！ 三本木 亮
・組込み現場の「C」プログラミング 標準コーディングガイドライン 福田 晃
・改訂版 組込みソフトウェア開発向けコーディング作法ガイド[C言語] (SEC BOOKS)
・武士道 (岩波文庫) 矢内原 忠雄

【関連記事】
・過学習と局所解
・このバグ直しますか? - 原因療法と対症療法
・ルールを破る時のルール

【関連リンク】
・ソフトウェア開発の守・破・離

人は誠実な批評よりも心にもないお世辞を好む。

プラトゥス

設計レビューやソースコードレビューといったレビューは、ソフトウェアの品質確保だけでなく、開発者のスキル向上のためにも非常に有意義です。このレビューを有意義なものとするために心がけてべき最も重要なことのひとつが、
「自分の書いたソースコードや設計書に対して客観的であること」
です。簡単そうで、これがなかなか難しい。

人間、自分で作ったものは愛着が出ます。これはソースコードも同じ。エレガントなモデル設計やスマートなアルゴリズムに仕上がったものは誇らしいけど、混乱した設計や実装も、こんなはずじゃないんだ、分かっているんだとかばいたくなる。なので、人からつっこまれると、ついつい、ソースコードの味方をしてしまうことがあります。これは、ちょっと過保護で、ソースコード君のためにはなりません。

では、客観的な立場に立てているどうかはどうやったら分かるでしょうか。ひとつの方法は、「レビューの指摘に対して、ソースコードを書いた本人が嫌な気分になるかどうか」で分かります。人の書いたソースコードレビューでは、気になった点をどしどし指摘するし、人の意見にも「うんうん」とうなずくのに、いざ、自分のソースコードの時には、ついつい守りに入っている、そんな経験ないでしょうか (私はあります ^^;)。自分のソースコードであっても、人のコードと同じような気分で、レビューに望めるようになれば、かなり客観的になれていると言えるでしょう。

レビューに関しては、「責める」のではなく「褒める」とことが大事だという意見もあります。確かに、自分の書いたコードや設計が褒められるのは悪い気はしません。褒められて伸びるというのも否定しませんが、そこで喜ぶのはその成果物を客観的に見れていないということです。「褒める」という行為によって、自信をもたせることもひとつ重要な点だとは思いますが、悪い点はそこそこに、良い点ばかりを見るように仕向けるのは決していい方法とはいえません。

「プラス思考」「ポジティブ・シンキング」という言葉があります。この言葉を「いいように考える」という意味で使っている間は、決してスキルアップはありません。マイナス面に目をつむって、いい部分だけ見ていては、それ以上の改善はありません。「いいように考える」のではなく「よくするように考える」、悪い点があるのなら、そこをどうやっていい方向に持っていくかを考える、守るだけでなく攻める、そういう姿勢が重要です。批判は単に「耐える」ものではありません。素直に受け入れてそれを力に変えることが重要です。レビュアは敵ではないんですからね。

なお、レビュアの方も単に攻撃してやろうという気持ちだけではいけません。意見を受け入れられるように的確な対案をまじえながら建設的な指摘する、そういうレビュア側の姿勢も、高品質・高効率なれビューには非常に重要です。

【関連書籍】
・ピアレビュー―高品質ソフトウェア開発のために Karl E.Wiegers 大久保 雅一
・「ほめる」技術 鈴木 義幸
・ソフトウェアインスペクション　Tom Gilb Dorothy Graham 伊土 誠一
・ソフトウェア・レビュー技術―基礎から実践までのノウハウ　織田 巖
・ピープルウエア 第2版 − ヤル気こそプロジェクト成功の鍵　トム・デマルコ ティモシー・リスター

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

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

ウォルト・ディズニー

昨日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. ノーマン
・アフォーダンス-新しい認知の理論　佐々木正人

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

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