Fine Software Writings 再読(2)

青木さんのサイト、まだまだ読み続けてます。

前回はこちら

私のヒーローたち

http://www.aoky.net/articles/paul_graham/heroes.htm

中学入試の面接などで、「尊敬する人は誰ですか?」などという質問があったりしますが、こうした質問は子供に限らずその人の本質が出てしまいます。

ポール・グレアムにとってのヒーロー像というのは、まさに彼そのものを表している気がします。

このリストに現れる人はみんなある2つの資質を持っているのだ。自分の仕事に対してほとんど過剰なまでに神経を使っていたということ、そして絶対的に誠実であったいうことだ。誠実と言ったのは、信頼できるという以上に、決して迎合しないということだ。

さて、このエッセイの中盤に彼の恩師が書かれています。自分の先生を「ヒーロー」として挙げることができるのは幸せなことです。

この一節を読んだとき、過去に教えを受けた先生達のことを思い浮かべました。彼らは、ヒーローとは少し違うかもしれませんが、それでも私に影響を与えたのは間違いありません。

今ここで一人一人名前を挙げて語るということはしませんが、いずれ機会があれば書いてみたいです。

あなたにとって、ヒーローとなる先生はいますか?

ギリガン島からの脱出

http://www.aoky.net/articles/jeff_atwood/escaping_from_gilligans_island.htm

マコネルによる「36のよくある誤り」を頭に叩き込んでおけという内容。

マコネルの本は読んだことはないですが、項目のタイトルだけ見てもなるほどとうなずいてしまいます。

自分の関わる(関わってきた)プロジェクトを想起すれば、該当する項目を半ダースぐらい挙げるのはたやすいのではないでしょうか。

誤りを犯すことは避けられないにしても、同じ誤りを繰り返すのは避けられることなのだ。

と書いてますけど、実はこれも結構難しいですよね。

ラピッドデベロップメント―効率的な開発を目指して (MicrosoftPRESS)

ラピッドデベロップメント―効率的な開発を目指して (MicrosoftPRESS)

Googleのようにコンピュータを組み立てる

http://www.aoky.net/articles/jeff_atwood/building_a_computer_the_google_way.htm

かつて私が自作サーバカンファレンスについてのレポートを書いたとき、一ヶ月ぐらい見向きもされなかったのに誰かが発見し、そして多くの人がブックマークしていきました。しかもその興味の中心が pixiv のベニヤ板サーバで、しかもネガティブととれるコメントが多く大変心苦しい思いをしたものです。あれ、私個人は純粋に結構すごいと思っていたんですよ。常識にとらわれない素晴らしい発想だなって。

しかし、この文書を読んで初めて、ベニヤ板サーバが彼らのオリジナルではないということを知りました。

当時のベンダのDellCompaqIBMなどから構成済みのラックマウントサーバを買う代りに、Googleはサーバインフラを自分の手で作ることを選んだのだ。たわんだマザーボードやハードディスクは、文字通り手作りのベニヤの骨格に支えられている。電源スイッチは前面にそっけなくつけられ、ネットワークケーブルが側面 から垂れ下がっている。下手に引き回された電源ケーブルは蛇行しながら後部の電源へと接続されている。

10年前も今と変わらず、このサーバを批判する人もいたようです。しかし Coding Horror の Jeff Atwood は Google のベニヤ板サーバを評価しています。

これらのGoogleの初期のサーバを見て、素人じみていて火事になりかねないと思う人もいるかもしれないが、私は違う。ここにはコモディティハードウェアが今日のインターネットを形作っていることへの先見の明が認められる。このサーバを見たとき、すごくしっくりするものがあった。私が同じ境遇にあれば、まさに同じものを作っただろう。このラックは、「安価に正しくやりたいなら自分で作ること」という、現場におけるコモディティx86マーケットDIY精神の完璧な例だ。

「イノベーション」という言葉に少しでも関心があるのであれば、この危なげなベニヤ板サーバと真っ直ぐに向き合うべきではないかと思います。

あらゆることがうまく行かなければどれくらいかかるか?

http://www.aoky.net/articles/jeff_atwood/how_long_would_it_take_if_everything_went_wrong.htm

最悪のケースをよく検討したいとき、私は開発者にあらゆることがうまく行かなければどれくらいかかるかと聞いている。人がする最悪の見積りというのは、真の最悪のケースよりは楽観的な最悪のケースとなっていることが多いのだ。

人って、一番不確実でしかも致命的な箇所に限って楽観的な判断を下すんですよね。

要するに思考停止です。

常日頃から気をつけたいところです。

一見無害だが危険な言葉

http://www.aoky.net/articles/gerald_weinberg/innocent-but-dangerous-language.htm

プログラマがこんな風に言うのを、何度聞いたことがあるだろう? 「簡単さ! 1行修正するだけだ!」

胸にグサグサと刺さります。

すいませんすいません。

ワインバーグのコンサルティング目標

http://www.aoky.net/articles/gerald_weinberg/weinbergs-consulting-target.htm

私が本やエッセイを書いたりセミナーで教えたりするときには、失敗について基本的な基準を設けている。これをワインバーグの目標と呼ぶことにしよう:

私の作品に触れた後、受け手はその題材について前より関心をなくしてはいないか?

この質問に対する答がイエスなら、私は失敗したことになる。

この視点は今まで持ったことがありませんでしたが、確かに重要なことです。

私のブログを読んでコンピュータの世界に興味をなくしてしまった人がいたら後でこっそり教えてくださいね。

天一? まさか。私の記事を読んで、食べたくなりこそすれ興味が失せるなどということはありえません。

天一かけてもいいですよ。

あらゆる年代の批評家に対処する

http://www.aoky.net/articles/gerald_weinberg/dealing-with-critics-of-all-ages.htm

内側のであれ外側のであれ、批評家の言葉に耳を傾ける前に使えるいいテストがある。

彼ら自身が書いたものに、彼らの批評の価値を裏付けるものはあるか?

このテストによって、高校や大学の英語(国語)の教師のほとんど、たいていの友人、多くの編集者やエージェント、それにあなたのお母さんが除外されることになるだろう。

これはちょっと極端過ぎかなと思います。

たとえ彼らが自分のことを棚に上げていたとしても、自分に向けた批評にはやっぱり価値があると思うのです。

もちろん、こうした批評に振り回されるぐらいなら上記の通りにスルーしてしまった方がいいと思いますが。

気付くことの意図されていないものに気付くこと

http://www.aoky.net/articles/gerald_weinberg/noticing_what_was_not_meant_to_be_noticed.htm

まわりに注意して、気付くことの意図されていないものを5つ見つけられるかやってみる。それを書き出して、少なくともそのうちの1つを含めてストーリーを書く。

これはとてもいい暇つぶしになります。

私も早速電車の中でやってみました。

  • 吊り革。リングの部分と革の部分の間が随分黒く汚れている。手垢かと思ったら革と根元の鉄との接続部も汚れていた。
  • 網棚。いくつかのパイプがボルトでしっかりと固定されていた。
  • 中吊り広告を挟む鉄の部分。18-1、18-2などのように番号が振られていた。

これを試したのが数日前なので、後は忘れてしまいました。

でも、これだけで新しい発見ができたのでなかなか楽しかったです。

また気が向いたときにでもやってみます。