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

テストの広さと深さ、どっちが大事？

松尾谷徹氏（以下、松尾谷）：こんばんは。ご招待いただきまして、ありがとうございます。お集まりいただきましたみなさまも、ありがとうございます。

今日は、従来の「テスト」という言葉より少し広い範囲で、現在のビジネスといいますか、市場がどういうふうに変化しているか。また、それに対して、従来のQAという概念からどう離脱して新しい分野に入っていくか？　今まさに、産業界、ビジネスが非常に大きく変わろうとしていますので、そのへんについて、老人が少しお話ししようと思います。

長い間この分野に関わってましたから、それを少し整理して。「こうだ」じゃなくて、あくまで「老人にはこう見えてるけど、どんなもんですか？」という私見で、お話ししたいと思っております。

どんな内容かといいますと（スライドを指して）ざっくり絵で表すとこんな感じです。ちゃんと描くの面倒くさかったから、ポンチ絵ですけど。

（会場笑）

1つは、非常に大きな市場の変化が起こっています。昔の、大きくは3つぐらいの時代に分けて、その市場の変化。それに対してソフトウェアの技術も非常に大きな変化をしている。その中で、QAというかテストというか、そういう1つの職種があって、これがどうなっていくかということです。

まだまだ続くとは思いますけれども、時代の変化とともに昔の領域、ソフトウェアのプロダクトに対するQAは、全体のビジネスの大きさからすればだんだんシュリンクしていく。すると、その技術でそのままやっていたら、QA難民になっちゃう。

そうじゃなくて、この新しいビジネスとか新しい技術の中で、なんとか貢献できるようになろう、Contributorになっていこうということです。そのために、分岐点といいますか、今までの技術だけではなくて、新しいところに入っていかなきゃいけない。

今日はその「新しいところっていったいなんなの？」ということを少し考えようという趣旨で、資料を作ってまいりました。

誰に対する品質なのか？

誰に対するお話か？　基本的には、今お話ししましたように、この業界といいますか、テストとかQAとか、どちらかというとスタッフ的にものを作る・サービスを提供するところ、ラインをサポートするようなところで、どういうふうにサポートしていけばいいか。

これをちゃんとしないと、いま本なんかで話題になってる、この先、絶滅危惧職種というものがある。そこにQAとか品質保証とかが載っちゃうとまずいわけです。そのままだと、確実になっちゃう。だから、中身を変えていかなきゃいけない。

どう変えていけばContributorとしてさらに発展できるか？　ということで、こういう業界に興味を持っている、実際に何年か仕事されてきた方々、ぜひ一緒に少し考えていきましょうという内容でございます。

観点はなにかというと、まず品質がだいぶ変わってきています。とくに「誰に対する品質なのか？」というところです。昔はプロダクトだったから、お買いになった人たちだった。現在はサービスになっています。そうすると、ぜんぜん違った品質特性を持っていることになる。

それをどういう方法で達成するか、達成するものはいったいなんなのか？　というところです。プロダクトのクオリティとサービス、とくに現在はネットを通して提供するいろんなサービスに対して、受け取る側はどういう品質を待っているのか？

非常に大きな変化が起こっています。今までは（プロダクトを）受け取るという特定の方だったのが、すでに相手が地域だったり国家、宗教、そういう社会に対する品質について議論しなきゃいけない段階になってきた。

そのためには、今のようなプロダクトのクオリティとはまったく違った品質特性、どちらかというと社会科学的な、そういう品質について考えていかなきゃいけない。そのぐらい、現在のサービスは大きな影響を与えるようになりつつあります。そこを考慮して広げていく必要がある。

ということは、そういうものを測らなきゃいけないですよね。測らないことにはコントロールできない。じゃあどういうふうにしてそれを測るか。それも、現時点で存在している値だけではうまくいかないわけですね。どんどん変わっていくわけですから、モデル化して「こういうことをしたらどう変化するか」（を測らなきゃいけない）。

アナリシスとシンセシス

今大きな流れとして、フェイクニュースの問題がありますね。あれは、国家に影響するぐらい非常に大きな影響力を持っています。そういうものが起こったとき、どういうふうに影響して、次にどう取り締まりや規制がかかって、それに対してビジネスはどうしていけばいいのか。非常に大きな流れを読んで、ビジネス的にも、クオリティの対象としても、考えていかなきゃいけない。

従来のような、作ったソフトウェアのIF分や分岐網羅がどうだこうだという、ミクロな世界だけでは済まない。ぜんぜん違う広さがある。

科学的には「アナリシス」と「シンセシス」という概念ですね。アナリシスは、細かいところを一生懸命見ていって、原子構造がどうだとか……（ソフトウェアでは）そこまでいきませんけど。要するにソフトウェアでも「原因はなにか？」を細かく見ようという技術的なアプローチです。それに対して、シンセシスは「統合していって、いろいろなものを組み合わせたときにいったいどうなる？」という考え方です。

ほかにも「虫の目」「鳥の目」といった言い方をしますね。この両方が必要になる。とくに「鳥の目」のほうです。

ソフトウェアでは、今までどちらかというと、小さなコードとかシステムとか状態とか、そういう細かいところに対する技術はそれなりに発展してきたんです。でも「こういうサービスを提供して、こういうことが起こったらどうなるか？」という、広い視点、鳥の目的なものがちょっと欠けている。これからはそちらのほうがどんどん広がっていくということです。

じゃあ、どういう技術や手段で達成していけばいいか？　要するに、自分たちの持っているパフォーマンスをどうやって発揮するかですね。

それから、大きく変わっていくことはもう明らかですから、残念ながら過去のものを捨てていかなきゃいけません。これがなかなかきついわけです。そのために、どういう心意気で、どう学んでいくか？　

最後のところは、モチベーションというところに落ち着くんですけど、そういう人材育成とか、どういうふうにして進んでいくのかというテーマで、少し考えていきましょう。

IT業界の市場の変化

まずは、市場の変化をざっくり見ていきましょう。どういう変化が起こってきたか？

IT大昔、正確には1993年ぐらいですか、IBMさんが突然大リストラをした。50歳以上の社員を全員クビ（笑）。「この人残す」とか「残さない」とかってね。この先、今のビジネスを続けていくと将来がないってことで行われた。日本はまだバブルの最中ですから、すごい時期だったんですけど。（スライドの図は）それまでのビジネスモデルですね。

このモデルは、汎用機メーカーさんがハードウェアを売ろうと（していた）。ですが、ハードウェアを売っても、ソフトウェアが難しいからなかなか買ってくれない。

そのとき、お客さん側はコンピュータをどう使ったかというと、多くの企業は合理化をしようとした。それまでの事務作業、例えば伝票処理とか帳票処理とか、バックエンドの作業をコンピュータで置き換えようと。

ただ、簡単なソフトウェアなので、若い人たちに3〜4ヶ月COBOLの演習でもさせて、実務の人に（プログラムを）書かせば書ける。そういう世界です。EDP部門が中心になって、それをやる。

汎用機メーカーはハードウェアを作って。原価率45パーセントとか40パーセントぐらいでしたからね、すごい儲かるんです。そのためにOSとかソフトウェアをタダで提供します。

ただ、OSは品質問題があるので、この時代の品質、まともな品質保証ができたのはメーカーのOSの部隊だけです。独立的な品質（保証）ができたのは、日本の場合は日立さん。まぁ、IBMさんもそうですね。その2社ぐらいしか、本当に独立した品質保証をやっていなかった。あとは、わりと部門の中の品質。

私もある会社でOS開発に従事していましたが、そこで突然「お前、品質やれ」とか言われて、ACOS-6という汎用大型機をやり始めたんですけど。そこで開発部隊の中に品質部隊ができる程度でした。83年ぐらいのことです。

日立さんなんかはすごいです。工場単位に検査部門がありまして、設計・製造・検査という三権独立になってる。ハードウェアの検査の部隊が、そのソフトウェアのクオリティを検査する。だから、発電機とか列車を作るような、そういう非常に大きな安全系の概念を持った人たちが中心になって作ってるということです。

IBMさんも品質保証の部隊を持っていました。でも、これはまったく違った活動です。ソフトウェアの品質は、IBMさんからすれば、競争相手と比べてもまったく心配はないんです。

なんで品質部門ができたかというと、独占禁止法です。当時、IBMさんは独占禁止法に引っかかって、会社が分割されるような大危機に瀕したんです。

たくさんの事業部の中の、ある事業部が、ペーパーマシンを出しちゃったんです。出荷できないんだけど、競争相手に対して有利になるためにすごいスペックのあるシステムをね。それがBurroughsから訴えられまして、独占禁止法の疑いで会社が潰れかけたんです。

それで、品質保証部隊ができた。つまり、事業部が勝手なことをしないように、社内を取り締まるための部隊としてできていったわけです。品質の良しあしとは、ぜんぜん違った意味の品質なんですね。

開発を重視してテストの比率が低くなっていた時代

日本の場合は、我々のところもそうでしたけど、やっぱりOSも、どこかの大きなメーカーにお客さんのところへ行って、テストでパッチを作ってたというような状況でしたから、ちょっとレベルが違ってました。

私達の場合もまったくそうでして、開発者たちがすごくがんばってソフトウェアを作ります。リリースごとにどこかが火を吹いちゃうんです。冷静に調べたらなんのことはない。非常に優秀な人たちが作っているんだけども、算数ができないんです。

算数ができないというのは、リリース時期までにいろんな機能を作らなきゃいけない。コンパイラなら新しいコンパイラ機能を作らなきゃいけません。それが半年とかある。そしたら一生懸命開発するんです。開発したらテストをしなきゃいけない。けど、リソースは半年という期間に限られているんですね。開発に多くの比率を使ってしまって、テストの期間が短くなって、ボコボコになっちゃう。ほとんどはこのパターンなんです。

ソフトウェアというものは思ったとおりにはできませんから、作れば必ずデバッグテストが必要です。それをどうするかという割合が、なかなか難しい。みんな作るほうにいってしまうから。登山家が山に登って、降りてこなきゃいけないんだけど、登るのに一生懸命になって、降りてくるときに遭難しちゃう。そういうパターンなんです。

これを第三者が検証しようとしても、コンパイラが難しいとかなんとかで、人海戦術じゃもうどうしようもありません。私はどうしたかというと、今は別のかたちで流れてますけど、「品質会計」というちょっと怪しいものを作りました。

作ったらテストの分（リソースが）要るだろう。そのバランスをちゃんと会計しなさい。要するに、お金をいっぱい使ったら家庭が崩壊するみたいな状況ですから、作った量とテストの量をちゃんと考える。1回目になにをやっても、それで1回失敗すれば、開発量とテスト量の簡単な会計をして、自分たちのバグ生成係数を理解すれば、必要なテスト量がわかるわけですね。それで始めたのが品質会計です。

日本におけるテストの変遷

最近、品質会計の（話が）出てますが、あそこでは「誰が作り出したかわからない」って書いてますけど（笑）。私としては、品質会計はそんなにいいものだと思ってなかったので、あんまりほかには言ってないんですが。そういう会計をしていきましょうというシステムで始めたものです。

でも、テストも大変でした。その頃、テスト業務もいろいろやりましたが。OS関連のテストは、業務の合理化を行うアプリケーションと比べて難しいテストが多かったんです。

じゃあ一般的な情報サービス産業、ソフトハウスさんなんかがやるプロジェクトはどうだったか？　たいていプロマネの1つとして、プロジェクトの中にテストがある。

期間を決めていろいろテストをしていく。技法とかそういうところはあんまりなくて、スケジュール、進捗管理を中心にしたものでして、この時代は、アプリケーションのところにはあんまり本格的なテストはなかった。

それからは、工数はメーカーがマシンを買ってもらうために提供しましたから、日本のIT産業はちょっと違った状況といいますかね。

プレイヤーは汎用機メーカー。（当初基本）ソフトはおまけ。アプリケーションはユーザーのEDP部門が中心です。既存事業の置き換えですから、ロジックとかアルゴリズムにはそんなに難しいものはありません。汎用機メーカーが（ハードを）売るために、（メーカーの）営業側が工数を無償で提供して、そういうレンタルの競争をしたという体です。メーカー側のアプリケーション開発の人員が無かったので、日本のソフトウェア産業にお金が流れました。工数で精算する商文化はこの時から生まれました。

品質関連は、メーカーOS開発が組織化して、一部、品質保証（になった）。その頃の本が今でもたくさん残っていて、ある意味で現在の品質保証と言われているフレームワークは、この時代に作られた。代表的なのは日立の保田（勝通）さんとか。そういう人たちがお作りになった。

私も企業にいたとき、品質保証の部隊を作るときに、保田さんとIBMの大場先生にいろいろ教えてもらった（笑）。その頃は、この分野の人たちって、わりと業界全体で付き合いがあったんです。社内で聞いても、知ってる人がいないんですね。誰も（教えてくれる人が）いませんから、個人でいろいろ情報を交換していた。

アプリケーションのほうはプロジェクト管理の一環でしたね。

Web系ビジネスの登場

そういう時代があって、93年の大リストラのあとはどうなったかというと、IBMさんの予想どおり、汎用機がどんどんピークを通り越して落ちていきます。エンタープライズ系のビジネスは、どちらかというとオープン系のLinuxを中心にしたサーバ系にどんどん移っていきました。

それ以外に、組み込み系のビジネスがだいぶ盛んになってきました。携帯ですね。それからカーナビ。要するに、今まで小さいものしか作ったことがなかったところが、突然でかいものを作らなきゃいけなくなった。そういうところですね。

もう1つは、Web系。これはどちらかというと、最初はホームページのような小さいものを作るところから始まって、その後AmazonとかGoogleとかでかいものが出てきて、小さいところと大きいところに分かれていきます。

小さいところは、Web系のビジネスです。2000年頃は、例えば自治体がWebのホームページを1個作ろうと思ったら、1,000万とか2,000万ぐらいお金がかかっていました。それがちょっと経つと、WordPressなんかを使えば簡単にできるようになって、30〜40万になってきた。最近は1ページあたり4万とか5万ですからね。大企業ではもうビジネスになりません。

しかも、そのクオリティの対象はなにかといったら、一番はデザインです。ソフトウェアのバグとかは（問題になりません。）ほとんどパッケージ、それもオープンソースのパッケージでできちゃいますから、（プログラミングやデバッグ）そういうものはもう必要ない、という大きな変化をしていますね。

これがサブプライムショックが起こるぐらいまでの、ちょっと昔の市場構造です。これ以後もいろいろ残っていますけども。

汎用機ビジネスの終焉

このあたりで汎用機ビジネスが終末を迎えました。ほとんどの大型機はダメになってきている。都銀さんは残っていますが、あれは変えたくないんじゃなくて、変えられないんです。システムがあまりにも複雑で置き換えられないから、そのまま使ってる。だから、この先もお使いになるらしくて、メーカーはそのために必要な機材を用意していますね。

一方、パソコンのほうはすごい勢いですね。Microsoftがものすごい勢いで展開している。

それからソフトウェアのほうも。この1つ前の時代は、垂直分散といって、データベースからコンパイラから全部1つのメーカーが（自社のマシン向けに）提供するやり方だった。これは、お客さんにとっては非常にクオリティが高いんです。なにか問題が起こったらそこ（メーカー）に文句を言えば直してくれるから。

ところが、やってるほうはもう無理なんです。非常に複雑化してきて、会社として応えることが難しくなってきた。

そこで、水平分散になった。Oracleさんとか、もうデータベース1本で、ほかとのつながりは使った人が責任持ってくださいっていうやり方ですね。システム全体の責任なんてとても持てない。そういうふうに、だんだん水平分散になってくる。こういう時代ですね。

メーカーも、垂直分散でものを提供することがだんだん難しくなってきた。ここで、90年前半まで栄えたメーカーといいますか、汎用機の時代は終わって、同時に日本の電機メーカーはだんだん力をなくしていきました。

90年ぐらいまでは、自動車と電機は同じぐらいの輸出額で、日本の大きな産業だったんですけど、戦略が悪いのか時代に対応できなかったのか、現在はもう輸入のほうが多いんですか。逆転しちゃいました。

今度は、組み込み系です。一時期、2000年のちょっと前ぐらいから携帯電話等々がものすごい勢いで伸びた。今ではガラケーとか呼ばれてますが。その次に、カーナビとかAVとか家電機器にソフトウェアが入って、非常に栄えてきました。

もう1つは、Web系の新ビジネスですね。急激な成長、裾野の拡大等々が起こってきた。

ガラケー、カーナビの品質問題

ここで品質環境を見てみますと、非常に大きな問題になったのが、ガラケーとかカーナビの品質問題です。結局、人海戦術しかなくて、このときにたくさんテストの企業が生まれた。

要するにEnd-to-Endです。最後の段階で評価をして問題を見つけて、それを直していく。ものすごい時間と工数をかけてやっていましたね。それでも商売になるぐらい、そのときは繁栄したといいますか、進んでいきました。

そのときにテストとか品質保証という、要するに工学的な技法で解決できなかった。どちらかというと負け犬の遠吠えというか、実践の場である携帯では火の手がガーッと上がって、カーナビでしっちゃかめっちゃかになった。

あとからみんな「こうしたほうがいい、ああしたほうがいい」とは言ったんですが、本当にソフトウェア工学を使って成功したところって、ないんです。残念ながら、最初からこうすればこういう混乱はなくて、そこを勝ち抜いたメーカーとかソフトウェアのところがあったかというと残念ながら少なくて、結果的には、あとからいろいろ議論もされたんですけど、うまくいっているところはあまりいません。

現実にガラケー、携帯で大混乱が起こって、その後カーナビで火が上がった。まったく同じような形態、状況で混乱が起こっている。対処方法もあまり変わっていません。

現在は、車系だとメーターとかの表示系、要するにGUIが入ってきますから、簡単に仕様を決められないし、その仕様が本当に正しいかどうかもよくわからない。「正しいってなんなの？」っていうね。

使いやすさとか、（基準は）いろいろあるわけですよね。そうすると、そういうものをどう評価するか？　ということです。

やっぱりうまい方法はなくて、みんなソフトウェア工学的に「モデルが大事だ」とか「アーキテクチャが大事だ」とかいろいろ言うんだけど、それでうまくいったかというと、あとからはいろいろ言えるけど、なかなかうまくいってない。

そうやっているうちにブームが去って終焉しちゃう。こういう状況なんですね。