最近読んだ本

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

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

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

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

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

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

Advertisements

The more you write, the more you'll be able to write.

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

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

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によれば、「ライティングは筋力だ、書けば書くほど上達する」と本の中で言っている。僕は、それはプログラミングも同じだと感ずる。プログラム(コード)を書く力は、プログラムを書けば書くほど上達する。機能スペックがソフトウエア開発に及ぼす良い影響は明らかだ。僕は良いソフトウエアを作るためにも、より良いソフトウエア開発プロセスのためにも、よい機能スペックを書かなければならない。よいスペックを書くためにも、普段からもっと文章を書かなければならない。

The Joel Test

前から読みたいと思っていた、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?

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

  1. ソースコードバージョン管理システムを使っているか?
  2. 1ステップでアプリケーションをビルド出来るか?
  3. 毎日コードをビルドしているか?
  4. バグ管理システムを使っているか?
  5. 新機能を追加する前にバグを修正しているか?
  6. スケジュールは絶えずアップデートしているか?
  7. コードを書き始める前にスペックは書いているか?
  8. プログラマーが仕事に集中できる環境であるか?
  9. 最高のツールを使っているか?
  10. QAエンジニアはいるか?
  11. 仕事の面接で候補者にコードを書かせているか?
  12. ユーザービリティ・テストをしているか?
僕が働いてきたソフトウエア会社は、どこも、1番、4番、10番は満たしている。しかし、その他の部分は会社に寄って違う。7番に関しては、ソースコードが仕様書だとか言って、いきなりコードを書き始める事もある。6番に関して、いざ開発が始まるとスケージュールのアップデートなどは後回しになってしまう。インタビューでは、僕が今日の面接官は出来る人だったなと感じた人は、インタビューの中で、実際のコードもしくはpseudoコードを書かせていたなー。上記の12リスト当たり前の事だけど、当たり前に出来ていないので、この本の中でJoelが上手に説明してくれていて大変役に立つ。この本は読むのが楽しい。
(*)この本はJoelのブログを元に書かれています。

「パラダイス鎖国」を読んで-その2-自分について

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

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

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

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

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

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

「パラダイス鎖国」を読んで-その1-メモ

パラダイス鎖国 忘れられた大国・日本を読み終えた。このエントリーは自分の為のメモとして。

メモ1(ページ044辺り)

ハードウエア産業における2つのグローバル化公式

  1. 数の多いほうが勝ち
  2. グローバルブランドの確立と維持

ハードウエアの生産にはソフトウエアと違いコストがかかる。数を作れば作るほど一台当たりのコストが安くなる。そこに競争力が生まれる。ブランド力があれば少しくらい高くても買ってもらえる。この二つはソフトウエア及びインターネットビジネスにも当てはまる。ソフト及びネットビジネスは、コストは数に限らず、限りなく一定である。ソフトウエアであれば、お客さんに納品するコストは、CD一枚?送料?ダウンロードの為のホスティング代?ネットビジネスであれば、ウエブ・ホスティング代?ハードと比較すると限りなくゼロに近い。しかし、ニッチなものを除き、基本的にはマーケットシェアを取った1つ・2つの企業しか生き残れないので、ソフト・ネットビジネスでも、1の数は大事である。2は基本的にどんなビジネスにも当てはまると思う。お客さんはブランド力のある企業から商品を買いたいものである。ブランド力は信頼と言う言葉と置き換える事ができると思う。

メモ2(ページ056辺り)

高度成長期の日本企業は、欧米の技術を学んで自社開発し、高品質・低コストの製品を作り、先進国に輸出していた。しかし最近はそれをしない。(<-本の中に直接はこうは書いてない。自分の意見込み)

ソフトウエア・ネットビジネスに関してこれをしないのは、そうする事が難しいからではないかと考える。ハードウエアに関しては、韓国、台湾、中国からより高品質で低価格な商品がでて来る。しかし、インド・中国から低価格で高品質なソフトウエア・ネットビジネスが出て来たとは聞いた事がない。ソフトを開発する為の人員はインド・中国から供給されているが。日本も同様、ソフトウエア・インターネット関連ビジネスに関してはこうする事が難しいのではないか?たとえばオラクルより2倍速いデーターベースをオラクルの半額で売るなんてのはかなり難しい(殆ど無理?)。

メモ3 (ページ123辺り) メモ1の2つの公式は今の時代にあわなくなっている。そこで著者は下記のアプローチを提案している。

「試行錯誤戦略 (けもの道戦略)」

日々、試行錯誤して生きて行くというのもありかもと思えるが、絶えず試行錯誤するのも辛い時もあると思う。そこで、似てるけど、ちょっと違う僕の提案。イノベーションを生み出すために、Googleには「20%ルール」がある(Wikipedia: Google Innovation Time Off)。Yahoo!には「HackDay」がある(Wikipedia: Hack Day)。エンジニアは、絶えずイノベーションを起こそうと行動しているのではなく、普段は自分がやらなければならないことをやり、Googleの場合は20%を何か違う物に費やす時間があり、Yahoo!では、みんなで集まってHack(イノベート)する日があるのである。絶えずイノベーションを起こす事が仕事という人もいるとは思うが。この方法を個人に当てはめると、自分のプライベートの時間の20%を何か新しいものに費やすとか、月に一日、個人Hackの日を設定するなどして、新しい事を始めたり、学んだり、作ったり、考えたり、何か行動する時間を作ったりするのも、一つの手だと思う。

海部さんを見習って、この戦略にコピーを考えた。「個人イノベーション・タイム・オフ戦略」、「個人ハック・デイ戦略」。ちょっと今一だなー。

「おもてなしの経営学」を読んで

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

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

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

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

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

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

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

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

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

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

第5定理「大人の流儀」の中から

ウェブ時代 5つの定理 この言葉が未来を切り開く!の第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定理の中ではこの部分が一番心に響いた。能力は普通だけど、がんばっている人達(自分もこのカテゴリーに入ると思う)が、今後、もう一段上を目指して頑張って行く元気が湧く言葉だと思う。