モデレータは楽天の荻野さん、パネリストはGoogleのJohnMiccoさん・サイボウズの天野さん・クックパッドの松尾さん・ヤフーの山口さんのセッションでした。
注）仕事しながら参加してたので、聞き漏らしあります。可能な限り脳内補完しましたが、ご了承ください。
内容メモ
デプロイとリリースの頻度と、自動化をどのくらいしているか
バックグラウンドの違いをまず把握するために、この質問から。
- 天野さん
- リリースは月一
- 山口さん
- デプロイ・リリースの頻度はサービスによって違う。。
- 多いところだと１日数十のデプロイ、少ないところは2週間や1か月に１回のデプロイ・リリースというところも
- テストの自動化も進めている
- 松尾さん
- １チームが６，７人のエンジニアとディレクターなどで構成
- ビルドパイプラインはGithubとCIで、グリーンになったら本体にマージ、そこからデプロイコマンド。
- デプロイコマンドはエンジニアが全員権限を持っている
- １日30回程度デプロイ
- ジョンさん
- ビルドやデプロイ、リリースは範囲外
- ドメインや会社によらず、けっこう共通の課題を持っている。みなさん固有の課題だと思っているかもしれないが。
- リリース頻度は１日に２万、そのうち本番にプッシュされるのはそのうち５％程度
- あとは１日１リリースのチームもあれば、月に１回以下のリリースのものもある
- これは中央で管理しているわけでなく、チームが権限を持っている
初日の招待講演の話。Googleでの、テストを効果的に削減するアルゴリズムについて
- 荻野さん
- 昨日のジョンさんの話で衝撃的だったのは「全て自動化していること」「そして全部のテストを実行せずにリリースしていること」だった
- パネリストはどうか
- ジョンさんの紹介してくれたアルゴリズムを導入したい、お金を払ってでも欲しい、と思うか
- 天野さん
- Jenkinsでのリトライなど、不安定で落ちちゃうところでの苦労はある。
- 今は「このへん最近よく落ちる」と、感覚で見ているところが多い。
- そんなときに昨日のジョンさんのツールがあればうれしいと思った。
- 山口さん
- まだそこまでのボリューム感がない。テストに。
- 昨日見たアルゴリズムで出た優先順位というのは、チームの感覚と一致しているのか、を気にしたい。
- 良いから使う、というのはなさそう。
- 松尾さん
- テストが多くなったら、欲しい。
- いろいろなチームが自分たちのところに責任を持つ、という効果が期待できる。
- 荻野さん
- ジョンさんに聞きたい。
- １．全てのテストを実行しないと、バグを見逃している可能性があると思うが、どういった思想でそうしているのか。
- ジョンさん
- 確かにリスクはある。
- テストするためのバックエンドに莫大なお金とコンピュータリソースをかけているので、社内で品質を保ちつつコストを下げるという圧力がある
- 荻野さん
- ２．機械学習を使ったリグレッションテスト選択に、人が介在するのか。妥当性を確認しているのか。
- 将来、AIが「このテストをやればok」という時代がくるのか。
- ジョンさん
- 規模が大きいから、人間が介在するのは不可能。
- 機械学習はある程度間違いを起こすかもしれないが、後で見逃した欠陥を見ながら、その原因を機械学習にフィードバックしながら精度を上げていく。
テストの「価値の定義と計測」
- 荻野さん
- 先日聞いた話で驚いたことがあった。松尾さん紹介してほしい
- 松尾さん
- クックパッドではソースコードがコミットされてから世の中にリリースされるまでがかなり早い。
- CIが回るのが、長くても20分。
- 速いときだと10分いかないくらい。
- （荻野さん）日本一速いのでは？
- 天野さん
- サイボウズではSeleniumで1000ケース以上が1日10回以上
- エンジニアがわりと自動化をしていて、QAのほうは自動化しきれなかったところがマニュアルでテストしている
- ジョンさん
- Googleでは完全に自動化されているので、品質についてはすぐさまフィードバックが可能
- テストが成功に終わっているというのはその証
- クックパッドの速さは日本最速という話があったが、世界最速だと思う
- 天野さん
- サイボウズではウォーターフォールからスクラムに移行
- 少しずつ試験の比率を増やし、KAIZENスプリントというものも導入。
- スクラムの導入はリーダーの天野さんから
- 成果として、リリースサイクルを３か月から１か月に不具合報告数が70％減、お試しからの契約率38％増
- 荻野さん
- 山口さんコレみてどう思います？
- 山口さん
- やったことと成果との因果がよくわかっていなくて。。。数値的に向上したというのは良いことなんじゃないですかね
- すごいけど、スクラムにはこの効果がないと思う。
- ジョンさん
- google全体でテストを自動化する文化が根付いたのは、コードとテストを必ず一緒にコミットするというルールを設けたため
- 変更というのは段階踏んでやっていった。
- １領域ずつ「ここは全てのテストを自動化する」という決めて、取り入れていった。
- デベロッパの行動を買えるのは、コードレビューによって行っている。
- このカンファレンスにおいて一番うれしかったのが、おおむねエンジニアのみなはテストの自動化が良いものだと思っている、しかし経営者に説明をするのが難しいと感じている、ということを知れたこと。
- アメリカの企業ではほぼ自動化は済ませて、それがあったうえでどう改善するかというステージに来ている。自動化を経営幹部に説明するには、といったスライドを用意してこなかったよ。
- GoogleではQA部門が独立してあるわけではない、各チームにSETIという役割がいる
- もしQA部門が別にあるようなら、そこからQAを各開発チームに派遣するのが良いのではないか。
- 幹部・上層部に「自動化を売り込む」ためには、価値を語れるようにならなければいけない。具体的にいくらコストを削減できて、どのくらい生産性が上がるのか、を数字で出すのは難しい。
- ソフトウェアの自動化をフィーチャごと、コード１行ごといくら、といった数字で示せる公式には落とせない。そこで再認識したのが、そういった主張ができるような状態にする。そのために研究して、説得できる具体的な数字が出せるといいと思う。
- 山口さん
- YahooではQA部門がない。ゲートとしてのQA部門には価値がない。
- いまはチームごとにリリース権とともに責務があっる。
- テストする人がいないわけではない。職責としてはないが、行為はある。
- 「よきモノの提供に向けた ～開発とテストが一体となったソフトウェア開発～」
- 開発者が、自分で作ったものをテストしないということは無いと思っていて。
自動テストの話
（伊藤注：ここまでも自動テストの話してたわけですが。）
各社どういった自動化をして、Flakyなところの解決にあたっているのか。
- 松尾さん
- Flakyなところは、いろんな依存関係を持っているような箇所。
- でも本来はそういった自動化のコードを書かなくともよい（＝モックとかスタブを使うべきところ）だったりした
- エンジニアにサンプルコードを提示しつつ説得した。
- ピラミッドをベースにテストサイズを設定して責任範囲を分担。
- 実行時間との兼ね合いもそこで設定。
- マイクロサービス化で、開発のメリットと、テストのメリットがある
- 山口さん
- CI・CDのツールを開発したり、そこでの並列化も積極的に進めている
- ジョンさん
- Flakyになったのはデベロッパのせいではない、無駄な調査時間を削減する
- テストが失敗だったことと、インフラ側の問題とを切り分ける必要がある
- 荻野さん
- 切り分けのうまい方法あります？
- ジョンさん
- インフラそのものの欠陥をしっかりと認識できるようにして、リトライを行うようにする。
- システムの問題だった場合、デベロッパには通知しない。
- 松尾さん
- ひとりに責任をおわせてキャパを超えるのはよくない、責任分散。
- テストを意識しなくとも確認がされているような世界になればいい
- 山口さん
- いまのヤフーの状態が、良くできているととらえられたとしたら、ちょっと違うと思っている。
- 「何をすると良くなるんだっけ？」を考えた結果が今。
- じゃあみなさんの開発において、そのプロダクトやサービスをユーザに届けるにあたってなにをすればいいか、を考えた結果が次のアクション。それがテスト自動化ならやればいいし、そんな場合でないなら別の対応が必要。
感想
最後の山口さんのコメントが一番大事なところだと思っています。
今回のJaSST、テストオートメーター（自動化エンジニア）としてパネルディスカッションした自分が言うのもアレですが、自動化というバズワードに引きずられすぎてませんか・・・
自動化100%は確かにすごいのですが、自分たちが良いプロダクトを生み出すために改善を重ねていった結果の100%であって、Googleは「よーし、100%目指すぞ」とかやってないと思うんですよね。
山口さんのおっしゃっているように、「何をすべきか」を考えて、それが自動化することならテストを自動化すればいいし、もっと違うことをすべきなのであれば、そちらからやる。
という、言葉にするととてもシンプルに「とにかくやる」に落ち着くという。。。
とにかくやりましょう。