JaSST’20 新潟に参加してきました

長友優治

2020.09.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

事業開発部でQAエンジニアをしている長友です。

今日はJaSST'20 新潟に参加しましたという記事です。

以前JaSST’20 北海道に参加しましたという記事を書いていますが、同じJaSSTの新潟開催のイベントがオンラインで行われました。その様子をどんなだったかを書きます。

JaSST'20 Niigata
http://www.jasst.jp/symposium/jasst20niigata.html

(今月は JaSST'20 関西も行われて参加したのですが、ブログを書いていいか確認取れなかったので、その次の新潟開催の中で掲載してよいと登壇者の方がおっしゃっていた基調講演と事例紹介についてです。)

今回のJaSST新潟のテーマはテストの自動化でした。

基調講演

基調講演はテスト駆動開発で有名なタワーズ・クエストの和田卓人さんです。

ご講演内容は、「組織にテストを書く文化を根付かせる戦略と戦術」です。何度かこのテーマでの講演を聞いた記憶がありますが、2020の秋バージョンということで、内容がアップデートされていました。

予稿集として公開されていた資料にも新しいスライドに差し替えなどが加えてくださっていて、何度聞いても新しい学びのある内容でした。

司会の方が読み上げて和田さんを紹介されて、それに和田さんが動揺されていました。そんな和やかな雰囲気で基調講演は始まりました。

まずは戦略編から入りました。

最初のスライドが予稿集にないスライドで、ITの位置づけの変化を説明されて、現在はITが事業のコアとなっているという前提を見せてくださいました。

続けて、４つのキーメトリクスで変わる世界についてのお話です。リードタイムとデプロイ頻度という開発スピードを捉えるメトリクスと、MTTRと変更失敗率という質を捉えるメトリクスから時代が変わってきていることがわかるそうです。これらのメトリクスをもとに2019年の調査では、エリート、ハイパフォーマ、ミディアムパフォーマ、ローパフォーマーの区分けで示されて、開発スピードと品質はトレードオフの関係ではない。また組織間の格差が、年々広がっていることなどが説明されました。

トレードオフではなくどちらも高め合うものという認識になっているそうで、組織的な投資により、格差が大きくなるそうです。

実際に2019年の調査では、MTTRに関しては、エリートとローパフォーマーの格差は2604倍にまでなっている。

なお、どのようなチームがローパフォーマーになる傾向が強いのかは、

「他社(外注先など)が開発したカスタムソフトウェア」

という言葉を話されるチームだそうです。

その流れで、なぜテスト自動化なのかについては、コストを削減したいからというのはもうあてはまらなくて、ITが事業のコアなのでアジリティが競争力だからということだそうです。

ただし、現場はそうした中で疲弊しきっていて、以下のような言霊が出てくるそうです。

テストを書く時間がない
動くコードに触れるな

最初のテストが書く時間がないについては、テストを書かないから時間がなくなるのですという言葉が印象的でした。また、動くコードに触れるなについても、現代は何もしてないから壊れる時代になっているということで、たしかにOS含めていろんなものが変わっていくので、何もしないと動かなくなるソフトが当たり前になりつつあるそうです。

こうした組織の文化を変えていくには、年単位の時間がかかり、2〜5年もかかるとおっしゃっていました。自分の組織も腰をすえて考えていかないと思う方も多かったと思います。確かに銀の弾丸はないということなので、アドバイスとして聞けたのは、

ToBe ではなく、 AsIs と NotToBe から始める

ということだそうです。ここで　NotToBe は1年後にこれを続けているのは勘弁してほしいというものだそうです。これは人やプロジェクトも自分そしてプロジェクトの速度でしか成長できなからとのこと。最近では、開き直ってしまう人もでてくるそうで、なかなか難しとおっしゃってました。

また、動きにくい組織を動かすには、みんなやっていますよということで、事例を集めて示す。なぜ変えていけないのかという説明責任の向きを反転させてみるなどを説明していただけました。

論理武装するためのグラフなども示されて、そうした情報から楽になるや損得にレベルを変えて話せるようになるといいそうです。例えば、テスト自動化で工数が増えることがあるのですが、それを示すと難色を示されてしまいますが、工数はあがるが、それで予測可能性があがると示すと上の方々にも理解を示してもらえるそうです。

そして、テストは品質をあげないということもにも触れられて、テストでは品質がわかるようになり、品質を上げる設計とプログラミングで、再設計とリファクタリングをテストで支えるんだそうです。

さて、ここまでが戦略編で、その後は戦術編のお話が続きました。

戦術編の最初は、道標となる２つの本をご紹介いただきました。

レガシーコード改善ガイドとレガシーソフトウェア改善ガイドです。

それぞれの本の特徴を添えて、説明があり、役立ちそうな本だと思いました。

次はどこにテストを書いていくかです。優先度を決めて対応をしていく必要があるそうで、傷んだ箇所と手が届く果実というお話を例に示して、一番やばそうなところから書いていくそうです。

また続けて、テストのトリアージの仕方を説明してもらいました。リスク、手動テストのコスト、そして自動化コストをテストケースを一覧にしたものに対して色分けして示し、その優先順位を並べ替えて、どこから着手するのが良いかを示してくださいました。だいたいのところでは、決済周りとかが多いそうです。

自動テストのテスタビリティなども説明がありましたが、その後はこだわらないところとこだわるところの話が続きます。

こだわらないこととしては、最初から全部やろうとしない、テスト駆動、テストファーストにもこだわらない。またテストの網羅性などにもこだわないのよいそうです。

逆にこだわったほうがいいものとしてあげておられたのは二つで、再現・繰り返しの可能性と、独立していることにはこだわったほうがいいでそうです。

それから、設計の可動域を確保についてと、テストピラミッドと話が続き、テストピラミッドではユニットテストや結合テストなどの定義でもめることもあるが、そうした場合には、Googleが提唱されたTest Sizeというもので、自分たちの中でのSmall, Medium, Largeを決めて考えるといいとおっしゃっていました。

最後には、和田さんが実際のプロダクトのコードを使ってテストコードを書くのを見せるワークショップのお話をされて、背中を見せることの大切さにもふれていました。実際に和田さんは、受託案件を年に何本かは行って、そうした背中を見せられるようにご自身を磨いておられるそうです。

講演後質疑応答の時間は取れませんでしたが、オンラインなので残してあったQ&Aのコメントにひとつひとつ丁寧に答えてくださっていました。

今のうちの状況とは違うところもあるので、そのままはあてはめられないとは思いましたが、参考になることも多かったので、今後エンジニアの方含めていろいろ話し合っていこうと思いました。実際に今日参加していたエンジニアの方もいたので、またお話してみようと思いました。

事例紹介(S5)

組み込み系の自動化の事例紹介もありましたが、そちらは公開してよいかのお話が聞けませんでしたので、最後の事例紹介の方については公開してもよいということで、そちらについて書きます。

ご講演いただいた方は、ウイングアーク1st株式会社の伊藤潤平さんです。

ご講演は「APIテストを自動化してリグレッションテストにしたら、安心で安全な開発ができて気持ちが楽になった」というタイトルの内容です。

自己紹介のあと、会社のご紹介が終わり、まずはこれまでの開発の状況のお話がありました。

これまではウォーターフォール開発をされていて、クオリティーゲートを設けて、品質保証の工程をしっかり実施されていたようです。

(ご登壇された伊藤さんは自己紹介でもお話されていたように、いろいろなイベントの登壇でお話をされていて、SQiPシンポジウムでも以前発表されていて、そのときにクオリティゲートのお話をされていたので、論文を見たことがあります。 http://www.juse.jp/sqip/library/shousai/?id=355 )

それが開発側がスクラムを導入するようになり、最初は品質保証部はこれまでと変えないプロセスで対応されていたそうです。

それだとクオリティゲートを通過できなくて、品質保証の工程が始められないという問題が発生したそうです。

開発チームの方にヒアリングを行い、開発工程内で品質を高めて、品質保証工程をスムーズに行えるように変えたそうです。その結果、最後にクオリティゲートを1つ設けてそこがちゃんと通るようになったとのことです。それにより、スムーズな検証作業に入れるようになったそうです。

改善内容の詳細としては、まず、テストのルールを決めたそうです。テストレベルで担当を分けて、実装者がコンポーネントテストまでをしっかりやる。そして、QAチームから開発チームの中にSETとして加わったメンバーが結合テストを担当。そして、その後のテストレベルのテストをQAチームが実施するようにされたそうです。そうして、スクラムの完成の定義の中に、テストに関する定義を追加したそうです。

次に改善にとりかかったのが、WebAPIテストの自動化です。

テストピラミッド的にはアイスコーン型になってしまっていて、いきなり理想形にはもっていけないので、まずはWebAPIのテスト部分の拡充を行うようにされたそうです。

その概要としては、WebAPIのバリデーション処理やバックエンドの単機能を検証するテストセットの作成を行ったそうです。 WebAPIについてもちゃんとテスト設計を行い、チェックリストと呼ばれるかなり細かいところまで把握できるテストケースを作り、それをもとにテストコードに落とされているようでした。

これにより重大な不具合を早期に発見することができるようになったそうです。また、ユーザー利用を想定した準正常系のテスト(こちらはQA視点でのテスト)により、安心感が得られるようになったそうです。

WebAPIテストはリグレッションテストとして、スプリント毎に実施されて、デグレードを発見できるようにもなったそうです。

この結果、クオリティゲート1つにして、品質保証工程がはじめられることが確認できるようになったそうです。

実際に開発工程での品質が上がったことは、バグ密度を計測して確認をされていて、開発時に発見されるものが多くなって、QAでの発見が減っていることが示されていました。

最後に現在の状況をご説明いただき、テストレベルでの担当範囲が変わってきていて、実装者の担当範囲が広がっていました。より開発の段階で品質をあげるようになっているようでした。

まだ課題もいろいろあるとのことでしたが、開発とQAがうまく協力しあっているので、きっとまたうまくいくものを見つけ出されていくのではないかと思いました。