「Qiita × Uzabase Tech Meetup#1 〜 TDDカルチャーの未来」 を視聴しました
「Qiita × Uzabase Tech Meetup#1 - connpass」 を視聴したので、感想をつらつらと。
企業にテスト文化を根付かせる戦略
お目当ての講演。内容もそうだけど単純にプレゼンも上手かった。淀みなく聞き入ってしまった。
４つのキーメトリクス
これからの時代に求められる開発のメトリクスとして、以下の４つを説明してた。
- リードタイム
- コードが書かれてからリリースされるまでの時間。
- デプロイ頻度
- デプロイされる頻度。（週１回とか）
- MTTR（Mean Time To Repair, 平均修復時間）
- バグが発生してから修復が完了するまでの時間の平均値。
- 従来はMTBF（Mean Time Between Failure、平均故障時間、ソフトウェアの場合はバグの個数）が用いられていた
- 変更失敗率
- デプロイに失敗した（ロールバックされた）割合。
「リードタイム」と「デプロイ頻度」がスピードを表す指標。
「MTTR」と「変更失敗率」が品質を表す指標。
MTTRとかMTBFってハードウェアの指標かと思ってたけど、ソフトウェアにも使うのね。
ソフトウェアのバグってユーザ影響の低いバグだと放置されがちだから、レガシーなソフトウェアだととんでもない値になりそう。
実際、昔関わっていたプロジェクトだと10年間くらい放置してバグとかあったし。。。
そして実際に測定した結果が以下らしい。(2019年の調査)
| エリート | ハイパフォーマー | ミディアム パフォーマー |
ローパフォーマー | |
|---|---|---|---|---|
| リードタイム | 1日未満 | 1日から1週間 | 1週間から1ヶ月 | 1ヶ月から6ヶ月 |
| デプロイ頻度 | オンデマンド (1日複数回) |
1日1回から週1回 | 週1回から月1回 | 1ヶ月から6ヶ月 |
| MTTR | 1時間未満 | 1日未満 | 1日未満 | 1週間から1ヶ月 |
| 変更失敗率 | 0 - 15% | 0 - 15% | 0 - 15% | 46 - 60% |
リードタイム毎に組織を分類した結果のメトリクスみたい。
講演でも言ってたけど、開発速度（リードタイム、デプロイ頻度）と品質（MTTR、変更失敗率）はトレードオフの関係ではない、ってとこが面白いな。
（単にスーパープログラマを沢山抱えている組織は開発スピードも早くて品質も良いだけでは？。。。みたいな身も蓋もないことは言わない）
私が以前所属していた組織はまさに「ローパフォーマー」に属するところで、それはSIerでクライアントの了承無しにはデプロイできないから、という言い訳があるものの、結果的にバグは多かったし、リリースの度に緊張感もあった。
Sales Naviでは「ハイパフォーマー」を目標にCI/CD、DevOpsへ投資していきたいな。
バックエンド（Java）側のユニットテストは順調に記述できてるんだけど、フロントエンド（Angular）のユニットテストは全然できていない。猛省。。。
テストを書く時間がない
これはよく聞く話。
「テスト書く時間がない」のではなく「テスト書かないから時間がない」ってやつ。
よく聞く話といいつつ、やってしまいがち。耳が痛い。。。
テストにコストがかかることの解決方法は、テストをやめることではありません。
うまくなることです。 Sandi Metz
はい。おっしゃる通りです。。。
テストは品質をあげない
講演の最後、とても印象深かった。
- テストは品質をあげない
- 品質が「わかる」ようになる
- わかることこそ大事
- テストを書くだけでは良くはならない
- 体重計に乗るだけでは痩せない
- 品質を上げるのは設計とプログラミング
- 再設計とリファクタリングをテストで支える
CSM研修での「Scrumは問題解決のフレームワークではありません。現状を把握するフレームワークです。」ってのを思い出した。
E2Eの過去・現在・未来
E2Eテスト難しいよね。課題あるよね、って話とSeleniumとかのテストツールの話。
Googleでは全て（UI含む）自動テストしてる、ってとこでマジか！かっけぇ！ってなった。
和田さんの講演と比べて内容が薄くなったのに他意はありません。トイレ行ってただけです。
TDD実践を経て変わったこと
UZABASEのエンジニアさん達がTDDの実践を経てのBefore、Afterを語ってた。
印象的だったのは「テストを先に書くことで作るものが明確になる」ってとこ。
前職ではTDDの実現はできなかったけど、苦し紛れにマニュアルテストで使うテスト仕様書を先に書く、ってのはやってみた。
それだけでも驚くほど品質が上がったし、実践したメンバーも同じ感想を述べていた。
要求仕様だけを元にコーディングを始めるのと、テスト仕様書を書いてからコーディングを始めるのとでは見える景色が違う。
私のいたプロジェクトもそうだったけど、ユニットテストを書きたくても（フレームワーク都合、組織側のDevOpsに対する理解などにより）書けない、っていう状況は確かにある。
ならばせめて後回しにしていたテスト仕様書を先に書くだけでも作業の質が全然変わるから是非やってみて欲しい。
まとめ
TDDへの理解が浅かったな、って反省した。
ちゃんと本読んで勉強しよ、そんで実践しよ、とも思えた。
ユニットテスト書いてりゃ良いんでしょ、ってならないよう気をつけよ。
Fun :)
