DXにおける品質管理と自動テストは切り離せない
小林依光氏（以下、小林）：続いてのテーマは「DXにおける品質管理の取り組み事例」です。みなさまはDXにおける、まさに品質管理の専門家の会社さんなので、どういった事例があるのかを聞きたいです。では、今度は後藤さまからお願いしてもいいですか？
後藤香織氏（以下、後藤）ちょっとおもしろくない回答になってしまって申し訳ないのですが、本質的にはあまり変わらないと思っているんです。結局、品質管理や保証、私たちがテストをしたり品質に対する何かの活動をするのは、よく言われることとして、ものを作るわけではないし直す人でもない。となると、次の判断をするために非常に質の良い情報を提供する（人ということです）。
そこの本質は変わりませんが、（DXでは）違うところもあります。プロダクトそのものはその環境のニーズに合わせて変化していくことを前提としています。そのため、変わっていくプロダクトに対して、ゆっくりのんびり品質保証していても（その波に）乗っていけないので、スピードが求められるというところです。ここぐらいがちょっと異なるポイントだと考えています。
やはりそういった背景があるので、取り組み事例としては、いかに素早く必要な情報を提供できるかに尽きると思っています。そうすると、やはり取り組みのベースというか、（取り組みの）一部として、自動テストは切り離せないとは思っています。
自動テストは、よくテストの効率やコストを下げるという文脈で語られることもあると思います。けれども、自動テストの一番の価値は、人手ではやりきれないスピードや頻度でしっかりテストをすること。
そして、出てきたデータは蓄積できるので、テストの品質の情報をデジタルでしっかり持ち考察できる状態にしていくことが、けっこう幅広いところで共通して取り組まれているトレンドだと思っています。
DXの品質管理はデータが重要
小林：先ほどの五味さまのプレゼンとつながりますね。（プレゼンの中に）柔軟性とか速さとか（のお話）があったと思うんです。五味さまはどうでしょうか。
五味弘氏（以下、五味）：そうなのですよね。先ほど言いましたが、DXの品質管理は本当に難しいです。先ほどはプロダクト品質だけを取り上げましたが、DXに向けてはデータが大事ということもあります。
なので、そういうものはデータ品質についても（やらなければいけないので）審議する。いろいろと「あれもやんなくちゃいけないです」と（なる）。品質（そのもの）が幅広いので、「このバグだけ」「生産性だけ」じゃなくて、いろいろあるから、それ（品質）自体は間違いではないんだけれど、その中のどれを重視するか（という意見）がいろいろ出てきます。
品質は全部定量的に測れないのが困ったことです。なおかつ、先ほども言いましたが、（品質の文脈で出てくるキーワードの）“価値”というのは顧客価値、今は社会価値なので、社会価値はどうやって測るんだということになります。（すべての人が普遍的に価値があると認める）戦争をしないことはいい（ことだ）と思います。それは社会価値だと思いますけれど、いやぁ難しいですね。
だからここはいつも「いい質問ですね。一緒に考え、一緒に悩んで、一緒に苦しみましょう」と言っています（笑）。会場のみなさんも含めて、ネットワーク参加のみなさんも、ぜひ一緒に考えたいと思います。
パフォーマンスの面で「これまでと同じ」は通用しなくなってくる
小林：福原さんも、一緒に考えるネタをいただけると楽しいんですけれど。
福原和紀氏（以下、福原）：そうですね。新しいデジタル技術が絶え間なく生まれてくる中で、新たなサービスや機能が続々とエンハンスされていきます。福原（の意見）としても、先ほどの後藤さんと同様です。機能的な側面においては、既存のエンハンスと本質的なところでは大きく違わないと今のところは感じています。
ただ、そうではない側面もあります。それは性能評価の面だと思っていて、（そうではないのは）主にパフォーマンスの面です。
先ほどお話ししたように、物流業界における配送面でのさらなる効率化が現在進行形で進んでいるというところからも、取り扱うデータ量が一気に増えてきていると思います。「これまでだったらこのパフォーマンスレベルでOKだよね」と言っていたところが、もう今までどおりOKを出せなくなってきていると感じています。
なので、ある特定の処理において、どういう状況下でどれくらいのパフォーマンスを得るべきなのか、たたき出すべきなのか、お客さまとも定期的に会話をしています。ヒアリングした中からあるべき期待値を更新していく作業は、この品質管理のチームのマストの課題になっていると思われます。
「これまではこうだったからいいよね」という判断は、これからは通用しなくなってくる。品質管理を行う人は、共通認識として持っておくといいと感じています。
小林：今日の冒頭で私が出した図がありました。トライ・アンド・エラーをしながら物事を進めていくので、ある一定の基準・パフォーマンスを設けても、（その基準・パフォーマンスを）達成すると「さらにもっといいことがあるよね」みたいなことになって、（基準・パフォーマンスが）どんどん変わっていっちゃうと思うのです。
その性能を満たしたことによって、ユーザーが何かいいことを実現できる。それが先ほど五味さんがお話されていた「一緒に考えましょうね」というところになっていくと思っています。（ただ）そこまでエンドユーザーをしっかり見るとなると、なかなか目線を高くしないといけない、難しい仕事だと私も感じているところです。
五味：性能問題はなかなか難しくて、結局ユーザーさんがそれに満足するかどうかが一番大きいと思います。アジャイルの考えとも同じですが、ユーザーと一緒になって性能問題を考えないとやり過ぎることもあるんじゃないかということもあります。そのあたりはどうなのですか？
福原：企業さまが作る製品を一般消費者が受けることによる顧客満足度は、これまでの時代背景を考えると、一方通行で成長させていくところがあったと思います。
ただ、これからの時代は消費者側からもフィードバックをすることによる、双方向のコミュニケーションを取ることによって、さらに勢いを増して品質を向上させていく。それがこれからのDX時代に求められることである（という）ことは、今までの時代とは違ってきている感じがします。
五味：確かにコンシューマー向けだと非常に難しいですね。エンドユーザー、コンシューマーとの対話というか、「どんな性能がいいですか？」と（いうように）顧客満足度、コンシューマーの満足度を測ることはなかなか難しくて、やはり類推するしかない感じですよね。
福原：そうですね。なので、各企業さまの取り組み1つをとってみても、一発で成功するなんて絶対にあり得ないので、いかに失敗を繰り返しているかが重要になってくると思います。失敗データが財産になってきていると思うので、いかに失敗データを積み上げていけるかが非常に重要だと感じています。
DXの品質管理でも、世の中のニーズにいち早く適応する必要はある
小林：もっと話を聞きたいんですけれど、テーマをまだ用意しているので、少し進めていいですかね（笑）？ ちょっと近いテーマをもう1つ持ってきてしまっているんですが、DXならではの品質管理です。
先ほどの「コンシューマーの意見を拾うのは難しいですよね」というところです。例えば、私は以前スマートフォンのゲーム会社にいたので、そこですごく気にしていたことでもあります。今回のJSTQBのパートナー企業さまの中の1つのサービスでもあります。
Twitterのトレンドとか反響とかを自動的に収集して、それによって、ユーザーさんが製品に満足しているのか満足していないのかを取ってくる。「それだって品質管理ですよ」と言われた時に、ソフトウェアテストの範囲ではないじゃないですが、「そこまでやるんだ」みたいな感覚があって驚いたこともありました。
後藤さんはどうですか？ DXならではの「こんなことをやっている」みたいなものがあったらお話ししてほしいです。
後藤：「ならでは」かはわかりませんが、やはりベースとして、世の中のニーズとか環境変化にいち早く適応して、企業としての競争力を高めていくことが必要であると思っています。そうすると、やはり「変化に気づく」ということは意識していないとできません。
その中の1つが例えばゲームだったら、（過去に）ゲームに携わっていたことがあるのですが、「おもしろい」と言われたものをずーっと変化なく提供し続けていると、「飽きてきた」というユーザー側の感覚の変化を、ユーザーレベルから察知できます。あとは世の中のトレンドを追いに行きます。
ちょっと話が変わっちゃうかもしれませんが、プロダクトの変化は、今のパフォーマンスをどんどんエンハンスしていくと、あるリリースから急にパフォーマンスが落ちている。それは、見つけに行こうと思って仕掛けを作っておかないと気づけないんです。
なので、どういったKPIで何を見ていくかは、かなり戦略的に設計してモニターし続けることをやっていく必要があると思っています。洗練された企業だと、そこは取り入れている感覚があります。
仮説検証型の開発手法をとる企業が増えている
小林：福原さんはどうですか？ 先ほどパフォーマンスというお話もありましたが、その他に「DXだとこのあたりまで品質管理に手を出す」ということがあったら聞きたいです。
福原：DXは顧客の体験を変革していって、新たな価値を創出することが1つの大きなテーマになってくると思います。なので、そういった性質があるがゆえに、当たり前の品質から魅力的な品質に対しても、より重きを置いていくことが非常に大きなポイントになってくると思います。なので、仮説検証型の開発手法をとる企業さまが、非常に増えてきていると思っています。
そのために、はじめのうちは開発するものがけっこう不確定です。フワフワしている内容から開発に入っていくことがあると思うので、開発投資も非常にリスクの高いものになってきていると感じられます。
品質管理をする我々としては、企画そのものの品質を上げていくことが求められていると感じます。このようなところが、シフトレフトの必要性につながってくると思っています。
あとは、リスクの高い開発になってくるからこそ、リスクの管理も非常に求められます。媚びを売るわけではありませんが、まさにJSTQBの学習が非常に活かせるポイントになってくると思います。しっかりと学習して、しっかりと装着していきたいところではあります。
小林：しっかりJSTQBのアピールをしていただいて、ありがとうございます。
福原：いえいえ、とんでもないです。
DXの品質管理は信頼性以外のことも必要
小林：五味さまはどうですか。今の話を聞いてみて。
五味：お二方の意見、非常に参考になると思います。後藤さんが言った変化への対応、これは本当にDXでは大事です。それを品質管理までどうやって落とし込むか。今言われたように、モニターし続ける、観察し続ける。確かにこれが大事だと思っています。
その結果どうするか。福原さんが言っていた仮説検証、リスクとかも含めて、仮説検証で新しい価値、UXも大事にやっていく。確かにそれもDXの文脈によく出てくることです。DXならではの品質管理、モニターし続ける、変化に対応するための仮説検証。
先ほどの講演でも言いましたが、すべてがDX対応ならではじゃなくて、DXプラスということです。今までウォーターフォールでやっていたことも大事で、かつ、DXなら今お二人が言ったこと、アジリティとか俊敏とか、そちら側のキーワードにどうしても落ち着く品質管理をしなくちゃいけなくて。信頼性ばかりではなく（その他のことも必要）ということで、これはお二人と同じ（意見）だと思っています。
意思決定を早めるために定量化できるところはする
小林：先ほど福原さんと後藤さんが言っている中で私も思ったのですが、品質管理のやり方において、目的をしっかりしなくちゃいけないとか、魅力的品質とかについてお話されていました。
我々は品質の専門家なので「良いね」「悪いね」という程度をきちんと数値化して客観的に伝えなくちゃいけません。プロフェッショナルとして、がんばらなくちゃいけないと思っています。後藤さんはどうですか。そのあたりの数値化のこだわりはありますか？
後藤：数値はもちろん非常に重要なので取ってはいきますが、DXならではというところだと、やはりベースはウォーターフォールのよい考え方で良いと思うんです。
ただ、ウォーターフォールだといろいろなメトリクス（出さないといけない）。SIerとかだと「特にこれを取って出すべき」ということが決まっていたりするので、出さなきゃいけません。「コードステップあたりにどれだけバグが出ましたか」とか、「信頼度成長曲線を描きましょう」とか言われて描くんですが、その目的を問いただす必要はすごくあると思っています。
なぜならば、品質保証もすごいスピードの中でやっていかないといけないので、無駄な作業をやっている暇がないというところがまずあります。「なんのために使うのか」「必要なデータだね」とわかったのであれば、それを効率よく取っていく設計をしていくということです。なので、意思決定を早めるために、定量化できるものは（定量化）するということは、非常に大事だと思います。
小林：ありがとうございます。急な振りでしたが、きちんと答えてもらえたので助かりました。そうですね、意思決定ですね。確かにそれが大事なんですよね。
（次回につづく）
