好きなもの
好きなものと、その理由の記録。
意味のある名前
名前が意味をそのまま表すのが好きです。良い名前は、読むだけでそれが何かを教えてくれる。
IUPAC 系統名（化学）
「2-メチルプロパン」。この名前は分子の構造をそのまま綴っています。主鎖はプロパン、炭素三個が一列に並び、2 位の炭素にメチル基が一つ付く。図鑑を開かなくても、名前から構造式が描けます。俗名の「イソブタン」は呼びやすいけれど、名前に構造はありません。何と呼ぶかは分かっても、どんな形かは分からない。
この発想には原点があります。1787 年の『Méthode de nomenclature chimique』が起こした命名改革は、化学の名前を、個別に覚える記号から規則で導けるものへと変えました。
逆から考える
逆から考えるのが好きです。正面から通れない道も、裏返すと見えてくることがある。
逆に考えよ、常に逆に
マンガーが 1986 年にハーバード校の卒業式で行ったスピーチは、題からして逆です。『どうすればみじめな人生を送れるか』。幸福の話を、裏返して語る。その中で彼は数学者ヤコビの言葉を引いています。『逆に考えよ、常に逆に』。
このスピーチは『穷查理宝典』に収められています。
一つのことを、うまく
一つのことだけをする小さな道具が好きです。プログラムはそれぞれの役割を、うまくやり遂げる。あとは組み合わせに任せます。
各プログラムは一つのことを、うまく
1978 年、『Bell System Technical Journal』の Unix 特集号は、一篇の序文とともに刊行されました。そこにはこの流儀が四つの箴言にまとめられていて、第一は「Make each program do one thing well」——各プログラムは一つのことを、うまくやれ。新しい仕事は、旧プログラムに「機能」を継ぎ足すかわりに、新しく書け、というものです。序文の署名は McIlroy、Pinson、Tague の三人。筆頭の McIlroy はパイプラインの発明者で、この箴言は今も彼の名とともに語られます。
いっそう広く流れている言い方もあります。1994 年、Peter Salus の『A Quarter Century of UNIX』は、McIlroy の言葉として三つの文を記しました。一つのことをして、それをうまくやるプログラムを書け。互いに協力するプログラムを書け。テキストストリームを扱うプログラムを書け——それが普遍のインターフェイスだから。cat、grep、wc。どれも小さな仕事しかしない道具です。けれどパイプでつなぐと、単独では決してできない仕事までやり遂げられます。
特例のためには破らない
規則は少ないほうが守られます。特例をひとつ開くごとに、規則はほどけていく。
特例は規則を破るほど特別ではない
Python の設計哲学は、The Zen of Python という 19 行の小さな詩にまとめられ、PEP 20 として公開されています。端末で import this と打てば、そのまま読めます。その第八行——特例は、規則を破るほど特別ではない。すぐ次の行では一歩引いて、それでも実用性は純粋さに勝る、と認めています。規則の壁には、換気の窓がひとつ開いています。
好きな理由は実利的です。規則が多ければ特例も増え、特例が増えた規則はやがて飾りになります。数を絞り、一本一本を本気にするほうが、かえって守られます。『いつも最もシンプルなものを選ぶ』という好みと、この取捨は同類です。複雑さが苦手なのではなく、特例の代金をあとで何度も払わないための選択なのです。
直せるほどシンプルに
直せるほどシンプルな設計が好きです。ごく普通の道具だけでも、もう一度動かせます。
普通の整備士が直せる飛行機
KISS の原則、Keep it simple, stupid。ロッキードのスカンクワークスで主任技師を務めたケリー・ジョンソンの言葉とされています——U-2 と SR-71 ブラックバードを生んだ場所です。いちばん有名なのはこんな逸話。彼は設計チームにひと握りの道具を渡し、こう言いました。設計中のこのジェット機は、戦場で普通の整備士がこの道具だけで直せるものでなければならない、と。stupid が指すのは人の愚かさではありません。物がどう壊れるかと、手元に残された道具の数、その釣り合いのことです。
出典には決め手がありません。1960 年にはアメリカ海軍に Project KISS という計画があり、1938 年の新聞にはさらに早い変種が見つかります。誰が先に言ったかより、大事なのはこちら。シンプルを、確かめられる基準にしたことです。造った人が感じる簡単さではなく、直す人の手元で試される。ものをシンプルに設計するのは、あとから触れるすべての人への配慮です。
自信に届いたら、やめる
テストは手段で、動くコードが納品物です。自信は必要なぶんだけ買えばいい。
報酬は、動くコードのために
Stack Overflow に How deep are your unit tests? という質問があります。いちばん上に選ばれた回答は、Kent Beck——テスト駆動開発の創始者、エクストリームプログラミングの生みの親——によるものでした。答えは率直です。私の報酬は動くコードに対して払われるのであって、テストに対しては払われない。だから私の哲学は、必要な水準の自信に届く最小限のテストにとどめる、というものです。括弧書きにはこうあります。その水準は業界標準より高いはずだが、慢心かもしれない、と。
続けて彼は自分のさじ加減を明かします。いつもは犯さない間違いにはテストを書かない。条件の複雑なロジックは見誤りやすいから念を入れる。チームで書くときは、みんなが間違えやすいところに重点を置く。彼にとってテストは、ひとつずつ勘定する予算です。書くたびに、確かな自信と引き換えになります。テスト駆動開発の創始者の口から出る「最小限でいい」。多く書く一本には、自分で理由が要るのです。
モードはいらない
良いインターフェイスに、見えない状態はいらない。指したところに、すぐ効く。これから何をするか、いちいち告げる必要はありません。
ナンバーは NO MODES
切り取り、コピー、貼り付け。Larry Tesler が同僚の Tim Mott と、Xerox PARC のエディタ Gypsy で生み出し実装した操作です。彼は生涯、「モード」のあるインターフェイスに反対しました。どこかへ出入りしてはじめて操作できる設計——キーを一度叩いて挿入モードに入り、文字を打ち、もう一度叩いて出る。彼の望んだモードレスなインターフェイスは、すべての操作がいつでも手もとにあります。車のナンバープレートは NOMODES、個人サイトのドメインは nomodes.com。
モードの欠点は、インターフェイスが見えない状態を覚えていることです。同じ操作をしても、効き方はいまどのモードに隠れているかで変わる。モードレスはその帳簿を破り捨てます。操作はその場で効き、出入りの儀式はない。PARC を出てからも、Tesler はこの主張を手放しませんでした。インターフェイスを作る人への、ひとつの戒めです。ユーザーに、自分の状態の帳簿を付けさせないこと。
失敗は、目に見える形で
その場ではっきり失敗するものが好きです。エラーは起きた瞬間に姿を現すほうが、あとになって別の顔をして戻ってくるより、ずっといい。
失敗は即座に、目に見える形で
Jim Shore が 2004 年 9・10 月号の『IEEE Software』に発表した記事『Fail Fast』。書き出しはこうです。ソフトウェア開発でいちばん腹立たしいのはデバッグだ、と。数分眺めれば分かるバグなら構いません。嫌なのは、何時間も問題なく動いた末に、特殊な条件でだけ姿を現すバグ、スタックトレースが行き止まりに終わるバグです。彼の答えはシンプルでした。ソフトウェアを fail fast に作る——問題が起きたら、即座に、目に見える形で失敗させる。反対のやり方は「ゆっくり失敗する」（failing slowly）。問題を自動で回避するソフトは頑丈に見えて、実際にはエラーを飲み込み、あとになって奇妙な形で崩れていきます。
例は設定ファイルの読み取りです。プロパティが見つからないとき、既定値を返すか、例外を投げるか。既定値のシステムは、設定の打ち間違いに気づかないまま動き続け、ユーザーが使い始めてから原因不明のもたつきに見舞われる。調べるのに何日もかかるかもしれません。fail fast のシステムは、打ち間違いが入った瞬間に止まり、足りないプロパティとファイル名をそのまま告げ、30 秒で直せます。鍵になる道具はアサーション——条件をひとつ検査し、満たされなければ失敗する小さなコードです。どこに入れるか。彼はコメントを探せと言います。コメントには、コードへの前提がうっかり書き残されている。それを見たとき、あるいは自分で書きたくなったとき、アサーションにできないか考える。アサーションはシステムの継ぎ目に置いて、間違った使われ方を暴く役です。メソッドそのものの正しさは、テストに任せます。
「即座に、目に見える形で」は、一見するとソフトウェアを脆くするように聞こえます。彼は逆だと言います。バグは早く見つかるほど直しやすく、本番に届く欠陥は減る。ただし、何もかもクラッシュさせろという話ではありません。顧客先に届いた後は、グローバルなエラーハンドラで予期しない例外を受け止めて報告する。一方で、本番環境でアサーションを切ることには明確に反対しています。顧客先で起きたエラーはテストをすり抜けてきたもので、いちばん再現しにくいからです。黙っていてもエラーは消えません。最も見つけにくい時まで先延ばしになるだけです。私が自分のシステムを触るときも、なるべくそうしています。読めないものは読めないと、その場で言う。
枯れた技術の水平思考
熟れた技術に、新しい使い方を考えるのが好きです。技術は古いほど安く、発想は新しいほど面白い。
モノクロ画面でカラーに勝ったゲーム機
「散々使いこなれて枯れてきた技術を水平思考し、まるっきり違う目的に使うことによって、ヒット商品は生まれ出る」。こう語ったのは横井軍平。任天堂の技術者で、ゲーム＆ウオッチもゲームボーイも、彼の手から生まれました。この言葉は 1997 年のインタビュー集『横井軍平ゲーム館』に収められています。平たく言えば、こういうことです。いちばん新しい技術を追わず、使い込まれて安くなり、性質の知れた技術を、まったく別の用途へ横にずらす。新しいものは、そこから生まれます。
1989 年のゲームボーイは、この考えの見本です。同時代の携帯ゲーム機がこぞってカラー液晶に替えていく一方で、ゲームボーイはモノクロ画面のまま、単三電池四本で一日中動きました。安くて、壊れにくい。けっきょく市場の八割以上を取りました。好きな理由は、私の信条と同じところにあります——シンプルなほど、長く続く。古い技術は時間と市場にふるいにかけられたもの。簡単で、安くて、どこにも知っている人がいる。だから長く生きる。ゲールの法則が言うのも同じことです。動く複雑なシステムは、例外なく、動く単純なシステムから進化したものです。