開発スピードの速い企業は品質が高く、遅い企業は品質が低い。和田卓人氏による「組織に自動テストを根付かせる戦略」（その2）。ソフトウェア品質シンポジウム2022

今回は「開発スピードの速い企業は品質が高く、遅い企業は品質が低い。和田卓人氏による「組織に自動テストを根付かせる戦略」（その2）。ソフトウェア品質シンポジウム2022」についてご紹介します。

関連ワード （判明、検証環境、認定等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。

講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。

本記事は、2時間におよぶこの講演をダイジェストとしてまとめたものです。以下の4本から構成されています。

• 答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022
• 開発スピードの速い企業は品質が高く、遅い企業は品質が低い。和田卓人氏による「組織に自動テストを根付かせる戦略」（その2）。ソフトウェア品質シンポジウム2022
• （明日公開）フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022
• （明日公開）自動テスト文化を根付かせる王道と、邪道を教えよう。和田卓人氏による「組織に自動テストを根付かせる戦略」（その4）。ソフトウェア品質シンポジウム2022

いまお読みの記事は、その（2）です。

スピードの速い企業は品質が高く、スピードの遅い企業は品質が低い

では、実際に各企業はどんなメトリクスのスコアなのかを見ていきましょう。2019年と2021年です。

2019年における4つのキーメトリクスがどのような形になってるか、2019年の3万1000件の回答をクラスター分析した結果、「エリート」「ハイパフォーマー」「ミディアムパフォーマー」「ローパフォーマー」の4つのクラスターに分かれて、企業はいずれかのクラスターに含まれます。

State of DevOps 2019

エリートにおいては、リードタイム、書いたコードが1日未満でリリースされていき、デプロイ頻度はオンデマンドだから1日何回もデプロイされている、というわけですね。

ハイパフォーマーは、1日から1週間ぐらいでコードがデプロイされ、ミディアムパフォーマーにおいては、1週間から1カ月ぐらいの頻度でデプロイされています。

ローパフォーマーにおいては、1カ月から最長で半年。デプロイに半年かかってるわけですね。頻度も半年に1回という形になります。

このDevOpsレポートの恐ろしいところは、この企業のスピードとか質がそのまま企業の競争力や業績に関係しているというデータが出てしまっている、というところです。

例えば、エリートに含まれている企業の収益性、株価、従業員満足度、市場占有率、生産性などは、ローパフォーマーと比べて2倍以上の差がついているという残酷なデータが出ています。

では質の方のメトリクスはどうでしょうか？ MTTRと変更失敗率を見てみます。

エリートクラスターのMTTRを見ると、1時間未満で不具合が収束しています。変更失敗率は0から15%。ハイパーフォーマークラスターも1日未満で不具合が収束し、変更失敗率も同じく0から15％。

ミディアムパフォーマークラスターも、MTTRは同じく1日未満で、変更失敗率も0から15％。

ところがローパフォーマークラスでがくっと値が落ちまして、MTTRを見ると不具合が収束するまでに1週間から1カ月ぐらいかかり、変更失敗率は46から60%。つまりデプロイの半分が失敗しているんですね。

デプロイ頻度も半年に1回ぐらいですから半年に1回のデプロイの半分が失敗してる。デプロイのサイズと変更の失敗率は関係がありまして、デプロイが大きくなればなるほど、その中に不具合が含まれている可能性は高くなり、ロールバックされる可能性も高くなる、ということになります。

これが3万1000件以上の会社のクラスター分析をした結果です。

ここでまず一つ分かるのが、一般にはソフトウェア開発において品質とスピードというのはトレードオフであるといまだに言われてますが、トレードオフではない、ということですね。

参考：品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020

そして、スピードの速い企業は品質が高く、スピードの遅い企業は品質が低い。ここでも、ものすごく残酷な結果が出てきてるわけです。

上位と下位のパフォーマンスの差がさらに開く

エリートとローパフォーマーとのあいだにどのくらい差がついてるかというと、リードタイムでいうと106倍。デプロイ頻度で208倍、MTTRは2604分の1、変更失敗率が7分の1。これぐらいの差がついています。

しかもこの差が年々開いているというのが、さらに見えてくるのが2021年のDevOpsレポートです。

2021年のDevOpsレポートでは3万2000件の回答をクラスター分析し、その結果、エリートのリードタイムがさらに短くなったんですね。書いたコードが1時間未満で本番環境にデプロイされる、というところになってきています。

しかも、各クラスターの配分も変わっていて、エリートとハイパーフォーマーの数が増えてきている一方で、ミディアムやローパフォーマーからなかなか抜けられない企業もいる、という傾向だそうです。

ここから、エリートがさらに突き抜けて改善されている、という形が見えてきたのが2021年のDevOpsレポートです。

差がどのくらい開いたかというと、エリートの改善幅が大きいので、ローパフォーマーとエリートの差が大きく開きました。リードタイム、書いたコードがデプロイされるまでの時間は6570倍の差がついてます。

エリートはローパフォーマーの973倍の頻度でデプロイしています。

MTTR不具合の収束自体は、これたまたまなんですけど、その逆数の6570分の1で、これは本来はそこまで両者は相関しないので偶然の一致です。

ただし変更失敗率は、ローパフォーマーの値が改善されたので差が縮まりましたね。

ということで、丁寧にゆっくりモノを作るという時代では全然ないということが見えてきます。そして組織間の差がどんどん大きく開いています。

組み込みなのか基幹系なのかはパフォーマンスに関係ない

そうすると、皆さんこう思うんです。「でもこれって、Googleとかの話でしょ？」みたいに。私も思いました。「GoogleとかNetflixの話でしょう？」みたいな。

「うちのソフトは特殊だから」とか「うちの業界は特殊だから」みたいな話になってくるわけです。

なんですけど、この3万以上の企業の調査から分かってきたのは、システムのタイプ、つまり組み込みなのか基幹系なのかパッケージなのか、といったものと、先ほどの4つのキーメトリクスには相関関係がない、ということです。組み込みソフトウェアだから有意にリードタイムが長いとか、そういうことはなかった。

この調査をしてきた人たちも、最初は業界によって何らかの偏りがあるだろうと予測していたそうですが、それは外れたと。なので基幹系システムであろうがエンゲージメント系のシステムだろうがパッケージであろうが、ハイパフォーマーもいたしローパフォーマーもいました。

調査対象の企業にはIT事業者だけではなく、金融、小売り、情報通信、教育、メディア、政府機関、医薬品、保険、工業、製造業、エネルギーなどで、社員数も1万人以上の大企業もいれば20人ぐらいの企業もある、という業種も規模も様々な企業が入っていました。

「テスト容易性」と「デプロイ独立性」が重要

調査の結果、システムのタイプよりも、システムの2つのアーキテクチャの特性がパフォーマンスの差になり、つまりそれが業績に繋がっている、ということが判明しました。

アーキテクチャの2つの特性にパフォーマンスとの相関関係があったという、その2つの特性とは何なのか。それは「テスト容易性」と「デプロイ容易性（デプロイ独立性）」です。

これが、業種などよりもはっきりとデリバリーのパフォーマンスに影響を与えていました。

スライドを読みましょう。「アーキテクチャの特性の中には大きな影響を及ぼしうるものが2つある。我々の調査では次の2つの事項に同意できると回答した組織であれば、ハイパフォーマーである可能性が高いという結果が出たのである。

一つ目は「テストの大半を統合環境を必要とせずに実施できる」

統合環境というのはステージング環境みたいなものです。テスト用に用意された実機とか、本番環境に近い環境のことです。

テストの大半を、そういった特殊なテスト環境を使わずに実施できる、つまりユニットテスト、スモールテストから、ミディアムテスト、例えば仮想環境に閉じたインテグレーションテストまで。ここでいう「テストの大半」とは、理想的には95%です。

自動テストのうち95％はテスト環境を必要とせずに実施できる。95％はちょっとハードルが高いので90％ぐらいを大体目指してやっています。

これがアーキテクチャの要素その1です。

続きを読みましょう。

「アプリケーションを、それが依存する他のアプリケーションサービスからは独立した形でデプロイまたはリリースできる」

これがアーキテクチャの要素その2です。

つまり自分たちが作ってるシステムを、それが依存してるとか依存されているところとは独立して開発し、デプロイし、リリースできること。これを「デプロイ独立性」と言っています。

この2つ、テスト容易性およびデプロイ独立性、これが先ほどの4つのキーメトリクスに強く関係しているということです。

テスラのリードタイムはハードウェアにもかかわらず2日

例えば製造業においても、テスラは部品の変更頻度が高く、毎日60個の新しい部品が生産導入され、そして毎日61個以上の部品が削除されるそうです。

例えばヘッドライトやテールライト、充電口などは2日で変更する。2日で変更するというのは、設計、製造、テスト、リリースまでを2日で行うということです。

つまりテスラのリードタイムはハードウェアにも関わらず2日です。このような手法を電気自動車の「モデル3」などだけでなく、宇宙機器のスペースXでもやっているそうです。

あなたが学んだアジャイルとテスラの手法は何が違うのか？　認定スクラムトレーナーが語る、テスラの真の凄さ – ログミーTech

テスラは車のレベルでモジュラーアーキテクチャをとってるんですね。全てのモジュールがほぼ独立していて、パラレルに開発され、それぞれ改良を重ねて統合できる、というアーキテクチャになっている。

これはソフトウェアもハードウェアもという話になりますので、テスラにおいてはソフトウェアとハードウェアはひとくくりのものなんですね。

例えばインターフェースに互換性があればインプリメンテーションは自由に変えていくことができる。これがソフトウェアの世界ですよね。これはハードウェアの世界においても一緒で、ハードウェアのインターフェースの部分に互換性を保っていれば、インプリメンテーション自体はどんどんどんどん変更できる、改善できるという話。これはオブジェクト指向プログラミングでやっていることと同じなんですよね。

これがハードウェアでもできる。だからこそパフォーマンスに業種は関係なく、どれだけ並列化を可能にできるようなデプロイ独立性を保ったアーキテクチャになってるか、個別にテストができるアーキテクチャになってるか、というところが深く関係していると。

質問：デプロイ頻度とは本番環境へのデプロイの頻度

ちなみに今、Twitterで質問が来ていますね。「テストの95％が統合環境の必要なく実施できるというときのパーセンテージは工数ですか？」と。これは工数ではなくテストケース数ですね。ここで言っているのは自動テストのことですから、自動テストのテストケースのうち95%は統合環境を必要とせずに実施できる、という話です。

別の質問もきています。「デプロイ頻度とは、本番環境だけでなく検証環境も含めたデプロイ回数でしょうか？」。これは本番環境へのデプロイ頻度を示しています。この背後にあるのはデプロイとリリースを分離するという考え方で、本番環境にデプロイしても、例えばフィーチャーフラグをオフにすることで新機能はまだリリースしない、という状況を作ることができるんですね。

ですのでデプロイ頻度とは本番環境にコードがデプロイされていく頻度で、ステージングへのデプロイは数えません。

こんな感じで、質問をいただけるとインタラクティブ感が出ますし、喋る側としては部屋で1人で喋ってるわけですから1人じゃない感が出てとても嬉しいので、ガンガン質問いただければというふうに思います。

ソフトウェアを外注している企業はローパフォーマーになりやすい

DevOpsレポートでは、なんとなくわかっていたけど目を背けていた厳しい現実も見えてきます。

それはクラスター分析の結果、ローパフォーマークラスターとなる傾向が強いのは、質問に対して次のように回答したチームであったと。

「構築中のソフトウェア（あるいは利用する必要のある一群のサービス）は、他社（外部委託先など）が開発したカスタムソフトウェアである」

ソフトウェア開発を外注していると答えた企業は、有意にローパフォーマーになると。考えてみれば当たり前の話なんですけど、これが厳しい現実です。

だからこそ、内製化の波というのがやってきてるわけですよね。血も涙もない調査結果ですが、統計的に有意な形でこういうデータが出てきてしまっています。

≫次ページ（明日公開）：フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）

関連記事

• 品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020
• 品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ2020