テストの広さと深さ、どっちが大事?
ソフトウェア開発における品質を考える - Part2

テストの広さと深さ,どっちが大事? #2/2

DeNA QA Night #1
に開催

2019年11月27日、DeNA品質管理部が主催するイベント「DeNA QA Night」が開催されました。自動テストに特化せず、ソフトウェアテストや品質にまつわることを広く議論する場としての本イベント。第1回となる今回は、デバック工学研究所の松尾谷氏をゲストに招き、現在のテストの潮流やトピックスを語りました。プレゼンテーション「テストの広さと深さ、どっちが大事?」では、長きに渡りソフトウェアテストの領域において貢献してきた松尾谷氏が、ソフトウェア開発におけるテストの歴史やこれからについて語りました。

現在のQA市場

松尾谷徹氏(以下、松尾谷):ここまでは昔の話です。(スライドを指して)現在はどうなっているかですが、絵で示してみましたけども、鳥の目よりもっともっと遠ざからないと、人工衛星から見なきゃいけないぐらい分野が広がっちゃって、何の絵かまったくわからなくなっちゃいました(笑)。

左のほうに製造業とか情報通信とか書いてますが、従来はそういうものを作る側、提供側がプロダクトとしてソフトウェアがあって、その作るソフトウェアに対する品質保証とかをやってたんですが、気がついたらこのITの技術が、産業界とか、宿泊とか宿泊旅行、流通、金融・保険、マスコミ、公務というか公共、ほとんどのものに入ってきた。

それまではバラバラだったそういうものを、統合するビジネスをGoogleとかAmazonとかが仕掛けて、全部をカバーするような範囲で、市場を拓いた。

それを今度はお客さん側、市場側から見ると、それまでは銀行なら銀行のATMのサービスを受ける人というような、ある特定の人に対するサービスだったんです。それがどんどん広がって、スマホを使っている人とか、パソコンを使っている人、インターネットを使っている人というふうになった。つまり、個人ではなくて社会。市場が社会という、細かいものから大きなものに変わってしまいました。

現在は、まさに社会に対して供給、提供側がサービス。サービスは結果的にはデータですから、そのデータを提供している。こんなかたちで、ビジネスがどんどん広がっていってる。

もちろん昔のプロダクトを作ることもありますし、従来と同じような、個々のサービスのクオリティのものもありますが、全体的にはものすごい広がってしまった。この中で今後どうしていくか? これは非常に大きな変化ですね。今までとは考え方を変えていかないと、うまくいきません。

オープンな時代へ

ある意味でこの市場の比率、市場全体への影響から見ますと、プロダクトとしてのソフトウェアは、ビジネスとしてはもう終末状態です。これで儲けようというビジネスには、もうならない。単独のソフトウェアを作ってもビジネスにはならない。これは2010年前後ぐらいからもう明らかですね。プロダクト自体はもちろん残ってますけれどもビジネスにはならならい。

海外のメーカーはほとんどオープン化しちゃいましたね。Microsoftなどは特殊で、過去の資産としてまだ持ってますが、ほとんどの企業はOSS、オープン化していった。結果、ほとんどのソフトウェアはオープンソースになりました。

それも、背後に企業の戦略があります。オープンソースはそのへんの物好きなお兄さんたちが作っているものかというと、ぜんぜんそんなことはありません。あとでデータも話しますが、ほとんどは企業が作っています。とくに売れてる、人気のものを調べると、95パーセントぐらいが、企業がお金を出して、いろんな思惑を持って開発しているものです。

なぜOSSに変わっていったかというと、マネタイズといいますかね。要するに、ソフトウェアを作るとか、サービスを作る知識をどういうふうにしてお金に変えるかという問題なんです。これはビジネスの基本になってきます。マネタイジングが変わってきた。

昔は作ったものそのものを「キロ幾らです」みたいに「何ステップ幾ら」という、まぁそれもなかなかできないから「人月幾ら」というような商売だったんですが。もうそういうやり方は成り立たなくなりました。だってOSSに無償でいっぱいありますから。そちらのほうがはるかにいい。

要するに、現在の要求には、1つのソフトウェアだけでは応えられない。例えばカーナビを見ると、最初は道案内だけでした。だんだんいろんな機能が増えて、音楽を再生するとか、なんかチャラチャラ余計なものがいっぱいついてきた。

例えば、Bluetoothをつけなきゃいけない。Bluetooth1つとっても、ものすごい種類があるんです。これを全部自分たちの権利利用(例えば著作権)で作るなんて不可能です。

じゃあどうするか? (よそから)持ってくる。買ってきてもいいんだけど、ものすごい数だから、あっという間に破綻しちゃいます。そうなると、結局オープンソースしかない。オープンソースを使おうと思ったら、自分もオープンソースにならなきゃいけない。

GitHubができたぐらいですね、2010年ぐらいからアメリカをはじめ世界の企業はそれに気がついた。複雑なシステムを自分たちの権利使用だけでやっていくのは無理だろう。できても、Officeみたいな閉じた世界でしかない。そういうかたちで、オープンソースのほうにどんどん流れていきました。

かたや、そういうものを基盤にしたというか、それも含めてサービス系のビジネスはもう桁違いの繁栄。それまでのソフトウェアを作るとか汎用機を作るとかパソコン作るなんていうところとは桁違いのビジネスで世界制覇ですね。今だいぶいろんなところで問題になっていますけど、GoogleとかApple、Amazon、Facebookとかがものすごい勢いで伸びてきている。完全に世界を制覇した。

私も30年ぐらいサラリーマンしてまして、昔、ボスが「ソフトウェアを制する者が世界を制する」って言ったんですけど、実際は「情報を制する者」の間違いでしたね。ソフトウェアぐらいでは、世界は制覇できなかった。

GoogleとかAmazonとかFacebookは、ちゃんとそれを見て成功しています。いつまで続くかわかりませんけど、今、そういうふうにものすごい勢いで変わっていっています。

ソフトウェアのマネタイズをどうするか?

そうしますと、品質関連、ここはなかなか(この大変化)についていけていないところですね。要するにソフトウェアのマネタイズ。なにでお金を取るか?

だけども、まだソフトハウスさんとかテストの業界とかは工数でお金を取ろうと(するビジネスモデル)。もちろん工数でお金を取るだけではうまくいかないわけです。要するに、品質そのものが変わってきたわけです。「それにお金を出す人はいったい誰なの?」という、品質のパトロンは誰かということを考えなきゃいけません。品質だけでは商売にならないわけですから。

そうすると、コバンザメみたいにどこかについていかなきゃいかんですね。「サメは誰か?」つまりパトロンになってくれる人に対しての品質保証を考えなきゃいけない。要するにマネタイズジングなんです。

そういうサービスを提供している人たちがどういう方法で……。これはいろんな社会学者がいま分析していますね。「Amazonって何業なの?」「Googleって何業なの?」。広告業でもありますね。いろんなものを、情報を使って新しいビジネスを(広げている)。

この業界の特徴は、新しいビジネスがものすごい勢いで伸びます。ところが、一晩で落ちちゃうんです。そのぐらい怖いところです。どんどんいろんなものを出していかないと、自転車操業じゃないともたない。膨大な開発をして、次になるものを用意しておいて、どんどん出していく。そのためにいろんなビジネスを(試行錯誤して)やる。

つまり、品質管理の点から見ますと、その次になるものをちゃんとサポートする問題と、なにかのリスクで一晩でダメになっちゃうものをどう抑えるか。このあとも少しお話ししますが、この2つがある意味で非常に大事になってきたという状況です。

「誰に対する品質か?」が、プロダクトの品質の時代からだんだん、これはもうみなさんよくご存じで、日本では「QCD命」っていまだ残ってますけど。そういう概念では対応できない。

ただ、OSSはそれを払拭しました。「品質保証? いや、それは扱う人が考えて選んでください。だから無保証です」という。でも実態は、そのへんに売ってるソフトウェアよりよっぽど高品質です。それはなぜかというと、みんなが見てるから。

変化する“品質”

そういうかたちに、品質の概念が変わってきて、ビジネスモデルにも非常に大きな変化があった。

情報サービスの品質。これは非常に大きな変化です。先ほどもちょっと触れましたが、受け取るお客さんに対しての品質保証。これは社会インフラ的になってきてますから安定供給しなきゃいけない。

北海道の地震で、電源とかいろんなものが止まっちゃいまして、大変な状況になって電力とかボコボコになったんですが。でも、さくらインターネットは保ったんです。私もさくらを愛用していますけど、すごいですよね。要するに、インフラとしてのクオリティが非常に大事になってきています。

それから、社会とか文化に対する品質ということが非常に言われています。情報そのものの質が議論されている。日本人は情報漏えいに非常に敏感ですからね。Facebookなんかボコボコ叩かれてますが、そういうことがあったら企業自身の存亡に関わる。

それから、情報が法律的とか道徳に違反するような場合。フェイクニュースもそうです。それから宗教とか文化に関して。(気をつけないと)今まで築き上げたビジネスがあっという間にポシャる可能性があります。

イタリアのあるメーカーが、中国の文化を侮辱してエラい騒ぎになった。ちょっとした、文化とかそういうものに対するクオリティが、もうあっという間に影響する。これも非常に今までとは違ったクオリティですね。こういうものが出てきてる。

いったいどんな技術とか手段を使って、それに対応していくのか? 要するに、ソフトウェアのQAでは、良否の判断ができないといけないんです。対象がプロダクトであろうがサービスであろうが、多様化したとしても本質は「これはいいですよ」「これはまずいですよ」を法則化するといいますか、なんらかのかたちで判断しなきゃいけない。

昔は、これが仕様書だった。仕様書をもとにすればよかったわけです。でも、ガラケーぐらいから仕様書がよくわからなくなって(笑)、大騒ぎになってきた。

さらに、サービスの時代は、仕様がありません。「これが正しい」こと自体を探していけなきゃいけないんです。これが現在、我々が求められている、サービスとかに対するQAです。

テストの本質は何か

テストの実態はなにかというと、実は仕様記述だったんです。仕様を正確に出して、それが何が正しくて何がおかしいかを決める。

これは2007年の日科技連の基調講演でも言いましたが、それを完全にはなかなかできません。だから「有則」といって「これは達成しなきゃいけない」「これは必ずこういうことが起こらないといけない」「こういう入力に対してはこういう結果にならなきゃいけない」というような、定められた特性。

それから「禁則」といって「これはダメだよ」「こんなことが起こったり、こういう入力でこんなことが起こっちゃいけないよ」「デッドロックが起こっちゃいけないよ」ということを仕様を定義した。

でも実は、大多数は「無則」なんですね。仕様とかには書いてない。法律にも書いていない。道徳でもちょっとグレー。だけど、なにか騒ぎになったら、そこでなにか起こっちゃう。この無則の部分がどんどん増えてきています。この部分が無害であるかどうかは確認しなきゃいけないんです。

これもQAというか品質の問題としては非常に大事で「じゃあお前どうすんだ?」と言われると、それはものによって違いますから、いろいろこれから考えていかなきゃいけない。けれども、鳥の目的に概念で見たら、こういうふうに分けて、そのサービスとかデータに対してこういうことがまずわからなきゃいけないわけです。良否の判断ができなきゃいけない。

それは非常に多様ですから、それに対してどうしていくか? なにが有則で、なにが禁則で、無則かはよくわからないけれど、社会がどんどん進んでいく中でいろんな事件とか起こってきて、わかってくるわけです。

現在はフェイクニュースが非常に話題になっています。Googleも、今まではAIでやろうとか言ってたのが、もう無理ということがわかったから、何千人という人を雇ってチェックしますって言ってます。それはなぜか? そういう姿勢を見せないと、企業の存亡に関わるから。

そのぐらい非常に短時間で、無則のところが変わってくるということです。ある意味で、そういうところのリスクを早く見つけられれば、QAとしては非常にContributorになれるんでしょうね。

OSSにおける品質もそうです。これはバグがあっても「使う側の禁則ですよ」という方法で回避していますから、従来のようなプロダクトに対して徹底的な品質保証をしようというものはもうぜんぜんありません。見つけたものをいち早く直すほうがいいですし、改造とか追加をするときには、全体に影響を与えないものづくりをしましょう。

GitHubなどが提唱するベスト・プラクティスでは、何かを提案する場合まずForkをしてプルリクエストをして、その開発方法は近代的な開発をしている多くの企業やプロジェクトで定着してます。

もう1つは、システムが非常に大きくなっていますから、変動するシステムの稼働品質。ゲームとかがたぶんそうでしょうね。レスポンスタイムなんかは非常に大きな問題です。ほとんどはたぶんスマホの中でローカルでやってますが、一部ネットにつなぐところがあったりすると、電力とか通信と同じようにいろんなかたちでリアルタイム制を保証していかなきゃいけない。

そうすると、なにか新しいものをリリースして、それがものすごい勢いで伸びたときに、全体に本当に影響を与えるか与えないかという評価もしていかなきゃいけない。等々、いろんなものがありますね。そういう変化の時代になってきた。

キーワードは「Contribution」

本論です。これからどうしようか? 難民にならないためにはどうしていけばいいか?

キーワードはContributionです。本当にそれができているかどうか、一番にわかればいいんだけど、わからないんですね。「いろんなリスクがありますよ。これが品質保証ですよ」と言っても、起こってみなきゃわからない。だけども、職業としては、それに対応するお給料をもらって、仕事をもらわなきゃいけない。

ということは「Contributeしますよ」って示さなきゃいけないんです。そのビジネスをしてる人たちに対して「新しいQAはContributeしているんですよ」ということを示していくことが、難民にならないための大きなキーワードです。

Contributionというものはいったいどういう特性を持っているか? Google先生に聞いてみればいいんでね。例えばAtomというオープンソース、これはGitHubがしゃかりきになって作っている、MicrosoftのVisual Codeと競争している。

(スライドを指して)そこを開けるとこういうものがあって、そのContributionはどれだけコミットしたか? 「このソフトウェアを作るのに3万5,000件ほどコミット」、つまりソースコードを直したりいろんなバグを修正したりしてます。それをやっている人たちは誰か。この、400名ぐらいの人たちがそれをサポートして仕事をしています。

その400名の人たちの中身はどうなっているかというと、Contributorのところを叩くとこんなグラフが出てきます。始まってから今までの変更の回数を週ごとに出したものです。毎週毎週、ものすごい勢いで直してますね。

普通、ソフトウェアのプロダクトとかプロジェクトは1年とか2年で終わっちゃうんですが、これは2012年に登録されて、登録の前からすでに開発してましたから、その状況が全部ログに残っていて、データに入っています。

それを見ると、なんとここの上位3人ほどで、8割ぐらいの仕事してるんです。この、1、2、3名と上にいますが、その3人、びびびっとなんか出てる人たちが継続的に仕事をしてて、全体の何割かをやってる。要するに、非常に少人数の人たちがそれを実践しています。

トップContributorの働き方

じゃあ、それをしてるトップの人はいったいどういう働きをしてるか?  (スライドを指して)これを見てください。

この人がAtom以外にもいろいろしてるんです。ここにどれくらいContributeをしてるか、どのぐらいレビューしてるか、仕様に対する提案をどのぐらいしてるかってレーダーチャートが出てくるんです。この人がどういうふうにContributeしてるかが完全にオープンになってる。

今までは、その人がどんだけ働いたかということは企業の偉い人、給料決める人にさえ言っておけばよかったんですが、それじゃあもう保たない。企業側もわからないんです。だから、評価自体もオープンして、どのぐらいContributeしてるかをちゃんと見ていこうという時代なんです。それが非常に功を奏して、ほとんどのオープン系はこの方法を使って評価し、人材を伸ばしていってますね。すごいです。

全体の評価を見ると、3万5,000件のコミットがあって、426名の人がContributeしているんですが、実際は全体の半分以上、8割〜9割をこの3名の人がやっています。すごい状況ですね。昔の製造業のように「みんなで公平に働こう」というような時代ではなくなってきたんです。

ほかのものも調べてみましょう。例えばLinuxを見ますと、Linuxは1年に調べたら参加人数は1万7,000って出たんですけど、最近調べたら無限と出てくるんですよ(笑)。貢献したい人がいっぱいいるんです。「誤字脱字1つでも直して、俺は貢献しよう」という人がいっぱい入っています。もちろん、Linuxもコアーメンバーが大きな貢献をしていて、何と、そのトップは実は日本人なんです。

それからGit。これも(Linuxと)同じように大きい。これも(コアメンバーの)、トップは日本人です。

なにを言いたいか? 日本人はこういう、持続的になにかをすることに対して、非常に能力が優れています。一見、今の時代、取り残されているように思うかもわかりませんが、非常にいろんなところで日本人の貢献が出てきています。

なんで彼らがそんなに貢献できているかですね。今までは(スライドを指して)こういう分布なんです。これはなにかというと、横軸に1番の人から400番までの人たちのどれだけ貢献したかをとって、縦軸に貢献の度合いを示したものです。冪(べき)分布と呼ばれています。

パレートの法則は2割・8割ですけど、そんなもんじゃない。ほんのごく一部Headのところがあって、あとはTailがざーっと(伸びています)。Tailが役に立っていないわけじゃないですよ。この人たちのおかげでいろんな提案とかいろんな仕様とかが決まってるし、サポートしてくれるし、ファンにもなってくれてる。

こんなことで、実際はこのAtomだったら、実はGitHubの社員が30名ぐらい入ってまして、その人たちが中心になって運用している。それ以外にファンの人たちがいろいろサポートしてる。ファンの人たちはいろいろで、調べるとゲーム業界の人とか、いろんな人がいて、けっこうおもしろいです。

トップが

こういう分布はこの時代のいろんなもの。例えば売上もこうなんです。売上の製品を製品順に調べると、やっぱりトップのものが圧倒的に売れている。映画の配給もそうですね。現在、映画の配給は年間ものすごい量がありますが、トップ5つぐらいでほとんどの利益が出てます。小さなソフトウェアでもそうなんですよ。お客様のメインのところの人たちが、売上のほとんどに貢献してる。

サービス系でこれが怖いのは、ある日突然なにかの理由でトップがダメになったとき。次のものが出てくればいいけど、出てこなかったら企業全体が危なくなる。昔のように正規分布、学校の成績みたいなものは、たぶんぜんぜんないです。こういう実態があります。

この中で、どういうふうにいろんなことを考えていくか? だから、鳥の目といいますか、広がりのところもあるし、深いところもある。こういうところを考え、Headの部分、Tailの部分をどう見て対応していくか?

そういうことを少し分析して、オープンソースのソフトウェアはどうなっているかについて書きました。これ、論文をそのまま持ってくればよかったんだけど、電気学会に著作権があるので持ってこれなかったので、参考資料ということにしています。

今年の6月ぐらいに出しました。けっこう私、老人ですけど、それなりに研究はしています。趣味で社会人大学院の人たちをサポートしてまして、そこの研究の一環で、こういうものを(GitHub API)出しています。

重要なのは知識よりもメンタリティ

最後、まとめです。要するに、この現代のビジネスというものが、さっきのベキ分布みたいにものすごい幅があって、それぞれのところに深さがあって、HeadとTailという概念で考えていかなきゃいけない。

だから、Contributeも対象がいろいろあるわけです。Headの部分をいかに伸ばそうかというContributionもありますし、Tailのところ、リスクの部分を広く見るQA活動もあります。プロダクト以外にもいろんなものがありますから、そういうところをどう見ていくか?

過去の価値観を捨てないと、なかなか次の時代に入っていけない。過去の価値観の代表としては、昔のソフトウェア開発では「ISO 9000」とか、いろいろありましたけど、規範を作ってた。私自身もISOとかいろいろ作って、貢献しましたけど、そういうものには甘えない。

プロセスを決めればものができる。そんなことはありえない。そんな世界じゃなくなった。だから、(一部の)QAの人たちはまだ「プロセスを一生懸命定義して」とか言ってますが、それはもうあかんでしょう。

たくさんの対象が、ベキ分布で広がっていますから、そこに実際に入らないといけない。座学ではもう無理なんです。一生懸命勉強して入ればできる世界ではありません。その世界に入って、cut-and-try、試行錯誤して、もがいていかなきゃどうしようもないんです。

そこに入っていこうとしたら、知識そのものよりは、どちらかというとメンタリティのほうが問題になってきます。未知のところに入っていくわけですから。

キーワードとしては、ポジティブ心理学。現在は、Flowといいますか、熱中できるようなかたちで仕事をしていかないと、なかなかこの世界に入っていけない。中途半端なかたちでは難しくて、本当にそこに物事を忘れるぐらい熱中しないと、なかなか成功しないんじゃないか。こういうお話でございます。

ちょっととりとめのないお話でしたけど、以上でございます。まだ時間、ありますか? あればQ&Aを。

品質を規格で定義できるのか?

司会者:松尾谷様、貴重な講演をありがとうございました。まだ少しお時間がございますので、質問を受け付けたいと思います。質問ある方、挙手をいただけますか? では、真ん中の方、お願いします。

質問者:ご講演ありがとうございました。1点質問です。

(スライドに)「捨てる代表は、規範やプロセス定義」と書いてて、例としてISOという話があったんですが、例えばISO9126は、品質モデルとかどうやって測定するかということが書いてあって、守破離の守として学ぶべきところだと思います。そこを捨てるというのは、自分が間違った解釈をしてるのかなと思ったんですが。

そういった意味で、「捨てる代表」とは、具体的にどういったものを想像されているのかをおうかがいしたいです。

松尾谷:品質特性ができた時代と対象がぜんぜん変わってますから、今までの枠組みでは測れないという意味です。

だから、さっき言いましたように、フェイクニュースの品質をどう測るか? ということです。確かに、概念的にはそういうフレームワークで測れるかもわかりませんが「具体的に何なの?」というところを出さなきゃいけない問題です。

そこを規格から求めることができるかどうかについて、疑問に思っているんです。それで「そういう概念よりは、現実から測っていったほうがいい」という意味での「捨てたほうがいい」でございます。

質問者:どうもありがとうございました。

司会者:よろしいですか。では、ありがとうございました。

松尾谷:どうもありがとうございました。

(会場拍手)

Occurred on , Published at

DeNA QA Night

DeNA QA Nightに関するログをまとめています。コミュニティをフォローすることで、DeNA QA Nightに関する新着ログが公開された際に、通知を受け取ることができます。

このログの連載記事

1 テストの広さと深さ、どっちが大事? ソフトウェア開発における品質を考える - Part1
2 テストの広さと深さ、どっちが大事? ソフトウェア開発における品質を考える - Part2

スピーカーをフォロー

関連タグ

人気ログ

人気スピーカー

人気コミュニティ

ピックアップ

編集部のオススメ

ログミーTechをフォローして最新情報をチェックしよう!

人気ログ

人気スピーカー

人気コミュニティ

ピックアップ

編集部のオススメ

そのイベント、ログしないなんて
もったいない!
苦労して企画や集客したイベント「その場限り」になっていませんか?