2023.02.28

開発現場で目指すべき品質保証とは～効果が最大化するテスト自動化の適用方法～

著者株式会社SHIFT　マーケティンググループ

Introduction

プロダクトの品質保証課題をもつ企業は多く存在しているのではないでしょうか。プロダクト開発の環境が変化していくなかで、「品質保証」は企業に重要な課題ですが、品質保証の在り方が進化をしているとはいいきれません。

今回は、品質保証の在り方を進展させるために「テスト自動化」による効果と解決策、そのメリットについてご紹介します。

プロダクト開発を取り巻く環境

これまでの「計画通りにソフトウェア開発をする」ことがよいとされていた時代では、一年、またはそれ以上の長い期間をかけて開発を行っている現場も多かったのではないでしょうか。

しかし昨今では、開発中に市場ニーズが変化し、リリースするころには誰からも求められないソフトウェアになってしまう可能性もあります。

開発手法の変化

顧客ニーズの変化や市場動向に追従するため、より「高速」で「効率的」なソフトウェア開発のスタイルへと変化してきました。これまでのように中長期的にウォーターフォール型開発を行ってしまうと、市場に追いつくことはできません。

そこで、近年は開発途中でも仕様を市場に合わせて柔軟に変えることが重要視され、従来のウォーターフォール型開発からアジャイル型開発の取り組みが加速してきました。

新規機能開発へ事業投資が加速(保守の形骸化)

開発手法の変化により、新しい機能、新しいサービスを高速で生み出しつづける世界が実現しています。
しかし、その一方で、システム母体も急速に成長していき、過去にリリースした機能の品質保証、いわゆる、運用保守が軽視されがちな開発現場が多く存在します。

これは、限られた予算のなかで市場の波に追いついていくために、新機能開発への優先投資が必要と判断される場合が多いからです。資源が潤沢な開発環境でない限り、膨張したシステム母体の運用保守は、リスク低減になっても多くの利益を生みません。

品質保証の在り方も変化

従来は、当初計画通りの機能要件を満たす開発スタイルが主であったことから、機能面での品質が重視されていました。

しかし、開発手法の変化から「機能不備がなくても、利用者視点に立った機能性が伴っていなければ、プロダクトとしての品質は保証できない」という考えに変わってきています。
事実、システムやソフトウェア品質の国際規格である SQuaRE(ISO/IEC 25000 シリーズ)は、機能適合性や信頼性などの「製品品質」に加え、実際にユーザーが利用する際の「利用時の品質」を規定しています。

いま求められる品質保証とは、「製品品質と利用時の品質を掛け合わせた統合的な品質保証」ということになります。

品質保証のむずかしさ

市場に合わせた開発手法や品質が求められるなか、品質保証のむずかしさに悩む企業が多いと聞きます。
私たちが現場でよく耳にする、品質保証における課題感をあげてみます。

　・方法論が無数にあり、優先順位の絞り込みがむずかしい。
　・保証すべき「品質」が無形なため、目標の設定や比較対象を定義しづらい。
　　結果、定量的な成果や投資対効果が評価しにくい。
　・現状なんとかやれているということもあり、課題が顕在化するまで対策の意思決定がしづらい。
　・チャレンジ・トライするためのコスト(カネ・ヒト)が捻出できない。

このように、進め方や成果指標、資源などの課題がネックとなり、品質保証がますますむずかしく、進化しない状況となっています。

SHIFTはこうした現状を打開し、課題解決策の一つとして「テスト自動化」を推奨しています。
テスト自動化によって効果的に改善が見込めるケースを、まずはよくある課題や失敗を例にしてみてみましょう。

プロダクトの品質保証によくありがちな課題

① 低コストを意識するあまり、システム総規模に対して、保守のバランスが崩れる

以下は、プロダクト成長とともに移り変わるシステムと市場からの期待、それらに比例して、現場が十分な品質保証体制に達してないことがわかるグラフです。
機能拡張しつづけるプロダクトとともにシステム総規模は増加し、品質保証すべき範囲も比例して増えつづけていきます。

青線　システム総規模
新規開発が進み、システム総規模は増えつづける。品質保証範囲も比例関係で増えつづける。

赤線　市場からの期待品質
プレスリリースなどの市場認知が高まるタイミングで、市場からの期待品質が高まる。
実際、システム総規模からあるべき品質水準を期待値が超えることも(期待値の暴発)。

黄線　開発現場での品質保証
システムの拡張、市場からの期待に合わせて、品質保証体制が比例拡大している企業は多くない。
大半は、限られたコストと人的資源でなんとか品質を担保しているのが実態。

このような状況下、QCDバランスの崩れから、大規模なシステム障害につながるケースは少なくありません。

② 肥大化するシステム総規模の保守に、数少ない資源を投入し、新機能・新サービス企画に時間がとれない

本来、品質保証は「製品品質」と「利用時の品質」を統合した品質保証であるべき、と前述しました。
不具合のまったくないプロダクトでも、利用者視点における機能性が伴っていなければ成功とはいえません。

ただし、製品品質に偏った現場は多く存在します。
過去に重大なシステム障害を起こしたことのある企業が、是正策強化として資源投入をするケースなどはこの一例です。

偏った品質保証で開発が行われていくと、ますます売れないプロダクトができ上がってしまいます。

テスト自動化を用いた効率的な解決策

これからは、市場からの期待にこたえることのできる品質保証に向けて、品質リスクの除去と、バランスの優れたプロダクト開発の基盤をつくる必要があります。

システム総規模に対するあるべき品質保証と、市場からの期待品質に耐えうる体制を、限られたコストやリソースでも行うことのできる基盤づくりが必要なのです。
その基盤を、テスト自動化を用いて構築することが、有効策の一つであるとSHIFTは考えています。

テスト自動化を適用しない場合の失敗例

人材補強やガバナンス構築によってケアをする

なぜ、テスト自動化が有効なのか、シミュレーションしてみましょう。プロダクトと市場の成長を、人材補強と生産性向上のみで支えていく場合を例にします。

前述のグラフを利用して、人員数、役割の推移を、プロダクトライフサイクルごとに表現しました。

・導入期
開発初期には、少数のエンジニアによりプロダクトがつくられます。
少人数であるからこそ、「ツーカー」の世界観のなかで開発するため、盲目になりがちかもしれません。

・成長期
プロダクト成長と比例して業務量も増えるため、エンジニアの獲得をしながら、体制を増強します。このとき、導入期の「ツーカー」の世界観が、要員が徐々に増えるにつれて薄まり、ルールや定義が必要になってきます。
※実際、SHIFTの品質保証活動では、このフェーズでの仕組みづくり、品質ガバナンス構築などの実績が豊富にあります。

・安定期
世間の認知も高まり、より強固な品質保証体制が求められます。かつ、市場のニーズにこたえる形で、新機能開発やスピーディなプロダクト成長が求められるため、さらなる体制強化、人員補強が必要になります。

しかしながら、実際問題、このようなプロダクト成長に合わせた開発体制の増強、強化ができている企業はどの程度あるでしょうか。
SHIFTがガバナンス構築を支援する開発現場においても、実現できている企業は多くありません。潤沢な資産のもとでプロダクト開発している現場に限られる印象です。

IT業界における人材不足が深刻ななか、プロダクト成長と開発体制を比例して拡大できる企業は少なく、実現するのは困難です。

テスト自動化を適用した場合の推奨例

システムによるQA(＝テスト自動化)を適用し、要員の膨張とリスクを同時に抑止する

今度は、同じグラフを利用して、テスト自動化を適用した場合に、どのようにバランスのとれたプロダクト開発を実現していけるか見てみましょう。

テスト自動化を適用した場合に、どのようにバランスのとれたプロダクト開発を実現できるかのグラフ

・導入期
早期にテスト自動化基盤を構築し、後にスケールしていくプロダクトに耐えうる土台をつくります。
「ツーカー」の状態に依存せず、先を見据えた開発体制の基盤づくりが必要となります。

・成長期
プロダクト成長とともに増加した業務量を、システム化された自動化基盤にて補い、膨張しがちな体制に歯止めをかけつつ、業務を確実に行う体制にしていきます。
テスト自動化基盤が品質保証の領域を拡大させていきますが、要員の追加は開発者のみにとどめることができます。

・安定期
すでにつくられたテスト自動化基盤を成長させつづけることで、市場からの期待値も膨張しがちなこの時期においても、安定した機能開発と品質保証体制で、市場にプロダクト提供していくことができます。

品質保証基盤を構築して自動化することで、体制の膨張を最低限に抑えつつ、人が判断や創造しなければならない部分にリソースを割き、結果として効率的なプロダクト開発を推進していくことができるようになります。

これがいま、市場やプロダクト成長に適した開発スタイルであり、実現方法の一つがテスト自動化の適用であると考えています。

テスト自動化適用における重要なポイント

昨今では、テスト自動化を導入するために必要なナレッジであるシステム知見・品質知見などをブラックボックス化し、簡易的に導入できるようなツールが多く存在しています。
すべての開発現場にテスト自動化が適用されるべきである、と考える私にとっては非常に喜ばしい事実です。

ただし、「簡易的にはじめられること」と「どんな環境でも成功する」ことはイコールではありません。
簡単に導入できたとしても、適用方法や前提を間違えると、その後、テスト自動化がプロダクト開発において逆効果を生み出し、邪魔な存在にもなりえます。
それを防ぐためには、「テスト自動化を適用する際の前提条件、原理原則の理解」が必要です。

次に、前提条件、原理原則を理解して、効果的・かつ効率的にテスト自動化を適用するためのポイントを説明します。

障害検知の信頼性が高い仕組みをいかに構築するか

製品品質が安定しない状態や、動作環境が不安定な状態で、すべての機能に対してテスト自動化を適用すると、当たり前のことですが、実行エラーが大量に発生します。
テスト自動化には、実行後の結果分析や測定も非常に重要な要素ですが、検出されたエラーの結果分析に相当のコストがかかってしまいます。
業務効率やスピードアップが目的となることが多いテスト自動化において、こうした事態は避けなければなりません。

以下のように、テスト自動化基盤の実行結果で検出されたエラーが、障害として検知される割合の高い状況をつくるように構築することが重要です。

再発防止や未然防止、QA範囲拡大、リスク回避など、テスト自動化に期待する目的に沿って、移行プロセスを組み立てることで、障害検知の信頼性が高い基盤構築が可能です。

目的やゴール、移行プロセスなどが曖昧ななか、すべてを網羅的に自動化適用してしまうと、いずれ形骸化してしまい、根本的な課題解決にはなりません。

テスト自動化への要求事項と要件定義

ほとんどの場合、テスト自動化はどの工程、どの環境にも適用できてしまいます。ただし、誤った適用をしてしまうと狙った効果がでないこともあります。

要求と要件を整理し、適切に目標設定された状態でテスト自動化を導入していきましょう。

手動テストはなくならない

手動テストと自動テストには、それぞれの目的とメリットがあります。それらを適切に理解し、使いわけることが非常に重要です。

自動テストは、設定した通りにしか動作・検証をしないため、検知された不具合のほとんどは、デグレードです。
そのため、すべて正常に動作することを確認する仕組み(継続的な品質保証活動)で効果を発揮します。

似ているようで異なる目的と得意分野を十分理解し、スコープ選定などを行っていく必要があります。

まとめ

プロダクト開発における品質保証の在り方、陥りがちな失敗例と、テスト自動化を用いた解決策についてご説明しました。

市場の変化に合わせたプロダクト開発と成長のために、限られた資産でできることは限られています。早期に自動化の基盤を整えることで、品質保証はもちろんのこと、適正なリソース配置と体制構築が可能になります。

SHIFTでは、テスト自動化や管理ツールの提案だけではなく、どんな品質課題にも対応できるソリューションを提供しています。
ぜひ、今回のような課題感をおもちの方は、お気軽にご相談ください。

資料ダウンロード/動画視聴

テスト自動化のススメ(GUI編)

テスト計画講座

テスト観点の作り方講座～ゼロから導くテストの切り口～

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

開発現場で目指すべき品質保証とは～効果が最大化するテスト自動化の適用方法～

Introduction