まずソフトウェア開発における「アーキテクチャ」は、対象の基本的な概念・構造・特性を、構成、設計判断、設計原則で表現したものを指します。
例えばシステムのアーキテクチャの場合ですと、ISO/IEC/IEEE 42010ではアーキテクチャという言葉を次のように定義しています。
Architecture:
fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
(対象の環境におけるシステムの基本的な概念や特性を、システムの要素、関係、設計原則・発展原則として具体化したもの)
次に本テーマの「QAアーキテクチャ」についてです。
QAアーキテクチャは、電通大の西康晴さんが先導的に整備している考え方で、「品質をどこでどう確実に作り込んで確実に保証するか」「どんなQA観点を作り込んで保証できているのか」の基本構造・基本方針を設計したものです。
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
Re-collection of embedded software qa in the last decade
この一連の解説においては、前述の一般的なアーキテクチャの定義も加味し、QA(品質の保証)に特化して、QAアーキテクチャを次のように定義したいと思います。
QAアーキテクチャとは、「品質をどう保証するか」の基本的な概念・特性であり、それを品質保証の原則、基本方針、手段の構成で具体化したものである。
またこの解説では、上記のQAアーキテクチャを実現し、改善・保守し、検証する活動全体を指す言葉として、QAアーキテクティングという言葉を使用します。
今なぜQAアーキテクティングが重要になるのか
現在の開発スタイルとして、次の2つの重要性が高まっています。
- 様々なQA活動を高度に連携させ、開発全体で優れたアジリティや価値創造を実現する開発スタイルが求められている
- 【継続的デリバリ、DevOps】様々なQA活動を包含するデプロイメントパイプラインを洗練させ、開発とビジネスの距離を縮める
- 【アジャイル】様々なQA活動を組み合わせ、継続的かつ高速なリリース＆フィードバックを実現する
- 創発的・反復的なQAアプローチが求められている
- 【アジャイル】イテレーションごとにQA活動を積み重ねつつ、全体の品質保証としての整合性を確保し、プロダクトの品質を継続的に担保する
上記に対応するため、様々なQA活動の総体をアーキテクチャとして扱い、アーキテクティングでその構造やメカニズムを工夫するアプローチが有効となります。
QAアーキテクティングの目的は、プロダクトの成功のために必要なQAを実現することです。そのためQAアーキテクチャは以下の役割を担います。
- 予測。以降のQA活動に大きな影響を与える判断を示し、準備や計画を支える
- 先導。QAの方針を示し、状況が流動的に変化するソフトウェア開発ライフサイクルのあらゆる局面で、QA活動がどこに進むべきかを先導する。
- 橋渡し。ビジネス、マネジメント、開発、QAなど様々なステークホルダ・関係者からのQAへの要求・制約の調停を行い、妥当なQAの実現を支える。
- 協調。複雑・大規模なリスクや問題に対応するために、各QA手段をどう強調させるかを示す。また複雑・大規模な問題を対応可能にするために、具体化・分割する。
- 全体整合の確保。QAの適切な全体像を構築し、その実現・維持を支える。
コミュニケーションツールとしてのQAアーキテクティング
QA活動は、様々なステークホルダから要求や制約を受け取り、様々な担当者で推進します。そのためQAアーキテクティングは、QA技術を活用した問題解決ツールの側面のほかに、コミュニケーションツールの側面も強く持ちます。具体的には、QAアーキテクティングは次の役割を果たすことが重要になります。
- 様々なステークホルダからの要求や制約を調停し、ステークホルダが納得するQA活動を実現する
- 様々なQA活動関係者からの納得を確保し、QA担当者の協力を促しその力を結集する
アーキテクチャは様々な特性を備えていることから、一般的に、複数のアーキテクチャ観点で観た、複数の側面でアーキテクチャを表現します。このアーキテクチャ観点は、ステークホルダの関心事や、開発上重要な側面に基づいて選択されます。アーキテクチャ観点の数は少なすぎるとアーキテクチャを十分に表現できず、多すぎると各側面の整合性の確保・維持が大変になるため、重要性に基づいた適切な数の観点を使用します。
これはQAアーキテクチャも同様です。QAアーキテクチャはその役割上、構造的特性、プロセス的特性など重視すべき特性を持っていることから、それに対応したいくつかのアーキテクチャ観点で表現するのが有効です。
QAアーキテクチャの表現で有効なアーキテクチャ観点を次に示します：
QAタイプの責務分割の観点
QAタイプの責務分割を構造モデルで設計・整理する観点です。
例えば、ツリーモデルでQAタイプを整理するものが該当します。このツリーモデルによる構造観点は次の理由から有益です。
- QAアーキテクティングでは、複雑・巨大な品質保証を、扱えるサイズに分割するために「関心事の分離」が重要になります。ツリーモデルはこの関心事の分離をわかりやすく表現します。
- QAアーキテクティングでは、十分なQAの実現のために、多数の様々なQA手段を集めて連携させる必要があります。ツリーモデルは、多数のQA手段の洗い出しや整理を支援します。
QAタイプの構造の観点
QAタイプの構造をプロセスやデプロイメントパイプラインで設計・表現する観点です。
QAでは、様々なQA手段を、重ね合わせ、役割分担、横断的連携のパターンで組み合わせて、全体のQAを実現します。プロセスやパイプラインモデルは、それら組み合わせや連携の関係をわかりやすく表現します。
またQA活動は状況に応じて動的に変化することから、「通常デプロイ時」「Hotfixデプロイ時」などの条件をシナリオとして具体化して、シナリオごとにプロセスやパイプラインがどう変化するか補足表現する必要もあります。
その他、QAアーキテクチャ要求に基づいた分析観点
QAアーキテクチャには様々なタイプの要求・制約がインプットされます。QAアーキテクチャの構成要素と構造のほかに、それら要求・制約に基づいた観点で設計・表現を行うことが重要になります。
特に、QAアーキテクチャの要求のうち、特に影響が重大なアーキテクチャドライバに基づいて、QAアーキテクチャの骨格を構成するのは、アーキテクティング手法として重要なアプローチになります。
代表的なQAアーキテクチャの要求と、それに対応するQAアーキテクチャ観点を示します。
【要求：課題やリスクをリリース可能なレベルまでコントロールする】→QAタイプによる課題・リスクコントロールの観点で設計
「課題やリスクをリリース可能なレベルまでコントロールする」というのは表現の程度はありますが、QA活動の一般的な要求になります。
その要求があった場合、課題、プロジェクトリスク、品質リスクのコントロールに対し、各種QA活動がどう連携するかを設計・表現する観点が有効です。QAでは、目標や課題対応のために様々なQA手段を組み合わせます。その連携を記述する単位として、課題やプロジェクトリスク・品質リスクのコントロールを用いるということです。
【要求：様々なQAベースの実現性を保証する】→各QAベースとQA活動の対応付けの観点で設計
大規模な開発の場合、多数の成果物タイプを扱うことから、それぞれのドキュメントや成果物がきちんと実現性保証されているかに注意を向ける必要があります。
そうした要求があった場合、QAベース（QA活動のインプットになる成果物）を、どのQA活動で実現性保証するか関連付け・マッピングする観点が有効になります。
【要求：開発ライフサイクルの中で段階的に成長するQA活動を行う】→スケジュールやタイムラインの観点で設計
PoC→開発→量産開発など、開発ライフサイクルが明確に区別された開発フェーズで分類される場合、それに応じて段階的にQAアーキテクチャを成長させていく必要があります。
そうした要求があった場合、スケジュールやタイムライン上で、QAアーキテクチャをどう具体化し、成長させていくか設計する観点が有効になります。
CEQAAMでは、QAアーキテクチャを、(いくつかの独自の記法を導入したモデル記法で)上記の観点ごとに表現した姿と、各観点の要素の詳細を説明するQAアーキテクチャ管理表を使って表現します。
QAを複数人で分担する状況や、複数のQA手段を連携させる状況ならば、顕在的か/潜在的か、意図的に構築するか/無意識に生まれるか、の違いはでるものの、QAアーキテクチャは生まれます。
ただそのQAアーキテクチャをどこまで明示的に表現するか、QAアーキテクティングをどこまで方法論的・形式的に実施するかは、プロジェクトの規模や複雑さ、スタイルに依存します。
例えば、数百人程度の大規模プロジェクトであったり、難易度の高い品質保証が求められるプロジェクトならば、明示的にQAアーキテクチャを構築・維持する必要性がでてきます。
一方、少人数のプロジェクトや、リリースごとの品質保証が1、2週間のスプリントで収まるような軽快な開発ならば、QAアーキテクチャが成立したとしても、QAエンジニア判断任せで、QAアーキテクチャを特に明示化しない場面もありえます。
QAアーキテクチャは、開発ライフサイクル全体に渡って構築・維持・保守されます。
QAアーキテクチャのライフサイクルのフェーズを次に示します。
- 仕様化フェーズ：QAアーキテクチャ要求を収集し、各ステークホルダとすり合わせして、QAアーキテクチャを仕様化します。
- 発展フェーズ：QAアーキテクチャに基づいてQA活動を先導します。また、QA要求の追加・変化に応じて、QAアーキテクチャを発展・変更します。
- 保守フェーズ：完成したQAアーキテクチャを保守・再利用可能な形で記録し、保守開発や派生開発への展開を支えます。
QAへの要求は開発が進展しないと出てこないことものもあり、また開発の状況に応じて変化することもあるため、上記フェーズがウォーターフォールに実行されることは稀です。多くの場合で、五月雨式に、反復的に上記フェーズが実行されます。
QAアーキテクティングと連動する活動
QAアーキテクティングはマネジメント、ビジネス、開発、品質保証を調停することから、それらの様々な関連活動と相互依存関係をとっています。そのため、QAアーキテクティングの活動によって、それら関連活動の推進を促すこともあれば、ときにQAアーキテクタが作業代行する場合もありえます。
QAアーキテクティングと連動する関連活動の代表例を次に示します。
■QAアーキテクティングと連動するマネジメントの活動
組織設計
組織構造とQAアーキテクチャは連動しています。そのため組織設計とQAアーキテクティングは相互依存関係にあります。
具体的には、QAアーキテクティングは、組織設計に対してあるべき組織構造を示します。また組織設計は、QAアーキテクティングに対して、結果としての組織構造を示し、QAアーキテクティングに制約を指定します。
組織設計はQAアーキテクティングというよりマネジメントのタスクです。ただ上記の関係性から、QAアーキテクティングの活動を通じて、組織設計の推進を促したり、場合によっては代行したりすることが求められます。
開発プロセス設計もQAアーキテクティングと相互依存関係にあります。
QAアーキテクティングは、開発プロセス設計に対し、QAプロセスや望ましい開発プロセスを示します。開発プロセス設計は、QAアーキテクティングに対して、結果としての開発プロセスを示し、QAへのインプットやQAのプロセスを指定します。
そのため、QAアーキテクティングの活動を通じて、開発プロセス設計を促したり、その一部を代行したりする場合があります。
■QAアーキテクティングと連動する開発の活動
QA容易性や試験性（テスタビリティ）の確保
QAアーキテクチャは、試験性を含むプロダクトのQA容易性に依存します。
具体的には、QAアーキテクティングは開発に対し、必要なQA容易性・試験性を求めます。開発は、QAアーキテクティングに対し、結果として実現したQA容易性を制約として指定します。
そのため、QAアーキテクティングの活動では、プロダクトの仕様定義や設計の活動に含まれる、QAに必要なQA容易性の仕様化を手掛けたり、促したりする場合があります。
QAアーキテクティングの基本方針として、QA活動を先導しながら、QAアーキテクチャの完成像に向けて累積的に・適用的に組み立てていくことになります。例えばアジャイル開発ならば、イテレーションごとに刹那的にQA成果物を使い捨てるのではなく、包括的な品質保証を組み立てつつ、イテレーションごとのQA活動も実施するように、QAアーキテクチャでQA活動を先導していきます。
具体的なQAアーキテクティングの設計方針を次に示します。
開発全体で構築する
開発全体の様々なQA手段を総動員してQAアーキテクチャを構築します。
例えばある欠陥の流出を予防したい場合は、設計・実装で欠陥予防策を実現し、レビューで静的に欠陥を見つけ、テストで動的な欠陥を見つける、というように、様々なアプローチを組み合わせ、全体のQAを実現します。
発展的に構築する
QAアーキテクチャは反復的、段階的に育て、完成させます。
QA要求は流動的であり、開発の進展に従って徐々に明らかになっていくことから、QAアーキテクチャはBDUF（Big Design Up Front）で構築できません。最終的に実現すべきQAアーキテクチャが実現されるように、EDUF（Enough Design Up Front:EDUF）で、反復的・段階的に拡張洗練させていきます。
ビジネス・マネジメント・開発・QAをすり合わせ構築する
QAアーキテクチャはビジネス・マネジメント・開発・QAの橋渡しであり、それぞれの要求・制約を調停し、プロジェクトの成功の点で妥当な品質保証を実現させる役割を持っています。
そのため、ビジネス・マネジメント・開発・QAと相互に連携しながら、適応的にQAアーキテクティングを推進します。
関心事の分離を推進する
一般的にQAは大規模・複雑であり、様々なロールが分担して実現します。レビュー手法、テスト手法などを適用し、具体的なQA手段を実装するためには、QAの責務の分割が必要です。その実現のため、QAアーキテクティングは、QAの活動について、関心事の分離を行い、それぞれの具体的なQA活動を行えるようにすることが求められます。
QAアーキテクチャは、様々なステークホルダの調停を行う点、幅広いQA手段を扱う点から、集合知的なアプローチが活用されます。
そのためにも、QAアーキテクティングの活動にはコミュニケーションに関するプラクティスが多く含まれますし、QAアーキテクチャ自体がコミュニケーションを支える基盤になります。
また、QA活動への要求や制約をどのように調停したのか、QA要求をQAアーキテクチャにどのようにインスタンス化したのか、といった重要な設計判断をどのような集合知で行ったか記録するのも重要な活動となります。
