この記事では、Slalom Buildの品質エンジニアリングチームより、当社の品質エンジニアリング基本原則をご紹介します。これらの原則は、ソフトウェア開発の品質を担保するうえで、私たちの観点を明らかにし、伝えるためのものです。ソフトウェア納品の手法の核としてこの原則を確立しましたので、これを世に広く共有したいと考えました。この記事が皆さんのお役に立ち、品質を保ちながら最先端のソフトウェアを納品するうえでの課題についての議論の呼び水となることを願っています。

なぜ基本原則が必要なのか
Slalom Buildでは、この品質エンジニアリング基本原則を通じて、私たちの品質へのアプローチの全体的な概要を定義し、伝えています。これらの4原則は、高い品質を実現するための私たちの意見と推奨する手法を表します。私たちは、その他のあらゆる対立する概念ではなく、この原則に従うことで、結果がより予測しやすくなり、より高い品質のソフトウェアを納品できるようになると信じています。

最新のソフトウェアを開発する際に品質を担保する最善の方法については、多くの異なる見方が存在します。テストの専門家から成る品質専任チームもあれば、担当者を設けずに自発的なアジャイルPODで進める場合もあり、また、コードを書く前にテストをする場合もあれば、オフショアの自動化サービスを利用する場合もあるなど、どのようなチームを組織し、タスクの順序を決め、担当者を任命してソフトウェアの品質を担保するかを決めるには幅広い選択肢があり、開発チームはその中から選ばなくてはなりません。これらの手法の多くは併用できず、どのような組織にとっても、そのどれを選ぶのかを明確に決定することは非常に重要です。

この基本原則は私たちの強い信念を短い言葉でまとめたものですが、何かを指示するものではありません。それぞれの状況の課題に適切に対応するには、プロジェクト、技術スタック、領域、チームに特有のニーズに合わせてカスタマイズを行う必要があります。そのため、基本原則は「こうありたい」という方向性を示しはしますが、プロセスやアプローチを実行する人が、必要に応じて柔軟にやり方を変える余地があります。私たちの原則は目印となる星のようなもので、戒律ではないのです。

私たちの観点をまとめるためにこの基本原則を定義しましたが、これを実行するにはチーム全体のコラボレーションが必要になります。ソフトウェア開発のすべての側面が品質に影響を及ぼすため、品質戦略を定義して実行するには、ソフトウェアエンジニア、プログラムマネージャー、DevOps エンジニア、ビジネスアナリストなど、品質エンジニア以外のすべての担当者にも関与してもらう必要があります。品質へのアプローチはチームによるアプローチであり、品質エンジニアが一方的に考えて実行するものではありません。これらのグループのそれぞれが品質を担保する手法を効果的に実践できるよう、自分たちにとって品質が何を意味するのか、共通理解を持つことが必要です。

1.     チーム全体で責任を持つ
私たちは、チーム全体で品質に責任を持つことが必要だと考えています。高品質のソフトウェアを成功裏に納品するには、チーム全体の関与が求められます。品質への責任は、一つの役職や個人にだけ担わせるべきものではありません。ソフトウェアチームの一人ひとりが納品物の品質に責任感を抱き、その品質に自分がどのように貢献するのかを理解し、その責任を積極的かつ熱心に果たしていかなければなりません。

品質への責任を「品質保証（QA）」担当者だけに担わせ、製品リリースの前にコードの品質を彼らに保証させようとするなら、実のところ、高品質の製品を納品するための彼らの能力は損なわれます。この権限移譲は、好意的に言っても、悪気はないが判断を誤った品質保証戦略です。悪く言えば、これは品質保証担当者をスケープゴートにして、問題が起こった時に企業の経営陣が責任を逃れようとする意図的な試みです。私たちは、現在のソフトウェア開発において、品質への責任を細分化させることが効果的な戦略になりうるとは考えていません。

 
チーム全体で責任を持つという哲学を体現する組織は、それとは異なる行動を取ります。「それは私の仕事じゃない」とは決して言わず、コードを無責任に書き散らすことはなく、自分の作業の最適化を怠ることもなく、また、「なぜQAはこれを発見できなかったのか」と問うこともありません。チームのすべてのメンバーが継続的に深いコラボレーションを行い、共通の目標に向かってただ進んで行くのみです。このように行動するチームは、一つの役職や個人よりもはるかに強力で、隅々にまで行き渡る品質への推進力を生むことができます。このチーム全体が責任を持つ文化は、私たちがすべての開発において目指すものです。

2.     チームの力となる
私たちは品質エンジニアの役割の重要性を信じており、その役割とは、品質を重視することの重要性を体現することでチームの力となることです。品質エンジニアは、テストの自動化、品質保証、アジャイル開発プロセス、CI/CDなどの専門知識をチームにもたらします。たくさんあるんだな、と思われたかもしれませんが、実際にたくさんあるのです！ あらゆることが品質に影響を及ぼすため、品質エンジニアはソフトウェア開発のすべての側面と、それらと品質との関連性を理解していなければなりません。品質エンジニアはこの専門知識を活用して品質の擁護者・伝道者となり、影響を与え、その重要性を説きますが、（基本原則の1で説明したように）彼らだけが品質を担当するわけではありません。

品質エンジニアはすべてのアジャイル開発チームの中心となります。彼らは開発チームの外側や隣にある独立したチームではありません。彼らは開発チームの中にいて、開発作業において他のメンバーと対等の立場で協働します。例えば、開発チームの中で品質エンジニアは自動化フレームワークを構築し、開発者とタッグを組んでストーリーを実装し、ストーリーの受け入れ条件とテストの実施可否について意見を述べ、ユースケースの理解を深めるためにユーザーの話を聞きます。品質エンジニアの役割には非常に多くが求められ、エンジニアリングの専門知識、高いコミュニケーション能力、ユーザーへの共感力、「創造的破壊」を起こす物の見方が必要とされます。

現在のソフトウェア開発においては、品質担当者を全く置かず、着想から本番までを通じて開発者がコードに責任を持つことを期待するような品質へのアプローチも存在します。このようなアプローチがうまく機能する組織や状況もあり、それが間違いであるとか方向性を誤っているなどと述べているわけではありません。ただし、品質エンジニアリングの専門家でもある開発者を見つけることは難問です。チームのメンバーに品質エンジニアリングの役割に特化させたほうが、より強力で効果的なチームを自然に形作ることができます。また、品質担当を外部のチームや企業に委託するやり方もありますが、私たちはこの種のあらゆる戦略に断固として反対します（基本原則の3をご参照ください）。私たちの最先端のアジャイルソフトウェア開発手法においては、あらゆる開発チームにおいてその不可欠な一部として機能する専任の品質エンジニアが最も優れた結果をもたらします。

3. 近くにあることの重要性
私たちは、開発とテストの活動がお互いに近接していることが利点をもたらすと考えています。ソフトウェア開発の成功にはすべてのチームメンバーの間のコラボレーションが必要とされますが、特に私たちは開発とテストの間の密接な連携の必要性を強調したいと思います。なぜなら、よくある開発手法の多くが開発とテストを分けてしまっているからです。分離してしまうことで、品質を担保しながら開発を行うことができなくなってしまいます。

近接とは必ずしも物理的な近さではありません。同じ小さなチームのメンバーが、やり取りを妨げる（プロセスや技術などの）障壁なしにリアルタイムでコラボレーションをしながら、開発とテストを（実質的に）同時に行うことを意味します。開発者と品質エンジニアは成果物の共同制作者であって、組み立て工程の一部ではありません。その意味するところは、リリース前やスプリントの最後ではなく、ソフトウェアの開発過程に品質の検証が組み込まれるということです。品質を担保することは開発の不可分な一部です。

では、実際にはどのようになるのでしょうか。例えば、品質エンジニアがコード検証やマージのリクエストに関与します。例えば、ストーリー構築の一環として、多くの場合は品質エンジニアと共に、開発者が（あらゆる種類の）テストを計画します。例えば、品質エンジニアがテストの可否の観点からアーキテクチャーの計画を確認し、ユーザーストーリーをより良いものにしていく過程の中で、開発者やプロダクトオーナーと共に、特殊なケースや考えうる悪影響を一つ一つ話し合います。これらすべての活動が、品質と開発をミックスし、開発とテストの作業をより近接させることにつながります。

このように私たちは近さの重要さを唱えていますが、チームメンバーの具体的な役割や担当業務、日々の作業のやり方は、チーム自身で決めるべきものです。近接性を高めるには多くのやり方があります。TDD（テスト駆動開発）は必須ですか？　ストーリーについてペアを組むことは推奨でしょうか、必須でしょうか。具体的にだれがいつ、それぞれの種類のテストの計画を立てますか？　それぞれのチームがこれらの質問への答えを決めることができ、自分たちにとってうまくいくやり方を構築できます。

開発とテストの近接性を低下させるやり方は、どのようなものであっても、双方の効率と効果を減少させ、チームが品質を担保しながら納品を行うことを困難にします。私たちはこれからも自分たちの現在のやり方を批判的に見直しながら、開発とテストの近さを促進できるよう、継続的に改良を図っていきます。

4. 自動化は必須
高品質なものを迅速に納品するために、自動化は必要不可欠です。ソフトウェアは飛躍的に複雑化し、デプロイメントはより段階的に改良を繰り返すプロセスに移行しているため、手作業のゆっくりとしたテストでは、プロジェクトの速度を維持できません。検証作業が開発のペースに後れを取らないためには、自動化が必要です。段階的に改良を繰り返す納品手法を取りながらテストの自動化に十分な投資をしなかった場合、必ずリグレッションの負の連鎖に陥ります。

一部の企業はテストの自動化を優先事項としてはいますが、その多くは生産性向上の恩恵を十分に得られていません。テストを自動化するためのコードを書いただけでは、必ずしも恩恵は得られません。十分な計画や見通しなしに、一方的に一定数や一定の割合のテストを自動化するようチームに要求すれば、速度の遅い肥大化した自動テスト群ができあがり、往々にしてその結果は無視され、ほとんど価値が出せません。

健全なテストの自動化はソフトウェアエンジニアリングの一種として扱われ、製品開発と同様の厳格なプロセス（デザインレビュー、コードレビュー、lintによる解析など）を活用すべきです。品質エンジニアはチームと協働し、ソフトウェアのアーキテクチャーや技術スタックの特徴に合わせて自動化戦略を決め、継続的に進化させます。この難しさを理解し、プロジェクトの迅速化につながる自動化アプローチを促進することは、品質エンジニアが開発チームにもたらす専門性の重要な領域の一つです。

まとめ
これら4つの基本原則が、ソフトウェア開発において品質を担保する方法についての私たちの観点を定義したものです。これが品質についての唯一のアプローチというわけではなく、成功しているソフトウェア会社の中には異なる考え方をする企業も多くあり、それは問題ありません。これらの原則は、私たちが長年にわたり何百というクライアントにソフトウェアを納品する中で培われ、改良されてきており、私たちのプロジェクトや開発モデルに適したものです。いずれもオリジナルな考えではなく、すべては今までに品質についての考え方を広く共有してきた企業や個人に影響されたり、そこから発展させたりしたものです。これらの原則は完ぺきなわけでも、すべてを網羅したものでもなく、不変のものでもありません。最先端のソフトウェアを納品するうえで品質を保証することの複雑さ、難しさについて長期的に深い議論を行うためのきっかけにすぎません。私たちは一つ一つのプロジェクトにおいてこの原則の達成に努めていきますが、私たちの理解は常に進化し、そしてこの業界も絶えず変化しています。今日うまく機能するものが明日も機能するとは限りませんが、次の課題に向けてアプローチを改良していくことは、この仕事の楽しさの一部でもあります。

一つ一つの基本原則は、ここに書けるだけでは十分でなく、もっと詳細に語るべきものです。ただ、上記の紹介文だけでも、私たちが何者で、何を信条とし、最先端のソフトウェアを品質を担保しながら納品するという複雑な課題にどのようなアプローチをとりたいと考えているかをお分かりいただけたかと思います。今後、それぞれの基本原則についてより詳細に語り尽くした記事を公開できればと考えています。