このページはハイパーコンテンツビルダーが 2007年 10月 09日 16時55分36秒 にクロールしたキャッシュ情報です。

検索キーワード＝ ダイエット
優先キーワード＝

間違っとは？

[ 113] スタートアップを始めない理由が間違っている理由
[引用サイト]　 http://www.aoky.net/articles/paul_graham/notnot.htm

私たちはY Combinatorを十分長くやってきたので、成功率について話せるくらいデータがたまった。最初に投資をした2005年夏のグループには8つのスタートアップがあった。現在ではそのうちの少なくとも4つは成功しているようだ。この中の3つはすでに買収されており、Redditは2つの会社、RedditとInfogamiが合併したものだ。3番目のやつについてはまだ買収先を話せない。最後の1つはLooptで、これは非常にうまくいっており、その気があれば10分以内に買収先を見つけられるだろう。
だから最初の夏の創業者たちのうちの半分くらいは、2年もしないで金持ちになったことになる。少なくとも彼らの基準で言えば。(金持ちになってみて学ぶことの1つは、金持ちにも多くのレベルがあるということだ。)
私たちの成功率が50%という高い水準を保つだろうとはまだ言いかねる。第1弾は例外だったのかもしれない。しかし成功率はよく言われている(そしてたぶんでっち上げの)数字である10%よりは高いものになるはずだ。25%は楽に狙えると思う。
そして失敗した創業者達でさえ、そんなにひどい目にあったというわけではない。最初の8つのスタートアップのうちの3つは今では死んでいる。2つのケースでは創業者たちが夏の終わりに他の方面に進むことにしたというだけだ。彼らがこの経験によってトラウマを負ったとは思わない。トラウマ的失敗に一番近いのはKikoだろう。創業者たちはこのスタートアップのために丸一年働き、そしてGoogle Calendarによって叩きつぶされた。しかし彼らも結局はハッピーになれた。彼らのソフトウェアがeBayで25万ドルで売れたのだ。エンジェル投資家たちにお金を返したあとでも、彼らの手元には1年分のサラリーくらいのお金が残った。[1] 彼らはそのあとすぐにもっとエキサイティングな新しいスタートアップを立ち上げた。Justin.TVだ。
したがって、数字はさらに衝撃的なものになる。最初のグループでひどい経験をした者は0%なのだ。すべてのスタートアップの習いとして、彼らにはいいこともあり、悪いこともあったが、彼らの中でそれをキュービクルでの仕事と取り替えようと思う者はいないだろう。そしてこの数字はおそらく例外的なものではない。私たちの長期的な成功率が最終的にどんなものになるにせよ、普通の仕事をしていれば良かったと思う者の割合は0%に近いままだろう。
だから私にとっての大きなミステリーは、どうしてもっと多くの人がスタートアップを始めようとしないのか、ということだ。スタートアップを起こす人のほとんどすべてがそれを普通の仕事よりも好んでおり、かなりの割合の人が金持ちになっているというのに、どうしてみんなやりたいと思わないのだろう? 多くの人は、投資のラウンドごとに私たちの元には何千という応募が来ているのだろうと思っているようだが、実際はほんの数百だ。どうしてもっと多くの人が応募してこないのだろう? そしてスタートアップの世界を見ている人にはスタートアップが狂ったように生まれ出ているように見えているのだろうが、必要なスキルを持った人の数に比べればずっと少ないのだ。プログラマの大多数は、大学を出るとまっすぐキュービクルへと向かい、そしてそこに居続ける。
人々はどうも自分の興味に従って行動しているのではないらしい。いったいどうなっているのだろう? この疑問については、答えられると思う。Y Combinatorはベンチャー投資プロセスの最初の部分に位置しているため、会社を始めたいのか確信を持てない人の心理について、私たちはエキスパートなのだ。
別に確信がないことに悪いことは何もない。スタートアップを始めることを考えているハッカーであって、その溝を跳び越えるのにためらいを感じているなら、あなたは大きな伝統の一部なのだ。ラリーとサーゲイはGoogleを始める前に同じように迷っていたし、ジェリーとファイロもYahooを始める前に同じように迷っていた。実際、最も成功したスタートアップの多くは、自信満々のビジネスガイによってではなく、確信のないハッカーによって始められているのだ。
このことの裏付けになる事実がある。私たちが投資した最も成功したスタートアップの人たちは、応募を決めたのが最後の最後の瞬間だったと後になって話してくれた。締め切りのほんの1時間前に決めたという人さえいる。
確信のなさに対処する方法は、その不安をコンポーネントへと分解することだ。何かをするのに気が進まない人の多くは、8つくらいの異なった理由が頭の中に入り交じっていて、どれが一番大きな要因なのか自分でもわかりかねているものだ。その中にはもっともな理由もあれば、実体のない理由もある。しかしそれぞれの要因の相対的な割合が分らなければ、確信がないことが全体として大方もっともなことなのか、それとも大方実体のない不安なのかも分らない。
だからスタートアップを始めるのを躊躇させる要因をすべてリストアップし、どれが本質的なものなのか説明することにしよう。そうすれば創業者になりたいと思う人が自分の気持ちを確かめるためのチェックリストとして使えるだろう。
私の狙いがあなた方に自信をつけさせることであるのは認めよう。しかしこれがよくある自信をつけるエクササイズと違っている点が2つある。1つは私には正直であろうとする動機があるということだ。自信をつけ
させるビジネスをしている人の多くは、あなたがいかにすばらしいかを教えてくれる彼らの書いた本の代金やセミナー参加費をあなたが払った時点で目的を達している。一方、スタートアップを始めるべきでない人たちにスタートアップを始めるように私が勧めるなら、私は自分の生活を悪化させることになる。あまりに多くの人にY Combinatorに応募するよう励ますなら、彼らの応募すべてに目を通す私の仕事が単に増えるだけだ。
もう一つ違っている点は私の姿勢だ。ポジティブになろうとするかわりにネガティブになろうと思っている。私は｢やってみようよ、君ならきっとできるさ｣とは言わない。私はあなたがやろうとしない理由のすべてについて考え、その多くは??全部ではない??無視できる理由を説明する。まず誰もが生まれながらにして持っている理由から始めよう。
多くの人が、自分はスタートアップを始めるには若すぎると考える。それが正しい場合も多い。世界的に見て中央値は27歳くらいだ。だから1/3くらいの人は本当に若すぎると言えるだろう。
若すぎるとはどういうことだろう? Y Combinatorで目指していたことの1つは、スタートアップ創業者の年齢の下限を見出すということだった。私たちには
いつも投資家たちが保守的にすぎるように思えた。彼らは大学院生や学部学生に投資すべきときでも、大学教授に投資したがった。
この範囲を押し広げていく過程で私たちが見出したのは、限界がどこにあるかということではなく、限界が曖昧だということだ。限界は16あたりかもしれない。私たちが18より下の人たちを対象としないのは、彼らが法的に契約を結べないからだ。私たちがこれまでに投資した中で最も成功した創業者であるサム・アルトマンは、当時19歳だった。
しかしサム・アルトマンは例外的なデータポイントかもしれない。彼は19のときでも、内面的には40くらいに見えた。一方で19歳であっても内面的には12くらいの人たちだっているのだ。
ある年齢を超えた人を指す｢成人｣という言葉があるのには理由がある。人が越える境界というものがあるのだ。それは伝統的に21に固定されているが、実際には異なる人は異なった年齢でこの境界を越える。そしてこの境界を越えていれば、年齢に関わりなく、スタートアップを始められる年なのだ。
それはどうすれば分るのか? 大人扱いできるか調べられるテストが2つある。実はこれらのテストの存在に私が気付いたのは、サム・アルトマンに会ってからだ。彼に対していると、何かもっと年長の人と話しているような気がしていた。後になって、自分は何を基準にそう思ったのか疑問を持った。彼が年長に思えたのは何によってなのだろう?
大人扱いのためのテストの1つは、まだ子供のすっぽかしの名残を持っているか見るということだ。小さな子供は、何か難しいことをやるように言われたとき、泣いて｢できないよ
｣と言えば大人はたいてい免除してくれる。子供には魔法のボタンがあって、｢ぼくは子供なんだ｣と言ってそのボタンを押せば、ほとんどの難しい状況から開放してもらえる。しかし成人の場合、すっぽかしは許されない。もちろん相変わらずやる人もいるが、そうすると無慈悲に切り捨てられることになる。
成人かどうか言うためのもう一つの方法は、挑戦に対してどう反応するか見ることだ。まだ成人にならない人は、大人に挑戦されると、彼らの支配を認めるような仕方で反応する。大人が
｢ばかげたアイデアだ｣と言うなら、子供は脚の間にしっぽを挟んで引き下がるか、あるいは反抗する。しかし反抗は従属と同様、下位にあることを意味するのだ。｢ばかげたアイデアだ
｣に対する大人の反応は、相手の目を見て、｢そうですか? どうしてそう思われるんです?｣と聞くことだ。
もちろん挑戦に対して子供じみた反応をする大人はたくさんいる。あまりお目にかからないのは、挑戦に対して大人のように反応する子供だ。そういう人を見つけたなら、その人は年齢に関係なく大人なのだ。
私は以前、スタートアップ創業者は少なくとも23であるべきだと書いたことがある。そして自分の会社を始める前に何年か別な会社で働くべきだと。今ではもうそうは思っていない。私が考えを変えたのは、私たちが投資したスタートアップの例を見てのことだ。
今でも21よりは23の方がいいとは思っている。しかし21歳の人が経験を積む一番いい方法は、スタートアップを始めることなのだ。だから、逆説的ではあるが、スタートアップを始めるための十分な経験がないなら、スタートアップを始めるべきなのだ。これは普通の職に就くよりも、はるかに効果的に未経験を治療してくれる。普通の職というのは、実際にはスタートアップを始めにくくしてしまうかもしれない。働き場所としてのオフィスと、どんなソフトウェアを書くか指示するプロダクトマネージャを必要とする飼い慣らされた動物にあなたを変えてしまうことによって。
このことを私に確信させたのはKikoの創業者たちだった。彼らは大学を出てすぐにスタートアップを始めた。彼らは経験のなさからたくさんの誤りを犯した。しかし1年後に私たちが彼らの2番目のスタートアップに投資する頃には、彼らはものすごく手強い連中になっていた。彼らは間違いなく飼い慣らされた動物ではなかった。彼らが働いていたのがMicrosoftだったなら、あるいはたとえGoogleであったとしても、彼らがこれほど大きく成長することはなかったと思う。彼らはいまだ自信のない下級プログラマでいたことだろう。
だから今では、私は大学を出たらすぐスタートアップを始めるようにアドバイスしている。リスクを取るのに若いときほどいい時はない。確かに失敗するかもしれない。しかし失敗した場合でさえ、就職するよりも早く、究極の目的にたどり着くことができるだろう。
こう言うのは少し懸念を感じないわけではない。実質的にこれは、私たちの費用持ちで失敗を通じて学ぶようにと勧めるようなものだからだ。しかしこれは真実なのだ。
スタートアップ創業者として成功するためには相当な意志が必要だ。これはたぶん成功を占う一番いい指標になると思う。
起業をやってのけられるだけの意志のない人もいる。これは私には確信を持って言うのが難しいのだが、それは私自身ははっきりと意志を持っており、そうでない人の頭の中がどうなっているのかわからないからだ。しかしそういう人がいるだろうことはわかる。
ハッカーの多くは自分の意志を過小評価していると思う。スタートアップの運営に慣れるにつれ、目に見えて意志が強くなっていく人を多く見てきた。私たちが投資した何人かは、最初は200万ドルで買収してもらえたら大喜びというようだったのが、今では世界支配に狙いを定めている。
自分が十分な意志を持っているかはどうすればわかるのだろう? ラリーとサーゲイでさえ、最初会社を始めることに迷っていたというのに? これは推測だが、自分のプロジェクトに取り組むことに十分強い動機づけを感じるかどうかがテストになると思う。ラリーとサーゲイは自分たちが会社を始めたいのか確信がなかったかもしれないが、彼らは指導教官の命令におとなしく従うだけのリサーチアシスタントではなかった。そして彼らは自分のプロジェクトを始めたのだ。
スタートアップの創業者として成功するためには、それなりに頭がいい必要があるかもしれない。しかしそれについて懸念しているようなら、あなたはたぶん間違っている。スタートアップを始められるほど頭が良くないかもしれないと心配しているくらいなら、あなたはたぶん十分頭がいいのだ。
何にせよ、スタートアップを始めるのはそんなに知性を要求されることではない。スタートアップの種類によっては必要となる場合もある。Mathematicaを作るつもりなら、数学で秀でている必要があるだろう。しかし多くの会社はもっと日常的なことをやっており、そこで決定的要因になるのは頭脳ではなく努力だ。シリコンバレーはあなたの見方を歪めてしまうかもしれない。シリコンバレーには頭の良さに対するカルトがあって、頭の良くない人たちでさえ、少なくとも頭が良さそうに振る舞っている。もし金持ちになるには高い知性が必要だと考えているなら、ニューヨークやロサンゼルス
技術的に難しい何かをするスタートアップをやれるほど頭が良くないと思っているなら、エンタープライズソフトウェアを作ればいい。エンタープライズソフトウェア企業というのはテクノロジー企業ではないのだ。彼らはセールス企業であり、セールスでは努力がものを言うのだ。
これもまた、係数が0であるべき変数だ。スタートアップを始めるのにビジネスについて何か知っている必要はない。最初のうちは製品に集中すべきなのだ。このフェーズにおいてあなたが知っている必要があるのは、人々が欲しがるものをどうやって作るかということだ。それに成功したなら、どうすればそこから金を引き出せるか考える必要があるが、それは簡単なことであり、その場になればどうにかできる。
私は創業者たちに、ただ優れたものを作り、金儲けのことはあまり心配するなと、かなりうるさく言っている。そしてあらゆる経験的な証拠が、そのことを示している。人気になるものを作るスタートアップの100%が、そこからどうにかして金を稼ぎ出しているのだ。そして買収者たちが私に個人的に言っているのは、彼らがスタートアップを買うのはその収入のためではなく、戦略的価値のためだということだ。それはつまり、彼らが人々の欲しがるものを作っているから、ということだ。買収者たちはこの法則が彼ら自身にも当てはまることを知っている。ユーザがあなたを気に入っているなら、あなたはどうにかしてそこからお金を得ることができる。そしてユーザがあなたを気に入っていないなら、世界で最も巧みなビジネスモデルだろうと、救いにはならない。
ではどうしてこう多くの人が反論しているのだろう? 1つの理由は、20歳の連中が金にならないクールなものを作って金持ちになるという考えが彼らには気に入らないのだと思う。そんなことが可能であって欲しくないのだ。しかしどれほど可能であるかは、どれほどそうあって欲しいと思うかに依存するわけではない。
感化されやすい若いハッカーを破滅に導く無責任な笛吹男のように言われることをずっと煩わしく思っていたが、今ではそのような議論が起きること自体いいアイデアであることの徴だと思うようになった。
もっとも価値ある真実は、多くの人が信じないような真実なのだ。過小評価されている株のようなものだ。そういうアイデアで始めればその領域全体が手に入る。だから自分ではいいアイデアだと分っているがみんな認めないようなものを見つけたなら、単に彼らの反対を無視するというだけでなく、その方向に積極的に進むべきなのだ。今の場合、それは人気になるだろうが金を得られそうにないアイデアを探すということだ。
あなたが人気になるものを作ったのに私たちがそこから金を得る方法を見つけられないなんてことにはならないよ。賭けてもいい。
共同創業者がいないというのは本当の問題だ。スタートアップを1人で持ちこたえるというのは難しすぎる。私たちは他の投資家たちと多くの点で違った考えを持っているが、この点についてはみんな考えが同じだ。投資家は誰であれ例外なく、共同創業者がいない場合よりいる場合の方が投資してくれる可能性が高い。
私たちは単独の創業者2人に投資したが、どちらの場合も優先度第一のことは共同創業者を見つけることだとアドバイスした。彼らはどちらもそのアドバイスに従った。しかし私たちは彼らが応募する前に共同創業者を見つけておいてくれる方がうれしい。投資を受けたばかりのプロジェクトで共同創業者を見つけるのはそんなに難しくない。それがすごく難しいときにサインするくらいに十分コミットしている共同創業者が望ましいのだ。
共同創業者がいない場合、どうすればいいのだろう? 見つけることだ。これは他の何よりも重要なことだ。あなたが住んでいるところには、一緒にスタートアップを始めようという人が1人もいないというなら、そういう人がいる場所に移ることだ。あなたの今のアイデアでは一緒にやろうという人がいないなら、アイデアを変えることだ。
もし在学中なら、潜在的な共同創業者に囲まれていることになる。大学を出て何年かたつと、探すのはずっと難しくなる。選べる対象が少なくなるだけでなく、彼らの多くは職を持ち、支えなければならない家族さえいるかもしれない。だからスタートアップについてよく話していたような友達がいるなら、極力連絡を絶やさないようにすることだ。彼らが夢を生き続けさせる助けになるかもしれない。
ユーザグループやカンファレンスのような場所で共同創業者となる人に出会えるかもしれないが、私はあまり楽観的ではない。その人を共同創業者にしたいかどうかは、いっしょに仕事してみないと分らないからだ。[2]
このことの本当の教訓はどうやって共同創業者を見つけるかということではなく、スタートアップは共同創業者となるべき人が周りにたくさんいる若いときに始めるべきだということだ。
ある意味で、いいアイデアを持っていないのは問題ではない。それというのも、スタートアップの多くは、どのみちアイデアを途中で変えるものだからだ。Y Combinatorの平均的なスタートアップは、最初の3ヶ月が終わるまでに、アイデアの70%が新しいものになっている。場合によっては100%新しくなっていることもある。
実際、創業者自身が初期のアイデアよりも重要であることを私たちは確信しており、今度の投資サイクルでは新しいことを試みようとしている。全然アイデアのない人にも応募させようと思っているのだ。何をするつもりなのか問う応募用紙に、
｢アイデアはない｣と書いて済ませてもいい。あなたが非常に優れていると思えば、私たちはどのみち受け入れるのだ。私たちはきっと、あなたと一緒に腰を据えて見込みのあるプロジェクトを何か考え出せると思う。
実際には、これは私たちがすでにやっていることを成文化しただけだ。私たちはアイデアには小さな重みしか置いていない。私たちは主に礼儀として聞いているに過ぎない。応募用紙の質問の中で私たちが本当に気にかけているのは、その人がこれまでにどんなクールなものを作っているかということだ。見込みのあるスタートアップのバージョン1を作っているならすごくいいが、私たちに関心があるのは、その人がものを作ることに優れているかどうかということだ。人気のあるオープンソースプロジェクトでリードデベロッパーをしているというのも同じくらいにポイントが高い。
Y Combinatorから投資を受けるのであればそれで問題は解決するわけだが、一般的にはどうだろう? 別な意味では、アイデアを持っていないというのは問題になる。アイデアなしにスタートアップを始めたなら、次にすべきことは何
あなたのためにスタートアップのアイデアを得るための簡単なレシピをお教えしよう。あなた自身の生活に欠けているものを何か見つけ、そのニーズを満たすものを提供すればいいのだ??それがどんなに特殊なものに見えても構わない。スティーブ・ウォズニアックは自分でコンピュータを作ったが、そんなものを欲しがる人が他にもたくさんいると誰にわかっただろう? 狭いが真性のニーズというのは広いが仮想的なニーズよりも、出発点としてはいいのだ。だからあなたの問題が土曜の夜だというのにデートの相手がいないということ
なのだとしても、ソフトウェアを作ってそれを解消できる方法を見つけたなら、何かに行き当たったことになる。同じ問題を持つ人なら大勢いるからだ。
多くの人は増え続けるスタートアップを目にして、｢こんなの続くわけない｣と思う。彼らが暗に仮定しているのは、存在しうるスタートアップの数には限界があるということだ。しかしこれは誤りだ。社員1000人の会社で給料をもらって働ける人の数にそういう限界があると主張する人はいない。それならなぜ、5人の会社を所有して働く人の数に限界があると考えなければならないのか? [3]
働いている人のほとんどすべてが、何らかの必要を満たしている。会社を小さなユニットに分けたところで、この必要がなくなるわけではない。既存の必要は、少数の巨大で階層的な組織よりも、スタートアップのネットワークの方が効率的に満たすことができるだろう。しかしそれは機会が少なくなることを意味するわけではない。現在のニーズを満たすことは、より多くのニーズを生み出すことになるからだ。これは確かに個人に当てはまるし、それで何かまずいことがあるわけでもない。建物全体が年中春のように温められているような、中世の王侯であれば女々しい贅沢だと考えたようなことを、私たちは当たり前のこととして享受している。そしてものごとがうまく進むなら、私たちの子孫は私たちが驚くような贅沢を当然のこととして享受しているだろう。物質的な富に絶対的な基準はないのだ。ヘルスケアというのもその一つであり、それだけで1個のブラックホールを作り出す。今後当面は、人々はさらに多くの富を求め続けるだろう。だから企業に求められる仕事の量に上限はなく、スタートアップでは殊にそうなのだ。
通常、余地がないという俗説は直接的には語られず、｢GoogleやMicrosoftやYahooが買えるスタートアップがそうたくさんあるわけはない｣というような言い方で暗に示される。そうかもしれないが、買収者のリストはこれよりもずっと長い。そして他の買収者はともかくとして、Googleは愚かではない。大企業がスタートアップを買うのは、それが何か価値あるものを作っているからだ。個人が求める富の量に上限があると思わないのに、どうして企業が買える価値あるスタートアップの数に上限があると考えるのだろう? 1つの買収者が飲み下せるスタートアップの数には実際的な上限があるかもしれないが、それが価値あるものなら、即座の支払いの見返りに創業者たちは喜んで上昇過程にあるものを譲り渡し、買収者
これは本当の問題だ。私は家族を持っている人にはスタートアップを始めることを勧めない。それがまずいアイデアだからではなく、やるように勧める責任を負いたくないということだ。22歳の相手にスタートアップを始めるように勧める責任なら喜んで負う。彼らが失敗したらどうするか? 彼らはそこから多くを学び、職が必要であれば依然としてMicrosoftの職は待っていてくれる。しかし私にはおっかさんたちを怒らせる覚悟はない。
あなたにできることとしては、家族があってスタートアップを始めたいなら、コンサルティングビジネスを始めて、徐々に製品ビジネスへと変えていくという方法がある。経験的に言って、その切り替えをやってのけられる可能性はとても低い。そういうやり方では、けっしてGoogleは作れないのだ。しかし少なくとも収入が途絶えることはない。
リスクを減らすもう一つの方法は、自分でスタートアップを起こす代りに、既存のスタートアップに参加することだ。スタートアップが採用する最初の社員の1人になるというのは、創業者の立場にかなり近い。いい意味でも、悪い意味でも。大まかに言って、社員ナンバーnの人は1/n^2くらい創業者なのだ。
これは私がスタートアップを始めない言い訳だ。スタートアップはストレスに満ちている。金に困ってないのに、どうしてそんなことするんだ? ｢連続起業家｣1人につき、
｢また会社を始めるかって? バカ言っちゃいけない!｣というまともな人間がたぶん20人くらいいるはずだ。
私は新しいスタートアップを始めそうになったことが2度ほどあるが、いずれの場合も自分の人生の4年間をめちゃめちゃな苦労で埋めたくないがために引っ込めた。私はこのビジネスのことなら十分よく知っている。生半可ではやれないのだ。いいスタートアップ創業者を危険にするのは、際限のない苦労をよろこんで耐えるということだ。
しかし引退というのにもちょっとした問題がある。多くの人と同様、私は仕事するのが好きだ。そして金持ちになったときに発見するたくさんの奇妙な問題の1つに、いっしょに働いてみたいと思うような興味深い人たちの多くは金持ちでないということがある。彼らは生活のためにどこかで働く必要がある。それはつまり、彼らと同僚になりたかったら、あなたも生活のための仕事をする必要があるということだ。たとえあなたには金を稼ぐ必要がなかったとしても。実のところ、これが連続起業家たちを駆り立てているものじゃないかと思う。
そしてこれは私がY Combinatorでの仕事をすごく好きな理由だ。この仕事は好きな人たちと興味深い仕事をいっしょにやる口実を与えてくれるのだ。
これは私が20代の頃にスタートアップを始めない理由になっていたことだ。この年代の人の多くと同様、私は何よりも自由に価値を置いていた。私は何であれ数ヶ月以上のコミットメントを要することをするのは気が進まなかった。そしてスタートアップのように生活を完全に奪われてしまうようなことをしたくはなかった。それはいい。世界を旅行して回ったり、バンドで演奏したりして時間を過ごすのが望みなら、それはまったくもって当を得た会社を始めない理由になる。
成功するスタートアップを始めるなら、少なくとも3年か4年は取られることになる。(失敗すれば、ずっと早くて済む。) だからそれくらいのスケールでコミットする覚悟がないなら始めるべきではない。しかし注意して欲しいのは、定職についたなら、おそらくスタートアップに取られるのと同じくらい長くそこにいることになるということだ。そして思っていたよりも自由になる時間が少ないことに気付くだろう。だからあなたがもしIDバッジをつけてオリエンテーションに行く覚悟があるなら、スタートアップを始める準備だってできていると言えるかもしれない。
生活に構造を必要とする人もいるのだと聞いたことがある。これは何をするか人に言ってもらう必要があるというのを聞こえよく言っているだけのように思える。そういう人たちはきっといるのだろう。経験的な証拠であれば、軍隊に、カルト、そ
あなたがそういった人たちの1人であるなら、スタートアップを始めるべきではない。実際のところ、スタートアップで働くべきでもない。いいスタートアップでは、何をするか指示されるようなことはあまりない。CEOという肩書きを持つ人間が1人いるにしても、社員数が12人くらいになるまでは、他の人に指図する人間はいるべきではない。そんなのは非効率すぎる。それぞれの人はただ必要なことを、言われるまでもなくやるべきなのだ。
それがカオスを作り出すレシピのように聞こえるなら、サッカーチームのことを考えてみるといい。11人が非常に複雑な仕方で一緒に働き、非常の場合でもなければ、誰も他の人にどうしろと言ったりはしない。レポーターがデビッド・ベッカムに、レアル・マドリードでは選手の出身国が8つにも分かれていて、言葉が問題になることはないのかと聞いたことがあった。それに対してベッカムは、言葉が問題になることはなく、みんな非常に優れているので、話す必要がないのだと答えていた。彼らは各自がそれぞれただしかるべきことをしているのだ。
自分がスタートアップを始められるほど十分独立心が強いかどうかはどうしたら分るだろう? もし独立心がないかのように言われるとムカつくなら、あなたにはたぶん十分な独立心がある。
不確かなことを嫌うためにスタートアップを始めるのを先延ばしにする人たちもいると思う。Microsoftに働きに行くなら、この先何年かのことを非常に明確に予見することができる。明確すぎるくらいだ。実際、スタートアップを始めるなら、どんなことだって起こりうる。
不確かさが問題だというなら、私がそれを解決してあげよう。スタートアップを始めたなら、それはたぶん失敗する。まじめな話、これは起業の体験全体について考える悪くない方法だ。最高を望みながら最悪を予期しておくのだ。うまくいかなくとも、少なくとも興味深い体験ができる。そしてうまくいけば、たぶん金持ちになる。
あなたのスタートアップがこけても、あなたが真剣に努力している限りは誰も批難はしないだろう。採用者が起業の失敗をマイナスと見ていた時期もあったが、今は違う。私は大企業のマネージャたちに聞いてみたが、彼らはみな起業を試みて失敗した人の方を、同じ時間を大企業で過ごしていた人よりも雇いたいと言っていた。
投資家達も、失敗の理由が怠慢や救いがたい間抜けさというのでもない限り、マイナスとは考えない。よその国(たとえばヨーロッパ)では、起業の失敗が大きな汚点として捉えられると聞くが、ここでは違う。アメリカでは、会社というのもまた、他のあらゆるものと同様、使い捨て可能なのだ。
1年か2年社会に出ていた人が、大学を出たての人よりもいい創業者になる理由の1つに、彼らが自分で何を嫌うかわかっているということがある。スタートアップが失敗したら仕事に就く必要があり、そしてそれがどんなに嫌なものなのかを彼らは知っているのだ。
大学の時夏休みに仕事していたので、仕事がどんなものかくらい分っていると思うかもしれない。しかしあなたは恐らく分っていない。テクノロジー企業における夏の仕事というのは本当の仕事ではないのだ。夏の仕事としてウェイターをしたというなら、それは本当の仕事だ。自分の担当分のことをする必要がある。しかしソフトウェア会社が夏に学生を雇うのは、安価な労働力としてではない。彼らは卒業後に採用することを思ってそうしているのだ。だからあなたが何か作れば彼らは喜ぶだろうが、別にそれを期待しているわけではない。
それが卒業して本当の仕事につくと変わる。あなたは生活費を稼ぐ必要がある。そして大企業のしていることのほとんどは退屈なことなので、あなたは退屈なことをやることになる。大学でやっていたことに比べれば簡単なことだが、しかし退屈だ。最初のうちは、簡単なことをやって金がもらえるというのは、大学で金を払って難しいことをやっていたことから考えるとうまい話に思えるかもしれない。しかし何ヶ月かするとそういう気持ちは消える。そしてそのうちくだらないことをやるのにウンザリするようになる。たとえそれが簡単でいい金になったとしても。
それが最悪のことというわけではない。本当に嫌なのは、正規の仕事では所定の時間そこにいることを期待されるということだ。Googleだろうと、これには煩わされる。そしてこれが意味するのは、正規の仕事に就いている人が誰でも言ってくれるだろうが、どんな仕事もする気にならないような時であっても、会社に行ってディスプレイの前に座り、仕事している振りをしなければならないということだ。多くのハッカーがそうであるように、仕事が好きな人には、これは拷問ともいえることだ。
スタートアップでは、このようなことは省略できる。スタートアップの多くには勤務時間という概念はない。仕事と生活はただ混ざり合っている。これのいい点は、仕事場に生活を持ち込んでも誰も気にかけないということだ。スタートアップでは、ほとんどの時間、どんなことをしていることもできる。あなたが創業者なら、あなたがほとんどの時間にやりたいと思うことは仕事だろう。しかし仕事している振りをすることが必要になることは決してない。
大企業では、オフィスで居眠りするのは職業人らしくないと見なされる。しかしスタートアップをやっていて日中に居眠りするなら、共同創業者たちは単に疲れてるんだろうと思うだけだ。
おそらくスタートアップ創業者になりえた人のかなりの数が、両親に言われて思い留まっているだろうと思う。両親の言うことを聞くべきでないと言っているのではない。家族にはそれぞれ自分のやり方を持つ権利があるし、だいたいそれに反対しようなんて何様なんだろう? しかし安全なキャリアというのは、おそらくあなたの両親が本当にあなたに望んでいることではない。その理由を2つほどお話ししよう。
1つには、親というのは、子供に対しては、自分に対してよりも保守的になりがちなものなのだ。これは実際合理的な態度だ。親は子供の幸運よりは悪運をより多く共有することになる。多くの親はそのことを気にかけない。それは彼らの仕事の一部なのだ。しかしこのことは彼らを過剰に保守的にしがちだ。そして保守的に過ぎるというのも間違いなのだ。ほとんどあらゆることについて、報酬はリスクに比例する。だから子供をリスクから遠ざけるというのは、親はそう自覚していなくとも、報酬からも遠ざけることになるのだ。そのことが分かれば、彼らもあなたがもっとリスクを取ることを望むだろう。
親が間違っているもう1つの理由は、将軍と同様、彼らはいつも昔の戦いを戦っているということだ。彼らがあなたに医者になって欲しいのは、単に病気の人たちを助けて欲しいと思っているのではなく、医者というのが富と名声を伴うキャリアだからだ。[4] しかし彼らの意見が形成された頃に比べると、医者というのはそれほど富にもならなければ名声にもならない。私が子供だった70年代には、医者はみんななりたいと思うものだった。医者に、ベンツ450SLに、テニスは黄金の三角形だった。今では3つともすごく時代遅れの感がある。
あなたに医者になってもらいたいと思っている親は、ものごとがどれほど変わっているか認識していないだけかもしれない。あなたが医者でなくスティーブ･ジョブズにしかなれなかったら、彼らはがっかりするだろうか? だからあなたがどうすべきかについての親の意見は、機能要求のように扱うことだ。たとえあなたの唯一の目標が両親を喜ばすことであったとしても、そのための方法は彼らが求めるものをそのまま与えることではない。そうではなく、彼らがそれを求めるのはなぜかを考え、彼らが本当に求めるものを与えることのできる、もっといい方法を探ることだ。
最後に、普通の職に就くおそらくもっとも強力な理由として、それがデフォルトだということがある。デフォルトというのはものすごく強力なものであり、それは意識的に選択することなく選択されるからだ。
犯罪者を別にすれば、ほとんどの人は金が必要なら職に就くものだと思っている。実際には、この伝統には100年程度の歴史しかない。それ以前には、生活のためのデフォルトの方法は、農業をすることだった。ほんの100年くらいしか歴史のないものを原理のように扱うのは間違っている。歴史の基準で言えば、これは短期間で変わっていることなのだ。
私たちが今目にしているそのような変化は他にもある。私は経済史の本をたくさん読んでるし、スタートアップの世界のことなら良く理解しているつもりだが、私たちが見ているのは農業から工業への移行と同じくらい大きな変化の始まりであるように思える。
農業から工業への移行の初期 (ヨーロッパでは1000年ころ) に居合わせていたなら、富を得ようと都市に向かうことはほとんどの人に狂ったことと思えただろう。農奴は土地から離れることを許されていなかったが、都市へと逃げ出すのはそんなに難しいことではなかったはずだ。村の境界をパトロールしている番人がいたわけではない。土地を離れることから農奴の多くを引き留めていたのは、それがものすごくリスクの高いことに見えたということだ。自分の区画を離れるって? 人生の間ずっといっしょに過ごした人たちから離れて? 見も知らぬ3000か4000という人の住む巨大な都市で暮すために? どうやって生活するつもり? どうやって食べ物を
彼らには恐ろしいことに見えたことだろうが、自分の才覚で生活するというのは現在の我々にはデフォルトになっている。だからスタートアップを始めるのがリスキーに見えるなら、私たちが今している生活が祖先たちにどれくらいリスキーに見えたかを考えてみるといい。このことが一番よく分っているのは、あなたを古いモデルに縛り付けておこうとしている人たちだ。あなたが社員として働きに来るべきだとラリーやサーゲイにどうして言えるのだろう? 彼らは自分では職についたこともないのに!
中世の小作農のことを考えると、どうして彼らがそんな身分を我慢していたのか不思議になる。一生涯同じ土地で何かが良くなる見込みもなく生きていくというのは、どんなにか気がふさぐことだったろう? すべて領主や司祭の言うがままで、利益はすべて取り上げられ、彼らを主人として認めなければならない。いつか、私たちが普通の仕事と思っていることが同じような目で見られるようになったとしても、私は驚かない。人間味のないオフィスビルにあるキュービクルへと毎日通勤
し、ボスと認めなければならない相手の言う通りにしなければならないというのは、どんなに気がふさぐことだろう? その人間はあなたを自分のオフィスに呼んで、｢かけたまえ
するとあなたは言われたとおり腰を下ろすのだ! ソフトウェアをユーザにリリースするときに許可を求めなきゃならないことを想像してほしい。日曜の午後に、週末が終わって明日また朝起きて働きに行かなければならないことで陰鬱になっているところを想像してほしい。どうしてみんなそんなことに我慢できるんだろう?
私たちは農業から工業へのシフトに匹敵するくらい大きな変化の発端にいるのかもしれないと考えるのはエキサイティングなことだ。それが私がスタートアップを気にかける理由だ。スタートアップが興味深いのは、それがたくさんの金を得られる方法だというだけではない。金を儲けられるにしても、他の方法、たとえば株の売買なんかにはまったく興味を感じない。それが面白いのはせいぜいパズルが面白いというのと同じような意味においてだ。スタートアップにはもっと
すごいことがある。スタートアップは、富の作られる方法が変わる希なる歴史的な転換を体現しているかもしれないのだ。
究極的にはそれが、私たちをY Combinatorの仕事へと駆り立てたものだ。スタートアップにかかわるのをやめずに済むという限りにおいて、私たちも金を作りたいとは思うが、しかし金が主な目的ではない。人類の歴史において大きな経済的シフトは数えるほどしか起きていない。それが起きるのを早めてやるというのは、すごいハックだとは思わないか?
[1] 損をしたのは私たちだけだ。エンジェルたちは転換社債を持っており、オークションの売り上げに対して優先的な権利があった。Y Combinatorは1ドルに対して38セントしか得られなかった。
[2] このための最良の組織はたぶんオープンソースプロジェクトだが、オープンソースプロジェクトでは顔を合わせてのミーティングはあまり行われない。顔を合わせるオープンソースプロジェクトというのはやってみる価値があるかもしれない。
[4] 思考実験: 医者が同じ仕事をしているが、貧乏な浮浪者として暮すとしたら、親たちは依然子供を医者にしたいと思うだろうか?
原稿に目を通してくれたトレバー・ブラックウェル、ジェシカ・リビングストン、ロバート・モリス、PowerPointキラーとなるだろうWebベースの製品をまだローンチされてないにも関わらず使わせてくれたZenterの創業者たち、そして講演に招待してくれたBerkeley CSUAのミンヘイ・ラクに感謝する。

 

[ 114] マイクロソフトのアンチウイルスソフト、Outlookのメールを間違って全削除 - GIGAZINE
[引用サイト]　 http://gigazine.net/index.php?/news/comments/20070309_liveonecare/

この前はノートンがウイルスと誤認してデータを削除するというミスをしてしまいましたが、今度はマイクロソフトが新発売したアンチウイルスソフト「Windows Live OneCare」がOutlookのメールをすべて削除してしまうという事態が相次ぎ、マイクロソフトのフォーラムで大騒ぎになっています。
すでに現時点でこのスレッドには100以上のレスが付けられ、「ビル・ゲイツはこのことを知っているのか！」「ノートンの新製品の方がまだましだ！」と訴える人も出てくるなど、かなりむちゃくちゃな状態に。
どうやらOutlookが受信したメールの中にウイルスが含まれていると通常は隔離処理を行うはずなのですが、何がどうなってしまうのかマイクロソフトいわく「特殊な状況」では、メールごと削除してしまうとのこと。しかもメールの入ったフォルダ（というかまとまった一連のファイル）を丸ごと削除してしまい、復旧不能になるケースが多発しており、利用者から怒りの声が相次いでいます。それだけならまだしも、マイクロソフト側の提示した復旧方法では確実に復旧できるとは言えず、さらに火に油を注ぐ結果になっています。
一応、次のアップデートではこのようなことにならないように改良が加えられるそうですが、それまでに一体どれぐらい被害が拡大するのか、予想不能の状態になっています。
（送信前にこのページを更新し、その際に表示されたトラックバック用アドレスを使って下さい。反映されるまで最大1時間ほどかかります。また、本文中でこの記事のアドレスを引用してください。引用がない場合はスパムとして削除し、以降の全トラックバックを拒否します）
この前はノートンがウイルスと誤認してデータを削除するというミスをしてしまいましたが、今度はマイクロソフトが新発売したアンチウイルスソフト「Windows Live OneCare」がOutlookの...
この前はノートンがウイルスと誤認してデータを削除するというミスをしてしまいましたが、今度はマイクロソフトが新発売したアンチウイルスソ
この前はノートンがウイルスと誤認してデータを削除するというミスをしてしまいましたが、今度はマイクロソフトが新発売したアンチウイルスソフト「Windows Live OneCare」がOutlookのメール...
日本食レストラン認定制度に実施前から高まる反発…とか、マイクロソフトのアンチウィルスソフトに早速不具合…とか、雑記とか
農水省が海外の日本食レストランを評価し、認定する日本食レストラン認定制度に、実施前から反発が高まっています。
http://blog.livedoor.jp/dqnplus/archives/936069.html:title=マイクロソフトのアンチウイルスソフト、Outlookのメールを間違って全削除 ] 痛いニュースでの反応 まぁ、MSやっちまった、って感じだけど、かの企業のソフトウェア品質管理はどうなっているのか非常に興味があ
最近ノートン先生が語作動を起こしたばっかですけど、被害範囲がOutlookとなると今回はさすがにマズイだろ・・・常識的に考えて。
＞この前はノートンがウイルスと誤認してデータを削除するというミスをしてしまいましたが、今度はマイクロソフトが新発売したアンチウイルスソフト「Windows Live OneCare」がOutlookのメー...
マイクロソフトのアンチウイルスソフト、Outlookのメールを間違って全削除（GIGAZINEより）
マイクロソフト社製ソフト、Windows Live OneCareにメールを全削除してしまうバグあり
Windows Live OneCareに間違ってOutlookのメールをすべて削除してしまうというトラブルが発生しているみ
マイクロソフトのアンチウイルスソフト、Outlookのメールを間違って全削除 - GIGAZINE
この前はノートンがウイルスと誤認してデータを削除するというミスをしてしまいましたが、今度はマイクロソフトが新発売したアンチウイルスソフト「Windows Live OneCare」がOutlookのメールをすべて削除してしまうという事態が相次ぎ、マイクロソフトのフォーラムで大騒ぎに...
たった今、上の文章書いてて気づいたんですけどこのBlog、現時点で魔理沙ネタが約５分の１を占めてますね…
というミスをしてしまいましたが、今度はマイクロソフトが新発売したアンチウイルスソフト「Windows Live OneCare
この前はノートンがウイルスと誤認してデータを削除するというミスをしてしまいましたが、今度はマイクロソフトが
アンチウィルスソフトを入れている人はかなりいるかと思います。実際にアンチウィルスソフトを入れていて、ウィルスメールが来ると何かしらのメッセージが表示され、そのウィルスメールはほとんどの場合が削除されずにアンチウィルスソフトによってどこかに隔離されます。隔
マルウェアのサンプル100万種以上を使ってアンチウイルス・ソフトウエア17製品を調べた結果が公表されました。いろいろとありますが、日本で販売されているもので個人的なお勧めはKaspersky と N...
マイクロソフトのアンチウィルスソフトがoutlookのメールを全て削除してしまうバグがあるようです。世話ないですねｗｗｗ
1ヶ月のページビューはRSSなど含めて約2312万、1ヶ月のユニークユーザー数は約820万、日本にあるブログ中「第1位」。
オンラインマガジンとしてギガバイト級のサイトという意味で「MAGAZINE（雑誌）」＋「GIGA」を由来とする造語。
2006年4月にブログ形式に変更、2006年7月より編集部体制で記事を更新、2007年1月中旬に負荷増大のためサーバ移転し、今に至る。
ネタのタレコミやニュースリリース送付は「お問い合わせ」から、広告媒体資料は「GIGAZINE.BIZ」から、広告掲載依頼や記事購入、講演などの仕事依頼はこちらのお問い合わせからお願いします。

 

[ 115] Amazon.co.jp： ヤコブ・ニールセンのAlertbox -そのデザイン、間違ってます- (RD Books): 本: Jakob Nielsen，舩井 淳，奥泉 直子，川崎 幹人
[引用サイト]　 http://www.amazon.co.jp/%E3%83%A4%E3%82%B3%E3%83%96%E3%83%BB%E3%83%8B%E3%83%BC%E3%83%AB%E3%82%BB%E3%83%B3%E3%81%AEAlertbox-%E3%81%9D%E3%81%AE%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%80%81%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E3%81%BE%E3%81%99-Books-Jakob-Nielsen/dp/4903065065

対象商品であれば、購入金額にかかわらず、配送料が無料になります。つまり、無料配送サービスの最低購入金額（1,500円）を意識せずに、お買い物をお楽しみいただけます
Amazonプライム会員規約（以下｢本規約｣といいます）へようこそ。本規約は、お客様とAmazon.com Int’l Sales, Inc.及びその関連会社（以下「Amazon.co.jp」又は「当サイト」といいます）との関係並びに各々の権利及び義務について規定するものです。本規約は、Amazonプライムサービス（以下「プライム」といいます）の利用にあたり提供される無料体験に適用される規約とともに、プライム会員プログラムに関連するAmazon.co.jpとお客様との間の完全な合意を構成します。なお、お客様がAmazon.co.jpのウェブサイトやプライムをご利用される場合には、当サイトの利用規約やプライバシー規約、その他Amazon.co.jpのウェブサイト上の制限及び条件も、全て（都度の変更も含め）本規約と一体のものとして適用されます。お客様がプライムの会員登録をされる場合には、これらの規約、制限及び条件に同意することになりますので、本規約を注意深くお読みください。
プライム会員は、対象商品の購入の全てについて、通常配送又はお急ぎ便配送を無料（本規約中のその他の制限や条件にご留意ください）で受けることができます。但し、これらの配送オプションは、当サイトの在庫状況、注文期限及び一部については発送地域により限定されます。プライム会員は、同一の住居（同一住所）に住む家族を2人まで追加費用なしで家族会員としてプライムに加入させることができます。（20歳未満の会員は、その親権者又は後見人の関与なしにAmazon.co.jpのサイトを利用することはできません。）プライム会員は、いつでも家族会員の変更又は退会をさせることができます。家族会員は、プライム会員が会員を辞めた場合又はプライム会員により退会させられた場合には、自動的に家族会員の地位を失います。プライムは、法人利用、又は営利目的、業務目的若しくは再販売目的のお客様にはご利用頂けません。
プライムの対象は、Amazon.co.jpがwww.amazon.co.jp上で販売する特定の商品で、沖縄及び一部離島を除く日本国内を発送先とするものに限られます。当サイトは、都度当サイトの判断により、例えば設置が必要となる大型商品又は重量商品、危険物として規制されている商品その他発送に関して特別な配慮が必要な商品を、プライム対象外商品とすることができます。また、第三者により、又はAmazonマーケットプレイスなどの第三者販売プログラムを通じて販売される商品は、プライムの対象ではありません。なお、プライムの対象商品である場合には、当サイトのウェブサイト上に、それが明示されます。
お客様は、プライム会員に登録し、プライムを利用するために、Amazon.co.jpのアカウントを取得しなければなりません。当サイトは、当サイトの判断により会員登録を受入れ又は拒絶する権利を有しています。お客様は、上述の家族会員によるプライムの利用方法を除いては、自己の会員資格又はその特典を譲渡又は移転することはできません。プライム対象商品であっても、場合により注文や取扱いに関する料金又は税金がかかる場合があります。支払い方法が代金引換の場合は、別途代引手数料が請求されます。もし、お客様が注文する商品の一部がプライムの対象商品ではない場合には、お客様はかかるプライム対象外商品について所定の配送料を支払うことになります。また、注文の変更やとりまとめ、送付先、配達時期又は配達方法の変更は、プライムの適用について影響を与えることがあります。以下の点に注意して下さい。
通常配送及びお急ぎ便配送オプションは、お客様への配達予定日を決定するためのものです（これらのオプションは、商品の入手可能性や当サイトの発送予定日を反映するものではありません。）。
当サイトは、当サイトの判断において、陸路又は空路から発送することができます（これらのオプションは、運送方法の指定サービスとは異なります。）。
プライムの年会費は、3900円です。この年会費は、以下に明示的に規定する場合を除き、払戻しされません。翌年についてのプライム会員登録の更新前に、お客様が退会したい旨を当サイトに通知しない場合には、お客様の会員登録は自動的に更新され、お客様への通知なくして、当サイトは、お客様が登録された支払い方法に基づき、その時点で適用される年会費及び税金の支払を受けることができます。
Amazonプライムの会員は、会員登録後、サービスを共有できる家族の方も含め、一度もサービスを利用されていない場合は、キャンセルすることができ年会費の払い戻しを受けることもできます。
当サイトは、お客様に対し様々なプライム無料体験その他の会員の募集をすることがあります。無料体験会員は、当該会員募集の際に特別に規定されたものを除き、本規約の条件に従うものとします。無料体験会員はいつでも、無料体験期間の終了の際に、Amazon.co.jpのアカウントサービスを通して年会費を負担するプライムの会員登録をしないという選択をすることが可能です。
当サイトは、当サイトの判断により、お客様に何らの通知なくして、本規約、Amazon.co.jpの利用規約やプライバシー規約又はプライム会員に関する事項について変更することができます。しかしながら、年会費の増額については、会員登録を更新するまでは適用されません。また、当サイトが通常配送、お急ぎ便配送オプションの配送を有料としたり料金を値上げする場合、又は当サイトが、お客様が加入させることができる家族会員の人数を減らす場合には、その変更が生じる少なくとも30日前にEメールによりお客様にその旨を通知します。もしお客様がこれらの変更の実施前に退会される場合には、当サイトは、残りのプライム会員期間(但し、一ヶ月単位で残っている期間に限る)を基準に、年会費の割合的払い戻しをします。この払戻オプションは、当サイトが行なうその他の変更には適用されません。万が一、これらの変更が違法、無効又は何らかの理由により強制力がないと判断された場合でも、これにより、その他の有効かつ強制力のある変更又は条件は影響を受けることはありません。当サイトが本規約等を変更した後に、お客様がプライム会員登録を継続する場合には、お客様はその変更に同意したものと見なします。もしお客様がかかる変更に同意しない場合には、お客様はプライムを退会しなければなりません。
当サイトは、当サイトの判断により、お客様に通知なくして、プライム会員登録を解除することができます。もし当サイトが解除を行う場合には、当サイトは、残りのプライム会員期間(但し、一ヶ月単位で残っている期間に限る)を基準に、年会費の割合的払い戻しをします。しかしながら、当サイトが、お客様の行為が本規約又は法律違反、会員特典の詐取又は悪用並びに当サイト又は他の会員の利益を害するものと判断し解除する場合には、年会費の割合的払戻しはいたしません。当サイトがお客様に対して本規約の各規定を厳格に遵守するように要求しなかったとしても、それは当サイトの権利の放棄を意味するものではありません。
Amazon.co.jpの利用規約中の責任の限定及び免責に加えて、当サイト若しくはその取締役、役員、従業員、代理人若しくはその他代表者は、プライムに起因若しくは関連する直接的、間接的、特別、偶発的、必然的又は懲戒的な損害賠償又はその他の損害賠償について責任を負いません。当サイトの契約上、保証上、不法行為法上（不作為も含む）又はその他の責任限度額は、お客様が支払った直近の年会費を上限とします。 これらの免責及び責任の限定は、法律上許容される限度において適用され、退会又は解除によりその効力は失われません。お住まいの国や地域によっては、法律により、特定の損害について免責又は責任限定が許されません。もしこれらの法律がお客様に適用される場合には、上記の免責又は責任の限定の規定の全部又は一部は適用されず、お客様は上記規定に関係なく損害賠償請求ができます。
Amazonプライムの会員に登録すると、同居されているご家族2人に登録案内を送ることができ、対象商品について配送無料のお急ぎ便または通常配送を使い放題ご利用いただけます。Amazonプライムの特典は会員登録（年会費￥ 3,900）をしていただくだけで、いつでも無料でご利用いただけます。
下のボタンをクリックして今すぐお申し込みいただけます。お申し込み完了後、この注文に新しい配送料が適用されます。今回お申し込みされない場合でも、申し込みページからいつでもAmazonプライムの会員登録ができます。
後でお申し込みされる場合は、この注文にAmazonプライムのサービスは適用されませんのでご了承ください。
Amazonプライムのサービスをご利用いただくには、1-Click機能での注文が便利です。対象商品の詳細ページの上部に、会員専用の1-Clickボタンが表示されます。ボタンをクリックすると注文が確定され、商品は無料のお急ぎ便または通常配送でお客様にお届けします。
Amazonプライムのサービスと1-Click機能での注文を便利にお使いいただくために、1-Click設定を確認してください。
1-Clickはオンになっていますか？ 1-Clickがオフに設定されていると、会員専用の1-Clickボタンが表示されません。
お届け先はAmazonプライムのサービス対象地域ですか？ Amazonプライムのサービス対象地域をお届け先として指定していることを確認してください。一部の地域は、Amazonプライムの配送サービスでお届けすることができません。
支払い情報は最新のものですか？ 指定したクレジットカード番号や有効期限を更新する必要がないか、必要に応じて確認してください。
配送方法はお急ぎ便ですか？ 商品詳細ページの右側にある通常の1-Clickボタンを使用する場合は、お届け先への配送方法を確認してください。Amazonプライムのサービスを便利にご使用いただくには、配送方法を通常配送からお急ぎ便に変更する必要があります。
1-Click機能を利用して注文するのではなく、ショッピングカートを使用して注文する場合は、ショッピングカートに商品を入れて通常どおりレジに進んでください。「注文内容」ページには、以下が表示されます。
できるだけ早くお届けするように、商品は初期設定で「準備ができ次第発送」されるように設定されます。追加料金は発生しません。
対象商品は、商品ページ、レジに進む際、また最後の注文確定時に指定されます。対象商品は、Amazon.co.jp が販売、発送する商品に限られます。Amazonギフト券のご購入については、Amazonプライムの対象外です。また。Amazon.co.jp が販売、発送する商品でも、一部の商品は対象外となります(重量やサイズの大きい大型商品、危険物として規制されている商品、特別な配送が必要となる商品など)。Amazonマーケットプレイスなど、第三者が販売する商品も対象外となります。
家族に登録案内をおくるには、名前、続柄、Eメールアドレス、誕生日をそれぞれのフィールドに入力して、「登録案内を送る」をクリックします。入力したEメールアドレス宛てに、Eメールが自動的に送信されます。登録案内を受け取られたご家族の方はEメールの中にあるリンクをクリックし、サイト上にて登録手続きを完了してください。なお、登録案内を送ったお客様の誕生日を入力する必要がありますのでご注意ください。
家族会員を削除するには：削除する家族名の横にある「削除」ボタンをクリックします。削除された家族会員には、お知らせEメールが自動的に送信されます。
お急ぎ便は、日本国内への発送のみにご利用いただけます(一部地域を除く)。お急ぎ便対象外の商品については、通常配送をご利用いただけます。
商品は陸路または空路を使用して発送されます。このオプションは配送業者指定の配送サービスとは対応しません。
Amazonプライムの会員は、会員登録後、サービスを共有できる家族の方も含め、一度もサービスを利用されていない場合は、キャンセルすることができ年会費の払い戻しを受けることもできます。
Amazonプライムをキャンセルするには、「アカウントサービス」からAmazonプライム会員ページにアクセスして、キャンセル手続きを行ってください。
会員登録は、毎年自動的に更新されるように設定されています。「アカウントサービス」から会員ページにアクセスすれば、自動更新しないように設定したり、更新時に支払い方法を変更することもできます。
下のボタンをクリックすると、上記の商品をショッピングカートに入れるとともに、年会費￥ 3,900でAmazonプライムの会員登録の手続きができます。年度の年会費、¥3900 は、お客様が選択したクレジットカードに請求させていただきます。また、お客様がAmazonプライムの会員登録を更新し続ける場合は、毎年、このクレジットカードに請求させていただくことになります。会員登録は、「アカウントサービス」でいつでもキャンセルすることができます。会員登録をキャンセルすると、次年度の年会費は、クレジットカードに請求されません。また、Amazonプライムの特典を一度も使っていない場合、会員登録をキャンセルし、年会費の全額返金を受けることができます。有効期限切れなど、なんらかの理由によりご指定のカードが使用できない場合、アカウントサービスに登録してある別のクレジットカードを選択させていただきます。
下のボタンをクリックすると、会員規約に同意したことになり、登録されているクレジットカードに年会費を請求します。
Amazonプライムに会員登録すると、お急ぎ便が無料になります。 会員登録はお済みでしょうか? サインイン。
1500 円以上国内配送料無料でお届けします。（一部大型商品は除く）！詳しくはこちら。代金引換、 コンビニ・ATM・ネットバンキング・Edy払い、Amazonショッピングカード™でもお支払いいただけます。
今から以内にレジに進み、「お急ぎ便」オプション(有料)を選択して注文を確定されたご注文が対象です。 詳しくはこちら
ウェブサイトのデザインでは、きれいな画像や人目を引くFlashをどう活用するかなど、表面的な問題が先行しがちである。しかし、見目麗しいウェブページであっても使いやすいものでなければ、ユーザは容易にサイトから離れてしまう。ウェブのデザインでは、ウェブがいかに使いやすいか、すなわち「ユーザビリティ」が考えられているかどうかがユーザを集めるための重要なポイントとなる。ユーザビリティ分野の第一人者であるヤコブ・ニールセン博士は、1995年以降、ユーザビリティに関するさまざまな話題についてコラムを発表してきた。ニールセン博士の運営するサイトで人気連載中のこのコラムが「Alertbox」だ。本書では、1995年から2006年4月までに発表された300以上のコラムの中から、ユーザビリティの改善に役立つ50のコラムを厳選し、まとめている。
ウェブにおいて、普遍的なウェブユーザビリティ(使いやすさ)とは何か。この分野の第一人者による、デザインや視覚的手法ばかりにとらわれない、ユーザビリティの改善に役立つ50のコラムを取り上げる。
ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン (情報デザインシリーズ)

 

[ 116] 間違ったコードは間違って見えるようにする - The Joel on Software Translation Project
[引用サイト]　 http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B

私が最初の本当の仕事をはじめたのは1983年9月に遡る。それはオラニムというイスラエルの大きな製パン工場で、16台の飛行機ほどもある巨大なオーブンで、毎晩10万個のパンが作られていた。
はじめて工場に入った時、そのあまりの汚さに信じられない思いだった。オーブンの側面は黄ばんでいるし、機械は錆びていて、そこらじゅうが油だらけだった。
「なんだって? なんの話をしてるんだ?」とマネージャが答えた。「掃除したばかりだから、今が一番きれいな状態なんだ」
毎朝の工場の清掃を何ヶ月か続けて、ようやく彼らの言っていたことが理解できるようになった。パン工場では、きれいというのは機械にパン生地が付いてないことを言うのだ。きれいというのは、ゴミ箱に発酵したパン生地が入ってないことを言うのだ。きれいというのは、床にパン生地がついてないことを言うのだ。
きれいというのは、オーブンが白くきれいにペンキが塗られていることをいうのではない。オーブンのペンキ塗りが行われるのは10年に1回とかのもので、毎日することではない。きれいというのは油がついてないということではない。実際機械の多くは定期的に油をさしてやる必要があり、薄いきれいな油の層は通常機械が清掃されたばかりであることを意味していた。
パン工場できれいというのがどういうことを指すのかは、学ばないとわからないことなのだ。門外漢にはその場所がきれいなのか汚いのか判断するのは不可能だ。門外漢はパン生地こね機(右の写真にある、パン生地の四角い固まりをボールにする機械)の内側にこびりつきが残ってないか覗いてみようとは決して思わない。門外漢は古いオーブンのパネルが色落ちしているのを気にするが、それはパネルが目立つからだ。しかしパン職人はオーブンの外側のペンキが黄色くなりかけていても、これっぽっちも気にしない。パンの味には影響しないからだ。
あなたが初心者プログラマか、あるいは初めて使う言語のコードを読もうとするとき、どの部分も同じように不可解に見える。そのプログラミング言語を理解するようになるまでは、簡単なシンタックスエラーにさえ気がつかない。
学習の最初のフェーズにおいて、私たちが「コーディングスタイル」と呼んでいるものを認識するようになる。そうして標準的なインデントの付け方に合ってないところや、変数名の大文字/小文字が変なところに気づくようになる。
この時期に典型的なことは「水ぶくれのフジツボみたいだ。一貫したコーディング規則がなきゃだめだ」みたいなことを言って、次の日をチームのためのコーディング規則を書くために使い、そのあと6日間で「唯一正しい括弧付けのスタイル」について議論し、そのあとの3週間を古いコードが「唯一正しい括弧付けのスタイル」に合うよう書き直すのに費やすが、それに気付いたマネージャから全然お金にならないことに時間を使っていることで怒鳴りつけられ、それでソースに手を入れる必要が出た時ついでにフォーマットを直すのでも別に悪くないと思い直し、半分だけ「正しい括弧付けスタイル」という状態になってしまうが、そんなことはすぐに忘れ、そしてすぐまた別な何か、1つの文字列クラスを別な文字列クラスで置き換えるというような、お金になることとは無関係なことに心を奪われるのだ。
その環境でコードを書くことにさらに熟達していくと、もっと別なことに気づくようになる。まったく合法で、コーディング規則上はまったく問題ないのだが、しかし何か不安にさせるようなことにだ。
このコードは正しい。コーディング規則にも合っているかもしれないし、意図した通りのコードなのかもしれない。しかしCのコードを書く経験を積んでいれば、destがcharポインタを宣言している一方、srcはただのchar型なことに気付くだろう。それが意図した通りという可能性もあるが、おそらくはそうではない。このコードは少し嫌な臭いがするのだ。
この場合、コードは100%正しく、ほとんどのコーディング規則を満たし、まずいことは何もないのだが、if文の本体が括弧でくくられていない1行のステートメントになっているのがあなたに不安を抱かせる。それというのも、後で誰かがもう1行追加するかもしれないからだ:
そして括弧をつけ忘れる。結果としてfoo(i)は無条件に実行されるようになる! だからあなたは括弧に入っていないブロックを見ると、何かほんの、ごく、ちょっとした汚さを感じるようになり、不安を覚えるのだ。
2. きれいさについて表面的な考えを持っている。そのほとんどはコーディング規則に合っているかどうかというレベルだ。
3. コードのきたなさについて、表面的でない小さな兆候も嗅ぎつけるようになり、気になってコードを直すようになる。
4. コードを直すために汚いコードに対する嗅覚を生かせるような仕組みを、最初から作り込むようになる。
これこそ本当のアートだ。エラーが画面から飛び出して見えるような規則を考案することによって、頑強なコードを作り出すのだ。
では、小さな例で見ていくことにしよう。そのあと頑強なコードのための規則を考案するのに使える一般的なルールを示す。最後に、ある種の(人々が乗り物酔いを感じる類のものではない)ハンガリアン記法の擁護を行う。そしてある状況における例外の使用を批判する(ただしこれはおそらく普段あなたが直面しているような状況ではない)。
あなたがハンガリアン記法は悪であり、例外はチョコレートミルクセーキ以来の最良の発明であると信じて疑わず、他の意見には耳を傾けるつもりがないのなら、結構、かわりにローリーのサイトに行って、すばらしいコミックを読むといい。たぶんあなたは大して損することにはならないだろう。実際このあとすぐ、私はあなたを居眠りさせるようなコード例を示すつもりだ。だからあなたは怒りはじめる前に眠り込んでしまうだろう。つまり、私のプランは、あなたをすっかり眠り込ませ、その間にハンガリアン=良い、例外=悪い、というアイデアをもぐり込ませてしまおうというものなのだ。あなたは眠くって抵抗もできないだろう。
じゃあ例を見よう。あなたはWebベースのアプリケーションを作っているものとしよう。若い人たちの間で最近流行っているみたいだから。
クロスサイトスクリプティング、別名XSSと呼ばれているセキュリティ脆弱性がある。あまり詳しい説明はしないが、Webアプリケーションを作るときにはユーザがフォームで入力した文字列をそのまま返してはいけない、ということをとりあえず知っておいてもらえればいい。
たとえばテキストボックスを出して「あなたの名前は?」と質問するページがあって、送信すると別なページに「こんにちは、エルマー!」と表示されるとする(ユーザの名前がエルマーだとしてだ)。その場合、セキュリティ脆弱性があって、それはユーザが「エルマー」の代りにあらゆる奇妙なHTMLやJavaScriptを入力でき、その奇妙なJavaScriptコードにはいろいろな嫌らしいことをさせることができて、その嫌らしいことをそのサイトがやっているように見えるのだ。それで彼らはクッキーを読み取ってDr.Evilのサイトに送信するといったことができるようになる。
このコードで入力(POST引数)をHTMLフォームから読み込めるとしよう。あなたが以下のように書いたとすると、あなたのサイトはXSS攻撃に対して脆弱性を持つことになる:
コピーした文字列をHTMLに書き出す前にエンコードする必要がある。エンコードというのは、"を"で置き換えたり、>を>で置き換えたりすることをいう。
あなたがこの間違いを犯したときに、コードがただ間違ってるように見えるコーディング規則を作ってみよう。間違ったコードが間違って見えるなら、そのコードをいじっている人やレビューする人の目にとまる可能性がある。
この規則に従っていればXSSバグがなくなるという点では、この規則は上手く機能する。しかしこれは最適なアーキテクチャというわけではない。たとえばあなたはユーザの入力文字列をどっかのデータベースに格納したいと思うかもしれず、データベースに入れる文字列をHTMLエンコードするというのは意味がない。その文字列はHTMLページ以外の所に行くわけで、クレジットカード処理アプリケーションがHTMLエンコードされた文字列を食わされたら混乱することだろう。ほとんどのWebアプリケーションは、内部的な文字列はエンコードせず、HTMLページに出力する直前にエンコードするという原則で開発されている。これはたぶん正しいアーキテクチャだ。
しかしこれはあまりうまくいかない･･･ときどきちょっとしたHTMLを使う必要があり、それはエンコードするわけにいかないのだ。
しかしこうしてしまうと、"<br>"は改行のつもりなのに、&lt;br&gt;とエンコードされ、ユーザに文字通りの< b r >を見せることになる。これもまた正しくない。
だから文字列を読み込んだ時にエンコードできない場合がときどきあり、文字列を出力するときにエンコードできない場合もときどきあって、これらの案はどちらもうまく行かないのだ。そして規則がないと、次のようなことをするリスクが残る:
文字列をエンコードしなきゃいけないことを果たして覚えているだろうか? バグを見つけるために一カ所見ればすむ場所というのはどこにもない。臭う場所がどこにもないのだ。こういうコードがたくさんあれば、出力される文字列のそれぞれがエンコードされているか確認するために、その起源をたどっていくという膨大な作業が必要になる。
ユーザから来た文字列は(安全でない?Unsafe?文字列という意味で) プレフィックス"us"をもつ名前の変数(あるいはデータベースのカラム)に格納する。HTMLエンコードされた文字列や、素性の安全なことのわかっている文字列は(安全?Safe?な文字列という意味で)プレフィックス"s"を持つ名前の変数に格納する。
新しい規則で気付いてほしいのは、この規則にしたがっていれば、安全でない文字列について間違いを犯したとき、どこか1行のコードでその間違いを見つけられるということだ。
これは理論的に間違っている。sで始まる名前の変数にRequestの結果を代入しており、これは規則に反しているからだ。Resultの結果は安全でなく、したがって常に"us"で始まる名前の変数に格納する必要がある。
すべてのコード行が、その行だけ見てチェックすることができ、そして各行がすべて正しいなら、コードの全体も正しいことになる。
このコーディング規則を使っていれば、Write usXXXのようなコードを見ると間違いだと気付くようになり、そしてどう修正すればいいのかがすぐにわかる。はじめはコードの間違いを見つけるのが難しく感じられるかもしれないが、これを3週間も続けていれば、目が慣れるようになる。ちょうど巨大なパン工場の見方を覚えた職人が即座に言うように。「まったく、こね機ん中誰も掃除してねぇじゃねぇか! ここじゃ一体どんな運用してんだよ?」
このルールをもう少し拡張して、Request関数やEncode関数をリネームして(あるいはラップして)、UsRequestやSEncodeという名前にすることもできる･･･言い換えると、安全でない文字列を返す関数や安全な文字列を返す関数に、変数と同様、それぞれUsとSで始まる名前を付けるのだ。コード例で見てみよう。
ここで何をしているかわかる? こうしておけば、等号の両端が同じプレフィックスで始まっているか見てコードに間違いがないか確認できる。
こうすれば間違いがさらに見つけやすくなる。あなたの目には臭うコードが「見える」ようになり、それはあなたが、コードを書いたり読んだりしているときに奇妙なセキュリティバグを見つける助けになる。
間違ったコードを間違って見えるようにするのはいいことだが、これがあらゆるセキュリティ問題に対する最良の解法とは限らない。起こりうるあらゆるバグやミスをこれで見つけられるわけではなく、それはあなたがコードをすべては読まないかもしれないからだ。しかし何もしないよりずっといいのは確かだ。そして私は間違ったコードが少なくとも間違って見えるコーディング規則を持ちたいと思う。プログラマの目がコード行の上をたどるたびに、バグがチェックされ、回避されるという、追加的な利益がすぐに得られるのだ。
間違ったコードが間違って見えるためには、関連するものが画面上で近くにある必要がある。コードが正しいか確認しようと文字列を見るとき、どれでも文字列を見れば、それが安全か安全でないかがわかる必要がある。その情報が別なファイルや、スクロールしなければ見えない別なページにあっては困る。その場にあるのを見ることができる必要があり、それには変数命名規則が必要なのだ。
関係するものを隣り合わせにしておくことでコードを改善できる例はたくさんある。コーディング規則の多くは以下のような規則を含んでいる:
これらのルールに共通しているのは、1行のコードが実際にすることに関連した情報を可能な限り物理的に近づけるということだ。そうすることによって、あなたの目玉が何が起きているのか理解できる可能性が高くなる。
･･･を見れば、少なくともCであれば、j の値が5倍されて結果が i に格納されるということがわかる。
しかしC++の場合では、同じスニペットから分かることは何もない。まったく。C++で本当に起こることが何か知るためには、ぜんぜん違う場所で宣言されているかもしれない i と j の型を見つける必要がある。それはjがoperator*をオーバロードしている型の変数かもしれず、かけ算したときにはなはだ気の効いたことをやってくれるかもしれないからだ。そして i はoperator=をオーバロードしている型の変数かもしれず、また型が異なるために暗黙の型変換関数が呼ばれることになるかもしれない。そして何が起るか知るためには変数の型をチェックするだけでなく、その型を実装しているコードを見つける必要があり、そして，神よ救いたまえ、どこかで継承が行われていれば、コードが実際どこにあるのか自分でクラス階層をたどる必要があり、そしてどこかにポリモーフィズムがあれば、あなたは本当に難儀することになり、それは i と j の型がどう宣言されているか知るだけでは不十分で、実行のその時点における型が何か知る必要があるからであり、それにはどれくらいの量のコードを調べなければならないかわからず、停止性判定問題のおかげで、あなたは決してすべてをチェックしたか本当に確信することはできないのだ。(やれやれ!)
C++におけるi=j*5というコードは任意性が高く、その分コードを見るだけで問題を見つけ出せる能力は下がることになる。
これらの機能は問題となることが想定されたものではもちろんない。あなたが賢い中学生みたいにoperator*をオーバライドするとき、それは素敵な漏れのない抽象化を提供することを意図している。j がUnicode文字列型ならUnicode文字列の整数倍が繁体中国語から簡体中国語への変換だというのは優れた抽象化に違いない。そうだよね?
問題は、漏れのない抽象化は存在しないということだ。この点については「漏れのある抽象化の法則」で詳しく議論したので、ここでは繰り返さない。
スコット・メイヤーズは彼のキャリアのすべてを、C++で失敗したりしくじったりするためのあらゆる方法を示すことに費やしている。(ところで、スコットの本Effective C++の第3版が出たところだが、この本は前の版から完全に書き直されている。すぐ手に入れるといい!)
間違ったコードが間違って見えるコーディング規則を探すこと。関連する情報を画面上でひとまとまりにして見られるように配置することで、ある種の問題を容易に見つけて修正できるようになる。
ハンガリアン記法はMicrosoftのプログラマ、チャールズ・シモニイにより考案された。シモニイがMicrosoftで手がけた大きなプロジェクトの1つにWordがある。実際彼はXerox PARCで、Bravoと呼ばれる世界最初のWYSIWYGワードプロセッサを構築するプロジェクトの指揮をしていたのだ。
WYSIWYGワープロにはスクロールする画面があり、すべての座標はウィンドウに対する相対座標なのかページに対する相対座標なのか解釈する必要があり、どちらであるかによって話は大きく違うので、取り違えないようにすることが重要だ。
私の推測ではこれが、ハンガリアン記法と呼ばれるようになるものをシモニイが使い始めた理由の1つなのだと思う。それがハンガリー語のように見え、またシモニイがハンガリー人であったことから、この名前が使われるようになった。シモニイ版のハンガリアン記法では、すべての変数に、それが保持するものの種類を示すタグを小文字で付ける。
私はここで種類(kind)という言葉を意図して使った。シモニイはタイプ(type)という語を不用意に使い、それが後の世代のプログラマたちの誤解の元となった。
シモニイの論文を良く読めば、彼が書いているのは、私が上の例で使った命名規則と同種のものであるのがわかるだろう。usは「安全でない文字列」を表し、sは「安全な文字列」を表すが、どちらも型(type)としてはstringだ。間違って代入してもコンパイラは助けにならないし、インテリセンスは何も教えてくれない。しかしこれらは意味論的には異なっており、違ったように解釈し、違ったように扱う必要がある。そして一方を他方に代入するときには変換関数を呼ぶ必要があり、そうしないと実行時バグを目にすることになる。運が良ければね。
シモニイのハンガリアン記法のオリジナルのアイデアは、Microsoft内部ではアプリケーションハンガリアンと呼ばれ、それはアプリケーション部門で、すなわちWordとExcelで使われていたためだ。Excelのソースコードにはrwとcolというのがたくさん出てくるが、これは行(row)とカラム(column)を表している。どちらも整数だが、これらの一方を他方に代入するのは意味がない。Wordでは、聞いたところによると、xlとxwというのがたくさん出てくる。xlは「レイアウトに対する相対水平座標」、xwは「ウィンドウに対する相対水平座標」を意味する。どちらもintだが、交換可能ではない。ExcelでもWordでも「バイト数」を意味するcbがたくさん出てくる。これもまたintだが、変数名を見るだけで、ずっと多くのことを知ることができる。その変数はバイト数であり、すなわちバッファサイズだ。そしてxl = cbのようなコードを見たなら、まずいコードを知らせる警鐘が鳴り響き、コードの間違いは明らかだ。それはxlとcbがどちらもint型であるにせよ、ピクセル単位での水平オフセットにバイト数をセットするというのはまったく狂ったことだからだ。
アプリケーションハンガリアンでは、プレフィックスは変数名と同様に関数名にも使われる。私は、ほんとのこと言ってWordのソースは見たことがないのだが、垂直ウィンドウ座標を垂直レイアウト座標に変換するYlFromYwという名前の関数があるだろうことには賭けてもいい。アプリケーションハンガリアンでは、前の例でEncodeをSFromUsにリネームしたように、よく見られるTypeToTypeという形ではなく、TypeFromTypeという記法を使い、関数名が戻り値の型で始まるようにしている。実際、本来のアプリケーションハンガリアンでは、Encode関数はSFromUsという名前にしなければならないのだ。アプリケーションハンガリアンではこの関数の名前について選択肢はない。これはいいことであり、記憶しなければならないことが1つ少なくなり、Encodeという名前がどんな種類のエンコーディングを表しているのか思いまどう必要もない。ずっと正確に表せるのだ。
アプリケーションハンガリアンは非常に価値があり、ことにコンパイラがあまり型について有用な情報を与えてくれなかったCプログラミングの時代にはそうだった。
それがなぜなのか、どういう経緯でそうなったのか誰も知らないのだが、どうやらWindowsチームのドキュメントライターたちが、不用意にシステムハンガリアンとして知られるようになるものを作り出したということらしい。
誰かが、どこかでシモニイの論文を読み、「タイプ」という言葉が使われていたため、それがクラスのような、タイプシステムや、コンパイラのタイプチェックというときのタイプ(型)を意味するのだと考えた。これはシモニイの意図していたことではない。シモニイは「タイプ」が正確に何を意味するのか注意深く説明しているが、それも救いにはならなかった。ダメージは為されてしまった。
アプリケーションハンガリアンは有用で意味のあるプレフィックスを使う。配列インデックスを表す"ix"や、個数(count)を意味する"c"、2つの数の差(difference)を意味する"d"などだ(たとえば"dx"は幅を表す)。
システムハンガリアンはlongを意味する"l"、unsigned longを意味する"ul"、double word(これは、実際は、その、unsigned longと同じものだ)を意味する"dw"のような、あまり役に立たないプレフィックスを使う。システムハンガリアンでは、プレフィックスが教えてくれるのは変数のデータ型だけだ。
ちょっとした誤解ではあるが、シモニイの意図とやり方を完全に捉え損ねている。込み入ってわかりにくい学術的な文章を書くと、結局誰も理解できず、アイデアは誤解され、誤解されたアイデアはあなたのアイデアでないにもかかわらず、あなたがあざ笑われることになるのだ。システムハンガリアンではたくさんの"dwFoo"が出てきて、それは「double word型のfoo」を意味しているのだが、ばからしい、その変数がdouble word型であるというのは有用なことをほとんど何も教えてくれない。だから人々がシステムハンガリアンに反対するのも無理のないことなのだ。
システムハンガリアンは広く普及し、Windowsプログラミングのドキュメンテーションにおける標準となった。これはWindowsプログラミングのバイブルである、チャールズ・ペゾルドの「プログラミングWindows」のような本によって広められた。そして急速にシステムハンガリアンがハンガリアン記法の支配的な形態となり、Microsoft内部においてさえ、WordチームとExcelチームを別にすると、彼らがいかに大きな間違いをしたか理解しているプログラマはごくわずかしかいなかった。
そして大きな反乱が起きた。ハンガリアン記法をそもそものはじめから理解していないプログラマたちは、自分たちの使っているハンガリアン記法の誤解されたサブセットがはなはだ煩わしくほとんど役立たずであることに気づき、反旗を翻したのだ。システムハンガリアンにも、バグを見つけやすくする特質がなくはない。少なくとも、システムハンガリアンを使うなら、変数の型がその使われているその場でわかる。しかしそれはアプリケーションハンガリアンの有用性には遠く及ばない。
大反乱は.NETの最初のリリースでピークを迎えた。Microsoftはついには人々に言い始めたのだ。「ハンガリアン記法は推奨しない」。これは喜びをもって迎えられた。Microsoftはその理由を説明すらしなかったと思う。彼らはただドキュメントの命名ガイドラインの部分をたどって、それぞれの項目に「ハンガリアン記法は使わないこと」と書き込んでいった。ハンガリアン記法ははなはだ人気がなかったので、誰も苦情を言う人はおらず、ExcelチームとWordチームを別にすると、強い型付けとインテリセンスの時代には不要と思える面倒なだけの命名規則にもはや従わなくていいことに、みんなほっとしていた。
しかしアプリケーションハンガリアンには依然としてものすごい価値がある。コードのコロケーションを増し、コードは読みやすく、書きやすく、デバッグしやすく、メンテナンスしやすくなり、そして最も重要なのは、間違ったコードが間違って見えるようになることだ。
終わる前に、もうひとつ約束していることがあった。もう一度例外を攻撃するということだ。前にやったときには、すごいトラブルに見舞われた。Joel on Softwareのホームページに即席のコメントで例外が嫌いだと書いた。例外は実質的に見えないgotoであり、目に見えるgotoよりいっそう悪いという議論をしたのだ。もちろん何百万という人々が私ののど元に飛びかかってきた。私の擁護に立ち上がった唯一の人間は、もちろんレイモンド・チェンで、彼は世界最高のプログラマなわけだから、それは意味のあることなはずだ。そうだよね?
このアーティクルの文脈における例外とはこういうことだ。あなたの目は、見えるものがある限り、間違ったものが見えるようになり、それがバグを抑止する。コードを本当に頑健なものにするためには、コードレビューしたとき、コロケーションを可能にするコーディング規則が必要になる。言い換えると、コードが何をやっているかについて目の前にある情報が多いほど、間違いを見つける上でいい仕事ができるのだ。次のようなコードがあるとき
･･･あなたの目はこれのどこに問題があるのか教えてくれるだろうか? いつでもクリーンアップする必要がある! しかしdosomethingが例外を投げる可能性により、cleanupは呼ばれないかもしれない。それはfinallyかなにかを使って容易に修正できるが、それは私の論点ではない。cleanupが間違いなく呼ばれることを確認できる唯一の方法は、dosomethingのコールツリーをすべて調べて、何か、どこかに、例外を投げるかもしれないものがないかチェックし、それによって問題が起きないか確認するということで、チェック例外によりいくぶん骨折りを軽減できるにしても、本当の問題は、例外がコロケーションを殺してしまうということだ。コードが正しいことをしているかという質問に答えるためには、どこか別なところを見なければならず、あなたの目の持つまずいコードを見つけ出す能力が生かせないことになる。そこには見えるものがないからだ。
たくさんのデータをかき集めてきて１日に1度プリントアウトする小さなスクリプトを書いているのであれば、例外は大変結構なものだ。起こりうるあらゆるまずいことをすべて無視し、古き良きtry/catchを使ってプログラムに片を付け、起ったまずい問題はメールで通知するというのは、私の喜んでやりたいことだ。例外はやっつけ仕事や、スクリプトや、ミッションクリティカルでも生命維持にもかかわらないコードにはいいものだ。しかしオペレーティングシステムや、原子力発電所や、心臓の手術に使う高速回転丸鋸をコントロールするソフトウェアに例外を使うのは、はなはだ危険なことだ。
みんなが私のことを、例外をちゃんと理解できず、例外を受け入れればずっと人生が良くなることが分からないヘボなプログラマだと思うのはわかっている。しかし、そのために自分の心臓に例外を入れるというのはまずすぎる。本当に信頼性のあるコードを書く方法は、人の典型的な弱さを考慮に入れるシンプルなツールを使うことであって、副作用のあることや、プログラマの無謬性を前提とする漏れのある抽象化を隠している複雑なツールを使うことではない。
あなたが依然例外に献身的なら、レイモンド・チェンのエッセイCleaner, more elegant, and harder to recognizeを読むといい。「例外ベースのまずいコードと、例外ベースのまずくないコードを見分けるのは、はなはだ難しい･･･例外はあまりに難しく、私は例外を扱えるほどに頭が良くはないのだ」
レイモンドのマクロ死についての議論A rant against flow control macrosは、必要な情報がすべて一カ所でわかるようにしそこねているコードはメンテナンス不能であることのもうひとつのケースを示している。「(マクロを)使っているコードを見るとき、ヘッダファイルを掘削してそれが何をやっているか理解する必要がある」
ハンガリアン記法の歴史的な背景については、手始めにシモニイのオリジナルの論文Hungarian Notationを読むといい。ダグ・クランダーがハンガリアン記法をExcelチームに紹介した文章はもう少し明快に書かれている。ハンガリアン記法とそれがドキュメントライターによっていかに損なわれたかについての話は、ラリー・オスターマンの投稿(特にスコット・ラドウィグのコメント)か、リック・ショートの投稿を読むといい。

 

[ 117] 転職の相談する人、間違っていませんか − ＠IT自分戦略研究所
[引用サイト]　 http://jibun.atmarkit.co.jp/lcareer01/rensai/debug08/debug01.html

ITエンジニアの世界でも、中途採用を積極的に行う企業が増え、以前に比べて転職が容易になっている。その一方で転職した後に、「転職に失敗した」といって人材紹介会社に駆け込むITエンジニアが急増中だ。失敗しないためにできることは何か。パソナキャリアの人材コンサルタントがそんな疑問に答えよう。
転職は、人生においてかなりのインパクトを与える重要な出来事です。転職によって、収入やライフスタイルなど、仕事内容以外に影響を受ける事柄はたくさんあります。転職活動の中で考えること、悩むこともいろいろあります。転職すべきか、いつ転職すべきか、どの職種に進むべきか、どの会社を選ぶべきか……。
転職に関する情報は十分すぎるほど流通しているため、最終的にどの情報を選択すればいいのか、迷ってしまう人がほとんどでしょう。そんなとき、自分の状況や性格を知っている人に、意見を求めたいと思う人も多いのではないのでしょうか。今回は、知人に相談したために、転職に失敗したKさんとHさんの例をご紹介しましょう。
Kさん（29歳）は、大学院で情報システムなどを学び、卒業後、大手システムインテグレータ（SIer）に就職しました。大学院での専門知識だったこと、大学時代からアルバイトとしてシステム構築にかかわった経験もあり、会社からは新卒とはいえ即戦力として期待され、実際配属直後から活躍していました。
フリーエンジニアになりたい、フリーとしてどう生き残ればいいか分からない。そんな人のために、＠IT自分戦略研究所では、「フリーエンジニアカンファレンス2007」を企画しました。「安定した案件を受注するテクニック」など、具体的なノウハウを伝授。詳しくはセミナーページを！
大学院の研究室時代の仲間や、アルバイト時代の知り合いの多くもIT業界に進んだこともあり、Kさんには新卒時代から多くのITエンジニアの知り合いがいます。
入社から5年ほどたったとき、Kさんはそろそろ転職をしようかと考えるようになりました。そこで、友人に転職の相談をすることにしました。
その相談で、さまざまな会社のうわさを聞くことができました。「A社と仕事を一緒にしたんだけど、エンジニアはイマイチだった」「B社に中途入社した知り合いがいるけど、面接は露骨な圧迫面接だったらしい」「C社は、辞める人が多いらしい」などなど。
そんな話を聞いた後、以前から優秀なITエンジニアだと尊敬していた先輩に会う機会がありました。先輩にも転職のことを相談しました。すると先輩から、思ってもいなかった次のような誘いを受けたのです。
「実は、自分が働いている会社はベンチャーなんだけど、いいエンジニアを探しているんだよ。Kさん、興味ない？」
Kさんは、優秀だった先輩の誘いにかなり心を動かされました。興味があると話すと、さっそく会社との面接の手はずを整えてくれました。とはいっても、先輩はすぐに面接しようなんてことはいいません。Kさんには、「都合が良いときに連絡してくれればいいよ」といってくれたのです。
そんな配慮に感謝し、Kさんは後日先輩に連絡し、先輩の働く会社の社長も含めた役員との面接を行うことになりました。面接当日も先輩が出迎えてくれ、面接もアットホームな雰囲気で進みました。役員も優秀なITエンジニアという感じで、その点もKさんはかなり気に入りました。
「年収については、いまの会社の50万円プラスくらい出すよ」と社長のひと言。そんなこともあり、先輩の会社に入社することにしました。
そしてそのベンチャー企業に入社したのですが、想像以上に仕事が忙しいことが分かりました。年収が50万円アップするなら、多少の残業も仕方ないと思っていましたが、残業は増え続けるのに対して、年収はまったく上がる気配はありません。先輩の紹介だっただけに、遠慮もあって待遇面の要望を話すことはありませんでしたし、会社の待遇の実態がどうかもあまり聞いていませんでした。
これでは体がもたないと、Kさんは転職を考えるようになり、ある人材紹介会社に相談に行きました。もちろん、先輩には話していません。転職するとなれば、先輩との仲がどうなるか分かりません。最終的には業務が忙しすぎて、転職活動を中止することになりました。結局いまもKさんは何となく納得できないまま仕事を続けています。
Hさん（26歳）は、システムハウスに勤務しています。その会社が扱うプロジェクトは、すでに仕様が決まっていて、コーディングがメインというものが多いのです。もちろんHさんが担当するプロジェクトもコーディング作業が中心で、ユーザーと打ち合わせることはありません。
もともとHさんは、ユーザーの喜ぶことがしたいという動機でIT業界に就職したので、ユーザーとの接点がないことに不満でした。そこで、もっと上流工程を担当でき、ユーザーと折衝できるような会社に転職したいと思うようになったのです。
転職について考えていると、同僚などとの飲み会で、こんなことが自然と口に出てきます。
この言葉を聞いたHさんの同僚は、何となくモチベーションが下がり、嫌な気分になりました。また、Hさんの愚痴を聞いて「Hさんのようにはなりたくない」と思った同僚もいるようです。
あるとき、Hさんは会社の先輩に転職を考えていることを打ち明け、相談に乗ってもらったのです。
そんなことがあった数カ月後、会社が新しいプロジェクトを受注しました。何と上流工程からかかわれるチャンスのある魅力的なものです。この案件ならばHさんも希望がかなうとやる気満々でしたが、プロジェクトにアサインされなかったのです。
もしかしたら先輩に相談したことが、会社の経営層に伝わり、プロジェクトのアサインに影響を与えたのかもしれませんが、本当のところは分かりません。
実はHさん、先輩に相談した後に転職サイトに登録していたのです。しかもその事実を、会社の同僚などにも何気なく吹聴していたのです。そんなことまで話していたHさんですが、せいぜい転職サイトで案件を見ながらこっちがいいか、あっちがいいかと見ているだけで、実際に転職のための行動はしていませんでした。もちろん職務経歴書や履歴書を準備することなどもまったくしていませんでした。
しかし、Hさんがためらっている間に、同僚が1人、2人と、転職していったのです。どうやら同僚も、会社の方向性、プロジェクトの進め方などに不満や不安があったようなのです。しかし同僚は転職について何もいっていなかったので、彼らが転職するとはHさんは考えていませんでした。
その後も何人か転職したため、会社側もこのままではまずいと気付き、退職の引き留めを厳しくしたようです。Hさんはその事実を、転職した元同僚から教えてもらったのです。「会社が転職を警戒しているらしいよ」と。
そうこうしているうちに、Hさんと同期のメンバーは2、3人だけとなっていたのです。そんな状況になっても（そういう状況だからこそでしょうか）、Hさんの仕事内容は転職を考え始めたころと変わりません。コーディング中心の作業ばかりです。上流工程からかかわれて、ユーザーとの接点ができそうな案件も、その後の受注は皆無で、まったく縁がありません。Hさんは「いつかは転職しないと」と、いまも考えています。まだ行動に移していませんが……。
Kさんの例のように、知人（今回の場合は先輩）に転職相談をしたところ、その相談相手から「一緒に働こう」と誘われるケースは多いと思います。積極的に中途採用を行うIT業界では、紹介した知人が入社したら奨励金を社員に与える会社もあるそうです。
もちろん、知人がいると仕事がしやすい、イメージしやすいなどのメリットがありますが、福利厚生や条件についてあまり確認せずに入社を決めると、失敗するケースも少なくありません。
会社を判断するに当たって、知人からの情報やイメージが先行してしまうため、客観的なデータなどによる比較ができないこともあるようです。知人から紹介された会社だからこそ、条件や会社の判断を冷静に行う必要があるのです。
また、Hさんのように会社の同僚・先輩に、転職に関する相談をしてしまうのは考え物です。転職の相談をされた相手は、結果として、いまいる環境のネガティブな意見を聞かなくてはなりません。改善するために問題を話すのではなく、転職するつもりで愚痴をいうだけでは、周囲に悪影響を与えているのは間違いありません。
いつのまにか情報がもれてしまい、退職を考えている社員として人事に影響を与えてしまうケースもあります。
価値観が似ていて身近な相談相手は、職場の仲間くらいだという人は多いかもしれませんが、転職に限っては、職場の仲間に安易に相談するのではなく、慎重に相手を選ぶべきです。
ただし、転職に関する相談相手のイメージが思い浮かばなれば、まずは気軽にコンサルタントに相談してみてはいかがでしょうか。
転職カウンセリング、転職支援を行う中で、よくITエンジニアからいわれるのが、「良い相談相手ができてよかった」という言葉です。
それにIT業界では、応募要件をはじめ、転職に関する情報はかなりの速さで変化していきます。多くのITエンジニアの転職をサポートする中で、「半年くらい前であれば、T社は○○な人は採用していなかったのに、いまは採用している」といった情報が乱れ飛びます。ですから知人から情報を得たとしても、もしかしたらそれはもう古い情報かもしれません。転職コンサルタントなら、常に最新の情報を持っているのです。
大学でWebデザインを専攻。在学中にインターンシップでデザインの実務を経験する。大学卒業後、SIerにて約3年間Web系のシステムエンジニア（SE）として開発業務に従事。主にJ2EEアプリケーションの開発とITエンジニアへの教育・育成業務を経て、人材紹介業界へ転職。現在ITエンジニアやデザイナー、営業などを中心に、IT業界出身者への転職サポートを行っている。
【社会人大学院特集】 10年後、なりたい自分になるために――社会人になってからのスタート。キャリアチェンジもキャリアアップも、勝負はこれから！
運用管理の基本を押さえ内部統制本番に備えよ 日本版SOX法施行が目前！効果的な内部統制を実施するため、まずは運用管理の基本を押さえよう
●IT資格試験の模擬問題を平日（土日祝日などを除く）1問ずつメールで配信するサービス「ITトレメ」。10月1日から一部のテーマを刷新します。
＠IT自分戦略研究所トップ｜キャリア実現研究室トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ

 

戻る