マニアが潰したテスト駆動開発〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （５）

和田さんに『テスト駆動開発』の付録Cを書いた動機を聞いてみると、この15年のTDDを取り巻く問題点が浮かび上がってきました。

昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。

対談のこれまでの記事は以下になります。

前回は、「エンジニアの生き生き」とは何かについて話が及びました。今回は、「付録Cはなぜ書かれたのか？」について和田さんにぶつけてみました。

付録Ｃを書いた動機を聞きたい！

家永：個人的には付録Ｃの教義化と意味の希薄化、あそこを書いた動機、何であれを書きたかったのか。和田さんとしてあれを含めたかったのかという動機みたいなのを聞いておきたいなと思って。

和田：「付録Ｃ」は新訳版の『テスト駆動開発』の付録Ｃで、僕が書き下ろした20ページの文章です。書いたきっかけ自体は、これは編集の森田さんが実際に付録みたいな章を本書に付けたいと提案してくださったからで、だから僕のアイデアではないんです。では何で付録を書こうという話になったかというと、一つはこの原書が出てから15年ぐらい経っているので、技術的な詳細は古くなっている所と、古くなってない所があるんですね。

xUnit（テスティングフレームワークの総称）の詳細とかに近づければ近づくほど古さが見える。逆に第一部、第二部、第三部もそうだけど、本質的には全然古くなってないんです。そうすると、章によってはいっぱい訳注を付けるわけなんですね。その訳注がすごい分量になってしまい、訳注をいっぱい付けるぐらいだったら付録にして、結局15年経過した結果の着地点みたいなものを一網打尽にするような付録を書きましょうという話になりました。結果的に大仕事だったんですけど、まずそういうきっかけです。

家永：はい。

和田：教条主義化と意味の希薄化の所は、付録Ｃの「現在編」にあたる部分。テスト駆動開発の付録Ｃは大きくは３部構成になっていて、過去・現在・未来です。

過去編は、この『テスト駆動開発』が出てから実際に現時点（2017年）までに、テスト駆動開発が拡大とか拡張とか誤解とか誤読とか、そういったものを含めて、良い面も悪い面も含めてすごいバブリーだった時期があり、その後、バブルがはじけた時期があった。そういう過大評価と、その過大評価に耐えかねて、テスト駆動開発が自壊していくみたいな15年間を見てきたので、それを努めて客観的な視点でまとめたものです。なので、xUTP(※1)があって、GOOS(※2)があって、BDDがあって、あとはテストとは、テスト駆動開発のテストなのか、そうじゃないのかみたいな議論を全部丸ごと入れて書くことにしました。その結果明らかになったのは、現時点（2017年）におけるテスト駆動開発は抜け殻のようになってしまっていること。

(※1) 『xUnit Test Patterns: Refactoring Test Code』のこと。

(※2) 『Growing Object-Oriented Software, Guided by Tests』のこと。邦訳版は『実践テスト駆動開発』 （翔泳社）

マニアが潰したテスト駆動開発！？

家永：抜け殻？

和田：抜け殻というのは、つまりテスト駆動開発という言葉を聞いて、例えば、今の若いプログラマーがイメージするものというのが、Kent BeckとかSteve FreemanとかNat Pryceがやっていたテスト駆動開発ではないんです。「テスト駆動開発」という名前と「テストコードを書かされる」というところだけ残ってしまった。

家永：ライオン(※3)に怒られる。

(※3) 和田さんがメンテナをしているpower-assert-jsのアイコンが紆余曲折あってライオンに決まったのをきっかけに、「テストを書いてないとライオン（和田さん）に怒られる」と表現したアスキーアートが一部で広まったことに由来する。

和田：そうそう、なぜそうなったかというと、やはり過去に理由があって、こういった過去の経過を経ているから、名前とやっていることずれてしまったなとか、あとは単純に15年たったから、みずみずしさみたいなものが失われて、「いいからテストを書け」みたいな感じになってしまっているとか、そういったところがある。なので現在編として、テスト駆動開発が直面した２つの変化について述べました。一つは先鋭化と教条主義化で、テスト駆動開発自体が自己目的化してしまった件。特にテスト駆動開発のカルトっぽさによって、すごい自己目的化してしまって、テスト駆動開発をやるためにコードを書くとか、テスト駆動開発をやっている事が偉いと思ってしまったりとか、「お前がやっているのはテスト駆動開発じゃない」とか、そういったもの。

家永：プロレスっぽい。

和田：プロレスっぽさとか、何て言うのかな、狭量というか、そういった状況がどうしても起こってしまいがちになってしまう。プロレスの世界の言葉を借りると「全てのジャンルはマニアがつぶす」という。

家永：西村さんがよく言ってた。

和田：そのジャンル自体の広がり自体をマニアがつぶしてしまうとか、教条主義化がつぶしてましうみたいなところがあって、それはすごいもったいないと思うし、くだらないと思っていたので、それをちゃんと書こうと思いました。テスト駆動開発自身を目的にするなという話とか、そういった事が目的化してきた過去というのをちゃんと書こうと思った。それに対してDHH(※4)がそれは違うとブログエントリーに書いたという事件もあったので、相対化しやすいという土壌はできていた。

(※4) デイヴィッド・ハイネマイヤー・ハンソン (David Heinemeier Hansson)氏の略称。「Ruby on Rails」の作者、Basecampの創設者、CTOとしても著名。

DHHはなぜTDDに反旗を翻したのか

天野：事件だったんですね。

和田：事件と言えば事件。DHH、TDDに反旗を翻すという。

家永：結構過激に。ただあの感覚は何かもう。。。

和田：真っ当だと思います。

家永：うちのメンバー、エンジニアの動き見ていると、あの判断はそうなるだろうなあという。

和田：そうなる。付録Ｃにも書いたんだけど、Ruby on Railsという舞台の上で、その文化の衝突は起きるんですよ。テスト駆動開発とかその後のTDDのパラダイムを引っ張っていたのはRubyでした。Rubyは特にプルーフ・オブ・コンセプトを自分で発表するのに向いている、自分の考えを形にして世に問うのに、すごく向いている言語だったというのがあって、Rubyでプロトを作ってからJavaで書きなおすような流れがあった。Rubyでプロトを作って、それをある程度の形にする。Nat Pryce(※5)や、Dan North(※6)もそうしていました。ソフトウェア開発の文化が変革していく土壌にRubyがあり、Rubyという言語の柔らかさとか、メタプログラミングの強さがそういった土壌を支えていました。そのような土壌の上でメタプログラミングの力を全開にしていたのがRuby on Railsでもありました。Rubyで書くとはRuby on Railsでサイトを作るのとほぼ同義、くらいの強さだった。だけど、先鋭化したテスト駆動開発や、例えばクリーンアーキテクチャーのような依存を逆転させて清潔にしたレイヤリングとRuby on Railsの強みは明らかに対立関係にあったんですね。

(※5) GOOSの著者の一人

(※6) BDDを提唱したことで有名

家永：ギャップ。

和田：Ruby on Rails自身は疎結合の設計に対してNoを言っている。密結合にすることによって疎結合な設計以上の開発スピードが生まれる。少なくともスタートアップ企業にとってスピードは本当にクリティカルな力なので、もし密結合の状態でも速く走れるソフトウェアの構造があるのであれば、それはゆっくり安定して継続的に歩いていく疎結合のソフトウェア設計より強いということをRailsはある程度証明していたわけですね。そしていま、その構造のまま大きくなるとすごく大変になるということも証明している。

家永：それでうちのメンバー困ってる。

和田：少なくとも初期の段階での開発スピードは、特にスタートアップビジネスにとっては最もクリティカルなもので、短距離走を速く走るためにRuby on Railsは設計をすごい密結合にすることを選び、それによって様々なスタートアップの足回りになってきたわけです。

だから、そのRailsの強みと、そのRails上できちんときれいな設計をすべきであるという、クリーンアーキテクチャーやモッキストTDDの話は対立しやすい。クリーンアーキテクチャー界隈とロンドン学派のアジャイル界隈は思想的に距離が近いので、どうしてもRails上で疎結合設計でサービスレイヤーを入れるぞみたいな話になりがち。

それとDHHが大事にしている事は、思いきりコンフリクトするので、同じ日のRailsカンファレンスの中で全然違う事を言っている人たちが現れ始めるわけです。

DHHがキーノートでRailsの価値観や強み、設計の率直さ、次に見ている世界の話をしている同じ日に、別のトラックでは別の人が「クリーンRails」みたいな感じでRailsにクリーンアーキテクチャーをインプリメンテーションしたみたいな話をしていると、全然違う事を言っている印象になる。そういう軸がぶれている感じが見えてきて、批判の矛先がRailsが意識的に選択している密結合に向かうことが多いので、（DHHには）結構フラストレーションがたまっていそうだったんですね。

このテストの書き方は良くないとか、この結合度が良くないとか、依存の向きはこういう向きだから良くないみたいな議論が多く、一つのRailsという枠の中で全然違う価値観のコードたちがバラバラの方向を向いているというのはソフトウェアのエコシステムとしては、多様性はあるんだけど、あんまりDHH自体はあまり良い状態だと思ってなさそうでした。

きれいなコードを書くというのはRails上でも自己目的化しがちです。そうじゃなくてRailsはもっと率直に市場やお客さんの求める変化のスピードに適応するコードを書いていこうというフレームワークだから、何か違わないだろうかという話になってくる。

そういう背景があって、DHHが「TDD is Dead」でワンパンチをかましたわけですね。だからテスト駆動開発、およびオブジェクト指向プログラミングの先鋭化と自己目的化 vs DHHという一つのアングルなんです。