【連載】QAの変遷を語る： イデソン代表・誉田直美氏「時代は変われどもQAの基本は不変、バグは少なくすべき」

——まずは、QA・テストに関わることになったきっかけを教えてください。

私は日本電気株式会社（以下、NEC）に1982年に新卒で入社し、ソフトウェアの品質保証部に配属されました。当時はメインフレームコンピューターの時代で、その基本ソフトを開発するためにNECで最初にできたソフトウェア専門部隊の一員となったのです。

ただ、私はモノづくりがやりたくて入社したのに、テストをしろと言われて「なんだよ」という感じでした（笑）。すぐにでも転職したかったのですが、当時は転職先がそうそうなかったので、せめて何か資格くらい取ったら転職しようと思っていました。

最初の1年くらいはそんな心持ちで働いていましたが、仕事自体は忙しかったです。メインフレームコンピューター全盛期だったので、開発すべき機能はたくさんあったからです。しかし、開発プロセスや開発技術が未整備で、個人の力量に依存する開発だったために、モノを作ればバグが出る状態で、品質が悪いことが問題でした。基本ソフトの特性上、不具合があるとコンピューターが止まってしまいます。毎日のようにシステムダウンが起きては、そのダンプリストが磁気テープに記録されて、私がいた府中の事業所にバイク便で届けられました。

バグが多発する状況があまりにも続くため、経営幹部層が「これはどうにもならない」と問題視するようになりました。そこで私は指示を受けてバグの数を減少させる道筋を示したグラフを作成しました。「品質10倍作戦」と呼ぶ、現在の出荷後のバグ数を5年で10分の1にしようという目標でした。

当時の品質保証部はバグ取りの業務が中心で、正直つまらなかったのですが、このような改善の取り組みがきっかけでソフトウェア工学に基づいた活動を始めることになりました。実のところ、それまでソフトウェア工学には縁がありませんでしたが、ある時会社の図書室でソフトウェア工学の論文を見つけ、こんな世界があるのかと気付いたのです。そこから興味が出てきて、ツールを見つけてきては試すようになりました。

品質10倍作戦では、まずは自分たちが何をやっているのかを可視化するべく、開発に関するデータを取り、開発途中の品質管理を始めました。しばらくすると開発部門から出てきた開発データの紙が私の机に積まれるようになりました。そこに書かれているデータを入力、整理、分析して上司に報告しました。それが「イエローブック」と呼ばれる、年に1回発行のデータ白書になっていきました。黄色い紙に印刷したのは、白い紙だとどこかに紛れてしまうけれど、黄色だと目立つからです。

このようにして20年かけて作り上げたのが「品質会計」というソフトウェア品質管理手法です。品質会計の特徴は、上流工程でできるだけ品質を良くする、バグを取るということを重視すること、そしてテスト終盤の残存課題を全て解決してから出荷すること、この二つがベースになっています。

ちなみに、先ほど私が品質10倍作戦のグラフを作成したと言いましたが、実は作れと指示されたから作っただけで、私自身は当初、「本当にこんなことできるの？」と疑心暗鬼でした。そして、人事面接のときに部長に「可能だと思っているのですか？」とぶつけたところ、その部長は「本当に真剣になってやったら実現できると思うよ」と答えました。そして実際に目標を達成したのです。最終的にはバグの数が10分の1どころか、20分の1になりました。

この時に、品質を良くするというのはマネジメントの意志の問題であり、組織で品質改善に取り組むことが重要だと実感しました。

——どうやってバグを20分の1にまで減らしたのでしょうか？

本当に地道なことです。品質は「プロセス品質」と「プロダクト品質」の両面だとよくいわれますが、私たちの改善活動のスタート時はプロダクト品質だけでした。つまり、製品が出来上がって、バグがなくなるまでテストするというアプローチです。テストを今までの何倍もやってバグを出し、バグがなくなるまで出荷しないという考えから始まりました。しかし、それだといつまでたってもバグはなくならないから出荷できないのです。

そこで「元から絶たねばならない」と考え、上流工程のレビューに力を入れるようになりました。すると大元の製品設計がきちんとできていなかったわけですから、レビューをするとバグがたくさん出る。それを修正して再度レビューすると、またバグが出る。そのサイクルが収束するまでレビューをしようと決めました。

バグがどれくらいあるかという予測モデルも並行して開発し、その工程で作り込んだバグの8割程度のバグを出せば次に進んでいいというルールを設定しました。100%は無理ですから。それが一番品質向上の原動力になったと思います。

プロダクト品質、そしてプロセス品質に取り組むようになって2〜3年で状況は大きく改善しました。世の中が見えるようになったといいますか、どこがおかしいのかが分かるようになりました。

——その後、キャリアはどのように進みましたか？

私は基本ソフトの開発部門で品質保証をずっとやっていましたが、上の人たちが社内のいろいろなソフトウェア開発部門に散らばっていくにつれて、品質会計という技法が全社的なデファクトになっていきました。

ところが、残念なことに品質会計の名前だけが先行して、バグ数のつじつま合わせだけが広まってしまいました。そこで、正しい品質会計を広めるために「ソフトウェア品質会計」という本を書きました。

その後、2002年ごろに本社に移りました。そこでNEC全体のソフトウェア品質向上に携わるようになりました。さまざまな部門にアプローチしていくわけですが、当初は門前払いのような扱いも受けたし、前時代的なことを言う人もたくさんいる中で、やはり信頼してもらえるようになるまでが大変でした。

人手も足りなかったので、いろいろな部署を回り、「2年で育成するから人員を貸して」とお願いして7〜8人集めました。そのメンバーを使ってデータを集めたり、分析したりしていると、次第に出身部署の人たちも、私たちの活動に関心を持ってくれるようになりました。

加えて、「こういうことをやったら品質が良くなる」「生産性はこうすれば高まる」といったことがデータで見えてくるようになったため、年に1回、説明会を開催して全社に共有しました。海外拠点も含め、とにかく足を運んでは直接説明しました。そうした取り組みを続けてようやく認知されるようになるまで10年くらいかかりましたね。

——10年も！

そうです。データだけ見ても違いが分からないため、直接話をしたり、実際の状況を説明したりする必要があります。私が退職する頃には、育てた人材を元々いた組織に戻し、その他社内でも品質保証に関わる人材が増えていました。現在はその人たちが中心になって活動を継続しています。

——ちなみに、社内の認定資格制度である「NECプロフェッショナル認定制度（NCP）」において、品質保証のプロフェッショナル枠がなかったのを、誉田さんの活躍によって生まれたとか。

当初は全社のキャリアパスの中に品質保証はありませんでしたが、上司だった役員が私を想定して作ってくれたようです。ただし、認定試験はかなり厳しくて、面接官である役員2人と社外の大学教授2人に1時間くらい質問されます。必ず合格するわけではなく、落ちる人もたくさんいましたよ。

——NECが品質会計の確立を進めていた頃、他社の品質保証に関する取り組みはどうでしたか？

他も同じような状況だったと思います。日立や富士通もそれぞれのやり方で品質保証を進めていました。

そうした企業との交流の機会はあって、日本科学技術連盟が設置するSQiP（Software Quality Profession）の前身であるSPC（ソフトウェア生産管理研究委員会）では、メインフレーム製造会社の品質保証部長が集まり、（元東京理科大学の）菅野文友教授の号令の下、お互いの取り組みを発表する会合が毎月開かれていました。

私も若い時にSPCの研究会に参加させてもらい、他社の方々と議論して勉強になりました。また、SPCの調査団として、インドや中国、あるいは欧米を訪問する機会もありました。

印象に残っているのは、30歳の時にノルウェー・オスロで開かれたソフトウェア品質シンポジウムで発表する機会があり、NECで取り組んでいる品質保証について話したところ、非常に高評価を受けたことです。

——それは日本の品質への取り組みが先進的だったからでしょうか？

というよりも、真面目にやっていたからです。誰もが「やればいいと思っているけどできない」と感じていたところに、「日本の会社は本当にやっているのか！」という驚きがあったのだと思います。真面目かつ実際に取り組む。そこが日本人の良いところですし、強みなので今後も残すべきだと感じています。

——80年代から現在までQA・テストの世界に身を置いてきた中で、最も大きな変化は何だったと思いますか？

私にとっては全部つながっている話であり、QAとしてやるべきことの観点は基本的に変わっていないと思います。例えば、プロセス品質とプロダクト品質の関係はアジャイル開発においても同じです。

ただし、サービスという世界になると少し違うと思います。アジャイル開発までは「バグの少ないソフトウェアを効率良く作る」ことに焦点がありました。しかし、サービスになると、例えばGoogleが提唱するソフトウェア開発チームのパフォーマンスを示す指標「Four Keys」のように、バグが少ないことよりも、顧客から見てバグがないように見える（バグがあっても素早く直す）ことや、アイデアを短期間で実現することが重要になってきます。

とはいえ、バグをすぐに直せばいいからといって、バグがあっていいわけではありません。バグがあると修正対応のオーバーヘッドがかかるし、開発にも影響が出ますからやはり少ない方が好ましいです。そういう意味では従来と根本的には変わらないのですが、パフォーマンスを測る視点が変わってきている気がします。

私の経験から、効率良く製品を作るためのコツは「後戻りをいかになくすか」ということです。後戻りの最たるものはバグで、バグは後工程になればなるほど修正に時間がかかります。だからこそ上流工程での品質管理が大切です。アジャイル開発でも同じで、最初から良いものを作ることは変わらないはずです。

——今後、QAエンジニアに求められるスキルや知見はどのようなものでしょうか？

NECにいた時には、QAだけでキャリアを積むのではなく、開発グループでも一定期間仕事するようなキャリアパスを作るよう働きかけました。テストやQAだけでなく、いろいろな経験をする中で最終的に軸足がQAにあるという形が望ましいです。

それと、世の中がどうなっているかという広い視野を持つことが重要です。私自身が周囲から尊重された理由は、世の中の技術動向を知っていたからだと思います。新しいことが好きで、他社の人とも付き合い、講演依頼があれば基本的に断らないようにしていました。その結果、さまざまな情報が自分のところに集まるようになりました。だから社内外の人たちに「ここに来ると何かが得られる」と思われるようになったのではないでしょうか。

私はNECにいた時に作ったネットワークが今も生きています。現在は起業して、一人で仕事をしていますが、営業はせずとも声をかけてもらえています。改めて外に出ることの重要性を実感しています。