前置き
「テスト駆動開発」で有名な t_wada さんこと和田卓人さんが基調講演をするという事で、
- Forkwell さん
- Autifyさん
主催のイベントに参加してきました。
t_wada さんと言えば、あのライオンのアスキーアートで有名ですね。
（引用：「テスト書いてないとかお前それ〜」が私の代名詞になるまで。テスト駆動開発とともに歩んだキャリア）
その基調講演と Q&A セッションで聞いた話がとても勉強になる話だったので、皆さんにもお伝えしたくここに書いていきます。
- 基調講演：和田 卓人 氏（@t_wada）
- モデレーター：末村 拓也 氏（@tsueeemura）
- パネリスト：近澤 良 氏（@chikathreesix）
-> アーカイブ動画はこちら
概要
t_wada さん基調講演
これは20分という時間だったため、以下スライドをかいつまんでお話ししていました。
「これをちゃんと話すと100分かかっちゃうので」
と3回ぐらい言っていたのが印象的でした。
（なのでスライド見てほしいという事なのかと...）
詳しくは上のスライドを見てもらえると良いと思いますが、要するに以下だと理解しました。
- 多くの PJ は質を犠牲にしてスピードを優先しがち
- その結果得られるメリットは短期的なものであり、中・長期的には逆効果となって致命傷となる
- スピードを犠牲にすれば質が上がるかと言ったらそうではない。 質とスピードはトレードオフではない。
質とスピードはトレードオフではない、どちらを犠牲にしてどちらを高めるという発想が間違っているという事です。どちらも高めていく取り組みが結果として高いパフォーマンスを発揮できるようになります。
- 2021年の調査におけるエリートクラスタとローパフォーマークラスタの差
これは去年の最新情報で、エリートとローパフォーマーの違いは年々広がってきているという事を表しています。
その上で保守性に投資した投資対効果は数年後とかではなく、ほとんどの場合1ヶ月以内に現れるとの事です。
- キャディ株式会社様の事例
実際に t_wada さんの講演を聞いて Sprint 内の2-3割を保守性に投資した結果、最初はベロシティが落ちたが1~2ヶ月経った後にデリバリー速度が高まった事例もありました。
基調講演の感想・まとめ
「バグがないようにデプロイをする」 事も大事ですが、それ以上に大事なのは 「不具合が見つかった時にすぐに治す体制がとても大事」 であるという 意見は印象的でした。
安全なデプロイも大事だがデリバリーパフォーマンスがそのまま企業の業績に因果関係があることを考えると、それだけに注力してしまう世界も結果的には業績を落としてしまう事につながってしまうという事。
FT などを活用した高速なロールバックなどなどでデリバリーパフォーマンスを上げていきましょうというお話しでした。
Q＆A・パネルトーク
Chikazawa さん、Suemura さん、t_wada さんが視聴者からのQ&Aを拾って答えていくコーナー。
- Q1
必要ではあるが増えすぎたテストへの対応方法を教えていただきたいです。（実行に1日かかる等々）
- A1
この質問に対しては御三方各々いろんな意見がありましたがまとめると以下です。
- パラレルを導入（札束で殴る！というワードがここで登場）
- おそらく
E2Eが多すぎて、ユニットテストが少ない構造なのでは。なのでテストピラミッドを意識しよう。 - Google の事例では、テスト結果を一件一件 DB に入れて、それをデータエンジニアリングして最も有効なテスト順番や優先順位を考えてテストを間引くという手法。
- テストごとにサイズやタイプなどでタグをつけて、タグでフィルタリングしてテスト実行を考える
この回答から E2E テストについての話が広がります。
-
E2Eはユニットテストと同じ感覚で作ったらダメだよね- ケースは少なくて、中にガッツリ長く書いて良い
- ユニットテストはその逆
- 中身がガッツリ書かれてるユニットは論外
テストの網羅性の話になり、t_wada さんからツリー形式の大事さについての話。
- 大事なのはテストのカバレッジじゃなくて、仕様のカバレッジ
- テスト結果をツリー構造にして、それを仕様と比較して網羅できているかを考えよう
- そしてテスト結果のツリーを仕様書と考えよう
- テストが仕様書になっていれば、PR の Descrition にはつらつら文を書かなくても、テストの実行結果ツリーを貼り付けるだけで良い。むしろそうしよう。
- Q2
テストを書かずにプロダクトの開発を進めてしまっており、今からテストを書きたいと考えています。開発の途中からテストを書く場合、どこから手を付ければよいでしょうか。
- A2
レガシーコードはそもそもテストが書きにくい構造になっている、だから構造を変えたいと思いテストを書きたいとなるのだが、ここでジレンマが起きます。
これに対してのアプローチは二つあるとの事です。
戦略1 まずは大外からテストを書いていく
ここでは E2E が活躍します。今動いてる動きを E2E で埋めていき、少しずつテストを書いてコードを担保していく。どうあるべきがわかる人がいなくても、今どう動いてるかをなぞるという事ができるはずだ。これをキャラクタライゼーションテストと呼びます。
そして少しずつコードをリファクタリングして、インテグレーションとユニットのテストを追加していく事を目指します。ここでもテストピラミッドを意識して、最終的には E2E を最小限に減らして理想的なテストの割合を作っていくことを目指していく事は忘れずに。
戦略2 テストがないことを承知の上で穴を開けやすい所からプロダクトコードに手をつけていく
これはそのままの通りで、まずは穴を開けやすい場所からリファクタリングをし、その部分からテストを書き始めること！
ここでおすすめの書籍がレガシーコード改善ガイド
- Q3
スケジュール優先でテストをおろそかにする人に対し、能動的にテストを書いてもらうアプローチに悩んでいます。導入できていない・予定も立たない E2E テストに思いを馳せるだけで現実は変わらない状態をどうすれば良いでしょうか。
- A3
「テストを書き慣れてる人はテストを書きながらやることが早いことを知ってる」
だからそうじゃない人はそれを知らないだけなので、わからないなりにテストを書ける状況を作る事が有効なアプローチ。
- 一番良いのは真似をしてもらう。つまり背中を見せて自分自身が真似してもらう人になろう
- そしてテストがある生活の快適さを知ってもらう
- 社内チュートリアルとかがあるのも大事
ここでテストコードのメンテナンスに悩む日が来るが、それは第二のゴール。
まずはテストを書こう。
- Q4
テスト文化を社内で広めるにあたって、ソフトウェアテストをテーマに勉強会を社内で開く予定です。自分の経験が浅いこともあり、本屋をめぐってみてもどれが良いのかいまいち決めかねています。勉強会に最適な本などあれば、ご教授お願い致します
- A4
Suemuraさんおすすめ
t_wadaさんおすすめ
- 入門（読書会ならこれが良い）：初めての自動テスト Webシステムのための自動テスト基礎
- 手を動かす系：ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～
- テスト技法についての話：ソフトウェアテスト技法ドリル テスト設計の考え方と実際
- Q5
既にコードは崩壊していて（過去のスキル不足、ドメイン変更への未対応等）、ただビジネス的には「だらだら」継続しており、低予算の範囲内で「ビジネス的な爆発的成長」を求められた場合に、クリーン化（のための予算確保）を説得する方法が思いつかないです。どのようなケーススタディがあり得ますでしょうか
- A5
相手にわかる語彙で伝わる話し方をするしかない。つまり語彙を手に入れて、相手に伝わる翻訳をしよう
→ おすすめ書籍：エンジニア組織論への招待
- Q6
「この会社（もしくは人）の文化はよかった」みたいなものがあったら知りたいです
- A6
- 株式会社VOYAGE GROUP(現株式会社CARTA HOLDINGS)
- 理由としては「みんなオーナーシップを持っている」
- 事業をエンジニアリングする技術者たち
- サイボウズ
- 理由としては「今までの意思決定の履歴を全てハイパーリンクで遡れる」
感想
テストを書きます。
そしてただ書くだけではなく、どういうテストを書くかをテストピラミッドを意識して書いていくこと。そのテスト結果が仕様書となるようなテストケースの書き方をすること。
まずはチーム内で TDD を実践して行って、いずれラクマ全体に良さを（TDDが良ければ）布教していきます。
おまけ
私の座右の銘
以上です。