６月１２日から２２日にかけて日本に行って来た。前から読んでみたかった本、本屋で見つけて買った本、親がなぜかくれた本、全部で４冊読んだ。せっかく読んだので記録としてここに載せます。

Googleを支える技術 ‾巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)
Ｇｏｏｇｌｅの技術的な部分が分かり大変良かったのだが、この本を読むことによって、Googleを技術的に支えるGFS, MapReduce, BigTable, Sawzallを、オープン・ソースでやろうとしているＨａｄｏｏｐ (HDFS, Hadoop MapReduce, HBase, Pig) により興味が持てた。

道をひらく
ＰＨＰから出版されているこのシリーズの本田宗一郎の「やりたい事をやれ」、稲盛和夫の「成功への情熱」が大変よかったので、本屋でみつけ衝動的に買ってしまった。松下幸之助の言葉も心に響く。１１０ページの岐路にたちつつの項に勇気づけられた。

やはり次々と困難に直面し、右すべきか左すべきかの不安な岐路にたちつつも、あらゆる力を傾け、生命をかけてそれを切りぬけてゆく　－－　そこにこそ人間としていちばん充実した張りのある生活があるともいえよう。

情報は1冊のノートにまとめなさい 100円でつくる万能「情報整理ノート」
前から、アイデアノートを作ったり、物忘れがはやいので、ノートを持ち歩いて活用しようと考えていた所にこの本が目にとまった。全ての情報を一冊にまとめるのは中々よいアイデアだと思う。

白洲次郎名言集―男の品格2 (コスミック新書)
母親がくれた本。興味持てるかな？と疑いながら読み始めたが、読み始めたら面白く一気に読んでしまった。こんな人もいるんだなー。

前のエントリーにも書いたが、現在、Joel on Softwareを読んでいる。Ｊｏｅｌの文章能力が高いからだと思うが、Ｓｏｆｔｗａｒｅ開発の基本が優しく解説されている。小難しく書いてないから、頭にもスムーズに入ってくるし、１エントリーごと納得しながら読める。

今日、僕にとって、ためになったなーと特に思えた部分。

Painless Functional Specifications – Part 1: Why Bother?

I think it’s because so many people don’t like to write. Staring at a blank screen is horribly frustrating. Personally, I overcame my fear of writing by taking a class in college that required a 3-5 page essay once a week. Writing is a muscle. The more you write, the more you’ll be able to write. If you need to write specs and you can’t, start a journal, create a weblog, take a creative writing class, or just write a nice letter to every relative and college roommate you’ve blown off for the last 4 years. Anything that involves putting words down on paper will improve your spec writing skills. If you’re a software development manager and the people who are supposed to be writing specs aren’t, send them off for one of those two week creative writing classes in the mountains.

正直に告白すると、僕はスペックを書かずにプログラム（コード）を書き始める事が多々ある。理由は時間がかかって、面倒くさいからだ。要するにスペックを書くのが嫌いだ。なぜ面倒なのか？なぜ嫌いなのか？私のスペックを書く力が弱いのだ。Ｊｏｅｌによれば、「ライティングは筋力だ、書けば書くほど上達する」と本の中で言っている。僕は、それはプログラミングも同じだと感ずる。プログラム（コード）を書く力は、プログラムを書けば書くほど上達する。機能スペックがソフトウエア開発に及ぼす良い影響は明らかだ。僕は良いソフトウエアを作るためにも、より良いソフトウエア開発プロセスのためにも、よい機能スペックを書かなければならない。よいスペックを書くためにも、普段からもっと文章を書かなければならない。

前から読みたいと思っていた、Joel on Softwareを読み始めた。出だしから中々良いです。ソフトウエア開発に関して、今まで、当たり前の事だけど、言葉として上手に整理出来ていなかった事がいくつかあった。それらの事を彼の言葉を借りて再確認している状況。今日中々良いと思えたものThe Joel Testに付いて。

The Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

これはＪｏｅｌが考え出したソフトウエア開発チームの質をはかるテスト。

1. ソースコードバージョン管理システムを使っているか？
2. １ステップでアプリケーションをビルド出来るか？
3. 毎日コードをビルドしているか？
4. バグ管理システムを使っているか？
5. 新機能を追加する前にバグを修正しているか？
6. スケジュールは絶えずアップデートしているか？
7. コードを書き始める前にスペックは書いているか？
8. プログラマーが仕事に集中できる環境であるか？
9. 最高のツールを使っているか？
10. ＱＡエンジニアはいるか？
11. 仕事の面接で候補者にコードを書かせているか？
12. ユーザービリティ・テストをしているか？

パラダイス鎖国 忘れられた大国・日本を読み終えた。このエントリーは本を読んでいる間に考えた自分の事。前のエントリー「パラダイス鎖国」を読んで－その１－メモとはぜんぜん違う内容です。

本を読んでいる間に、僕も昔はパラダイス鎖国状態であった事を思い出した。全く海外に興味がなかった。では、どうして自分はパラダイス鎖国状態ではなくなったのか？

開国前（鎖国状態）：高校生の時までは東京が僕の憧れの土地であった。海外を含め別の地域などには興味がもてなかった。大学生時代、その日その日を生きるのに精一杯だった。海外の事など考えようともしなかった。社会人最初の１、２年、海外の事を考えるような状況になかった。英語が出来なかったので、その影響もあると思う。海外旅行に行こうとも考えた事がなかった。

開国前後：社会人２、３年目の頃、バックパックを担いで日本からヨーロッパまで一年かけて旅した写真家の本を読んだ。その人の困難を乗り越えながら新しいものに出会う、彼のライフスタイルに憧れた。自分の知らない土地に憧れ始めた。自分の知らない人に出会ってみたくなった。友人二人が海外旅行を経験した。それを聞き、僕も人生で一度くらい海外旅行をしなければと思った。バックパッカーの聖地、タイ・バンコクのカオサンの安宿街に泊まってみたかったが、初めての旅行でそんな勇気もなかったが、バックパックを担いで１ッ週間弱だと思うがタイを旅した。パスポートを確認したらそれは、１９９５年９月２４日だった。その頃はバック・パッカーに強い憧れを持っていた。テレビでは猿岩石がヒッチハイクの旅をして人気を集めていたと思う。

開国後：初めての海外旅行を経験すると、勢いがつき、ヨーロッパなどをバックパックを担いで旅して回った。バックパッカーと言っても、Ｍａｘ２週間の旅である。会社で休める範囲で行動していたので、連続２週間がＭＡＸだった。パリで出会って一日だけ一緒に行動したマイアミに住んでいたアメリカ人の家とかにも泊まりに行った。この頃、英語の勉強も始めた。ＴＯＥＩＣのスコアだけ見ると勉強の効果はなかった。仕事では、外資ソフトウエア会社に転職した。そこには最先端の技術が詰まっていると想像したから。そこで若干海外のエンジニアとのコミュニケーションが始まる。アメリカのソフトウエア会社に付いて書かれた本、ソフトウエア開発にまつわる話などを読み、影響を受け、アメリカでのソフトウエア・エンジニアのポジションに興味を持つ。そして、アメリカへ移住。

振り返ってみると、若い時の僕は意識的に鎖国していたわけではないが、結果として鎖国状態になっていた。理由として、その時期には自分が興味を持てる海外の情報が僕の所になかった。要するに、海外に付いて知らなすぎた。開国日は、初めての海外旅行だとおもうが、その行動を取った理由は、自分だって一度くらい海外旅行を経験しないととか、バックパッカーに憧れたとかそんなものだった。その後は、自分の興味に任せて拡大しつづけたのである。アメリカに移住したのは、アメリカに憧れたのではなくて、アメリカのソフトウエア・エンジニアというポジションに夢を持てたのが理由である。

おもてなしの経営学 アップルがソニーを超えた理由(中島 聡著)を読みました。読んだ記録としてのエントリーです。

この本の中で一番面白い部分は古川さんとの対談（第3章　特別対談　PartII　古川 享　私たちがマイクロソフトを辞めた本当の理由）。なぜって？、若かりし頃の中島さんのスリリングなソフトウエア開発の経験が読めるから。若かりし頃の中島さんってAppleのファウンダーのSteve Wozniakとだぶる部分があって、僕がSteveのBiography本「 iWoz」を読んだときに感じたエンジニアとしての興奮を、２人の対談から感じました。多分、アスキー時代、日本マイクロソフト時代の中島さんは、Ｓｔｅｖｅがゲーム作ったり、ＡｐｐｌｅＩＩを作っていた頃の日本版Ｓｔｅｖｅみたいな人だったのだと思います。推測ですが。マイクロソフト本社時代は、AppleのＭａｃチームのコアメンバーとして、MacのＵＩとか作っていたAndy Hertzfeldみたいな存在だったのかなーと思いをめぐらせています。（Andyに付いての知識はRevolution in The Valleyからです。）二人の対談を読んでいると、アメリカでのソフトウエア開発のエキサイティングな歴史を読んだ時と同じような、興奮が得られます。

話は飛ぶのですが、僕は２ｃｈユーザーでもなく、ニコニコ動画ユーザーでもありません。その為かも知れませんが、西村博之さんってどんな人かなって興味は持っていたのですが、この人を理解したいとか今日まで思ったことはありませんでした。その西村さんとの対談が、PartI　西村博之　ニコニコ動画と２ちゃんねるのビジネス哲学としてこの本には収録されています。西村さんの意見は中島さんの意見が普通に思えてしまうくらい、変わっていて面白いです。裏の裏を読んでいるような意見。結果として普通の人が考えている事と同じ結論になったりするのですが。たとえば普通の人はマイクロソフトはWindowsやＯｆｆｉｃｅを開発販売していいて凄い、儲かっていて凄いと考える。中島さんは、マイクロソフトは、スタートアップのように迅速に動けないから、ちょと今後はどうかなー？と言った意見。Ｐａｕｌ　Ｇｒａｈｍに限ってはMicrosof is Deadと彼のエッセイに書いている。僕なんかは中島さんの意見やＰａｕｌの意見に影響を受けている層。でも西村さんはその上を行く。上かはどうかは分からないが、ぜんぜん違った意見。

西村　（前略）たとえば、死に物狂いで働かないともたない会社と、午前９時から午後５時までダラダラ仕事をしていても利益の上がる会社って、どちらに価値があるかといえば僕は絶対に後者だと思うんですよ。肉体労働しないと利益が生まれない構造と、賢い人が仕組みを作って肉体労働しなくても利益が生まれる構造のどちらがいいかといえば、仕組みで利益を生む構造のほうがいいじゃないですか。そういう意味では僕は、マイクロソフトはそんなに悪い会社だと思わないですけどね。
中島　そうか、そんな考え方もあるか。
(Page 131)

西村さんの、一般的な結論を、一般的とは違った方向から導いてくる、ユニークさに彼の頭の良さを感じた。

もう一つ「おもてなし」に付いて、

（前略）技術を極めた先にあるもっと大切な差別化要因が、実は機能の豊富さや知的財産ではなく「おもてなし」である、というのが本書である。 （Ｐａｇｅ　４）

「技術を極めた先にある…」の部分に僕は、「おもてなし」の前に中身がすばらしいのは成功の為にはあたりまえと書いてあるように読めた。いくらウエイターやウエイトレスのサービスの良いレストランでも料理がまずかったら僕は行かない。今の時代、「提供する中身が良いのは成功の為の必要条件、おもてなしは十分条件」と思うのだがどうでしょうか？

この本は、なぜ僕が中島さんのブログLife is beautifulを読む事が好きなのか分った本でした。

次は、ペア本の「パラダイス鎖国 忘れられた大国・日本」を読みます。

ウェブ時代 5つの定理 この言葉が未来を切り開く!の第５定理「大人の流儀」の中から印象に残った言葉

p.259
自分がやらない限り世に起こらないことを私はやる。── ビル・ジョイ
I try to work on things that won’t happen unless I do them.──Bill Joy
Hope Is a Lousy Defense, Wired, November 12 2003

尊敬するビル・ジョイの言葉はスケールが違うなー。なぜ彼を尊敬しているかというと、ビル・ジョイがBSD UNIXの父みたいな人だから。僕がキャリアを始めた時の最初の仕事はSun MicrosystemsのSunOS(Solarisの前のOS)上で、C言語を使ってのソフトウエア開発だった。そのSunOSの元はBSD Unixなのであった。ただ単純にこんな凄いOSを作るなんて凄すぎるなんて思ったものだ。今の人達がLinuxの開発者のLinus Torvaldsに憧れているようなものだ。当時は、BSDがUC Berkley発のOSということで、そのUC Berkleyに留学してみたいとも夢描いていた。そして、Sun Microsystemsは当時もっとも憧れていた会社である。そんな理由でビル・ジョイの言葉には少し反応してしまう。

「僕にはスケールがでかすぎる言葉だな」と感じていた時、次の文章が目に飛び込んで来た。

p.260
しかし、この言葉はそんな一握りの天才だけに許された言葉なのでしょうか。
私はそうは思いません。
どれほどの数の人がいても、一人ひとりの個性や経験や環境はすべて異なります。さまざまな個性や志向性を組み合わせていけば、「自分がやらない限り世に起こらないことをする」ことは必ずできる。これはだれにも開かれた考え方で、それがフラット化するこれからの時代に、仕事の上でコモディティ化しないための心構えだとも思うのです。
梅田望夫

梅田さんからの若者達、がんばっている人々への言葉を見つけた。第５定理の中ではこの部分が一番心に響いた。能力は普通だけど、がんばっている人達（自分もこのカテゴリーに入ると思う）が、今後、もう一段上を目指して頑張って行く元気が湧く言葉だと思う。

ウェブ時代 5つの定理の第４定理「グーグリネス」の中から印象に残った言葉と思ったが、この第４定理はミニＧｏｏｇｌｅ解説本みたいになっていいて、無理してＧｏｏｇｌｅの人が言った言葉を集めた感じがし、結果的に”これだ!”という言葉が見つからなかった。強いてあげれば次の言葉

p.201
「ニューノーマル」時代における成功とは、タイムマネジメントに尽きる。
この時代における通貨は、時間なのである。── ロジャー・マクナミー
Success in the New Normal is all about time management. Time is the currency of this age. ──Roger McNamee
How to Succeed in the New Normal, SandHill.com, May 23 2005
参考
文藝春秋｜梅田望夫著「ウェブ時代　５つの定理」｜ビジョナリーたちの名言リンク集　第４定理「グーグリネス」

時間の使い方は 本当に重要だと思う。アメリカに住んでいるので他の人より自分の時間は多いと思うが、それでも自分が自由に使える時間は限られている。何にフォーカスするのかを決め、その時間を大切に使わなければならない。

—————————————————-

第４定理「グーグリネス」をよんでいて考えた事、「梅田さんはＧｏｏｇｌｅのではなくて、”はてな”について話すべき」なのではないかという事。第４定理を読む前に、Paul Grahamのエッセイ：You Weren’t Meant to Have a Bossを読んだので、第４定理を読みながら、梅田さんとPaul Graham(ポール・グラハム)を知らないうちに比べていた。アップルとオレンジを比べているとは分かっているのだが。Paulはベンチャーを起業し、そして成功した経験を持つ。最近はY-Combinatorを通して、若者の起業を助けている。エンジェル投資家＆アドバイザー。一方、梅田さんは日本大企業をターゲットにしたコンサルタント＆投資家＆はてな取締役。共に若者向けの本を執筆。Paulは上記のエッセイのなかで、若者に向けて、大学を卒業したら、大企業(グーグル)で働くよりも、ベンチャー（スタートアップ）を起こして、そして失敗したほうが、よっぽど良い経験になると語っている。成功できたらもっとすばらしいが。一方、梅田さんはＧｏｏｇｌｅは良い会社だよ、グーグルみたいな良い会社で働いて経験をつみなよ、きっと楽しいよって、間接的に若者に語っているように思える。どちらが正しいのかは、分からないし、正解はないと思う。でも、梅田さんは、Ｐａｕｌ Grahamが若者の起業にＢＥＴ（賭け）しているように、はてな（ベンチャー）にＢＥＴしているのに、はてなの事にはあまり触れず、グーグルの事ばかり書いている。なんとなく、梅田さんはグーグルの事ではなく、はてなの事を書くべきだったと思う。成功しているグーグル（既に大企業）について書くのではなく、将来のグーグルを目指している若者達が発する熱い言葉を、日本の将来ある若者（実年齢ではなく、心が若い人達）に向けて書いて欲しかった。

(*) 梅田さんの第４定理と、Ｐａｕｌのエッセイの目的が違う事は理解しているが、先の考えがわいて来た。

ウェブ時代 5つの定理の第３定理「技術者の眼」の中から印象に残った言葉

私は根っからの、テッキーナードだ。そして科学を愛する。
科学はリソースを何乗にも膨らませるから。
正しい方針と正しい市場環境は必要だ。
でもケタ違いにリソースを膨らませるのは科学だけ。
科学は、何かを10％や20％良くするのではなく
100倍良くする可能性を秘めている。
私はその力に興奮を覚える。── ビノッド・コースラ

At heart, I’m a techie nerd. I love science because it’s a huge multiplier of resources. You need the right policy. You need the right market environment. But the one thing that multiplies resources by a factor of 10 is science. It has the potential to do something not 10 percent better or 20 percent better but 100 times better, and that power is what’s so exciting to me. ──Vinod Khosla

文藝春秋｜梅田望夫著「ウェブ時代　５つの定理」｜ビジョナリーたちの名言リンク集　第３定理「技術者の眼」

過去の偉大な人々は 科学を用い何度も１００倍良くなるソリューションを提供してきた。これは事実である。インターネットの出現は既存の情報共有を１００倍？１０００倍？１００００倍？以上向上させた。自分（達）も日々の努力の中から、１００倍良くなる可能性を発見出来ると信じて粘り強く続けるしかない。Linearの向上じゃなくて、Quadraticな向上を信じて。

————————————————————

第３定理の中に、Paul Grahamの、ハッカーと画家からの引用がある。第３定理に引用された「ハッカーと画家の共通点」よりも、違う部分をPaulはハッカー（プログラマー）として伝えたかったのだと思う。

Paul Grahamはハッカーと画家は、良い作品を作る際の、”Ｍｅｔｈｏｄology”が似てるという事をハッカーかつ画家として言いたかった。（私の意見）

ハッカー（プログラマー）と画家は作品を作る上で似ていると。殆どの画家は部分部分を書いていく事によって全体を書くような事はしない。たとえば、レンガ の建物を描く際に、レンガ一つ一つを描いていって全体を構成するような事はしない。レンガ一つ一つを描く作業はつまらないし、半分も書かない内にその絵を 描くのに飽きてしまうからだ。 そんな絵はつまらない絵になってしまう。殆どの画家は全体のスケッチを描いて、全体の構成を描いてから部分部分を描いていく。ハッカーも同じで、部品から 作り始めると、中々全体を通して動く物を作る事が出来ないし、興味もだんだんうすれ、途中で挫折してしまう。ハッカーもすぐ動く物を作って、少しずつ改善 していくアプローチの方が成功するものづくりが出来ると。上手に日本語化できなかったので、原文の一部を下記に載せときます。全文は下記のリンクにあります。

Morale is key in design. I’m surprised people don’t talk more about it. One of my first drawing teachers told me: if you’re bored when you’re drawing something, the drawing will look boring. For example, suppose you have to draw a building, and you decide to draw each brick individually. You can do this if you want, but if you get bored halfway through and start making the bricks mechanically instead of observing each one, the drawing will look worse than if you had merely suggested the bricks.

Building something by gradually refining a prototype is good for morale because it keeps you engaged. In software, my rule is: always have working code. If you’re writing something that you’ll be able to test in an hour, then you have the prospect of an immediate reward to motivate you. The same is true in the arts, and particularly in oil painting. Most painters start with a blurry sketch and gradually refine it. If you work this way, then in principle you never have to end the day with something that actually looks unfinished. Indeed, there is even a saying among painters: “A painting is never finished, you just stop working on it.” This idea will be familiar to anyone who has worked on software.

Design and Research

ウェブ時代 5つの定理 この言葉が未来を切り開く!の第２定理「チーム力」の中から印象に残った言葉

好きな人と働かなければならない。－　ロジャー・マクナミー

You have to work with people you like. – Roger McNamee

文藝春秋｜梅田望夫著「ウェブ時代　５つの定理」｜ビジョナリーたちの名言リンク集　第２定理「チーム力」

大小色々な会社の為に今日まで働いてきた。会社に属しているとなかなか出来ない事がいくつかある。その一つは働く仲間を真に選べない事であると思う。ラッキーな場合は選べる事もできると思うが。この定理を満たすためには、本当に好きな仲間と起業するしかないと感ずる。良いチームは、好きな人、尊敬できる人、信頼できる人としか築けないと思う。