システム設計・開発ベンダD社

コンシューマ向けSaaSアプリケーションおよびシステムの設計・開発を行うD社は、インターネット・プロバイダや各種サービス・プロバイダなどから、月額有料課金サービスや通販サービス、会員制ポータル・サービスなどの設計・開発を受託しているベンダ。その領域は、Webシステムに代表されるユーザに最も近いフロントエンド・システムから、各種データベース、eコマース、ロボットエンジン、バッチ処理などのバックエンド・システムまで、広範をカバーしています。

この中で、とある取引先のプロバイダが提供するポータル・サービスのフロントエンド・システムは、同社の悩みの種となっていました。というのも、サービスリリースのサイクルが非常に早く、“品質確保”との両立が難しくなっていたのです。中には、1ヶ月しかない開発プロジェクトもあるほど。
ポータル・サービスのフロントエンド・システムは、不特定多数のユーザにインフラ的な利用をされる部分なだけに、リリース後の不具合発生は許されません。本来であれば、品質確保のために綿密なテスト工程が必要ですが、厳しい“短納期”要求に応えるため、多くの場合、満足のいくレベルで実施できていないのが現状でした。

そのような折に、危惧していた事態が発生。新たにリリースしたサービスにおいて不具合が発覚したのです。ユーザが当たり前に操作する動作の中に未検証の部分があり、不具合はそこに潜んでいました。同社技術本部アプリケーション開発部のU部長はこう語っています。

「当社はわずか50人のエンジニア集団。開発者はいますが検証専門リソースの確保は容易ではありません。これまでは自分たちだけで何とかテストを実施してきましたが、ユーザに簡単に見つけられるような不具合を出してしまったことは大きなショックでした。不具合の修正に大きな労力とコストを費やす事態になっただけでなく、取引先のサービスにとって大きなイメージダウンを引き起こしてしまいました」

この後同社では、取引先プロバイダからの要求もあり、テスト工程を万全にするため派遣のテスターを利用することに。しかし、あろうことか、次の案件においてもまた不具合が発覚してしまったのです。

同社の開発現場からは、リソースもさることながら「検証ノウハウ自体」の欠如を憂慮する声も挙がり、U氏らはテスト工程の早急な見直しを迫られることになったのです。

解決の糸口を探していた技術本部アプリケーション開発部 部長のU氏は、とあるソフトウェア開発系の展示会で第三者検証専門会社の株式会社ヴェス（以下、ヴェス）と出会います。「開発の上流から下流まで、どの工程においても柔軟かつ第三者視点でプロの検証ノウハウを提供する」という特色に惹かれたU氏は、担当者に自社が抱える要件を伝え、「機能性検証」に関する提案を後日受けることに。

U氏は、ほどなくヴェスよりひとつの提案を受けます。その骨子は、「機能性検証」を行う前に、「まず“システムの機能を正確に把握すること”が重要である」というもので、U氏はこの指摘に納得します。

「ヴェスさんからは、“テストケースの網羅性”に問題があるのでは？と指摘されました。確かに、開発プロセスの中で機能性検証は行っていましたが、そもそもテストケース設計のもとになるシステム仕様書が十分に記述されておらず、テストケースがシステム全体を網羅できていない可能性は十分に考えられました」

そして、現在開発中の案件について、既存の仕様メモとβ版システム、および開発者へのヒアリング、Q&Aなどからシステムの機能を洗い出したところ、予想通り、仕様においていくつかの不整合が見つかりました。

「機能が一覧できるようになることで、仕様が明確になっている部分と、不明確なまま開発が進んでしまっている部分が浮かび上がりました。仕様の認識が、各チームや開発者間で一致していなかったのです」（前出U氏）

「機能性検証」結果より

その後同社では、仕様の不明確な部分についてクライアントと協議し、あらためて確認と再検証を行うことにしました。しかし、当然ながらリリース時期は変わりません。

ここでヴェスは納期に合わせ、「機能性検証」に着手していました。仕様が明確な部分に関するテストケースの設計に際しては、第三者検証のノウハウを活かしてテストの“範囲”と“観点”を明確化。また、仕様が不明確な部分については、ユーザ視点に立って予測対応し、確定後に段階的に補正していきました。

主な機能単位別の不具合発生個所

「アドホックテスト」結果より

「機能性検証」が順調に進捗する中、ヴェスは続いて「アドホックテスト」を同社に提案します。U氏は、この提案を受け入れ、実施することに。

「第三者検証会社としての経験と、ここまでの「機能性検証」での知見から、“テストケースに起こしていない部分での不具合の可能性を探索する”ということでした。これぞノウハウの固まりですし、開発期間に余裕がない場合の有効なアプローチ法だと聞き、お願いすることにしました」（前出U氏）

「アドホックテスト」は非公式で行われる直感的かつ自由形式のテストで、通常のウォーターフォール型の開発工程とは異なりテスト設計に依存しないため、経験とノウハウが要求されます。実施の結果は、テスト実施項目中8%の機能において、不具合が指摘されました。

致命度の高い不具合