はじめに ──「常識」は、最初から常識ではなかった

シンプルに書こう。テストを書こう。コメントより、まず名前を考えよう。コードは、人に見せよう。

プログラミングを学びはじめると、こうした言葉に、次々と出会う。先輩が言う。本に書いてある。研修で教わる。どれも、もっともらしい。そういうものか、と受け入れて、あなたは従う。

だが、ふと思う。これは、誰が決めたのだろう。

どこかの偉い人が、ある日「こう書きなさい」と定めたわけではない。これらの「当たり前」は、最初から当たり前だったわけではないのだ。誰かが困り、答えを出し、その答えで盛大に失敗し、言い争い、少しずつ直してきた。その長い積み重ねの果てに、いつのまにか「当たり前」になった。常識は、生まれたときから常識だったのではなく、常識になったのだ。

図 0-2　どの物語も、六つの拍子で回る。

──

この本は、その「当たり前」が、どうやって当たり前になったのかを語る。

ただし、「正しい開発手法のカタログ」としては書かない。「こう書くのが正解です」と並べる本は、すでにたくさんある。この本が描くのは、もっと手前の話だ。プログラマーたちが、何に困り、何と戦い、何を手に入れてきたのか。その物語のほうだ。

そして、この物語には、一本の背骨がある。不自由と、自由だ。

プログラマーは、ずっと、いくつもの不自由に縛られてきた。たとえば――複雑さに飲み込まれる。半年後の自分にすら、コードが読めない。仕様が変われば、動けなくなる。一人が抜ければ、誰も触れない。道具の中身を、勝手に直せない。こうした不自由は、まだまだある。そして本書で語る「当たり前」は、どれも、その一つひとつに対して、プログラマーたちが勝ち取ってきた、別々の自由なのだ。

だから本書は、九つの不自由をめぐる、九つの物語でできている。それぞれの章で、一つの不自由が立ちはだかり、最初の答えが試され、手痛く失敗し、新しい考えが生まれ、やがて「当たり前」になる。そして、まだ終わっていない問いが、次の章へと続いていく。

図 0-1　九つの不自由と、九つの自由。本書の地図。

──

読み終えたとき、あなたに残ってほしいのは、知識ではない。

「なるほど、そういう理由でそう考えるのか」と、外から納得して終わってほしくない。そうではなく、こう感じてほしい。自分もこれから、そう考える側になっていくのかもしれない、と。

なぜなら、この物語は、まだ続いているからだ。当たり前は、今も作られ続けている。そしてその作り手の列に、これからあなたも加わる。

これは、技術の解説書ではない。プログラマーという人たちが、何を大事にし、なぜそう考えるようになったのかを語る、ソフトウェア文化への入門書だ。

この本は、プログラミングスクール FjordBootCamp（フィヨルドブートキャンプ）の教材として作った。これからプログラマーになる人、なったばかりの人に向けて書いている。覚えてほしいのは、個々のやり方ではない。「なぜ、そう考えるのか」をたどる、その考え方のほうだ。

では、最初の不自由から始めよう。それは、ある日あなたが「便利な機能を足しましょう」と言ったときに、先輩が見せた、あの渋い顔の話だ。

第1部 複雑さと読めなさに抗う

プログラマーが最初に向き合う不自由は、自分の作ったものに振り回されることだ。機能が絡み合って、誰も全体を見渡せなくなる。やっと分けたその部品も、半年後には自分ですら読めなくなる。

第1部では、この二つの不自由――複雑さと、読めなさ――を続けて扱う。第1章は、機能を足すたびに膨らむ複雑さと、それを「倒す」のではなく「小さく分けて手なずける」までの道のりを追う。第2章は、分けた一つひとつを「読める」ものにするための、名前という道具を扱う。

この二つは、地続きだ。複雑さを分けても、分けた先が読めなければ、結局また手が出せない。だから第1章の終わりは、そのまま第2章の入り口になる。

第1章 機能を増やそうと言ったら、止められた

「便利だから、この機能も入れましょう」

あなたは、よかれと思って言った。ユーザーが喜ぶ。手間も省ける。足して困ることなんて、あるだろうか。

なのに、先輩は浮かない顔をする。

「……うーん。それ、本当に要りますか」

要るに決まっている。便利なのだから。なぜ、足すことを、こんなに渋るのか。

この渋い顔の裏には、百年ぶんの経験が畳み込まれている。そして、その経験が教えるのは、たいてい同じことだ。

足すのは一瞬。抱えるのは、一生。

──

ソフトウェアには、不思議な性質がある。

機能を一つ足すたび、増えるのは「一つ」では済まない。新しい機能は、すでにある機能と手をつなぐ。組み合わせが、かけ算で膨れていく。十の機能が二十になると、気を配るべき関係は、その倍では済まない数になる。

図 1-1　足すのは一つ。増える関係は、一つでは済まない。

やがて、誰も全体を見渡せなくなる。ここを直すと、あそこが壊れる。なぜ壊れたのか、誰にもわからない。作ったはずの自分たちが、自分たちの作ったものに振り回されはじめる。

これが、プログラマーをずっと苦しめてきた、最初の不自由だ。複雑さに、飲み込まれる。

──

最初に人類が選んだ答えは、勇ましかった。複雑さに、力で勝とうとしたのだ。

もっと賢い言語を。もっと万能な設計図を。複雑さを一撃で消し去る、特別な道具がきっとあるはずだ――その夢に、時代の最良の頭脳がつぎ込まれた。

日本も、国を挙げてその夢を見た。第五世代コンピュータ。論理を突き詰めれば、機械は人のように考えはじめる。膨大な予算と、当時の一流が集まった。本気だった。誰も、笑ってなどいなかった。

だが、特別な道具は、来なかった。

その壮大な目標は、思い描いた形では実らない。そして同じころ、フレデリック・ブルックス――巨大なソフトウェア開発の難しさを、誰より知る技術者だ――が、静かに、しかし決定的なことを書く。

銀の弾丸は、ない。

彼が言ったのは、こういうことだ。ソフトの複雑さには二種類ある。たまたま今の道具が未熟なせいで生じる複雑さと、解こうとしている問題そのものが、本質的に抱えている複雑さ。前者は、よい道具で減らせる。だが後者は、どんな魔法の道具を持ってきても、消えない。複雑さは、退治すべき敵ではなく、問題の一部なのだ。

図 1-2　複雑さは二種類ある。外側は道具で減らせるが、内側の本質は消えない。

力で勝とうとした時代は、こうして静かに終わる。

──

勝てないなら、どうするか。

ベル研究所の片隅で、まったく別の答えが育っていた。複雑さを倒すのをあきらめて、小さく分ける。

ダグ・マキルロイ――UNIX という土壌を耕した一人だ――は、こう考えた。一つのことだけを、うまくやるプログラムを書く。そして、それらを組み合わせて使う。大きな一つではなく、小さな多数を。

それを象徴するのが、パイプという仕組みだ。小さな道具の出口を、次の道具の入口へ、縦棒一本でつなぐ。一つ一つは単純なのに、つなぐと複雑な仕事をやってのける。複雑さを、一個の頭で抱え込むのではなく、小さな部品に分けて預けてしまう。

図 1-3　一つのことだけをやる道具を、縦棒一本でつなぐ。小さな部品の連結が、大きな仕事になる。

この「分けて手なずける」という発想は、その後、いろいろな現場から少しずつ言葉を与えられていった。出どころは、ばらばらだ。航空機の整備の現場からは、単純に保て（KISS）。経験を積んだ職人たちからは、同じことを二度書くな（DRY）。変化の速い開発の現場からは、いま要らないものは作るな（YAGNI）。

誰か一人の英雄が、上から決めたのではない。別々の場所で、別々の人が、同じ壁にぶつかり、似た知恵を持ち帰った。それらが寄り集まって、いつのまにか「当たり前」になった。

──

だから今、ベテランは、機能を足す前に一度、立ち止まる。

足すこと自体が悪いのではない。足したぶんだけ、全体が見渡せなくなる――その代償が見えているから、あの渋い顔になるのだ。

ただし、ここでよくある誤解を、ひとつ解いておきたい。

「いま要らないものは作るな」は、「先のことを一切考えるな」ではない。将来の変更に備えて余白を残すことと、来るかどうかもわからない機能を先回りで作り込むことは、まったく別だ。「同じことを二度書くな」も、「何でも一つにまとめろ」ではない。たまたま今だけ形が似ているコードを無理にひとつにすると、後でかえって、ほどけなくなる。

面白いのは、これらの誤解そのものが、小さな「銀の弾丸探し」だということだ。一つの原則を万能の魔法だと思い込んだ瞬間、人はまた、複雑さに足をすくわれる。

──

そして、この戦いは、今も終わっていない。

「大きな一つより、小さな多数を」。この教えを推し進めると、ひとつのアプリを、たくさんの小さなサービスに割っていく考え方になる。分ければ分けるほど身軽になる――はずだった。だが、分けすぎると、今度は部品と部品のあいだが複雑になる。複雑さは、結局どこかで、姿を変えて戻ってくる。

大きく作るか、小さく割るか。これは、まだ誰も最終的な答えを出していない、開いたままの問いだ。

──

それでも、百年かけてプログラマーが学んだことが、ひとつだけある。

複雑さは、力で消すものではない。小さく分けて、手なずけるものだ。なぜ、わざわざそうするのか。明日も、半年後も、このソフトに手を入れ続けられるように、だ。

シンプルさとは、複雑さに飲まれず、手を入れ続けられる――という自由だ。

ただし、複雑さを分けただけでは、まだ足りない。

分けたその一つ一つが、読めなければ。半年後のあなたが、それを開いて「これは、何だ」とつぶやくなら、結局あなたは、また手を出せなくなる。

複雑さの次に立ちはだかるのは、読めなさという、もうひとつの不自由だ。

その話は、次の章で。

第2章 コードは、誰のために書くのか

レビューが返ってきた。

ロジックは、どこも直されていない。動きは、何も変わっていない。直されたのは、ただ一つ――変数の名前だけだった。

tmp が、unpaidInvoices に変わっている。

それだけ。たったそれだけのことに、先輩はわざわざ一言を添えている。「動くんですけど、これだと半年後に読めないので」。

動く。なのに、読めない。その二つは、両立するのか。

──

ソフトウェアには、見落とされがちな事実がある。コードは、書かれる回数より、読まれる回数のほうがずっと多い。

図 2-1　書くのは一度。読まれるのは、そのあと何度も、ずっと。

一度書いたコードを、人はそのあと何度も読み返す。直すために読む。機能を足すために読む。なぜ壊れたのかを探すために読む。書くのは一瞬でも、読むのは、そのソフトが生きているあいだ、ずっと続く。

そして、その読み手は、たいてい未来の自分だ。半年もすれば、なぜそう書いたのか、きれいさっぱり忘れている。半年後の自分は、他人だ。 その他人が、何も思い出せないまま、あなたの書いた数行の前に立つ。

ここで、前の章の続きに気づく。複雑さを、小さく分けた。だが、分けた一つ一つが読めなければ、結局あなたは、また手を出せなくなる。分けることと、読めること。その二つがそろって、はじめて手を入れ続けられる。

読めなさ。これが、プログラマーを縛ってきた、もうひとつの不自由だ。

──

最初の答えは、親切だった。読みにくいなら、説明すればいい。コメントを書こう。

コードの脇に、人間の言葉で注釈を添える。この行は何をしているか。この変数は何を表すか。一行ごとに、ていねいに語る。かつて、読みやすさとは「コメントの量」のことだと、半ば本気で信じられた時代があった。手厚いほど親切だ、と。

──

だが、コメントには、ひとつ弱点がある。機械は、コメントを読まない。

機械が動かすのは、コードのほうだ。コメントは、ただの添え物として、素通りされる。だから、コードを直してもコメントはそのまま取り残される。書いた本人は、注釈まで直す義務を、機械から課されていない。

こうして、コメントは少しずつ、コードと食い違っていく。やがて、コードは右へ行けと言っているのに、コメントは左を指している、という事態が起きる。

間違ったコメントは、ない方がましだ。なにしろ、自信たっぷりに、間違った道を教えてくるのだから。手厚く書けば書くほど、腐ったときの嘘は増えていく。親切のつもりが、いちばん質の悪い罠になる。

──

ならば、どうするか。注釈で外から補うのをやめて、コード自体を、読めるものにする。

ドナルド・クヌース――組版から教科書まで手がけた、計算機科学の巨人だ――は、こう言い換えてみせた。プログラムを書く仕事を、「機械に命令する作業」だと思うのはやめよう。「人間に、何をさせたいかを説明する作業」だと考え直そう、と。

同じころ、ある教科書の冒頭に、のちのち何度も引かれる一文が置かれる。プログラムは、人間が読むために書かれる。機械が実行するのは、ついでにすぎない。

そして、マーティン・ファウラー――変更に強いコードの作法を、現場の言葉で広めた一人だ――は、もっと端的に言った。機械にわかるコードなら、誰でも書ける。人間にわかるコードを書けるのが、よいプログラマーだ。

ここで、梃子になるのが「名前」だ。

なぜ、コメントではなく名前なのか。理由ははっきりしている。名前は、コメントと違って、コードの一部だからだ。機械が実際に使う。だから、嘘をつけない。名前を変えれば、その名を呼んでいる場所すべてが、いやおうなく変わる。放っておいても、コードと食い違いようがない。コメントは添え物だから腐る。名前は本体だから、腐れない。

図 2-3　コメントは添え物だから、いつか食い違う。名前は本体だから、食い違いようがない。

──

ここで、少し手を動かしてみてほしい。

三十日ログインのないユーザーを集めて返すだけの、数行の処理がある。これに、名前をつける。三通り、並べてみる。

• f ……何も言っていない。中を全部読むまで、何をするのかわからない。
• getUsers ……「ユーザーを取ってくる」ことはわかる。だが、どのユーザーかは言っていない。結局、中を読むことになる。
• findDormantUsers（休眠ユーザーを探す）……中を開く前に、答えを返している。「ああ、しばらく使っていない人を探すのか」と。

半年後のあなたが、まっさらな頭で、このどれかと出会う。どれと出会いたいだろうか。

図 2-2　名前が語るほど、中を開かずに済む。

三番目の名前は、本来ならコメントが引き受けるはずだった説明を、自分で済ませている。しかも、コメントと違って腐らない。処理の中身が変われば、名前も直さざるをえないからだ。名前は、最も短く、最も嘘をつかないコメントだと言ってもいい。

──

だから今は、読みにくいと感じたとき、コメントを足す前に、まず名前を疑う。

ここで、よくある誤解を解いておきたい。「コメントを書けば、読みやすくなる」――これは、半分しか正しくない。

読みにくいコードにコメントを貼るのは、傷に絆創膏を重ねるようなものだ。tmp に「これは未払いの請求書です」と注釈するくらいなら、はじめから unpaidInvoices と名づければいい。コメントが要るのは、名前では言えないことを残すときだけだ。「なぜ」この一見おかしいやり方を選んだのか。なぜ、あえて遠回りをしたのか。その理由は、コードを見ても出てこないから、書き添える価値がある。

つまり、「何を」しているかは、名前とコードが語る。「なぜ」そうしたかは、コメントが語る。この線引きを取り違えて、「何を」までコメントで説明しはじめた瞬間、腐るコメントの山が育ちはじめる。

──

では、よい名前とは何か。そこから先は、まだ誰も決着をつけていない。

camelCase か snake_case か。英語で書くか、業務で使う言葉で書くか。短く済ませるか、長くても明確を取るか。チームごと、言語ごとに、今も議論は続いている。

ただ、一つだけ、疑いようがない。名前は、機械のためではなく、次に読む人間のためにつける。

──

そろそろ、最初の問いに答えられる。コードは、誰のために書くのか。

機械は、どんな名前でも動かす。tmp でも a1 でも、文句ひとつ言わない。名前に意味を求めるのは、ただ一人――いつかこのコードを開く、人間だけだ。

その人は、半年後のあなたかもしれないし、まだ会ったことのない誰かかもしれない。名前をつけるとき、あなたは、その人に向かって書いている。

名前をつけるとは、まだ見ぬ読み手に、理解する自由を贈ることだ。

──

読めるコードができた。あなたは、半年後も、その中身をたどれる。

だが、半年のあいだに変わるのは、あなたの記憶だけではない。

「やっぱり、こうしたい」と、お客さんが言う。きれいに名づけ、きれいに分けたはずのコードに、最初は思ってもみなかった要求が、ぶつかってくる。

どうせ、仕様は変わる。その前提に、どう備えるのか。

その話は、次の章で。

第2部 変化との戦い

きれいに分け、読めるように名づけた。それでも、ソフトウェアには逃げられない現実がある。後から、変わるのだ。仕様が変わり、要求が変わり、前提が変わる。

第2部では、その「変わること」を、敵ではなく前提として引き受ける考え方を扱う。第3章は、最初にすべてを決めきろうとする設計が、変化の前であっけなく崩れるさまと、「決めすぎない」という発想の転換を追う。第4章は、いざ変えるたびに「どこかを壊していないか」という恐怖を、テストという仕組みでどう手なずけたかを扱う。

設計を緩めて変えられるようにすることと、変えても壊れていないと保証することは、表と裏だ。だから第3章の終わりは、第4章の備えへと続く。

第3章 どうせ仕様は変わる

仕様が、変わった。

先週、「これでいきましょう」と決めたはずだった。なのに、お客さんは悪びれずに言う。「やっぱり、こうしたいんです」。

あなたは、青ざめる。あの設計は、この要求を、まったく想定していない。きれいに組んだはずの段取りが、根元から合わなくなる。一から作り直しか――。

ところが、先輩は慌てない。お茶を一口飲んで、こう言うだけだ。

「まあ、変わりますよね。仕様って」

なぜ、こんなに落ち着いていられるのか。変わって困らない作り方を、この人は知っているらしい。

──

ソフトウェアづくりには、逃げられない現実がある。作りはじめる前に、すべてを正しく決めることは、できない。

人は、使えるものを目の前にして、はじめて「本当に欲しかったもの」に気づく。だから、動くものを見せたとたん、要求は動く。市場も、法律も、競合も動く。決めた前提は、決めたそばから古くなっていく。

これが、プログラマーを縛ってきた、次の不自由だ。最初に固めると、あとで動けない。

──

最初の答えは、いっそ潔かった。変わるのが困るなら、変わる前に、すべてを決めきってしまえばいい。

まず、完璧な設計図を描く。あらゆる場合を先回りして、隅々まで紙の上で固める。図さえ完成すれば、あとはそのとおりに組み立てるだけ――そう考えた。

この夢は、本気で追いかけられた。図を描けば、そこからプログラムが自動で生み出される。そんな道具に、巨額が投じられた。設計を図として記述する記法も整えられ、「この図を描ききれば、設計は終わる」と信じられた。手を動かして作るより、上流で考えきるほうが偉い、という空気さえあった。

──

だが、現実は、その夢をやすやすと裏切った。

完璧なはずの図は、最初の仕様変更ひとつで、ただの古い絵になった。図とコードは、別々に育っていく。直すのはいつもコードのほうで、図は放置され、やがて誰も信じなくなる。図から自動で完璧なコードが湧く、という道具も、約束したものを届けられなかった。

わかったのは、こういうことだ。図は、設計そのものではない。 それは、人と人が設計を話し合うための、会話の道具にすぎない。会話の道具を、未来を固定する契約書だと取り違えたところに、無理があった。

決めきろうとすればするほど、変化が来たときの痛手は大きくなる。固めた量だけ、動けなくなるのだ。

図 3-1　決めなさすぎても、決めすぎても、変化は痛い。

──

ここで、発想をまるごとひっくり返した人がいる。ケント・ベック。

彼が言ったのは、こうだ。変化は、避けるべき事故ではない。最初から、そこにある前提だ。 ならば、変化が来ないことに賭けるのをやめよう。来たときに、安く変えられるように作ろう。彼はそれを、強い言葉で掲げた。変化を、抱きしめろ。

考え方が逆なのだ。これまでは、変えずに済むように、最初にすべてを固めた。ベックは、いつでも変えられるように、あえて固めすぎない、と言う。

この発想は、彼ひとりのものではなかった。ウォード・カニンガム――まだ手を入れやすいうちに直さず放置したコードを、利子のつく「借金」にたとえた人だ――は、設計の先送りには代償が積み上がると説いた。マーティン・ファウラーは、その手入れの作法を整理した。動いているコードの、外から見た動きはそのままに、内側の形だけを整える。この小さく安全な手直しを、彼らは一つの技術として確立した。

やがて、同じ考えを持った人たちが集まり、短い宣言を書き残す。計画に従うことよりも、変化に対応することを。 一人の英雄が決めたのではない。変化に何度も殴られた者たちが、別々の現場で同じ結論にたどり着き、それを言葉にしたのだ。

──

だから今、慣れたプログラマーは、仕様が変わっても青ざめない。最初から、変わる前提で作っているからだ。

一つ、混同されやすいことがある。いま言った「内側の形を整える」手直し――リファクタリングは、「作り直し」ではない。

作り直しは、いったん壊して、ゼロから組み直すことだ。動きが変わるかもしれないし、新しいバグも生まれる。大きな賭けになる。リファクタリングは、その正反対だ。動きは、一ミリも変えない。 名前を直し、絡んだ部分をほどき、形だけをきれいにする。外から見れば、何も変わっていない。だが内側は、次の変更を受け入れやすくなっている。

図 3-2　リファクタリングは外の動きを変えず、内側だけ整える。作り直しとは、そこが違う。

この二つを混同して、「リファクタリングします」と言いながらゼロから作り直しはじめると、たいてい火を噴く。動きを変えない、という一点こそが、この手入れを安全にしている。

──

では、設計は、どこまで先に決めておくべきなのか。そこから先は、まだ誰も決着をつけていない。

何も決めずに走りだせば、行き当たりばったりで迷子になる。決めすぎれば、変化で動けなくなる。前もって設計する量を、どこに置くか。その目盛りは、チームごと、プロジェクトごとに、今も探り続けられている。

ただ、向きだけは、もう定まっている。すべてを先に決めることは、できない。そして、決めきれないことは、弱さではない。

──

あの、お茶を飲む先輩に戻ろう。なぜ、仕様が変わっても動じないのか。

変わらないように身構えるのをやめて、変わってもいいように作っているからだ。決めるべきことは決め、決めきれないことは、決めきれないまま、手を入れられる形で残しておく。

設計とは、最初にすべてを決めなくていい――という自由だ。

──

変わってもいいように作る。言うのは簡単だ。

だが、いざコードの内側を直すたび、心配になる。この手入れで、どこか遠くを、静かに壊してはいないか。動きは変えていないつもりだ。けれど、「つもり」を、誰が保証してくれるのか。

完成したはずのコードに、それでも手を入れ続けるための、もう一つの備えがいる。

その話は、次の章で。

第4章 完成したはずなのに、まだテストを書く

あなたが書いたコードは、動いている。

レビューに出す。返ってきたのは、こんな言葉だ。

「ここは、触らないほうがいいですね」

意味が、最初はわからない。動いているのに。直したい場所が、目の前にあるのに。なぜ、触ってはいけないのか。

実はこの章には、ひとりの主人公がいる。人ではない。**「動いているのに、誰も触れないコード」**だ。これから話すことは全部、その一点の恐怖をめぐっている。

──

プログラマーは、ずっとこの恐怖と暮らしてきた。

かつて、ソフトウェアをリリースするということは、半分、祈ることだった。手元では動いた。だから出す。あとは、壊れていませんように、と願う。実際、よく壊れた。しかも厄介なのは、直した場所ではなく、まったく関係のない遠くが壊れることだった。一行直すと、半年前に書いた別の機能が、静かに死ぬ。誰も全体を確かめられない。

ある時期、技術者たちは、ある言葉を口にしはじめる。ソフトウェア危機。 ハードウェアは年々速く、安くなっていくのに、それを動かすソフトだけが、大きくなるほど手に負えなくなっていく。作れるはずのものが、作れない。直せるはずのものが、直せない。業界全体が、「自分たちはソフトの作り方をまだ知らない」と認めた瞬間だった。

恐怖が現実になった例には、事欠かない。

あるロケットは、前の機体で何年も正しく動いていたプログラムを、ほぼそのまま新しい機体に積んだ。古い機体では決して起こらなかった計算上のあふれが、より速く飛ぶ新しい機体では起きた。誰も、そこを確かめていなかった。例外は誰にも受け止められず、装置は自ら停止し、機体は打ち上げから一分足らずで、自分を破壊した。

動いていたコードは、文脈が変わった瞬間に牙をむく。 これが、恐怖の正体だ。

──

最初の答えは、素朴だった。人間が、頑張って確かめる。

リリースの前に、手で一通り動かす。専門の担当者を立てて、画面を端から端まで叩いてもらう。徹夜の総点検。問題があれば、見つかる。たぶん。

けれど、これは規模に負ける。機能が二つなら、組み合わせは数えられる。十、二十と増えていけば、確かめるべき道筋は、人間の手に負えない数に膨れ上がる。どれだけ丁寧に総点検しても、確かめきれない一点が必ず残る。

そして恐怖は、こうして悪化する。怖いから、触らない。触らないから、古びる。古びるから、もっと怖くなる。

図 4-2　怖いから触らない。触らないから古びる。古びるから、もっと怖くなる。恐怖は一周するたびに濃くなる。

──

ここで、その答えを先取りしていた人たちがいる。

月へ向かう着陸船の中。降下の最中、画面に数字が灯った。1202。 機械が、抱えきれない量の仕事を一度に背負わされた、という悲鳴だった。普通なら、固まる。だが、そのソフトは固まらなかった。優先度の低い仕事を自分から投げ捨て、着陸という一点だけを、生かし続けた。

設計したのは、マーガレット・ハミルトンたちのチームだ。ハミルトンは、ソフトウェアを書く仕事を、まだ誰もそう呼ばなかった時代に「工学」と呼んだ人である。彼らは、起こりうる最悪を先に数え上げ、「そのとき機械がどう自分を守るか」まで作り込んでいた。だから 1202 は、故障ではなかった。設計どおりに、自分を守っているという報告だったのだ。

その数字は、月面着陸を止めなかった。

そして半世紀後。別の数字が、あなたの画面に、毎日のように灯る。

FAIL。

よく似ている。どちらも、機械が「ここが危ない」と先に教えてくれている。違うのは、1202 が一度きりの本番だったのに対し、FAIL のほうは、あなたが安心して何度でもやり直すために、自分で、わざと鳴らしているということだ。

図 4-1　同じ警告。違うのは、鳴らす回数だ。

──

信頼は、祈りではなく、設計できる。

ハミルトンたちが月の上で示したことを、地上のありふれた開発に持ち込んだ人たちがいる。

ケント・ベック。エクストリーム・プログラミングを提唱した一人である。彼は、書いたコードのとなりに「これはこう動くはずだ」という小さな検査を一緒に置いておく、という作法を広めた。変更するたび、機械がその検査を全部やり直す。壊れたら、その場で、赤く知らせる。

ここが、この章のいちばん大事なところだ。

自動テストの本当の値打ちは、品質を保証することではない。

よくある誤解を、ひとつ解いておきたい。テストは、「バグがないことの証明」ではない。エドガー・ダイクストラ――構造化プログラミングを唱えた計算機科学者の一人だ――は、こう指摘した。テストはバグがあることは示せても、バグがないことは、決して示せない。どれだけ検査を足しても、「これでもう完璧です」とは言えない。カバレッジが 100 パーセントでも、それは安全の証明書ではない。

では、テストは、何を守っているのか。

最初の恐怖に戻れば、わかる。「動いているのに、誰も触れない」。テストは、その呪いを解く。検査がすべて緑なら、あなたは安心してコードに手を入れられる。何か壊せば、機械がすぐ、赤く教えてくれるからだ。

図 4-3　変更のたびに検査が走る。通れば安心して手を入れられ、壊せばその場で気づける。

テストを書くという方向そのものは、もう決着がついている。いまさら、手作業の総点検だけに戻ろうという人はいない。まだ開いているのは、その先だ。先に書くか、後に書くか。どこまで書けば十分か。そこには、いまも本物のトレードオフが残っている。

けれど、入口の問いには、もう答えられる。

完成しているのに、なぜ、まだテストを書くのか。

テストが守っているのは、品質ではない。

テストとは、明日も、来年も、このコードに触れ続けられる――という自由だ。

──

明日も触れる自由を、あなたは手に入れた。

だが、コードはもう、一人で抱えるには大きすぎる。その自由を、大勢で、どう信頼し合うのか。

その話は、次の章で。

第3部 一人では作れない

ここまでの不自由は、コードと自分のあいだの戦いだった。第3部から、相手が変わる。ソフトウェアは、もう一人で抱えるには大きすぎる。

第3部では、知識を一人の頭に閉じ込めないための工夫を扱う。第5章は、なぜ動いているコードをわざわざ他人に見せるのか――属人化という不自由と、見せ合いを文化にしたレビューの話だ。第6章は、その「見せ合い」を会社やチームの壁を越えて世界中へ広げたとき何が起きたか――オープンソースを扱う。

第6章は、この本の心臓にあたる。ここでだけは、歴史の当事者自身が、文字どおり「自由」を旗印に掲げた。チームの共有から世界の共有へ。第5章の終わりは、その飛躍の入り口になる。

第5章 なぜ、他人にコードを見せるのか

「これ、レビューに出しておいてください」

そう言われて、あなたは少しためらう。コードは、もう動いている。テストも通っている。なのに、なぜ、わざわざ他人の目にさらすのか。

見せれば、粗が見つかる。「ここ、おかしくないですか」と言われる。せっかく書いたものに、赤い印が並んで返ってくる。動いているのに、わざわざ恥をかきにいくようなものではないか。

見せたくない。その気持ちの裏に、ひとつの落とし穴が隠れている。

──

ソフトウェアは、一人で抱えられるうちは、気楽だ。全部、自分の頭の中にある。どこに何があるか、なぜそう書いたか、聞かなくてもわかる。

だが、その「自分だけがわかる」状態には、値札がついている。

考えてみてほしい。決済まわりのコードを、たった一人が握っている。仕様も、癖も、落とし穴も、すべてその人の頭の中だけにある。チームは、何かあるたび「あの人に聞けばいい」で回している。

ある日、その人がいなくなる。転職でも、長い休みでも、理由は何でもいい。残されるのは、誰も中身を知らない、触れないコードの山だ。

図 5-1　一人に閉じた知識は、その人が抜けると誰も触れない。

これが、プログラマーを縛ってきた、次の不自由だ。一人が消えたら、誰も触れない。 しかも縛られているのは、残された側だけではない。握っている当人も、抜けられない。休めない。倒れられない。「あの人に聞けばいい」は、あの人を、逃げ場のない場所に閉じ込める呪いでもある。

──

最初の答えは、むしろ逆を向いていた。詳しい一人がいれば回るなら、その一人に頼ればいい。

エースに任せる。いちばん詳しい人間が、いちばん難しいところを抱える。チームは、その人を中心に組み立てられる。属人化は、避けるべき欠陥ではなく、頼れる強みだと思われていた。「あの人がいるから大丈夫」――それは、ほめ言葉ですらあった。

──

だが、その作り方は、たった一つの出来事で崩れる。その一人が、いなくなったとき。

引き継ぎ書を残していても、足りない。文書は、コードの「何を」は書けても、「なぜ」までは書ききれない。書いた本人にとって当たり前すぎたことは、そもそも書かれない。残るのは、動いてはいるが、誰も理由を説明できないコードだ。

「あの人に聞けばいい」は、あの人がいるあいだしか成り立たない。たった一人に知識を預けることは、その人を質に取られているのと変わらない。強みに見えていたものが、いちばんもろい一点だったと、いなくなってはじめて気づく。

──

ならば、どうするか。知識を、一人の頭に閉じ込めない。書いている最中から、見せ合う。

書きながら、二人で一つの画面に向かう。一人が書き、もう一人がその場で読む。書き上がったコードを、別の誰かの目に通してから取り込む。やり方はいろいろあるが、狙いは一つだ。一人の頭の中にしかない知識を、外に出して、複数の人が触れる状態にする。

この「見せ合い」を、一部の現場の作法から、世界中の当たり前へ押し広げた仕組みがある。プルリクエストだ。

自分の変更を、いきなり本体に入れるのではなく、いったん「こう変えたいのですが、どうでしょう」と提案の形で差し出す。誰でもそれを読み、その場で意見を書き込み、納得してから取り込む。この一連の流れを、誰もが使える普通の手続きにした。見せ合うことは、特別な儀式ではなくなった。

図 5-2　変更を、いきなり本体に入れない。提案として差し出し、読んで、納得してから取り込む。コードを書いたら、人に見せる。それが、日常になった。

──

ここで、少し考えてみてほしい。同じ一つの指摘を、二通りの言い方で書く。

• 「ここ、間違ってます。直してください。」
• 「ここ、こうするとどうでしょう？　もし意図があれば教えてください。」

どちらも、伝えている中身は同じだ。だが、受け取ったあなたは、次もコードを見せたくなるだろうか。前者を何度ももらえば、人は見せるのが怖くなる。後者なら、見せてよかったと思える。

この違いは、好みの問題ではない。見せ合いの文化が続くかどうかが、ここにかかっている。

──

だから今、レビューは、粗探しの品評会ではない。

ここで、ありがちな思い違いを正しておきたい。レビューとは、「相手のコードの欠点を、ひとつ残らず指摘すること」ではない。

すべての粗を並べ立て、優劣をつける場にした瞬間、人は見せるのをためらいはじめる。見せなくなれば、知識はまた一人の頭に閉じこもる。それでは、何のためのレビューかわからない。

レビューの目的は、相手を負かすことではない。コードを、複数の人が触れる状態にすることだ。だから、致命的でない好みの違いは、ときに流す。理解を分け合うことを、粗探しより優先する。指摘の数ではなく、見せ合いが続くことを大事にする。

──

では、どこまでレビューすべきなのか。誰の承認があれば取り込んでいいのか。そして、その目をどこまで機械に任せられるのか。そこから先は、まだ決まっていない。

形式的な誤りは、機械が自動で見つけるようになった。最近では、人より先に道具が下読みをすることもある。それでも、「なぜこう書いたか」を分かち合う部分は、まだ人の手に残っている。どこまでを機械に渡し、どこからを人が担うか。その線引きは、いまも動いている。

ただ、こればかりは、もう揺るがない。コードは、一人の頭に閉じ込めない。書いたら、見せる。

──

あのためらいの正体が、これで見える。なぜ、動いているコードを、わざわざ他人に見せるのか。

見せるのは、欠点をさらすためではない。あなたの頭の中だけにある知識を、外に出して、チームの共有物にするためだ。そうすれば、あなたは安心して休める。倒れても、コードは生き続ける。誰かが辞めても、それは終わりではなくなる。

レビューとは、コードを一人の記憶から解き放つ――という自由だ。

──

見せ合うことで、コードは、チームみんなのものになった。

だとしたら、その「みんな」を、もっと広げたら、どうなるだろう。会社の壁も、チームの境目も越えて、世界中の誰にでも、コードを見せてしまったら。

無料で公開して、いったい何の得があるのか。

その話は、次の章で。

第6章 無料で公開して、何の得があるのか

ある研究所に、一台のプリンタがあった。

よく紙が詰まった。詰まっても、誰にも知らされない。みんな、印刷したつもりで席に戻り、しばらくして「まだ出てこない」と気づく。

そこにいた一人の技術者は、考えた。紙が詰まったら、使っている全員に知らせる。たったそれだけの仕組みを、自分で足せばいい。前に使っていた別のプリンタでは、実際にそうしていた。中の仕組みに、数行を書き足すだけのことだ。

だが、できなかった。新しいプリンタの中身――それを動かしているソフトは、外に公開されていなかった。読むことも、直すことも、許されていない。たった数行のために、彼は、作った会社が気が向くのを待つしかなかった。

彼は、納得がいかなかった。自分が毎日使う道具の中身を、なぜ、自分で直してはいけないのか。

──

この小さな出来事の中に、大きな不自由が畳み込まれている。

ソフトの中身が見られないと、使う人は、作った者に従属するしかない。困っても、自分では直せない。気に入らなくても、作り替えられない。会社が「もう売りません」と言えば、明日からそのソフトは、誰にも直せないまま死ぬ。あなたは、ただ待つ人になる。直す力も、学ぶ機会も、配る権利も、手元にはない。

これは、昔話ではない。中身を開けられない機械、勝手に修理してはいけない製品、契約で分解を禁じられたソフト。今のあなたの周りにも、同じ不自由は、いくらでもある。

──

この不自由は、長いあいだ、当たり前の商売の形でもあった。ソフトの中身は、秘密にして売る。

中身を見せれば、真似される。だから隠す。隠すことが、価値を守るのだと考えられた。ソフトを買うとは、動く結果だけを受け取ることで、中の仕組みは、作った会社だけのものだった。

理屈は通っている。だが、その当たり前は、使う人から力を奪っていた。バグを見つけても、報告して待つしかない。自分の仕事に合わせて少し変えたくても、手が出せない。会社の都合ひとつで、頼っていた道具が消える。使う人は、いつまでも、無力なままに置かれた。

図 6-2　中を閉じれば、直す力は作った会社に。中を開けば、その力は使う人の手に移る。

──

ここで、さきほどの技術者が動く。リチャード・ストールマン。

彼は、こう考えた。ソフトを使う人には、本来、四つの当たり前の権利があるはずだ。自分の目的で使う。中身を読んで学ぶ。直したいように直す。それを他人に配る。 中を隠す商売は、この四つを、まとめて取り上げていた。彼は、それを取り戻そうとした。

図 6-1　使い、読み、直し、配る。四つの自由。

そして、ひとつの宣言を書く。誰でも使え、誰でも中身を読め、誰でも直して配れる――そういうソフトを、自分たちの手で作り上げる、と。

ここで、言葉の取り違えを、一つ解いておきたい。彼が掲げたのは「フリーソフトウェア」だった。だが、この「フリー」は、無料という意味ではない。自由、という意味だ。 英語の free には、両方の意味がある。彼が言いたかったのは、値段が 0 円だということではなく、使う人が縛られていない、ということだった。ただ酒のフリーではなく、言論のフリーだ、と彼は繰り返した。

そしてこの一語こそ、この本がずっと追いかけてきたものだ。

──

ひとりの宣言は、思いがけない広がり方をした。

世界中の見知らぬ技術者たちが、自分の手元から少しずつ、部品を持ち寄りはじめた。やがて、その流れに、一人の学生が書いた中核部分が合流する。リーナス・トーバルズ――のちに、世界の大半のサーバーやスマートフォンの土台となる、あの基盤を書きはじめた人だ。誰のものでもないソフトが、本物の、実用に耐えるものとして組み上がっていった。

図 6-3　ひとりの宣言に、世界中の見知らぬ手が集まる。やがて、実用に耐えるソフトへ組み上がっていく。

膨大な人数が、同じソフトに同時に手を入れる。その混乱を捌くために、トーバルズは、もう一つの道具まで作ってしまう。誰が、いつ、どこを変えたかを記録し、世界中の変更を安全に束ねる仕組みだ。いま、ほとんどのプログラマーが毎日使っている、あれである。

同じ考えは、コードの外へも漏れ出した。誰でも書き換えられる百科事典が、専門家が囲い込んだ百科事典を、いつのまにか追い抜いていた。中を開き、皆で直し、自由に配る。その形が、コードでないものまで作り替えていった。

──

だから今、世界の根幹は、こうして公開されたソフトの上で動いている。あなたが今日触れた技術の、見えないところのほとんどが、誰かが無償で公開したコードでできている。

ここで、よくある誤解を、二つ解いておきたい。

ひとつ。これは「タダ働き」や「趣味の善意」ではない。世界中の企業が、本業として、給料を払って、公開されるソフトに人を投じている。なぜか。土台を皆で共有したほうが、各社が秘密に抱えるより、結局みんなが速く進めるからだ。自由なソフトは、慈善ではなく、れっきとした戦略になった。

もうひとつ。さきほどの「フリー」だ。公開されているからといって、何でも 0 円で好き放題できる、という意味ではない。自由には、作法がある。直したものは同じように皆に開け、作った人の名は消すな――そうした約束の上で、自由は回っている。自由とは、無法とは違うのだ。

──

では、その自由を、どうやって支え続けるのか。そこから先は、まだ誰も答えを出していない。

世界が頼りきっている土台が、たった数人の、無償の善意で支えられている、ということが珍しくない。彼らが疲れ果てて手を引けば、世界が揺らぐ。タダで配るものに、どう報いるのか。自由を、誰が支えるのか。この問いは、いまも開いたままだ。

ただ、譲れない一線だけは、はっきりしている。使う人から、直す力を取り上げない。中を開き、皆で直し、自由に配る。

──

問いそのものに、戻ってみる。無料で公開して、何の得があるのか。

問いの立て方が、そもそも、ずれていた。彼らが手に入れようとしたのは、金銭の得ではない。あのプリンタの前で、一人の技術者が奪われていたものだ。自分の使う道具の中身を、自分で開き、自分で直し、自分で配る。 その当たり前を、取り戻すこと。

オープンソースとは、直し、見て、配る――その自由そのものだ。

──

こうして、プログラマーたちは、自由に作り、自由に配れる世界を手に入れた。

ところが、その自由な世界の中で、彼らは、いつまでも言い争うのをやめない。この書き方か、あの書き方か。この道具か、あの道具か。決着がついたものもあれば、何十年も平行線のままのものもある。

なぜ、その議論は、終わらないのか。

その話は、次の章で。

第4部 正解はない

自由に作り、自由に配れる世界を手に入れたあとも、プログラマーは言い争うのをやめない。タブかスペースか。この言語か、あの言語か。何十年も決着しない論争が、いくつもある。

第4部では、その「終わらない議論」との付き合い方を扱う。鍵になるのは、問いを二種類に分けることだ。決着のついた閉じた問いと、どちらにも理由がある開いた問い。第7章で、その枠組みそのものを手渡す。第8章は、開いた問いの最たるもの――言語選びと、ありものに満足できず言語そのものを作る選択。第9章は、作ったものを誰の許可もなく世界へ届ける、Web という仕組みを扱う。

この部だけ、勝ち取る自由の形が少し違う。他の部が自由を「獲得」する物語なら、第4部は、自由を一つの正解に「潰さない」物語だ。「正解はない」は、投げ出しではなく、選び続ける責任を引き受けることだと、ここで示す。

第7章 その議論は、なぜ終わらないのか

チャットが、燃えている。

きっかけは、ごく小さなことだった。インデントは、タブか、スペースか。たったそれだけの話に、何十件もの投稿が積み上がっている。大の大人が、本気で、一歩も譲らない。

あなたは、戸惑う。どちらでも、コードは動く。なのに、なぜ、こんなことで、こんなに揉めるのか。そして、もっと不思議なのは――この手の論争が、何年も、ときには何十年も、決着しないまま続いていることだ。

なぜ、その議論は、終わらないのか。

──

プログラマーには、ひとつの癖がある。「正しい、たった一つの答え」を、探したがる。

これは、悪い癖ではない。むしろ、ここまで見てきた多くの前進は、より良い一つを探す力から生まれた。だが、この癖には裏がある。どんな問いにも唯一の正解があるはずだ、と思い込むと、答えの出ない問いの前で、人は延々と争い続けることになる。

終わらない論争の正体は、たいていこれだ。本来は決着のつかない問いを、決着がつくはずだと信じて、殴り合っている。 唯一の正解という幻が、争う人々を、その場に縛りつけている。

これが、この部で向き合う不自由だ。「正しい一つ」に、縛られる。

──

最初の答えは、力ずくだった。決着がつかないなら、誰かが「これが正解だ」と決めてしまえばいい。

権威ある誰かが宣言する。あるいは、論争に勝ったほうが、唯一の正解の座につく。みんながそれに従えば、不毛な争いは終わる――そう考えられた。実際、プログラミングの歴史には、「これが絶対だ」という宣言が、いくつも刻まれている。

──

だが、その「唯一の正解」は、何度も裏切られた。

ある時代に「これしかない」とされた書き方が、文脈が変わったとたん、時代遅れになる。万能とされた道具が、別の現場ではまるで役に立たない。唯一の正解を立てるたびに、後になって、「あれは、ある条件の中での正解にすぎなかった」と判明する。これは、第1章で見た「銀の弾丸探し」の、別の顔だ。一つの答えですべてを片づけたい、という誘惑が、また顔を出している。

ここで、問いには二つの種類がある、と気づいた人たちがいた。

──

閉じた問いと、開いた問い。 この二つを、分ける。

閉じた問いは、決着のついた問いだ。なぜ片方が残ったのかを、はっきり語れる。

たとえば、かつて、プログラムの流れをあちこちへ自由に飛ばす書き方をめぐって、大きな論争があった。エドガー・ダイクストラ――テストの章でも顔を出した、計算機科学者の一人だ――は、その自由な飛び方が、コードを誰にも追えない迷路にする、と論じた。流れを、決まった形の積み重ねだけで書こう、と。この論争には、勝者がいる。今、彼の言うとおりの書き方が、当たり前になっている。これは、閉じた問いだ。

開いた問いは、決着のつかない問いだ。どちらにも、ちゃんとした理由がある。だから、勝ち負けを書けない。

たとえば、型のあるなしをめぐる長い論争。書くときの安全を取るか、書くときの身軽さを取るか。どちらにも、確かな言い分がある。これは、何十年経っても決着していないし、おそらくこれからも決着しない。タブかスペースか、も、この仲間だ。

図 7-1　勝者を語れるかで、問いは二種類に分かれる。

──

ここで、少し仕分けをしてみてほしい。

世の中で繰り返されている論争を、いくつか思い浮かべる。そして、一つずつ、自分に問う。これは、勝者を語れる閉じた問いか。それとも、どちらにも理由がある開いた問いか。

最初の数件は、迷うはずだ。だが、この「どちらの種類の問いなのか」を、議論を始める前に見分けられるようになると、世界が変わる。閉じた問いなら、答えを学べばいい。開いた問いなら――勝とうとするのをやめて、選び方を考えればいい。

──

だから今、成熟したプログラマーは、論争に飛び込む前に、まずその種類を見分ける。

ここで、いちばん大事な誤解を解いておきたい。「正解はない」とは、「どっちでもいい」という意味ではない。

開いた問いに決着がつかないからといって、何でもありになるわけではない。「全部アリ」は、考えるのをやめた人の言葉だ。閉じた問いには、ちゃんと答えがある。学ばずに「人それぞれ」で済ませれば、ただの怠慢だ。そして開いた問いでさえ、「この場面では、こちらの理由が勝つから、こちらを選ぶ」と、根拠を持って選べる。

「正解はない」とは、投げ出すことではない。唯一の正解という幻に縛られるのをやめて、自分の文脈で選ぶ責任を、引き受けることだ。

──

では、どの問いが、いつか閉じるのか。それは、誰にもわからない。

今は開いている問いが、未来に決着するかもしれない。逆に、閉じたと思われた問いが、新しい文脈で、もう一度開くこともある。問いの仕分けそのものが、永遠に更新され続ける。だから、この見分けに、最終版はない。

ただ、一つの構えだけは、変わらない。すべての問いに唯一の正解がある、とは考えない。

──

では、冒頭の炎上に戻ろう。なぜ、その議論は終わらないのか。

終わらない議論は、たいてい、開いた問いを閉じようとしているからだ。どちらにも理由があるものに、無理やり唯一の正解を立てようとするから、永遠に殴り合うことになる。

種類さえ見分ければ、あなたは、その消耗から降りられる。勝ち負けではなく、選び方の話を始められる。

「正解はない」とは、選ぶ自由を手放さない、という積極的な答えだ。

──

開いた問いの、最たるものがある。どの言語で書くか、だ。

言語は、ただの道具ではない。何を簡単にし、何を難しくするかで、書く人の考え方そのものを、静かに形づくる。

では、用意された言語の、どれもが気に入らなかったら――人は、どうするのか。

その話は、次の章で。

第8章 言語をつくる、という選択

「自分で、プログラミング言語を作った人がいるんですよ」

そう聞いて、あなたは、ちょっと驚く。世界には、もう数えきれないほどの言語がある。なぜ、わざわざ、もう一つ増やすのか。車輪を、もう一度発明するようなものではないか。

だが、その「もう一つ」が、あなたが今、毎日書いている言語かもしれない。誰かが、ありものに満足できず、ゼロから作ったもの。その人は、いったい、何が気に入らなかったのか。

──

まず、見落とされがちなことがある。言語は、ただの道具ではない。書く人の考え方そのものを、静かに形づくる。

どんな言語も、あることを簡単にし、別のことを難しくする。そして、難しいことは、だんだん「やらなくなる」。やらないうちに、やがて「思いつきもしなくなる」。気づけば、人は、その言語が許すことの範囲でしか、ものを考えられなくなっている。

これは、自分では気づきにくい。檻の中にいる者には、檻の外が見えない。もっと楽に書ける世界があると知らなければ、今の不便を、不便とすら感じない。「プログラミングとは、こういうものだ」と思い込む。

図 8-1　言語が難しくすることは、やがて思いつかなくなる。

これが、この章の不自由だ。言語が許すことしか、考えられない。

──

最初の答えは、まっとうだった。ありものの中から、いちばんマシなものを選ぶ。

速いから、これにしよう。みんなが使っているから、これにしよう。仕事で求められるから、これにしよう。世にある選択肢を見比べて、その中の一つに決める。賢い選び方だ。

──

だが、どれを選んでも、ひとつ、ついて回るものがある。その言語を作った人の価値観だ。

速さを何より優先して作られた言語は、書く人に、こまごました我慢を強いる。理論的な正しさを突き詰めた言語は、近寄りがたい。流行で選んだ言語が、自分の作りたいものと、根っこのところで噛み合わないこともある。

選んでいるつもりで、実は、選ばされている。誰かの価値観が染み込んだ道具に、こちらの考え方を、合わせ続けている。ありものから選ぶかぎり、その誰かの価値観からは、逃げられない。

──

ここで、まったく別の基準を持ち込んだ人がいる。

彼が言語を作るとき、第一に置いたのは、速さではなかった。理論的な美しさでもなかった。書く人が、楽しいこと。 ただ、それだった。

奇妙に聞こえるかもしれない。道具を作るのに、性能でも正しさでもなく、「楽しさ」を中心に据える。だが、彼の理屈は、筋が通っていた。道具は、人間のためにある。 ならば、人間が道具に我慢するのは、おかしい。書いていて気持ちがいい、書いていて嬉しい――そういう言語があっていいはずだ。彼は、人間が機械に歩み寄るのではなく、機械を人間のほうへ引き寄せようとした。

これは、彼ひとりの考え方ではない。言語を作る人は、それぞれの価値観を、道具に込める。一つのことを、いろんなやり方で書ける自由を大事にした人。逆に、誰が書いても同じ形になる素直さを選んだ人。読みやすさを、何よりも上に置いた人。言語の数だけ、「何を大事にするか」の答えがある。

──

だから今、言語は、性能の順位表ではない。価値観の、見本市だ。

図 8-2　言語は、性能の順位表ではない。大事にするものの数だけ、言語がある。

ここで、しばしばある誤解を解いておきたい。言語を選ぶこと、まして作ることは、「速いから」「流行っているから」で決まる話ではない。

速さは、たしかに大事だ。だが、それは数ある価値観の、一つにすぎない。速さのために何を捨てるか、捨てないか――そこにこそ、その言語の思想が出る。流行も同じだ。なぜ流行ったのかをたどれば、たいてい、多くの人の価値観に響く「何か」がそこにある。性能の数字や流行の波だけを見て選ぶのは、いちばん大事なところを見落としている。

問うべきは、「速いか」ではない。「自分は、何を大事にしたいのか」だ。

──

では、どんな価値観の言語が、いちばん良いのか。それは、答えの出ない問いだ。

前の章の言葉でいえば、これは「開いた問い」だ。楽しさか、速さか、安全か、素直さか。言語に優劣をつけられないのは、価値観に優劣をつけられないのと、同じことだ。だから、言語をめぐる論争も、終わらない。終わらなくて、いい。

ただ、芯だけは、ぶれない。道具に、人間が合わせるのではない。人間の価値観に合わせて、道具のほうを、選び直す。

──

最初の驚きに、戻ろう。なぜ、わざわざ、新しい言語を作るのか。

ありものが気に入らなかったからだ。正確に言えば、ありものに染み込んだ価値観に、従いたくなかったからだ。彼らは、与えられた檻の中で我慢する代わりに、自分の大事にするものを中心に、道具そのものを作り直した。

言語を作るとは、究極の「選び直し」だ。何を簡単にし、何を大事にするかを、自分で決める。

言語をつくるとは、自分の価値観で、道具を選び直す自由だ。

──

こうして、人は、自分の価値観で道具を作り直せるようになった。

だが、作っただけでは、誰にも届かない。作ったものを、世界中の人の手元へ運ぶには、また別の壁がある。どの会社の許可も、どの機械の都合も超えて、作ったものを、いきなり世界へ送り出す。

そんなことが、どうして可能になったのか。

その話は、次の章で。

第9章 Web だけが、世界を覆った

あなたは、作ったものを、友達に見せたい。

「URL ちょうだい」と言われて、リンクを一つ送る。それだけだ。相手は、何もインストールしない。Windows でも、Mac でも、手元のスマートフォンでも、リンクを開いた瞬間に、あなたの作ったものが動きだす。

あまりに当たり前で、すごさに気づかない。だが、少し前まで、これは魔法のような話だった。作ったものを、世界中の、どんな機械を使っている誰にでも、許可も審査もなしに、一瞬で届ける。なぜ、Web だけが、こんなことを可能にしたのか。

──

かつて、作ったものを人に届けるのは、途方もない難事業だった。

機械の種類ごとに、作り直す。この OS 用、あの OS 用、と何通りも用意する。そして、配る道は、たいてい誰かに握られていた。プラットフォームの持ち主が「うちでは配らせない」と言えば、それで終わり。どれだけ良いものを作っても、届けるかどうかの最後の鍵は、作り手ではなく、別の誰かが持っていた。

これが、最後の不自由だ。機械や、配る場所の持ち主に縛られて、作ったものが、届かない。

──

最初の答えは、壮大だった。バラバラな機械やソフトを、一つの完璧な共通規格で、統一してしまえ。

世界中のあらゆるシステムが、同じ精密な作法でつながる。そういう、分厚くて、厳密で、隙のない標準が設計された。きっちり決めきれば、何でも、何とでもつながるはずだ――そう信じられた。一流の頭脳と、大企業の連合が、本気でそれに取り組んだ。

──

だが、その重い標準は、重すぎて、沈んだ。

仕様は、分厚かった。読みこなすだけで一苦労だ。きちんと動かすには高価な道具が要り、扱える技術者は限られた。完璧を目指した精密さが、そのまま、参加の高い壁になった。少数の大組織は使えても、世界中の名もない作り手には、手が出せない。

ここに、この章の影の主役がいる。完璧を目指して、重くなりすぎたもの。 それは立派な設計だった。だが、立派さは、普及とは別のことだった。誰もが参加できなければ、世界は覆えない。

図 9-1　重さは、参加の壁だった。

──

世界を覆ったのは、その正反対だった。ゆるく、軽く、つなぐ。

Web は、拍子抜けするほど単純な仕組みで始まった。文書に少しだけ印をつける書き方。その文書を「ください」と頼んで受け取るだけの、素朴な約束ごと。そして、受け取った文書を映す窓。どれも、厳密とはほど遠い。多少いいかげんでも、動く。だからこそ、誰でも参加できた。

やりとりの作法でも、軽いほうが勝った。重厚な手続きを踏ませる方式は、結局、あの分厚い標準と同じ道をたどる。代わりに広まったのは、「ものごとに住所を与えて、その住所へ取りに行く」という、あっけないほど素朴なやり方だった。

決定的だったのは、これらが、誰か一社の持ち物ではなかったことだ。仕様は公開され、誰のものでもなかった。だから、どの会社のブラウザも、どの言語も、許可を求めずに参加できた。あとから、ページを動かすための言語が乗り、それを楽に作るための土台が積み重なっていった。土台は、すべて、あの「ゆるく、軽く、公開する」の上にある。

──

だから今、あなたは、URL 一つで世界に届く。誰の許可も、いらない。

図 9-2　作り直して配れば、鍵は他人が握る。URL 一つなら、許可はいらない。

ここで、繰り返し現れる誤解を解いておきたい。新しい技術が出てくるたびに頭をもたげる、あの誘惑だ。「これからは、Web は全部、こう作るべきだ」――たとえば、ページを切り替えず、一枚の画面で全部こなす作り方を、唯一の正解のように掲げる。

だが、思い出してほしい。Web を強くしたのは、軽さと、ゆるさと、誰でも参加できることだった。何でもかんでも一つの重厚なやり方に寄せれば、その軽さを、自分から手放すことになる。それは、Web を覆い尽くせなかった、あの重い標準の失敗を、小さく繰り返しているだけだ。

新しい技術を「唯一の正解」に祭り上げたくなったら、第7章を思い出すといい。それが閉じた問いなのか、開いた問いなのか。たいていは、開いている。そして開いた問いに唯一の正解を立てようとするのは、第1章で見た、銀の弾丸探しの、いちばん新しい姿だ。

──

では、Web は、どこまで重くなっていいのか。そこから先は、まだ誰も答えを出していない。

軽さで世界を覆ったはずの Web は、年々、重くなっている。豊かになった、とも言えるし、勝った理由を手放しつつある、とも言える。どこまでが進歩で、どこからが逆戻りなのか。この問いは、今まさに、開いたままだ。

ただ、これだけは、動かない。届ける力を、誰か一人の持ち主に、握らせない。

──

では、初めの問いに答えよう。なぜ、Web だけが、世界を覆ったのか。

完璧だったからではない。むしろ、逆だ。ゆるくて、軽くて、いいかげんで、誰のものでもなかったから、誰もが参加できた。完璧で重い標準が届かなかった場所へ、不完全で軽い Web は、するりと入り込んだ。

そうして、作る人は、ついに、届ける力まで手に入れた。どの会社の許可も、どの機械の都合も超えて、作ったものを、まっすぐ世界へ送り出せる。

Web とは、誰の許可もなく、作って届けられる自由だ。

──

ここまで、九つの不自由と、九つの自由を見てきた。

複雑さに飲まれない自由。読まれる自由。変えられる自由。触れ続けられる自由。一人に縛られない自由。直し、見て、配る自由。選び続ける自由。価値観で道具を作り直す自由。許可なく届ける自由。

どれも、最初からあったものではない。誰かが不自由に気づき、本気で間違え、議論し、少しずつ勝ち取ってきたものだ。

その営みは、まだ終わっていない。そして今、その営みに、新しい書き手が加わろうとしている。コードを、人と同じように書く存在が。

最後に、一つだけ、問いが残る。

その話は、終章で。

終章 AI は「当たり前」を作れるのか

ここまで、九つの物語を見てきた。

形は、どれも同じだった。まず、困りごとがあった。誰かが、本気の答えを出した。その答えは、やがて失敗した。新しい考えが生まれ、人々が言い争い、少しずつ直された。そして、いつのまにか「当たり前」になった。終わったように見えて、その先には、また次の困りごとが待っていた。

問題、答え、失敗、議論、改善、文化。この六つが、百年のあいだ、何度も繰り返されてきた。プログラマーが「そう考える」ようになった理由は、結局、これだった。誰かが不自由に気づき、本気で間違え、それでも前へ進もうとし続けたからだ。

──

さて、ここで、新しい書き手が現れた。

コードを、人と同じように、いや、人より速く書く存在。AI だ。あなたが今、まさにこの本を手に取っているこの時代に、それは、プログラマーの隣に座っている。

では、問わなければならない。この営みを、AI は引き受けられるのか。

ここで、第7章の区別が物を言う。閉じた問いと、開いた問いだ。

閉じた問い――すでに決着がついて、なぜそうなのかを語れる問い。その答えなら、AI は見事に再現する。世界中の「当たり前」を学び、最も標準的なやり方を、瞬時に差し出す。シンプルに書くことも、テストを書くことも、良い名前をつけることも、AI はもう、たいていの新人より上手にこなす。

だが、この本で見てきたのは、閉じた問いの答えだけではなかった。

──

思い出してほしい。それぞれの章は、決着のついた答えで終わらなかった。最後は必ず、まだ開いている問いへと続いていた。

大きく作るか、小さく割るか。どこまで設計を先に決めるか。どこまでを機械に任せるか。どんな価値観の言語が良いか。Web は、どこまで重くなっていいのか。――どれも、誰もまだ答えを出していない。

そして、もっと大事なことがある。この本に出てきた「当たり前」は、最初はどれも、開いた問いだった。 複雑さとの戦い方も、テストの意味も、自由なソフトの価値も、生まれた当初は、答えのない問いだった。誰かが、まだ答えのない場所で、本気で間違え、議論し、文化に変えた。だから今、それは閉じた問いになっている。

AI が再現できるのは、その結果だ。誰かが命がけで開き、戦い、閉じてくれた、その後の答えだ。

図 e-1　AI が差し出すのは、閉じた後の答えだ。

では、まだ開いている問いを引き受けることは、どうだろう。答えのない場所で立ち止まり、選ぶ責任から逃げず、盛大に間違え、その失敗を恥ではなく次の文化に変えていくこと。自由を、勝ち取り、更新し続けること。 ――それは、AI にできるのか。それとも、それは最後まで、人の仕事として残るのか。

正直に言えば、この問いも、開いている。今、答えを断言できる人は、いない。

──

ただ、一つだけ、確かなことがある。

この本を読み終えたあなたは、もう、外から眺める人ではない。

プログラマーが「なぜそう考えるのか」を、あなたはもう知っている。それは、暗記すべきルールではなく、不自由と戦った人たちの、生きた選択の積み重ねだった。そして、その物語は、まだ閉じていない。次の不自由に気づき、次の「当たり前」を作る列に、あなたは、もう並んでいる。

AI は、コードを書く。おそらく、これからもっと上手に書く。

だが、自由は――まだ誰も答えを出していない問いを引き受け、選び続け、失敗を文化に変えていく、あの営みは――あなたと AI の、どちらが作るのだろうか。

その答えを書くのは、この本ではない。

これから、あなただ。

おわりに

本書がたどってきたのは、開発手法のカタログではない。プログラマーたちが「なぜ、そう考えるのか」という、その考え方の来歴だった。

個々のやり方は、道具や流行とともに移り変わる。だが、困りごとに正面から向き合い、失敗から学び、少しずつ「当たり前」を作り替えていく――その姿勢そのものは、どの時代の、どの技術にも通用する。本書から持ち帰ってほしいのは、まさにそれだ。

FjordBootCamp について

本書は、プログラミングスクール FjordBootCamp（フィヨルドブートキャンプ） の教材として作られた。現役のエンジニアが運営する、オンラインのプログラミングスクールだ。Rails エンジニアコースとフロントエンドエンジニアコースがあり、実務に近い課題を通して、Web エンジニアとして働く力を育てている。

FjordBootCamp が大切にしているのは、答えの丸暗記ではない。分からないことにぶつかったとき、自分で調べ、考え、手を動かして、学び続けられること――その力だ。本書が問いつづけてきた「なぜ、そう考えるのか」という姿勢は、そのまま、この学び方に重なっている。

技術は移り変わる。だが、自分の頭で考えつづける力は、古びない。その力を、ここで、あるいはこの先のどこかで、育てていってほしい。

公式サイト：https://bootcamp.fjord.jp/

付録 年表

本書は、本文では年号を前景化せず、「困りごと」で物語を進めてきました。出来事の正確な時期と人物を確かめたい読者のために、本文で触れた事柄を、ここに年表としてまとめます。

注記：本表は執筆時点の下書きであり、刊行前に一次資料で再確認します（各項目の精度確認は別途進行中）。年代は、その考え方や出来事が広く知られるようになった時期を目安に置いています。

年表に並べると、一直線の進歩に見えるかもしれません。けれど本文で見たとおり、実際は、各時代の人々が、それぞれの不自由の中で本気で間違え、議論し、少しずつ「当たり前」を作り直してきた積み重ねです。