セッションテーマはフロントエンド開発テストの「必要性」と「歴史」
古川陽介氏（以下、古川）：さて、次のパネルディスカッションは、「フロントエンド開発テスト最前線」というタイトルで発表していこうかなと思います。
ご登壇いただくのは、タワーズ・クエスト株式会社取締役社長の和田卓人さんです。和田卓人さんはリクルートの技術開発の技術顧問をやっています。
また、株式会社リクルート兼株式会社ニジボックスの倉見洋輔さんもお呼びして、今回は話をしていこうかなと思います。倉見さんに関して言うと、どちらも私の直属のメンバーというかたちで、一緒に働いています。
今、プロダクト開発において、やはりテストというのが開発の生産性などを決める上でもかなり重要な要素になっているかなと思っています。この必要性や歴史を3人で話していけるといいなと思っています。
テスト駆動開発の第一人者・和田卓人氏
古川：じゃあ、もう始めていこうかなと思うんですけど。まず、簡単に自己紹介をお願いしていこうかなと思います。じゃあ、最初に和田さん、お願いいたします。
和田卓人氏（以下、和田）：和田卓人といいます。よろしくお願いします。世の中的には、たぶん「t-wadaさん」と呼ばれていると思います。
リクルートグループの技術顧問を5、6年ぐらいやっていて、古川さんや倉見さんとは、そこでいろいろな技術的な議論とかをやっていた間柄です。
日本には、自動テストを書きながら開発をしていく「テスト駆動開発」という考え方があるのですが、そのテスト駆動開発を「日本でやっていこうな」と言い続けて16年、17年ぐらい経った感じです。例のライオンと一緒にやっています。よろしくお願いします。
古川：ありがとうございます。僕は和田さんの講演だったり資料だったりを、まだ駆け出しの頃に読んでいるので、今こうしてお話しできるのを非常に光栄に思います。
それはそれとして、和田さんと私ではいろいろなところで接点があるというか。まず、今はもう和田さんの代名詞になっているかもしれませんが、「それ、t-wadaの前でも同じこと言えるの？」っていう、「テスト書いてないとかそれお前t_wadaの前でも同じこと言えるの？」っていう有名なアスキーアートを作ったのが私という（笑）。
インターネットミームと化していて、いろいろなところでライオンの顔が和田さんのアイコンとして出てくるんですけど。もし見たことがない人は、1回検索してみるとわかると思います。「t-wada ライオン」で検索すると出てくると思います。そこを最初にミーム化したのが私ということで、それもまた光栄だなと思っています（笑）。
Storybook駆動開発を得意とする倉見洋輔氏
古川：では、次にですね、倉見さんもお願いしていいでしょうか？
倉見洋輔氏（以下、倉見）：倉見洋輔といいます。僕は、TwitterとかGitHubでは「Quramy」という、まぁ、名字そのままですね。たぶん音で聞いたら、知っているかもしれないぐらいのアレです。
先ほど紹介にあったとおり、今は古川さんと同じ株式会社リクルートで、フロントエンドエンジニアというかたちで一緒に働かせてもらっています。
ここにいる経緯というか、何が得意かというところで言うと、リクルートに来る前、ここ5、6年ぐらい前から、例えばビジュアルリグレッションテストとか、Storybook駆動開発とかですね。開発フローの中に見た目を作っていくということを、みんなに負荷をかけることなく取り込むということをやっていくのがけっこう好きで、ずっとそういうのを追いかけているというバックグラウンドがあります。
古川：ありがとうございます。そうですね、一緒に働いていて、もう本当に頼れるメンバーの1人というところではあるんだけど（笑）。
1on1で「よもやま」をすると、他のメンバーとの「よもやま」は、だいたい技術の話半分、キャリアや悩みごとが半分という感じなんですが、倉見さんと話していると、99パーセント技術の話で、1パーセント、「そういえば、これってどうなりました？」だけなので（笑）。正直に言うと、倉見さんと「よもやま」しながら「俺はちゃんと仕事しているんだろうか？」っていつも思っていて（笑）。それがまた1つのカラーなのかもしれないんですけど（笑）。
和田：割り込むと、「よもやま」っていうのはリクルート語だから。
古川：あぁ、そうか。「1on1」（笑）。そうですね、「1on1」。
倉見：リクルート出身者あるあるですね。
古川：そうですね、リクルートの中では、よもやま話をする会議のことを「1on1よもやま」と言うんですけど。本来は1on1か。いずれにせよ、1on1でけっこういろいろ雑談をしているということでした。
今までテストが書かれていなかった理由とは？
古川：じゃあ「フロントエンド開発テスト最前線」ということで、さっそく話していこうかなと思うんですけど。
「そもそも」というところから話していこうかなと思うんですね。そもそもフロントエンドっていう概念自体も、ここ10年ぐらいでできてきた気がしているんですが、テストって、そのへんの経緯があまり書かれてこなかったのかなと、私はちょっと肌感覚としてあります。
今までテストが書かれてこなかったのは、テストそのものはロジックの部分では書かれるけれど、見た目のところ、特にViewのところは基本的には変わり得るもので、例えば、「新しくバナーを追加してほしい」とか「リンクは隠してほしい」とか、そういう細かい要望に応えていこうとすると、どうしても見た目はけっこう変わり、移ろいゆくものになる。
ドメインと呼ばれているビジネスロジックの部分は、基本的には大きくは変わらないけれど、見た目がダイナミックに変わっていくことが求められる段階においては、あまりテストが書かれてこなかったんじゃないかなと思います。
そのへんちょっと、肌感覚的にも歴史的な意味でも、和田さん、いかがでしょう？ このへんの話って、なにか語れるところがありますか？
和田：フロントエンドという観点で言うと、ここで言うテストというのは、テストコードを書いて自動化していく自動テストの観点ですが、量的にも、プロジェクトとしてもやはりあまり書かれてこなかった。
なんであまり書かれてこなかったのかというと、やはり「コスパが悪い」って思われていたんですよね。書いても、すぐに画面変更したら壊れてしまう。画面変更はどんどんやっていきたいのに、壊れたテストのメンテナンスばかりしていて、本質的な開発にあまり時間を使えていないんじゃないかという思いが出てきたり。
あとは実りが少ない。がんばるわりに壊れやすくて、メンテナンスに時間がかかりがちだし、そもそも技術的にフロントエンドの技術って、非同期の度合いが強くて繊細なんですよね。信頼性の低いテストになりやすかった。
テストが失敗した時の理想像は「テストが失敗した＝コードが悪い。だから、原因箇所をすぐに調べて直さなきゃいけない」なんだけど、そうじゃなくて、もう1回実行すると成功しちゃうタイミング依存のテストが多くて、だんだんだんだん治安が悪くなってしまう、メンテナンスされなくなってしまう。
そういうのが多くて、「なんかコスパが悪いな」というのが強い印象になってしまった。まぁ、Viewは生ものだし、都度目で確認すればいいよという時代がずっと続いていたというのがあったと思いますね。
古川：そうですね。いわゆるテストの1つの観点としては、将来バグが起きた時のための投資というか、いったんここに工数かけてカバーするためのコードを作っておく。その上で、（エラーを）見つけられたらその投資が成功してリターンがあるという話だし、将来の不具合を防げたということになるので、そこはよかったとなると思うんですけど。
テストそのもの自体が、ある時は成功して、ある時は失敗してとなってしまうと、やはりどうしても、投資対効果の薄いものになってしまいがちになるというお話だったかなと思いました。
（次回へつづく）
