はじめに: 名言はなぜ残るのか

“Talk is cheap. Show me the code.”

Linus Torvaldsがこの一文をLinuxカーネルのメーリングリストに投稿したのは2000年8月25日のことです。それから四半世紀が経った今も、世界中のエンジニアがこの言葉を引用し続けています。

一方で、同じメーリングリストには何万通ものメッセージが流れました。その大半は忘れ去られています。なぜTorvaldsのこの一文だけが生き残ったのか。私がこの本を書こうと思ったのは、その問いがきっかけでした。

「刺さる言葉」の構造

Chip HeathとDan Heathの著書『アイデアのちから(Made to Stick)』(2007)は、記憶に残るアイデアの条件をSUCCESsという6文字にまとめました。

• S imple: 核を一文に絞る
• U nexpected: 予測を破る
• C oncrete: 抽象ではなく具体物を見せる
• C redible: 権威や実績で裏打ちする
• E motional: 感情を動かす
• S tories: 物語で包む

Torvaldsの言葉をこのレンズで見てみましょう。

Simple: 「口で言うな、コードを見せろ」。これ以上削れない一文です。Unexpected: 世界最大のOSSプロジェクトのリーダーが「議論するな」と言い切る。普通は対話を重視するはずのリーダーが、真逆のことを言う意外性があります。Concrete: “code”という、エンジニアなら全員がイメージできる具体物を指している。Credible: Linuxを一人で作り始めた人物が言うから重みがある。口先だけの人が同じことを言っても響きません。

6条件のうち4つを同時に満たしている。だからこの言葉は四半世紀経っても消えないのです。

なぜ今この本を出すのか

2025年、Andrej Karpathyが「vibe coding」という言葉を生み出しました。AIが書いたコードのdiffを見ずにAcceptする開発スタイル。一方で、Dijkstraは50年前に「シンプルさは信頼性の前提条件である」と書いています。AIがコードを書く時代に、先人たちの言葉はまだ有効なのか、それとも過去の遺物なのか。その問いに答えるために、100個の名言をSUCCESsフレームワークで解剖してみることにしました。結論を先に言えば、驚くほど多くの言葉が、今のほうがよく刺さります。

この本の読み方

本書では、エンジニアリングの歴史から100個の名言を選び、テーマ別に10章に分類しました。

各名言には3つの解説がつきます。

1. 背景: 誰が、いつ、どんな状況でその言葉を発したのか
2. SUCCESs分析: 6条件のうちどれを満たしているか
3. 実務への教訓: 明日の仕事にどう活かせるか

第1章「コードの美学」から第10章「エンジニアの生き方」まで、好きな章から読んでください。名言集なので順番に読む必要はありません。

そして終章「あなたの一文をつくる」では、SUCCESsフレームワークを使って、コードレビューやドキュメント、プレゼンで「刺さる一文」を書く方法を紹介します。名言を鑑賞するだけでなく、自分の武器にする。それがこの本のゴールです。

対象読者

• プログラミング経験が1年以上あるエンジニア
• モチベーションや技術判断の拠り所を探している方
• 先人の知恵を体系的に知りたい方
• 自分の言葉で人を動かしたいテックリード・マネージャー

名言の原文は英語のものが多いですが、すべて日本語の解説をつけています。英語が苦手でも問題ありません。

この続きはKindleで →

第1章: コードの美学

美しいコードとは何か。この問いに対する答えは、半世紀にわたって驚くほど一貫しています。シンプルであること。読む人間のことを考えていること。そして、書いた本人がいなくなっても意図が伝わること。この章では、コードの美しさについて語られた10の言葉を紹介します。

---

01. “Simplicity is prerequisite for reliability.”

シンプルさは信頼性の前提条件である。

— Edsger W. Dijkstra, EWD498 “How do we tell truths that might hurt?” (1975)

背景

Dijkstraは1975年のメモで、プログラミング教育と業界の問題点を率直に指摘しました。そのなかで、信頼性の高いソフトウェアを作るために何が必要かを一言にまとめたのがこの言葉です。彼はチューリング賞の受賞講演(1972)で「謙虚なプログラマー」という概念を提唱した人物でもあります。

SUCCESs分析

• S(Simple): 「シンプルさ→信頼性」という因果を一文に凝縮
• Cr(Credible): 構造化プログラミングを確立したDijkstraの実績が裏打ち
• C(Concrete): 「前提条件」という言葉で、シンプルさが信頼性の必要条件だと明示。オプションではない

教訓

機能を追加するとき「これは本当に必要か」と問い直す習慣は、この一文に集約されます。複雑さは機能ではなく負債です。コードレビューで「これ、もっとシンプルにできない？」と言えるようになることが、信頼性への第一歩です。(→ 第3章 #23「Keep it simple, stupid.」、#24「You aren’t gonna need it.」)

---

02. “Programs are meant to be read by humans and only incidentally for computers to execute.”

プログラムは人間が読むために書かれるべきで、たまたまコンピュータが実行できるにすぎない。

— Harold Abelson & Gerald Jay Sussman, Structure and Interpretation of Computer Programs (1985)

背景

MITの計算機科学の教科書として伝説的な存在であるSICP(通称「魔法使い本」)の冒頭近くに書かれた言葉です。この本はLISPを使ってプログラミングの本質を教えるもので、コードは機械への命令ではなく、人間同士のコミュニケーション手段だという思想を打ち出しました。

SUCCESs分析

• U(Unexpected): プログラムの主な読者は「コンピュータ」だと思い込んでいる人の常識を覆す
• C(Concrete): 「読む」「実行する」という具体的な動詞で対比
• Cr(Credible): MITで数十年にわたり計算機科学の入門書として使われ続けた教科書からの引用
• E(Emotional): 「たまたま」という一語が、プログラマーの日常的な優先順位への静かな挑発として機能する

教訓

変数名を d ではなく elapsedDays にする。コメントを「何をしているか」ではなく「なぜそうしているか」で書く。すべてはこの原則から始まります。コードを書くときの問いは「コンピュータは理解できるか」ではなく「半年後の自分は理解できるか」です。(→ 第9章 #81「The hottest new programming language is English.」)

---

03. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

コンピュータが理解できるコードは誰でも書ける。優れたプログラマーは人間が理解できるコードを書く。

— Martin Fowler (Kent Beck), Refactoring: Improving the Design of Existing Code (1999)

背景

Martin Fowlerの名著『リファクタリング』に登場するこの言葉は、Kent Beckとの共同作業から生まれました。リファクタリングとは外部から見た振る舞いを変えずに内部構造を改善すること。その目的は「人間にとっての読みやすさ」を高めることだと、この一文は宣言しています。

SUCCESs分析

• S(Simple): “fool” と “good programmer” の対比で構造が明快
• U(Unexpected): 「コンピュータが理解できる」を「誰でもできること」と切り捨てる挑発

教訓

動くコードを書いた瞬間は「完成」ではなくスタートラインです。プルリクエストを出す前に「このコードを初めて見る人が理解できるか」と自問する。その一手間がチーム全体の生産性を変えます。

私がこの言葉を痛感したのは、あるコードレビューでのことです。自分では「きれいに書けた」と思っていたデータ変換処理に、レビュアーから「これ、何やってるかわかるまで15分かかった」とコメントがつきました。ロジックは正しい。テストも通っている。でも「理解するのに15分かかる」時点で、チームにとっては負債です。その日から、プルリクエストを出す前に一度画面を閉じて、5分後にもう一度自分のコードを「初見の目」で読む習慣をつけました。(→ 第7章 #66「Code is like humor.」)

---

04. “UNIX is simple. It just takes a genius to understand its simplicity.”

UNIXはシンプルだ。そのシンプルさを理解するのに天才が必要なだけだ。

— Dennis Ritchie

背景

C言語とUNIXの共同開発者であるRitchieの言葉です。UNIXの設計哲学は「一つのことをうまくやる小さなプログラムを組み合わせる」というもの。一見単純に見えるこのアプローチの背後には、深い設計判断の積み重ねがあります。Ritchieはその設計判断を「シンプル」と呼びつつ、真に理解するのは容易ではないと認めています。

SUCCESs分析

• U(Unexpected): 「シンプル」と「天才が必要」の矛盾した組み合わせが記憶に残る
• Cr(Credible): UNIXを実際に作った本人の言葉

教訓

シンプルな設計は「手抜き」ではなく、最も高度な設計判断の結果です。複雑な問題をそのまま複雑に実装するのは簡単で、本当に難しいのは複雑さを削ぎ落とすことです。

---

05. “One of my most productive days was throwing away 1000 lines of code.”

最も生産的だった日の一つは、1000行のコードを捨てた日だった。

— Ken Thompson

背景

UNIXの共同開発者であるThompsonの言葉です。プログラマーの生産性を「書いた行数」で測る文化への静かな反論です。Thompsonはチューリング賞受賞者であり、後にGo言語の設計にも携わりました。彼のキャリア全体を通じて「不要なものを削る」という姿勢が一貫しています。

SUCCESs分析

• U(Unexpected): 「生産的」と「捨てた」の逆説。普通、生産的な日は「たくさん書いた日」だと思われている
• C(Concrete): “1000 lines”という具体的な数字

教訓

コードの量は価値ではありません。むしろ少ないコードで同じ機能を実現できるなら、それはより優れた解決策です。リファクタリングで行数が減ったなら、それは前進です。

以前、私はあるプロジェクトで認証周りのユーティリティモジュールを担当していました。3週間かけて実装した約800行のコードが、既存のライブラリの設定変更だけで完全に置き換えられることにチームメイトが気づいたのです。正直、最初は抵抗がありました。3週間の努力を「なかったこと」にするのは辛い。でも消した瞬間、テストの複雑さが半分になり、CIのビルド時間も短くなった。Thompsonの言う「生産的な日」とは、こういう日のことだと身をもって理解しました。

---

06. “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it.”

シンプルさは偉大な美徳だが、それを達成するには努力が必要で、それを評価するには教育が必要だ。

— Edsger W. Dijkstra, EWD896 “On the nature of Computing Science” (1984)

背景

Dijkstraは繰り返しシンプルさの価値を説きましたが、この1984年のメモでは「シンプルさの難しさ」そのものに踏み込んでいます。シンプルなコードを書くのが難しいだけでなく、シンプルなコードの価値を認識すること自体が教育を必要とする、という二重の指摘です。

SUCCESs分析

• U(Unexpected): 「シンプルさ」が「easy(簡単)」の同義語ではないと突きつける意外性
• E(Emotional): シンプルなコードを書く努力が報われないと感じた経験を持つ人の感情に響く

教訓

シンプルなコードを提出したら「もっと頑張れ」と言われた。複雑な設計を説明したら称賛された。こういう経験があるなら、Dijkstraの言葉を思い出してください。複雑さを評価する文化があるなら、それはチームの教育の問題です。

---

07. “I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy.”

Rubyが世界中のプログラマーの生産性を高め、プログラミングを楽しみ、幸せになる手助けをすることを願っています。

— まつもとゆきひろ(Matz)

背景

Ruby言語の作者であるMatzは、一貫して「プログラマーの幸福」を設計原則の中心に据えてきました。Ruby以前のプログラミング言語は、実行速度や安全性を最優先にするものが主流でした。「プログラマーが幸せかどうか」を設計基準にした言語は、当時としては異端です。

SUCCESs分析

• E(Emotional): 技術的な効率ではなく「happy(幸せ)」を目標に掲げる。エンジニアの心に直接訴える

教訓

ツールを選ぶとき、ベンチマークのスコアだけでなく「このツールを使って楽しいか」も判断基準にしてよいのです。開発者体験(DX)は贅沢品ではなく、長期的な生産性に直結します。

---

08. “The principle of least surprise means principle of least MY surprise.”

最小驚き原則とは、私にとっての最小驚き原則のことだ。

— まつもとゆきひろ(Matz), Artima Developer (2003)

背景

Rubyの設計原則としてよく引用される「最小驚き原則(POLS: Principle of Least Surprise)」。Matzはインタビューで、この原則が「万人にとっての最小驚き」ではなく、「言語設計者である自分にとっての最小驚き」だと明確にしました。つまりRubyをよく学んだ人にとって直感的であることを目指しており、初見の全員にとって直感的である必要はない、という立場です。

SUCCESs分析

• Cr(Credible): 実際にRubyを設計した本人の設計判断

教訓

API設計やライブラリ設計で「誰にとっての直感か」を明確にすることは重要です。すべての人にとって直感的なインターフェースは存在しません。ターゲットユーザーを決め、その人たちにとっての一貫性を追求する方が、結果的に良い設計になります。

---

09. “Elegance is not a dispensable luxury but a quality that decides between success and failure.”

エレガンスは省略可能な贅沢品ではなく、成功と失敗を分ける品質だ。

— Edsger W. Dijkstra

背景

Dijkstraにとってエレガンスとは見た目の美しさではなく、構造的な明快さでした。エレガントなコードは理解しやすく、バグが見つけやすく、拡張しやすい。それは開発速度にも保守コストにも直接影響する、実用的な品質です。

SUCCESs分析

• U(Unexpected): 「エレガンス」を「贅沢品」ではなく「成否を決める要因」と再定義する
• S(Simple): 二項対立(贅沢 vs 必須、成功 vs 失敗)で構造が明快

教訓

「動けばいい」というコードは、短期的には早いように見えます。しかし変更が入るたびに苦しむのは、エレガンスを軽視したツケです。コードレビューで「もっときれいに」と言うのは、美意識の押しつけではなく、プロジェクトの成功確率を上げる行為です。

---

10. “Science is what we understand well enough to explain to a computer. Art is everything else we do.”

科学とは、コンピュータに説明できるほどよく理解していること。芸術とは、それ以外のすべてだ。

— Donald Knuth, Foreword to A=B (1996)

背景

Knuthは『The Art of Computer Programming(TAOCP)』という書名にあるように、プログラミングを「アート(技芸)」と位置づけてきました。この言葉は、科学と芸術の境界を「コンピュータに説明できるかどうか」で線引きしたものです。つまりプログラミングには、形式化できない領域がつねに残る。その部分こそが「アート」だと。

SUCCESs分析

• S(Simple): 「科学/芸術」の二分法で複雑な議論を圧縮
• C(Concrete): 「コンピュータに説明できる」という明確な判定基準

教訓

設計判断の多くは「科学」ではなく「芸術」の領域にあります。ベンチマークでは測れない良し悪しがある。経験を積むということは、この「芸術」の部分で精度を上げていくことに他なりません。(→ 第9章 #82「I’m mostly programming in English now」)

この続きはKindleで →

第2章: バグと失敗の哲学

ソフトウェアにバグがないと思っている人は、ソフトウェアを書いたことがない人です。この章に登場する言葉は、失敗を恐れるのではなく、失敗との付き合い方を教えてくれます。

---

11. “Testing shows the presence, not the absence of bugs.”

テストはバグの存在を示すが、バグの不在は示さない。

— Edsger W. Dijkstra, NATO Software Engineering Conference (1969)

背景

1968-69年のNATOソフトウェアエンジニアリング会議は、「ソフトウェア危機」が議論された歴史的な場です。Dijkstraはこの会議で、テストの本質的な限界を一文で示しました。テストを100回通してもバグがゼロとは言えない。この認識は、テスト駆動開発やフォーマル検証が重要になる理論的基盤を作りました。

SUCCESs分析

• U(Unexpected): テストが「安全を保証する」と思い込んでいる人への意外な真実
• S(Simple): presence/absenceの対比で一瞬で理解できる
• Cr(Credible): フォーマル検証の先駆者であるDijkstraが、テストの限界を1969年に指摘した歴史的重み
• C(Concrete): 「存在」と「不在」という論理的に厳密な対比で、抽象的になりがちなテスト論を地に足のついた議論にしている

教訓

テストカバレッジ100%であっても安心してはいけません。テストはリスクを下げるツールであって、品質を保証する証明書ではないのです。「テストが通ったから大丈夫」ではなく「テストで見つけられない問題は何か」と考える。この思考の転換が、堅牢なシステムを作る第一歩です。(→ 第7章 #61「The only way to go fast is to go well.」)

---

12. “Beware of bugs in the above code; I have only proved it correct, not tried it.”

上のコードのバグに注意してください。正しいことは証明しましたが、試してはいません。

— Donald Knuth, Notes on the van Emde Boas construction of priority deques (1977)

背景

Knuthがメモの末尾に添えたこの一文は、形式的証明の限界を自覚した上でのユーモアです。数学的に正しいことを証明できても、実際に動かしてみなければ実装のバグは見つからない。理論と実践の間に横たわるギャップを、世界最高の計算機科学者が認めているのです。

SUCCESs分析

• U(Unexpected): 「証明した」のに「試してない」という矛盾が可笑しい
• Cr(Credible): Knuth本人が自分のコードに対して言っているからこそ重みがある

教訓

コードレビューで理論的に正しいことを確認するのは大切です。しかし実際に動かすことの代わりにはなりません。「ロジックは合ってるはずなんだけど」と言ったことがある人は、Knuthでさえ同じ落とし穴を認めていることを思い出してください。

---

13. “It’s easier to ask forgiveness than it is to get permission.”

許可を得るより許しを乞う方が簡単だ。

— Grace Hopper

背景

アメリカ海軍の准将でありCOBOL言語の開発に貢献したGrace Hopperの言葉です。彼女は「最初のバグ」を発見した逸話(蛾がリレーに挟まった記録)でも知られています。この言葉は本来、官僚組織の中でイノベーションを起こすための処世術でした。技術的な文脈では「まず試して、問題が起きたら対処する」というアプローチを正当化する言葉として広く引用されています。

SUCCESs分析

• U(Unexpected): 軍の准将が「規則を破ってもいい」と言っている意外性
• E(Emotional): 「やりたいことがあるのに許可が下りない」という誰もが経験するフラストレーションに響く

教訓

新しいツールの導入、テスト自動化の提案、アーキテクチャの改善。承認プロセスを待っていたら何も始まりません。小さなプロトタイプを作って結果を見せる方が、提案書を100枚書くより説得力があります。ただし、本番環境でこれをやるのは別の話です。

---

14. “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

デバッグはコードを書くことの2倍難しい。だから、自分の限界まで賢くコードを書いたら、定義上、それをデバッグするだけの知力が残っていない。

— Brian Kernighan, The Elements of Programming Style (1978)

背景

KernighanはC言語の教科書『プログラミング言語C(K&R)』の共著者として知られています。この言葉は、彼とPlaugerの共著『プログラミング作法(The Elements of Programming Style)』から。賢いコードを書くことを戒め、シンプルなコードの方が保守しやすいという主張を、論理的に導いています。

SUCCESs分析

• S(Simple): 「書く=難易度X、デバッグ=2X、だから…」という算数の構造
• U(Unexpected): 「賢いコードを書ける能力」が不利に働くという逆説
• C(Concrete): 「2倍」という具体的な倍率が、直感的な理解を助ける
• Cr(Credible): K&Rとして知られるC言語バイブルの共著者による、実践に裏打ちされた主張

教訓

コードレビューで「これ、何やってるかわからない」と言われたら、それはレビュアーの能力不足ではありません。書いた本人がデバッグできないコードは、チームにとって時限爆弾です。

私が新人の頃、先輩のコードに三項演算子のネストとビット演算を組み合わせた1行がありました。パフォーマンス上の理由があるのだろうと思い、本番でその行が関わるバグが出たときに調べたところ、単に「短く書きたかった」だけでした。デバッグに丸1日かかり、修正後のコードは5行の素直なif文になりました。読みやすさと正しさの両方が改善された瞬間、Kernighanの「2倍」の意味を実感しました。(→ 第1章 #03「Good programmers write code that humans can understand.」)

---

15. “The most dangerous phrase in the language is, ‘We’ve always done it this way.’”

最も危険な言葉は「ずっとこうやってきた」だ。

— Grace Hopper (帰属。類似の発言は確認されているが、この正確な表現の一次ソースは未確認)

背景

Hopperの発言として広く引用されますが、Wikiquoteでは”unsourced variant”と注記されています。彼女が類似の趣旨を述べたことは確認されており、インタビューで「Go ahead and do it. You can always apologize later.(やってしまえ。謝るのは後でいい)」と語った記録があります。名言の帰属問題の典型例でもあります。

SUCCESs分析

• E(Emotional): 「古いやり方に縛られている」と感じたことがある人の感情を直撃
• S(Simple): 「最も危険な言葉」というインパクトのある断言

教訓

レガシーコードの保守で「なぜこうなっているのか」を聞いたとき、「昔からこうだった」は答えになっていません。理由なく残っている設計は、技術的負債の発生源です。同時に、この名言自体が帰属不明であるという事実は、名言を引用する際の検証の重要性も教えてくれます。

---

16. “Shipping first time code is like going into debt.”

初回のコードを出荷するのは、借金をするようなものだ。

— Ward Cunningham

背景

「技術的負債(Technical Debt)」というメタファーの生みの親、Ward Cunningham。Wiki(WikiWikiWeb)の発明者でもあります。金融の「借金」にたとえることで、非エンジニアの経営者にも技術的な問題を説明できるようにしました。借金自体は悪ではない。問題は返済せずに利子だけが膨らむことです。

SUCCESs分析

• C(Concrete): 「コードの品質」という抽象概念を「借金」という身近な概念にマッピング
• Cr(Credible): WikiとXPの先駆者としてのCunninghamの実績

教訓

技術的負債をゼロにすることは現実的ではありません。重要なのは「意図的に負債を負っている」と自覚すること、そして返済計画を持つことです。スプリントの振り返りで「今期、どの借金を返すか」を議題にするチームは強いです。

以前、あるプロジェクトのスプリント計画で「技術的負債の返済」を提案したとき、プロダクトオーナーに「それはユーザーに見える改善なのか」と聞かれました。そこでCunninghamの借金メタファーをそのまま使い、「今のコードベースは年利20%の借金を抱えている状態です。新機能を追加するたびに利子が増えて、3ヶ月後には新機能の開発速度が半分になります」と説明しました。数字は概算でしたが、「借金」と「利子」という言葉で、技術的な問題がビジネスの言語に翻訳された瞬間でした。その週、リファクタリングに2日分の工数が割り当てられました。(→ 第7章 #68「We will meet our schedules by knowing that the only way to go fast is to go well.」)

---

17. “Move fast and break things.”

速く動いて、壊せ。

— Mark Zuckerberg, Facebook社内モットー (2009頃-2014)

背景

Facebookの初期の社内モットーとして有名です。スタートアップのスピード感を象徴する言葉として広まりましたが、Facebook自身が2014年に”Move fast with stable infrastructure(安定したインフラで速く動け)“に変更しました。つまり、この名言はその限界まで含めて教訓になっています。

SUCCESs分析

• S(Simple): 4語。これ以上短くできない
• U(Unexpected): 「壊すこと」を肯定する大胆さ

教訓

この言葉がフェーズによって有効か有害かが変わるところが面白いのです。プロトタイプ段階では正しい。しかしユーザーが何億人もいるプロダクトでは、壊すことのコストが破壊的です。Facebook自身がモットーを修正したことが、最大の教訓と言えます。

---

18. “Fail fast, fail often, fail forward.”

早く失敗し、何度も失敗し、前に向かって失敗せよ。

— シリコンバレーの格言(特定の個人への帰属は困難)

背景

シリコンバレーの文化を象徴するフレーズで、特定の人物に帰属させることは困難です。John C. Maxwellの著書タイトル(2007)としても知られています。「失敗は学びの機会」というスタートアップ文化の核心を表現した言葉ですが、無責任な失敗を正当化する文脈で乱用されることもあります。

SUCCESs分析

• S(Simple): 3つのfailのリフレイン(韻)が記憶に残る

教訓

失敗そのものに価値があるのではなく、失敗から学んだことに価値があります。“fail forward”(前に向かって失敗する)という部分が最も重要で、同じ失敗を繰り返すのは「fail backward」です。ポストモーテムの文化がないチームでは、この言葉は空虚なスローガンに終わります。

---

19. “First, solve the problem. Then, write the code.”

まず問題を解け。コードを書くのはその後だ。

— John Johnson

背景

プログラマーの間で広く引用される言葉ですが、John Johnsonという人物の詳細な経歴は明確ではありません。しかしこの言葉の価値は、帰属よりも内容にあります。キーボードに飛びつく前に、問題を理解する。解決策を頭の中で設計する。そしてようやくコードを書く。このプロセスを一文で伝えています。

SUCCESs分析

• C(Concrete): “solve”と”write”という具体的な動詞の対比

教訓

IDEを開く前にホワイトボードの前に立つ。テストを書く前に要件を確認する。何を作るかが曖昧なまま実装に入ると、やり直しのコストが指数関数的に膨らみます。

---

20. “The amateur software engineer is always in search of magic.”

アマチュアのソフトウェアエンジニアは、つねに魔法を探し求めている。

— Grady Booch

背景

UML(統一モデリング言語)の開発者の一人であるGrady Boochの言葉です。新しいフレームワーク、新しい言語、新しい手法。何か一つの「銀の弾丸」で全てが解決するという幻想を、Boochは「magic(魔法)」と呼びました。Fred Brooksの「銀の弾丸はない」と同じ系譜にある言葉です。

SUCCESs分析

• C(Concrete): 「魔法」という具体的なイメージ
• Cr(Credible): UMLの設計者というソフトウェア工学の権威

教訓

新しい技術が出るたびに飛びつくのは楽しいですが、銀の弾丸は存在しません。問題を解くのは道具ではなく、道具を使う人間の判断力です。技術選定で大切なのは「何ができるか」ではなく「自分たちの問題に合うか」です。

この続きはKindleで →