答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022

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

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

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

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

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

組織に自動テストを書く文化を根付かせる戦略

和田卓人といいます。インターネット上ですと「＠t_wada」と呼ばれています。

今日の講演はスクリーンショットを撮っていただいて構いません。むしろ私としましては推奨、どんどんスクリーンショットを撮ってくださいということをお願いしたいです。

スクリーンショットをTwitterに投稿していただくのも、もちろん構いません。むしろやってもらいたいなと思ってます。講演者としましては聞いてくださっている皆様のリアクションが見えるというのがテンションを保つために大事で、今日私も今部屋で1人で喋ってますので孤独なんですね。

（筆者注：講演者の和田氏と同じく、この記事で掲載しているスクリーンショットや本文の一部をTwitterに積極的にご投稿いただいて構いません。ハッシュタグは #sqip2022 です）

私の本業は技術者でありコンサルタントです。コンサルタントとしては技術顧問業というものをやっていまして、大きくは4社の技術顧問をさせていただいています。それだけでなく様々な企業様に伺いまして、主にテスト自動テストを軸足にしていろんなコンサルティングをさせていただいた経験が、今日の講演の中に出てきます。

本業はコンサルタントで技術者ですが副業として出版にも関わっています。いま入手しやすいものとしてはこの4冊に関わっています。

今日の講演ですが、若干タイトルを変更しまして「組織に自動テストを書く文化を根付かせる戦略」ということでお話しさせていただければと思います。

答えが分からないものを模索しながら作り続ける世界に

これは長沢智治さんのスライドを借用していますが、まずソフトウェアがハードウェアのおまけだった時代があり、そこから2000年頃には既存のビジネスにとってITが便利だったり有効だったりして、そして2010年頃には、ITはビジネスにとって不可欠なものとなり、2020年代にはITはビジネスのコアとなりました。

そして、近年のソフトウェア開発を取り巻く状況を背景とする大きな出来事の1つが、2021年に行われたプロジェクトマネージメントの体系であるPMBOKの改定です。

第6版までは、基本的にプロジェクトというものは期限のある、そしてゴールのある、決められたときまでに決められたものをどう破綻なく作るか、簡単に言うとそういう観点で編纂されたプロジェクトマネジメントの知識体系でした。

それに対してPMBOK第7版は、不確定なもの、決まっていないものや分かっていないもの、そこに対してどう価値を出していくか。複雑なもの、どんどんゴールが変わっていくものに対してどう価値を出していくか。そういうところに軸足が大きく変わりました。

簡単に言うと、予測型から適用型に考え方を変えていかなければならないかなという話になってきたわけですね。これはプロジェクトマネジメントの世界に結構な大きなインパクトを与えました。

誰も答えが分からないものを模索しながら作り続ける。作るだけじゃなくて、作り続けなきゃいけない、どんどん変わっていかなきゃいけなくて、しかも答えが刻々と変わっていく。

というような世界に我々は突入したわけです。

決めたものを作るんじゃなくて、分からないものを作る。そこにどうやって適応していくか。

これに関しては日経の中田さんという記者のシリコンバレーのレポート。これがとにかく素晴らしいです。Slideshareに上がってる「シリコンバレーの「何が」凄いのか」という資料があるので、ぜひそちらを皆さんもご覧いただければと思いますが、ざっくりと何ページかだけを紹介します。

分からないものをどう作るか？

体験したことのない製品サービスを作るということは、事前の要件定義はできません。

また体験したことがない体験を作るにはどうするか。プロトタイプをとにかく早く作って、使ってもらい、フィードバックを得て改善サイクルを回すという形になるわけですね。

これをソフトウェアに近い世界の言葉に翻訳していくとすると、リーンスタートアップのやり方です。

なので、その背景にあるのは、技術面で言うと「アジャイル開発」、設計面やデザイン面では「デザイン思考」です。

この2つの柱のうち、デザイン思考の方はこの講演では収まりきらないのでスコープ外とさせてください。

シリコンバレーの「分からないものを分からないなりに作る」という世界における価値観とは、「リリースした製品は必ず間違っている」という前提に立つことで、作ったものは必ず間違っているからこそ、リリース後の改善力こそが強みであり、競争力であるということです。

そういったリーンスタートアップの考え方ですとか、アジャイルの技術面のプラクティスですとか、そういったものは年を追うごとに、一種の技術体系として統合されていきます。

元々はTPS、トヨタ生産方式などからやってきたものが「リーン」になり、またアジャイルの世界では「スクラム」とか「XP（Extreme Programming）」があり、XPの背後にはオブジェクト指向のコミュニティがあり、みたいな形ですよね。

それらが2000年代や2010年代に入ると「継続的デリバリー」になり、それが「リーン」と合流して「DevOps」という一種の技術体系、技術領域に統合されてくるという形になります。

改善のサイクルや仮説検証のサイクルをとにかくこまめにぐるぐると回す。そのための技術的な体力、技術的な基盤というものをある程度体系化して言語化したものが「DevOps」という形になっています。

今日の講演では、DevOpsの両輪（リーン、継続的デリバリー）のうちの片方、継続的デリバリについてもう少し詳しく話していきます。

というのも、「組織に自動テストを書く文化を根付かせる戦略」の「自動テスト」というのは、継続的デリバリの大事な大事な柱の一つ、大黒柱の一つだからです。

ソフトウェアの開発力を測る4つのメトリクス

まず、DevOpsの適応度合いを大規模に調査したレポートとして「The State of DevOps Reports」（以下DevOpsレポート）があります。

このDevOpsレポートは、最近では3万3000社ぐらいに対してアンケートで調査を行い、その回答に対してクラスター分析などを行い、統計的に有意な形で、何らかの技術的な能力というものが企業の業績、例えば株価ですとか従業員満足度ですとか、市場占有率などに相関関係や因果関係があるかどうかを調べるというものです。

その結果、4つのメトリクスによって組織が備えているソフトウェアの開発力を測ることができるだけでなく、その企業の開発力はそのままその企業の業績、競争力に繋がっている、というところがはっきりデータとして出てきました。

その調査をまとめた書籍が日本語の翻訳書として出ていまして「LeanとDevOpsの科学」という本です。この本は近年出版されたソフトウェアエンジニアリングの本の中でも特に重要な1冊であるというふうに私は位置づけています。

• リードタイム
• デプロイ頻度
• MTTR（平均修復時間）
• 変更失敗率

この4つのメトリクスによって、その企業がどのくらいのソフトウェア開発力を有しているかが予測できる。

「リードタイム」の一般的な定義としては、施策、つまり業務上のアイディアが出てきてからそのアイディアを体現する機能がリリースされるまでの長さのことを指しますが、それを正確に測ることはできないので、今回の調査においては意図的に定義を狭めて、施策を体現するコードが最初にコミットされてからそのコードがリリースされるまでの長さ、これをリードタイムとしています。

「デプロイ頻度」は、本番環境にそのコードがデプロイされる頻度です。月に1回とか、週に1回とか1日1回とか、そういうことですね。

「MTTR」は平均修復時間、つまり不具合が発生してからその不具合が収束するまでの時間の長さです。

「変更失敗率」は、リリースやデプロイが何らかの問題を抱えて、例えば不具合が見つかったとか設定ミスがあったとか、何らかの理由でロールバックされる率のことです。15回に1回とか、2回に1回とか、ですね。

最初の2つ、リードタイムとデプロイ頻度は、簡単に言うとスピードのメトリクスです。

リードタイムとデプロイ頻度がなぜ重要かというと、現在のソフトウェア開発は作って終わりではなくて、作ってからがむしろ始まりだからですね。

先ほども出てきましたが、リリースしたものは必ず間違っているので、どうやって情報収集し、どうやって改善していくかというサイクル、仮説検証プロセスを回すことが大事です。

このプロセスをぐるぐる回すにはスピードが必要なわけですね。そのスピードを測るメトリクスがリードタイムとデプロイ頻度である、という話です。

一方で、品質に関するメトリクスは、従来はMTBF（平均障害間隔）が多く使われていました。しかしMTBFよりもMTTR（平均修復時間）の方が企業のソフトウェアの品質とその企業の業績の関係というものを明らかに捉えることができるというような実態になってきてまして、MTBFからMTTRに変わってきた、という形になります。

つまり不具合が発生しても、それがごくごく短い時間に発見され修正され回復緩和するのであれば、実は十分にソフトウェアの能力が高いとみなす、という考え方になってきてるわけですね。これは多くのソフトウェアが非修理系から修理系に、つまりデプロイメントの制約が変わってきている、という事実に根ざしています。

≫次ページ：開発スピードの速い企業は品質が高く、遅い企業は品質が低い。和田卓人氏による「組織に自動テストを根付かせる戦略」（その2）

公開されたスライド：組織に自動テストを書く文化を根付かせる戦略（2022秋版） - Speaker Deck

関連記事

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