【連載】QAの変遷を語る：ベリサーブ・江澤宏和さん「何をもってテストを終わりとすべきか」を問い続ける

——QA・テスト業界でどのようにキャリアをスタートされたか教えてください。

1992年に、ベリサーブの前身である株式会社CSK（現SCSK株式会社）に入社し、IBMのPCホストコンピューターのエミュレーターのテストからキャリアをスタートしました。開発とテストではチームが分かれており、新人はまずテストチームに入るという形でした。当時は、テストを勉強してから開発へ、というキャリアパスが多かったと思います。

1995年にWindows95が出てきて、さまざまなパソコンとその周辺機器が販売されるようになりました。このような時代背景で最初に私が携わったのは、プリンターやデジタルカメラ、スキャナーに対する互換性テストでした。各機器をPCと接続した時に、うまくつながらないような問題を発見するという観点での互換性テストです。

基本的には一括請負での業務でしたから、かけられる工数には限りがあります。このため、さまざまなパソコンとの接続環境を選択する際には、納期とかけられる工数から最適な組み合わせが選択できるよう、おのずとお客様に提案していました。そいういう点では、お客様に鍛えていただいたように思います。

次に携わったのが、カーナビゲーションシステムでした。ベリサーブのビジネスとして、「フルライン検証サービス」という名称でのワンストップサービスの立ち上げを兼ねた業務でした。ワンストップとは、開発の上流から下流まで、お客様にとってベリサーブがワンストップで支援する、ということでした。

QAについては、私自身が実施するというよりは、管理者という立場で以降のプロジェクトに携わるようになりました。テスト自体をどのように回していくべきか、開発を含めプロジェクト全体をどのようにリードするか、といったところで苦労しましたが、テスト工程だけにとどまらず、開発工程全般を俯瞰（ふかん）するという視点を持つことができましたので、良い経験を積めたと思っています。

——最近はどのようなテスト業務に取り組まれているのでしょうか？

直近だと、自動車メーカーでIVI（In-Vehicle Infotainment）のシステムテストに携わっていました。

私自身はマネジメントの立場から、テスト仕様書やテストケースなど、テストウェアをテストの設計段階でレビューすることが多かったです。レビューを行うことで、お客様（自動車メーカー）へチームが作成したテストウェア（テスト工程の成果物）の説明根拠を示すことは大切なのですが、それだけではなく、テストを収拾可能な範囲で収められるテスト設計になっているかどうかも重要です。

分かりやすく言うと、私のチームメンバーの休日を担保できる工数内にテストが収まり、かつ合理的なテストになっているかどうかも、レビューでポイントを押さえるように心掛けました。ですから、「レビューで協議したことを言語化できるようにしなさい」ということは、メンバーに指導しています。他にも、お客様を巻き込みながら、レビューそのものを洗練させていきました。

——どのようにして、ソフトウェア品質やテストの知見を深められたのですか？

現場で鍛えられたのに加え、ベリサーブ社内のシステム検証研究会（以下、研究会）という活動に参加することで、知見を深めることができました。この研究会自体は、私が入社した1994年から始まっていたのですが、私が参加したのは1997年からです。

というのも、入社当時はそういった活動に参加する余裕もなければ、興味もなかったからです。そのような中、ある先輩から研究会を推進するチームに入らないかと誘われたことをきっかけに、本格的に研究会の活動に取り組むようになりました。研究会に参加するメンバーと、さまざまなテストに関わる話をしていくうちに、テストの技法や方法論、理論などさまざまなことを考えるようになりました。

研究会での活動で、システムテストに適用できるテストの種類（ISTQB用語ではテストタイプ）を整理しようということになりました。当時は「システムテストカテゴリ」と定義したのですが、カテゴライズすることで、どのようにテスト分析、設計、実装に生かせるのかをテストタイプごとに担当のメンバーを振り分けて提案しようということになりました。私はボリュームテストを担当したのですが、研究会には顧問として、品質に造詣が深い大学の先生も参加いただいており、先生方からアドバイスを頂きました。また、研究会の主要メンバーである先輩方からもさまざまな示唆を頂くことができました。

ボリュームテストを手順化するために、大容量、総数（ボリューム）といった形でパターン分けして整理しました。これは実際に私がテスト管理を行っていた業務アプリケーションでのテスト経験に基づいたものでした。このパターン分けについて研究会で報告した時、いつもは厳しいコメントばかりの中條先生（中央大学理工学部ビジネスデータサイエンス学科　中條 武志 教授）から、お褒めの言葉を頂き、とてもうれしかったことを覚えています。

——テスト対象となるソフトウェアがどのように変遷していったと思われますか？

私が新人だった1990年代から10年スパンくらいでお答えしたいと思います。1990年代は、私自身が携わったパソコンに搭載されるスタンダードなアプリケーションのテストであれば、周辺機器に接続できるかどうか、という観点でのテストが多かったと思います。

PC/AT互換機が登場し、DOS/V機へとトレンドが移る中で、パソコンに接続するためのインターフェースが日進月歩だったことや、周辺機器自体のはやり廃りといった要因も大きいと思います。

次の2000年代では携帯電話の普及がエポックメイキングな出来事でした。携帯電話の小さな筐体（きょうたい）に、数百万ステップものソフトウェアが搭載されるようになりました。今とは異なり、一度ソフトウェアがROMに焼かれ（保存され）てしまうと、たとえソフトウェアに不具合が出たとしても簡単にソフトウェアを入れ替えられない時代でした。

もし、不具合が流出してしまうと、たとえ数百億円かかったとしても、その不具合を直すために対応を行った、というニュースが報道されることさえありました。このため、特にソフトウェアのアップデートを簡単にはできない組み込みソフトウェアは、不具合に対して敏感だったと思います。

そして2010年代は、ネットワークの進化が大きいと思います。いわゆるIoT時代が到来したわけですが、SaaSのようにネットワークを介して接続するサーバーからさまざまなフィーチャーや機能が提供されるようになりました。このようにネットワークにより実現することが多くなればなるほど、エンドツーエンドで相互に関連しあうサービスやフィーチャーが相対的に増えていくため、品質の担保が難しくなっていると感じています。

今、2020年代半ばへと差し掛かっていますが、IoTによる機能実現という意味では2010年代と変わっていません。しかし、オンプレミスからクラウドベースへとインフラが変遷する中で、クラウド間をまたがるような、つまりクラウド同士がやり取りを行うようなサービスなどの品質は、エンドツーエンドで確認することが難しくなってきていると思います。自分たちが作っていないシステムやソフトウェアで不具合が出たことを想定し、いかに品質保証するのか／すべきなのか、できるのか、といったことに取り組む必要があるからです。

そういう意味だと外部のコンポーネントもそうですし、オープンソースなども、当然考慮することになります。

——これからも残るであろうテストでの課題とは何でしょうか？

「どこまでテストをやるべきか」について年代ごとに振り返りましたが、テストで「何をするか」や「どこまでやったらいいのか」ということへの課題感は、今も昔も変わっていないと思います。

ソフトウェアの複雑化に伴い、テストも複雑になり、しかもボリュームも増えているのですが、何をどこまでということについて、実際のテストの現場で担保していることは今も変わらないからです。

ベリサーブ設立時までさかのぼりますが、経営トップから（テストの）終了理論に取り組むべきだという話がありました。「何をもってテストを終わりとすべきか」という課題に私は今でも取り組んでいます。ですから、これまで得た経験と知見を基に、終了理論をこれからも仲間と共に洗練させつつ、次世代へとつないでいきたいと考えています。