Web品質保証：ユーザー要件からWebリスク管理まで
公開: 2022-03-10貿易による化学者として、私はボルドー大学から品質管理と品質管理の修士号を取得しました。 私の最初のキャリアはワイン業界であり、研究所の運営とそこから得られた分析の質を保証していました。 ちなみに、研究室の品質保証マネージャーとしての面接の最後の質問は、「ワインは好きですか？私は好きではないと言いました。 彼らは「あなたは雇われている」と言った。
1999年に、私は品質管理の洞察をWebに適用することにしました。 私はワイン研究所での仕事を辞めました。 私はすぐに、「 Webユーザーにとって品質とは何を意味するのか」という質問に答える作業を開始しました。 」それはまた、この他の質問に答えることを意味します：「ウェブサイトの品質をどのように評価、管理、保証することができますか？」
品質保証（QA）は次のように定義されます。
「プロジェクト、サービス、または施設のさまざまな側面を体系的に監視および評価して、品質基準が満たされていることを確認するためのプログラム。」
—「品質保証」、メリアム・ウェブスター
QAは品質管理アプローチの中心的な部分であり、すべての品質管理はリスク管理と非常に密接に関連しています。 リスクが重大であると理解され認識されているほとんどのセクターでは、品質保証が必然的に発展します。 これが、品質保証が航空、自動車、健康、さらにはビデオゲーム業界の柱であり、多くの人がそれを疑問視することを夢見ない理由です。
品質保証に関連する質問への回答を検索することで、会社を設立し、オープンデータ、パフォーマンス、およびWebアクセシビリティに関するいくつかの文書化されたチェックリストと標準を作成しました。これには、アクセシビリティに関するフランスの国家標準の最初の2つのバージョンが含まれます（「RGAA 」は、 R eferentiel G eneral d' A melioration de l' A ccessibiliteの略です）。 また、Web品質保証に関する本と、UX、エコデザイン、CSS、フロントエンド開発などに関する8冊の本の序文を書くようになりました。 これらの質問に答えることは、私が何年も経った今でもWeb品質保証に情熱を注いでいる理由でもあります。 そして、私をあなたとあなたのWebプロジェクトに導くのは、これらの同じ質問です。 ちなみに、今はどこからでもワインが好きです。
品質はユーザーにとって何を意味しますか？
2001年にウェブサイトの品質保証の概念を掘り下げたとき、私たちは簡単な質問から始めました。「品質はユーザーにとって何を意味するのですか？」
ISO（国際標準化機構）によると、品質という用語は次のとおりです。
「...オブジェクトの固有の特性のセットが要件を満たす程度。」
Webサイトについてこの最初の質問をすることは、ユーザー要件を分析することを含みます。 調査中に、5つの基本的なユーザー要件で構成されるモデルを作成しました。
- 可視性とは、潜在的なユーザーがサイトに遭遇する能力です。
- 知覚は、ユーザーが使用可能で前向きに知覚できる能力を表しています。
- 技術的には、正しく機能する能力に関係しています。
- コンテンツは、質の高い情報を提供する機能をカバーしています。
- サービスは、質の高いサービスを提供、同行、および/または生成する能力を決定します。
ユーザーにとって重要な多くのユーザー要件があります。 たとえば、これらの5つの要件は、感情（喜び、愛着、感謝など）に焦点を当てるのではなく、基本的な要件の成功にのみ焦点を当てています。 このモデルは、すべてのユーザー要件を網羅的に特定することを目的としたものではありません。 ただし、それらを分類および順序付けするために使用できます。 これをVPTCSモデルと呼びました。
それは、製品やサービスが何であるか、またはユーザーが誰であるかに関係なく、次のことを示しています。
ユーザーはウェブサイトを見つけることができる必要があります。 彼らはそれを正しく使用し、知覚できる必要があり、ウェブサイトが正しく機能する必要があり、高品質のコンテンツが必要であり、また訪問後の良い経験が必要です。
Web品質保証はUXとUIにどのように関連していますか？
Web品質保証に取り組むには、品質定義の別の部分であるオブジェクトの固有の特性にも取り組む必要がありました。 それはウェブサイトが何であるかを説明することを意味します。 そのため、UXの構造（ユーザーエクスペリエンス）と、それがUI（ユーザーインターフェイス）とどのように関連しているかについて作業することになりました。 そのために、VPTCSモデル（可視性、知覚、技術、コンテンツ、サービス）も使用しました。
モデルは、ユーザーのサイトへのアクセスと、前、中、後の3つの主要なフェーズに関連する時系列で読み取ります。
- V ：訪問前
- PTC ：中
- S ：訪問後
以下に示すように、VPTCSモデルを使用して、総合的なユーザーエクスペリエンス（UX）とユーザーインターフェイス（UI）を区別することにしました。 UIは、モデルの3つの中心的なセクションである知覚、技術、コンテンツでカバーされており、旅の一部にすぎません。
UXは、UIの前に開始し、UIの後に終了します。
可視性により、ユーザーが到着した理由と方法に関心を持ってもらうことができます。 ユーザーがインターフェースに遭遇する前に、可視性が始まります。 たとえば、検索エンジンの結果ページでWebサイトが説明される方法や、ソーシャルメディアで人々がWebサイトについて話す方法。 それはすべてユーザーエクスペリエンスの一部です。
モデルのもう一方の端では、[サービス]セクションから、ユーザーがインターフェイスを離れた後に何が起こるかを確認できます。 たとえば、eコマースサイトでは、サイトを離れた瞬間にエクスペリエンスが終了するのではなく、継続します。 たとえば、カスタマーサポートに連絡できない場合、実際の人と話すのに20分待たなければならない場合、パッケージが破損しているか部分的に開封されている場合、またはWebサイトの製品説明が正確でないことに気付いた場合です。 。 このような場合、インターフェース自体は使用しなくなりますが、実際のユーザーエクスペリエンスで対話します。
VPTCSモデルは、Webサイトとは何か、ユーザーの要件は何かという視点を提供してくれましたが、Webプロジェクトの利害関係者、つまり設計、作成、開発、商品化、またはマーケティングの利害関係者への影響も判断したいと思いました。ウェブサイト。
Web品質保証にはどの取引が関係していますか？
「企業の製品で高品質のユーザーエクスペリエンスを実現するには、エンジニアリング、マーケティング、グラフィックおよび工業デザイン、インターフェイスデザインなど、複数の分野のサービスをシームレスに統合する必要があります。」
—「ユーザーエクスペリエンス（UX）の定義」、DonNormanとJakobNielsen
Web品質保証に取り組み始めたとき、ユーザー要件（可視性、知覚、技術、コンテンツ、サービス）を特定するだけでは不十分であることがわかりました。 品質保証アプローチに専門家の賛同を得るために、Webプロジェクトに関係するさまざまな分野を特定し、それらを要件に関連付ける必要がありました。 さまざまな取引をマッピングする際に、すべての取引が必要であり、それらすべてに少なくとも1つの共通点（ユーザー）があることがわかります。
この時点で、ユーザー側の一連の要件と、Web取引がこれらのユーザー要件にどのように関連しているかを理解するための一連のツールがありました。
品質の概念に取り組むことは、常に学際的なアプローチです。 各ユーザーは、製品の品質について独自の主観的な見解を持っています。 一部のユーザーは技術的な問題に敏感であり、他のユーザーはコンテンツの品質に夢中になっており、一部のユーザーはサービスの品質に深く影響を受けています。 品質を評価することは完全に客観的ではありませんが、一般的なユーザー要件をより実用的なツールに変換することは常に可能です。 そのために作成できる最も簡単なツールの1つはチェックリストであり、私たちはまさにそれを実行しました。
ユーザー要件を実用的なチェックリストに変換する
「私たちは失敗を克服するための別の戦略を必要としています。それは経験に基づいて人々が持っている知識を利用するものですが、どういうわけか私たちの避けられない人間の不備を補います。 そして、そのような戦略があります—その単純さではほとんどばかげているように見えますが、これまで以上に高度なスキルとテクノロジーを注意深く開発するのに何年も費やしていない私たちにとっては、おそらく夢中です。
これはチェックリストです。」
— Atul Gawande、チェックリストマニフェスト
次のチェックを適用して、VPTCSモデルを個々のルールに変換することにしました。
「普遍的で、現実的で、持続可能で、エンドユーザーが直接検証できる、ユーザーのコンセンサスと付加価値を備えたルールはありますか？」
2004年に、公開オンラインワークショップでWebプロフェッショナルのOpquastコミュニティに一連のルールを提出しました。 ルールを提出するための次の基準を提供しました。各ルールは、ユーザーに説明された影響を与える必要があり、現実的であり、コンセンサスがあり、普遍的であり、エンドユーザーによって検証可能である必要があります。 この「ルールを作成するためのルール」のセットは、コミュニティが受け入れて使用できるルールのみを保持するための健全性テストです。
それ以来、2004年、2010年、2015年、2020年の4つのバージョンのチェックリストを作成しました。合計で10,000を超えるコメントを収集し、1,000を超える品質ルールを破棄し、健全性テストに合格した240のみを保持しました。 。 このチェックリストは、他のプライバシー、セキュリティ、アクセシビリティ、SEO、またはエコデザインのチェックリストや標準に代わるものではありません。 これは、Webプロジェクトに適用される、チェック可能で、現実的で、有用で、普遍的な、数値以外の主なルールをリストすることだけを目的としています。
重要なのは、すべてのWeb専門家に受け入れられ続けていることであり、それが、オープンライセンスCC-BY-SA（Creative Commons Attribution–ShareAlike License）の下で作業することを決定した理由でもあります。 目的（ユーザーにとっての付加価値）、ルールの実装方法（実装可能性）、およびルールの検証方法（検証可能性）をリストしたカードを作成しました。 ちなみに、ルールに数値を含めることはできません。 私たちはこれを難しい方法で学びました。最初のバージョンをリリースした後、ルールの1つは、画像とホームページを合わせて150koを超えることはできないと述べていました。 2004年には現実的に見えましたが、ルールは2005年までにすでに無関係でした。少なくとも5年間はルールの関連性を維持する必要があり、数値の制限を決定することは、私たちが到達しようとしているコンセンサスに深刻な打撃を与えます。 そこで、この制約を健全性チェックに追加しました。
240のルールは、開発者からカスタマーサポート、管理から運用、UXデザイナーからコンテンツプロデューサーまで、Webチームのすべての役割に影響を与えます。 たとえば、240のうち35のルールがあり、エコデザイン、23はセキュリティ、37はSEO、126はアクセシビリティ、38はeコマースに関連しています。
最も論理的で明白なアプローチは、チェックリスト（これまたは他のもの）を構想またはリリース前のツールとして使用することです。 私たちの場合、これは、各ルールの制御セクションの助けを借りて、この完全なチェックリストを監査に使用できることを意味します。 また、チェックリストの抜粋を使用して、構想および設計プロセス中に使用することもできます。
ただし、Web品質保証プロセスを効率的に開始するために必要な最初のことは、監査または事前起動ではないことがわかりました。 ルールを順守する前に、ルールがプロジェクトでの役割に直接関係していないように見える場合でも、Webプロジェクトに関与するチーム全体がルールを理解していることを確認する必要があります。
- *チェックリストの最新バージョンを参照してください（フランス語、英語、スペイン語で利用可能な240枚のカード、2020年）*
Web品質保証チェックリストの使用方法は？
一見、ルールで理解する最も重要なことは、ルール自体です。 しかし、ルールが存在する理由は、もっと興味深く洞察に満ちているかもしれません。 ルールn°233の例を見てみましょう：「内部PDFドキュメントのテキストを選択できます。」
このルールへの準拠が役立つ可能性のあるユーザーコンテキストをリストしてみましょう。
- PDFファイルの内容は、スクリーンリーダーで読み上げることができます。
- PDFファイルのコンテンツは検索エンジンで索引付けできます。
- PDFファイルの内容を検索できます。
- PDFファイルの内容は翻訳できます。
- PDFファイルの内容をコピーして貼り付けることができます。
これらのユーザーケースは、5人の異なるユーザーに関係する可能性があります。
- スクリーンリーダーを使用している目の不自由なユーザー。
- 検索エンジンでコンテンツを検索するユーザー。
- ドキュメント内の特定のコンテンツを検索するユーザー。
- ドキュメントの言語を話せず、翻訳が必要なユーザー。
- ドキュメントのコンテンツの一部を再利用したいユーザー。
または、上記の5つのケースを経験する同じユーザーに関係する場合もあります。 たとえば、目の見えないブルガリアの科学者が、ウェブ上で引用されている場所を検索し、英語でPDFを見つけ、PDFファイルで自分の名前を検索し、自動的にブルガリア語に翻訳して、コピーして貼り付けることで終了するとします。彼/彼女のポートフォリオのコンテンツの一部。
つまり、240のうち1つのルールだけで、ルールがユーザーにとって役立つ5つのコンテキストを特定できます。 これは、さまざまなコンテキストで画面の反対側にいるユーザーに共感を呼び起こす方法であることを意味します。
したがって、品質ルールを検討する専門家にとって最初にすべきことは、ルール自体をどのように適用するかではなく、ルールが何であるか、誰のためにあるのか、なぜ存在するのかを理解することです。 すべてのルールはユーザーにとってメリットがありますが、Webプロジェクトの現実は、専門家には無制限の手段がないということです。 したがって、彼らは決定を下す必要があり、最後に、専門家はルールを適用するかどうかについて情報に基づいた決定を下せる必要があります。
Webプロフェッショナルとして、また参加するWebプロジェクトの手段が限られているにもかかわらず、サイトの品質を客観的に評価し、その評価の根拠について議論および説明し、リスクを特定し、調停することができなければなりません。既知の事実の完全な知識。
品質保証は、統合された組織全体のチーム（Webデザイナー、管理、販売、開発者、マーケティング、アフターセールス、配信ドライバー）の主要な反射となる必要があります。ユーザーエクスペリエンスに関与するすべての人々です。
振り返りのこの時点で、Web品質保証を展開するための初期のツールセットがありますが、それはWeb品質保証とWeb品質管理をプロセスに統合するために必要なすべてを備えているという意味ではありません。
さらに先に進むには、Webプロジェクトの主なリスクを調べる必要があります。
Webプロジェクトの主なリスクはどこにありますか？
「リスク評価とは、個人、資産、および/または環境に悪影響を与える可能性のある潜在的な（将来の）イベントを特定して分析することを組み合わせた取り組みです（つまり、ハザード分析）。 影響要因（リスク評価）を考慮しながら、「リスク分析に基づくリスクの許容度」を判断する。
—「リスク評価」、ウィキペディア
私たちの業界全体は、そうです、ウェブ活動が豊富なリスクを伴うという難しい方法を学びました。 同様に、航空、自動車、健康などの他の業界でも。 各リスクは、それが重大であるかどうかを考慮して分類する必要があります（ハザード分析）。
リスクを重大であると認識することは、常に部分的に主観的です。 したがって、ウェブ業界の場合、リスクが特に重要な4つのテーマを見つけました。 これらの主題のうちの3つ（アクセシビリティ、セキュリティ、プライバシー）は、ユーザーに大きな影響を与える可能性があります。 これらの結果は、ブランドイメージとビジネスにも悪影響を与える可能性があります。 それらは、ユーザーにとっては計り知れない問題、収益の損失、訴訟につながる可能性があります。
私が選んだ最後の主題（エコデザイン）もまた、私たちの個人的および職業的生活に大きな潜在的影響を与える体系的な観点から重要です。
ビジネスに実際に害を及ぼす可能性のある問題はたくさんありますが（パフォーマンスの低下、UXデザインの悪さ、SEOの不足など）、一般的に、以下で特定する4つほど害はありません。 リストされている4つの主題は、あなた、あなたが協力している企業やクライアント、そして何よりもまずユーザーにとって、はるかに重要です。
これらの4つの主題とそれに関連するリスクは、すべてのWebプロジェクトに存在します。 それらを見てみましょう：
- アクセシビリティ
私のサイトは障害を持つ人々がアクセスできますか？ 私は特定の人々を差別していますか？ もしそうなら、リスクは何ですか？
Accessibility.comが発行したレポートでは、昨年265,000件のWebサイトのアクセシビリティ要求書が企業に送信されたと推定され、2020年だけでアクセスできないWebサイトの直接の結果として、米国企業はおそらく数十億ドルの法定費用を費やしました（出典： BOIA ）。 - 安全
私のプロジェクトは私の組織、同僚、またはユーザーを危険にさらしていますか？ もしそうなら、リスクは何ですか？
govtech.comによると、2020年には、2019年と比較してデータ侵害による侵害されたレコードが141％増加しました。データ侵害活動について報告して以来、1年間で最も多くのレコードが公開されました（www.govtech.com ）。 彼らはまた、2020年の時点でのデータ侵害の平均コストは386万ドルであると報告しました（出典： IBM ）。 - プライバシー
会社のデータ、ユーザー、または従業員のデータを危険にさらしていますか？ 潜在的な結果は何ですか？
一般データ保護規則（GDPR）は2018年5月に発効しました。GDPRにより、EUのデータ保護当局は最大2,000万ユーロ（2,410万ドル）または世界の年間売上高の4％（いずれか高い方）の罰金を科すことができます。 […]GDPRに基づく罰金は、合計1億5,850万ユーロ（1億9,150万ドル）でした。 （出典： Tessian ）。 - エコデザイン
私のプロジェクトの環境への影響は何ですか？ 私のプロジェクトは気候変動にどの程度貢献していますか？
非営利団体であるシフトプロジェクトは、デジタルテクノロジーの環境への影響に関する170近くの国際的な研究を調査しました。 専門家によると、世界のCO2排出量のシェアは2013年から2018年の間に2.5％から3.7％に増加しました[…] Borderstep Instituteはさまざまな研究を比較し、デジタルの生産、運用、廃棄によって引き起こされる温室効果ガス排出量を結論付けていますエンドデバイスとインフラストラクチャは、世界の排出量の1.8〜3.2％です（2020年現在）。 （ソース： RESET ）。
上記のリスクを無視するわけにはいきません。 過去10年間で、これらのリスクとその結果は増加し、コストの急上昇、再設計の失敗、訴訟、サイバー攻撃、スタッフの燃え尽き症候群、離職率の高さ、環境への影響などを引き起こしています。 前の例でわかるように、これらはすべて、経済的、人的、社会的、環境的コストがかかり、業界ではこれらすべてを回避する必要があります。
現在Webで見ているのは、若い業界の非常に古典的な成熟段階であり、顧客がより高い品質を要求し、プロバイダーがそれを達成するために品質目標を設定するにつれて、標準、方法、およびフレームワークが徐々に展開されます。 アクセシビリティ、エコデザイン、パフォーマンス、セキュリティ、プライバシーなどのさまざまなリスクとドメインは、ますます構造化され、標準化され、国内法や規制の対象となっています。
解決すべき同様の品質管理方程式に直面している確立された業界で何が出現したかを見てみましょう。
学際的なWeb品質管理に向けて
80年代の変わり目に、品質管理の専門家は主にISO9000規格を使用して、品質の問題に取り組んでいました。 1990年頃に教えられたのは、品質管理、品質保証、品質管理だけでした。しかし、ISO14000は環境の基準であり、ISO 27000はITセキュリティの基準であり、さまざまなリスクに取り組んでいる人々がいました。
これらの管理標準のコンプライアンスと展開は、産業会社の個別の部門によって推進されました。 ある時点で、すべての標準がリンクされ、おそらく相互に関連するタスクやツールがたくさんあったため、企業はHQSE （ H eath Q uality S ecurity E nvironment）サービスを作成しました。 この種のアプローチは「統合管理システム」と呼ばれます。
「昔々、H＆S（安全衛生）マネージャーがいて、その役割はHSE（健康、安全、環境）マネージャーにまで拡大していました。 同時に、HSEスーパーバイザーとは完全に独立した役割を持つ品質マネージャーがいました。 しかし、テクノロジーがワークフローにますます統合され、迅速で高品質のサービスと製品に対する需要が高まるにつれて、役割は1人のQHSEマネージャーに統合されました。」
—「Let'sBuild」、Houdayfa Cherkaoui
品質管理または統合管理システムについて知っておくべき非常に重要なことがあります。それは、品質を「生成」せず、環境またはセキュリティコンプライアンスを提供しないということです。 それらは、組織の他のメンバーがこれらの主題を管理および改善するのを助けるだけです。 これらの部門の担当者はいずれも専門家に取って代わるものではなく、ツール、標準、機械の自動化などを提供するだけです。 これらは、企業が一定レベルの品質を提供できることを証明する必要がある場合に、すべての人が最新の状態を保ち、クライアントとやり取りするのに役立ちます。
今、私は未来に賭ける時が来ました。 航空、自動車、医療などのすでに確立された業界で起こっているように、品質保証はリスク認識の直接的な結果として導入されています。 Webチームはすでにリスクを個別に管理していますが、ユーザーはすべてのリスクに関心を持っていますが、Webプロジェクトを構築または維持するときに対処しなければならないすべての主題をまとめる、学際的なアプローチが必要になります。
何が起こるかを正確に言うのは時期尚早ですが、私が想像しているのは、さまざまなWeb取引と領域を組み立て、維持し、近づけるWebQAの新しいレイヤーの統合です。
この記事で何を取り除くか
私の旅の途中で（私はそれが終わっていないことを願っています）、私はかなり多くのことを学びました。
Web品質保証を展開するには、ユーザーの要件と、Webプロジェクトに関連するWeb取引の結果を理解する必要があります。 VPTCSモデルに戻ると、私たちが観察した最も重要なことの1つは、可視性とサービスの部分がWebチーム、特にWebサイトの所有者によってしばしば過小評価されていることです。
また、ユーザーに最大の価値をもたらす2つの要件は、コンテンツとサービスであることがわかりました。 ただし、Webプロジェクトでは、可視性、知覚、および技術のカテゴリに分類される役割で作業するWebプロフェッショナルが最も重要であると認識されることがよくあります。 Webプロジェクトチーム内にシームレスに統合された高品質のコンテンツとサービス（サポート、ロジスティクス、配信など）がなければ機能しません。
私たちが学んだもう1つのことは、UIは純粋に視覚的で人間工学的な仕事として認識されることが多いということです。 UIが知覚、技術、コンテンツの組み合わせであることを示すことで、リモートで作業するさまざまなチーム間の誤解を減らすことができます。 そのため、すべての取引を関与させ、連携させる統一されたチームが必要になります。
Web業界標準には、規制、単体テスト、機能テスト、自動ツール、手動監査、チェックリストなど、さまざまな形式の品質保証がすでに存在します。 ウェブでは品質保証が徐々に向上していますが、私に関する限り、私たちはまだ道のりの始まりに過ぎません。 まず、チェックリストは、コンプライアンスに到達するためだけでなく、共通の文化や語彙を共有するために使用できる非常にシンプルなツールです。
Webチームはコンプライアンスのチェックリストを使用できますが、私自身の経験では、コンプライアンスを改善したい場合、およびWeb品質保証を組織に持続的に展開したい場合は、最初に共通の語彙を使用してWeb品質文化を作成する方が効率的です。ブートストラップの基本的なフレームワーク。
「デジタルトランスフォーメーションプロセスに参加している人の63％は、文化が最大の障壁であると述べています….56％は、部門間のコラボレーションを3番目に大きな課題として述べています。」
—高度計とキャップジェミニの調査
目標は、リスクを共有する文化的基盤（私が言及したものや他のすべてのものなど）と、ユーザーに向けられた責任を作成することです。 グローバルなルールセットは、Webチームに権限を与え、グローバルな文化と語彙を作成するために使用できるソリューションの1つですが、Webプロジェクトのグローバルな相互リスク管理システムも伴う必要があります。 この管理システムは、複雑な問題について専門の専門家を呼び出すことができる一連のグローバルなルール、標準、およびツールを処理する必要があります。
Web品質保証は、ユーザー、顧客、および市民の最善の利益を代表する品質管理者として訓練され、権限を与えられた、より責任のある専門家の存在に貢献することができます。
旅は続きます。
参考文献
- 「品質管理」、ウィキペディア
- 「VPTCS：UXおよびWeb QAモデル（2001）」、Elie Sloim、Medium
- 「Web品質保証チェックリスト」Opquast
- 「統合管理システム」、ISO