長きにわたって主流となっている「テストピラミッド」の考え方で品質戦略を推進するだけでは、もはや十分ではありません。より包括的な思考パターンをご紹介します。

品質とは、自動化されたテストだけで達成するものではありません。この考え方はソフトウェア業界ではかなり一般的ですが、いまだにエンジニアチームや幹部層、プロジェクトマネージャーなどにそれを理解してもらうのは困難です。

「品質担当」「品質保証スペシャリスト」「品質エンジニア」または単純に「テスト担当」など、肩書は様々ですが、その役割は徐々に進化してきました。そして急速かつ継続的に発展している「ソフトウェアエンジニアリング」の領域のサイエンスと技術に後れを取らないことが求められるようになりました。

「テストピラミッド」の概念も、Mike Cohnの著書「 Succeeding with Agile: Software Development Using Scrum （アジャイルで成功するために：スクラムを活用したソフトウェア開発）」において、初めて系統立った形で紹介され、一定の進化を遂げてきました。それ以降、この概念については書かれ、議論され尽くした感があります。テストピラミッドについてより深く知りたい方には、最もよくまとまったMartin Fowlerのこの 記事  （英文）がおすすめです。

しかし、テストピラミッドは良い品質エンジニアリングの概念のすべての側面を十分に網羅しているでしょうか？ 正直に申し上げて、それだけでは足りないと思います。少なくとも、すべての側面について明示的に触れてはいません。

それでは、より深く掘り下げてみましょう
テストピラミッドの思考パターンを良い品質戦略の基礎の一部とすることで、確実にエンジニアチームが良質なプロダクトを納品できるようになることは疑いの余地がありません。網羅的な単体テストや、様々な種類のコンポーネントテスト、サービスレベルテスト、統合テストや、少数のE2E（エンドツーエンド）テストを行うことは、品質の担保に大きく寄与します。しかし、品質エンジニアリングにおいて考慮すべきことをテストピラミッドだけで推進しようとするならば、並み以下の品質戦略になりかねません。なぜなら、他の概念を追加することで、戦略をより強化できるからです。他の概念とは何か、と疑問に思われることでしょう。良くある議論から一歩引いて、少し俯瞰で考えてみましょう。

新型コロナウイルスは、直接または間接的に、地球上のほぼすべての人に影響を及ぼしており、コロナウイルスの感染予防と安全策は引き続き私たちの生活の一部になっていますので、そこから示唆を得たいと思います。昨年、私は「感染爆発におけるディフェンス」という優れたモデルの存在を知りました。このモデルはロックダウン（都市封鎖）や行動制限、良い習慣づけの大切さの宣伝など、私たちがここ数年目にしてきた概念すべてを裏付ける根拠を理解する助けになります。

ではここで、ソフトウェアのバグが有害な細菌であり、私たちの日常生活に影響を及ぼす異常だと想像してみましょう。そして、これらのチーズの層は、その有害なバグがカスタマーのところにまで到達しないように、エンジニアチームが実施するコントロールや、品質向上のための習慣や、関門や、サポートであると考えてみます。
このディフェンスモデルの必要性についての原則は、ソフトウェアエンジニアリングにも当てはめられます。

• 一つひとつの層は完ぺきではありません。それぞれに穴があり、それらの穴が同じ場所に開いていれば、バグによるダメージは増大します。

• しかし、複数の層を重ねることによって、全体的なリスクを大幅に低減できます。

• ただし、そのためには一つだけでなく、すべての要素が必要です。

• 感染爆発の際の初期の原則の一つは、信頼できる情報源からの一貫した明確なメッセージでなければなりません。

では、「品質エンジニアリングのスイスチーズ」モデルを構成する「チーズの層」のうちのいくつかを確認していきましょう。テストピラミッドのすべての構成要素はこの中に含まれており、※印で示されていますが、他にもいくつか追加されているものがあります。

上の図では、単体テスト、統合テスト、E2Eテストが依然として主要な役目を果たしていますが、その他のソフトウェア開発のベストプラクティスも同様に重要であり、そのすべてを「品質のレンズ」を通してとらえようとしています。

例えば、アナリスト、開発者、デザイナー、プラットフォームエンジニアなどのコラボレーションを促進し、「3アミーゴスタイル（ビジネス、開発、テストなど、異なる立場の人がそれぞれの視点を持ち寄る方式）」のストーリー改善テクニックを使って、しっかりとしたストーリーを作れれば、価値ある武器がソフトウェア開発チームに加わります。これにより、よりストーリーが強靭でテスト可能なものになるだけでなく、「チームの絆」が深まるのを助け、それは高品質なソフトウェアを納品できるチームをつくる上での要となります。

このモデルを最大限活用するには
品質戦略の案を出す際に、ソフトウェア開発チームが集まって、この「ソフトウェアエンジニアリングのスイスチーズモデル」についてワークショップを行うことをお勧めします。ワークショップでは、どのチーズが最も自分たちに合っていて、どのチーズが自らのプロジェクトやクライアントに当てはまるかを考え、そのチーズたちがお互いの効果を増幅できるような順番やプログラムを検討します。それぞれのチーズのスコープやサイズはクライアントのニーズや顧客基盤などに応じて決められますが、すべてはワークショップ中の品質戦略の議論の一部として検討し、全体的・包括的に成果物の品質を担保するようにします。

このモデルの良いところは、上の図はすべてを網羅したリストではないことです。決してそうはなり得ません。例えば、他のプロジェクトも参考にするために、私の現在のチームのメンバーではない、他の同僚とこれらのコンセプトを議論してみたところ、以下のようなチーズが話題に上りました。

この他にもまだまだあるはずです。

品質エンジニアの皆さんが品質戦略を考える際に、この手法がただのチェックリスト項目やテンプレートや備忘録になってしまわないことを心から願っています。皆さんの会社で行う「ソフトウェアエンジニアリングのスイスチーズモデル」のワークショップが良い体験となりますように！