※本記事は、Kent Beck氏とGergely Orosz氏によるポッドキャスト「The Pragmatic Engineer」の内容を基に作成されています。本記事では、ポッドキャストの内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのポッドキャストをお聴きいただくことをお勧めいたします。また、Kent Beck氏、Gergely Orosz氏、および関連メディア(The Pragmatic Engineer)のソーシャルメディアアカウントもご参照ください。
1. オープニング:AIとソフトウェアエンジニアリングの本質論争
1.1 スポンサー紹介
Gergely： 本編に入る前に、今回のスポンサーをご紹介します。まずはAntithesisです。エージェントと一緒にコードを書く時代になると、私たちの仕事はもはやコードを書くことだけではなく、それを仕様化し、検証することになります。Antithesisは、今日もっとも効果的にエージェントが書いたコードを検証できる手法だと考えています。仕組みとしては、システム全体を敵対的なシミュレーション環境の中で動かすことで、ユーザーが気づく前にあらゆるバグを見つけ出します。しかもそのシミュレーションは完全に決定論的なので、単にバグを見つけるだけでなく、問題を毎回まったく同じ形で再現することができます。これはSFのように聞こえるかもしれませんが、実際には非常に泥臭いエンジニアリングの積み重ねです。Jane Street、Fly.io、そしてCCDコミュニティは、Antithesisによって検証されているという安心感のもとで、エージェントが書いたコードを自信を持って本番に出しています。詳しい事例はantithesis.com/pragmaticをご覧ください。
続いてはTurbopufferです。Turbopufferは、いわばAIエージェントのための検索エンジンへと成長した会社で、Ramp、Cloudflare、Harvey、Granolaといった名だたるAI企業がこのサービスの上で動いています。彼らはこれを「puffing」と呼んでいるそうです。Turbopufferはベクトル検索、全文検索、属性フィルタリング、正規表現検索などを1つのAPIにまとめて提供しており、唯一のステートフルな依存先としてオブジェクトストレージを使っているため、非常にスケーラブルで信頼性が高く、コストも安く済みます。それでいて、賢いキャッシュ層のおかげで速度も十分です。面白いのは検索インデックスを無制限に持てる点で、マルチテナントのAIアプリケーションには最適です。テナントごとにインデックスを作れば、データはデフォルトで分離され、規模を気にせずスケールできます。そして先週、Turbopufferは基本料金を月額64ドルから16ドルに引き下げたと発表しました。試してみるには今が絶好のタイミングです。turbopuffer.com/pragmaticからどうぞ。
1.2 Daario発言への反論と「コードと信頼」の気づき
Gergely： 今日は本当にタイムリーな話から始めたいと思っています。Daarioが「コーディングはまずなくなり、その後にソフトウェアエンジニアリング全体がなくなる」という趣旨の投稿をして、話題になりました。これについて、Kentは言いたいことがあるそうですね。
Kent Beck： ええ、私の反応としては、それはソフトウェアエンジニアリングを理解していない人の発言だということです。コーディングはやっていることの一部ではありますが、それはごく一部にすぎません。かなりの時間を占めているとしても、コーディングをしている間には、自信を築いたり、他の人との関係を築いたり、自分自身の理解を深めたりということが同時に起きています。しかもコーディングは、理解を確固たるものにするための優れた手段でもあります。プログラムを書けば書くほど、自分が取り組んでいる領域への理解が深まっていくのです。ですから、それをすべて機械に任せてしまえばいいという考え方は、物事の一部しか見ていないと思います。
Gergely： 興味深いのは、LLMがとにかく速くコードを書けるという点です。以前は、タイピングそのものにも、考えることにも時間がかかっていました。でもKentは、その過程には思考や理解も伴っていたと言っているわけですね。数日前にある言葉を見かけて、それが強く心に残りました。「私たちは信頼が蓄積される速度よりも速くコードを蓄積している」という言葉です。
Kent Beck： その感覚は非常に的を射ています。信頼というのは、自分がある領域の概念を理解しようと苦労し、それを理解できたときに生まれるものです。私はそれをコードとして表現し、自分が本当に理解していたことを示すテストを書きます。そうして初めて、自分のプログラムを信頼できるようになるのです。しかし、もし誰かと一緒にプログラミングをしているのなら、一緒にプログラミングをするという行為そのものが、お互いへの信頼をより深めることにもなります。もし私たちが最終的なユーザーと話し合い、その人のニーズを理解していることを示せたなら――例えば相手が「こういうボタンが欲しい」と言ったときに、「本当に解決したい問題は何ですか」と問い返し、行ったり来たりの対話を重ねたなら――それは人間同士の信頼を築くことになります。こうしたことは、どれ一つとして自動化できません。AIにプロンプトを投げて、指鉄砲を撃つようなポーズとともに「はい、終わりましたよ、ボス」と言われるだけでは、こうしたことは何も起きないのです。「終わった、と言われても、一体何が終わったのか」という話になってしまいます。
Gergely： ソフトウェアエンジニアリングについて話しているのに、Kentは信頼、つながり、理解について語っていて、技術や特定のプログラミング言語、リファクタリングといった話は一切出てきませんでした。これは非常に興味深いです。Kentはこの仕事を50年以上続けてきたわけですが、ソフトウェアエンジニアリングにおいて、人間的な部分こそが最も難しく、あるいは最も重要な部分だと理解してよいのでしょうか。
Kent Beck： これはこれまでで一番大がかりな宇宙的な悪ふざけだと思っています。私のように、他人をあまり理解できないタイプの若者たちは、こう約束されていました。「これがコンピュータだ。このコンピュータを完全に理解すれば、それで君は大丈夫だ」と。それさえやればいい、と言われていたのです。私はキャリアの前半を、自分がなれる最高のプログラマーになることに費やしました。それが成功するために必要なことだと思っていたからです。ところがその後になって、実は人間的な側面がまるごと存在していて、世の中に変化を起こせるかどうかは、他者とコミュニケーションする力、共感する力――これは私の得意分野ではまったくありません――そして相手を説得し、なだめ、理解する力によって左右されるのだと気づかされました。それはまさに、私が学ばなくてよいと思い込んでいたスキルそのものでした。つまり私は「コンピュータさえ理解すればいい」と約束された挙句、「実は違います、人間を理解する必要があります」と告げられたわけです。しかも、その時点ですでに10年分の後れを取っていたのです。
2. 幼少期から大学まで
2.1 電卓とNixie管での原体験
Gergely： ここで一度、原点に立ち返らせてください。多くの人はKentのことを、著書や、Kentが生み出した、あるいは広めることに貢献した数々の技法――XPやTDD、細かなリファクタリングの数々――を通じて知っています。ですが、そもそもの始まりはどこにあったのでしょうか。コンピュータとの最初の接触はどのようなものでしたか。父上が電気工学者だったと伺っています。
Kent Beck： はい、私の父はもともと電気工学者でした。朝鮮戦争のときに海軍で無線オペレーターを務め、そこから学校に戻って電気工学の学位を取り、航空宇宙産業で電気工学者として働き始めました。その後、私たちはサニーベール、つまりシリコンバレーへと引っ越したのですが、それはまだそこが「シリコンバレー」と呼ばれる前の話です。シリコンが発明される以前ということです。当時、エル・カミーノ通りにはまだサクランボ畑が残っていました。私が生まれたのはちょうどその頃です。私が6年生のとき、父がプログラム可能な電卓を家に持ち帰ってきました。大きさはこのテーブルの半分くらい、重さは65から70ポンド(約30キログラム)ほどありました。その電卓にはニキシー管が使われていました。これは7セグメントLEDが発明される前のもので、LEDそのものがまだ存在していなかった時代です。数字の形をした10本のフィラメントを持つ白熱電球のようなものでした。私が書いた最初のプログラムは、単に数を上がったり下がったりカウントするだけのループでした。フィラメントが手前から奥へと並んでいて、0、1、2、3……という具合に光っていくのを、ただ何時間も行ったり来たり眺めるのが好きだったからです。
Gergely： それはまさに、見入ってしまうような光景だったのでしょうね。
Kent Beck： ええ、まさにそうです。それが私にとって、実際のハードウェアに触れた最初の経験でした。ただ、それ以前にも父が持ち帰ってきた本を私は読んでいて、私自身は少しオブセッシブでスペクトラム的な子どもだったので、その本を繰り返し読み込んでいました。最近引っ越しの際にその一冊を見つけたのですが、Burroughs B6700の命令セットマニュアルでした。これは非常に興味深いマシンで、レジスタベースではなくスタックベースの、ハードウェアスタックを持つアーキテクチャでした。当時のディスクリートトランジスタでどうやってそれを実現していたのか、今でも私にはわかりません。ただ、非常に面白いアーキテクチャだったのです。私はその本のページを何度も読み返していましたが、内容はまったく理解できていませんでした。それでも、その仕組みそのものに魅了されていたのです。そして実際に電卓という機械を手に入れ、それをいじれるようになり、アセンブリ言語に近いものを扱えるようになったとき、頭の中にあるアイデアを、この仕組みを理解していれば実際に機械にやらせることができ、それが次のアイデアを生む、ということに気づきました。まさにこれが私を惹きつけたものでした。創造したいという衝動と、機械についての知識が組み合わさることで、自分が世の中に生み出したいと思っていたものを実際に作り出せる、という感覚です。
Gergely： これは1970年代の非常に早い時期の話ですね。Microsoftが設立されたのは1975年ですから。
Kent Beck： そうですね、Microsoftが設立される前でした。当時、こうした機械がどれくらい一般的だったのでしょうか。それとも、まだ何が起こるかもわからない、単に発明されたばかりの面白いものという位置づけだったのでしょうか。おそらく最初の小型化の波は、プログラム可能な電卓、つまり父が持ち帰ってきたようなあの卓上型の電卓だったと思います。その後、手のひらサイズの電卓が登場しました。父がHP-35を400ドルで買ったのを覚えています。今の価値に換算するといくらになるのか見当もつきませんが、こんな小さなものにしては大金でした。
Gergely： 場所を考えると2,000ドルくらいの価値でしょうか。
Kent Beck： そうかもしれません。この電卓では、演算の順序をスタックとして頭の中に保持しておく必要がありました。すべてをスタックに積んでからプラスのボタンを押すと、スタックからポップされて計算される、という仕組みです。その後、HP-45が登場し、これには独自の簡単なプログラミング言語が組み込まれていて、「これは本当にすごい」と思いました。
2.2 マイクロプロセッサとの出会い
Kent Beck： そしてマイクロプロセッサが登場し始め、Z80や8080、6800が出てきました。父と私は、最初の6800ベースのマシンを自分たちではんだ付けして組み立てました。それからアセンブリ言語でプログラミングをするようになり、その後BASICが登場しました。
Gergely： これは1970年代半ばの話ですね。
Kent Beck： そうです。私はこのマシンにかなりの時間を費やしていました。エリートレベルで理解していたとは言えませんが、とにかく夢中になっていました。この機械について学べば学ぶほど、あの創造的な衝動――頭の中にある想像を、実行を通じて世の中に存在するものへと変えていく――において、より効果的になれたのです。それは私にとって常に素晴らしい感覚でした。
2.3 オレゴン大学での学生生活
Gergely： その後、大学に進学する際にオレゴン大学を選ばれましたね。
Kent Beck： といっても、オレゴン大学が私を選んだというのが正しいかもしれません。他に出願した大学にはどこも合格しなかったので。
Gergely： まさかそんな。オレゴン大学では何を学ばれたのですか。学生時代はどのようなものでしたか。
Kent Beck： 最初の年はコンピュータサイエンスでした。楽しんではいましたが、それでもまだ優れたプログラマーとは言えませんでしたし、授業は簡単すぎて少し退屈していました。そこで2年目が始まる直前、非常に暑い日に音楽科の建物を通りかかったところ、オーディションの参加者を募集するチラシが貼ってありました。「ギターを弾けるし、どんなものか見てみよう」と思ったら、気づけば音楽専攻の学生になっていました。私は8歳のときにギターを始めていて、ちょうどフォークブームの終わり頃、カード先生の夏期講習のクラスで、家に転がっていたギターを弾き始めたのがきっかけでした。そのときも、とにかく夢中になって取り組みました。先生が何かを見せてくれると、家に帰って指から血が出るまで練習し、翌日教室に行くと、他の皆はだいたい前日と同じ位置にいるのに、自分だけはあるピッキングパターンやストロークパターンを完全に習得している、というような状態でした。3、4時間ぶっ通しで練習していたからです。音楽にはかなりのめり込んでいて、高校では合唱団に入っていました。私たちの高校にはスポーツはあまりありませんでしたが、音楽は盛んでした。ですから音楽を専攻するのは自然な流れだったのです。音楽で1年過ごした後、プログラミングが恋しくなって戻り、その後シニアリサイタルのためにまた音楽に戻り、それからさらに1年、修士号を取るためにプログラミングに戻って、結局それを修了しました。ですから、私はただ間違った年に学年を終えてしまった、というだけの話です。オレゴン大学には合計で8年間いたことになります。
Gergely： フルタイムで5年、その後修士論文を仕上げるのにも苦労されたのですね。
Kent Beck： はい。修士論文のテーマは新しいクエリ言語についてでした。驚くことではないかもしれませんが、私は権威者とうまくやっていけないタイプで、これは私のキャリアを通じて繰り返し出てくるテーマです。すべての要件を満たして仕上げるということに、とても苦労しました。周囲からは「せっかくここまで来たのに、やめたらもったいない」と言われましたが、当時の私はもう本当にやめたい気持ちでいっぱいでした。「これは単なる形式的な儀式にすぎず、プログラミングとは何の関係もない」と感じていましたし、その頃にはすでにプログラマーとして十分な収入を得ていましたから。ですが結局、私は修士論文を完成させました。ものごとを最後までやり遂げることは重要だと思っています。世の中にある何かへのビジョンから、それを実現するための地道な作業を経て、実際にそれを世の中に生み出すという過程には、どこかで「仕上げる」という段階が必要なのです。もっとも、ジェシー・ジャクソン牧師の言葉を借りるなら、私は「ゼリーを作る人ではなく、木を揺する人」であり、それは間違いなく私自身の性質でもあります。
3. Tektronics時代:Smalltalkと共創
3.1 Smalltalkの設計思想
Gergely： 大学院生だった最後の数年間、実はすでにプログラマーとして働き始めていましたね。最初の仕事は何だったのですか。
Kent Beck： そのとおりです。大学院生時代のある年、Tektronicsのチームがやってきて、彼らが取り組んでいたプログラミング環境の研究について発表をしてくれました。Tektronicsはもともとポートランドで電子計測機器の会社として始まり、そのニッチな分野で成功を収めた後、当時多くの企業がそうしていたように、基礎研究を行う産業研究所を立ち上げていて、その研究テーマの一つがプログラミング環境だったのです。彼らが発表をした際、私は彼らが答えられないような質問をいくつかしました。それがきっかけで夕食に招待され、それが面接につながり、最終的に就職につながりました。
Gergely： Tektronicsは、Ward Cunninghamと出会った場所としても興味深いですね。
Kent Beck： そうですね。Tektronicsは、Smalltalkという型破りなオブジェクト指向プログラミング言語に早くから投資していて、それを商業的に成功させようとしていました。私が入社した頃、オレゴンで発表されていた研究の内容が実際にどう展開していくかを見ていたのですが、このSmalltalkというやつが、これはすごいぞ、と感じて、そこにのめり込んでいきました。
Gergely： Smalltalkに触れたことがない人、あるいは名前だけ聞いたことがあるという人のために伺いたいのですが、Smalltalkの何がそんなに画期的だったのでしょうか。何がKentを惹きつけたのですか。どんな言語だったのですか。
Kent Beck： Dan Ingallsによる「Smalltalkの背後にある設計原則」という美しい論文があるのですが、その冒頭の一文が「Smalltalkはすべての人の創造的精神をコンピュータで支援するものである」というものでした。ここには2つの大きなテーマがありました。一つはプログラミングのための言語としてのSmalltalk言語そのもの、もう一つは、重なり合うウィンドウやポインティングデバイスとしてのマウス、ペイン、スクロールバーといった、対話のための言語です。これらは今でこそユーザーインターフェースの世界から生まれた当たり前のものですが、当時としては先駆的なものでした。しかし言語としてのSmalltalkは、非常に少数のプリミティブから構築されていました。実質的に言語のプリミティブは3つしかありません。メッセージの送信、変数への代入、そして値の返却です。それがすべてです。後半でお話ししますが、私は今、ゼロから新しいSmalltalkを構築するプロジェクトにも取り組んでいます。今なら誰にとってもそれが手の届く範囲にあるからです。ただ、私が美しいと感じたのは、この言語が自らの仕組みを極限まで押し詰めていたという点です。Smalltalkでは数値も含めてすべてがオブジェクトです。2つの整数を足すための関数を呼び出すのではなく、整数に対してプラスというメッセージを送り、パラメータとして別のオブジェクトを渡します。そのオブジェクトがたまたま別の整数であれば、それらが足し合わされる、という仕組みです。これによって、例えば制御構造が言語の中に定義されていないという興味深い事態が起こります。if-thenやif-then-elseは言語の一部ではなく、ライブラリの一部なのです。trueというオブジェクトに対してクロージャを添えてifTrueというメッセージを送ると、そのクロージャが評価されます。falseに対してifTrueを送ると、何も行われずnullが返されるだけです。すべてが同じ基盤の上に構築されていて、Smalltalkには特殊なケースがほとんど存在しません。そのため、条件分岐がどう動作するかを理解するには少し頭を使う必要がある一方で、いざ抽象化を組み立てる段になったときには、余計な特殊ケースに邪魔されることがないのです。
Gergely： それは、今の現代的なプログラミング言語――KotlinでもSwiftでも、それ以降のどの言語を考えても――が、制御構造や予約語といった多くの機能を最初から組み込んでいるのとは対照的な考え方ですね。
Kent Beck： ええ、なぜ予約語などというものが必要なのか、失礼な話です。プログラミング言語は、できる限り多くの語彙を私に与えてくれるべきなのです。ただ、私が調べたところによると、Smalltalkを使った人たちは非常に情熱的になり、使うことを愛するようになる傾向があるようです。そして、ある時期、Smalltalkは数年間にわたって急速に人気を高めていったと理解しています。なぜそれほど人気が出て、その後どうなったのかを教えていただけますか。どうやら下火になっていったようですが。
Kent Beck： 少し長い話になりますし、私が直接関わっていなかった部分もあります。一部はビジネス上の判断に起因します。当時オブジェクトは急上昇していました。それまでCOBOL、FORTRAN、Pascalといった以前の世代の言語でプログラミングをしてきて、その制約に慣れきっていたところに、オブジェクトというものが登場し、これがすべてを変えるだろうと言われていました。人々は本当に興奮していましたが、同時に「オブジェクトを使えばプログラマーはずっと生産的になるので、今ほど多くのプログラマーは必要なくなる」とも言われていました。実際、Smalltalkを使えば普通の人でも自分でプログラムを書けるようになる、専門のプログラマーは要らなくなる、とまで言われていたのです。
Gergely： それは最近もよく聞く話ですね。
Kent Beck： まさにそうです。当時、業界の内部では真剣にそう語られていました。オブジェクトやSmalltalkを使えば、より少ないプログラマーでより多くのことができ、コストも安くなる、と。そしてある程度まではそれが実際に真実でもありました。Tektronicsはワークステーションを開発し、Smalltalkをバンドルして販売するようになりました。すると、化学工学や構造工学、油圧工学といった異なる分野の技術者たちがやってきて、Smalltalkで自分たちが作ったシステムを見せてくれるのですが、表面的にはそれらは見事なもので、彼らは自分の作品をとても誇らしげにしていました。しかし、そのコードの中身を見てみると、それはひどく保守不能な代物でした。とはいえ、人々が自分の欲しいプログラムを自分でプログラムできるようになったこと自体は、大きな前進でした。当時の代替案が「1,000ページの要件定義書を書いて、8年待って、結局欲しかったものが手に入らない」というものだったことを考えればなおさらです。
Gergely： これは今日の状況にもよく似ていますね。専門の開発者を雇うことなど夢にも思わなかったような異なる分野の人々が、今では自分でプログラムを構築するようになっていて、同じことが繰り返されています。ソフトウェアエンジニアとしての視点でそのコードの中身を見れば、カバーされていないコーナーケースがたくさんあり、修正や拡張が不可能な状態になっている、という具合です。
Kent Beck： ええ、まさにそうです。しかし、そこまでは良かったのですが、その後何が起きたのでしょうか。より理解しやすい代替案が登場したのです。例えば、Smalltalkの構文は少し風変わりで、キーワードを用いた中置記法でした。そこに、もともとは「オブジェクト付きC」と呼ばれていたC++が登場します。C++の構文は馴染み深いものでしたが、その設計思想はSmalltalkとはまったく正反対で、多くの仕組みがあり、それらは非常に複雑なものでした。それでも、親しみやすい見た目であったこと、そしてコンパイラが存在したという点が大きかったのです。私たちはSmalltalkでコンパイルやリンクという工程を経験していませんでした。コードを編集すれば、すぐにその新しいコードで実行される、という具合です。編集中のテキストがあって、「これは思ったように動かない」と思ったらControl-Cを押せばデバッガが立ち上がり、スタックを下りていって望み通りに動作していないコードを見つけて修正し、そのまま作業を続けられる、という環境でした。まさにパーソナルコンピュータであるという感覚があり、その所有感の一部は、すべてを見ることができ、すべてを変更できるという点にありました。もっとも、100人がひとつのプログラムに同時に取り組むとなれば、ブレーキをかける必要が出てきます。誰もが好き勝手に、互いに矛盾する形ですべてを変更できてしまっては、それはうまくいきません。ただ「これは自分のコンピュータだ」という感覚と、それを理解しているからこそ力を持てるという感覚、そしてそれによってより多くのアイデアを思いつき、それを実行して世の中に生み出せるという点においては、Smalltalkは見事に機能していました。
3.2 Wardとの週次協働とHotDraw開発
Gergely： Tektronics時代、KentはWard Cunningham――後に世界初のWikiを開発する人物ですね――と一緒に仕事をしていました。彼はデザインパターンの考案にも大きく関わり、エクストリーム・プログラミングにも関わることになります。彼と一緒に仕事をするのはどのような経験でしたか。そして、当時はまだ存在していなかったデザインパターンというものに、どうやって二人で辿り着いていったのですか。
Kent Beck： 私たちはSmalltalkのトレーニングクラスを開講する必要があり、Wardはすでにいくつかのサンプルコードを書いていました。研究所には60人から80人くらいの人がいたので、私たちはお互いを見た目で知っている程度の関係でした。私はすでに自分のプロジェクトを通じてSmalltalkについてかなりのことを学んでいて、同時にPrologのプログラミング言語処理系の開発にも取り組んでいました。当時は論理プログラミングも大きな話題だったからです。私はPrologのための仮想マシンを3つほど実装し、Prologの単一化(ユニフィケーション)の仕組みを示す素敵なアニメーションもいくつか作っていました。Wardは、そのSmalltalkのクラスのために「配管」と呼ばれるサンプルコードを書いていて、「これを一緒に見てほしい」と言われたので、彼の隣に座ってそのコードを見せてもらい、いくつか改善案を提案しました。私たちは一緒にそのクラスを担当し、そこで後に生涯の友人となる人たちにも出会いました。そしてやがて自然な流れで、「Smalltalkにこんなことをやらせられないだろうか」と考えるようになっていきました。というのも、コンピュータがプログラミングをどう支援できるかという世界そのものが、爆発的に広がっている最中だったからです。私たちは誰も見たことのないような高解像度のスクリーンを持ち、動的な言語――しかも自分たち自身の実装なので必要なら自分たちで手を加えられるものです――を持っていて、何が可能なのかすら分かっていませんでした。まず、Wardは低レベルの技術に関して私よりもずっと優れたプログラマーでした。同時に彼は、より高いレベルでの設計の才能や、Wikiに見られるような、力強いトップレベルの目標を見定め、それを実現するものを作り上げる才能も持っていました。私はといえば、生意気な24歳の若造で、彼はしばらくの間、私にキーボードを触らせてくれませんでした。私はただ見ているだけでしたが、やがて「その括弧の対応が取れていない、ここにピリオドが必要だ」というような指摘ができるようになり、実際に彼の役に立つようになっていきました。私は熟練したプログラマーの仕事ぶりを見て吸収していたわけですが、まだ自分が主導しているわけではありませんでした。しかし次第に低レベルのパターンを理解するようになり、そこから次のレベル、さらに次のレベルへと積み上げていき、「これはなぜこう呼ばれていて、あれではないのか」と考えるようになり、シソーラス(類語辞典)を取り出して、まさにぴったりの言葉を探すようになっていきました。やがて私は、彼がすぐには理解できないような提案をするようにもなっていきました。そうなると、私が少しの間キーボードを取って「こういうことだよ」と示すと、彼が「なるほど、分かった」と言ってまたキーボードを取り返す、というやり取りが生まれました。数か月のうちに、私たちはキーボードを行ったり来たりさせながら、複数のレベルで対話するようなプログラミングスタイルを築いていきました。「このコードはなぜ動かないのか」「そもそもこれに取り組むべきなのか」「これを簡単にするにはどんなプログラミングツールが必要か」「うまく機能させるにはどんな設計にすべきか」「そもそも哲学的にこれをやるべきなのか」といった具合に、あらゆるレベルの間を行き来していました。私たちには週ごとの決まったリズムがあり、月曜の朝にコーヒーを飲みながら「こんなものがあったらいいのに」という話をし、そこから「じゃあどこまでできるか試してみよう」となって、火曜・水曜と作業を進め、木曜にはデモを行って磨きをかけ、金曜にはテクニカルレポートを書く、という流れでした。こうして、6か月から12か月ほどの期間にわたって書き続けた一連のテクニカルレポートが残っています。たとえその週の取り組みがうまくいかなかったとしても、月曜、火曜、水曜と過ごす中で「これはうまくいかなかった、その理由はこうだ、次にこれを簡単にするには何が必要かが分かった」ということが分かり、それが次の月曜のコーヒータイムの議題になっていく、という具合でした。こうして私たちは幅広いプログラミングツールやアプリケーションを開発していきました。その一つに、グラフィカルエディタの「HotDraw」があります。私たちにはグラフィカルインターフェースがありましたが、それまでずっとテキストインターフェースに慣れていた身としては、高速なグラフィックスが使えるようになって「これで一体何ができるだろう」と考えたのです。それでどんどんグラフィカルなインターフェースを作っていったのですが、それを作ること自体がとても大変な作業でした。
Gergely： 当時のHotDrawの写真を見たことがあります。
Kent Beck： ええ、そしてこれを見ると、後年のUMLのような、箱と矢印を使った表現を思い出させますね。まったく同じアイデアというわけではありませんが、可視化するという発想には通じるものがあります。もちろん今はUMLを使う人はあまりいませんが、それでも人々はホワイトボードに向かって箱と矢印を描いて、それらがどうつながっているかを示します。これは1987年頃の話でした。当時、私たちには当時としては高性能なグラフィックスのプリミティブがあったので、HotDrawにおける魔法のような瞬間は、複数の四角形を重ねて描き、1つおきに選択して、それをドラッグして前後に動かしてみたときに訪れました。当時のマシンでも10ヘルツ程度のアニメーションが可能で、それが滑らかに動き、四角形の半分が他の半分の後ろに隠れながら動く様子が見えたのです。「これはすごい」と、私たちは本当に興奮しました。
Gergely： それが「HotDraw」という名前の由来だったのですね。
Kent Beck： そうです。あの滑らかなアニメーションを見られたことへの反応が、そのままこの名前になりました。それ以前は、そういった滑らかなアニメーションを書くこと自体が、一からあつらえる大変な作業だったのです。しかしこの仕組みでは、Figure(図形)クラスをサブクラス化するだけで、この2.5次元の世界で動くものが手に入り、あとはそれを使うだけでした。ただ、それらの図形は単なる四角形を表していたわけではなく、それぞれがプロセッサであったり、ジェネレータであったり、何らかの意味を持つものを表現していました。そしてそれをクリックすると、状態を操作するためのハンドルが現れます。それは単にグラフィック上の見た目を操作するだけでなく、その背後にある意味を操作するためのものでした。例えば、あるハンドルは温度を上げ下げし、別のハンドルは圧力を変える、というように、それぞれが取り組んでいる領域の意味を反映していました。そして、これは箱と矢印のモデルでもあったので、要素間の接続もあり、その接続もまた意味を持つものとして、図形の動きに追従するようになっていました。実際、Figure、Handle、Drawingといった言葉そのものは、Wardが考え出したものです。私が考えていたのはもっと平凡な「drawing object」や「drawing handle」といった言葉でした。
Kent Beck： 私はこうしたことに対して、なかなか良い言葉を見つけられずにいましたが、そこでシソーラスの出番になりました。Wardは、これは本の中の図のようなものだ、と考える人で、私たちにはそこに一種のメタファーがありました。ただコンピュータの世界では、図はいくらでも作ることができてしまいます。
Gergely： 実際に紙のシソーラスを持っていたということですか。
Kent Beck： ええ、文字通り紙でできた、言葉が載っている本を持っていました。
Gergely： プログラマーとして、実際にこの本を手に取って、より良い言葉を探していたということですね。
Kent Beck： そうです。これが自分たちだけの習慣だったのか、それとも他にもシソーラスを使っていた人がいたのか、と聞かれれば、私たちはその点ではかなり極端な部類に入っていたと思います。もちろん、正しい言葉を求めて奮闘していた人は他にもいたはずです。
Gergely： これはまさに、プログラミングが単にコードを書くこと以上の営みであるということを思い出させますね。例えば、読書量が多ければより表現力豊かなプログラムを書けるでしょうし、そうでなくてもシソーラスを――もちろん今ならオンラインでもできますが――手に取ってページをめくり、多くの言葉に触れることで語彙が育ち、結果としてより良いプログラマー、より理解しやすく保守しやすいコードを書ける人になっていくのだと思います。
Kent Beck： プログラムの目的の一部は、意図を他の人間に伝えることにあります。そして今では、それをモデルに対しても伝えるという、はるかに開かれた課題も加わっています。人間同士でどう効果的にコミュニケーションを取るかについては、私たちはかなり理解が進んでいます。その理解を実際に活かしているかどうかは別として。しかし、モデルに対してどう効果的にコミュニケーションを取るかについては、私たちはまったく理解できていません。人々はあらゆることを試している最中で、それは素晴らしいことだと思います。それこそが、まさにやるべきことなのです。
3.3 CRCカードとデザインパターンの起源
Gergely： その後、Wardはデザインパターンに深く関わっていくことになりますね。HotDrawを振り返ると、Gang of Fourのデザインパターンにおける箱と矢印の描き方と重なる部分が見えてきますし、モニター上でオブジェクトを可視化するという発想にも通じるものを感じます。
Kent Beck： ええ、すべての要素が私たちのために組み合わさっていったのです。パターンに関する取り組みについて言うと、私はオレゴン大学時代からChristopher Alexanderに関心を持っていました。『The Timeless Way of Building』は当時の私には買えなかったので、書店に何度も足を運んで、立ち読みで読み通しました。Wardもまた、Christopher Alexanderとパターンについて触れたことがありました。Alexanderは、ある種の精神性を宿した建築物を作りたいと考えていました。彼はそれを少し神秘的な言葉で語るのですが、それはそれでよいのです。彼は、人々が自分自身で建物の設計に関する意思決定を行うことで、その精神性が宿るのであり、建築家が「あなたが何を必要としているか教えてください、そうすれば私があなたの完璧な空間を思い描いて、その解決策をお持ちします」というやり方では、それは実現しないという仮説を立てていました。彼が望んでいたやり方は、制約の中で人々自身が意思決定できるように力を与えることでした。私が自分で家を設計すれば、屋根は崩れ落ち、壁は噛み合わないでしょう。なぜなら私はそれを知らないからです。だからこそ制約が必要なのですが、自分自身の生活については自分が一番よく知っています。だからこそ、「家族での食事の時間がとても大切だ」といったことについては、自分自身が意思決定すべきなのです。
Gergely： それは建築という、まさに物理的な建物の領域における話ですよね。
Kent Beck： そうです。ソフトウェアは非常に仮想的なもので、私たちの頭の中、あるいはコンピュータの中に存在するものですが、それでもこの分野から多くのインスピレーションを得たのです。パターンとは制約のことです。人はどんな意思決定でも自由にできるわけではなく、それまでに下してきた意思決定に基づく制約の中で、特定の時点において特定の意思決定を行い、それがまた次の意思決定のための制約を生み出していく、というものです。私たちは、このSmalltalkによるパーソナルコンピュータの精神を次のレベルへと引き上げ、それをプログラムの利用者たちにも与えたいと考えていました。ちょうどそのとき、私たちはTektronicsでうまくいっていないあるプロジェクトのコンサルティングをしていました。何人かのプログラマーが、テスト技術者たちのためのソフトウェアを書いていたのですが、それがまったくうまくいっていなかったのです。そこでWardは、ユーザーインターフェースを設計するための初期のパターン群を考え出しました。当時、グラフィカルインターフェースはまだ真新しいもので、誰も何をすればよいのか分かっていませんでした。音楽学校で学んだ音楽記譜法の歴史も、私たちの参考になりました。記譜法が発明される前は、音楽はまったく口頭伝承の伝統の中にありました。そして記譜法が発明されると、これまでで最も複雑な音楽のいくつかは、実は記譜法が発明された直後の、1200年代や1300年代に書かれています。誰もその限界を知らなかったからです。その後、状況は落ち着いていき、「4部構成のモテットで十分だ、60種類の楽器に60通りのことを同時にやらせる必要はない」というような形に収まっていきました。ユーザーインターフェースについても、まさに同じことが起きていました。誰もそれをどう組み立てればよいのか分かっていなかったのです。そこで私たちは、Wardが考え出した初期のパターン群を提示し、Christopher Alexanderとパターンについて話し合いました。私はポートランドのPowell's Booksで『Notes on the Synthesis of Form』という本を見つけて読みふけりましたが、これはパターンの理論的な土台となる本でした。私たちはこれらのパターンをそのテスト技術者たちに手渡し、「一からやり直しましょう。このパターンを使って、あなたたちの業務プロセスをウィンドウとペインに分解してください」と伝えました。私たちは、自分たちが実装できると分かっているものだけを彼らに使わせるよう慎重に配慮していました。そのため、彼らが実現不可能なものを考え出すことはありませんでした。ペインの中身はリストか、テキストか、波形のいずれかに限られていました。波形は特別扱いでしたが、それでも実装可能でした。彼らが行う各作業には、それぞれ専用のウィンドウが割り当てられ、4つか5つほどの異なるパターンを組み合わせることで、彼らは実装可能なインターフェースを作り上げ、しかも自分たちがそれを所有しているという感覚を得ることができました。そしてSmalltalkのプログラマーたちがそれを見て、「なるほど、これをどう実装すればいいか」を考える、という流れになったのです。これが私たちにとって、パターンへの最初の一歩でした。
Kent Beck： この責任の委譲について、人々はしばしば動揺します。「私はインターフェースの設計者であり、これに一生懸命取り組んできた。あなたにいくつか質問をして、それについてじっくり考えて、その上で解決策を持ってくるので、あなたはそれに感謝し、私の頭を撫でてくれるだろう」と考えたくなるものです。しかし、もちろんそうはなりません。他人の抱える問題への理解には限界があります。なぜなら、あなたはその問題の渦中にいるわけではないからです。あなたは、その人と同じだけの当事者性(スキン・イン・ザ・ゲーム)を持っていません。もしあなたが半導体のテスト技術者でないなら、実際にその技術者本人ほどの当事者性は持ち得ません。なぜなら、彼らはあなたがいなくなった後も長くそのインターフェースを使い続けなければならないからです。
Gergely： それは「フライバイ・アーキテクト」という概念にも通じますね。チームがある非常にシニアな人物を呼び寄せて、その人が提案をしてまた飛び去っていく、というものです。
Kent Beck： それはまさに「カモメ」です。飛んできて、大きな音を立てて、あちこちに糞をまき散らして、また飛び去っていく。
Gergely： そしてその人は当事者性を残さずに去っていくわけですね。ある程度の規模、あるいは在籍年数のあるチームで働いたことがある人なら、誰もがこうした状況を目にしたことがあるのではないでしょうか。それはその人物のスキルの高さとはあまり関係がないという点も興味深いです。
Kent Beck： ええ、例外はいくつかあるかもしれませんが、一般的に、当事者性を持たなければ、下す意思決定はまったく違ったものになってしまうのです。
4. AppleとMasParでのSUnit開発
4.1 Apple時代の挫折と解雇
Gergely： Tektronicsの後、Kentは1987年にAppleで働くことになります。これは私にとって最近になって知った事実でした。どういう経緯でAppleに入ったのですか。当時はどんなことをしていたのですか。
Kent Beck： 当時、Smalltalkは急上昇していました。もともとXerox社がSmalltalkを開発し、それを4社ほどに手渡して「これを実装できるか、それとも特別なものなのか」を確かめさせていました。HP、Apple、Tektronics、そしてもう1社――名前は忘れてしまいましたが――です。HPは結局それで何もしませんでしたが、AppleとTektronicsは本気で取り組みました。Appleは独自のSmalltalk実装を持っていて、それを販売目的の商業化ではなく、Mac向けに使えるものとして活用しようとしていました。ちょうどMacが発売された直後の時期です。私はそのプロジェクトのことを知っていましたし、Tektronicsでは自分が身の丈に合わないほど大きくなりすぎているという感覚もありました。多くのことを学びましたが、自分が成長するスピードよりも組織がそれを認識するスピードのほうが遅く、しかも自分が思っているほど自分は成長していない、という一種の圧縮のようなものを感じていました。周囲からの見え方と、自分自身の見え方との間にギャップが生まれ、その中間のどこかに本当の自分がいる、という状態です。そのギャップが広がりすぎると、動かざるを得なくなります。そこで私はAppleに連絡を取り、Smalltalkプロジェクトで約1年間働きました。しかしそのプロジェクトは結局、実を結びませんでした。というのも、そもそも意味をなさなかったからです。Smalltalkはごく小さなメモリ容量でも動作しましたが、Appleが本当に必要としていた開発ツールは、CコンパイラとPascalコンパイラだけでした。というのも、AppleのソフトウェアのほとんどはCで書かれていたからです。それが当時の業界標準でもありました。もちろん外部の開発ツール市場自体は活況を呈していましたが、Smalltalkがそこで何かを成し遂げることはありませんでした。せいぜい学校の子ども向けくらいで、Appleの売上を牽引するものにはなりませんでした。Appleのコンピュータを買う人たちは、そもそもSmalltalkをやりたいとは思っていなかったのです。
Gergely： Smalltalkの衰退についてお聞きしましたが、パーソナルコンピュータが普及していく中で、結局ニッチな存在にとどまってしまったということでしょうか。
Kent Beck： いいえ、当時はまだ非常に勢いよく成長している最中でした。前年と比べても相対的に多くの人がSmalltalkを使うようになっていました。Xeroxからスピンオフした「Park Place」という会社が、開発者向けにSmalltalkを高額な製品として販売していました。当時はまだオープンソースというものが存在していなかったので、言語処理系そのものにお金を払わせるというビジネスモデルが成り立っていて、これは同じような手法を踏襲するものでした。ですから、Smalltalk自体は依然として盛んでした。ただ、Appleの顧客層やハードウェアには合わなかった、というだけのことです。同じ時期、多くの元Xeroxの人々がAppleに移ってきていました。私の友人であるLarry Teslerもその一人で、友人とは言っても、互いに敬意を抱きながらも「宿敵」と呼べるような関係でした。人にはときどき、首の後ろの毛が逆立つような相手というものがいますが、私にとってLarryはまさにそうでした。彼が同じように感じていたかどうかは分かりません。彼は数年前に亡くなり、もう話す機会はありませんが、その後も互いに近況を確認し合うような間柄ではありました。彼は当時、Appleの先端技術グループのトップを務めていました。Alan Kayもすでにこの頃Appleに移っていて、子ども向けのプログラミング言語「Playground」というプロジェクトに取り組んでいました。Dan Ingallsもそこにいましたし、Xeroxの多くの人々がAppleに移っていて、Alan Kayのプロジェクトのことは私にとって夢のような話でした。Byte誌にSmalltalkについての記事が載っていて、その開発の経緯を読んでいましたし、Smalltalkのプロジェクトは1971年に始まり、実際に何かが公に発表されるまでには1980年までかかっていました。あの環境で働くことを想像するだけで、私にとってはまさに天国のように思えました。そこでAlan KayのPlaygroundプロジェクトに異動したのですが、私はそこでひどく非効率な働き方をしてしまい、結局そのプロジェクトを解雇されてしまいました。
Gergely： まさかそんなことが。プログラマーとして非効率だったというのは、具体的にどういうことだったのですか。
Kent Beck： 私は自分自身のやり方を通したいと思っていました。当時の私はまだ、パンク的なモードにあって、誰かのアイデアを聞いても「いや、それは違う、自分にはもっといいアイデアがある」と考えてしまうタイプでした。もし一人で働いているならそれでも構いませんが、チームで働いているならそれではうまくいきません。そしてついに事態は決定的な局面を迎えました。私はOOPSLAというカンファレンスのプログラム委員長を務めていました――これはもっと早い段階で触れておくべきだったかもしれませんが、当時このカンファレンスは業界で最も注目される存在になっており、業界の名だたる人物が皆そこに集まり、急速に規模を拡大していました。私はいつの間にかそこに巻き込まれるような形で関わるようになっていたのですが、1989年、私はOOPSLAのプログラム委員長として、丸1か月をPlaygroundプロジェクトの業務を放り出して論文を読むことに費やしてしまい、それが最後の一押しとなりました。「君は私たちの役に立っていないのだから、別の道に進むべきだ」というわけです。そしてそのカンファレンスが開催されたとき、私の2人目の子どもがまさに生まれようとしている真っ最中で、結局私はそのカンファレンスに出席することすらできませんでした。ただ、Playgroundプロジェクトのことは以前から耳にしていたので、そちらに異動して、子ども向けのこのプログラミング言語の開発を少し手伝うことになりました。これはオブジェクト指向プログラミングの次に来るものとして構想されていたもので、今なら「リアクティブプログラミング」と呼ばれるようなものでした。メッセージを送るという概念はなく、あるオブジェクトが何らかの条件を発生させ、それを別のオブジェクトが待ち受ける、という仕組みしかありませんでした。いわばパブリッシュ・サブスクライブのような形が、唯一の制御メカニズムだったのです。
Gergely： ちょうどこの頃、CRCカードについても伺いたいのですが。クラス・責務・協調者(Class-Responsibility-Collaborator)カードの略だと理解していますが、これは何だったのですか。どういう経緯で考案されたのですか。
Kent Beck： それまでは命令型のプログラムがあり、そのプログラムの制御の流れを、多少冗長ではあっても正確に表現するフローチャートというものがありました。ところが今や私たちにはオブジェクトがあり、多態性を持つメッセージを送ることができます。つまり、あるメッセージを送ったときに実際にどのコードが呼び出されるのかが、事前には分からないのです。すると人々は「これをどう可視化し、どう内面化すればよいのか」と困惑していました。私自身についていえば、私にはある種の運動感覚を伴う共感覚のようなものがあり、あるコードを見ているとき、それが体の感覚として「こっちに行きたがっている」というふうに感じ取ることができます。他にこういう形でプログラミングの体験を語る人に出会ったことがあるかどうかは分かりませんが、とにかく私はそうなのです。「この行を実行して、次にこの行を実行する」というふうに単純には言えない状況の中で、プログラムの中で何が起きているのかをどう把握するか――そこでWardは、それをインデックスカードに書き出すというアイデアを思いつきました。私たちは普段からそういう話し方をしていたからです。「この四角形があって、それがレンダラーに何かをするよう依頼して、それがパイプラインに入って……」というふうに、手ぶりを交えながら話していました。そこで彼は「これをカードに書き出してみないか」と言い出したのです。オブジェクト指向プログラミングにおける大きな課題の一つは、責務をどう分割するかということです。計算をデータのある場所へと移していくことになるので、「このオブジェクトがこれを行い、あのオブジェクトがあれを行う」という決定は非常に重要なものになります。計算をデータの近くに置くことで、結合度を下げたいからです。これは、その後の議論の中で少し見失われてしまった教訓だと思いますが、オブジェクト指向プログラムを設計する上での根本的な設計上の動きであり、私は今でもその考え方を支持しています。
Gergely： つまり、データが使われる場所の近くに計算を置く、ということですね。
Kent Beck： はい、逆に言えば、計算をデータがすでに存在する場所へと移動させる、ということです。例えば、たくさんのデータを内部に持つリッチなオブジェクトがあれば、計算はそこへ移動させたいわけです。四角形の内部にあるもの――例えば面積――を計算したいのであれば、高さと幅をあちこちに散らばらせて持たせるのではなく、四角形の内部に「面積」という計算そのものを持たせて、高さと幅を扱わせるようにするのです。四角形を2つの対角の座標で表現してもいいですし、左上の座標・高さ・幅で表現してもかまいません。外の世界にとっては、両方とも「面積」というメッセージに応答しさえすれば、どちらでも構わないのです。ですから、別の表現方法、またさらに別の表現方法を考え出したとしても、計算をデータのある場所に移動させている限り、外の世界がそれを気にする必要はありません。
Gergely： そしてそれが、より疎な結合を実現することにつながるわけですね。
Kent Beck： そのとおりです。今日、私たちが行っていることのほとんどは、その裏側では――ほぼすべてがと言ってもいいですが――オブジェクト指向的な考え方に基づいています。ただ、私たちは普段それをあまり意識していません。オブジェクト指向プログラミングや設計そのものへの批判ではなく、実際にはオブジェクト指向言語で書かれたプログラムそのものへの批判にすぎないケースを、私はよく目にします。
4.2 テスターとの社会的分断
Gergely： Appleの後、KentはMasParという会社に移ります。ここで私が注目したいのは、単体テストについてです。ご自身の理解では、この場所で「SUnit」と呼ばれるものを考案されたということですね。
Kent Beck： Tektronicsにいた頃から、私はテストに関心を持つようになっていました。当時、テストというものは一種の社会的な分断の対象でした。コンピュータサイエンスの授業でAやBの成績を取れば、あなたはプログラミングをする側に回れます。しかしCの成績しか取れなければ、あなたはテスターにならざるを得ませんでした。つまり、それはある種の身分のようなものだったのです。「自分はテストなどしない、自分はこちら側の人間だ、あちら側の人間ではない」というわけです。しかし私は、どうすればプログラムを自動的にテストできるのか、どうすれば自分がやっていることへの確信を得られるのかということに興味を持っていました。私は不安を感じやすい性格で、プログラムが複雑になればなるほど、不安を抱える対象も増えていきました。どんな種類のバグが起こり得るのかについての経験が増えれば増えるほど、私はより不安になっていったのです。そして、薬に頼らずにこの不安を鎮める方法があるはずだと考えていました。私はいくつもの異なる自動テストの手法を試してみました。当時は、この地位の分断に加えて、ツールの分断というものもありました。テスト用のツールには、それぞれ独自の言語や、テスト対象のプログラムと連携するための独自の仕組みがありました。ですから私は、あれこれといろいろなことを試していました。
4.3 SUnit誕生の経緯
Kent Beck： 実際にそれが形になったのはMasParを離れた後のことで、その経緯は今となってはもう相当昔の話になってしまいましたが、私はコンサルティングの仕事を始めていて、あるクライアントに「テストを書くべきだ」と伝えようとしていました。翌日にはシカゴへ飛ぶ予定だったのですが、彼らにはテストを書くための手段が何もありませんでした。そこで私は、それまで自分が行ってきた5、6回の実験から、テストケース、テストスイート、テスト結果という3つの概念を合成しました。これは3つのクラスと12個のメソッドほどの、非常に小さなものでしたが、これによってテストを互いに独立した形で自動的に実行し、その結果をまとめて報告してくれるフレームワークができあがったのです。
Gergely： つまりこれは、Smalltalk向けの単体テストフレームワークだったということですね。
Kent Beck： そうです、書かれたのは――少なくとも最初のバージョンは――Smalltalkで書かれていました。MasParはシリコンバレーのベンチャー企業で、SIMD、つまり単一命令複数データという、まったく新しいアーキテクチャをまるごと構築しようとしていました。処理素子をトーラス状のグリッドに最大16,000個接続する、というものです。処理素子同士は左右上下、さらに斜め方向にも通信できるようになっていました。これは今のNvidiaのアーキテクチャに非常によく似ていますが、当時としてはあまりにも時代を先取りしすぎていました。私はそこで3年間、高性能計算のためのプログラミング環境を構築する仕事をしていました。当時のCrayと同等の性能を、10分の1のコストで実現しようという狙いがあり、そのためにはプログラミング環境が必要でした。私たちはSmalltalkでそのプログラミング環境を構築し、そこではかなり面白いこともできるようになっていました。例えば、FORTRANのプログラムをシングルステップ実行しながら、同時にパフォーマンスプロファイルを構築することができたのです。
Gergely： それはすごいですね。Smalltalkの中で、例えばプログラムを解釈しながら実行するようなランタイムを構築していた、ということですか。
Kent Beck： いいえ、そうではなく、私たちには通常の最適化コンパイラがありましたが、オペレーティングシステムそのものを自分たちで管理していたので、非常に低レベルなプローブを構築して、パフォーマンスのプロファイリングデータを収集することができたのです。おかげで、16,000個のプロセッサ上で動作するFORTRANのプログラムについて、行単位のプロファイルと、膨大な量のデータを取得することができました。
Gergely： それは素晴らしいですね。単に低レベルの領域に踏み込んで、プログラムを実行するインフラを構築するというだけでなく、そこからSUnitの話に戻りたいのですが、SUnitのコンセプト――テストケース、テストスイート、テスト結果というものは、なぜこれほどまでに定着したのでしょうか。そして、なぜそれ以前には生まれなかったのでしょうか。
Kent Beck： その後、Erich Gammaと一緒にJUnitを作ることになり、さらに.NET向けのNUnit、xUnit.netなど、こうしたアイデアの多くがそこに引き継がれ、現代の単体テストフレームワークの多くは、こうしたアイデアの上に成り立っています。なぜこれほど定着したのか、そしてなぜそれ以前には生まれなかったのかについて言えば、まず背景として、プログラマーとテスターの間にあった社会的な分断がありました。テスター側には、自分たち独自の言語を持ちたいという強い動機がありました。「これは私たちの道具であり、私たちがその使い方を知っていて、私たちがそれを実行するのだ」というわけです。当時はかなり対立的でもあり、どこか見下すような雰囲気すらありました。「あなたはプログラマーなのだから、テストを任せることはできない、ただ『問題ない』と言うだけだろう。私たちが大人の監督役を務めるのだ」というような態度です。プログラマーが実際にそういうふるまいをしてしまうこともあったので、それに反論するのは難しい面もありましたが、こうした状況が「テストのためのツールはそれ自体独立した世界であるべきだ」という考え方を助長していたのだと思います。テストする言語とテストされる言語を同じものにするというのは、いわば着想の飛躍でした。私自身がSmalltalkの中にいて、Smalltalkであれば何でも表現できるはずだと考えていたので、これは自然な判断でした。ものごとをどうオブジェクトとして表現するか、ということに私は慣れていたのです。
Gergely： つまり、Smalltalkという言語は、数多くのことに先駆けていたということですね。
Kent Beck： ええ、Smalltalkからは多くのイノベーションが生まれたと感じています。オブジェクトを持つ最初期の言語の一つでありながら、非常にシンプルな言語だったからこそ、多くのものを自分たちで構築する必要があり、それが、さまざまなものを表現し、それについて語り合うことにつながり、そして必要であれば――あるいは必要に迫られれば――自分たち自身のテスト環境を書くということにもつながっていったのだと思います。
Kent Beck： そこにはSmalltalkに根付いた一種の精神性がありました。もし使っているツールが気に入らなければ、たとえばデバッガを使っていて、今まさに必要な機能がそこになければ、自分でスタックの上に乗って、その欲しい機能をその場で実装し、また元の作業に戻ればよい、というのがごく自然な発想でした。今日、たとえばCコンパイラを使っていて「Cにこの新機能があればいいのに」と思ったとしても、それを実現するには何年もかけたプロジェクトに乗り出さなければならず、次のレベルに進むための障壁は非常に高いものです。しかしSmalltalkでは、その設計そのものによって、たとえばポップアップメニューにすべての選択肢が表示されるようになっていました。これは意図的な教育的配慮でした。「あなたはカット&ペーストのことは知っているだろうが、他にもできることがある」ということを示すためです。メニューは単にカット&ペーストだけを提示するのではなく、できることすべてを提示することで、ユーザーがそれらについて学ぶことを促していました。というのも、いずれ「ここにフォーマット項目があるが、これは何をするものだろう」と気づくことになるからです。これはまさにSmalltalkの精神の一部であり、このシステム自体が、使い続けるほどにユーザーを教育していくようにできていたのです。ですから、テストツールをその言語自体の中で構築するというのは、非常に自然なことでした。もちろん、そこでは言語を多少「行儀悪く」使う必要も出てきます。あるテストケース用のクラスがあり、その中にテストケースの一つを表すメソッドがあって、それが「t」という接頭辞から始まる、というのは、いわば言語の本来の使い方から少し逸脱した、癖のあるやり方です。そして実行時には、そうしたオブジェクトの一つを生成して「setup」を送ります。なぜなら、事前に何かを準備しておく必要があるかもしれないからです。それから「test何とか」というメッセージを送ると、その一つのテストが実行され、その後、成功したかどうかにかかわらず「tearDown」が実行される、という流れです。つまり構文としては、通常の言語のコードの表現方法をそのまま借りているのですが、それを自分たちで独自に解釈しているという点で、それは言語の中にありながら、実は完全には言語そのものではない、という不思議な性質を持っています。しかし、人々はそんなことをいちいち意識しません。ただ「このクラスをサブクラス化して、testという接頭辞のついたメソッドを書けば、それだけで動き始める」と考えるだけです。それでよいのです。
5. Chrysler:XPとTDDの誕生
5.1 パフォーマンス改善での気づき
Gergely： 数年先に話を進めたいのですが、1996年、Chryslerでのあるプロジェクトに携わり始めますね。ここでMartin Fowlerと出会うことになります。このプロジェクトはどのようなものだったのですか。
Kent Beck： 実はMartin Fowlerとは、それより少し前にすでに会っていました。初期のOOPSLAカンファレンスの頃から、「オブジェクトを使ったプロジェクトを、それ以前の世代のツールを使ったプロジェクトとどう違う形でマネジメントすべきか」という問いが議論されていました。それ以前の世代のツールは、変更のための選択肢がずっと少なかったのです。コードを変更すること自体はできましたが、オブジェクト指向プログラムで作業する場合と比べると、はるかに困難でした。では、オブジェクトのための方法論とは何なのか、どうあるべきなのか――これが1986年の最初のOOPSLAにおける、いわば100万ドルの問いでした。
Kent Beck： 1994年から1995年頃になると、その答えの輪郭が見え始めてきました。当時すでに、いわゆるRational Unified Processにつながる考え方――Grady BoochやIvar Jacobson、James Rumbaughといった人たちが関わっていたものです――が存在していました。人々はそれぞれの形で答えを見出そうとしていて、Wardも自分なりの答えとして「エピソード」と呼ぶものを、パターンランゲージの形で考案していました。私たちには決まった「手法の引き出し」があるわけではなく、その都度同じことを何度も繰り返し使わなければならない、という感覚があったからです。これは誰にとっても同じことでした。これらのエピソードは今もWardのC2サイトで見ることができます。私はそこから多くを借用しましたし、それまでに見聞きし経験してきたあらゆるものからも借用していました。ただ、その時点で――MasParを辞めたのはいつだったか、1992年です――私はすでに4年間、独立コンサルタントとして活動していました。この方法論に関するワークショップがSnowbirdで何度か開催されていて、なぜSnowbirdだったのかは分かりませんが、私はその最初のワークショップでMartinと出会いました。彼の自己紹介はまさにMartin流で、「私はここにいる中で、私が名前を聞いたことのない唯一の人間です」というものでした。彼はすでに分析パターンについて素晴らしい仕事をしていて、私もそれを知っていたので、彼に会えることに興奮していました。
Kent Beck： そこからChryslerのプロジェクトの話につながります。このプロジェクトは2000年問題対応にとって重要なものでしたが、期限までに完成するかどうかは怪しい状況でした。Martinはすでにそこにコンサルタントとして関わっていました。私はRon Jeffriesとは、以前Smalltalk関連の仕事をしている中で知り合っていましたが、正確にどう出会ったかは覚えていません。とにかく、私はリード・コンサルタントのような立場で、まったく異なる開発スタイルでそのプロジェクトを立て直すために招かれました。そのスタイルのために、私は自分が有用だと知っているものはすべて取り入れ、その効果を証明できないものはすべて捨て去りました。それが、この新しい開発スタイルの背後にある価値観でした。Martinと私は定期的にそこを訪れ、Ronはフルタイムでそこに常駐していました。私がもともと招かれたのはパフォーマンスコンサルタントとしてで、Smalltalkのパフォーマンスに詳しかったからです。彼らはGemstoneというデータベースを使っていました。これはSmalltalkのオブジェクトとSmalltalkのセマンティクスを持ちながら、永続化・トランザクション・インデックスといったデータベースとしての機能も備えたものでしたが、動作が十分に速くありませんでした。そこで私は「変更を加えたときに何かを壊していないことを保証するテストケースはどこにありますか」と尋ねたのですが、答えは「実は、まだ正しい答えを計算できていません」というものでした。私は「それなら、非常に高速にすることはできますよ」と答えました。彼らはその答えをあまり快く思いませんでした。とにかく、その1週間で私が見た中で最大の変化が起こり、週末にはみんな疲れ果てていました。彼らは非常に長時間働いていたので、私は「全員を2週間、休みに送り出してください。休養を取らせてください。私たちは戻ってきたら、これまで書いたコードをすべて捨てて、最初からやり直します」と伝えました。
5.2 XPという名前の由来
Kent Beck： そこから私たちは、3週間サイクルでの開発を再開しました。毎回の3週間ごとに、給与計算の専門家であるMarieが指定するテストケースが増え、作業を進め、また次の3週間セグメントを始める、という繰り返しでした。私たちが「11まで振り切った」と言っていたそれらの要素にも、実はさらにいくつか段階があったのですが、とにかくそれは、私たちが想像しうる限り最も強度の高い形で、再計画・統合・デプロイ・リファクタリングなどに取り組んでいた、ということです。そこに込められたアイデアは、私がそれまでに経験してきたすべてのものが一つに統合された結果でした。
Gergely： これはWardから受け継いだ、二人でペアを組んでキーボードを渡し合いながら、取り組むべきことをすべて決めていくというやり方、そしてテストという概念についての経験――それはテストチーム自身が行う必要はなく、自分自身の言語で自分自身が行えるものだ、という考え方――これらすべてが組み合わさったということですね。
Kent Beck： そうです。そしてこの取り組みに名前をつけたのはいつだったのか、というと、それがうまくいき始めた頃でした。最初は興奮もしていましたし、怖くもありました。それから本当にうまくいき始めました。6週間ほど経った頃には、この新しい仕事のやり方について、友人たちに話すのが楽しみになっていました。「Chryslerでこんな新しいやり方をしているんだ」と繰り返し話しているうちに、さすがに同じ言い回しばかりでは飽きてきてしまいました。そこで、シソーラスを片手に、これを何と呼ぶべきか考え始めました。私は、これが大きなものになると確信していたので、それを守りたいと思いました。Grady――今では良き友人ですが、彼には申し訳ないのですが――に、彼が「自分もこれをやっている」と言い出すようなことは絶対にさせたくありませんでした。そこで、誰かが盗みたくなるような、あえて魅力に欠ける名前を選ぶ必要があったのです。
Kent Beck： ちょうどこの頃、私はまた「パンク」に戻っていました。今でもそうですが、少し年を取ったパンクです。ただ、体制に少し中指を立てるような感覚がありました。エクストリームスポーツという言葉が念頭にありました。私はこのエクストリームスポーツとの対比を気に入っています。なぜなら、雪崩の頂上でいきなりスノーボードに初めて乗る、というようなものではないからです。そうではなく、圧倒的な準備をしていて、優れたスキルを持っているからこそ、物事を成し遂げられるのです。
Gergely： トレーニングなどもすべて含めて、ということですね。
Kent Beck： そのとおりです。準備をしていなければ不可能に思えるようなことも、準備をしていれば可能になる。だからこそ、正確でもあり、エッジも効いていて、「エクストリーム」という言葉がぴったりでした。こうして「エクストリーム・プログラミング」が生まれたのです。それが「エクストリーム」の部分の由来です。「プログラミング」の部分について言うと、私は最初「デベロップメント」と呼ぶことも考えていましたし、今でもその言葉は好きです。なぜなら、ソフトウェアで価値を届けることには、単なるプログラミング以上のものが含まれるからです。しかし、当時主流だった方法論は、プログラミングを単なる事務的な作業として扱っていました。「まずこの図を描いて、あの図を描いて、これを組み立てて、14通りの方法でこれを可視化して、それからようやくプログラミングをして、またさらに図を描いて」という具合です。しかし私にとっては、指をキーボードに乗せてコードを見つめる、まさにその瞬間こそが、自分が学びを得る場所でした。なぜなら、そこでは自分がもう自分自身を欺くことができないからです。正しい値を計算しているか、していないか、そのどちらかしかないのです。ですから私は、その「現実とプログラムが出会う瞬間」を、より高い位置に引き上げたいと考えていました。そして、それこそがプログラミングという言葉の由来です。ただ、ごく早い段階から、私はこれを「XP」とも呼んでいました。「エクストリーム」と「プログラミング」という両方の言葉が持つ負の側面から距離を置くための方法として、より一般的な呼び方ができるようにしたかったのです。ところが、その少し後にMicrosoftが「Windows XP」をリリースしました。私が彼らを訴えて成功していたら、という並行世界もありますし、訴えて敗訴し、自分自身も子どもたちも路頭に迷って飢え死にしていた、という並行世界もあったかもしれません。
Gergely： それはまさに1990年代後半、Windows XPが出たのと近い時期のことですね。
Kent Beck： そうです。その少し後、2000年か2001年頃だったと思います。エクストリー・プログラミングが人々に思い出されるようになり、実際に大きな存在になり始めたのはいつ頃のことだったのでしょうか。名前をつけて、人に話し始めたときからだったのか、それとも2000年に出版された著書がきっかけだったのでしょうか。私が最初にXPについて講演をしたときのことを覚えています。配るためのチラシをいくつか用意していました。
Kent Beck： OOPSLAのパネルか何かの場だったと思います。講演の後、人々が「コピーをください」と言ってきました。「いや、いや」という感じで――その反応は、まさに私のシャツを引っ張って「これの一部が欲しい」と言われているようなものでした。そして私は、XPが非常に絶妙なタイミングを得ていたと思います。ドットコムの――バブルではなく、上昇局面のほうが――ちょうど本格化し始めていたのです。人々は他の方法論に目を向けても、「とにかく入念に準備をして、この分析書類を作り、この設計書類を作り、それから大量のコーディングをして、それから大量のテストをする」というものばかりでした。彼らには、それがインターネットの波がこれほど速く変化していく世界ではうまくいかない、ということが分かっていました。一方で、私たちも、Jolt Colaを片手にした「カウボーイ」スタイル――安らかに眠れ、Jolt Cola――で、プログラマーたちが訳の分からないことをして、誰とも会話をせず、ドアの下からピザを滑り込ませているうちに、なぜかコードが出来上がっている、というやり方もうまくいかないと分かっていました。ここに、その両極端の中間に位置するように見えるものが登場したのです。規律があり、反復があり、透明性がある。物事の進め方を舵取りする手段があり、プロセスを調整する手段があります。実際に機能していることを確認するための、あらゆるテストがあります。ビジネス側の人々と技術側の人々との間、あるいは技術者同士の間で、頻繁なすり合わせがあります。「これならうまくいきそうだ」と彼らは考えたのです。インターネットが爆発的に成長していく中で、XPを使えばその機会を活かせる、他にはこれといった代替案がない、と彼らは見ていました。
Gergely： 基本的にXPは、かなり速く俊敏に動きながらも、単に無秩序に突き進むのではなく、安定感を持たせる方法を提供していた、ということですね。テストがあり、反復があり、計画があり、学びがある。
5.3 入出力テープからのTDD着想
Gergely： では、TDDが登場したのはいつだったのでしょうか。というのも、2年後に『Test-Driven Development: By Example』という著書が出ていますが、これはXPとどう関係していたのですか。
Kent Beck： TDDはそれよりも前に生まれたものでした。テスト駆動開発は、私にとってはより早い時期の「再発見」でした。私は子どもの頃、あらゆる本を読んでいたと言いましたが、父が持ち帰ってきた本の一冊――今もまだそのコピーを見つけられずにいるのですが――に「プログラムの書き方」というものがありました。当時はまだ、テープからテープへという時代でした。入力テープ――例えばタイムカードのようなもの――があり、それを給与計算プログラムに通すと、出力テープが出てきます。それは小切手の金額や源泉徴収額などが記録されたものでした。給与計算や買掛金、在庫管理を運用するということは、これらのテープをこのプログラムに入れ、その出力を別のプログラムに入れて……という連鎖の連続でした。これは実は関数型プログラミングでもあります。入力テープを変更することはできないからです。それを実際に、人の手でテープを引き抜いて別の場所に移す、という物理的な作業として行っていたのです。
Gergely： 本当に文字通り物理的にテープを引き抜いて移動させていた、ということですか。
Kent Beck： そうです。その本には、こうしたプログラムの書き方として、「実際の入力テープを一つ取り、処理したいものを用意し、そこから生成されるはずの出力テープを手作業で書き出す」と書かれていました。「この労働時間数であれば、出力にはこういう記録があるはずだ」というふうに、事前に出力を定義しておくのです。
Gergely： つまり、プログラムを書き始める前に、出力を定義しておく、ということですね。
Kent Beck： そうです。まず何を期待するのか、それをどう検証するのかを知る必要がある、というわけです。私はこれを子どもの頃に読んでいて、何一つ理解していませんでしたが、頭のどこかに残っていました。私はSUnitを書いて使い始め、当時知っていた中でも特に優秀なプログラマーの一人であるHal Hildebrandにそれを渡しました。彼が必要とするとは思っていませんでしたが、彼はそれを使い、気に入ってくれました。それで、私はこのテストフレームワークで何か有望なものを掴んでいると分かったのです。
Kent Beck： その後、私はただぶらぶらといろいろ試している中で、あの「出力テープを先に手書きする」というやり方をふと思い出し、それをSUnitで行っていたテストに重ね合わせてみました。「あのパターンに従うなら、コードを書く前にテストを書くことになるな」と思い至ったのです。そして、それがあまりにも馬鹿げたアイデアだったので、思わず声を出して笑ってしまったのを覚えています。なぜ、失敗すると分かっているテストをわざわざ書くのか。まだクラスも定義されていないし、メソッドも定義されていない。それは色々な形でとにかく失敗するだろう、成功するはずがない、というわけです。でも「面白い、試してみよう」と思いました。私は最初の例としてスタックを使いました。スタックを新しく作り、何かをプッシュして、それをポップする。同じものが返ってくるはずです。それを実際にプログラムしてみると、それを満たすのは簡単なことでした。「では次は何か」というと、2つのものをプッシュして、正しい順序で返ってくることを確認する、というものです。それから「duplicate」「pop」「top is empty」といったものを済ませて、終わりました。
Kent Beck： 「あの不安はどこに行ったのだろう」と思いました。
Gergely： それが、消えてしまった、と。
Kent Beck： ええ、初めてのことでした。もう他に失敗しそうなテストケースが思いつかなかったのです。だから、本当に終わったのだと感じましたし、実際に終わっていました。そして気分は最高でした。「これは馬鹿げたアイデアだ」から「とにかく試してみよう」へ、そして実際にやってみたら――という流れです。私はある発言をしたのを覚えています。「安く、かつ元に戻せる形でできるなら、馬鹿げたアイデアは必ず試してみるべきだ」というものです。橋から飛び降りるようなことは、元に戻せない決断ですから、それとは話が別です。そうではなく、こういう類の話です。「これは馬鹿げたアイデアだ」というものの、100回に99回は失敗するでしょう。しかし、たった1回でも成功すれば、あなたには競争相手がいません。なぜなら、他の誰もこんな馬鹿げたことを試すほど愚かではないからです。この「他人にどう思われようと構わない」というパンク的な態度こそが、私に数多くの馬鹿げたアイデアを試させてくれました。その大半は誰の目にも触れることはありませんが、その中には、期待していた以上にうまくいったものが一連あったのです。
Gergely： そしてその後、他の多くの人々もこうしたアイデアを試すようになりましたね。TDDはその良い例で、Kentが著書を出されたすぐ後の時期、非常に人気の高い本になりました。当時はグループ演習をやっている開発者もいたと記憶しています。私も2000年代後半にその本を持っていたと思います。それが2010年代に入ると、実践する人が徐々に減っていったように見えました。そしてほとんど完全に廃れかけていた時期もありました。それが今、エージェントの登場によって再び戻ってきています。時間がかかるように見えて、実はエージェントにとっては、自分自身をテストできるということが非常に有用なのだと分かってきたからです。
Kent Beck： 短期的にはトークンのコストがかかりますが、長期的にはそれによってコストを節約できます。というのも、エージェントにありがちな典型的な失敗のひとつは「何かがうまく動いていない」という状況で、そこからどう手綱を引き戻すか、という問題だからです。
Gergely： ではなぜTDDは廃れてしまったのでしょうか。
Kent Beck： その大きな理由の一つは、私自身が、あるものにしばらく取り組んだ後、また別のものへと移っていくタイプだからです。それはパターンについても、JUnitについても、TDDについても、XPについても同じでした。私はただ次のものへと移っていくのです。それでTDDについても、私自身は次のものへと移っていきました。TDDはそのまま世の中に残り続けましたが、そこにやがて、これを一種の道徳的な棍棒のように振りかざす人たちが現れました。「TDDを使っていないなら、あなたはプロフェッショナルではない」というようなものです。これはまったく的外れなことだと思います。人々は非常に幅広い種類のワークフローで、優れたソフトウェアを書くことができます。それぞれのワークフローには利点と欠点があります。TDDの本領が発揮されるのは、「発見」と「実感」がうまく組み合わさる状況です。自分がどこに向かいたいのかはある程度分かっているけれど、そこにどうたどり着くかは正確には分からない、ただ最初の一歩だけは分かっている、という状態です。その一歩を踏み出すことで何かを学び、それが次の一歩へとつながり、また何かを学ぶ、というふうに続いていきます。ただひたすら実装、実装、実装で進めるならそれでも構いませんし、他にもうまくいくワークフローはあります。ただひたすら学び、学び、学びだけをしたいのなら、それはあまりうまくいかないと思いますが、そこにTDDが絶対必要というわけでもありません。TDDが本当に威力を発揮するのは、「何かをやってみる」「何かを学ぶ」「何かをやってみる」「何かを学ぶ」という素早い往復がある場面です。それこそがTDDの意義であり、道徳的な決断ではなく、実務上の決断なのです。
6. アジャイル宣言とJUnit
6.1 Snowbird会議と宣言誕生
Gergely： それでは、Kentがこれもまた非常によく知られている取り組み、17人が書いたけれどKentが最初に名前を連ねているという、アジャイル宣言についてお聞きしたいと思います。Snowbirdで何が起きたのか、当時の業界がどんな状況で、何が皆さんを一堂に集めることになったのか、教えていただけますか。
Kent Beck： 先ほどお話ししたように、オブジェクトのための方法論とは何か、という問いを巡って、多くの人たちが動いていました。当時、いわゆるRational Unified Processというものが支配的な立場にありましたが、私に言わせれば、それは合理的(rational)でも、統一的(unified)でも、プロセス(process)でもありませんでした。もっとも、そう言うのは半分、人々の神経を逆撫でするための冗談でもありましたが。とはいえ、それが「大人としての正しい開発のやり方」だとされていました。GradyやJim、Ivarと話をすれば、彼ら自身が実際に開発する様子は、私のやり方とかなり近いものになるはずです。しかし、重要なのは自分たちが何をするかではなく、自分たちが書いたものを読んだ人たちが何をするか、ということです。そして実際には、それは非常にウォーターフォール的なスタイルで使われていました。大量の分析、大量の設計、大量の実装、切り離されたテスト、そして何度も何度も繰り返される失敗です。私たちの何人かはそれを見て、それぞれ独自の形で、それぞれのタイミングで、「いや、これはやるべきではない、何か別のことをすべきだ」と考えるようになっていました。私たちはそれなりに声を上げ始めていて、Rational Unified Process側の人々から反撃を受けるようにもなっていました。「そんなことをする必要はない、私の方法をやりなさい、そのためのツールを何百万ドルで売ってあげよう」というわけです。彼らがそう反撃してくる気持ちも理解はできます。しかし私たちは、自分たちが皆、似たような方向に向かっているのだと気づき始めました。スクラム、フィーチャー駆動開発――私たちは、集まらなければならないという結論に至りました。
Kent Beck： 私たちはノルウェーで会議を開き、そこでプレゼンテーションを行いました。これは私がヨーロッパに住んでいた時期の終わり頃のことです。私はスイスに2年間、1997年から1999年まで住んでいました。1999年、私たちはノルウェーの先端まで飛び、私が何度も練習した(それでもうまく発音できなかったと思いますが)「グーテンベリー」というフェリーに乗って、ベルゲンまで下りました。その時期は一日中明るいか、一日中暗いかのどちらかでした。人生で一度は経験すべき、絶景のスポットです。しかしその会議では、実際に一緒に何かをするだけの共通点があるのかどうかを話し合っていました。その会議で得られた感触としては、「一緒に何かをすべきだ」というものではありましたが、それでも依然として多くの摩擦があり、多くの意見の相違がありました。皆それなりに強い自我と、はっきりした意見を持った人々でしたから――私自身も、その中で決して控えめなほうではありませんでした。
Kent Beck： それで、私たちがヨーロッパから戻った後、Jim HighsmithとAlistair Cockburnが、私たちが以前から方法論について話し合うために使っていたのと同じ場所、Snowbirdで別の会議を招集しました。私たちは皆そこに集まりました。会議の詳細については、他の人たちがすでに語っていますので、私自身がそれを十分正確に思い出せる自信はありません。詳しい話が知りたければ、そうした記録を探してみてください。私個人にとっては、その会議はあまりうまくいっていませんでした。ひどい副鼻腔炎にかかっていて、強い薬を飲んでいたので、会議全体についてあまり多くを覚えていないのです。ただ、物事があまりうまく進んでいないことは分かりました。とにかく大勢の人がいて、皆それぞれ「自分のものを盛り込みたい」と主張し、「いや、私のものを盛り込みたい、それはあなたの主張と矛盾する」というような状態でした。それで私たちは休憩を取りました。皆で外に出たのですが、MartinとJim Highsmithだけは中に残っていました。休憩から戻ってくると、そこにはすでに宣言の骨子ができあがっていました。あの「私たちはこれらの価値を認めるが、これらの価値をより重んじる」という、あの形式です。4つの具体的な項目も、すでにすべて出来上がっていました。そしてこれは、私がまったく関わっていない、まさに魔法のような瞬間でした。それから私たちは、そこに原則を付け加えていきました。私が覚えている限り、その中で私自身の言葉と言えるのは「daily(日次)」という一語だけです。ユーザーとの日次の対話について触れている箇所です。それ以外、私が加えたものは他になかったと思います。ただ、実際に公表する段になったとき、名前をどういう順番で並べるかが問題になりました。アルファベット順にするのか、と。
Gergely： 完全にアルファベット順ですね。
Kent Beck： そうです。ですから、「あなたが署名者なのですね」と人に言われるとき、私はアルファベット順で最初の署名者だ、ということです。
Gergely： それで、アジャイル宣言のインパクトはどのようなものでしたか。
Kent Beck： ああ、すぐに、また人々は非常に興奮しました。ちょうどドットコムバブルの前兆がまだくすぶっていた頃で――まだ上昇局面だったと思います――終わりに近づいてはいましたが、人々はまだ「これをどうやるべきか」を探し求めていました。ソフトウェアを速く、安く、信頼性高く作るにはどうすればよいのか。誰もが選択肢(オプショナリティ)を求めていました。
Gergely： オプショナリティを伴う形で、ですね。
Kent Beck： そうです、オプショナリティを伴う形で。というのも、物事が不確実であるときこそ、選択肢は最も価値を持つからです。そして私たちには、選択肢をどう保持するかについての物語がありました。私たち全員が、それぞれ独自のやり方でそれを持っていました。これもまた、以前にも経験したのと同じような現象でした。XPは、私が初めて人にシャツを引っ張られるような経験をしたものでした。JUnitはまた別の例で、これはSUnitに端を発しています。私はSUnitを持っていて、Erich Gammaは新しい言語であるJavaを使っていました。私たちはアメリカへ向けて飛行機で移動していて、彼は私にJavaを見せてくれる予定でしたし、私は彼にSUnitを見せる予定でした。そこで私たちは、ウィーンからワシントン・ダレスへの機内で、JUnitそのものをテストしながら開発しました。
Gergely： 飛行機の中、インターネットもない状態で、ですか。
Kent Beck： インターネットもなく、バッテリーはたった2時間半しか持たず、座席には電源アダプタもありませんでした。まさに時計との勝負でした。まるで馬車で行う計算作業のようなものでした。それで着陸してから、Fowlerにそれを渡しました。彼は当時OOPSLAに参加していたのですが、翌日には「Javaのテストフレームワークを持っているらしいね、コピーをもらえないか」という声が私の耳に届くようになりました。それで私たちは3.5インチのフロッピーディスクを焼いて、需要に応えるためにできる限り速いペースで配って回りました。それが、私が経験した2度目の、いわゆるプロダクトマーケットフィットの瞬間でした。
Gergely： まさにプロダクトマーケットフィットですね。そして次に来たのが、アジャイル宣言で、人々が本当に興奮したもう一つの出来事でした。オリジナルの署名者たちの名前を掲げ、それに署名したい人はしばらくの間署名できるようにする、というのは見事なマーケティングでもありましたね。
Kent Beck： ええ、確かある時点で締め切ったと思います。あまりにも多くの人が集まりすぎたので。ただ、それによって人々は自分がその一部であるという感覚を得ることができました。すでに自分の名前をこの取り組みに結びつけていたわけですから、すでに「買い込んで」いたのです。
Gergely： 何かに投資している感覚、貢献できている、あるいは貢献していると感じられることが、大きな違いを生む、というのは興味深いですね。
Kent Beck： それは確かに違いを生みますし、アジャイルについては間違いなくそうでした。
6.2 "agile"への反対と形骸化批判
Kent Beck： 一つ補足しておきたいのですが、「agile」という言葉についてです。これをどう呼ぶかという議論の一環として、誰かが「アジャイル」という言葉を提案しました。誰が言い出したのかは覚えていませんが、おそらく誰かが覚えているでしょう。私はそれに反対しました。当時から気に入らなかったし、今も気に入っていないのは、それが「守りきれない」言葉だという点です。「私はアジャイルではありません」と言う人など誰もいません。「いえ、私は硬直的な開発のほうが好みです」とか「私は融通の利かない開発を好みます」などと言う人はいないでしょう。誰もが自分は「アジャイル」だと言うでしょう。これは「エクストリーム」という言葉には当てはまらない性質です。ペアプログラミングのスキルを磨き、インクリメンタルに設計を進めるスキルを磨き、徹底的にテストするスキルを磨き、必要なツールを自分で作るスキルに投資したなら、その時初めて「よし、私はエクストリーム・プログラマーだ」と言えます。もしその投資をしていなければ、あなたは自分がエクストリーム・プログラマーだとは決して言わないでしょう。もしそうでないなら。しかし「アジャイル」については、実際にはまったくそうでなくても、誰もが自分はアジャイルだと言うでしょう。それが当時の私の反対理由であり、実際にそのとおりの展開になりました。あの言葉は、もはや何の意味も持たなくなっているだけでなく、むしろ否定的な意味を持つようになってしまいました。
Gergely： では、その後のアジャイルの展開について、いわゆる「Capital A」のアジャイル――本来は良いことをするために生まれたはずが、ある意味で怪しげな「スネークオイル」産業へと変貌していった側面についても伺いたいと思います。今では大企業向けに、莫大な金額で売られる「スケールドアジャイルフレームワーク」まで存在していて、想像できる限りのさらなる官僚主義を組織にもたらしています。これがこれほどまでに大きくなり、商業的な物語としても、いくつかのスネークオイル的な部分としても展開していくことを、Kentはどう見ていましたか。予想していましたか。
Kent Beck： 私たちがこれをまとめた当時から、そうなってしまうことを恐れてはいました。アジャイル宣言は、その場にいた人たちのアイデアの「交差点」にすぎません。ソフトウェア開発には、この宣言に含まれている以上のものがずっと多くあると私は思っていますし、実際に私はそれについて何冊も何冊も本を書いてきました。技術的なスキルという土台がなければ、「私たちは再計画ができます」「機能をどんな順序でも実装できます」「いつでも新しい機能を追加できます」という最良の意図があったとしても、それを実際に実行できるだけの技術的な力量――効率よく信頼性の高いソフトウェアを少しずつ書く力、少しずつ設計する力、選択肢を保持し高めていく力、必要なときには自分でツールを作る力――がなければ、意味がありません。これらは技術的に難しいものです。それはちょうど、雪崩の頂上で初めてスノーボードに乗る人を立たせるようなものです。落ちていく過程には、確かにある種の「敏捷さ(アジリティ)」があるかもしれませんが、それは私たちが本来話していたこととは違います。あの土台が必要なのです。それなのに「いや、いや、そんなことは心配しなくていい、これは簡単だ、誰にでもできる、半分の時間で2倍の仕事ができる」と言い切る人たちがいました。私の見方では、それは単なる嘘です。半分の時間で2倍の仕事をこなすことは可能でしょうか。ええ、間違いなく可能です。しかしそれは、コンピュータサイエンスの学校では教えられておらず、多くの場合、最初の勤め先でもモデルとして示されることのないスキルを、懸命に身につけて初めて実現できるものです。そして今、この「genie」の世界でも、まったく同じことが繰り返されています。「誰もがプログラマーになれる」というわけですが、誰もが「同じ」プログラマーになれるわけではありません。
Gergely： ある種のパターンがあるように思えます。新しい技術、あるいは今回のように新しい方法論が現れると――もっとも技術と方法論は互換可能な概念かもしれませんが――高度な訓練を受けた人たちの集団がそれを使って本当に優れた成果を出し、それを発表して「私たちにはこれがうまくいった、これが結果だ」と共有します。すると、それをより大きな産業が取り上げて、「誰でもこの結果を得られます、私たちがそれをお見せしましょう、そして売りましょう」と言い始めます。そして、例えばある大手銀行がそれが実際にはうまくいっていないと気づく頃には――
Kent Beck： 彼らはすでに多大な投資をしていて、もしかしたら多少の成果は得ているかもしれませんが、期待していたものとは違う、という状態になっているのです。
Gergely： そしてこれこそが、まさにスネークオイルというものの本質なのかもしれません。スネークオイルは何かしらの効果はあるけれど、宣伝されていたものとは違う、という。
Kent Beck： 2001年以降に何が起きたか、話を続けましょう。
7. 失われた10年からFacebook入社まで
7.1 バブル崩壊とバーンアウト
Gergely： 当時、Kentは実際にその渦中でどのような状況にいたのでしょうか。その頃はシリコンバレーにいらっしゃったのですか。
Kent Beck： 1987年から1997年までは、シリコンバレーの上に広がるサンタクルーズ山地に住んでいました。その期間の多くは、そこから職場まで通勤していました。それから1997年から1999年まではスイスに移り住みました。サンタクルーズ山地のボルダー・クリークに住んでいた最後の時期に、私の祖母の近く、南オレゴンに8ヘクタールほどの、木々ばかりの土地を購入していました。そこに電源や井戸、道路などを整備し始めていた矢先に、スイスへ移ったのです。オフィスを建てて、トレーラーハウスを用意していたのですが、それからスイスへ渡り、また戻ってきました。ですから、当時の私は南オレゴンの田舎に住んでいたことになります。
Gergely： そして業界全体が、あの大きなブームを経験することになりますね。今、私がAIに関わる人々と話していて感じる状況とも似ている部分があるように思います。その後、突然のバブル崩壊が起きました。これも私自身は歴史の本や、当時のニュースを読み返して知ったことですが、非常に突然で、衝撃的な出来事だったようですね。当時Kentはどのようにそれを見ていたのでしょうか。プログラマーとして働いていた周囲の友人たちは、何を目にし、どんな影響を受けたのでしょうか。
Kent Beck： 私個人にとっては、それはひどい経験でした。転機となったのは9月11日でした。私はその時点で、8か月分の仕事がすでに、それも今よりも――インフレを考慮してもなお高い――報酬で埋まっている状態でした。ところが9.11の翌日、すべてがキャンセルされました。ちょうど私たちは家を建てている最中で、その仕上げのために大きな支払いが控えていた時期でもありました。まさにその同じタイミングで、収入がすべて消えてしまったのです。一夜にして。
Gergely： 一夜にして、ですか。
Kent Beck： ええ。すでに状況は悪化しつつありました。大型の倒産もいくつも起きていましたし、Pets.comのような話もすでに起きていました。そこへ9.11が加わって、すべてが完全に止まってしまったのです。それは私にとって大きな衝撃で、私は徹底的に燃え尽きてしまいました。深刻な抑うつ状態に陥りました。境界線について、非常に重要な教訓を学ばなければならない時期でした。それまでは――先ほどお話ししたように、周期的に人々から「シャツを引っ張られる」ような経験を、3回ほど大きな形で経験していました。
Gergely： パターンについても、それ以前から同じような状況だったのですね。
Kent Beck： ええ、ですが当時の私は「スター」でした。そう感じていました。「JUnitのおかげで人生が救われた」「XPは素晴らしい、大好きだ、あなたは天才だ」といったメッセージを受け取ることもありました。そういうメッセージをもらうと、とても良い気分になったものです。ところがその後、こんなメッセージも届くようになりました。「XPのせいで人生が台無しになった。仕事を失った。妻に去られた。子どもにも会えない。路上生活をしている」というようなものです。そうすると、今度はひどく気分が落ち込みました。今、私が思うのは、「人からどう見られているか」と「自分自身をどう見ているか」、そして「実際に本当のところどうなのか」というのは、それぞれまったく別のものだ、ということです。人々が、あなたが実際よりもずっとすごい人間だという反応をたくさん寄せてくると、それはあなたの自己認識を歪めてしまいます。有名人にもときどきこういうことが起きます。誰かが非常に有名になり、そしてその人の頭の中が「爆発」してしまう。それは、人からの見られ方と、自分自身の見方との間のギャップです。そして私が学ばなければならなかったのは、人々が私に対して、実際とはかけ離れた過剰な反応――英雄視するにせよ、悪役視するにせよ――を寄せてくる理由は、彼らがそれを必要としているからだ、ということでした。彼らには英雄か悪役のどちらかが必要で、その必要性は、私自身とは何の関係もないのです。もし私でなかったとしても、彼らは別の誰かに同じことをしていたでしょう。それは本当に、私個人とは無関係な話なのです。しかし、その調整をかけることは――「自分は本当にこれほどすごいのだ」と自分を納得させようとしているところに、「いや、あなたはそうではない」というフィードバックを受け取る――それは私にとって、深刻な意味でのリセットでした。
7.2 回復プロセス
Kent Beck： それで私は、いくつものメンタルヘルスの問題を抱えることになりました。仕事もできず、プログラミングもまったくできない状態になりました。私は数独から出直しました。最初は簡単なレベルから始めて、やがて中級レベルもできるようになり、その後、クロスワードパズルにも取り組むようになりました。
Gergely： それはすごいですね。
Kent Beck： そしてやがて、あるプログラミングの問題にたどり着きました。当時新しかったEclipseで、いろいろな作業をしていたのですが、あるプログラミングの問題を見事に解決できたときに、「ああ、まだこれは楽しめるんだ。まだこれができるんだ」と気づいたのです。ただ、2002年頃から2011年にFacebookに入るまでの期間は、いわば「失われた10年」でした。
Gergely： つまり、業界の頂点近くにいた立場から、まさに自分の道を再び見つけ出そうとする状態に落ち込んでしまった、ということですね。
Kent Beck： そうです。似たようなことが、あの突然の暴落がなかったとしても起きていたと思いますか、それとも、すべてが一気に足元から崩れ去るような、あの状況の強烈さそのものが原因だったのでしょうか。
Kent Beck： 私が思うに、人々が私に対して抱く期待に、自分では応えられないと分かっている――それはいずれ何らかの形で必ず破綻する、というものだったと思います。そういう状態のまま、残りの人生をずっと生きていくことなどできません。それがまさに、典型的な「ミッドライフクライシス」というものなのだと思います。それまでうまくいっているように感じられていた仮面が、実は今後はうまくいかないのだと気づく瞬間です。「自分自身でいなければならない」と気づくのです。実際には、それらの仮面は一度もうまく機能していなかった、ただ自分自身をそう思い込ませていただけなのだ、と。それがやってくる年齢は、35歳のときもあれば、40歳、45歳のときもあるでしょう。私の場合は42歳でした。
7.3 Facebook入社の経緯
Gergely： そして2011年、KentはFacebookに入社することになります。この話には非常に興味をそそられます。というのも、当時Facebookは設立からまだ7年ほどで、社内の年齢の中央値はおそらく24歳くらいだったはずです。そこに、業界の伝説的存在であるKentが現れたわけです。TDDやXP、効率的なソフトウェアの作り方について数々の貢献をしてきた人物が、自分の半分ほどの年齢の人たちの中に飛び込んでいくことになります。以前と同じようにコンサルタントとして活動を続けることもできたはずですが。
Kent Beck： 私は実際、以前とまったく同じことを続けようとしていました。コンサルタントとして同じことをやろうとしていたのですが、そこにはもう需要がまったくありませんでした。私は大学の学費を払わなければならず、5人の子どもがいて、4年連続で2人分の学費が重なることも分かっていました。安定した収入がどうしても必要だったのです。本の出版というのは、それほど儲かるものではありません。
Gergely： Kentのようなまれなケースは別かもしれませんが。
Kent Beck： ええ、私の場合は、Amazonのセルフパブリッシングが登場して以降のまれなケースであって、それ以前は違いました。それに、人々がまとめ買いをしてくれるような立場でもなければ、それ以外の場合は――そうですね、儲かりません。
Gergely： Kentがどれほど成功しているか知っているからこそ、こうしてからかいたくなるのですが。
Kent Beck： それは受け止めなければなりませんね。ここで、そしてこのポッドキャストでも受け止めなければなりません。ですから、まず安定と収入が必要だったというのが理由の一つです。しかしもう一つ理由がありました。Facebookの人たちは、私の本に書かれているようなことを何もしていないのに、これだけ大規模なサイトを安定して運用していたのです。完璧ではないにせよ、あれほどの規模でこれだけ安定しているのは、前例のないことでした。しかも彼らは、拡大も続けていました。ユーザー数も成長も劇的に伸びていて、同時にイノベーションも起こしていました。「一体どうなっているんだ、これはまるで飛べないはずのマルハナバチが飛んでいるようなものだ、私の理論からすればあり得ない」と思い、その中で何が起きているのかを知りたくなったのです。
Kent Beck： その時点で私はまだ、方法論や、人々がどう協調していくか、社会的な規模でのソフトウェア開発というものに強い関心を持ち続けていましたが、同時にお金も必要でした。それで入社することにしました。当時、私はおそらく最初の、あるいは最初期のリモートエンジニアの一人だったと思います。従業員は全体で2,000人ほど、エンジニアは700人ほどでした。私はただ、規模の拡大と成長とイノベーションを同時に実現するというのがどうやって可能なのかを解き明かしたいと思っていました。それまで、そのうちの一つを実現している例は見たことがありましたし、二つ同時というのも稀にありましたが、三つすべてを同時に実現している例は、前例がありませんでした。
Gergely： そしてこの入社にまつわる、あのTDDクラスの話について伺いたいのですが。以前どこかでその話をされていたと思います。
Kent Beck： ええ、もちろんです。Facebookに入ってすぐ、私は不安でした。「自分はどうやって貢献すればいいのだろう」と。ここで1週間ほど過ごした挙句、追い出されるだけになるのではないか、と。ちょうどハッカソンが予定されていて、ハッカソンにはよく、参加者向けの講座がセットになっていました。講座の申し込みシートがあったので、私は「TDDの講座をやろう」と考えました。何しろ本まで書いているのだから、と。
Gergely： 「本を書いたのだから」ということですね。
Kent Beck： ええ、「本を書いたし、この分野を作り上げてきたのだから、彼らにも明らかにこれが必要なはずだ」と思っていました。実際、当時単体テストがほとんど書かれていない状況を目にして、私はショックを受けていたのです。「どうしてこんなことがあり得るのか」と。それで申し込みシートに「TDDクラス、講師はKent Beck」と書きました。私の講座の直前には「アルゼンチンタンゴ」の講座があり、直後には「上級Excelテクニック」の講座がありました。実際に講座の時間になると、アルゼンチンタンゴの講座は満席、上級Excelの講座も満席でしたが、私のTDDクラスには誰一人――同情での申し込みすら――一人も現れませんでした。
Gergely： それは驚きですね。
Kent Beck： つまり、そのエンジニアたちは、自分たちはすでにこの分野をきちんと理解できている、この年寄りから学ぶことなど何もない、と感じていたわけです。それで私は決意しました。「自分がソフトウェアエンジニアリングについて知っていると思っていたことは、いったんすべて忘れよう。とにかくやってみよう」と。まさに「見て真似る」というやり方です。人々がやっていることをそのまま真似て、フィードバックをもらいながら、これまでとはまったく違うスタイルの開発を、十分な速さで身につけられるかどうかを試そうとしたのです。「クビにならない程度の速さで、ソフトウェアエンジニアリングをもう一度学び直せるだろうか」と。結局、私はそこに7年間在籍することになりました。
8. Facebookでの7年間
8.1 フィードバックの層モデル
Gergely： それで、何を学んだのですか。何がうまくいく要因だったのでしょうか。というのも、外から見ると、Facebookがやっていたことは意味を成さないように見えたはずです。当時彼らはテストを書いていませんでした。それでいて、あの巨大なサイトをどうにか動かし続けていたわけです。しかも、何十年もの経験を積んで、どんな間違いを避けるべきかを知っているような人材が揃っていたわけでもありませんでした。
Kent Beck： ほとんどが若手のエンジニアでした。ただ、非常に優れたリーダーシップを持ったシニアな人材も何人かいて、彼らがそれを体現し、規範として示すことができていました。そして、システムの中には何層ものフィードバックが組み込まれていました。開発者それぞれが、実際にサイトを動かせる自分専用のマシンを持っていました。ですから、もし色をブルーからグリーンに変えたければ、自分のマシン上でそれができました。
Gergely： モノレポのような仕組みがあって、実際にチェックアウトできた、ということですね。
Kent Beck： そうです。ですから、何でも自由に変更でき、PHPだったので、その変更結果を数秒のうちに確認できました。これが一つ目のフィードバックの層です。そこにコードレビューが加わり、また別の層のフィードバックが得られます。社内向けにはもっと頻繁にロールアウトすることができ、しかも社員は皆、Facebookを個人的にも社内業務でもあらゆる形で使っていたので、自分が開発した機能が何であれ、人々はすぐにそれを使い始めます。これでまた別の一段階のフィードバックが得られます。それから、段階的なロールアウトの仕組みがあり、そこで問題があれば、その影響範囲(ブラスト半径)は数百万人程度に限定されます。
Gergely： シグナルに基づく自動ロールバックのようなものですね。
Kent Beck： そうです。全体には広がりません。Chuck Rossiが率いるデプロイチームも、また別の一段階のフィードバックの層でした。そこには「スター」という仕組みもありました。彼らはこっそりと星の数を割り振っていて、もしあなたが「3つ星」であれば、あなたのコードはあまりチェックされません。しかし「1つ星」であれば、そもそもプッシュすることすらできませんでした。これもまた、フィードバックの一段階です。そしてコードをデプロイした後には、その結果を見ます。初期のオブザーバビリティの仕組みのようなものです。それによって、自分がやったことについての、さらなるフィードバックが得られます。ですから、フィードバックはまるでフィルターのように何層にも重なって入ってくるのです。
Gergely： スイスチーズのように、ですね。
Kent Beck： そうです。そして、異なる種類の層が十分に重なっていれば、悪いものはどこかで引っかかり、良いものだけが通り抜けていくのです。
Gergely： スイスチーズモデルというのは、あちこちに穴が空いているとしても、ということですね。
Kent Beck： その6層の穴が並んでしまわない限り、大丈夫だということです。もし単体テストがあれば、もっと良かったのでは、という話もあるかもしれませんが。私自身、最初にロールアウトした機能について単体テストを書きましたが、それでもサイト障害を引き起こしてしまいました。私が気づいていなかった、別の結合されたコードが原因でした。ただ、それはインシデントレビューを通すほど深刻な問題ではありませんでした。インシデントレビューというのは、また別のフィードバックの層で、毎週金曜日に最もシニアな人たちが集まり、その週に何らかのインシデントを起こした人が来て、「これがそのタイムラインで、私たちはこれを学びました、これを二度と起こさないためにこうします」と説明する場です。もしその場でそのように説明できれば、あなたは問題ありません。しかし、もし「いや、運用チームがこうしたから」「他の誰かがああしたから」というふうに言い訳を並べたら、文字通りドアの外に連れ出されることもありました。それもまた、同じ間違いが二度と起きないようにするための、フィードバックの一段階であり、それは真剣に受け止められていました。
Gergely： 私が知る限り、多くの人が知っているように、Facebookは長い間、ほとんどのものに対して単体テストをしていませんでした。実際、もし誰かがコードをプッシュしようとして単体テストをつけていたら、コードレビューの過程でそれを削除されてしまうことすらあったと聞いています。それ自体は、当時――2010年代初頭、単体テストがベストプラクティスとされ、当たり前の前提とされていた時代――としては、かなりまずいことのように聞こえます。しかし、多くの人が見落としているのは、こうした他のすべての層です。ほとんどの企業にはこうした層は存在しません。私の理解では、今日に至るまで、Facebookのウェブサイトやモバイルアプリのロールアウトのインフラは、シグナルを自動で収集し、自動でロールアウトし、自動でロールバックするという点で、おそらく世界で最も高度なものです。これは他のほぼすべての企業には存在しない仕組みで、それは規模や機会、あるいはビジネスの性質そのものが異なるからだと思います。公共インフラの会社がダウンするのと、Facebookがダウンするのとでは、影響の大きさがまったく違いますから。
Kent Beck： そうですね。私が在籍していた期間で、私が2017年に退職する頃には、Facebookは入社当時とはまったく違う会社になっていました。最初の数年で、Facebookはずっと「公共インフラ」に近い存在になっていきました。大きなサイト障害や大きな負の事件には、名前がつけられるようになりました。その中に「コールオブコップスセフ(Call of Cops Sev)」と呼ばれるものがあって、これはFacebookがダウンしたときに人々が実際に911に電話をかけた最初の事例でした。「うわ、これはもっと真剣に受け止めないといけない」と皆が思いました。なぜなら、私たちは社会インフラであり、人々はそれが絶対に機能することを当たり前に期待するようになっていたからです。
8.2 50/50ゴール制度
Gergely： Facebookの内部はどのような様子でしたか。エンジニアの働き方は、業界の他の場所と比べてどう違っていたのでしょうか。というのも、Kentはそれまでとはまったく違う働き方をする「バブル」の中に身を置くことになったわけですから。
Kent Beck： 計画というものがほとんどありませんでした。締め切りらしい締め切りもありませんでした。Zuckが「写真の解像度を4倍に上げたい」と言えば、エンジニアたちは「それはこれこれの理由でできません」と答えます。すると彼は「分かった、でも写真がもっと綺麗に見えるようにしたい」と返します。そして人々は実際にそれに取り組みに行くのです。それがどれだけ時間がかかろうとも、時間をかけて取り組んで、それがどうしてもできないとなれば、別のことに切り替える、という具合でした。以前、Microsoftから来た人とランチをしたことがあるのですが、その人はこう言っていました。「Microsoftでは、良い課題を見つけたら、それを歯を食いしばって死守しようとする。なぜなら、課題の数自体が足りていないからだ」と。一方Facebookでは、もしあなたが取り組んでいる課題を誰か他の人が手をつけ始めたら、あなたはただ次の課題に移ればいいだけでした。なぜなら、他のどこかで常に何かしらの「燃えさかる火事」があったからです。それは今のFacebookにはもう当てはまりません。当時は機会にあふれていましたが、今は機会が枯渇しています。私はブートキャンプの期間中、うっかり年間500万ドルを節約したことがあります。
Gergely： まさかそんな。
Kent Beck： 当時写真のコードは、一枚のPHPファイルでできていて、私はそれをすべて印刷してつなぎ合わせたことがあります。18ページに及ぶそのファイルが、当時世界最大の写真サイトのすべてでした。それを見て、「何かおかしい」と思ったのです。私たちは、フロントエンドとキャッシュ、あるいはさらに悪い場合はデータベースとの間の往復回数を減らすことに非常に気を使っていました。それでコードを見て、「これは並列化できるな」と気づきました。それで変更を加えたところ、1週間後に写真部門のマネージャーが私のところに来て、「運用チームが、あなたたちの変更をロールアウトした途端に、写真サーバーへの負荷が急に下がったことに気づいた。おかげでサーバーを何台か廃止でき、年間500万ドル節約できることになった」と言ってきました。私はただぶらぶらといろいろ試していただけだったのですが。まさにゴールドラッシュのような感覚で、金塊がそこら中に転がっていて、それをただ拾い上げるだけ、という状態でした。今日ではそれはもう当てはまりませんし、私が退職する頃にはすでに、以前と同じような意味ではそうではなくなっていました。しかし、あの頃は、ただプログラマーとしてプログラマーらしいことをやっているだけで、途方もないレバレッジを持てたのです。それがあの時代の魔法の一部でもありました。これは上場前の話です。
Kent Beck： 中間管理職、つまりエンジニアリングマネジメントの第一階層、第二階層にいた人たちは皆、権利確定していないストックオプションによる、いわば「世代を超えた富」を抱えていましたが、それでもまだ上場を果たさなければなりませんでした。そのため、その階層は局所最適化ではなく、全体最適化に非常に強くフォーカスしていました。彼らは進んで手放すこともありました。あるチームに話を聞くと、「あなたのことは本当に必要なのだが、あなたはこちらのチームに行ったほうがいい。そのほうが私のストックオプションの価値が上がるからだ」というようなことを言われることもありました。それは、いったん希少性を前提とした発想に陥ると、非常に不思議な行動に見えるものですが、当時はそれが実際、極めて新しいことでした。私はこうした事例を、一連のコレクションとして集めていました。先日、その手書きの原稿を見つけたのですが、「Facebookはどう機能しているか」というタイトルで、それまで見たことのないような制度がいくつも書かれていました。その一つが「50/50ゴール」という制度です。6か月ごとの評価サイクルがあり、その6か月の初めに「これが自分の目標です」と宣言します。そしてその6か月後、マネージャーとそれを振り返るとき、もし目標の半分を達成していれば、それはA+評価になります。もし設定した目標をすべて達成していたら――それは「サンドバッグしている」とみなされます。十分に挑戦していない、十分にリスクを取っていない、6か月の間に何も学んでいない、というわけです。もし目標を一つも達成できなければ、それはただクビになるだけでした。ですから、エンジニアやエンジニアリングマネージャーは、私がそれまでどこで見たよりもずっと早いペースで解雇されていました。それは不安を生み出す一方で、周りに「怠け者」を守る必要がないという安心感ももたらしていました。なぜなら、全員が同じ種類のプレッシャーの下にあり、皆が「世界をよりオープンに、よりつながったものにする」という同じ目標に向かって働いていたからです。もっとも、後になって「世界はあまりにオープンでつながりすぎることもある」ということが分かってくるのですが、それはまた別の話です。
Gergely： それでも、Kentがいたのは、いわゆる「黄金時代」だったように感じられます。今は士気が非常に低く、多くのエンジニアが本人の希望に反してデータラベリングの業務に回されているという話も聞きます。まったく違う文化になってしまっているようです。ただ、これは組織というものは変化していくものだ、ということを示しているのかもしれません。当時のFacebookは、まさに成長期にあり、ミッションも非常に興味深く、Kent自身が言うように「機会にあふれた」時代で、エンジニアたちをコーチングする立場にもありました。すでにFacebookに入社できたような、際立った人材について、どんなことを学びましたか。彼らをどのような形で助けることができたのでしょうか。
8.3 Good to Greatコーチング
Kent Beck： 入社から1年ほど経った頃、私はFacebook Messengerというプロダクトのための、C++のプロジェクトインフラに取り組んでいました。このプロダクトは非常に成功していたのですが、そのインフラの規模を超えてしまい、支援が必要な状態でした。私はあまり優れたC++プログラマーではなかったので、そこで際立った成果を出せる立場ではありませんでした。私には状況を立て直すために6か月の猶予が与えられていて、その「行方不明」だった期間、私は自分の生活を支えるためにリモートでのコーチングを行っていました。それまでに、おそらく数百時間、いや数千時間ものコーチングの経験を積んでいたはずです。Facebookの古参の友人であるPeter Demovが、あるとき「君はずっとそのコーチングの話をしているじゃないか。いっそそれを始めてみたらどうだ」と言ってきました。Facebookは、まさに「あなたがエンジニアであり、何かをやりたいと思うなら、それをやればいい。うまくいかなければその結果を引き受け、うまくいけばその見返りを得る」という文化の会社でした。それで私は「よし、自分はコーチになろう」と決めました。看板を掲げて、最初の3人の生徒を見つけ、毎日1時間の対話から始めました。これは3週間、あるいは4週間続けるには多すぎるとすぐに分かりました。生徒のうち2人はうまくいき、1人は解雇されてしまいました。ただ、彼らが他の人にもそのことを話してくれたので、この「コーチング」というものを求めて、人々が私のところに来るようになりました。それがやがて「Good to Great(グッド・トゥ・グレート)」というプログラムへと発展していきました。
Kent Beck： そのアイデアは、優れてはいるものの、ある種の停滞状態に入ってしまったプログラマーたちと話をする、というものでした。ここには一種の「区切りのある均衡」のような現象があります。人々はある程度うまくなった後、あまり成長しないまま経験だけを積み重ねていってしまい、次の段階に押し上げるためには、ちょっとした後押しが必要になるのです。それが「Good to Great」の部分です。私は1対1でコーチングを行っていて、一度に6人をコーチングしていましたが、これは非常に消耗する仕事でした。同時に、他のシニアなエンジニアとジュニアなエンジニアをマッチングして、コーチングをしてもらうことも行っていました。そして「コーチをコーチする」というメタな対話の場も持っていました。「今週あった、どう対応すればいいか分からなかった出来事、あるいは難しかった出来事を教えてください」というような形で、皆で話し合うのです。あるオフサイトでは、ストーリーテリングのコンサルタントを呼んだこともあります。Aaron Orgeという人を、自分にとって得意分野ではないこうした運営の取りまとめのために雇いました。彼女はHRと協力してこのプログラムを分析し、私の指導を受けた人たちは、コーチングを受けなかった同じような属性のコホートと比べて、翌年に昇進する確率が2倍になっている、ということを明らかにしました。つまりこれは、実際にその人たちのキャリアの進展を加速させる効果があった、ということです。
Kent Beck： 私自身は、このプログラムの政治的な側面をあまりうまく扱えていませんでした。これは、正式なラーニング・アンド・デベロップメント組織の外側で行われている、いわば「learning and development」のようなものだったのですが、私はそれが問題になり得るということを理解していませんでした。私が退職する頃には、Good to Greatの大ファンになった人たちがいる一方で、このプログラムが存在すること自体を快く思わない人たちもいました。結局、私は200人ほどを個別にコーチングし、自分自身で講座を書き、それを他の人たちにも教えられるようにしたことで、さらに何千人ものエンジニアがその講座を受けることになりました。退職する直前、私はFacebookのトップ1パーセントのエンジニアたちが集まるオフサイトに参加したのですが、そこに集まった100人あまりのうち、10人が、かつて私の生徒だった人たちで、その後そのレベルまで昇進していたのです。それを見て、私はこれがどう実を結んだかについて、本当に良い気持ちになりました。これはある意味で、Wardとの関係に対する恩返しのようなものでもありました。それは決して常に心地よいものではありませんでした。頭を撫でて「大丈夫だよ」と言うようなものではなく、「いや、それは違う、これをやってみて、どうなったか教えてくれ」「ああ、それをやらなかったんだね」「その課題に取り組みたくないのか。分かった、それならここまでにしよう」というような、かなり妥協のないやり方でした。私はよく、コーチというのは「生産的な不快感」を見出し、それを引き起こす存在だと言っています。ただ、このコーチングプログラム全体としては、私が退職する頃には、私にコーチングされた人がコーチになり、その人がまたコーチングした人がさらにコーチになり、というふうに「ひ孫弟子」にあたる世代まで生まれていました。この種の学び方には、他では代替できないある種の要素があると思います。ですから、Daarioが「私たちはソフトウェアエンジニアリングをなくすつもりだ」と言うとき、それは彼がソフトウェアエンジニアが実際に何をしているのかを理解していない、ということなのです。私たちは、ソフトウェアエンジニアリングを構成する活動のいくつかを変容させていくことになるでしょう。それは間違いありません。私自身、それを心から楽しんでいます。しかし、「私たちはコードモンキーで、要件を入力すればコードが出てくるだけの存在だ」という考え方――冗談じゃない、という話です。
Gergely： 正直に言うと、私にはDaarioが開発者、いわゆるソフトウェアエンジニアという存在に対して、ある種の軽蔑を抱いているように感じられます。あるいは、彼がソフトウェアエンジニアを好んでいる、あるいは自分自身もそうであったことがある、という形跡を、私は一度も見たことがありません。
Kent Beck： ええ、彼は明らかにソフトウェアエンジニアではありませんでした。それはそれで構いません。物理のバックグラウンドを持つ人、というようなものでしょう。それ自体は問題ありません。「あなたの仕事を置き換えるつもりだ」と言うこと自体、私はそれを失礼だとは思いません。ただ、それは「無知」だと思うのです。
Gergely： ちなみに、この話題は私たちの議論の中で何度も出てきましたが、人々がしきりに私たち開発者を置き換えたがるということについて、改めて振り返ってみたいのですが、なぜこの話が繰り返し出てくるのだと思いますか。
Kent Beck： 単純に、私たちは時々そういう存在だから、というのが長い話を短くまとめた答えだと思います。私自身、スペクトラム上にある人間として、長年エンジニアをやってきましたし、父もエンジニアで、祖父も、無線という自分なりの形でギークだった人でした。ですから、私はこれを正直に受け継いでいます。私たちは、必ずしも良い感情の制御スキルを持っているわけではありません。生まれつきの共感力も持ち合わせていません。私たちはしばしば、他の人が簡単には受け止められないほど直接的な物言いをしてしまいます。
Gergely： ビジネスの場では特にそうですね。
Kent Beck： 私はただ真実を言っているだけだ、あるいはただ質問をしているだけだ、と思っているのですが、その質問の仕方自体が、実はある種の攻撃的な行為になってしまっている――それに私自身は気づいていないのですが、それが人々の反応の仕方なのです。ですから、私は誰かが私に対して大目に見てくれることを期待してはいません。「自分の変わったところに、世界の方が合わせるべきだ」と言う人もいますが、それはただ実現しないことです。だからこそ、共感を学ぶこと、ボディランゲージを読み取る学び方を身につけること、声のトーンを読み取る学び方を身につけることが必要になります。これらは生まれつきのスキルではありませんが、学習可能なスキルではあります。私は決して、社会的な天才である私のパートナーほどには上手にはなれないでしょうが、それでもひどい状態ではなくなることはできます。「攻撃的であること」は、私のようなタイプの人間にとってよくある社会的戦略であり、私自身もこれまでそういう戦略を取ってきました。
Kent Beck： 私たちの間に何か意見の相違があったとき、私がそれを解消するやり方は、例えば「これはどれくらい時間がかかるものなのか」というものです。4週間かかるところを、2週間でやらなければならない、と言われたとします。
Gergely： それは対話への招待のようなものですね。私が「4週間かかる」と言って、あなたが「いや、2週間でなければならない」と言ったとき、私はそこで縮こまって「分かりました、なんとかやってみます」と言う必要はありませんし、かといって「勝手にしろ、この野郎」と言う必要もありません。そのどちらも助けにはならないのです。
Kent Beck： 「分かりました、それではあなたのニーズを理解させてください」と言うことです。私にとって簡単なことではありませんが、それはできることです。私にはちょっとしたチェックリストのようなものがあります。『ターミネーター』の最初の映画で、彼が対応のパターンをプルダウンメニューのように表示するシーンがありますが、まさにあんな感じです。
Gergely： それはよくそう感じますね。
Kent Beck： ただ、そのプルダウンメニューの選択肢を持っておくほうが、相手を遠ざけてしまい、対話が終わる前に会話そのものを終わらせてしまうような何かをするよりは、ずっと良いのです。私が思うに、私たちには、他の人が実際に耳を傾けられるようなスタイルでコミュニケーションを取る方法を学ぶ責任があると思います。だからこそ私は、金融の世界やスポーツ、歴史など、あらゆる場所からアナロジーを持ち込もうとするのです。それは、他の人を理解し、そして自分自身の視点や、それが状況にどう関わってくるのかを、相手が実際に理解できる形で伝えようとする、いわば必死の試みなのです。
9. Explore/Expand/Extractと現代AI時代
Gergely： 現在に話を移していきたいと思います。ここ数年、私たちはAIのLLMを手にするようになり、今ではそれを単に「AI」、あるいはKentの言葉を借りれば「genie(ジニー)」と呼んでいます。これは願いを叶えてくれるものですが、実際には自分が本当に望んだものとは違うものが出てくることもあります。個々の開発者の働き方や、チーム、テック企業がソフトウェアを構築するやり方に、これがどう影響していくと考えていますか。ここまで、ソフトウェアエンジニアリングとは本当は何なのか、理解やコミュニケーション、コーディングをしながら学んでいくということについて話してきましたが、それが縮小しているように見える、あるいは奪われつつあるようにも見えます。
Kent Beck： それは選択の問題です。ただ、最後まで質問を聞かせてください。
Gergely： これは業界全体を見渡しての話です。ちょうど昔、インターフェースというものが登場したときに、人々がそれをやりすぎてしまい、賢明なやり方を忘れてしまった、という状況とも似ているように感じます。今、私たちはAIエージェント、いわゆる「ジニー」をあらゆる場所で使うようになっていて、人々はそれに夢中になるあまり、いくつかの分別あるやり方を見失いつつあるようにも見えます。
Kent Beck： そうですね、これは非常に開かれた問いです。一つ言えるのは、開発のペースは間違いなく加速している、ということです。しかし私が疑問に思うのは、ビジネスのペースはそれほど加速していない、ということです。そして、そのミスマッチが、これからますます顕著になっていくだろうと思います。あるクライアントのところで、彼らが年間200万ドルを支払っているあるSaaSプロダクトについて話していたことがあります。誰かがそれをバイブコーディングで置き換えたところ、彼らの用途にとってはより良いもので、しかも年間200万ドルもかからないものができてしまいました。このとき、そのベンダーはどう対応するのでしょうか。かつて――といっても2年前の話ですが――であれば、彼らには対応するための猶予が何年もありました。「ええ、うちにはこのアドオンがあって、年間200万ドルかかりますが、ユーザーはあまり気に入っていません、いずれ代替品を見つけることになるでしょう」と言っていられる、そのための猶予が3年、5年とあったわけです。しかし今では、「このアドオンで課金できていたものが、1か月以内になくなってしまう」という状況になっています。ベンダー側も、より良い代替品を自分たちでコーディングできるかもしれません。彼らも同じような加速を経験しているのですから。しかし問題は、代替品が必要だという認識が、カスタマーサービスからマーケティング、営業、事業開発、プロダクト組織へと伝わっていくのに、それだけの時間がかかるかどうかです。「うんぬんかんぬん」というプロセスは、もともと5年かかるように設計されていて、今ではそれが1か月しかないのに、彼らはその収益の大きな部分を失おうとしています。これはAIのせいではありません。これは単なる加速であって、彼らのビジネスプロセスがその新しいペースに対応する準備ができていない、というだけの話です。私が個人的に定義する「アジャイル」とは、「時間内に対応できること」です。彼らは、この新しいペースに対応するだけの準備ができていません。トラクターを運転していたのに、突然レースカーに乗っているようなものです。車輪はまだあり、エンジンもまだあります。しかし、そのカーブの多い山道で、A地点からB地点へ、どれだけ速く行けるかという点で、あなたのスキルはその車に見合ったものになっているでしょうか。トラクターの運転に慣れていたのに、今やフェラーリに乗っているようなものです。それは車のせいではありません。ただ、これは今後も続いていく傾向だと私は思っていて、対応が間に合わずに失敗していく企業が出てくるでしょう。彼らはこれまで安穏としていて、そのペースの変化に対応する準備ができていなかったのです。別のアナロジーを挙げるなら、これは三行広告を抱えていた新聞のようなものです。三行広告が記者たちの給料を支払い、印刷された紙をすべての家庭に届けるコストを賄っていました。しかし三行広告がなくなると、ジャーナリズムはそれに対応せざるを得なくなり、ある面ではうまく対応しましたが、別の面ではうまくいきませんでした。そして今、私たちは以前よりも地域ジャーナリズムに恵まれない状態になっています。つまり、これまでスイッチングコストに頼って利益を守ってきた人々がいて、そのスイッチングコストがゼロにまで下がってしまうと、彼らの利益もゼロに向かっていきます。そして中には、その変化を生き延びられない人たちも出てくるでしょう。
Kent Beck： 逆の面もあります。あなたが何かのサービスにお金を払っているとして、「自分ならもっと良いものをバイブコーディングできるのでは」と考えるとします。実際にそうしてみたとしても、そこで解決できているのは、問題全体のうちのごく一部にすぎません。
Gergely： それはまさに氷山の一角、ということですね。目に見えている部分だけをバイブコーディングできる、という状態です。
Kent Beck： 私自身の経験からお話ししますが、私はGustoという中小企業向け給与計算のサービスに3年間関わっていました。「Claudeに、これだけの労働時間があって、この時給で、この税区分にいると伝えたら、給与の金額をすべて教えてくれた。もうGustoは要らない」と言う人がいます。しかし、それにはまったく分かっていないことがあるのです。実際に自分で四半期分の給与計算を運用してみてください。それから、様々な州や、自分がここに住んでいて別の州で働いていて、会社の本拠地はまた別の場所にある、といった状況で、各種税務当局に提出しなければならない報告書すべてを把握してみてください。そのとき、給与の金額はどうなるのでしょうか。総支給額、手取り額といったもの以外にも、正しく、法令を遵守した形で給与計算を実行するためには、非常に多くのことが関わってくるのです。ですから、私たちはこれから、こうした落とし穴にはまっていく人たちを目にすることになるでしょう。「氷山の見えている先端の部分だけをバイブコーディングして、残りの氷山を捨ててしまった。そして今、自分がどうすればいいか分からないまま困っている」というような形です。今まで存在すら知らなかった下流の問題にぶつかることになるのです。ですから、こうした「バイブコーディングによる置き換え」を行う側では、こうした無邪気さが露呈していくのを目にすることになるでしょう。
Gergely： では、ソフトウェアエンジニア自身についてはどうでしょうか。多くのエンジニアにとってのアイデンティティは、コードを作り込むこと、技巧を大切にすること、こうした事柄を可視化できること、といったことにありました。そして今、こうしたツールはそのかなりの部分を、本当にうまくこなせるようになってきています。この技術変化を経ても、トップレベルのソフトウェアエンジニアであり続けたいと思う人たちに、どんなアドバイス、どんな心構えの変化を勧めますか。
Kent Beck： 私の心の支えとなっている標語は「誰も知らない」です。人々が私のところに来て、「拡張されたコーディングの世界の中で、TDDはどう当てはまるのか」と聞いてきますが、私は「誰も知らない」と答えます。私が知らないというだけでなく、誰も知らないのです。私がFacebookで学んだ大きな教訓は、プロダクトやソフトウェア開発には3つの異なる「フェーズ」があるということでした。一つは「探索(エクスプロール)」のフェーズで、予測ができないので、いろいろなことを試す必要があります。それから、何かが軌道に乗る瞬間があります。私のキャリアの中から、その例はいくつもお話ししてきました。そして、いったんロケットに火がついてそれに乗って上昇していくときの規律というのは、空間を探索していたときの規律とはまったく別物です。拡張(エクスパンド)しているときには、非常に強く集中する必要があり、それは持続不可能なほどのものになることもありますが、そう長くは続きません。それから、そこから価値を「抽出(エクストラクト)」するフェーズに入り、それが次の探索のための資源となっていきます。これは、私が2016年か2017年頃に考え出したものです。
Kent Beck： 2015年か2016年に、ようやくそれをはっきりと理解できたのです。私は、Facebookがどうやって「大規模であり、成長していて、かつ革新的である」という状態を同時に実現できたのか、その仕組みを理解できたと感じました。それは、プロジェクトをそれぞれの段階に応じて、まったく異なるスタイルで扱っていたからです。「探索」というのは、何かを探しているものの予測ができない段階です。だから、できるだけ安いコストで、できるだけ多くの、互いに相関のない実験を試す必要があります。数を打つゲームなのです。それから「拡張」に入ります。何かが軌道に乗ったら、少しずつあらゆることを試すのではなく、うまくいっている一つのことに集中し、それ以外はすべて捨て、次々と現れる障害を乗り越えていきます。そしてある規模に達すると、成長を予測できるようになり、「新しい国にプロダクトを展開すれば、すでに5か国で実績があるのだから、この手順に従えばいい」というプレイブックを書けるようになります。それが「抽出」のフェーズです。すでに規模の経済を実現しているので、小さな調整でも大きな違いを生みます。そのフェーズには長い寿命もあります。コードの書き方も、プロジェクトの管理の仕方も、誰を何人雇うか、組織構造はどうあるべきか――これらはすべて、この3つのフェーズごとにまったく違ってくるのです。
Kent Beck： 過去20年間、私たちはずっと「抽出」の段階にいました。そこにはプレイブックが存在していました。多少の進化はありましたが、たとえば「本番環境でバグが多すぎる、これが試せる3つのことです」「開発を加速させる必要がある、こういうことができます」というふうに、プレイブックが存在していたのです。ときには人々がそのプレイブックどおりに実行しないこともありましたが、それでもプレイブック自体は存在していました。
Kent Beck： そしてシニアエンジニアであるということは、そのプレイブックを知っている、ということを意味していました。プレイブックを知れば知るほど、より効果的に働けたのです。「バックエンドをどうスケールさせるかも知っている、冪等性(べき等性)についても、それを実装するとどんな利点があるかも知っている」というふうに。しかし今や、誰もそれを知りません。そして、「私は自分がプレイブックを知っている人間だ」というアイデンティティを持っていた人たちは、今、恐怖を感じています。「自分は一体何者なのか」と。ここで分かったのは、プレイブックを書くというスキルと、プレイブックを実行に移すというスキルは、まったく別物だということです。私たちがオブジェクトの時代にやっていたことは、まさにプレイブックを書くことでした。それは、あの曲線でいうところの「探索」の部分だったのです。プレイブックがないからといって、効果的に働く方法がないわけではありません。ただ、それはまったく異なるゲームだ、というだけのことです。プレイブックがないと安心できない人たちは、頭を切り替える必要があります。「誰も知らない」のです。ジニーを使った開発のための秘密のプレイブックがどこかに存在していて、100万ドル払えば手に入る、などということはありません。そんなものは存在しないのです。私たちがそれを垣間見たと思っても、次の週にはもう変わってしまいます。入力へのわずかな変更が、出力に大きな変化を引き起こすからです。ですから、私たちは皆、再び「探索」の段階に戻っているのです。試せる手数が多ければ多いほど良い、という状態です。
Kent Beck： よくこんな質問を受けます。「1テストずつ書くのではなく、まとめて複数のテストを書くべきではないか、と思うのですが、それでうまくいくと思いますか」と。誰も知りません。試してみて、その結果を教えてください、というのが答えです。より多くの人が、コミュニティの中でより多くのことを試し、それを共有していく――「私はこれをやってみた、このマークダウンファイルを追加してみたら、こういう効果があった」と誰かが言い、別の誰かが「私も追加してみたが、状況は悪化した。では、何が違ったのだろう」と対話を始める。そういう会話こそが、結果としてプレイブックを生み出していくことになるのです。
Gergely： アジャイル宣言は2002年でしたね、たしか。
Kent Beck： 2001年です。
Gergely： 2001年ですね。最初のOOPSLAは1986年で、宣言をまとめるまでに15年かかったことになります。だからこそ、私は今日「マニフェスト」というものを見ると、いつも「時期尚早だ」と感じてしまいます。悪いアイデアだというわけではありません。あってもいいと思いますが、まだその時期ではないのです。オブジェクト指向プログラミングという技術的な変化がもたらされてから、その帰結を語れるようになるまでには15年かかりました。この技術を日々使い続けてきた中で、それをどう効果的に使えばよいかをシンプルに表現できるようになるまでに、それだけの時間が必要だったのです。ジニーが登場した今、人々は「新しいマニフェストは何なのか」と聞いてきますが、答えは「まだそのマニフェストの時期ではない」ということです。
Gergely： 最後の話題として、AIエージェント、ジニー、こうしたあらゆる変化を前にして、この「まっさらな状態」の中で、Kentは今、何を楽しみにしていますか。何がKentにエネルギーを与えているのでしょうか。
Kent Beck： これはまさに私にとってのホームベースです。プレイブックを書くこと――私はそれを心から愛しています。私は「木を揺する人」であって、「ゼリーを作る人」ではありません。何かを立ち上げること、木を揺すぶることが大好きなのです。
10. Kentの人間性と現在地
10.1 特性とコミュニケーション術
Kent Beck： 私は自分のことを、感情の制御スキルにあまり恵まれていない人間だと思っています。生まれつきの共感力も持ち合わせていません。私たちのようなタイプの人間は、しばしば他の人が簡単には受け止められないほど直接的な物言いをしてしまいます。私はただ真実を言っているだけだ、あるいはただ質問をしているだけだと思っているのですが、そうした言い方自体が、相手にとってはある種の攻撃的な行為として受け止められてしまうことがあります。私自身はそれに気づいていないのですが、それが人々の反応の仕方なのです。だからこそ、共感を学ぶこと、ボディランゲージを読み取る学び方を身につけること、声のトーンを読み取る学び方を身につけることが必要になります。これらは私にとって生まれつきのスキルではありませんが、それでも学習可能なスキルではあります。私は決して、社会的な天才である私のパートナーほどには上手にはなれないでしょうが、それでもひどい状態ではなくなることはできます。「攻撃的であること」は、私のようなタイプの人間にとってよくある社会的戦略であり、私自身もこれまでそういう戦略を取ってきました。私は、感情を読み取る練習として、ポーカーを打っています。自分に共感力が欠けているときに、それに対するフィードバックを得られるからです。
私たちの間に何か意見の相違があったとき、私がそれを解消するやり方は、例えば「これはどれくらい時間がかかるものなのか」と尋ねることです。4週間かかると私が言い、相手が「いや、2週間でなければならない」と言ったとき、私はそこで縮こまって「分かりました、なんとかやってみます」と言う必要はありませんし、かといって「勝手にしろ」と突き放す必要もありません。そのどちらも助けにはなりません。そうではなく、「分かりました、それではあなたのニーズを理解させてください」と言うのです。私にとって簡単なことではありませんが、それはできることです。私にはちょっとしたチェックリストのようなものがあります。『ターミネーター』の最初の映画で、彼が対応のパターンをプルダウンメニューのように表示するシーンがありますが、まさにあんな感じです。ただ、そのプルダウンメニューの選択肢を持っておくほうが、相手を遠ざけてしまい、対話が終わる前に会話そのものを終わらせてしまうような何かをするよりは、ずっと良いのです。私たちには、他の人が実際に耳を傾けられるようなスタイルでコミュニケーションを取る責任があると思います。だからこそ私は、金融の世界やスポーツ、歴史など、あらゆる場所からアナロジーを持ち込もうとするのです。それは、他の人を理解し、そして自分自身の視点や、それが状況にどう関わってくるのかを、相手が実際に理解できる形で伝えようとする、いわば必死の試みなのです。
10.2 現在の個人プロジェクト
Kent Beck： 私にはとても幅広いプロジェクト群があります。Arloというオブジェクト指向のデータベースのプロジェクトや、いくつかの基本的なデータ構造にも取り組んでいます。自分がまったく知らない言語で、ライブラリ品質と呼べるほどのコードを書けるかどうかを試してみたかったのです。結果として、それはできることが分かりました。あるケースでは、Rustの標準的なB木よりも一部の操作で高速なB+木を、自分自身で構築しました。
Gergely： それはすごいですね。
Kent Beck： ただ、私自身はRustの専門家ではありません。では、本物のRustの専門家なら、同じツールを使って何ができるのだろうか、そしてなぜ彼らはそれを書かなかったのだろうか、と考えます。その答えは分かりません。ただ、自分が関心を持っている物事のために、小さなアプリのかけらをいろいろと組み立てています。ビジネスプランニングにもジニーを使っています。あなたと同じように、私にもニュースレターがあります。あなたのものとは違って、私のニュースレターはかなり小規模なものですが、それでもそれなりに大きくはなっています。
Gergely： うまくいっていますよ。
Kent Beck： 今考えているのは、それをどうやって持続可能なビジネスにしていくか、ということです。そのためにビジネスパートナーも一人雇いました。ですから、たくさんの文章を書いたり、自分の経験を振り返ったりもしています。あらゆることを試しています。もし私がやっていることに何か秘訣があるとすれば、それは「一からやり直すことを恐れない」ということです。
Gergely： そしてKentのキャリア全体が、ごく初期の頃からこの姿勢を示していますね。TDD、XP、3xモデル、Tidy First、そしてジニー、というふうに。
Kent Beck： ええ、私のGitHubを見ていただければ、project、project2、project3、project4、new project、new project2、new project3、new project……という具合に並んでいるのが分かるはずです。あるところまで押し進めて、ジニーがそれ以上の選択肢を使い果たし、それ以上先に進めなくなったら、私はそれを消して最初からやり直します。微調整をしようとはせず、一からやり直して、「別の順序で実装したらどうなるか」「このマークダウンファイルを使って実装したらどうなるか」「このコミットフックを使って実装したらどうなるか」というふうに考えるのです。私たちは集団として、あらゆることを試してみる必要があります。その中には、馬鹿げて聞こえるアイデアがうまくいくこともありますし、逆に馬鹿げて聞こえるアイデアが実際に大失敗に終わることもあります。しかし、私たちがいつでも一からやり直せるという前提に立っているなら、それは大した問題にはなりません。実際には、それほど大きなリスクを負っているわけではないのです。この創造的な衝動こそが、ジニーの登場によって私の中に戻ってきたものです。「Go言語でB+木を実装したらどうなるだろう」「B+木の代替案として、この適応型基数木(アダプティブ・ラディックス・ツリー)はどんな見た目になるだろう」――そういうことを、私は今、実際に確かめることができます。ジニーと向き合って座り、実際にそれを解き明かすことができるのです。そしてそこには、それまで存在しなかった、何らかの成果物が生まれます。それは私の想像力と、私自身の作業によって生まれたものです。
Kent Beck： かつての私は、プログラミングの細々とした煩わしさに、うんざりしていました。「そのためには、このアップグレードのバージョン7.1が必要で、それが別の何かを壊してしまい、それがまた別の何かを壊してしまい、結局バージョン7.1を使えなくなる」というような話に、私は本当にうんざりしていました。あるアイデアを思いつき、それに感情的に投資し、ある程度まで進んだところで、何の意味もない理由でこれ以上先に進めないと気づく――それが私は嫌でたまらなかったのです。そして、そうした行き詰まりが、今の私にはもう起こりません。それはもう、まさに天国のような状態です。私には40年分ものアイデアがあります。「これは面白そうだ」「でも、これは大きすぎる」といったアイデアが、今、また現実的な選択肢として戻ってきています。そして私は今、実際に形あるものを作り出すことに、本当に大きな喜びを感じています。
Gergely： その様子は伝わってきます。そして、それをこうして共有してくださっていますね、Kent。今日は本当に素晴らしい時間でした。特に、こうして実際にお会いしてお話しできたことがとても良かったです。
Kent Beck： ええ、素晴らしい時間でした。あなたの故郷で、こうして腰を落ち着けて話せたことをとても嬉しく思います。ここに来られて良かったです。
10.3 クロージング
Gergely： 今回は、私にとって特別なエピソードでした。ハンガリーのブダペストで、Craft Conference 2026の直前に収録したものです。Kentがこれまでポッドキャストで一度もしたことのないような形で、キャリアの始まりから現在までを丁寧に語ってくれるのを聞けたのは、初めてのことでした。私が心に残っているのは、Kentが「私たちは、信頼が蓄積される速度よりも速くコードを蓄積している」と語った言葉です。Kentは、こうした真実を要約するのが本当に上手だと思います。ある領域を理解しようと苦労し、それをコードとして表現し、自分が本当に理解していたことを証明するテストを書いたとき、人は自分のプログラムを信頼できるようになります。そして、それを他の人たちと一緒に行うことで、その人たちとの信頼も築かれていくのです。Kentが指摘しているのは、AIに――彼の言葉で言えば「ジニー」に――プロンプトを投げて、動くコードが返ってきて、AIが「これで完成です」と言うだけでは、こうしたことは何一つ起こらない、ということです。
私が印象的だったのは、Kentが50年にわたって驚くほど一貫している、という点です。Smalltalkであれ、デザインパターンであれ、TDDであれ、今日のAIであれ、その本能は変わっていません。「馬鹿げたアイデアを試してみること、そしてそれをすべて捨てて一からやり直すことを恐れないこと」です。Kent自身の言葉を借りれば、彼は「ゼリーを作る人ではなく、木を揺する人」であり、その「木を揺する」という衝動は、今まさにAIに対して馬鹿げたことを試してみる、という形で戻ってきています。
最後に、Kentがどれだけ地に足のついた人物であるかということにも、感銘を受けました。人々はKentに、AI開発時代のための新しい「マニフェスト」は何かとしきりに尋ねますが、彼の答えは「それはまだ時期尚早だ」というものです。アジャイル宣言がまとまるまでには、オブジェクト指向プログラミングの実践を15年積み重ねる必要があり、それによってKentのような人物がようやく教訓をまとめられるようになったのです。AIをめぐる状況は今なお急速に変化し続けており、Kentは、今の時点では何がうまくいくのか誰にも分かっていない、ということを正直に認めています。