Technical Information

DX時代のITサービスに要求される「安心・安全な品質」とは?
~より安心・安全なITシステムの構築を支援する品質エンジニアとしてのアプローチ~

asset_approach_column_security03_hero.jpg

私は1995年の入社以来、性能やセキュリティの分野における品質向上に数多く携わってきました。本講演では、こうした分野における弊社の活動をご紹介し、皆様の課題解決に役立つヒントをご提供できればと考えています。

※この記事は、『ベリサーブ アカデミック イニシアティブ 2020』の講演内容を基にした内容です。

桑野 修

株式会社ベリサーブ
ソリューション事業部 事業部長
桑野  修 

DX時代のITサービスに求められる品質とは?

ここ数年、「DX」という言葉をたびたび耳にするようになりました。 AI・5G・IoT・クラウド・ビッグデータなどの要素技術を組み合わせることで、さまざまなサービスがデジタル化され、新たな価値がもたらされています。

利便性の高いサービスが次々と登場する一方、これらに深刻なインシデントや障害が起きるケースも散見されています。特にセキュリティ関連のトラブルは増加傾向にあり、個人情報の漏えいは年間数千件のレベルで発生(図1)、大手決済サービスにおいても、ユーザーに金銭的な被害をもたらす事案が起きています。

また、アクセスの集中によるシステム障害も頻発しています。記憶に新しいところでは、コロナ禍に対する公的助成金制度で受付システムの停止や障害によるデータ損失などが起こっています。このように、誰もが知るような巨大ベンダや国・地方自治体が提供するシステムでも、こうしたトラブルは後を絶ちません。

業種別情報漏えいの件数
(独立行政法人情報処理推進機構「情報セキュリティ白書2020」

図1:業種別情報漏えいの件数
(独立行政法人情報処理推進機構「情報セキュリティ白書2020」)
https://www.ipa.go.jp/security/publications/hakusyo/2020.html
(参照2021-02-25)

1.非機能要件とは?

ソフトウェアやサービスには、「機能要件」と「非機能要件」が存在します(図2)。機能要件は、何を実現するのかを文字通り機能として記述したものです。一方、非機能要件は機能に依存しない特性で、時に暗黙的にしか定義されない要件を指します。その代表が性能やセキュリティで、先に挙げたようなトラブルは、まさにこの非機能要件に関わるものです。

機能要件と非機能要件

図2:機能要件と非機能要件

2.非機能要件の標準化の取り組み

暗黙的である非機能要件についても、可能な限り顧客とベンダ間での明示的な合意が必要です。これを促進するため、標準化の試みが国内外で実施されています(図3・4)。

しかし、こうした努力にも関わらず、非機能要件に起因するトラブルは今も続いています。非機能要件の品質確保は、それほど難易度が高いものだということがご理解いただけるかと思います。

この非機能要件に対し、テストや検証をサービスとして提供する弊社がどのように取り組んできたかをご紹介します。

非機能要件について明示的に合意するためのフレーム

図3:非機能要件について明示的に合意するためのフレーム

品質特性と品質副特性の変化

図4:品質特性と品質副特性の変化

非機能要件とテストプロセス

図5は、90年代後半に弊社が当時の親会社の検証部門として事業を開始した頃の活動を表したものです。一般的なV字型モデルの中で行われるテストとは別に、専門のチームによる独立したテストプロセスを定義し、開発のスタート段階からテストを考える体制を作りました。

システム開発におけるテストプロセスの独立

図5:システム開発におけるテストプロセスの独立

1.テストアプローチの進化と変遷

初期の活動で課題となったのは、不具合の発見にチームのメンバー間でバラツキがあることでした。これを解消するにはプロセスの上位にある「設計」フェーズの強化が必要と考え、テスト手順の標準化に取り組みました。具体的には、過去に見つけた不具合をグルーピングして分析し、有効であったアプローチに名前を付けていき、最終的に11個の「システムテストカテゴリ」に集約しました(図6)。信頼性(耐障害性)やユーザビリティ、セキュリティなど、すでにこの時点で非機能要件的な問題を取り扱っていたことがお分かりいただけると思います。
この標準化の効果もあり、徐々に品質改善の実績を積み重ねていく中で、2000年代前半には開発の初期段階である要求分析の時点から積極的に関与する案件が増えていきました。お客様は、この業務やサービスをIT化したい、といった機能要件の定義はしていても、実施するテストや品質の在り方には明確な答えを持っていない場合も多かったためです。

11個のシステムテストカテゴリ

図6:11個のシステムテストカテゴリ

図7は、こうした場合に私たちが採った代表的なアプローチの一つです。品質特性にはISO/IECの国際標準を、それに対するテスト項目には先にご紹介した11個のシステムカテゴリを使ってマトリクス化しています。

これにより、お客様や開発チームとの間で、品質とテストに関する共通認識を早期に醸成することが可能になりました。また、設計の品質向上に寄与したほか、私たちのテスト活動自体にも良い影響をもたらしたと記憶しています。

テストカテゴリと品質特性を利用したテストのアプローチ

図7:テストカテゴリと品質特性を利用したテストのアプローチ

2.非機能要件テストのサービス化・水平分業

ここからは、現在私たちが実施している非機能要件テストの概要についてご説明します。端的に言って、専門家である私たちにとっても非機能要件のテストは簡単ではありません。これには、大きく二つの要因があります。

まず、かつてのシステム開発はフルスクラッチが主流で、開発者が内部構造をすべて把握している場合がほとんどでした。しかし、最近は短納期化などの影響で、さまざまなモジュールやサブシステム、マイクロサービスを利用することが増えています。その結果、個々のブロックの構造は開発者にも理解が難しく、仮に性能劣化が起きた場合でも原因がどこにあるか不明なケースが出てきています。

もう一つは繰り返しになりますが、性能やセキュリティに対する定義付けが、お客様自身にも明確でないことです。性能を例に取ると、「このシステムは5万人が使える」とお客様が言ったとしても、それ以上の定義が何もない場合があります。アクセス集中への対処としては、ではそのシステムを10秒間で500人が同時に利用した時にはどうなのか、といったことを要件として定義しておくべきなのですが、これが欠けているプロジェクトが多いため、まずはテストをする私たちが「あるべき要求」を整理するところから入る必要があります。

セキュリティの場合も状況は同じです。攻撃者のアプローチは千差万別で、システムをどう守るかという問いに対して体系的な回答を持つ方は多くありません。そのため、こうした要件についても、テストをする側の私たちが定義しなければならないケースがあります。

こうした状況から、非機能要件のテストについては水平分業による専門チームでの対処を基本としています。具体的な手法としては、特殊なツールを使用して、同時に大量のアクセスを生成したり、システムへの疑似攻撃を試みたりします。これにはプログラムが実施する通信の内容を深く理解しておく必要があり、一般的なテストエンジニアが持っていないような、内部のロジックに踏み込んだ知見が求められます。

さらに、テストの結果として応答時間の劣化やシステムの停止が起きた場合に、その原因や対策について設計側が簡単には見極められないケースも多いため、私たちが問題の解析や改善に対するアプローチを示唆することも必要です。

このような専門的なサービスを必要なタイミングで提供することで、プロジェクト全体のQCD最適化に貢献することを目指しています(図8)。

非機能要件のテストにおけるアプローチ

図8:非機能要件のテストにおけるアプローチ

3.非機能要件に対する支援領域の拡大

非機能要件に対する私たちへの要望は、徐々に開発の上流へとシフトしていく傾向にあります。品質の問題が下流工程で発覚すると手戻りが大きくなるため、上流からそのリスクの低減を図ることが求められています。具体的には、非機能要件の定義と設計への反映をレビューしたり、プログラムがセキュリティを担保した構造になっているかをソースコードレベルで解析したりと、テストの前段階で品質を上げるアプローチを行っています。

さらに、ここ2~3年は、非機能要件を開発のライフサイクル全体でコントロールする支援も行っています。特にセキュリティ分野では、システム開発がスタートする前の要求分析の段階から「どんなリスクがあるのか」という脅威分析を行うことがさまざまなガイドラインで推奨されるようになったり、製品のリリース後、システムが使用しているコンポーネントに脆弱性が発覚するというニュースが増えたりしたことから、システム開発プロセスの前後の工程である、要求分析や脆弱性管理を含む運用支援への依頼も増えてきています。

また、大規模なプロジェクトで複数のチームが、それぞれが担当するサブシステムの開発・テストを行っている場合、サブシステムごとに性能試験を実施する必要が生じることがあります。そのようなケースでは、プロジェクト全体のマネジメントを支援するPMOチームなどに参画して、テスト全体のコーディネートを支援するケースも出てきています(図9)。

セキュリティにおける要求の拡大

図9:セキュリティにおける要求の拡大

4.セキュリティ要求の増大と必須化

非機能要件の中でも、セキュリティに関する要求はここ数年で急速に高まり、業界ごとに設けられた国際標準や規制への準拠が必須となっています(図10)。自動車関連業界などでは、ISOのセキュリティ規格に準拠していない製品は、2023年以降には販売できなくなる方向で法制化が進んでおり、弊社でもその対応への支援を行う案件が増えています。

セキュリティが他の非機能要件と大きく異なるのは、意図的に何らかの障害を起こそうとする攻撃者への対応が必要である点です。このため、もう一段高い要求分析や品質のマネジメントが必要になってきています。

セキュリティに関する業界標準

図10:セキュリティに関する業界標準

おわりに

非機能要件への対処は、単にテストをするだけでなく、システム開発全域にわたるコントロールが必要です。それには開発に関わるすべてのステークホルダー、特に上位層がリスクマネジメントの意識をしっかり持つことが非常に重要だと感じています。本講演でご紹介した課題と、私たちのアプローチにご興味をお持ちいただき、意見交換の場をいただければ幸いです。