目まぐるしくビジネスの環境が変わる中、IT技術がビジネスにおける成功と切っても切れない関係になっています。迅速かつ品質の高い製品・サービスを開発し続けていくために、テスト駆動開発（以下、TDD）の重要性が今まで以上に高まっているといえるでしょう。

こうした中、経済情報プラットフォーム「SPEEDA」を始めとする経済情報に特化した複数のサービスを運営する株式会社ユーザベース（以下、ユーザベース）と「Qiita × Uzabase Tech Meetup」を共同開催しました。

第1回目となる今回は「TDDカルチャーの未来」をテーマとして、ゲストにTDDに知見のある和田卓人氏やユーザベースでB2B SaaS事業の執行役員CTOを務める林尚之氏が登壇。TDDの方法・ノウハウをユーザベース社での事例と合わせて、講演・パネルディスカッションが展開されました。今回はその模様をダイジェストでお伝えします。

イベントアーカイブ動画を見る

プロフィール

和田卓人氏 ゲスト講演「企業にテスト文化を根付かせる戦略」

「Tech Meetup #1　TDDカルチャーの未来」は、タワーズ・クエスト株式会社取締役社長の和田卓人氏による、「企業にテスト文化を根付かせる戦略（2021春バージョン）」と題する講演から開始されました。

ITは事業のコアになった

まず和田氏は、長沢智治氏による図解を引用し、ビジネス環境の前提を整理しました。1990年ではビジネスにおいてITがあると便利という程度の認識だったものが、年を経るとともに有効なもの、不可欠なものへと変化し、現在ではITは事業のコアとして位置付けられるに至っています。

ではITがコアになった時代において、今回の主題でもあるテスト自動化の実践は企業のパフォーマンスや業績に対してどのような影響を与えるのでしょうか。和田氏は『LeanとDevOpsの科学』という書籍から、その解を示唆しました。

『LeanとDevOpsの科学』ではテストやデプロイの自動化といった技術がデプロイ負荷の軽減や修正作業を減少させ、最終的に企業のパフォーマンスに結びつくことが実証されているのです。

変わる世界：4つのキーメトリクス

企業のパフォーマンスは具体的にどんな数値で測られるのでしょうか。ここで重要になるのが、リードタイム、デプロイ頻度、MTTR（平均修復時間）、変更失敗率の4つの指標です。

2016年から2019年にかけて行われた約3万件のアンケート調査の結果から、企業をエリート、ハイパフォーマー、ミディアムパフォーマー、ローパフォーマーの4つのクラスタに分類しています。

それぞれの違いは図表の通りで、分類ごとの差が大きいこともさることながら、スピードと質がトレードオフの関係であるという従来の認識が覆されていると指摘しました。例えば2019年時点においては、エリートとローパフォーマーの間にはリードタイムは106倍、デプロイ頻度は208倍、MTRは2604倍、変更失敗率は7倍もの差が開いており、エリートではスピートと品質の両方が備わっているのです。

この圧倒的な差は、テスト自動化などが関わる継続的デリバリーへいかに投資するのかという差から生まれます。つまり、テスト自動化はコスト削減ではなく、企業の競争力強化という視点で捉えなければならないことを和田氏は強調しました。

テスト文化の浸透を妨げる2つのならわし

こうしたデータからテストの自動化の重要性は認識されているものの、まだまだ企業にテスト文化が根付いているとは言い難い状況です。和田氏はこうした背景にあるものとして、企業や個人の認識に存在する2つの“ならわし”を提示しました。

その1つ目が“テストを書く時間はない”という認識です。スケジュールなどでストレスがかかるとテストの実施頻度が下がり、現状を把握できないため余計に負荷がかかってテストを行わなくなるという悪循環に陥ります。

しかし、「テストを書く時間がないのではなく、テストを書かないから時間がなくなる」のであって、本来的にはテストの実施と時間の確保は因果関係が逆です。できる範囲でテストを書いていけば、確認作業が減って負荷も軽減し、テストの範囲も広げられるという好循環を生むことができるのです。

2つ目が“動くコードに触れるな”というならわしで、かつては環境や言語も安定しておりメンテナンスフリーなソフトウェアがもてはやされました。しかし、ネットワーク環境や言語トレンドが目まぐるしく変わる中で、「何もしていないから壊れる」時代へと変化しています。

こうした環境にあっては、積極的かつ自信を持って修正できるソフトウェアこそ価値が高いという発想へ転換しました。そこで重要になるのがテストの自動化であることを改めて和田氏は主張しました。

テスト文化を根付かせるための実践

では、組織にテスト文化を根付かせるためには何をすべきでしょうか。和田氏は有効な手段として3つの方法を紹介しました。

1つは日本人の特性を考慮した声かけで文化を変える方法です。『世界の日本人ジョーク集』を引き合いに、日本人を動かすには「みんながやっている」ことをアピールすることで、変化に対しても受け入れのハードルを下げることができます。

続いての方法は評価を反転させることで、行動する理由ではなく行動しない理由を問うという手法です。これは河野行政改革担当大臣が行政手続きの中で押印の不要化を進める際に、判子を廃止できない理由を説明させたことが好例でしょう。

最後はデータを示すことで理論武装し、組織にはびこる前例主義と立ち向かう手法です。すでに手動で4回テストを行うと自動化するよりもコストが高くつくことや、テストを書くなどの内部投資は1ヵ月以内に効果が表れるといったことが実証されています。

テストは品質を上げない

最後に和田氏は、テストを実行するだけでは品質は向上しないという重要な指摘を強調しました。体重計を買っただけではダイエットにはなりませんが、体重を把握することから改善への1歩が進みます。

それと同様に、テストを実行しただけでは品質の良し悪しがわかったとしても、品質までは向上しません。品質を高めるためには設計とプログラミングが必要になり、再設計やリファクタリングを支えるのがテストという位置付けであることを改めて強調し、和田氏は講演を締めくくりました。

林尚之氏　技術講演①「E2Eの過去・現在・未来　そしてE2Eにおいて重要なこと」

続いての講演は、ユーザベースでB2B SaaS事業執行役員CTOを務める林尚之氏による「E2Eの過去・現在・未来　そしてE2Eにおいて重要なこと」です。

E2Eの発展の歴史と課題

林氏はこの講演をE2Eの過去について整理することから始めました。2000年代に登場したSeleniumやDBUnitなどによって、Ｗebアプリケーションの分野においてE2Eテストの技術が知れ渡るようになりました。こうした新しい技術が登場したものの、E2Eには技術習得コストやメンテナンスコストがかかるという点で課題が存在していたことを林氏は指摘しました。

具体的な課題として挙げたのが、Ajaxなどの非同期処理に対するブラウザ上での画面テスト、夕方になるとともに画面が切り替わるなど時間経過によるシステム状態変化に対するテストを実行することの困難さです。また、DBのアサーションに関しては、外部キーの制約によるデータの作成や大量のデータのアサ―ションなどについて課題がありました。あるいはテストの実行時間が長いことに加え、問題が発生した際に復旧させるまでのフィードバックも時間がかかる上に、そもそもテスト環境を準備するのが困難だったことも挙げられました。

プロダクトの発展とE2Eの現在

こうした課題がある中で、E2Eはどのように発展を遂げていったのでしょうか。そもそも2010年ごろからプロダクトの側にも変化が訪れていました。例えば、全文検索エンジンの登場やスマホの浸透によってデバイスが多様化したこと、その中でもマイクロサービス化していることから、内部構造が複雑化していることを林氏は指摘しました。

E2Eサイドでは2018年にWeb DriverがW3C勧告になったことや、機械学習やディープラーニングを取り入れてE2Eを高度化させる取り組みが進みました。また、一時中断されていたSelenium関連のサービスも開発が進められたり、Selenium以外のテストフレームワークが普及したりするなど、E2E関連技術も進化を遂げています。

こうしたE2E技術の変化の背景には、和田氏の講演にもあったようにビジネスのスピードが競争力を生む環境にあるでしょう。事業を成功させるには継続的に品質の高いサービスを迅速にリリースする必要があり、そのためにテストを自動化させていくという関心が高まっていることを林氏は強調しました。

ちなみにGoogleのCI／CD責任者（当時）であったJohn Micco氏は、2018年時点で同社では全てのテストを自動化していることを明かしており、世界的な企業でも品質の担保をするものとして自動化テストを認識していたことがうかがえます。

これらビジネスサイドからはもちろん、資金を出す投資家もE2E関連サービスへの関心を高めていることが林氏から示唆されました。創業間もないWebE2Eテストフレームワーク開発会社が、ここ数年で数十億円規模での資金調達を繰り返すことができているのです。

これからのビジネスにとっても重要性が増すE2Eの未来

E2Eの今後に関しては、林氏はますますその重要性が高まるとの見通しを明らかにしました。なぜなら、現在のようなビジネスの変化が激しい環境は今後も変わらないため、いっそう迅速なリリースへ対応しなければないないからです。

またTDDに関しても、2000年台にはユニットテストの必要性を感じる人も多くはありませんでしたが、現在では少なくともそれを否定する意見は業界内でも聞かれないでしょう。こうしたことから、E2Eはユニットテストの10年程度後を進んでいるため、時間をかけて浸透していくとの展望があることを林氏は示しました。

E2Eにおいて重要なこと

E2Eに十数年向き合ってきた林氏は、E2Eにおいて最も重要だと感じることはTDDの考え方だとしました。TDDの中でもキーとなるのが、テストの独立性やアサートファースト、アサーションの数やテストダブルといった考え方です。これらを正しく理解し実践しなければ、もろく壊れやすいE2Eテストになってしまいます。

そうならないためには、良いユニットテストを書けるようにスキルを磨くことや、小さく始めることで常にグリーンな状態を保つという強い意志を持つことが、E2Eにおいて重要であると指摘しました。

最後に林氏は、プロダクトの複雑性が増してきている中でE2E技術も進化もしている点や、投資家のレベルでも関心興味が高まってきている現状において、E2Eの中で大切になるのがTDDの考え方であることをまとめました。

鈴木謙士氏×橘内孝幸氏　技術講演②「TDD実践を経て変わったこと」

3つ目の講演は、株式会社ユーザベースでSaaS Product Division ソフトウェアエンジニアの鈴木謙士氏と橘内孝幸氏による技術講演②「TDD実践を経て変わったこと」です。

まず初めに、TDDが目指すゴールとはなんでしょうか。それは「動作するきれいなコード」であると橘内氏は定義しました。これを目指す中で実際の設計や実装に起きた変化、価値観、行動の変化、プログラミング以外の変化を紹介してくれました。

TDDの実践を通して設計に起きた変化

TDDを実践することによって設計に起きた変化として、テスト容易性を測るテスタビリティという指標が誕生したこと、「しくじり」に気づくタイミングの違いを挙げました。

橘内氏によればテスタビリティが誕生する前は、設計の良し悪しの判断があくまでも自己満足の域を出ていなかったとしました。しかしこの指標を使うことで、テストがしやすいかどうかで設計の議論が進み、テストしにくければ設計を見直すきっかけをつくることができるようになったのです。

また従来であれば、コードの必要性や他商品との組み合わせ、使いやすさなどについて、実際に使われる段階になって初めて失敗していることに気づいていました。しかし、TDDを実践する中で、テスト段階で「しくじり」に気づくことができるようになったと鈴木氏は語ります。

組み合わせも含めてテストから実装を繰り返すため、そもそも使わないコードを書くことや、後から組み合わせられなかったと気づくことが発生しないのです。また鈴木氏は、テストが簡単に書けないということは、そもそも設計が良くないことが実装前にわかるようになったとしました。

TDDによって実装においても変化が

続いて、実装の仕方についても鈴木氏から訪れた変化を紹介されました。当初は完成形を目指して実装し、コードを書き終えてからテストを書くという手順で進んでいました。つまり、実装が正しいことを検証するためのテストになっていたのです。

そのため、テストが複雑になって余計な検証が増えたり、必要以上に実装していたりすることを許容するようになっていたと鈴木氏は明かしました。また、すでに実装段階に入っていると、今さら設計を見直すという発想にはならず、コードが複雑なままでも許容していたといいます。

それがTDDを実践することで、テストと実装を小さく繰り返すようになり、徐々にコードを育てていく方針へと変わっていきました。先にテストを書くことで仕様や期待値、検証内容を集中的に考えられ、違和感があればすぐ対処できたからです。結果として、設計やテス全体の改善につながったと、TDDの有効性を強調しました。

テスト・実装に対する価値観、行動の変化

TDDの実践から実装や設計には良い変化がもたらされたのが確認できましたが、テストや実装に対する価値観や行動は何か変わったのでしょうか。橘内氏はTDDを実践する以前は、そもそもテストをそこまで重要視しておらず、実装のおまけ程度の認識でしかなかったことを正直に語ってくれました。それがTDDの手法を使うことで、実装はテストをグリーンにするために存在するという見方へと逆転したといいます。

また、テストに対する見方だけではなく、実際にコードを書く上でも変化があり、橘内氏が個人的に新しい言語を勉強する際にも、まず検証するコードから書くようになったそうです。そのコードを書く目的や状態を明確にしてからの方がコードも書きやすいと感じるようになったからです。

プログラミング以外の変化

TDDの実践は鈴木氏の中で、プログラミング以外の仕事の進め方にも影響があったといいます。以前はできるところまで進めて、最後に失敗したことに気づいていたのが、全体のゴールは見据えつつ小さなゴールを定めて進めることが多くなったのです。

実際のプロジェクトもそうですが、たいていのことは想定通り進まないですし、実際やってみるまでは不確定な要素が多いのは納得できるところではないでしょうか。しかし、フィードバックループを短いスパンで実施することで、早期に改善につなげられるようになったのです。つまり、TDDの考え方が仕事の進め方全体に対しても応用が利くことを示唆しています。

また、橘内氏は安心して仕事に臨めるようになったことを明かしてくれました。それまでは、自分が書いたコードが不具合を起こしてないかと不安に駆られ、動作確認を必要以上にしていました。

それが、デプロイされるものはテストをくぐり抜けたものである認識が生まれ、安心感を持って開発ができるため、仕事に対する自信にもつながったといいます。むしろ、現在ではテストがないと正しいコードでも不安になってしまうほどになったようです。

TDDを通して、設計や実装に対する価値観に影響があったのみならず、仕事の進め方などについてもTDDの考え方を取り入れることができるようになったことをまとめて、技術講演②が終了しました。

和田卓人氏×林尚之氏／Qitta PM　パネルディスカッション

最後に、和田氏と林氏によるパネルディスカッションが展開されました。モデレーターはQiita PMの清野が務めました。最初のディスカッションのテーマは「TDD文化のリアルな現状について」です。

【トークテーマ】TDD文化のリアルな現状について

これまでの講演の中でもTDDの重要性は明らかになりましたが、実際の現場レベルではどのように浸透しているのでしょうか。さまざまな企業を見てこられた和田氏から現場レベルの実情について語られました。

前提として、TDDはテストファーストに書く狭義のものと、テストコードを先に書くことにはこだわらず1人のプログラマが自動テストを含めて開発する広義のものに分かれると和田氏は見ています。

狭義のTDDをしている人はそこまで多くはないですが、広義のものを含めるとこの15年ほどでずいぶん浸透したという実感が和田氏にはあるとのことです。また、和田氏自身は狭義のTDDにこだわる必要はないと考えおり、分野によっては先にテストが書きにくい場合も当然あることを指摘しました。

ただし、実装とテストの時期が近いことは重要であることは強調し、やはり実装の1ヵ月後にテストしようにも他のプログラマが使用している可能性もあって改善できない場合もあります。

また、TDDはチームや組織レベルのスキルではなく、あくまでも個人のスキルです。その意味では、テストから先に書くことに苦手意識を持っている人はまだまだ多いとしています。とはいえ、テストを書く人が増えていることで、自信を持って不具合を修正できる企業も増加していることは重要な視点だとしました。

【トークテーマ】企業の規模やステージによる違いはどのように捉えるべきですか？

創業間もないスタートアップにおいては、いかに早く製品を市場に出すかが求められるのでテストが後回しになってしまうことはないのでしょうか。パネルディスカッションに参加している林氏から和田氏に対して、こうした質問が投げかけられました。

それに対して和田氏は、確かにスタートアップの場合はテストを書く時間もないケースはあり得ると共感を示していました。しかし、事業が軌道に乗り始めてからテストを書こうにも、それは書かれたコードのテスタビリティにも依存します。そのため開発段階で、プログラマがテスタビリティを意識していることが重要であることを強調しました。

また、聴講者からも類似の質問が寄せられており、和田氏が紹介した著書の中で、企業間の４つの指標の差はシステムの種類や企業の規模などによって左右されないのかという点が問われました。

この点について、4つの指標が高い数値を出している企業は、システムのタイプや規模などによって有意な差があるとは言えなかったと明らかにしました。また、開発を外注している企業よりも内製化している方が、4つの指標において高い値を出す傾向があるようです。

【トークテーマ】個人・組織の開発現場にTDDを導入するためには

続いて「個人・組織の開発現場にTDDを導入するためには」にというトークテーマに移りました。まずはモデレーターの清野氏から林氏に対してユーザベースでTDDが導入された経緯について聞かれました。

林氏はTDD導入の経緯について、ユーザベースに加わり現場を指揮する立場になった当初から、自身のトップダウンによってTDDを推し進めたわけではないことを明かしました。そもそも、入社当初は現場レベルでTDDは実践されていませんでした。

林氏はこれまでの経験からTDDの有用性については確信があったものの、入社間もない時期には実績をつくって信頼を得ることに徹したといいます。そこから、プロジェクトについて相談を受けた際などにTDDを勧めることで、チーム内にもその意義が認識されて少しずつ浸透していったと、これまでの経緯を振り返りました。

この点については和田氏も同様に、TDDはあくまでも個人のスキルなので、自分ができるようになってから周囲に広げていくことが重要であるとしました。チームに根付かせるために考えられるケースとしては、自分が書いたテストを同僚にも共有し、テストを書いた方が役に立つことを実感してもらうことです。それが例え1人ずつでもチーム内に伝播していけば、自然とTDD文化は浸透していくとしました。

【トークテーマ】テストを書いた後に改善につなげるためのコツはありますか？

パネルディスカッションの最後に、聴講者から「テストを書くことまではできるがリファクタリングにまではつながっていないため、そのためのコツがあれば教えてほしい」との質問が寄せられました。

この質問に対しては和田氏から、目標の設定を誤っている可能性があり、指標をデータとして蓄積して可視化することが重要であると指摘されました。

テストを書くことはゴールではなく、あくまでも内部品質の向上に主眼を置くべきです。まずは何に問題があるのかについて理解することから始まりますから、内部品質に関するデータを取ることで改善へと道が開けると語りました。

また林氏からは、ある意味で妥協しながら取り組み続けることがリファクタリングにつながると説明されました。自分が思い描く理想形までいきなり改善することができればいいのですが、それは現実的ではありません。

まずは10行のソースコードが8行になるだけでも十分だという気持ちで臨むことで、継続した取り組みにつながります。それが結果として内部品質の向上をもたらすことを林氏は強調しました。

最後に

和田氏は現在のTDDが、一度バブルを迎えた後に再評価されてきていると指摘しました。過大でも過少でもなく評価されることで、プログラマが一般的に使えるツールとして浸透します。そのためにはさらなる啓蒙活動が必要であるとの認識で、今後もその取り組みを続けていきたいとしました。

林氏は自分自身がE2Eの実践を通して、プログラマとしてのスキルが向上したことを実感しているとしました。そして、こうした取り組みを通じて、プログラミングのスキルが高められる文化を根付かせていきたいという展望を語ってくれました。

質疑応答

セッション終了後、和田氏、林氏が参加者からの質問にチャットで回答されました。そこから何点かをご紹介します。

1つ目の質問は、現在、TDDで開発するように言われているのですが、実装よりもテストを書く方がどうしても難しく感じてしまいます。テストをすらすら書きTDDで開発していくためにはどう勉強していくのが良いのでしょうか？というものでした。

これに和田氏は、テストを書くのはスキルなので、最初は難しいため、まずは真似するところから始めてみてくださいと回答されました。自分が手がけている技術に関連するチュートリアルを「写経」していくのがおすすめだと説明されました。

2つ目の質問は、Webアプリ開発のTDDにおいて、「バックエンドに比べフロントエンドはTDDに向かない」という意見も見るのですが、フロントエンドとバックエンドに違いはあるでしょうか？という質問でした。

これに和田氏は、どちらも特有の難しさがあると回答されました。フロントエンドは画面が見えてしまうのと、画面が変更されやすいため、テストコードが陳腐化しやすく、割りに合わないという側面はあると説明されました。
フロントエンドはテストが必要なロジックのテストを書き、あとは Visual Regression Test などでカバーするというのも手であると付け加えられました。

3つ目の質問は、E2Eテストがなく、手動のテストで大変な状況なのですが、マイクロサービス横断のE2Eではなくまずは単一のマイクロサービスを対象にしたE2Eを書くのを目標にしたほうがいいでしょうか。単一のサービスを対象にしたE2Eがあるだけでも手動の画面を操作するテストを減らすことに繋がりますか？というものでした。

これに林氏は、統合テストは、マイクロサービスの辛い部分であると説明されました。もちろんテストを減らす効果はあると解説した上で、大事なことは独立したデプロイ単位でテストを書けることであると回答されました。

イベントアーカイブ動画

編集後記

ビジネスの中でもITがコアになっていることは誰の目にも明らかなことで、こうした環境で競争力を高めていくためにTDDが活用されるべきであるという視点は改めて重要だと感じました。和田氏が紹介する著書の中でも、さまざまなデータを用いてその有効性が証明されていたことが印象的です。

また、ユーザベースの林氏や鈴木氏、橘内氏からの講演でもTDDの重要性が高まっていくという指摘や、実体験としてTDDを取り入れることで生まれたメリットは説得力のあるものでした。本セミナーを通して、開発の際にTDDを取り入れることを検討する機会になったのではないでしょうか。

文：深尾 亮