開発生産性カンファレンスの概要
こんにちは、エンジニアの三田です。
こんにちは、エンジニアの博崎です。
ゆるテクは、三田と博崎が有力技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
というわけで、今日もやっていきたいと思います。
今日持ってきたネタ、ちょっと時間が経ってしまっているんですが。
そうでしたっけ。
6月の29日に行われた開発生産性カンファレンス2024というのがありまして、
それの登壇資料とかがもろもろたくさんまとまって出てきているので、
その辺の話をできたらなって思っています。
やっていきましょう。
とはいえなんですけれども、出てきた資料たくさんあって、
私、しっかり目を通したのってまだT和田さんのやつしかなくてですね。
なので、その資料を振り返りながら2人で話ができるといいかなって思っております。
自動テストの目的
はい、私はこのT和田さんの資料も見ていないので、眺めながら話をしましょう。
ちなみに博多家さん、開発生産性って言われると、どういうものが思いつきますとか雑に振ってみるんですけどあります?
まずそれ以前にみたいな感じの話なんですけど、最近なのかな、開発生産性って言われていると思うんですよね。
生産性ではなくて。
自分はその辺も全然追っていなくて、最近急に生産性ではなくて開発生産性って言われるようになったなみたいな。
確かに確かに。
そういう感じなんだって、にわか調べでそう思ってるんですよ。
なるほどなるほど。
っていう前提があって、きっとその開発生産性っていうのは今まで自分たちがこの開発の文脈で話してきた生産性のことだろうなという前提で話すと、
分母に投入した時間があって、分子に何らか計測できそうなアウトカムが顧客価値みたいなものがあるイメージですかね。
私もだいたい同じで、多分出てくるキーワードとしてやっぱり大事になってくるのってアウトカムっていうところなのかなと思ってて。
よく開発生産性ってなる前の生産性ってもしかするとアウトカムで捉えてる人もいたかもしれないし、純粋にアウトプット量で捉えてる人もいたのかなって思ってて、
その辺がここ数年っていうか近年で、アウトプットも大事なんだけど、アウトカム側で大事だよねみたいな話がよく出てくるようになってなって気がしますよね。
うんうん、してます。
あと私のイメージだと、これ系で出てくるキーワードって、フォーキーズとか出てきますよね。
そうですね。深くはいろいろ言われてると思いますけど。
深くは言わないけど、そういうキーワードも出てきますよね。
ちょっと最近会議的というか内見が多いフォーキーズですが。
あんまりそこの会議的なところに対して今日深掘っていく準備はしてないので下手なことをしゃべるのは2人ともやめておきましょう。
やめておきましょう。
で、いろいろな視点から資料を作って発表してくださっている方々もいるので、ぜひぜひまとめてくれてる人のところを読んでみるといいんじゃないかなと思うんですけど。
これノートの資料がまとめてある。
っていうのはあるものの、今日ちょっとだけ話せるといいなって思ってるのが冒頭に話をさせてもらったT和田さんの資料で書いてるタイトルなんだっけな。
開発生産性の観点から考える自動テストっていうのだけはちゃんと読んで、全体的にすごく共感得られる内容だなって思ったんですけど。
一番個人的にこれしっくりきたなって思ったのが、多分発表資料の何ページ目だったかな。割と前半の方で書かれてた自動テストの目的。
目的はいはい。どこだろう。
多分10ページ数が。
なぜ自動テストを書くのかのスライドですかね。
そうですそうです。
これかはいはい。
これまでってよくテストがあると品質がどうこうとか、チェックするコストがどうこうっていう話ってたびたび上がってたと思うんですけど、
今回T和田さんが書かれてる、なぜ自動テストを書くのかっていうところで、素早く躊躇なく変化し続ける力を得るためって表現されてて、
もうめちゃめちゃこれだなって思ってて。
過去の経験からするとやっぱりソースコードとか何か変更するときってやっぱり怖いなって思ってて、
これがどこに影響してるかもわからない、全部把握しきれないし、本当にこの変更で大丈夫なのかみたいな心理的不安ってやっぱりあったなって振り返ってて思うんですよね。
そこの文脈で自動テストがあると何が助かるかっていうと、それだけいろんなチェックをしてくれてるから、
じゃあ今回行った変更って安心してデリバリーできるんだなっていう自信が得られる。
それをおそらくしっかり言語化したのがこの素早く躊躇なく変化し続ける力を得るってことなんだろうなっていうところだったんだなっていうのを、
すごく今日は博多さんに伝えたかったですね。
伝えました。
この辺って多分自動テストの良さなんて皆さん分かりきってる人の方が多いんじゃないかなって思ってるんですけど、
どうでしょうね、我々、博多さんのキャリアだとちょっと分からないかもしれないですけど、
テストのサイズ分割の課題
少なくとも自分のキャリアで考えると、全然自動テストがなかったタイミングで、もちろんリリースとかコードの変更やってた時期って長かったなって思ってて。
自分も長いです。
その頃と比べると、自動テストが入ってきたことによって何か変化ってありました?体感として。
そうですね。自分がいわゆる自動テストが入ってきたタイミングって今三浦さんおっしゃいましたけど、
それがCIと同じタイミングなんですよね。
確かに確かに。
なので、デプロイ前に必ずチェックされるっていう体験がセットできたんですよね。
その時手動でやっていたテストをやらなくて良くなったことがまず嬉しかったのと、
あと、そんな大きな変更じゃない時にデプロイしちゃって壊れたっていう体験がなくなったっていうのも結構大きいですかね。
確かにそれ大きいですよね。
手動でやってた時はやっぱりやらないんですよね。デプロイの時に小さな変更だと。
ちょろっと変えるだけだったから別に良くないとかありますもんね。
その時でもCIでやられることによって必ずチェックされたから、そこで壊れるってことがなくなったっていうのはすごい体験として大きかったと記憶しています。
他にもあったかな。ちょっと思い出せないですけど、多分そんぐらい。
そうですね。私も同じような感じでした。
ただ、仕事柄というか、自分が主に携わってたところって、今博多家さんがおっしゃる小さな変更だったとしても、結構一画面丸々手でもう一回テストするみたいなルールだったので、
それがやはり自動テストが導入されることによって、そこの安心感と、コスト削減が目的ではないもののコスト削減にもつながったので、そこの感動はやっぱりすごい大きいですね。
CIで自動テストみたいなのって、手動でたまにテストみたいなところからするとすごい変化ですよね。
すごい変化だと思います。
逆に技術の変化が進んだことによって、多分CIとかCDとか、割といろんなプロジェクト、プロダクトで入ったのって、ここ10年くらいですか、国内だと。もうちょっとありますかね。
10年はいすぎか。
いや、10年前からやってる人は全然いたと思うんですよね。
今のここ数年なのかなどうかなっていう話をした意図として、結構もう人によっては、自動テストとかCIネイティブな感じでITエンジニアのキャリアをスタートしてる人も増えてきてるんじゃないかなって思ってて。
そうなってきた場合に、何となく一番自分だったら落ちてしまうんだろうなって思うのが、自動テストのサイズを適切に分けられるかどうかっていうこと。
例えば、よく言われるユニットテストでやるべきなのか、インテグレーションテストでやるべきなのか、エンドツーエンドでやるべきなのかとかそういう話は、きっと自分が新卒で入ったところからずっとCIとか自動テストがデフォルトであったら、もしかすると深く考えずに使っちゃうんだろうなって自分で思ってて。
そうですね。
その辺のサイズ分割とか壊れやすさの考慮してどこでテストするべきとかって、これまではくたけさんはどうですかね、チームで話したりとか、自分で設計してみたりとかっていうのってありました?
一番記憶が多いのは、E2Eテストが多くなりがちで、とにかくE2Eテストは時間がかかるので、CIのために実行していてはデプロイがすごい遅くなっちゃうんで、っていう問題に取り組んだのが結構多い気がしますね。
それは何かあれですか、E2Eのテストをもう少しユニットとかインテグレーション側のテストにサイズダウンさせるとかって話なのか、あるいはちょっとでも並列実行して実行速度を速くしようとかそういう話なのかで言うと何かあります?
小さいユニットテストとかにできればいいんですけど、それをやったことはなくて単に必要そうなやつだけに絞るっていう対応と、あとはそうですね、並列実行。このぐらいですかね、やったのは多分。
なかなかテストのマイグレーションというか、こっちに移そうっていうのはすでに書かれたテストがあるっていうのを思うと手放しづらかったりしますよね。
もしかしたらこのスライドの中で述べられているのかもしれないですけど、E2Eってちょっと曖昧な言葉なんですけど、結合テストみたいなものなので、ユニットテストで全部OKだとしても、E2Eテストをやるとうまくいかない、落ちるみたいなケースってあると思うんですよね。
それが大丈夫っていう安心感を得るためのテストなのでE2Eって、どうやってユニットテストとかに分解するんだろうみたいな気持ちはちょっとありますね。
そうなんですよね、そうなんですよね。確か発表資料の中で少し述べられていたというか、表として書かれているのがあって、スライドのちょうど半分ぐらいのところですかね、32ページ。
テストスコープとテストサイズ。スモール、ミディアム、ラージのやつか。
たぶんこの辺のテストスコープとテストサイズの観点とかが頭に入っていると、わりと例えば何でもエンドツーエンドでやっちゃえとか、何でもユニットのところでやっちゃえとかが減ってくるんだろうなと思いますよね。
そうですね。ユニットテストでいいやつはとにかくユニットテストにしたいですよね。
そうですよね。ただね、昨今そういうのを難しくしているのがきっとマイクロサービスなんだろうなとか思ったりもしますよね。
そうですね。あと特にウェブのシステムだとデータベースが関わるところが多くて、データベースが関わるとたぶんこれスモールにならないんじゃなかったかな。
そうなんですよね。
だから結構難しかった気がします。この分類を最初に確かめたときにスモール難しいなって。
だいたいミディアムなんじゃないかってことですよね。
自動テストと開発生産性の関係
そうそう。だからMockを使ってスモールにできるけど、そうすると本物のデータベースを使わないっていう別の問題が出てきて、っていう葛藤があった記憶がありますね。それもこれ書いてあるのかな。
そこまでは書いてなかったかもしれないですね。
なかったですか。
ただ、それをやっていくと結局ミディアムである程度スモールを含んだ確認までするから、スモールどこまで書こうかまで考えちゃいますもんね。
そうですね。量のバランスをどうするかってことですよね。
ですですです。
っていう話とかもあったりして、大いに発表の内容には共感しつつ、この辺の知識がないと、たぶん漠然とテストコードを書いてても、実は開発生産性に対してのメリットって得られないんじゃないかなとか思ったりはしたんですよね。
今思ったのが、このスライドではタイトルの通りなんですけど、自動テストと開発生産性についてどういう話に結局なってるんですか。
自動テストをどうすれば開発生産性が上がるみたいな、そんな話なんですか。
私が読んだ解釈だと、さっき2人で話してた自動テストのテストサイズであったりとか、テストするあれはなんて表現するのが正しいんだ。
よく出てくるのってテストピラミッドとアイスクリームコーンの話出てくるじゃないですか、テストサイズ。
あれをどうちゃんとテストピラミッドに沿ったような形に持っていけるのかどうかが重要になってきて、それが適切にできると、おそらくさっきの冒頭に述べた目的の話じゃないんですけど、素早く躊躇なく変更し続ける力が得られるにつながっていくんだと思う。
なるほど。
私の解釈だったら、テストピラミッドの形に沿った状態でテストが書けないパターンって、例えばほとんどのテストシナリオをエンドツーエンドで頑張っちゃいましたってなったとした場合って、結局エンドツーエンドシナリオを修正する手間っていうのが毎回かかってくるんで、
それってトータルで見た場合に開発生産性に対してあまり効果見出せてないよねってなってるんだと思う。
なるほど。
テストの保守性が高いのか低いのかとかそういう話ですよね。
テストピラミッドの重要性
そうですね。
特にそのE2Eは割と壊れやすいというか、なのであんまり見合ってないですよね、多すぎると。
多すぎると。
リファクタリングに対してどう修正とか耐性を高くするテストを書けるかが結果的にそこにコストをかけなくて良くなることになるはずなんで、開発生産性上げるのにもつながるよねってことですよね。
なるほどね。
これ資料読んでやっぱ思ったのはだいぶ前に発売された単体テストの考え方、使い方みたいな本。
あれやっぱ読みたいなって思いましたね。
読みましょう。
今がっつりプロダクトのコードを書いて開発するようなタスクが減ってきてるんで、ちょっと読んでもすぐ使えないんじゃないかとか思っちゃってたりするんですけど、単純な知識欲として読んでみたくなりますよね。
今の三田さんがいるチームとかでこれ読みましたとか読みたいよねみたいな話とか出てないんですか。そしたらほら、輪読会とかっていう手がありますけど。
今出てなくて、ただテストに関しての機運はちょっと高まってる人もいて。
そうなった時ってこれを最初に読むべきなのかTDDを最初に読むべきなのかちょっと悩みますよね。
そうですね。
個人的には最初に読むんだったらTDDからの方がいいんじゃないかなと思ったりするんですけどね。
結構あれ、自分で手を動かしていくから理解が結構しやすいというかですからね。
でもSREチームだとテストコードか書きやすいかなあんまりデータベースがなかったりするかな。
最近だとやっぱりIAC系のテストコードとかを改めて見直してるところはあったりするんですけど個人的に。
そうなった時にIAC系のテストだとさっきのラージミドルとかって適用できるのかなとか思いつつ。
ちょっとテラフォームのテストこれまで入りましたけどどうだろうなあんまり気軽にできる感じでもない気もするなあ。
あとはどっちかというとテストしやすさを考えた時にモジュールをどう分割するかとかを考えますよねきっとね。
そうですね。
1個のモジュールで裏でブラックボックス的に全環境を作るような設計したらおしまいだしとか思っちゃうし。
とかですかね。
そうですね。
まあという感じでですねそんなにしっかり全部読んでないけどここの話はなんだろうなやっぱテストの話してる時って面白い楽しんで話してみたかったってことですね。
そうですねテスト自分はテスト自体の書き方とかにそこまでめっちゃ興味があるみたいな感じではないんですけど。
はい。
いかにして品質を品質じゃないんだよなあまあそれこそ信頼性というか大丈夫なことをどのようにして保証するのかみたいな考え方には結構興味がありますね。
ああそういうことかなるほどですね。
なんか安心を買うにはどうするかみたいなそういう話っていうか。
はいはいはいはい。
そういうのはすごい好きです。
私はもしかするとそのテストをどう書くかっていうところが結果的にテストコードを書く対象の設計につながってると思ってて。
うんわかりますね。
その設計を考える段階は個人的には一番楽しいなっていうのもあって多分テストの動向が好きなんだろうなって思いますね。
そうですねテスト書いてるとプロダクションコードの方の理解も深まっていくっていうか。
そうそうそうそう。
行ったり来たりしてこれダメじゃんこうかこう。
でもこうするとテストが書きにくいとかなんかいろいろこう行ったり来たりしますよね。
そうなんですよそうなんですよ。
そういうのもあってきっとテスト駆動で開発していった方が良い設計というかにつながりやすいんだろうなってところですよね。
そうですね。
ちょっと開発生産性ってキーワードからは外れた話をしてましたけど。
そんな資料があったのでなんかもう1回こうプロダクトコードをいっぱい書くみたいなことをやりたくなったなっていう感じですね。
ちょっと入り戻しが来ましたか。
たまに来ますよね。
たまに来ます本当に。
この書きたいよくね。
もしかすると自分たちが今やってる仕事に対しても全然この考え方とかは使えるんだけど自分がその観点に気づいてないだけなのかもしれないですね。
なるほど。
というところであります。
面白いですね。これ資料見ておこうかな。
気になるやつはいっぱいあったんですけど最近結構プラットフォームエンジニアリング会議とかもあって全然資料が追い切れてないですね。
そっちの話もまたしましょう。
またしましょうぜひぜひ。
はい。
今日はちょっと早いんですけど。
大丈夫です。
今回は開発生産性カンファレンスの中の岩田さんの資料について話をしました。
感想などはハッシュタグユルテックをつけてポストをお願いします。
Googleフォームからも送れます。
今日はありがとうございました。
ありがとうございました。
