「旧来のテスト担当者の仕事は、たぶんどんどん減っていく」　アジャイルへの移行に必要な品質向上の定義

セッションの概要説明

高橋寿一氏（以下、高橋）：高橋です。今日は講演というよりは、できればディスカッションみたいな感じにしたいと思っています。「アジャイル開発での品質視点の変化」というところを1時間弱お話しします。

ステレオタイプですが、ウォーターフォールからアジャイルへいったと。みんなハッピーなんですよね。書店に行くと、どんな本を読んでも「アジャイルが素晴らしい、ウォーターフォールじゃない」みたいな。やはりものを作る上でも、もののフレキシブルな使い方というのはすごくハッピーです。

かたや品質はどうであるかは実はあんまり議論されていなかったりとか。2021年に開発者のテストの本を書きました。そこで英語も含めてすべての本を読みましたが、品質のことってあまり書いていないんですよ。「アジャイルでテストはどうしたらいいの？」みたいなことが、実は書籍にはあまりなくて。どんなところにあるかなと、かなり詳しく調べたんですけど、実はないことが最近私の中で発見されて。

「これはいい儲け話になるのかな」みたいなところもちょっとあり。ここ1年、こういうかたちの講演を数回して、実は自分の中でも2ヶ月ごとに講演の内容が変わっていたりするので。「以前言っていたことと違うんじゃないか」という意見もあるとは思うんですけれど、この2ヶ月でまた新しいネタを仕入れたので、それも含めて話そうかなと思っています。

あとはウェビナーなので、できれば忌憚のない意見というか。僕自身もこのアジャイル品質に関してはすごく勉強しています。大学の先生と一緒にAGEST Testing Labを立ち上げて研究もしていて。

みなさんからの現場のフィードバックはすごく重要で。「寿一はこういうことを言っているけど、現場じゃ通用しないよ」ということは、すーごく重要な意見なので、そういうのも含めてチャットで入れていただくと非常にうれしいかなと思います。

今日はスライドがたくさんあります。テクニカルなこともスライドの中に入れました。ただ、テクニカルなことは読めばわかるので。

というより、もう少し技術や品質の本質について、ウォーターフォールモデルがうまく流用できるところ、流用できないところを中心に話していこうかなとは思っています。

バグの数を数えるのは意味がない

主に『ソフトウェア品質を高める開発者テスト』という本を中心に話していきます。お買い上げになった方には非常に感謝しております。出て1年ちょっとになるんですけれど、うれしいことに改訂版が出ることになって、内容も実はけっこう刷新しています。その新しい内容を中心に話していくことになると思います。

僕の経歴ですが、マクロソフトのヘッドクォーターでWindows周りのテストとかをして、SAPでERP（Enterprise Resources Planning）をやって。アメリカでやってきてちょっと疲れてしまって日本に帰ってきて、直近ではソニーに十数年ぐらい。品質のストラテジーを考えるようなミッションでやっていて、今はAGESTで会社全体の技術を引っ張る立場で仕事をしています。

まずアジャイルになって考えなきゃいけないことは、ウォーターフォール時代って「バグがたくさんあるからなくしましょう」みたいな。バグと品質は相関関係にありました。バグって絶対ゼロにならないんですよ。なので、「バグの数を数えるのをやめましょう」みたいなことをけっこう言ったりします。コロナの患者を数えても意味がないように、バグの数を考えても意味がないので。

まず、今後定量的に品質を測る上でバグの数は、僕はもう取るべきではないと思っています。傾向という意味では取るべきかもしれないけど、バグの比重はすごく少なくなっていく。

悪口になっちゃうんですが、「ゼロバグの日」みたいなのをいまだに設定している会社さんがあると思います。お客さんなのであまり言えませんが、「バグはゼロにならないよ」みたいなことをサジェストするんですけれど。そういうのは今後、あまり意味がなくなるんじゃないのかなとは思っています。

Agile品質担保に必要な4つのBox

少し本題に入っていきます。（スライドを示して）これは数ヶ月前に僕が勝手に定義した4つのBoxになります。「Agile品質担保に必要な4つのBox」というところで、「こういう4つの活動をやると、アジャイル的にはうまくいくんじゃないか」と考えました。

まず1つは開発者の品質のフレームワークです。どういう戦略で開発者テストをやっていくか。あとは、テスト担当者の品質のフレームワーク。どういうフレームワークでテスト担当者がテストをやっていくか。例えばIEEE829というようなテスト計画書。もしくは今の新しいものだとISO29119。いわゆるテストプロセスといわれているもののフレームワーク。

あと（スライドの）左下にいって、今度は計画やストラテジーを決めた後にいったいどういうアクティビティを実際にしていくか。「開発者だったらリファクタリングをちゃんとやりましょう。単体テストをちゃんとやりましょう」というところですね。

テスト担当者の具体的な作業指針ですよね。「計画を書いたけれど、じゃあどうやってテスト計画を書いていこう。どうやってリクワイアメントに対してテストケースを対応させていこう」みたいな。4つのBoxをうまく算出して、整理していく必要があると思っています。

なぜこのような4つのBoxを書いたかというと、ウォーターフォールだとVモデルがあって、要求に対してなんとかをテストするようなことができます。でも、アジャイルの場合だとやはりVモデルなどを適用するのはけっこう重いです。

いわゆるアメリカやヨーロッパの研究者やケント・ベックがアジャイルの定義をしたところに対してスピーディにやっていくには、こういう4つのBoxを同時に考えるほうが、僕としては考えやすいなと思っていて、これを提唱しております。

開発者の作業は単体テストに頼らざるを得ないような世界に陥っていく

じゃあこの4つのBox、ウォーターフォールモデルではどういう感じになるかというところですね。テスト担当者の具体的な作業は、たぶん膨大なテストケースを書いて、膨大なテストを実行して、たくさんの時間、たくさんのバグを出すというのがウォーターフォール時代のテストだと思うんですよね。

ゆえに、何を言わんとしているかというと、大きなBoxにやはり膨大な開発のコストや開発の人員をかけていて、品質を上げていった。日本的に品質がこういうかたちで上がるんじゃないのかというのはあります。

じゃあ逆にアジャイル品質のモデルではどうなるかというと、（スライドの）左下のBoxのほうがボリュームは絶対に大きくなると思っているんですよね。開発者の作業は、具体的には今後、単体テストに頼らざるを得ないような世界に陥っていくんだろうなと思っています。

この後に詳しく説明していきますが、その単体テストをやっていくと。ただ単体テストの活動において品質がどれだけ向上したか。いわゆる出荷のための品質ゴールに達しているか、達していないか。2週間のライフサイクルの中で、定量的にメトリクスが測れるかどうかは、実はあまりわかっていない領域です。

例えばみなさんの中にも開発者がいらっしゃると思いますが。ウォーターフォールモデルだと、単体テストをやって結合テストをやってシステムテストをやって、「ああバグカードが減ってきましたね。出荷しましょう」みたいなストーリーができたと思うんです。

ただ、2週間のイテレーションの中に、単体テスト、結合テスト、システムテストは全部入らないから、開発者の単体テスト、レビューなりリファクタリング活動を2週間に詰め込む。

2週間のイテレーションが終わったら、成果物に対してステークホルダーがチェックをする。それで「これ、品質はどうなの？」と問われた時に、その開発チームが「いや、いいですよ」「いや、まだまだですね」ということが、非常に言いにくい世界だろうと僕は思っています。

ここはちょっと僕のテーマでもあるし、繰り返しになるんですけど。会社としても2週間のイテレーションが終わった後にチェックをする時に、定量的な品質をちゃんと言えるような世界にすることが必要なんじゃないかなと思って、こういう講演をしています。

イテレーションの中ですべての品質担保をする

こんな定義ばっかりしていてもしょうがないので、今日解決したいところですよね。基本的には、単体テストでイテレーション内に品質担保しなければならないですよと。組織にもよりますが、講座とかに行くと、多くの組織で「単体テストでやっています」とみなさん言ってくれるんですよ。その後「網羅率はどのぐらいですか」と言うと、途端に黙ってしまうお客さんがたくさんいるのも事実です。

なので、今後アジャイルに移る部分は、やはり単体テストをちゃんとというか定量的に、例えば「C1で80パーセント、C0で90パーセントですよ」みたいな、自分のチームの中でどう品質を上げていくかを定義しなきゃいけない。

イテレーションの中で品質が完結しないと、出荷後にやはりバグが出てしまう。言い方は悪いですが、エセアジャイル。そのイテレーション、イテレーションが終わって、その後に膨大なシステムテストをやって出荷する組織とかありますが、基本的にはアジャイルなので。イテレーションの中で完結して、そのタイミングで出荷後もう出せるようなかたちにするのがやはり自然だと思います。

基本的にはイテレーションの中で完結をして、そういうふうに出したとしても市場バグにはならないような体制なり考え方なり、もしくはアクティビティを定義しなきゃいけないと思います。

そうすれば、チームとしては圧倒的に仕事は減ると思うんですよ。これができないと市場問題になって、「4イテレーション終わって出荷しようと思うのに、やはりまだ1ヶ月システムテストをしなきゃならないじゃん」みたいな。「QAチームはいなくなっちゃったしね」みたいになってしまって、やはり自分の首を絞めるので。

言い方としては“シフトレフト”という言い方になるかもしれないんですけれど、イテレーションの中ですべての品質担保をするように済ませるべきだと思うんですよ。

旧来のテスト担当者の仕事は、たぶんどんどん減っていく

そうなった場合に、僕らのエンジニアリングの人材戦略は変えなきゃいけないと思うんですよね。さっき右下のBoxが大きかったんです。いわゆるシステムテストチームが膨大な仕事をして品質を上げていた世界から、今度は単体テストを膨大にして品質を上げなきゃいけない世界になるので。みなさんの仕事を奪うような言葉を書いて申し訳ないんですけれども、旧来のテスト担当者の仕事は、たぶんどんどん減っていくと思うんだ。

なので、必要であれば単体テストのやり方とか、ソフトのコーディングというスキルがテスト担当者には必要になってくる世界が今後……。預言者じゃないですけどね。ここ数年できっと来るんじゃないのかなというのが本日の主題です。

なのでタイトルは「すべてのエンジニア」ですね。とりあえずQA担当者だけではなく、開発者、もしくはプロジェクトのマネージメントをする人、すべての人が一丸となって……。なんかすごく高校生みたいですけど（笑）。一丸となって品質を担保しないと、なかなかアジャイルに適応できない。

みなさんは、アジャイルのメリットをもう知っているわけなんですよね。フレキシブルに物事を運営して、お客の望むものをスピーディに出せるっていう、すごいメリットがあります。

僕が言い切っていいのかわからないですが、ただ、デメリットって、品質を高める上ではそれなりの工夫をしないと。早く出してお客の望むものがあったとしても、ぼろぼろの品質で出してしまうと、それはやはりお客としては望むものではないので、そこを考える必要はきっとあるんだろうなとは思っています。

ウォーターフォールでもアジャイルでも品質は劣化する

もう少し具体的に言います。以前の会社でよくあった、もしくはコンサルをやっていてよくあるのが、コードが汚い。単体テストをあまりしていないのでコードが汚い。

機能追加をするとまた単体テストがしにくくなる。いわゆるネストが深くなったりとか、リファクタリングしなきゃいけないけれど、リファクタリングしないから、どんどんどんどんコードが汚くなってきて、ファイルサイズが大きくなって、複雑なソースコードになってきて。何が起こるかというと、品質が劣化すると。

品質の問題点は、ウォーターフォールでもアジャイルでも品質は劣化するんですよ。でもアジャイルの場合さらに悪いのは、品質の劣化スピードがすごく上がってきます。なぜならイテレーションが進んで、イテレーションごとに品質が悪化するので。品質の劣化スピードがあるから「アジャイルにしてよかったけれども、ウォーターフォールのほうが品質がいい」ということに実はなっていく可能性を秘めている世界ではあります。

実際に品質にかける費用って、ここ30年変わっていないんですよ。いわゆるアジャイルになろうが何になろうが、テストコスト、品質コストは変わっていません。

なので何が起こるかというと、OSSを使ったりしますよね。どんどんどんどんソースコードのサイズが増えていきます。でも品質にかかるコストは変わっていないので、人員も増えないですよね。その時に、やはり品質は下がっていく。コードのスピードがどんどん上がっていく。ある意味ノーコードみたいになっていきますが、品質のスピードはなかなか上がらないと思います。

結局、書けば書くだけある一定の倍率でバグが起こります。人間の書くものによってね。僕らとしては、その中で大きなバグを逃さないというのは、やはりすごく重要だと思うんですよ。

「お客さんもソフトウェアにそこまで完璧を求めていない」というマインドも、たぶん20年前よりは変わっていると思うんですよね。「小さいバグだったらしょうがないよね」って。

なので、いかにして大きなバグを素早く取っていくかという戦略は、僕はすごく重要だと思います。QAさんでも、テスターでも、仕事が少なくなっていく理由としては、やはりそういう小さなバグばっかり見つけていても、修正、フィックスする暇がないというのもあったり。

なくなっていくテスト手法としては、例えば（これまでは）膨大な組み合わせテストをけっこうやっていましたが、そのような、いわゆるなぞるだけの自動化テストがなくなったりとか。

でも単体テストのボリュームは増えていきますよね。というのが、大きなバグの中で、いかに早く大きなのを潰すかというのが必要なことなのかなと思っています。

効率的に品質を上げているGoogleのやりかた

ここではちょっとテクニカルなところで、例えばGoogleではどうやっているか。みなさん知っているように、Googleにはテスト担当者がいないんですよね。テスターさんがいません。なので、開発者がコードを書きます。その後、自分が担保する自動化コードをGCPのGoogleのプラットフォーム開発者の中にsubmitなりプルリクして自動的にビルドを流すのがGoogleです。今のGoogleのやり方は、たぶんある意味世界でトップレベルなので、僕らが学ぶべきテクノロジーなのかなとは思っています。

Googleはすごく効率的に品質を上げていると。彼らは「バグを潰している時間がない。だから、もう上流でテストをするんだ」と言っている。時間のほうが重要なんですよね。マニュアルテストは一切やっていません。なぜなら「そのマニュアルテストをやっている時間がないので、自動化しているんです」みたいな言い方をしているんですよ。

日本人にとっては少し矛盾しているのかもしれない。日本でお客さんと話している時に、時間のことをあまり言われることはないんですよね。「自動化でマニュアルテストのコストは下がりますか」みたいなことを言っているお客さんがすごく多くて。

Googleはそんなことは考えていなくて。「時間はお金で買いたい」。彼らはすごくお金を持っているというところを自覚しているので。やはり効率的に品質を上げているテクノロジーは、すごく重要だと思っています。

なので、膨大なシステムテストで今までやっていた部分は、ちょっと言い過ぎかもしれないんですけど、僕はほとんど無意味なような気がします。それよりは効率的に上流で単体テストを自動でやって、CI／CDで流していくみたいなところをやっていくことが一番重要なんじゃないのかなと思っています。

（次回に続く）