# ハッカーと画家 チートシート
「場面 → 主張・示唆 → 根拠(章)」。エッセイ集なので、行動手順よりも**ものの見方・判断基準**が中心になる。章番号は overview.md の章インデックスに対応。
## 設計とものづくり
| 場面 | 主張・示唆 | 根拠(章) |
| --- | --- | --- |
| 仕様が固まらないまま書き始めるのが不安 | プログラムの仕様が完璧であると期待するのは非現実的。書きながら理解せよ。プログラミングそのものがスケッチである | 第2章 |
| 設計を固めてから実装したくなった | 早過ぎる最適化と同じく「早過ぎる設計」を警戒せよ。仕様を創る一番の方法はそれを実装することだ | 第2章 |
| 道具・言語の柔軟性を評価する | ペンではなく鉛筆であるべき。落書き・ぼかし・塗りつぶしができるか。動的型付けが有利なのは、早くデータ表現にコミットせずに済むから | 第2章 |
| 最初の出来がそこそこだった | 捨てて再設計せよ。「良いデザインは再デザインだ」。「ここまで出来たならもっと出来るはずだ」と考えるには自信がいる | 第6章 |
| 完成品を作り上げてから見せたい | 「マリア様万歳作戦」は惨劇への切符。できるだけ速くプロトタイプをユーザーの前に出せ。ただし模型で終わらせず、そのまま最終製品まで詳細化せよ | 第11章 |
| 正確に作ろうとして手が止まる | ゆっくり輪郭をなぞると誤差が積み重なって線が合わなくなる。だいたいの位置にざっと線を置き、次第に詳細化せよ（絵画の教師の教え） | 第11章 |
| 問題がうまく解けない | 問題そのものを疑え。「良いデザインは正しい問題を解決する」。解と同じように問題も改善してよい | 第6章 |
| 独自性・自分のスタイルを出したい | まず正しくあることを優先せよ。最も偉大な作り手は一種の滅私状態にあり、正しい答えを知りたいだけだ。持つべきスタイルは「どうしてもそうなってしまう」もの | 第6章 |
| 説明を尽くしたくなった | 想像力を喚起する方を選べ。ジェーン・オースティンの小説には叙述がほとんどない。全部描いてある絵より、色々想像できる絵の方が飽きない | 第6章 |
| 誰も見ない箇所の作り込みを迷う | 妥協するな。ダ・ヴィンチは『ジネヴラ・ベンチ』の背景の杜松を一枚一枚描いた。見えない細部の集積が「圧倒される何か」になる | 第2章 |
| 簡単に見えるものを作りたい | 練習量を覚悟せよ。読みやすい会話調の良文は8回目の書き直しでようやく得られる | 第6章 |
## 判断の物差し（良いデザインの見分け方）
| 場面 | 主張・示唆 | 根拠(章) |
| --- | --- | --- |
| 「センスは主観的だ」と言われた | それは論争を避けるには良い方法だが、ものを作る人には有害な嘘。上達が自覚できる以上、古いセンスは違うのではなく悪かったのだ | 第6章 |
| 二案で迷う | まず単純さを疑え。「良いデザインは単純である」。装飾を見せられないなら実体を見せるしかなくなる | 第6章 |
| 流行に乗るか迷う | 色褪せない解を目標にせよ。それが最良の解を見つける方法でもあり、流行を避ける方法でもある | 第6章 |
| 対称性・規則性で揃えたくなった | 対称性は「深く考える代わりに」使われる危険がある。繰り返しと再帰のうち、数学と工学では再帰が有用 | 第6章 |
| 変わった案・奇妙な案が出てきた | 潰さないよう気を付けよ。「良いデザインはしばしば奇妙だ」。奇妙さは意識して作り出せない、せいぜい潰さないでいられるだけ | 第6章 |
| 何を改善すべきか分からない | 美を想像するより醜さに目をやれ。「俺ならもっとうまくできる」が偉大な仕事の発端になる。ただし直す場所を嗅ぎ分けるには、その分野を十分理解している必要がある | 第6章 |
| 苦労が続いていて判断がつかない | 良い苦しみ（走っている時の苦しみ）と悪い苦しみ（釘を踏み抜いた時の苦しみ）を区別せよ。気まぐれな顧客や信頼できない素材は後者 | 第6章 |
## 言語・道具の選択
| 場面 | 主張・示唆 | 根拠(章) |
| --- | --- | --- |
| 技術選定で「他社が何を使っているか」を調べた | ベンチャーが他のベンチャーと同じことをすれば、平均的な結果＝倒産になる。大企業は他の大企業に倣ってよいが、あなたは違う | 第8章 |
| 「全ての言語は等価だ」という前提に出会った | 等価なら、なぜ Java の開発者はわざわざ新しい言語を作ったのか。安心できるから広まっている信念であって事実ではない | 第9章 |
| 上位の言語の価値が分からない | ほげ言語のパラドックス。人は自分の使う言語で思考するので、下の言語は正しく見下せるが、上の言語は「おまけ付きの同等品」にしか見えない | 第8章 |
| 「業界の最良慣行」という言葉が出た | 技術的最適解ではなく、意思決定者を責任から護るための選択だと見抜け。それはあなたをトップにはせず、単に平均にする | 第9章 |
| 難しい問題を弱い言語で解こうとしている | 選択肢は3つ——(a) パワフルな言語を使う (b) 同等のインタプリタを弱い言語で書く (c) 自ら人間コンパイラになる。無自覚に(c)をやっていることが多い | 第9章 |
| コードに同じパターンの繰り返しを見つけた | 抽象化が足りていないサイン。マクロを書くべきコードを手で展開している可能性が高い | 第9章 |
| 言語選択がそもそも問題になるか見極めたい | 要求の高さで判断せよ。既存部品をつなぐ糊付けプログラムなら手に馴染んだ言語でよい。競争が激しく難しい問題なら言語の力が効く | 第9章 |
| 長期に賭ける基盤を選ぶ | 現在の人気ではなく「進化の系統樹の主要な枝にあるか」で判断せよ。行き止まりの枝に乗ると、後から動かせない | 第7章 |
| 自分の技術的アドバンテージを語りたくなった | 公言するな。ライバルが理解できない技術を持っていることには、ビジネス上の大きな価値がある | 第8章 |
| 競合の実力を測りたい | 宣伝ではなく人材募集内容を読め。募集要項は企業が本当に欲しているものを正確に表現している | 第8章 |
| 速いハードウェアが手に入った | そのサイクルを「より単純な設計を得るための良い無駄」に使え。悪い無駄と良い無駄を区別する | 第7章 |
| 並列化を早めに入れたい | 開発の最終盤・最適化の段階まで待て。バージョン1で並列性を前提に書くのは不適切な最適化 | 第7章 |
## 小さなチームと事業
| 場面 | 主張・示唆 | 根拠(章) |
| --- | --- | --- |
| リリース頻度を決める | 「バージョン」という考え方を捨てよ。動く前に出す必要はなく、動いたらすぐ出せる。年1回のリリースは数え切れないバグを溜め込んだ塊を作る行為 | 第4章 |
| バグを減らしたい | 変更を小さく段階的に出せ。新鮮なバグは古いバグより直しやすく、複合バグが生まれにくい | 第4章 |
| サポート体制を設計する | 開発者から離すな。サポートは実質的に品質管理部門であり、営業部門であり、フォーカスグループの代理でもある | 第4章 |
| 人を増やしたくなった | Brooks の逆転——グループが小さくなるほど開発効率は指数的に増大する。Viaweb はプログラマ3人でミーティングをした記憶がない | 第4章 |
| 「計画」を求められた | それが「棚に積まれたアイディア」の言い替えでないか疑え。寝かせることは実装が遅れるだけでなく、実装から得られたはずのアイディアを全て失うこと | 第4章 |
| 最適化する対象を決める | ベンチマークではなく実際のユーザを見よ。サーバにログインして CPU を食いつぶしているものを見ればいい | 第4章 |
| UI をどこから直すか決める | ユーザがどこで困っているかを見よ。Viaweb は Back ボタンを押される箇所に一言入れただけで、完走率が60%→90%、利益が50%増えた | 第4章 |
| 顧客セグメントを決める | まず小さな顧客を相手にせよ。大会社は遅れて気づく。残りは後からついてくる | 第4章 |
| 大企業とデザインで勝負する | 誰も防衛を確立していない新しいマーケットを選べ。城の中にいる相手に一対一の勝負を承知させるのは不可能に近い | 第2章 |
| ベンチャーを始めるのが怖い | ビジネスについて知るべきことは二つだけ——「ユーザが気に入るものを作ること」と「使った金より多くの収入を得ること」 | 第4章 |
| 投資家や買収候補を意識した製品設計をしている | やめよ。ユーザーを喜ばせるように設計せよ。ユーザーを獲得すれば残りは後からついてくる | 第9章 |
| 肩書きのある人の意見をどう扱うか | ソフトウェアはデザインを知っているハッカーによってデザインされるべきで、ソフトウェアをほとんど知らないデザイナーによってではない | 第4章 |
## 人・組織・自分の守り方
| 場面 | 主張・示唆 | 根拠(章) |
| --- | --- | --- |
| 優秀な人を集めたい | 給与ではなく道具と問題を用意せよ。良いハッカーは悪い道具に耐えられず、間違ったインフラのプロジェクトを単に拒絶する | 第12章 |
| 退屈なプロジェクトに人がつかない | 問題そのものを再定義せよ。ITA は航空料金検索を、Google は検索を、ジョブズは安いコンピュータを「美しいコンピュータを作る」問題に作り替えた | 第12章 |
| 仕事場を設計する | ハッカーが家でどう働いているかを見て真似よ。ドア付きの部屋、こじんまりして人が近くにいる場所。オフィス空間を階級バッジにする会社は社内で開発ができなくなる | 第12章 |
| 良いハッカーを見分けたい | 履歴書や面接に頼るな。唯一の方法は何かのプロジェクトで一緒に働くこと。だからハイテク企業の集積は大学の周辺にできる | 第12章 |
| 採用面接で何を聞くか | 応募者が余暇にどんなプログラムを書いているかを聞け（Viaweb の面接方針）。愛がなければ本当にうまくはできない | 第2章 |
| 大企業の中で優秀な人を守りたい | 研究部門を切り離すのではなく、ボトムアッププログラミングを使え。優秀な人に道具を作らせ、別グループにそれでアプリを作らせる | 第12章 |
| 共同開発の分担を決める | 明快に定義されたモジュールに分割し、各モジュールに所有者を決めよ。複数人が所有者不明のままハックしたコードは共有部屋のように埃が積もる | 第2章 |
| 最終決定をどう下すか | 批判は信頼できる人から受けよ。ただし会話が終わったら決断は一人に任される必要がある。委員会によるデザインは悪いデザインと同義 | 第11章 |
| 嫌な細かい問題（schlep）を振られた | 避けよ。バグだらけのインタフェースや顧客ごとの曖昧なカスタマイズから学べることは何もなく、関わっているとバカになる。これは気短さではなく自己防衛 | 第12章 |
| 自分の働き方を律したい | 「退屈なプロジェクトの仕事は一切しない。そのかわり絶対に中途半端な仕事は受けない」という契約を自分と結べ | 第12章 |
| 気が乗らない時期が来た | 周期があることを前提に予定を組め。1日16時間やり続ける時期と何も面白く感じない時期がある。乗らない時のためにデバッグなど楽な作業を取っておけ | 第2章 |
| 金にならないが面白いものを作りたい | 「昼間の仕事」を持て。ミュージシャンがレコード店で働くように、金のための仕事と愛のための仕事を分けろ。オープンソースのハッキングはまさにこれ | 第2章 |
| 良い仕事をする場所を選ぶ | ホットスポットに行け。「良いデザインは集団で生まれる」。中心から遠く離れていては良い仕事はほとんど不可能 | 第6章 |
## 常識を疑う・言論の扱い
| 場面 | 主張・示唆 | 根拠(章) |
| --- | --- | --- |
| 自分の思考が本当に自分のものか確かめたい | 順応性検査——同格の集団内で、表明するのを憚る意見を持っているか。No なら、言われたことをそのまま信じている可能性が高い | 第3章 |
| 現代のタブーを探したい | ①災難に巻き込まれた人の主張を「それは真実であり得るか」と問う ②レッテルを選び、そう呼ばれる考えの真偽を問う ③過去や他文化の常識との diff を取る ④上品ぶった人と世界を見てきた人の頭の中を引き算する | 第3章 |
| 相手が真偽ではなくレッテルで攻撃してきた | 注意を払え。レッテル貼りは、主張が虚偽ならそもそも不要なもので、虚偽でないことの兆候である | 第3章 |
| 口にできないことを発見した | 口にするな。少なくとも戦いを選べ。最重要なのは「考えたいことを考えられる」ことで、「言いたいことを言える」ことではない | 第3章 |
| 熱狂している集団に「賛成か反対か」と迫られた | 与するな。「どちらでもない」「まだ決めていない」と答えよ（ラリー・サマーズ「私はリトマス試験は受けない」） | 第3章 |
| どうしても反撃せざるを得ない | 議論の抽象度を一段上げよ。特定の異端に触れず、レッテル貼りという風潮そのものにメタレッテルを貼れ。あるいはユーモアを使え | 第3章 |
| 自分が怒っている・レッテルを使った | 群集だけでなく自分自身の考えも距離を置いて見よ。「子供が疲れているから怒っている」のを大人が一歩下がって見るのと同じことを、道徳の流行についてやれ | 第3章 |
| 突飛な考えを話す相手がいない | 信頼できる少数の友人を持て。とんでもないアイディアを聞いても飛び上がらない人こそ、知り合って面白い人だ | 第3章 |
| 集団の中で自分の評価が不当に低い | まずその集団に外部の実力の尺度があるかを見よ。尺度のない集団では、順位は「自分の順位を引き上げる能力」だけで決まり、ゼロサムの潰し合いになる | 第1章 |
| チームを結束させたい | 外部の敵・外部の目的を先に定義せよ。共通の目的がない集団は、必ず内部に敵を作り出して結束する | 第1章 |
## 分類問題・フィルタ設計（第5章の技法）
| 場面 | 主張・示唆 | 根拠(章) |
| --- | --- | --- |
| 判別ルールを人手で書き続けている | やめて統計的手法を先に試せ。著者は6ヶ月を特徴抽出に費やしたが、統計的フィルタは自分より賢く、思いもよらない指標（"ff0000" など）を見つけた | 第5章 |
| 誤判定のコストが非対称 | 意図的にバイアスをかけよ。正当なメールを失うことは spam を受け取るより何倍もダメージが大きいので、good 側の生起回数を2倍にカウントした | 第5章 |
| フィルタを多数のユーザに配る | 単一の初期モデルで済ませるな。ユーザごとにテーブルを持たせると精度が上がり、判断基準を正確に反映でき、攻撃者が回避を作ることが極めて困難になる | 第5章 |
| 学習データをどう集めるか | 日常操作に埋め込め。削除ボタンを「通常の削除」と「spam として削除」の2種類にするだけでコーパスが自動的に育つ | 第5章 |
| スコアの意味が説明できない | ベイズの利点は「自分が何を計測しているかがはっきりしていること」。特徴認識型フィルタのスコアは、開発者にすら何を意味するのか分からない | 第5章 |
| 攻撃者が回避してくる | 防御の種類を増やせ。フィルタの種類が多いほど、そのどれをも通過するものを作り出すのが困難になる | 第5章 |