フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022
今回は「フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022」についてご紹介します。
関連ワード （信頼性、山腰、左右等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。
講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。
本記事は、2時間におよぶこの講演をダイジェストとしてまとめたものです。以下の4本から構成されています。
- 答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022
- 開発スピードの速い企業は品質が高く、遅い企業は品質が低い。和田卓人氏による「組織に自動テストを根付かせる戦略」（その2）。ソフトウェア品質シンポジウム2022
- フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022
- [自動テスト文化を根付かせる王道と、邪道を教えよう。和田卓人氏による「組織に自動テストを根付かせる戦略」（その4）。ソフトウェア品質シンポジウム2022
いまお読みの記事は、その（3）です。
継続的デリバリーの5つの基本原則
ここからは、継続的デリバリーのプラクティスをいろいろ見ていきます。
継続的デリバリーには5つの基本原則があります。
- 「品質」の概念を生産工程の最初から組み込む
- 作業は（小さい）バッチ処理で進める
- 反復作業はコンピュータに任せ人間は問題解決に当たる
- 徹底した改善努力を継続的に行う
- 全員が責任を担う
こういった基本原則に寄って立つ一群の技能や技術の体系化された塊（かたまり）、これが継続的デリバリの考え方です。
品質の概念を生産工程の最初から組み込む、これは当たり前の話ではあります。品質は最後に検査するものではありません。シフトレフトをしていきましょう、プロセスに品質を組み込みましょうという話です。
全員が責任を担う、というのは継続的デリバリの世界において、特に近年この傾向が高まっていて、それぞれスペシャリストがその人の仕事をするという分業ではなくて、全員が得意不得意はあれど全ての仕事を担うというチームで開発をしていきましょうと。
全員が、設計もやる、開発もテストもデプロイも運用も、それだけじゃなくてサポートも含めて、みんなそれなりにやるよ、という時代です。
いろんなスキルを持ってるエンジニアのことを「フルスタックエンジニア」と言いますが、最近ではフルスタックではなくて「フルサイクルエンジニア」が大事です。
Netflixにおけるフルサイクル開発者―開発したものが運用する – CARTA TECH BLOG全てのソフトウェアの開発サイクル、しかもこれが高速にぐるぐる回るわけですが、そのサイクル全体を全員ができるようになる、という話です。
分業ではなくて、フルサイクル技術者によって構成されたチームを作っていく。
継続的デリバリーの3つの技術的な基盤
継続的デリバリーには、この5つの基本原則と支え合う関係にある、「3つの技術的な基盤」があります。
それは「包括的な構成管理」「継続的インテグレーション」「継続的テスト」この3つです。
構成管理というとGitとかでバージョン管理しましょうという話になりますが、包括的ということはつまり全部やるって話です。コードだけではありません。設計書もテストデータも、本番環境の設定も含めて全て構成管理する。
コードをバージョン管理している企業は今は普通なのですが、全てをバージョン管理の対象にしてるかどうかというと、これは話が変わってきます。
「継続的インテグレーション」はつまり、いつも統合し、いつもテストしているという話です。
いつもというのは、いつもです。テストはフェーズではなくなりました。テストは常に設計し、常に実行しています。
Agile Testingのエッセンス #scrumosaka / Agile Testing Essence – Speaker Deckそして「自動テスト」。自動テストの損益分岐点はいつ来るのかという問いがあり、3回と4回のあいだ、という話をよくしますが、継続的テストの世界において4回はあっという間にやってきます。あっという間どころか普通1日でやってきます。
Amazon | Experiences of Test Automation: Case Studies of Software Test Automation | Graham, Dorothy, Fewster, Mark | Methodologyということで、継続的テストではテスト自動化の損益分岐点を論ずるまでもなく、テスト自動化をしないと成立しなくなります。
ビルが倒壊しても次の日には復帰できるように、構成管理をする
包括的な構成管理について、質問が来ました。「包括的な構成管理の範囲はどこまでですか？ 提案書的なものも含まれるのでしょうか？」。はい、提案書もバージョン管理します。全部バージョン管理します。これはディザスタリカバリみたいなもので、もしいま、会社のビルが倒壊しても、バージョン管理システムがあれば業務が次の日には復帰できるような状況です。
もしそれができないのであれば、何かが構成管理できていないわけです。まあビルの中にハードウェアがあったらどうだとか、そういう茶々はありますが（笑）、開発が継続できるために必要な全ては構成管理の下に入っている、というのが包括的という意味です。
信頼性の高い自動テストを備えること
テストの自動化および自動テストにおいて、先ほどのDevOpsレポートの調査結果でITパフォーマンスと企業の業績などとの因果関係があるものとして判明した要素が2つありました。
- 信頼性の高い自動テストを備えること
- 開発者主体で受け入れテストを作成・管理し、手元の開発環境で簡単に再現・修正できること
この2つの要素は明らかに、4つのキーメトリクスと、そこから繋がる企業の業績との因果関係があることが判明しています。
「信頼性の高い自動テストを備えること」とは何でしょうか？ これは自動テストが成功すればリリースできる、失敗すればリリースはできない、とチームが確信できる状態であるということです。
確信できない状態とは、偽陽性（誤検知）と偽陰性（見逃し）ですね。偽陽性を伴う不安定なテストを「フレイキーテスト」と呼んだりしますよね。
参考：世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022
テストが不安定だと、開発者がテストの失敗に対して鈍感になるということがとてもとてもよく起きます。
すると、テストを5回実行して、そのうち何回か成功すればOKでしょ、みたいになってしまい、テストの信頼性をどんどん落としてしまうわけです。
自動テストというものは、失敗したら即判断して即リアクションできる、というな状況を作っておきたいのですが、テストのコードやテストの設計の質が低いと、誤検知や見逃しが多発してしまい、結果的に信頼性の低いテストはメンテナンスされなくなっていってしまう。
テストを信頼性の高い状態でキープするのにはメンテナンスコストがかかります。しかし継続的なメンテナンスコストを払うことには価値がある、ということがDevOpsレポートで分かってきてるわけです。
チームが確信できる状態とは
質問がきました。「確信が主観なのが、どうにかならないか、と考えることがあります」。鋭いですね、その通りです。ここはまだアートの世界であって、エンジニアの世界になってないところですね。
確信というのはエンジニア一人ひとりの心の中にあるので、確信の度合いを見るためにはテストの失敗に対して、エンジニアがどういうリアクションを取るかを観察します。何名かが何も考えずにもう1回テストを実行していれば、信頼性がある状態だとは確信できていないわけです。
ただ、Googleにおいては、フレイキーさが1％に接近するとテストは信頼性を喪失し始めると言われており、1％を切るように日々努力されているそうです。
（参考）このスライドは講演後に和田氏がスライドをアップデートした際に追加されたものですさらに質問が来ています「テストのカバレッジがそこまで高くなくても、チームが確信を持てば問題ない、ということでしょうか？」。難しいですね。
カバレッジが低い状態というのは、そもそも書かれるべきテストが書かれていないので、偽陰性の要因の一つとなってしまいます。だからその状態では誤った確信を持つことになってしまいますね。
ですので、必要十分なテスト設計と実装をしている、と自覚を持っている人が確信を持たないと駄目、という話になります。
開発チームと分かれたQAチームではパフォーマンスは向上しない
先ほどのDevOpsレポートの調査結果でITパフォーマンスと企業の業績などとの因果関係があるものとして判明した2つの要素の2つ目が、「開発者主体で受け入れテストを作成・管理し、手元の開発環境で簡単に再現・修正できること」でした。
これは裏返すと、QAチーム、つまり開発チームとは別に存在する品質保証チーム、あるいは外部委託先が作成管理している自動テストは、企業の業績と相関関係にない、と判明したということです。
これはある意味、残酷なデータではあります。つまり、受け入れテストやEnd-to-Endテストなどの開発を外部に委託しても、業績とは関係がない。むしろ外部に委託する場合は、先ほど言ったようにパフォーマンスとしては落ちる傾向にあります。
テストエンジニアも開発チームの中で仕事をする
これも質問が来ました。「同じ社内にあるテスト専任チームが自動テストをしてもパフォーマンスに関係ないということでしょうか？」。どうやら関係ありません。残酷ですね。テスト専任チームとして分けてしまうとパフォーマンスと関係がなくなるということです。
「テスト専任チームが開発サイクルの最初から参加してれば別扱いにならないのですか？」。そうです。
これは「フルサイクルデベロッパー」の話につながってきます。テストを専門技術として分業にしてしまうと、フローが流れなくなるという話です。
そうではなくて、テストエンジニアもストリームアラインドチームに入って、テストがすごく得意な技術者として開発に参加するのが、業績と連動できる望ましい形となります。
また質問をいただいています。「開発者主体で、というときの開発者とは誰を指し示していますか？ プログラマーという意味ではなく、関係者を入れた開発チームですか？」。これはイエスです。
プログラマーが、というように狭く捉えない方がいいです。プログラミングが得意な人もいればテストが得意な人もいて、要件をまとめるのが得意な人もいます。得意不得意はあれど、開発チームが主体となって開発したテストコードという意味ですね。
だからテストエンジニアが開発チームに入ったら、例えばプログラマーとテストエンジニアでペアプログラミングすれば、もっと上手いテストコードが書ける、もっとメンテナビリティが高く、かつ効果の高いテストが書けるようになるんです。
だから「開発チーム」「開発者が主体」と表現するのは、開発チームの開発者＝デベロッパーとして、プログラマーよりももうちょっと広い総体であると考えた方がいいかなと思います。
コードのテスタビリティとテストのメンテナビリティの向上
開発者がEnd-to-Endレベルも含めて受け入れテストなどの作成管理に関与すると、2つの重要な効果が生じます。
1つ目は、開発やテストを作成すると、コードのテスタビリティが高まる、よりテスト可能なものになります。当たり前の話ですね。
これはテスト駆動開発に繋がる話でもあります。テストを書きながら開発すると、テスト可能なコードになる。当たり前といえば当たり前。
開発者が自分でテストコードを書けば、自分のコードのテスタビリティの高い低いはその場で分かります。しかし、自分はプロダクトのコードを書くだけでテスト開発は別のチームがやってます、という状態だとテスタビリティに対して意識が働かない。これが2つ目の重要な効果に繋がります。
2つ目は、自動テストに対する責任を開発者が負うと、テストに対する意識が高まり、その管理や修正にも注力することになるのですね。
この2つが組み合わされて、テスタビリティが上がり、かつ、テストのメンテナビリティも上がることになります。
ベストを尽くすことでアンチパターンに落ちていってしまう
ここから想起される、よくあるアンチパターンがあります。私はコンサルタントとしていろんな企業に行きますが、私が参画した時点でよくあるのが、外部に自動テストの開発を委託して自動テストの一式を納品してもらったけれども、自分たちのサービスが変わっていく際に自動テストがメンテナンスされなくなって残骸が残るという状況です。
このアンチパターンをものすごく高い頻度で見てきました。
自動テストの開発を外部に委託して納品してもらい、そのまま自動テストのコードが腐っていく、というのを私は「買ってきた自動テスト」と名づけたのですが、買ってきた自動テストはほぼ間違いなくメンテナンスされずに腐っていきます。
なぜなら自分が書いてないテストコードをメンテナンスするのは容易じゃないからです。考えてみれば当たり前の話ですが、さまざまな企業がこの落とし穴に落ちています。
もう一つのアンチパターンは有名なパターン「アイスクリームコーン」。テストピラミッドの逆ですね。
手動テストの比率がものすごく多くて、自動GUIテストやEnt-to-Endテストも多くて、ユニットテストがちょっとしかない、みたいなパターンです。これも、すごくよくあるアンチパターンですね。
これはよかれと思ってこうなってしまうんです。「システム運用アンチパターン」という本から引用していきます。
「End-to-Endテストが多くなってしまう理由の1つは、テストの大部分を担当してるチームが開発チームではないことです。自動テストを行っている（すべてではないにしても）多くのQAチームは、UIテストに集中します。なぜならそれが彼らが慣れているアプリケーションやデータとのやりとりの仕方だからです」
アンチパターンというのは悪意があって落ちるものではないんです。よかれと思って行ってドツボにはまっていくものがアンチパターンです。
悪意があるわけではないので、そこに悪意を見いだしてはならないわけです。そうではなくて、ベストを尽くした結果、状況が悪化していくからアンチパターンなんです。
誰も悪いわけではない、チームの構造とか責任の主体とか、そういったところによって、ベストを尽くしたチームがベストを尽くすことによって、暗転していってしまう。これがアンチパターンのつらいところなんですよね。
そうすると、テストエンジニアの活躍の場はなくなるのか、みたいな話になって、つらい気持ちになる方もいらっしゃるんじゃないかなと思います。
テストエンジニアの活躍の場は探索テスト
ですが、テストエンジニアの活躍の場はあります。テストエンジニアには活躍の場がめちゃくちゃあるんですよ。
自動テストには、今のところテストできない領域があります。まずその領域においてテストエンジニアの高いスキルが何よりも必要とされています。それが、アジャイルテストの4象限で言うところの、「探索的テスト」の象限ですよね。
テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト（榊原 彰 榊原 彰 榊原 彰 Lisa Crispin Janet Gregory 山腰 直樹 山腰 直樹 増田 聡 増田 聡 石橋 正章 石橋 正章）｜翔泳社の本いま私は自動テストの話をしていますが、自動テストって結局のところテストじゃないよねみたいな話をよくされます。自動テストはテストを行ってるのではなくて、高速にチェックを行ってるんだよね、と言われます。
それはその通りです。テストというものは2つに分かれていて、それは「チェック」と「探索（Explore）」であると言われています。これは言い方を変えると「Known領域」（既知）と「Unknown領域」（未知）なんですね。
自動テストは既に分かっているものが、今もその通りである、ということを高速に確かめる最強の手段の一つです。既知を既知のままにし続ける。
それに対して、スキルのあるテストエンジニアが得意なものが未知のものを既知にしてくることですね。つまり、未知のバグを発見してくることです。これはものすごく価値のあることなんです。
未知のバグを発見したテストエンジニアは、プログラマーとペアになってそれを再現する自動テストを書きます。そして、そのテストが失敗することを確かめる。未知のものが既知の状態にやってくる瞬間です。こうして一度見つけたバグは、自動テストでずっと既知にし続ける。
ソフトウェア開発というのは基本的に、既知と未知の陣取り合戦です。未知の世界をどれだけ削り取って、既知の状態に取り入れ、既知の状態の砦をどれだけ広く取っていけるか。
これが自動テストの設計およびテストエンジニアと自動テストの協業という観点でも、特に特に大事になってくるんです。
ですので、探索的テストを行う、ユーザビリティテストを行う、利用者の目線でテストを行う、仕様策定に品質の観点から関与する。これらは今のところ機械では肩代わりできません。人間が最も価値を発揮できるところです。
これは継続的デリバリーの5つの原則にも入ってます。コンピュータができることはコンピュータがやり、人間は人間にしかできないことをやる。
ということで、探索的テスト、これがテストエンジニアがエースとして輝いていける一番の世界です。
自動テストの動機は変化に対応するため
自動テストの動機、なぜ自動テストを書くのか、というところをもう一度振り返ってみましょう。
ここでまたアンチパターンが出てきます。
テスト自動化するときの動機として一番最初に出てくるのが、コスト削減のために自動化する、ということです。
しかし、コスト削減のためにテストを自動化すると、いまいち削減できなくて失望してやめてしまうことがよくあるパターンです。
自動テストの回数が増えれば、コストはどんどん回収できるようになります。
しかし自動テストの学習コスト、実装コストがかかる上に、プロダクトコードの変更に追随できないようなメンテナビリティの低いテストコードを書いてしまえば、メンテナンスコストがかかる。となると、コストが全然削減できず、テストの自動化はやめよう、となって自動テストの残骸が残ることになります。
こうしたことも、たくさんの現場で見てきました。コスト削減をテスト自動化のメインの目的にしてしまうと、短期間で失望してやめる、ということになりがちです。
自動テストへの動機というものはコスト削減ではなくて、変化についていきたいから、ですよね。
なぜなら、変化についていかないと生き残れない時代だからです。
変化に対してついていけるソフトウェア的な体力を組織に身につけたいから、テストを自動化するわけです。
変化が多いものに対して、人力でテストしていくと人の方が疲れてしまうし、コストがかかるし、スケールしないからです。
O’Reilly Japan – Googleのソフトウェアエンジニアリング変更容易性を支えるから、自動テストが大事なんですよね。逆に言えば、変更容易性を支えない自動テストは負債になっていく。それが先ほどのテストの残骸たちです。
ということで、なぜ自動テストを書くのかというと、コストを削減したいから、という話がよく出てきますが、これは間違いとまで言うのはちょっと残酷ですが、それを狙うとだいたい失望することになりますし、それが本来の狙いとも言えないんですね。
そうじゃなくて、アジリティが競争力だからです。変化についていく力というのが企業の競争力の源泉だからです。だから、自動テストを書くんです、という話になります。
≫次ページ：自動テスト文化を根付かせる王道と、邪道を教えよう。和田卓人氏による「組織に自動テストを根付かせる戦略」（その4）
関連記事
- 品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020
- 品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ2020