はじめに ──「常識」は、最初から常識ではなかった
シンプルに書こう。テストを書こう。コメントより、まず名前を考えよう。コードは、人に見せよう。
プログラミングを学びはじめると、こうした言葉に、次々と出会う。先輩が言う。本に書いてある。研修で教わる。どれも、もっともらしい。そういうものか、と受け入れて、あなたは従う。
だが、ふと思う。これは、誰が決めたのだろう。
どこかの偉い人が、ある日「こう書きなさい」と定めたわけではない。これらの「当たり前」は、最初から当たり前だったわけではないのだ。誰かが困り、答えを出し、その答えで盛大に失敗し、言い争い、少しずつ直してきた。その長い積み重ねの果てに、いつのまにか「当たり前」になった。常識は、生まれたときから常識だったのではなく、常識になったのだ。
この本は、その「当たり前」が、どうやって当たり前になったのかを語る。
ただし、「正しい開発手法のカタログ」としては書かない。「こう書くのが正解です」と並べる本は、すでにたくさんある。この本が描くのは、もっと手前の話だ。プログラマーたちが、何に困り、何と戦い、何を手に入れてきたのか。その物語のほうだ。
そして、この物語には、一本の背骨がある。不自由と、自由だ。
プログラマーは、ずっと、いくつもの不自由に縛られてきた。たとえば――複雑さに飲み込まれる。半年後の自分にすら、コードが読めない。仕様が変われば、動けなくなる。一人が抜ければ、誰も触れない。道具の中身を、勝手に直せない。こうした不自由は、まだまだある。そして本書で語る「当たり前」は、どれも、その一つひとつに対して、プログラマーたちが勝ち取ってきた、別々の自由なのだ。
だから本書は、九つの不自由をめぐる、九つの物語でできている。それぞれの章で、一つの不自由が立ちはだかり、最初の答えが試され、手痛く失敗し、新しい考えが生まれ、やがて「当たり前」になる。そして、まだ終わっていない問いが、次の章へと続いていく。
読み終えたとき、あなたに残ってほしいのは、知識ではない。
「なるほど、そういう理由でそう考えるのか」と、外から納得して終わってほしくない。そうではなく、こう感じてほしい。自分もこれから、そう考える側になっていくのかもしれない、と。
なぜなら、この物語は、まだ続いているからだ。当たり前は、今も作られ続けている。そしてその作り手の列に、これからあなたも加わる。
これは、技術の解説書ではない。プログラマーという人たちが、何を大事にし、なぜそう考えるようになったのかを語る、ソフトウェア文化への入門書だ。
この本は、プログラミングスクール FjordBootCamp（フィヨルドブートキャンプ）の教材として作った。これからプログラマーになる人、なったばかりの人、そしてソフトウェア文化の来歴に興味のある人に向けて、最初から誰でも読めるように公開するつもりで書いている。覚えてほしいのは、個々のやり方ではない。「なぜ、そう考えるのか」をたどる、その考え方のほうだ。
では、最初の不自由から始めよう。それは、ある日あなたが「便利な機能を足しましょう」と言ったときに、先輩が見せた、あの渋い顔の話だ。
第1部 複雑さと読めなさに抗う
プログラマーが最初に向き合う不自由は、自分の作ったものに振り回されることだ。機能が絡み合って、誰も全体を見渡せなくなる。やっと分けたその部品も、半年後には自分ですら読めなくなる。
第1部では、この二つの不自由――複雑さと、読めなさ――を続けて扱う。第1章は、機能を足すたびに膨らむ複雑さと、それを「倒す」のではなく「小さく分けて手なずける」までの道のりを追う。第2章は、分けた一つひとつを「読める」ものにするための、名前という道具を扱う。
この二つは、地続きだ。複雑さを分けても、分けた先が読めなければ、結局また手が出せない。だから第1章の終わりは、そのまま第2章の入り口になる。
第1章 機能を増やそうと言ったら、止められた
「便利だから、この機能も入れましょう」
あなたは、よかれと思って言った。ユーザーが喜ぶ。手間も省ける。足して困ることなんて、あるだろうか。
なのに、先輩は浮かない顔をする。
「……うーん。それ、本当に要りますか」
要るに決まっている。便利なのだから。なぜ、足すことを、こんなに渋るのか。
この渋い顔の裏には、百年ぶんの経験が畳み込まれている。そして、その経験が教えるのは、たいてい同じことだ。
足すのは一瞬。抱えるのは、一生。
ソフトウェアには、不思議な性質がある。
機能を一つ足すたび、増えるのは「一つ」では済まない。新しい機能は、すでにある機能と手をつなぐ。組み合わせが、かけ算で膨れていく。十の機能が二十になると、気を配るべき関係は、その倍では済まない数になる。
やがて、誰も全体を見渡せなくなる。ここを直すと、あそこが壊れる。なぜ壊れたのか、誰にもわからない。作ったはずの自分たちが、自分たちの作ったものに振り回されはじめる。
これが、プログラマーをずっと苦しめてきた、最初の不自由だ。複雑さに、飲み込まれる。
最初に人類が選んだ答えは、勇ましかった。複雑さに、力で勝とうとしたのだ。
もっと賢い言語を。もっと万能な設計図を。複雑さを一撃で消し去る、特別な道具がきっとあるはずだ――その夢に、時代の最良の頭脳がつぎ込まれた。
1980 年代、日本も、国を挙げてその夢を見た。第五世代コンピュータ。論理を突き詰めれば、機械は人のように考えはじめる。膨大な予算と、当時の一流が集まった。本気だった。誰も、笑ってなどいなかった。
だが、特別な道具は、来なかった。
その壮大な目標は、思い描いた形では実らない。そして 1980 年代半ば、フレデリック・ブルックス（Frederick P. Brooks Jr.）――巨大なソフトウェア開発の難しさを、誰より知る技術者だ――が、静かに、しかし決定的なことを書く。
銀の弾丸は、ない。
彼が言ったのは、こういうことだ。ソフトの複雑さには二種類ある。たまたま今の道具が未熟なせいで生じる複雑さと、解こうとしている問題そのものが、本質的に抱えている複雑さ。前者は、よい道具で減らせる。だが後者は、どんな魔法の道具を持ってきても、消えない。複雑さは、退治すべき敵ではなく、問題の一部なのだ。
力で勝とうとした時代は、こうして静かに終わる。
勝てないなら、どうするか。
1960 年代から 1970 年代にかけて、ベル研究所の片隅で、まったく別の答えが育っていた。複雑さを倒すのをあきらめて、小さく分ける。
ダグ・マキルロイ（Douglas McIlroy）――UNIX という土壌を耕した一人だ――は、こう考えた。一つのことだけを、うまくやるプログラムを書く。そして、それらを組み合わせて使う。大きな一つではなく、小さな多数を。
それを象徴するのが、パイプという仕組みだ。小さな道具の出口を、次の道具の入口へ、縦棒一本でつなぐ。一つ一つは単純なのに、つなぐと複雑な仕事をやってのける。複雑さを、一個の頭で抱え込むのではなく、小さな部品に分けて預けてしまう。
この「分けて手なずける」という発想は、その後、いろいろな現場から少しずつ言葉を与えられていった。出どころは、ばらばらだ。航空機の整備の現場からは、KISS（Keep It Simple, Stupid）。経験を積んだ職人たちからは、DRY（Don't Repeat Yourself）。変化の速い開発の現場からは、YAGNI（You Aren't Gonna Need It）。どれも、複雑さを増やしすぎないための、別々の注意として生まれた言葉だ。
誰か一人の英雄が、上から決めたのではない。別々の場所で、別々の人が、同じ壁にぶつかり、似た知恵を持ち帰った。それらが寄り集まって、いつのまにか「当たり前」になった。
だから今、ベテランは、機能を足す前に一度、立ち止まる。
足すこと自体が悪いのではない。足したぶんだけ、全体が見渡せなくなる――その代償が見えているから、あの渋い顔になるのだ。
ただし、ここでよくある誤解を、ひとつ解いておきたい。
「いま要らないものは作るな」は、「先のことを一切考えるな」ではない。将来の変更に備えて余白を残すことと、来るかどうかもわからない機能を先回りで作り込むことは、まったく別だ。「同じことを二度書くな」も、「何でも一つにまとめろ」ではない。たまたま今だけ形が似ているコードを無理にひとつにすると、後でかえって、ほどけなくなる。
面白いのは、これらの誤解そのものが、小さな「銀の弾丸探し」だということだ。一つの原則を万能の魔法だと思い込んだ瞬間、人はまた、複雑さに足をすくわれる。
そして、この戦いは、今も終わっていない。
「大きな一つより、小さな多数を」。この教えを推し進めると、ひとつのアプリを、たくさんの小さなサービスに割っていく考え方になる。分ければ分けるほど身軽になる――はずだった。だが、分けすぎると、今度は部品と部品のあいだが複雑になる。複雑さは、結局どこかで、姿を変えて戻ってくる。
大きく作るか、小さく割るか。これは、まだ誰も最終的な答えを出していない、開いたままの問いだ。
それでも、百年かけてプログラマーが学んだことが、ひとつだけある。
複雑さは、力で消すものではない。小さく分けて、手なずけるものだ。なぜ、わざわざそうするのか。明日も、半年後も、このソフトに手を入れ続けられるように、だ。
シンプルさとは、複雑さに飲まれず、手を入れ続けられる――という自由だ。
この章でフレデリック・ブルックス（Frederick P. Brooks Jr.）が整理したのも、まさにその点だった。複雑さには、道具で減らせるものと、問題そのものに含まれるものがある。そして KISS、DRY、YAGNI もまた、万能の呪文ではなく、複雑さを増やしすぎないための別々の注意として読むと、それぞれが何を戒めているのかが見えてくる。もしここをもう少し掘りたくなったら、付録の用語集でそれぞれの綴りと意味を確かめてから、参考文献のブルックスへ進むと、この章で言いたかったことを追いやすい。
ただし、複雑さを分けただけでは、まだ足りない。
分けたその一つ一つが、読めなければ。半年後のあなたが、それを開いて「これは、何だ」とつぶやくなら、結局あなたは、また手を出せなくなる。
複雑さの次に立ちはだかるのは、読めなさという、もうひとつの不自由だ。
その話は、次の章で。
参考文献
- フレデリック・P・ブルックス Jr.『人月の神話』
- Frederick P. Brooks Jr., "No Silver Bullet: Essence and Accidents of Software Engineering"
- Brian W. Kernighan and Rob Pike, The Unix Programming Environment
第2章 コードは、誰のために書くのか
レビューが返ってきた。
ロジックは、どこも直されていない。動きは、何も変わっていない。直されたのは、ただ一つ――変数の名前だけだった。
tmp が、unpaidInvoices に変わっている。
それだけ。たったそれだけのことに、先輩はわざわざ一言を添えている。「動くんですけど、これだと半年後に読めないので」。
動く。なのに、読めない。その二つは、両立するのか。
ソフトウェアには、見落とされがちな事実がある。コードは、書かれる回数より、読まれる回数のほうがずっと多い。
一度書いたコードを、人はそのあと何度も読み返す。直すために読む。機能を足すために読む。なぜ壊れたのかを探すために読む。書くのは一瞬でも、読むのは、そのソフトが生きているあいだ、ずっと続く。
そして、その読み手は、たいてい未来の自分だ。半年もすれば、なぜそう書いたのか、きれいさっぱり忘れている。半年後の自分は、他人だ。 その他人が、何も思い出せないまま、あなたの書いた数行の前に立つ。
ここで、前の章の続きに気づく。複雑さを、小さく分けた。だが、分けた一つ一つが読めなければ、結局あなたは、また手を出せなくなる。分けることと、読めること。その二つがそろって、はじめて手を入れ続けられる。
読めなさ。これが、プログラマーを縛ってきた、もうひとつの不自由だ。
最初の答えは、親切だった。読みにくいなら、説明すればいい。コメントを書こう。
コードの脇に、人間の言葉で注釈を添える。この行は何をしているか。この変数は何を表すか。一行ごとに、ていねいに語る。かつて、読みやすさとは「コメントの量」のことだと、半ば本気で信じられた時代があった。手厚いほど親切だ、と。
だが、コメントには、ひとつ弱点がある。機械は、コメントを読まない。
機械が動かすのは、コードのほうだ。コメントは、ただの添え物として、素通りされる。だから、コードを直してもコメントはそのまま取り残される。書いた本人は、注釈まで直す義務を、機械から課されていない。
こうして、コメントは少しずつ、コードと食い違っていく。やがて、コードは右へ行けと言っているのに、コメントは左を指している、という事態が起きる。
間違ったコメントは、ない方がましだ。なにしろ、自信たっぷりに、間違った道を教えてくるのだから。手厚く書けば書くほど、腐ったときの嘘は増えていく。親切のつもりが、いちばん質の悪い罠になる。
ならば、どうするか。注釈で外から補うのをやめて、コード自体を、読めるものにする。
ドナルド・クヌース（Donald E. Knuth）――組版から教科書まで手がけた、計算機科学の巨人だ――は、こう言い換えてみせた。プログラムを書く仕事を、「機械に命令する作業」だと思うのはやめよう。「人間に、何をさせたいかを説明する作業」だと考え直そう、と。
同じころ、ある教科書の冒頭に、のちのち何度も引かれる一文が置かれる。プログラムは、人間が読むために書かれる。機械が実行するのは、ついでにすぎない。
そして、マーティン・ファウラー（Martin Fowler）――変更に強いコードの作法を、現場の言葉で広めた一人だ――は、もっと端的に言った。機械にわかるコードなら、誰でも書ける。人間にわかるコードを書けるのが、よいプログラマーだ。
ここで、梃子になるのが「名前」だ。
なぜ、コメントではなく名前なのか。理由ははっきりしている。名前は、コメントと違って、コードの一部だからだ。機械が実際に使う。だから、嘘をつきにくい。名前を変えれば、その名を呼んでいる場所すべてが、いやおうなく変わる。放っておけば置いていかれがちなコメントより、コードとのズレが起きにくい。コメントは添え物だから腐りやすい。名前は本体だから、ずっと食い違いにくい。
ここで、少し手を動かしてみてほしい。
三十日ログインのないユーザーを集めて返すだけの、数行の処理がある。これに、名前をつける。三通り、並べてみる。
f……何も言っていない。中を全部読むまで、何をするのかわからない。getUsers……「ユーザーを取ってくる」ことはわかる。だが、どのユーザーかは言っていない。結局、中を読むことになる。findDormantUsers（休眠ユーザーを探す）……中を開く前に、答えを返している。「ああ、しばらく使っていない人を探すのか」と。
半年後のあなたが、まっさらな頭で、このどれかと出会う。どれと出会いたいだろうか。
三番目の名前は、本来ならコメントが引き受けるはずだった説明を、自分で済ませている。しかも、コメントより腐りにくい。処理の中身が変われば、名前も直さざるをえないからだ。名前は、最も短く、最も嘘をつきにくいコメントだと言ってもいい。
だから今は、読みにくいと感じたとき、コメントを足す前に、まず名前を疑う。
ここで、よくある誤解を解いておきたい。「コメントを書けば、読みやすくなる」――これは、半分しか正しくない。
読みにくいコードにコメントを貼るのは、傷に絆創膏を重ねるようなものだ。tmp に「これは未払いの請求書です」と注釈するくらいなら、はじめから unpaidInvoices と名づければいい。コメントが要るのは、名前では言えないことを残すときだけだ。「なぜ」この一見おかしいやり方を選んだのか。なぜ、あえて遠回りをしたのか。その理由は、コードを見ても出てこないから、書き添える価値がある。
つまり、「何を」しているかは、名前とコードが語る。「なぜ」そうしたかは、コメントが語る。この線引きを取り違えて、「何を」までコメントで説明しはじめた瞬間、腐るコメントの山が育ちはじめる。
では、よい名前とは何か。そこから先は、まだ誰も決着をつけていない。
camelCase か snake_case か。英語で書くか、業務で使う言葉で書くか。短く済ませるか、長くても明確を取るか。チームごと、言語ごとに、今も議論は続いている。
ただ、一つだけ、疑いようがない。名前は、機械のためではなく、次に読む人間のためにつける。
そろそろ、最初の問いに答えられる。コードは、誰のために書くのか。
機械は、どんな名前でも動かす。tmp でも a1 でも、文句ひとつ言わない。名前に意味を求めるのは、ただ一人――いつかこのコードを開く、人間だけだ。
その人は、半年後のあなたかもしれないし、まだ会ったことのない誰かかもしれない。名前をつけるとき、あなたは、その人に向かって書いている。
名前をつけるとは、まだ見ぬ読み手に、理解する自由を贈ることだ。
ドナルド・クヌース（Donald E. Knuth）やマーティン・ファウラー（Martin Fowler）が繰り返し押していたのも、その見方だった。コードを機械への命令だけでなく、人に伝わる文章として見ること。コメントも、いらないのではなく役割が違う。「何を」は名前とコードに、「なぜ」はコメントに寄せると考えると整理しやすい。ここを自分でも確かめたくなったら、付録の用語集でコメントとリファクタリングを見てから、SICP や Fowler の本へ進むと腹に落ちやすい。
読めるコードができた。あなたは、半年後も、その中身をたどれる。
だが、半年のあいだに変わるのは、あなたの記憶だけではない。
「やっぱり、こうしたい」と、お客さんが言う。きれいに名づけ、きれいに分けたはずのコードに、最初は思ってもみなかった要求が、ぶつかってくる。
どうせ、仕様は変わる。その前提に、どう備えるのか。
その話は、次の章で。
参考文献
- Donald E. Knuth, "Literate Programming"
- Harold Abelson and Gerald Jay Sussman, Structure and Interpretation of Computer Programs
- Martin Fowler, Refactoring
第2部 変化との戦い
きれいに分け、読めるように名づけた。それでも、ソフトウェアには逃げられない現実がある。後から、変わるのだ。仕様が変わり、要求が変わり、前提が変わる。
第2部では、その「変わること」を、敵ではなく前提として引き受ける考え方を扱う。第3章は、最初にすべてを決めきろうとする設計が、変化の前であっけなく崩れるさまと、「決めすぎない」という発想の転換を追う。第4章は、いざ変えるたびに「どこかを壊していないか」という恐怖を、テストという仕組みでどう手なずけたかを扱う。
設計を緩めて変えられるようにすることと、変えても壊れていないと保証することは、表と裏だ。だから第3章の終わりは、第4章の備えへと続く。
第3章 どうせ仕様は変わる
仕様が、変わった。
先週、「これでいきましょう」と決めたはずだった。なのに、お客さんは悪びれずに言う。「やっぱり、こうしたいんです」。
あなたは、青ざめる。あの設計は、この要求を、まったく想定していない。きれいに組んだはずの段取りが、根元から合わなくなる。一から作り直しか――。
ところが、先輩は慌てない。お茶を一口飲んで、こう言うだけだ。
「まあ、変わりますよね。仕様って」
なぜ、こんなに落ち着いていられるのか。変わって困らない作り方を、この人は知っているらしい。
ソフトウェアづくりには、逃げられない現実がある。作りはじめる前に、すべてを正しく決めることは、できない。
人は、使えるものを目の前にして、はじめて「本当に欲しかったもの」に気づく。だから、動くものを見せたとたん、要求は動く。市場も、法律も、競合も動く。決めた前提は、決めたそばから古くなっていく。
これが、プログラマーを縛ってきた、次の不自由だ。最初に固めると、あとで動けない。
最初の答えは、いっそ潔かった。変わるのが困るなら、変わる前に、すべてを決めきってしまえばいい。
まず、完璧な設計図を描く。あらゆる場合を先回りして、隅々まで紙の上で固める。図さえ完成すれば、あとはそのとおりに組み立てるだけ――そう考えた。
1970 年代から 1990 年代にかけて、この夢は本気で追いかけられた。図を描けば、そこからプログラムが自動で生み出される。そんな道具に、巨額が投じられた。設計を図として記述する記法も整えられ、「この図を描ききれば、設計は終わる」と信じられた。手を動かして作るより、上流で考えきるほうが偉い、という空気さえあった。
だが、現実は、その夢をやすやすと裏切った。
完璧なはずの図は、最初の仕様変更ひとつで、ただの古い絵になった。図とコードは、別々に育っていく。直すのはいつもコードのほうで、図は放置され、やがて誰も信じなくなる。図から自動で完璧なコードが湧く、という道具も、約束したものを届けられなかった。
わかったのは、こういうことだ。図は、設計そのものではない。 それは、人と人が設計を話し合うための、会話の道具にすぎない。会話の道具を、未来を固定する契約書だと取り違えたところに、無理があった。
決めきろうとすればするほど、変化が来たときの痛手は大きくなる。固めた量だけ、動けなくなるのだ。
1990 年代後半、発想をまるごとひっくり返した人がいる。ケント・ベック（Kent Beck）。
彼が言ったのは、こうだ。変化は、避けるべき事故ではない。最初から、そこにある前提だ。 ならば、変化が来ないことに賭けるのをやめよう。来たときに、安く変えられるように作ろう。彼はそれを、強い言葉で掲げた。変化を、抱きしめろ。
考え方が逆なのだ。これまでは、変えずに済むように、最初にすべてを固めた。ベックは、いつでも変えられるように、あえて固めすぎない、と言う。
この発想は、彼ひとりのものではなかった。ウォード・カニンガム（Ward Cunningham）――まだ手を入れやすいうちに直さず放置したコードを、利子のつく「借金」にたとえた人だ――は、設計の先送りには代償が積み上がると説いた。マーティン・ファウラー（Martin Fowler）は、その手入れの作法を整理した。動いているコードの、外から見た動きはそのままに、内側の形だけを整える。この小さく安全な手直しを、彼らは一つの技術として確立した。
やがて、同じ考えを持った人たちが集まり、短い宣言を書き残す。計画に従うことよりも、変化に対応することを。 一人の英雄が決めたのではない。変化に何度も殴られた者たちが、別々の現場で同じ結論にたどり着き、それを言葉にしたのだ。
だから今、慣れたプログラマーは、仕様が変わっても青ざめない。最初から、変わる前提で作っているからだ。
一つ、混同されやすいことがある。いま言った「内側の形を整える」手直し――リファクタリングは、「作り直し」ではない。
作り直しは、いったん壊して、ゼロから組み直すことだ。動きが変わるかもしれないし、新しいバグも生まれる。大きな賭けになる。リファクタリングは、その正反対だ。動きは、一ミリも変えない。 名前を直し、絡んだ部分をほどき、形だけをきれいにする。外から見れば、何も変わっていない。だが内側は、次の変更を受け入れやすくなっている。
この二つを混同して、「リファクタリングします」と言いながらゼロから作り直しはじめると、たいてい火を噴く。動きを変えない、という一点こそが、この手入れを安全にしている。
では、設計は、どこまで先に決めておくべきなのか。そこから先は、まだ誰も決着をつけていない。
何も決めずに走りだせば、行き当たりばったりで迷子になる。決めすぎれば、変化で動けなくなる。前もって設計する量を、どこに置くか。その目盛りは、チームごと、プロジェクトごとに、今も探り続けられている。
ただ、向きだけは、もう定まっている。すべてを先に決めることは、できない。そして、決めきれないことは、弱さではない。
あの、お茶を飲む先輩に戻ろう。なぜ、仕様が変わっても動じないのか。
変わらないように身構えるのをやめて、変わってもいいように作っているからだ。決めるべきことは決め、決めきれないことは、決めきれないまま、手を入れられる形で残しておく。
設計とは、最初にすべてを決めなくていい――という自由だ。
ケント・ベック（Kent Beck）、ウォード・カニンガム（Ward Cunningham）、マーティン・ファウラー（Martin Fowler）が言葉にしたのは、変化を避けるのでなく、変化に耐える作り方だった。とくにリファクタリングは、外から見た動きを変えずに内側を整えることだと押さえておくと、作り直しとの違いを取り違えにくい。ここを誤解なく辿るなら、付録の用語集でアジャイルとリファクタリングを見てから、Beck と Fowler の本に進むのがいい。
変わってもいいように作る。言うのは簡単だ。
だが、いざコードの内側を直すたび、心配になる。この手入れで、どこか遠くを、静かに壊してはいないか。動きは変えていないつもりだ。けれど、「つもり」を、誰が保証してくれるのか。
完成したはずのコードに、それでも手を入れ続けるための、もう一つの備えがいる。
その話は、次の章で。
参考文献
- Kent Beck, Extreme Programming Explained
- Martin Fowler, Refactoring
- Ward Cunningham, "The WyCash Portfolio Management System"
第4章 完成したはずなのに、まだテストを書く
あなたが書いたコードは、動いている。
レビューに出す。返ってきたのは、こんな言葉だ。
「ここは、触らないほうがいいですね」
意味が、最初はわからない。動いているのに。直したい場所が、目の前にあるのに。なぜ、触ってはいけないのか。
実はこの章には、ひとりの主人公がいる。人ではない。「動いているのに、誰も触れないコード」だ。これから話すことは全部、その一点の恐怖をめぐっている。
プログラマーは、ずっとこの恐怖と暮らしてきた。
かつて、ソフトウェアをリリースするということは、半分、祈ることだった。手元では動いた。だから出す。あとは、壊れていませんように、と願う。実際、よく壊れた。しかも厄介なのは、直した場所ではなく、まったく関係のない遠くが壊れることだった。一行直すと、半年前に書いた別の機能が、静かに死ぬ。誰も全体を確かめられない。
1960 年代の終わりごろ、技術者たちは、ある言葉を口にしはじめる。ソフトウェア危機。 ハードウェアは年々速く、安くなっていくのに、それを動かすソフトだけが、大きくなるほど手に負えなくなっていく。作れるはずのものが、作れない。直せるはずのものが、直せない。業界全体が、「自分たちはソフトの作り方をまだ知らない」と認めた瞬間だった。
恐怖が現実になった例には、事欠かない。
1990 年代には、あるロケットが、前の機体で何年も正しく動いていたプログラムを、ほぼそのまま新しい機体に積んだ。古い機体では決して起こらなかった計算上のあふれが、より速く飛ぶ新しい機体では起きた。誰も、そこを確かめていなかった。例外は誰にも受け止められず、装置は自ら停止し、機体は打ち上げから一分足らずで、自分を破壊した。
動いていたコードは、文脈が変わった瞬間に牙をむく。 これが、恐怖の正体だ。
最初の答えは、素朴だった。人間が、頑張って確かめる。
リリースの前に、手で一通り動かす。専門の担当者を立てて、画面を端から端まで叩いてもらう。徹夜の総点検。問題があれば、見つかる。たぶん。
けれど、これは規模に負ける。機能が二つなら、組み合わせは数えられる。十、二十と増えていけば、確かめるべき道筋は、人間の手に負えない数に膨れ上がる。どれだけ丁寧に総点検しても、確かめきれない一点が必ず残る。
そして恐怖は、こうして悪化する。怖いから、触らない。触らないから、古びる。古びるから、もっと怖くなる。
ここで、その答えを先取りしていた人たちがいる。
1969 年、月へ向かう着陸船の中。降下の最中、画面にプログラム警報コードが灯った。1202。 それは、「いま処理があふれている。全部はさばききれない」という合図だった。普通なら、固まる。だが、そのソフトは固まらなかった。優先度の低い仕事を自分から投げ捨て、着陸という一点だけを、生かし続けた。
設計したのは、マーガレット・ハミルトン（Margaret Hamilton）たちのチームだ。ハミルトンは、ソフトウェアを書く仕事を、まだ誰もそう呼ばなかった時代に「工学」と呼んだ人である。彼らは、起こりうる最悪を先に数え上げ、「そのとき機械がどう自分を守るか」まで作り込んでいた。だから 1202 は、故障ではなかった。設計どおりに、自分を守っているという報告だったのだ。
その数字は、月面着陸を止めなかった。
そして半世紀後。別の合図が、あなたの画面に、毎日のように灯る。テストを実行したとき、期待どおりに動かなかったことを知らせる表示だ。
FAIL。
よく似ている。どちらも、機械が「ここが危ない」と先に教えてくれている。違うのは、1202 が一度きりの本番だったのに対し、FAIL のほうは、あなたが安心して何度でもやり直すために、自分で、わざと鳴らしているということだ。
信頼は、祈りではなく、設計できる。
ハミルトンたちが月の上で示したことを、地上のありふれた開発に持ち込んだ人たちがいる。
そして 1990 年代後半になると、ケント・ベック（Kent Beck）――エクストリーム・プログラミングを提唱した一人である――は、書いたコードのとなりに「これはこう動くはずだ」という小さな検査を一緒に置いておく、という作法を広めた。変更するたび、機械がその検査を全部やり直す。壊れたら、その場で、赤く知らせる。
ここが、この章のいちばん大事なところだ。
自動テストのいちばん大きな値打ちは、品質を証明することではない。
よくある誤解を、ひとつ解いておきたい。テストは、「バグがないことの証明」ではない。エドガー・ダイクストラ（Edsger W. Dijkstra）――構造化プログラミングを唱えた計算機科学者の一人だ――は、こう指摘した。テストはバグがあることは示せても、バグがないことは、決して示せない。どれだけ検査を足しても、「これでもう完璧です」とは言えない。カバレッジが 100 パーセントでも、それは安全の証明書ではない。
では、テストは、何を守っているのか。
最初の恐怖に戻れば、わかる。「動いているのに、誰も触れない」。テストは、その呪いを解く。検査がすべて緑なら、あなたは安心してコードに手を入れられる。何か壊せば、機械がすぐ、赤く教えてくれるからだ。
テストを書くという方向そのものは、もう決着がついている。いまさら、手作業の総点検だけに戻ろうという人はいない。まだ開いているのは、その先だ。先に書くか、後に書くか。どこまで書けば十分か。そこには、いまも本物のトレードオフが残っている。
けれど、入口の問いには、もう答えられる。
完成しているのに、なぜ、まだテストを書くのか。
テストが第一に守っているのは、品質の証明書ではない。
テストとは、明日も、来年も、このコードに触れ続けられる――という自由だ。
マーガレット・ハミルトン（Margaret Hamilton）、ケント・ベック（Kent Beck）、エドガー・ダイクストラ（Edsger W. Dijkstra）が、それぞれ別の角度から見ていたのも、信頼、変更、証明の限界だった。テストは万能の保証書ではない。けれど、変更したときにすぐ異変へ気づく仕組みとして、とても強い。作法より先に「なぜテストを書くのか」を考えたければ、参考文献の Myers や Beck を辿ると理解しやすい。
明日も触れる自由を、あなたは手に入れた。
だが、コードはもう、一人で抱えるには大きすぎる。その自由を、大勢で、どう信頼し合うのか。
その話は、次の章で。
参考文献
- Glenford J. Myers, The Art of Software Testing
- Margaret Hamilton, "Computer Gotchas"
- Edsger W. Dijkstra, Notes on Structured Programming
第3部 一人では作れない
ここまでの不自由は、コードと自分のあいだの戦いだった。第3部から、相手が変わる。ソフトウェアは、もう一人で抱えるには大きすぎる。
第3部では、知識を一人の頭に閉じ込めないための工夫を扱う。第5章は、なぜ動いているコードをわざわざ他人に見せるのか――属人化という不自由と、見せ合いを文化にしたレビューの話だ。第6章は、その「見せ合い」を会社やチームの壁を越えて世界中へ広げたとき何が起きたか――オープンソースを扱う。
第6章は、この本の心臓にあたる。ここでだけは、歴史の当事者自身が、文字どおり「自由」を旗印に掲げた。チームの共有から世界の共有へ。第5章の終わりは、その飛躍の入り口になる。
第5章 なぜ、他人にコードを見せるのか
「これ、レビューに出しておいてください」
そう言われて、あなたは少しためらう。コードは、もう動いている。テストも通っている。なのに、なぜ、わざわざ他人の目にさらすのか。
見せれば、粗が見つかる。「ここ、おかしくないですか」と言われる。せっかく書いたものに、赤い印が並んで返ってくる。動いているのに、わざわざ恥をかきにいくようなものではないか。
見せたくない。その気持ちの裏に、ひとつの落とし穴が隠れている。
ソフトウェアは、一人で抱えられるうちは、気楽だ。全部、自分の頭の中にある。どこに何があるか、なぜそう書いたか、聞かなくてもわかる。
だが、その「自分だけがわかる」状態には、値札がついている。
考えてみてほしい。決済まわりのコードを、たった一人が握っている。仕様も、癖も、落とし穴も、すべてその人の頭の中だけにある。チームは、何かあるたび「あの人に聞けばいい」で回している。
ある日、その人がいなくなる。転職でも、長い休みでも、理由は何でもいい。残されるのは、誰も中身を知らない、触れないコードの山だ。
これが、プログラマーを縛ってきた、次の不自由だ。一人が消えたら、誰も触れない。 しかも縛られているのは、残された側だけではない。握っている当人も、抜けられない。休めない。倒れられない。「あの人に聞けばいい」は、あの人を、逃げ場のない場所に閉じ込める呪いでもある。
最初の答えは、むしろ逆を向いていた。詳しい一人がいれば回るなら、その一人に頼ればいい。
エースに任せる。いちばん詳しい人間が、いちばん難しいところを抱える。チームは、その人を中心に組み立てられる。属人化は、避けるべき欠陥ではなく、頼れる強みだと思われていた。「あの人がいるから大丈夫」――それは、ほめ言葉ですらあった。
だが、その作り方は、たった一つの出来事で崩れる。その一人が、いなくなったとき。
引き継ぎ書を残していても、足りない。文書は、コードの「何を」は書けても、「なぜ」までは書ききれない。書いた本人にとって当たり前すぎたことは、そもそも書かれない。残るのは、動いてはいるが、誰も理由を説明できないコードだ。
「あの人に聞けばいい」は、あの人がいるあいだしか成り立たない。たった一人に知識を預けることは、その人を質に取られているのと変わらない。強みに見えていたものが、いちばんもろい一点だったと、いなくなってはじめて気づく。
ならば、どうするか。知識を、一人の頭に閉じ込めない。書いている最中から、見せ合う。
書きながら、二人で一つの画面に向かう。一人が書き、もう一人がその場で読む。書き上がったコードを、別の誰かの目に通してから取り込む。やり方はいろいろあるが、狙いは一つだ。一人の頭の中にしかない知識を、外に出して、複数の人が触れる状態にする。
2000 年代後半から 2010 年代にかけて、この「見せ合い」を、一部の現場の作法から、世界中の当たり前へ押し広げた仕組みがある。プルリクエストだ。
自分の変更を、いきなり本体に入れるのではなく、いったん「こう変えたいのですが、どうでしょう」と提案の形で差し出す。誰でもそれを読み、その場で意見を書き込み、納得してから取り込む。この一連の流れを、誰もが使える普通の手続きにした。見せ合うことは、特別な儀式ではなくなった。
ここで、少し考えてみてほしい。同じ一つの指摘を、二通りの言い方で書く。
- 「ここ、間違ってます。直してください。」
- 「ここ、こうするとどうでしょう？ もし意図があれば教えてください。」
どちらも、伝えている中身は同じだ。だが、受け取ったあなたは、次もコードを見せたくなるだろうか。前者を何度ももらえば、人は見せるのが怖くなる。後者なら、見せてよかったと思える。
この違いは、好みの問題ではない。見せ合いの文化が続くかどうかが、ここにかかっている。
だから今、レビューは、粗探しの品評会ではない。
ここで、ありがちな思い違いを正しておきたい。レビューとは、「相手のコードの欠点を、ひとつ残らず指摘すること」ではない。
すべての粗を並べ立て、優劣をつける場にした瞬間、人は見せるのをためらいはじめる。見せなくなれば、知識はまた一人の頭に閉じこもる。それでは、何のためのレビューかわからない。
レビューの目的は、相手を負かすことではない。コードを、複数の人が触れる状態にすることだ。だから、致命的でない好みの違いは、ときに流す。理解を分け合うことを、粗探しより優先する。指摘の数ではなく、見せ合いが続くことを大事にする。
では、どこまでレビューすべきなのか。誰の承認があれば取り込んでいいのか。そして、その目をどこまで機械に任せられるのか。そこから先は、まだ決まっていない。
形式的な誤りは、機械が自動で見つけるようになった。最近では、人より先に道具が下読みをすることもある。それでも、「なぜこう書いたか」を分かち合う部分は、まだ人の手に残っている。どこまでを機械に渡し、どこからを人が担うか。その線引きは、いまも動いている。
ただ、こればかりは、もう揺るがない。コードは、一人の頭に閉じ込めない。書いたら、見せる。
あのためらいの正体が、これで見える。なぜ、動いているコードを、わざわざ他人に見せるのか。
見せるのは、欠点をさらすためではない。あなたの頭の中だけにある知識を、外に出して、チームの共有物にするためだ。そうすれば、あなたは安心して休める。倒れても、コードは生き続ける。誰かが辞めても、それは終わりではなくなる。
レビューとは、コードを一人の記憶から解き放つ――という自由だ。
1970 年代にマイケル・ファガン（Michael E. Fagan）――IBM でソフトウェア検査の手法を整えた技術者だ――が整えたのも、レビューやインスペクションを属人的な善意ではなく、手法として扱う考え方だった。いまその流れをいちばん想像しやすいのが、プルリクエストという形だ。変更を提案として出し、読んで、話し合ってから取り込む。いまの開発現場でこの話がどう回っているかは、GitHub の Pull Requests の文書を見るとイメージしやすい。
見せ合うことで、コードは、チームみんなのものになった。
だとしたら、その「みんな」を、もっと広げたら、どうなるだろう。会社の壁も、チームの境目も越えて、世界中の誰にでも、コードを見せてしまったら。
無料で公開して、いったい何の得があるのか。
その話は、次の章で。
参考文献
- Michael E. Fagan, "Design and Code Inspections to Reduce Errors in Program Development"
- Karl E. Wiegers, Peer Reviews in Software
- GitHub Docs, Pull Requests
第6章 無料で公開して、何の得があるのか
1980 年代初め、ある研究所に、一台のプリンタがあった。
よく紙が詰まった。詰まっても、誰にも知らされない。みんな、印刷したつもりで席に戻り、しばらくして「まだ出てこない」と気づく。
そこにいた一人の技術者は、考えた。紙が詰まったら、使っている全員に知らせる。たったそれだけの仕組みを、自分で足せばいい。前に使っていた別のプリンタでは、実際にそうしていた。中の仕組みに、数行を書き足すだけのことだ。
だが、できなかった。新しいプリンタの中身――それを動かしているソフトは、外に公開されていなかった。読むことも、直すことも、許されていない。たった数行のために、彼は、作った会社が気が向くのを待つしかなかった。
彼は、納得がいかなかった。自分が毎日使う道具の中身を、なぜ、自分で直してはいけないのか。
この小さな出来事の中に、大きな不自由が畳み込まれている。
ソフトの中身が見られないと、使う人は、作った者に従属するしかない。困っても、自分では直せない。気に入らなくても、作り替えられない。会社が「もう売りません」と言えば、明日からそのソフトは、誰にも直せないまま死ぬ。あなたは、ただ待つ人になる。直す力も、学ぶ機会も、配る権利も、手元にはない。
これは、昔話ではない。中身を開けられない機械、勝手に修理してはいけない製品、契約で分解を禁じられたソフト。今のあなたの周りにも、同じ不自由は、いくらでもある。
たとえば、毎日使っているブラウザの開発者ツールでページの中身をのぞくこと。Gem や npm パッケージのコードを開いて、どこで動いているのかを追うこと。バグに気づいて issue を立てたり、手元で直して pull request を送ったりすること。受講生が「ちょっと中を見てみる」と言えるのは、この自由が、すでに足元まで降りてきているからだ。
この不自由は、長いあいだ、当たり前の商売の形でもあった。ソフトの中身は、秘密にして売る。
中身を見せれば、真似される。だから隠す。隠すことが、価値を守るのだと考えられた。ソフトを買うとは、動く結果だけを受け取ることで、中の仕組みは、作った会社だけのものだった。
理屈は通っている。だが、その当たり前は、使う人から力を奪っていた。バグを見つけても、報告して待つしかない。自分の仕事に合わせて少し変えたくても、手が出せない。会社の都合ひとつで、頼っていた道具が消える。使う人は、いつまでも、無力なままに置かれた。
1980 年代半ば、ここで、さきほどの技術者が動く。リチャード・ストールマン（Richard Stallman）。MIT の AI 研究所で働いていたプログラマーだ。
彼は、こう考えた。ソフトを使う人には、本来、四つの当たり前の権利があるはずだ。自分の目的で使う。中身を読んで学ぶ。直したいように直す。それを他人に配る。 中を隠す商売は、この四つを、まとめて取り上げていた。彼は、それを取り戻そうとした。
そして、ひとつの宣言を書く。誰でも使え、誰でも中身を読め、誰でも直して配れる――そういうソフトを、自分たちの手で作り上げる、と。
ここで、言葉の取り違えを、一つ解いておきたい。彼が掲げたのは「フリーソフトウェア」だった。だが、この「フリー」は、無料という意味ではない。自由、という意味だ。 英語の free には、両方の意味がある。彼が言いたかったのは、値段が 0 円だということではなく、使う人が縛られていない、ということだった。ただ酒のフリーではなく、言論のフリーだ、と彼は繰り返した。
そしてこの一語こそ、この本がずっと追いかけてきたものだ。
ひとりの宣言は、思いがけない広がり方をした。
世界中の見知らぬ技術者たちが、自分の手元から少しずつ、部品を持ち寄りはじめた。やがて 1990 年代初め、その流れに、一人の学生が書いた中核部分が合流する。リーナス・トーバルズ（Linus Torvalds）――フィンランドの大学生で、のちに多くのサーバーやスマートフォンの土台になる基盤を書きはじめた人だ。誰のものでもないソフトが、本物の、実用に耐えるものとして組み上がっていった。
そして 2000 年代半ば、膨大な人数が、同じソフトに同時に手を入れる。その混乱を捌くために、トーバルズは、もう一つの道具まで作ってしまう。Git である。誰が、いつ、どこを変えたかを記録し、離れた場所の変更を安全に束ねる仕組みだ。いま、多くのプログラマーが毎日使っている、あれである。
同じ考えは、コードの外へも漏れ出した。誰でも書き換えられる百科事典が、専門家が囲い込んだ百科事典を、いつのまにか追い抜いていた。中を開き、皆で直し、自由に配る。その形が、コードでないものまで作り替えていった。
だから今、インターネットの多くの土台は、こうして公開されたソフトの上で動いている。あなたが今日触れた技術の見えないところにも、誰かが公開したコードが、いくつも積み重なっている。
ここで、よくある誤解を、二つ解いておきたい。
ひとつ。これは「タダ働き」や「趣味の善意」ではない。世界中の企業が、本業として、給料を払って、公開されるソフトに人を投じている。なぜか。土台を皆で共有したほうが、各社が秘密に抱えるより、結局みんなが速く進めるからだ。自由なソフトは、慈善ではなく、れっきとした戦略になった。
もうひとつ。さきほどの「フリー」だ。公開されているからといって、何でも 0 円で好き放題できる、という意味ではない。自由には、作法がある。直したものは同じように皆に開け、作った人の名は消すな――そうした約束の上で、自由は回っている。自由とは、無法とは違うのだ。
では、その自由を、どうやって支え続けるのか。そこから先は、まだ誰も答えを出していない。
世界が頼りきっている土台が、たった数人の、無償の善意で支えられている、ということが珍しくない。彼らが疲れ果てて手を引けば、世界が揺らぐ。タダで配るものに、どう報いるのか。自由を、誰が支えるのか。この問いは、いまも開いたままだ。
ただ、譲れない一線だけは、はっきりしている。使う人から、直す力を取り上げない。中を開き、皆で直し、自由に配る。
問いそのものに、戻ってみる。無料で公開して、何の得があるのか。
問いの立て方が、そもそも、ずれていた。彼らが手に入れようとしたのは、金銭の得ではない。あのプリンタの前で、一人の技術者が奪われていたものだ。自分の使う道具の中身を、自分で開き、自分で直し、自分で配る。 その当たり前を、取り戻すこと。
オープンソースとは、直し、見て、配る――その自由そのものだ。
リチャード・ストールマン（Richard Stallman）とリーナス・トーバルズ（Linus Torvalds）が、それぞれ別の仕方で押し広げたのも、その自由だった。フリーソフトウェアとオープンソースは重なる部分が大きいが、強調点は少し違う。まずは「無料」より「自由」が先だと押さえると、この章の話を追いやすい。用語集の GNU とオープンソースを見てから Stallman や Raymond の文章に進むと、その違いもたどりやすい。
こうして、プログラマーたちは、自由に作り、自由に配れる世界を手に入れた。
ところが、その自由な世界の中で、彼らは、いつまでも言い争うのをやめない。この書き方か、あの書き方か。この道具か、あの道具か。決着がついたものもあれば、何十年も平行線のままのものもある。
なぜ、その議論は、終わらないのか。
その話は、次の章で。
参考文献
- Richard Stallman, Free Software, Free Society
- Sam Williams, Free as in Freedom
- Eric S. Raymond, The Cathedral and the Bazaar
第4部 正解はない
自由に作り、自由に配れる世界を手に入れたあとも、プログラマーは言い争うのをやめない。タブかスペースか。この言語か、あの言語か。何十年も決着しない論争が、いくつもある。
第4部では、その「終わらない議論」との付き合い方を扱う。鍵になるのは、問いを二種類に分けることだ。決着のついた閉じた問いと、どちらにも理由がある開いた問い。第7章で、その枠組みそのものを手渡す。第8章は、開いた問いの最たるもの――言語選びと、ありものに満足できず言語そのものを作る選択。第9章は、作ったものを誰の許可もなく世界へ届ける、Web という仕組みを扱う。
この部だけ、勝ち取る自由の形が少し違う。他の部が自由を「獲得」する物語なら、第4部は、自由を一つの正解に「潰さない」物語だ。「正解はない」は、投げ出しではなく、選び続ける責任を引き受けることだと、ここで示す。
第7章 その議論は、なぜ終わらないのか
チャットが、燃えている。
きっかけは、ごく小さなことだった。インデントは、タブか、スペースか。たったそれだけの話に、何十件もの投稿が積み上がっている。大の大人が、本気で、一歩も譲らない。
あなたは、戸惑う。どちらでも、コードは動く。なのに、なぜ、こんなことで、こんなに揉めるのか。そして、もっと不思議なのは――この手の論争が、何年も、ときには何十年も、決着しないまま続いていることだ。
なぜ、その議論は、終わらないのか。
プログラマーには、ひとつの癖がある。「正しい、たった一つの答え」を、探したがる。
これは、悪い癖ではない。むしろ、ここまで見てきた多くの前進は、より良い一つを探す力から生まれた。だが、この癖には裏がある。どんな問いにも唯一の正解があるはずだ、と思い込むと、答えの出ない問いの前で、人は延々と争い続けることになる。
終わらない論争の正体は、たいていこれだ。本来は決着のつかない問いを、決着がつくはずだと信じて、殴り合っている。 唯一の正解という幻が、争う人々を、その場に縛りつけている。
これが、この部で向き合う不自由だ。「正しい一つ」に、縛られる。
最初の答えは、力ずくだった。決着がつかないなら、誰かが「これが正解だ」と決めてしまえばいい。
権威ある誰かが宣言する。あるいは、論争に勝ったほうが、唯一の正解の座につく。みんながそれに従えば、不毛な争いは終わる――そう考えられた。実際、プログラミングの歴史には、「これが絶対だ」という宣言が、いくつも刻まれている。
だが、その「唯一の正解」は、何度も裏切られた。
ある時代に「これしかない」とされた書き方が、文脈が変わったとたん、時代遅れになる。万能とされた道具が、別の現場ではまるで役に立たない。唯一の正解を立てるたびに、後になって、「あれは、ある条件の中での正解にすぎなかった」と判明する。これは、第1章で見た「銀の弾丸探し」の、別の顔だ。一つの答えですべてを片づけたい、という誘惑が、また顔を出している。
ここで、問いには二つの種類がある、と気づいた人たちがいた。
閉じた問いと、開いた問い。 この二つを、分ける。
閉じた問いは、決着のついた問いだ。なぜ片方が残ったのかを、はっきり語れる。
たとえば、かつて、プログラムの流れをあちこちへ自由に飛ばす書き方をめぐって、大きな論争があった。エドガー・ダイクストラ（Edsger W. Dijkstra）――テストの章でも顔を出した、計算機科学者の一人だ――は、その自由な飛び方が、コードを誰にも追えない迷路にする、と論じた。流れを、決まった形の積み重ねだけで書こう、と。この論争には、勝者がいる。今、彼の言うとおりの書き方が、当たり前になっている。これは、閉じた問いだ。
開いた問いは、決着のつかない問いだ。どちらにも、ちゃんとした理由がある。だから、勝ち負けを書けない。
たとえば、型のあるなしをめぐる長い論争。書くときの安全を取るか、書くときの身軽さを取るか。どちらにも、確かな言い分がある。これは、何十年経っても決着していないし、おそらくこれからも決着しない。タブかスペースか、も、この仲間だ。
ここで、少し仕分けをしてみてほしい。
世の中で繰り返されている論争を、いくつか思い浮かべる。そして、一つずつ、自分に問う。これは、勝者を語れる閉じた問いか。それとも、どちらにも理由がある開いた問いか。
最初の数件は、迷うはずだ。だが、この「どちらの種類の問いなのか」を、議論を始める前に見分けられるようになると、世界が変わる。閉じた問いなら、答えを学べばいい。開いた問いなら――勝とうとするのをやめて、選び方を考えればいい。
だから今、成熟したプログラマーは、論争に飛び込む前に、まずその種類を見分ける。
ここで、いちばん大事な誤解を解いておきたい。「正解はない」とは、「どっちでもいい」という意味ではない。
開いた問いに決着がつかないからといって、何でもありになるわけではない。「全部アリ」は、考えるのをやめた人の言葉だ。閉じた問いには、ちゃんと答えがある。学ばずに「人それぞれ」で済ませれば、ただの怠慢だ。そして開いた問いでさえ、「この場面では、こちらの理由が勝つから、こちらを選ぶ」と、根拠を持って選べる。
「正解はない」とは、投げ出すことではない。唯一の正解という幻に縛られるのをやめて、自分の文脈で選ぶ責任を、引き受けることだ。
では、どの問いが、いつか閉じるのか。それは、誰にもわからない。
今は開いている問いが、未来に決着するかもしれない。逆に、閉じたと思われた問いが、新しい文脈で、もう一度開くこともある。問いの仕分けそのものが、永遠に更新され続ける。だから、この見分けに、最終版はない。
ただ、一つの構えだけは、変わらない。すべての問いに唯一の正解がある、とは考えない。
では、冒頭の炎上に戻ろう。なぜ、その議論は終わらないのか。
終わらない議論は、たいてい、開いた問いを閉じようとしているからだ。どちらにも理由があるものに、無理やり唯一の正解を立てようとするから、永遠に殴り合うことになる。
種類さえ見分ければ、あなたは、その消耗から降りられる。勝ち負けではなく、選び方の話を始められる。
「正解はない」とは、選ぶ自由を手放さない、という積極的な答えだ。
エドガー・ダイクストラ（Edsger W. Dijkstra）が残したのも、すべての議論を終わらせる魔法ではなく、「決着がつく問い」のはっきりした例だった。この章で置いた閉じた問いと開いた問いも、覚えるための用語というより、議論を整理するための見取り図として読んでほしい。身近な論争を一つ選んで、自分で仕分けしてみると、この章が急に手元の話になる。
開いた問いの、最たるものがある。どの言語で書くか、だ。
言語は、ただの道具ではない。何を簡単にし、何を難しくするかで、書く人の考え方そのものを、静かに形づくる。
では、用意された言語の、どれもが気に入らなかったら――人は、どうするのか。
その話は、次の章で。
参考文献
- Edsger W. Dijkstra, "Go To Statement Considered Harmful"
- Alan Kay, "Simple Things Should Be Simple, Complex Things Should Be Possible"
- 各言語・各コミュニティのスタイルガイド
第8章 言語をつくる、という選択
「自分で、プログラミング言語を作った人がいるんですよ」
そう聞いて、あなたは、ちょっと驚く。世界には、もう数えきれないほどの言語がある。なぜ、わざわざ、もう一つ増やすのか。車輪を、もう一度発明するようなものではないか。
だが、その「もう一つ」が、あなたが今、毎日書いている言語かもしれない。誰かが、ありものに満足できず、ゼロから作ったもの。その人は、いったい、何が気に入らなかったのか。
まず、見落とされがちなことがある。言語は、ただの道具ではない。書く人の考え方そのものを、静かに形づくる。
どんな言語も、あることを簡単にし、別のことを難しくする。そして、難しいことは、だんだん「やらなくなる」。やらないうちに、やがて「思いつきもしなくなる」。気づけば、人は、その言語が許すことの範囲でしか、ものを考えられなくなっている。
これは、自分では気づきにくい。檻の中にいる者には、檻の外が見えない。もっと楽に書ける世界があると知らなければ、今の不便を、不便とすら感じない。「プログラミングとは、こういうものだ」と思い込む。
これが、この章の不自由だ。言語が許すことしか、考えられない。
最初の答えは、まっとうだった。ありものの中から、いちばんマシなものを選ぶ。
速いから、これにしよう。みんなが使っているから、これにしよう。仕事で求められるから、これにしよう。世にある選択肢を見比べて、その中の一つに決める。賢い選び方だ。
だが、どれを選んでも、ひとつ、ついて回るものがある。その言語を作った人の価値観だ。
速さを何より優先して作られた言語は、書く人に、こまごました我慢を強いる。理論的な正しさを突き詰めた言語は、近寄りがたい。流行で選んだ言語が、自分の作りたいものと、根っこのところで噛み合わないこともある。
選んでいるつもりで、実は、選ばされている。誰かの価値観が染み込んだ道具に、こちらの考え方を、合わせ続けている。ありものから選ぶかぎり、その誰かの価値観からは、逃げられない。
1990 年代半ば、ここで、まったく別の基準を持ち込んだ人がいる。まつもとゆきひろ（Matz） だ。FjordBootCamp で多くの受講生が触れる Ruby を作った人でもある。
彼が Ruby を作るとき、第一に置いたのは、速さではなかった。理論的な美しさでもなかった。書く人が、楽しいこと。 ただ、それだった。
奇妙に聞こえるかもしれない。道具を作るのに、性能でも正しさでもなく、「楽しさ」を中心に据える。だが、彼の理屈は、筋が通っていた。道具は、人間のためにある。 ならば、人間が道具に我慢するのは、おかしい。書いていて気持ちがいい、書いていて嬉しい――そういう言語があっていいはずだ。Matz は、人間が機械に歩み寄るのではなく、機械を人間のほうへ引き寄せようとした。
これは、彼ひとりの考え方ではない。言語を作る人は、それぞれの価値観を、道具に込める。一つのことを、いろんなやり方で書ける自由を大事にした人。逆に、誰が書いても同じ形になる素直さを選んだ人。読みやすさを、何よりも上に置いた人。言語の数だけ、「何を大事にするか」の答えがある。
だから今、言語は、性能の順位表ではない。価値観の、見本市だ。
ここで、しばしばある誤解を解いておきたい。言語を選ぶこと、まして作ることは、「速いから」「流行っているから」で決まる話ではない。
速さは、たしかに大事だ。だが、それは数ある価値観の、一つにすぎない。速さのために何を捨てるか、捨てないか――そこにこそ、その言語の思想が出る。流行も同じだ。なぜ流行ったのかをたどれば、たいてい、多くの人の価値観に響く「何か」がそこにある。性能の数字や流行の波だけを見て選ぶのは、いちばん大事なところを見落としている。
問うべきは、「速いか」ではない。「自分は、何を大事にしたいのか」だ。
では、どんな価値観の言語が、いちばん良いのか。それは、答えの出ない問いだ。
前の章の言葉でいえば、これは「開いた問い」だ。楽しさか、速さか、安全か、素直さか。言語に優劣をつけられないのは、価値観に優劣をつけられないのと、同じことだ。だから、言語をめぐる論争も、終わらない。終わらなくて、いい。
ただ、芯だけは、ぶれない。道具に、人間が合わせるのではない。人間の価値観に合わせて、道具のほうを、選び直す。
最初の驚きに、戻ろう。なぜ、わざわざ、新しい言語を作るのか。
ありものが気に入らなかったからだ。正確に言えば、ありものに染み込んだ価値観に、従いたくなかったからだ。彼らは、与えられた檻の中で我慢する代わりに、自分の大事にするものを中心に、道具そのものを作り直した。
言語を作るとは、究極の「選び直し」だ。何を簡単にし、何を大事にするかを、自分で決める。
言語をつくるとは、自分の価値観で、道具を選び直す自由だ。
まつもとゆきひろ（Matz）が Ruby を通じて見せたのも、言語設計は速さや流行の競争だけではなく、「何を簡単にし、何を難しくするか」を決める営みだということだった。Ruby を使わない読者でも、好きな言語を一つ選んで、その言語は何を大事にしていそうかと考えてみると、この章は自分の話になる。
こうして、人は、自分の価値観で道具を作り直せるようになった。
だが、作っただけでは、誰にも届かない。作ったものを、世界中の人の手元へ運ぶには、また別の壁がある。どの会社の許可も、どの機械の都合も超えて、作ったものを、いきなり世界へ送り出す。
そんなことが、どうして可能になったのか。
その話は、次の章で。
参考文献
第9章 Web だけが、世界を覆った
あなたは、作ったものを、友達に見せたい。
「URL ちょうだい」と言われて、リンクを一つ送る。それだけだ。相手は、何もインストールしない。Windows でも、Mac でも、手元のスマートフォンでも、リンクを開いた瞬間に、あなたの作ったものが動きだす。
あまりに当たり前で、すごさに気づかない。だが、少し前まで、これは魔法のような話だった。作ったものを、世界中の、どんな機械を使っている誰にでも、許可も審査もなしに、一瞬で届ける。なぜ、Web だけが、こんなことを可能にしたのか。
かつて、作ったものを人に届けるのは、途方もない難事業だった。
機械の種類ごとに、作り直す。この OS 用、あの OS 用、と何通りも用意する。そして、配る道は、たいてい誰かに握られていた。プラットフォームの持ち主が「うちでは配らせない」と言えば、それで終わり。どれだけ良いものを作っても、届けるかどうかの最後の鍵は、作り手ではなく、別の誰かが持っていた。
これが、最後の不自由だ。機械や、配る場所の持ち主に縛られて、作ったものが、届かない。
1990 年代、最初の答えは壮大だった。バラバラな機械やソフトを、一つの完璧な共通規格で、統一してしまえ。 その象徴の一つが、CORBA（Common Object Request Broker Architecture） だった。
世界中のあらゆるシステムが、同じ精密な作法でつながる。そういう、分厚くて、厳密で、隙のない標準が設計された。きっちり決めきれば、何でも、何とでもつながるはずだ――そう信じられた。一流の頭脳と、大企業の連合が、本気でそれに取り組んだ。
だが、その重い標準は、広く使われるには、重すぎた。
仕様は、分厚かった。読みこなすだけで一苦労だ。きちんと動かすには高価な道具が要り、扱える技術者は限られた。完璧を目指した精密さが、そのまま、参加の高い壁になった。少数の大組織は使えても、世界中の名もない作り手には、手が出せない。
ここに、この章の影の主役がいる。完璧を目指して、重くなりすぎたもの。 それは立派な設計だった。だが、立派さは、普及とは別のことだった。誰もが参加できなければ、世界は覆えない。
世界を覆ったのは、その正反対だった。ゆるく、軽く、つなぐ。
1990 年代初め、Web は、拍子抜けするほど単純な仕組みで始まった。文書に少しだけ印をつける書き方――HTML（HyperText Markup Language）。その文書を「ください」と頼んで受け取るだけの、素朴な約束ごと――HTTP（Hypertext Transfer Protocol）。そして、受け取った文書を映す窓――ブラウザ。どれも、厳密とはほど遠い。多少いいかげんでも、動く。だからこそ、誰でも参加できた。
やりとりの作法でも、軽いほうが広く浸透した。重厚な手続きを踏ませる方式は、結局、あの分厚い標準と同じ悩みを抱えやすかった。代わりに広まったのは、REST（Representational State Transfer） に象徴される、「ものごとに住所を与えて、その住所へ取りに行く」という、あっけないほど素朴なやり方だった。
決定的だったのは、これらが、誰か一社の持ち物ではなかったことだ。仕様は公開され、誰のものでもなかった。だから、どの会社のブラウザも、どの言語も、許可を求めずに参加できた。1990 年代半ばには、ページを動かすための JavaScript が乗り、2000 年代になると、それを楽に作るための土台として Ruby on Rails のようなフレームワークも積み重なっていった。土台は、すべて、あの「ゆるく、軽く、公開する」の上にある。
だから今、あなたは、URL 一つで世界に届く。誰の許可も、いらない。
ここで、繰り返し現れる誤解を解いておきたい。新しい技術が出てくるたびに頭をもたげる、あの誘惑だ。「これからは、Web は全部、こう作るべきだ」――たとえば、ページを切り替えず、一枚の画面で全部こなす作り方を、唯一の正解のように掲げる。
だが、思い出してほしい。Web を強くしたのは、軽さと、ゆるさと、誰でも参加できることだった。何でもかんでも一つの重厚なやり方に寄せれば、その軽さを、自分から手放すことになる。それは、かつて重い標準が抱えた難しさを、別の形で呼び戻すことにもなりうる。
新しい技術を「唯一の正解」に祭り上げたくなったら、第7章を思い出すといい。それが閉じた問いなのか、開いた問いなのか。たいていは、開いている。そして開いた問いに唯一の正解を立てようとするのは、第1章で見た、銀の弾丸探しの、いちばん新しい姿だ。
では、Web は、どこまで重くなっていいのか。そこから先は、まだ誰も答えを出していない。
軽さで世界を覆ったはずの Web は、年々、重くなっている。豊かになった、とも言えるし、勝った理由を手放しつつある、とも言える。どこまでが進歩で、どこからが逆戻りなのか。この問いは、今まさに、開いたままだ。
ただ、これだけは、動かない。届ける力を、誰か一人の持ち主に、握らせない。
では、初めの問いに答えよう。なぜ、Web だけが、世界を覆ったのか。
完璧だったからではない。むしろ、逆だ。ゆるくて、軽くて、誰のものでもなかったから、誰もが参加できた。完璧で重い標準が広く届かなかった場所へ、不完全でも軽い Web は、するりと入り込んだ。
そうして、作る人は、ついに、届ける力まで手に入れた。どの会社の許可も、どの機械の都合も超えて、作ったものを、まっすぐ世界へ送り出せる。
Web とは、誰の許可もなく、作って届けられる自由だ。
ティム・バーナーズ＝リー（Tim Berners-Lee）やロイ・フィールディング（Roy T. Fielding）が形にしたのも、その公開性と軽さだった。HTML、HTTP、REST のような言葉を全部厳密に覚えなくても、「公開された単純な約束ごと」が広がりを作ったと掴めれば、まずは十分だ。綴りや違いを自分でも辿りたくなったら、用語集で HTML、HTTP、REST、CORBA を見比べてからこの章を読み返すと、対比がかなり見えやすくなる。
ここまで、九つの不自由と、九つの自由を見てきた。
複雑さに飲まれない自由。読まれる自由。変えられる自由。触れ続けられる自由。一人に縛られない自由。直し、見て、配る自由。選び続ける自由。価値観で道具を作り直す自由。許可なく届ける自由。
どれも、最初からあったものではない。誰かが不自由に気づき、本気で間違え、議論し、少しずつ勝ち取ってきたものだ。
その営みは、まだ終わっていない。そして今、その営みに、新しい書き手が加わろうとしている。コードを、人と同じように書く存在が。
最後に、一つだけ、問いが残る。
その話は、終章で。
参考文献
- Tim Berners-Lee, Weaving the Web
- Roy T. Fielding, Architectural Styles and the Design of Network-based Software Architectures
- Martin Kleppmann, Designing Data-Intensive Applications
終章 AI は「当たり前」を作れるのか
ここまで、九つの物語を見てきた。
形は、どれも同じだった。まず、困りごとがあった。誰かが、本気の答えを出した。その答えは、やがて失敗した。新しい考えが生まれ、人々が言い争い、少しずつ直された。そして、いつのまにか「当たり前」になった。終わったように見えて、その先には、また次の困りごとが待っていた。
問題、答え、失敗、議論、改善、文化。この六つが、百年のあいだ、何度も繰り返されてきた。プログラマーが「そう考える」ようになった理由は、結局、これだった。誰かが不自由に気づき、本気で間違え、それでも前へ進もうとし続けたからだ。
さて、ここで、新しい書き手が現れた。
コードを、人と同じように、いや、人より速く書く存在。AI だ。あなたが今、まさにこの本を手に取っているこの時代に、それは、プログラマーの隣に座っている。
では、問わなければならない。この営みを、AI は引き受けられるのか。
ここで、第7章の区別が物を言う。閉じた問いと、開いた問いだ。
閉じた問い――すでに決着がついて、なぜそうなのかを語れる問い。その答えなら、AI は見事に再現する。世界中の「当たり前」を学び、最も標準的なやり方を、瞬時に差し出す。シンプルに書くことも、テストを書くことも、良い名前をつけることも、AI はもう、たいていの新人より上手にこなす。
だが、この本で見てきたのは、閉じた問いの答えだけではなかった。
思い出してほしい。それぞれの章は、決着のついた答えで終わらなかった。最後は必ず、まだ開いている問いへと続いていた。
大きく作るか、小さく割るか。どこまで設計を先に決めるか。どこまでを機械に任せるか。どんな価値観の言語が良いか。Web は、どこまで重くなっていいのか。――どれも、誰もまだ答えを出していない。
そして、もっと大事なことがある。この本に出てきた「当たり前」は、最初はどれも、開いた問いだった。 複雑さとの戦い方も、テストの意味も、自由なソフトの価値も、生まれた当初は、答えのない問いだった。誰かが、まだ答えのない場所で、本気で間違え、議論し、文化に変えた。だから今、それは閉じた問いになっている。
AI が再現できるのは、その結果だ。誰かが命がけで開き、戦い、閉じてくれた、その後の答えだ。
では、まだ開いている問いを引き受けることは、どうだろう。答えのない場所で立ち止まり、選ぶ責任から逃げず、盛大に間違え、その失敗を恥ではなく次の文化に変えていくこと。自由を、勝ち取り、更新し続けること。 ――それは、AI にできるのか。それとも、それは最後まで、人の仕事として残るのか。
正直に言えば、この問いも、開いている。今、答えを断言できる人は、いない。
ただ、一つだけ、確かなことがある。
この本を読み終えたあなたは、もう、外から眺める人ではない。
プログラマーが「なぜそう考えるのか」を、あなたはもう知っている。それは、暗記すべきルールではなく、不自由と戦った人たちの、生きた選択の積み重ねだった。そして、その物語は、まだ閉じていない。次の不自由に気づき、次の「当たり前」を作る列に、あなたは、もう並んでいる。
AI は、コードを書く。おそらく、これからもっと上手に書く。
だが、自由は――まだ誰も答えを出していない問いを引き受け、選び続け、失敗を文化に変えていく、あの営みは――あなたと AI の、どちらが作るのだろうか。
その答えを書くのは、この本ではない。
これから、あなただ。
おわりに
本書がたどってきたのは、開発手法のカタログではない。プログラマーたちが「なぜ、そう考えるのか」という、その考え方の来歴だった。
個々のやり方は、道具や流行とともに移り変わる。だが、困りごとに正面から向き合い、失敗から学び、少しずつ「当たり前」を作り替えていく――その姿勢そのものは、どの時代の、どの技術にも通用する。本書から持ち帰ってほしいのは、まさにそれだ。
FjordBootCamp について
本書は、プログラミングスクール FjordBootCamp（フィヨルドブートキャンプ） の教材として作った。現役のエンジニアが運営する、オンラインのプログラミングスクールだ。本書そのものは、最初から FBC の受講生でなくても読めるものとして書いており、MIT ライセンスで公開している。
FjordBootCamp が大切にしているのは、答えの丸暗記ではない。分からないことにぶつかったとき、自分で調べ、考え、手を動かして、学び続けられること――その力だ。本書が問いつづけてきた「なぜ、そう考えるのか」という姿勢は、そのまま、この学び方に重なっている。もしこの本が FBC の外にいる誰かの学びにも役立つなら、それは公開した意味の一つになる。
技術は移り変わる。だが、自分の頭で考えつづける力は、古びない。その力を、ここで、あるいはこの先のどこかで、育てていってほしい。
公式サイト：https://bootcamp.fjord.jp/
付録 年表
本書は、本文では年号を前景化せず、「困りごと」で物語を進めてきました。出来事の正確な時期と人物を確かめたい読者のために、本文で触れた事柄を、ここに年表としてまとめます。
注記：本表は執筆時点の下書きであり、刊行前に一次資料で再確認します（各項目の精度確認は別途進行中）。年代は、その考え方や出来事が広く知られるようになった時期を目安に置いています。
1968年ごろ
ダイクストラの goto 論考
プログラムの流れを好き勝手に飛ばす書き方は、読み手を迷わせると強く批判された。構造化された書き方が広まる大きなきっかけになった。関連章は 第7章。
1969年
アポロ 11 号と 1202 アラーム
月着陸の最中に警告が出ても、ソフトは重要な仕事を優先して動き続けた。異常を前提にした設計の強さを示した。関連章は 第4章。
1970年代初頭
UNIX とパイプ
小さな道具をつないで大きな仕事をする、という発想が形になった。「一つのことをうまくやる」が広まった。関連章は 第1章。
1975年
『人月の神話』
ソフトウェア開発は、人を足せば単純に速くなる仕事ではないと整理された。大規模開発の難しさが言葉になった。関連章は 第1章。
1976年
コードインスペクションの形式化
コードを人に見せる営みが、個人の善意ではなく、手順を持つ実務の技法として整理された。関連章は 第5章。
1980年ごろ
ストールマンとプリンタの逸話
毎日使う道具の中身を読めず、直せず、配れないことへの怒りが、後の自由ソフトウェア運動の出発点になった。関連章は 第6章。
1982年
第五世代コンピュータプロジェクト開始
論理と高度な推論でソフトの難しさを飛び越えられるのではないか、という大きな期待に国家規模の資金が投じられた。関連章は 第1章。
1983年
GNU プロジェクト発表
誰でも使え、読み、直し、配れるソフトウェアを作るという旗が、はっきり言葉として掲げられた。関連章は 第6章。
1984年
クヌース「文芸的プログラミング」
コードを機械向けの命令列だけでなく、人に読まれる文章として捉える見方が、強い言葉で提示された。関連章は 第2章。
1985年
GNU 宣言／FSF 設立／SICP 初版
自由ソフトウェアの理念を支える組織ができ、同じ年に「プログラムは人が読むものだ」という感覚を育てる名著も登場した。関連章は 第6章 と 第2章。
1986年
「銀の弾丸はない」
ソフトウェアの本質的な複雑さは、魔法の道具ひとつで消せないと、はっきり言われた。関連章は 第1章。
1989年〜1991年
World Wide Web の考案
HTML、HTTP、ブラウザという単純な仕組みで、誰でも公開された文書をたどれる土台が作られた。関連章は 第9章。
1991年
Linux 公開／CORBA 1.0
一方では公開された OS カーネルが育ちはじめ、他方では重厚な分散標準が整えられた。軽さと重さの分かれ道が見えはじめる。関連章は 第6章 と 第9章。
1992年
「技術的負債」のたとえ
後で直せばいいと先送りした設計の粗さは、借金のように利子をつけて返ってくる、という見方が広まった。関連章は 第3章。
1995年
Ruby／JavaScript／WikiWikiWeb
言語の価値観、Web の動き、共同編集の文化が、同じ時期にそれぞれ別方向から立ち上がった。関連章は 第8章、第9章、第5章。
1996年
アリアン 5 打ち上げ失敗
前の機体で動いていたコードを再利用しても、文脈が変われば安全とは限らないことが、大きな事故として現れた。関連章は 第4章。
1997年
UML 標準化
図で設計を整理し共有するための共通記法が整えられた。設計を先に固めきろうとする時代の象徴にもなった。関連章は 第3章。
1998年
「オープンソース」という呼称
自由ソフトウェアの実利面を強調する呼び方が広まり、企業や実務の文脈で受け入れられやすくなった。関連章は 第6章。
1999年
『リファクタリング』／『XP』
コードを少しずつ整える技法と、変化を前提にした開発スタイルが、広く参照される形でまとまった。関連章は 第3章。
2000年
REST 論文
重い手続きより、Web の軽い約束ごとを生かしたやりとりの考え方が整理された。関連章は 第9章。
2001年
アジャイル宣言／Wikipedia
変化に対応する開発の価値観が短い宣言として示され、同じ年に「皆で直し続ける」百科事典も育ちはじめた。関連章は 第3章 と 第6章。
2004年
Ruby on Rails
Web アプリケーションを少ない手間で形にしやすい土台が整い、Web で作ることの敷居がさらに下がった。関連章は 第9章。
2005年
Git
離れた場所で行われる大量の変更を安全にまとめる道具が作られ、公開開発の規模が一段大きくなった。関連章は 第6章。
2008年
GitHub とプルリクエスト
コードを提案として見せ、議論してから取り込む流れが、誰でも使える日常の作法として広まった。関連章は 第5章。
年表に並べると、一直線の進歩に見えるかもしれません。けれど本文で見たとおり、実際は、各時代の人々が、それぞれの不自由の中で本気で間違え、議論し、少しずつ「当たり前」を作り直してきた積み重ねです。
付録 用語集
本文を読み進める途中で立ち止まりやすい言葉を、短くまとめる。厳密な定義を尽くすためではなく、読み直すときの足場にするための用語集である。
アジャイル
最初にすべてを決めきるより、短い単位で作って見せ、変化に対応しながら進める考え方の総称。計画を捨てるという意味ではなく、最初の計画だけで最後まで押し切れるとは考えない、という姿勢に近い。第3章で触れた XP（Extreme Programming）は、その代表的な実践の一つで、小さく作る、すぐ確かめる、変えやすく保つ、といった作法を強く押し出した。本文では「どうせ仕様は変わる」という前提を受け止める言葉として使っている。
オープンソース
ソースコードを公開し、読む・直す・配ることを可能にする考え方や、その形で公開されたソフトウェア。実務では、公開された開発のやり方や協業の仕組みまで含めて指すことも多い。第6章では「自由」の文脈で扱っているが、同じ章で出てくるフリーソフトウェアとまったく同じ言葉ではない。重なる部分は大きいが、フリーソフトウェアが使う人の自由を強く押し出すのに対し、オープンソースは開発の開かれ方や実務上の利点を前に出しやすい。
コメント
コードの外側に書く説明文。本文では、何をしているかの説明をコメントに頼りすぎると、コードと食い違いやすいと述べた。理由や背景を書くときに強い。たとえば「この変数は未払い請求書です」のように名前で書けることまでコメントに任せると、コードを直したときに置いていかれやすい。逆に「なぜこの回り道を選んだのか」「なぜ一見おかしな処理が必要なのか」のように、コードだけでは出てこない事情を書くなら役に立つ。第2章では、名前とコメントの役割を分けて考えるための足場として使っている。
CORBA（Common Object Request Broker Architecture）
異なるコンピュータやプログラム同士を共通のやり方でつなごうとした、重厚な分散システムの標準。Object Management Group（OMG）が標準化を進めた。第9章では、Web の軽さと対比するための例として使っている。
GNU（GNU's Not Unix）
リチャード・ストールマン（Richard Stallman）が始めた、誰でも使え、読み、直し、配れるソフトウェアを作ろうとするプロジェクト。名前は GNU's Not Unix の略で、Unix に似た自由なシステムを作ろうとしたことを示している。第6章では、ソフトウェアの「自由」を考える中心として出てくる。ここでいう自由は無料という意味ではなく、使う人が中身を読み、直し、配れることを指す。Linux だけを見ていると見えにくいが、その前から積み上がっていた思想と道具の流れを辿る入口が GNU である。
HTTP（Hypertext Transfer Protocol）
Web で文書やデータをやりとりするときの約束ごと。ティム・バーナーズ＝リー（Tim Berners-Lee）らが Web とともに形にしていった。ブラウザがサーバーに「これをください」と頼み、受け取るための基本の仕組みである。第9章で大事なのは、HTTP が高度な魔法ではなく、比較的単純な約束ごととして広まった点だ。複雑な共通基盤を先に整えなくても、「頼む」「返す」が共有できれば世界中で使えた。その軽さが、Web の広がりを支えた。
HTML（HyperText Markup Language）
Web ページの骨組みを表す書き方。ティム・バーナーズ＝リー（Tim Berners-Lee）が Web の文書のために考えた。見出し、段落、リンクなどを文書に印として埋め込む。第9章では、HTML が高機能だから勝ったというより、文書に最低限の意味づけを与える単純な形式だったから広がった、という点が重要になる。最初の Web は、豪華なアプリケーション基盤ではなく、まず文書を結びつける仕組みとして始まった。
JavaScript
Web ページに動きを与えるために広く使われるプログラミング言語。ブレンダン・アイク（Brendan Eich）が考案した。第9章では、Web の上に積み重なった要素の一つとして触れている。
KISS（Keep It Simple, Stupid）
できるだけ単純に保つべきだという考え方。第1章では、複雑さを増やしすぎないための注意として出てくる。何でも単純化すればよい、という意味ではなく、必要以上に込み入った作りにしない、という戒めに近い。将来に備えるつもりで過剰な仕組みを足しはじめると、かえって手を入れにくくなる。そのとき立ち戻る言葉が KISS である。
DRY（Don't Repeat Yourself）
同じ知識やロジックを無意味に重複させない、という考え方。第1章では、複雑さを増やしすぎないための注意として出てくる。ここでいう重複は、単に文字列が二回出てくることではなく、同じ知識を別々の場所で持ってしまうことに近い。片方だけ直してもう片方を忘れると、そこから不整合が生まれる。ただし、まだ意味の違いが見えていない段階で無理にまとめると、逆にほどけなくなる。DRY は万能の圧縮呪文ではない。
REST（Representational State Transfer）
Web の軽さを生かした、比較的単純なやりとりの設計スタイル。ロイ・フィールディング（Roy Fielding）が博士論文の中で整理した。第9章では、重い分散標準と対比される。難しく見えるが、この本で押さえたいのは「ものごとに住所を与え、その住所へ取りに行く」という素朴さである。巨大な共通基盤を前提にせず、公開された単純な約束ごとでつなぐ。その軽さが Web の広がりと相性がよかった。
Rails（Ruby on Rails）
Ruby on Rails の略。デイヴィッド・ハイネマイヤー・ハンソン（David Heinemeier Hansson）が作った、Ruby で Web アプリケーションを作りやすくするためのフレームワーク。第9章では、Web の上にあとから積み重なった土台の例として出てくる。HTML、HTTP、ブラウザのような公開された約束ごとが先にあったから、その上で Rails のような道具も育った。つまり Rails 自体が Web を作ったのではなく、開かれた Web の上で開発を速くする道具として広まった。
リファクタリング
外から見た動きを変えず、コードの内側の形だけを整えること。名前を直す、重複を減らす、絡んだ処理を分ける、といった手入れがこれにあたる。大事なのは、見た目や気分の問題ではなく、次の変更を安全に入れやすくするための整え直しだという点である。ゼロから作り直すこととは違い、動きは変えないまま少しずつ形を良くしていく。第3章では、変化に耐える設計を支える手入れとして扱っている。
レビュー
書いたコードを別の人に見てもらい、理解や改善点を分かち合うこと。第5章では、属人化をほどくための文化として扱った。目的は相手の粗をすべて暴くことではなく、一人の頭の中にしかない知識を外へ出すことにある。だから、言い方や場の作り方も大事になる。攻撃の場になると人は見せなくなり、見せなくなると知識はまた閉じこもる。プルリクエストは、この見せ合いを日常の手続きにした形の一つである。
YAGNI（You Aren't Gonna Need It）
まだ必要になっていない機能を、先回りして作り込まないという考え方。第1章では、複雑さを増やしすぎないための注意として出てくる。「将来あるかもしれない」を理由に仕組みを増やすと、その瞬間から抱えるものも増える。もちろん先の変更を考えなくてよい、という意味ではない。変更しやすい余白を残すことと、来るかどうかもわからない機能を実装しておくことは別である。YAGNI は、その線を見失わないための言葉だ。
付録 読書ガイド
本書は、プログラマーが「なぜそう考えるのか」をつかむための入口として書いた。ここから先は、ぜひ元になった本や論文そのものを読んでほしい。
全部を順番に読む必要はない。まずは、自分がいちばん引っかかった章から入るのがいい。そのうえで、「最初の一冊」と「次の一冊」を示す。
まず最初に読むなら
1. 『人月の神話』 フレデリック・P・ブルックス Jr.
複雑さ、見積もり、銀の弾丸探し。ソフトウェア開発がなぜ難しいのかを、流行語ではなく地に足のついた言葉で考えたいなら、まずここから入るのがよい。
向いている章:
2. 『リファクタリング』 マーティン・ファウラー
本書では思想や歴史の流れを中心に書いたが、実際にコードをどう整えるのかへ降りていくなら、この本が橋になる。読みやすさ、変更しやすさ、設計の手入れが、同じ実践の中に並んでいるとわかる。
向いている章:
3. 『XP エクストリーム・プログラミング』 ケント・ベック
変化を前提に作るとはどういうことかを、単なる精神論でなく実践の束として読むのに向いている。本書の第3章と第4章を、実際の開発の作法として読み直しやすくしてくれる。
向いている章:
4. Free Software, Free Society リチャード・ストールマン
第6章を読んで「自由」の意味をもう少し正面から受け止めたくなったら、やはり原典に近いところへ行くべきだと思う。賛成するにせよ距離を取るにせよ、一度は自分で読んでおく価値がある。
向いている章:
5. Weaving the Web ティム・バーナーズ＝リー
Web が単なる技術の積み重ねではなく、どういう思想で作られたのかを知るにはよい入口になる。第9章の「誰のものでもない」という感覚に、作った本人の言葉で触れられる。
向いている章:
テーマ別に読むなら
複雑さと設計
読みやすいコード
- Structure and Interpretation of Computer Programs
- Donald E. Knuth, "Literate Programming"
- 『リファクタリング』
テストと変更
オープンソースと自由
言語と道具の思想
Web と公開性
読み方の勧め
- 一冊を全部理解してから次へ進まなくていい
- 難しい本ほど、まず目次と序文と結論だけ読むやり方でいい
- 本書の対応する章を読み返しながら往復すると、名著の言葉が急に自分の問題として読める
名著は、要約で知った気になるより、どこかで一度、原文や原典に当たるほうがいい。本書が、そのための助走になれば十分だと思っている。