生産性の向上や多様な働き方への対応など、ビジネスの様々な経営課題を解決するにあたっては、ITの活用が有力な施策です。現実として、ITの活用を軸にビジネスを変革する「デジタルトランスフォーメーション（DX）」の実現を目指す企業は増えました。

しかしながら、ITが社会へ普及するにしたがい、情報漏洩やシステム障害といったニュースも散見されるようになりました。これらの多くはソフトウェア品質上の問題、ひいては、そのような問題を見逃してしまう品質保証の不備に起因しています。

発展を続けるテクノロジーとは対照的に、それらを送り出す品質保証の現場は旧態依然としているのが現状です。生成系AIやノーコードツールがビジネスに普及するなかでも、品質保証では依然として人海戦術に頼るケースが少なくありません。

ソフトウェア品質の向上には、品質保証とテクノロジーのギャップを解消することが求められます。つまり、品質保証のIT化により現場を変革し、ビジネスの創出につなげる、言うなれば「品質保証DX」が求められるのです。

今回のADOC TESLABブログでは、品質保証DXの実現にあたって必要な知識についてシリーズで分かりやすく解説。第1回となる本記事では、品質保証における現状や課題、品質保証DXの実現にあたり重要となるポイントについて整理します。

品質保証の現場を取り巻く状況と課題

昨今の品質保証の現場は様々な課題に直面しており、それらがDXの実現を難しくしています。品質保証の現場を取り巻く状況と課題としては、次の3点が挙げられます。

QA人材の不足による品質保証の困難化

適切な品質保証の実施には、計画や設計、環境構築、実行、分析、自動化といった広範なテストプロセスをカバーできるQA人材が求められます。しかし多くの品質保証チームは、QA人材の不足に直面しているのが現状です。

たとえ人海戦術に頼るとしても、QAの専門家ではない他チームからの補充要員をアサインすることとなります。こうした取り組みは、組織全体に混乱をもたらすばかりではありません。「品質保証の広範な知識・スキルの確保」という本来の要件を満たさないために、現場における柔軟性・生産性低下の主要因となり、品質保証の困難化を招いています。

リリースの迅速化によるテスト工数の圧迫

IT業界に参入する企業の増加、ソフトウェアに対するニーズの多様化などにより、IT市場の変化は激しさを増しています。こうした状況から昨今のソフトウェア開発には、市場の変化に素早く対応できる迅速なリリースが求められるようになりました。短いスパンに区切り開発を繰り返す「アジャイル開発」は、リリースの迅速化に対応するためのスタンダードとなっています。

そして、リリースの迅速化による影響を特に受けやすいのが品質保証です。ソフトウェア開発における工数の30～40％程度は、テスト工程に費やされると言われています。大きなウェイトを占める品質保証の工数は、迅速なリリースのための犠牲となりやすいのです。必要なテスト工数を確保できなければ、品質の担保は難しくなります。

ソフトウェアの複雑化・多様化によるテスト難易度の上昇

社会を取り巻くITが高度化するにつれて、ユーザーはより精緻かつ使い勝手のよいソフトウェアを求めるようになりました。結果として仕様の複雑化や要件の多様化が進み、これがテスト難易度の上昇を招いています。

たとえば、APIを介した他サービスとの連携が生じることで、「サービス間の相互作用」というテスト観点が生じます。また、モバイルOSを含む多端末への対応が求められれば、同一のテストケースを複数端末にわたり実施しなければなりません。

ソフトウェアにまつわる複雑化・多様化はテストケース数の増大、さらにはテスト実行に要する工数の増大をもたらします。テスト工数の制約が大きくなりつつあるなかで、漏れなくテストケースを作成し、正確に実行することは容易ではありません。

これら3点に代表される品質保証の課題は、現場業務の負荷高騰につながり、さらなる人材不足を招く要因ともなっています。負の連鎖を断ち切り、硬直化した現場の働き方・生産性を変革することは優先度の高い経営課題でもあり、それぞれの課題は個別に対応するだけでなく、抜本的な改善が求められているのが現状です。

なぜ品質問題が起きるのか？

短納期・高難易度のテストを限られたQA人材だけで実施するような状況では、品質問題を完全に防ぐことは難しくなります。しかし品質問題のすべてが、前述した課題のみに起因して発生するわけではありません。ここでは、なぜ品質問題が起きるのかについて、前述した課題以外の論点を整理します。

テストにおけるバグの見逃し

仮に品質問題を引き起こすバグが開発途中のソフトウェアに混入されていた場合でも、適切なテストを実施すれば検出は可能です。品質問題がリリース後に表出する場合、テストにおいて抜け・漏れといった不備があり、「バグを見逃した」と言わざるを得ません。

とはいえ、「テスト工数が確保できないことが原因」と結論付けるのは早計です。前述した人材不足やテスト工数、テスト難易度の課題以外にも、下記のような原因が考えられます。

最適でないテストプロセスによる非効率なテスト実行

テストプロセスが最適化されておらず、効率が低いことで相対的な工数不足に陥るケースは珍しくありません。自動化可能なテスト作業を手動に甘んじている、過去のテスト成果物を活用できていない、などが具体的な問題の例です。根本には、品質保証の体制面における問題も散見されます。

リソースの制約によるテストの網羅性低下

リソースの制約によりテストも制約を受け、網羅性が低下するケースが考えられます。必要な端末が確保できずテスト範囲が限定される、本番環境と同等の環境が再現できずテスト条件が不完全、などが制約の例です。

適切な環境・条件を再現できないのでは、テストケースを網羅的かつ正確に実施することはできません。「テスト環境で確認されなかった動作が本番環境で発生した」といったケースの多くが、この問題に起因しています。

非機能テストの不足

機能要件以外の性能などを検証する「非機能テスト」の不足も、往々にして品質問題につながります。非機能要件のテストは、機能要件と比べてよりユーザー観点での確認を求められることが多く、本番環境に近い環境が用意できる開発の最終工程まで回されるケースが少なくありません。このため、非機能テストで問題が判明すると手戻りが大きくなり、開発プロジェクト全体に影響を及ぼすデリケートなテストであると言えます。

同時に、判断基準が曖昧になりやすい、専門的な知識やツールが求められるなど、正確な実施が難しい側面もあります。こうした事情から、必要十分なカバレッジをもつ非機能テストが実行されず、速度やデータ量、脆弱性などに関する品質問題が生じるケースは少なくありません。

上流・実装工程におけるバグの混入

「ソフトウェアにバグはつきものである」という前提の中で、以上のような事情がバグの見逃しの温床となり、品質問題を引き起こします。しかしテストは、あくまで品質問題の流出を防ぐうえでの「最後の砦」です。実際には、要件定義や設計、実装といったテスト以前の工程で作り込まれたバグが、品質問題の直接原因となります。一切のバグが混入しなければ、品質問題は基本的に発生しません。そのため、品質保証の理想論を語るうえでは、テスト以前の工程に関する考慮も必要です。

重要な論点は「なぜ上流・実装工程でバグが混入するのか」です。テスト工程と同様、人的リソースや日程などの事情により品質が下がることは考えられます。他にも、バグが混入する原因として、次のようなものが挙げられます。

変更に対する許容性の欠如

工程を進めている途中で顧客の要求が変わり、ソフトウェアへの反映を求められるケースは珍しくありません。こうした急遽の変更への対応は、工程をさかのぼって大きな影響を及ぼすため、しばしばバグ混入の引き金となります。

要求の変更に素早く対応するためには、工程間のトレーサビリティ（追跡可能性）を確保し、迅速に関連工程へ変更を反映できる仕組みが必要です。しかし、こうした仕組みを内包するソフトウェア開発チームは多くありません。そのため、変更に際して多くの作業・リスクの発生を避けられず、結果として不備が生じやすいのです。

レビュー水準の問題

各工程終了時に実施されるレビューは、バグの混入を未然に防ぐための重要なプロセスです。十分なレビューが実施されていない、レビュー自体の品質が低い、といった体制上の問題があれば、バグを後工程へ持ち越すリスクが高まります。

高水準なレビューの実施を妨げるものは体制上の問題だけでなく、各工程において達成されるべき品質目標の欠如や、コミュニケーションを補う資材の不足といった準備・環境面にも存在します。いずれにしても、こうしたバグの持ち越しは積み上げ式のしわ寄せとなり、工程が終盤に近付くほど開発プロジェクト全体に及ぼす影響を増大させます。

品質保証DXの実現にあたり重要となる3つのポイント

このように、品質問題は様々な原因が引き金となって発生します。そして、品質問題のリスクが高まるほどに、品質保証の現場の負荷は増大するという現実があります。

高負荷な品質保証の現状を改善しつつ、ソフトウェアの信頼性を飛躍的に向上させる解決策となるのが「品質保証DX」です。ここでは、品質保証DXの実現にあたり重要となる3つのポイントについて解説します。

適切な品質計画の策定

健全な品質保証の実現には、プロジェクト初期段階において適切な「品質計画」の策定が不可欠です。達成すべき品質目標を定め、それらを可視化しながら、達成するための具体的な計画や施策に落とし込みます。特に、品質の早期安定化につながる品質計画を策定することは、QCDの向上を図るうえで最重要事項といえます。

品質計画はソフトウェア開発プロジェクトにおけるトレーサビリティの礎であるとともに、各工程のガイドラインとなり、レビューやテストプロセスの過不足ない実行や、目的に応じた自動化の活用といった品質保証の要点に影響を及ぼします。したがって、前提として品質計画が適切でなければ、品質保証DXを実現することはできません。

開発・テスト環境の計画や運用、適切なソリューションの適用

開発・テスト環境の計画や運用は、QCDに直結するポイントであるとともに、品質計画の遂行を支える重要な観点です。前述したようなテストの網羅性低下を防ぐうえでは、適切なテスト環境の構築が欠かせませんし、また各工程のスムーズな進行を左右するだけでなく、開発環境・テスト環境間、あるいは各工程間の連携しやすさは開発プロジェクト全体の生産性に直結します。

ここでいう「環境」はITインフラだけでなく、ソースコードやテストデータなど、各工程の成果物をすべて含みます。広範な環境を一元的に運用・管理するためには、適切なソリューションの適用が重要です。詳細は次回以降に紹介しますが、「CI/CD」や「IaC」といった技術を搭載したソリューションが有力といえます。

適切なソリューションを適用したテスト実行

品質保証の要であるテスト実行は、当然ながら品質保証DXにおいてもしかるべき対応が求められるポイントです。前述のように、工数圧迫や難易度上昇といったテストにまつわる課題は少なくありません。テストの負荷を軽減するために、適切なソリューションの適用が不可欠です。

特に品質問題の多くは、抜け・漏れといったテストケースの不足に起因します。そのため、テストケースを網羅的に作成でき、それらを確実に実行できるソリューションが望ましいと言えます。また、非機能テストを含めた広範なテストをカバーし、品質の早期安定化を実現できることが理想です。

品質計画の策定における手順やポイントとは？

今回は品質保証における現状や課題、品質保証DXの実現にあたり重要となるポイントについて整理しました。

品質保証DXの実現にあたっては、テスト実行はもちろん品質計画、開発/テスト環境に対するプロセスの見直しも不可欠です。品質保証チームがDXを取り入れるためには、テストにとどまらないプロジェクト全体を視野に入れた対応が求められます。

次回以降では、品質保証DXの実現にあたって重要となる、今回挙げた3つのポイントについて順次論じていきます。

• 品質計画
• 開発・テスト環境
• テスト実行

第2回となる次回は、品質計画の手順やポイントについて解説します。

• 「品質保証DX」の実現に向けて