「W3C Community and Business Groups」のひとつ、「Sustainable Web Design Community Group」がウェブサイトやプロダクトをよりサスティナブル（持続可能）にするための多岐にわたるガイドラインををまとめた、「Web Sustainability Guidelines (WSG) 1.0」（下記リンク参照）を「W3C CG/BG レポート（W3C Community Group/Business Group Report）」として公開したのが昨年、2023年の8月末でした。

W3C CG/BG レポートは、今後、正式な標準化プロセスに進むかどうかも不明なドラフト（草案）ですので、この仕様を現時点でそのまま実務に導入することはありません。

しかし、内容的には興味深かったのと、普段、弊社でも品質管理、というよりも開発・制作方針や制作ガイドラインの方が近いかもしれませんが、自社の制作物に対して考慮、あるいは重要視していることと一致、あるいは近い内容の項目も多かったため、本コラムでも取り上げようと思いつつ、結局1年間、書かずに放置したままに。

昨日、2024年8月26日付けでドラフトが更新されていることに気がついたのと、ちょうどコラムを書かないといけないタイミングというものありましたので、ここで取り上げてみることにします。

Web Sustainability Guidelines (WSG) 1.0の概要

「Web Sustainability Guidelines (WSG) 1.0」は、前述の通り、ウェブサイトやプロダクトをよりサスティナブル（持続可能）にするためのガイドラインをまとめたものです。

サスティナビリティ（持続可能性）の文脈では、『3つのP』、「人々（People）」「地球（Planet）」「利益（Profit）」という概念がよく用いられます。この3つのPのバランスが保たれている社会こそが、目指すべき持続可能な社会の姿であるという考え方です。

「Web Sustainability Guidelines (WSG) 1.0」は、この3つのPの概念をウェブサイトやプロダクトの設計、デザイン、開発や、それに関連する意思決定プロセス全体で活用することで、ユーザー中心の設計、パフォーマンス重視のウェブ開発、再生可能エネルギーを用いたインフラや持続可能なビジネス戦略を実現し、さらに、これらの要素を組み合わせることによって、ウェブサイトやプロダクトが与える環境への影響を最小限に抑えることが可能であるとしています。

「Web Sustainability Guidelines (WSG) 1.0」には6つの「原則」が定義されており、これら原則に基づいて各ガイドラインが定められています。

  • クリーン（Clean）
  • 効率的（Efficient）
  • オープン（Open）
  • 誠実（Honest）
  • 再生可能（Regenerative）
  • 回復力（Resilient）

また、ガイドラインは大きく下記の4つの「カテゴリ」に分類されています。

  • ユーザーエクスペリエンスデザイン
  • ウェブ開発
  • ホスティング、インフラ、およびシステム
  • 事業戦略、およびプロダクトマネジメント

形式としては、「Web Content Accessibility Guidelines (WCAG) 2.x」と似たようなものになりますが、各ガイドラインには、WCAGでいう、「適合レベル」の代わりに、「影響度」と「労力」という2つの指標と、それぞれに「Low（低）」「Medium（中）」「High（高）」という3段階の評価が付与されています。

各ガイドラインには、「達成基準」、つまりどうすればそのガイドラインを満たしたことになるのか、という説明と、それが機械的にテストできるものなのか、それとも人がテストすべきものなのかについても記載されています。

デザイナーの方であれば、「ユーザーエクスペリエンスデザイン」カテゴリが。

ウェブディレクターの方であれば、「ユーザーエクスペリエンスデザイン」カテゴリに加えて「ホスティング、インフラ、およびシステム」カテゴリが。

フロントエンドのエンジニアの方であれば「ウェブ開発」や「ホスティング、インフラ、およびシステム」カテゴリの内容が普段の仕事の範疇に関わってくるかもしれません。

「事業戦略、およびプロダクトマネジメント」カテゴリが関係してくるのは経営者やマネジメント層など、開発・制作現場というよりもう少し大枠の意思決定を行う方々になりそうです。

イントロダクションの章でも書かれているとおり、まずは自分の仕事やスキルセットにマッチしたガイドラインの中から、影響度と労力を考慮して取り組みやすそうなものを考えてみるとよいでしょう。

ガイドラインの中身を少し掘り下げ

「Web Sustainability Guidelines (WSG) 1.0」のガイドラインは数が多いため、全部を細かく紹介するのは難しいですが、下記に各ガイドラインだけを日本語訳したものを掲載しておきます。また、その中からいくつか簡単に取り上げてみたいと思います。

  • 2. ユーザーエクスペリエンスデザイン
    • 2.1 システミック・インパクト・マッピングを実施する
    • 2.2 訪問者のニーズを評価し、調査する
    • 2.3 非訪問者のニーズを調査する
    • 2.4 アイデアの初期段階で持続可能性を考慮する
    • 2.5 ステークホルダーの問題を考慮する
    • 2.6 既定で軽量なエクスペリエンスを作成する
    • 2.7 不必要な、あるいは過剰なアセットを避ける
    • 2.8 ナビゲーションと導線を構造化する
    • 2.9 訪問者の注意を尊重する
    • 2.10 認知されたデザインパターンを使用する
    • 2.11 操作的なパターンを避ける
    • 2.12 プロジェクト成果を文書化し共有する
    • 2.13 インターフェイスの一貫性を優先するためにデザインシステムを使用する
    • 2.14 目的をもって、アクセスしやすく、理解しやすい形式で書く
    • 2.15 画像アセットに対してより持続可能なアプローチを採用する
    • 2.16 メディアアセットに対してより持続可能なアプローチを採用する
    • 2.17 アニメーションに対してより持続可能なアプローチを採用する
    • 2.18 書体（フォント）に対してより持続可能なアプローチを採用する
    • 2.19 ウェブアセットに対する適切な代替案を提供する
    • 2.20 アクセシブルで使いやすい、最小限のウェブフォームを提供する
    • 2.21 コンテンツと対話するための非グラフィカルな方法をサポートする
    • 2.22 カスタマージャーニーを改善するために有用な通知を提供する
    • 2.23 ダウンロード可能な文書、または物理的な文書の影響を軽減する
    • 2.24 ステークホルダー重視のテスト・プロトタイピング方針の策定
    • 2.25 定期的な監査、回帰テスト、非回帰テストの実施
    • 2.26 各メジャーリリースサイクルにパフォーマンステストを組み込む
    • 2.27 各メジャーリリースサイクルに価値検証を組み込む
    • 2.28 各マイナーリリースサイクルにユーザビリティテストを組み込む
    • 2.29 各リリースサイクルに互換性テストを組み込む
  • 3. ウェブ開発
    • 3.1 関連するテクニカル指標を特定する
    • 3.2 HTML、CSS、JavaScriptを最小化する
    • 3.3 プロジェクト内でコード分割を使用する
    • 3.4 コードにツリーシェイク（Tree shaking）を適用する
    • 3.5 ソリューションへのアクセスを確保する（アクセシビリティを確保する）
    • 3.6 コードの重複を避ける
    • 3.7 サードパーティサービスを厳格に評価する
    • 3.8 HTML要素を正しく使用する
    • 3.9 レンダリングをブロックするコンテンツを解決する
    • 3.10 コードベースの経路探索メカニズムを提供する
    • 3.11 フォームエラーと外部入力の検証する
    • 3.12 メタデータを正しく使用する
    • 3.13 ユーザーの好みに合わせる
    • 3.14 モバイルファーストなレイアウトを開発する
    • 3.15 有益なJavaScriptとそのAPIを使う
    • 3.16 スクリプトの安全性を確保する
    • 3.17 依存関係を適切に管理する
    • 3.18 自動的に期待されるファイルを含める
    • 3.19 適切な場合にはプレーンテキスト形式を使用する
    • 3.20 非推奨、または独自コードの使用を避ける
    • 3.21 技術的要件と持続可能性の目標を一致させる
    • 3.22 最新の安定した言語バージョンを使用する
    • 3.23 ネイティブ機能を活用する
    • 3.24 可能な限り少なく、シンプルなクエリを実行する
  • 4. ホスティング、インフラ、およびシステム
    • 4.1 持続可能なホスティングプロバイダーを選択する
    • 4.2 ブラウザキャッシュを最適化する
    • 4.3 ファイルを圧縮する
    • 4.4 エラーページとリダイレクトの使用は慎重に行う
    • 4.5 追加環境の使用を制限する
    • 4.6 ニーズに合わせて自動化する
    • 4.7 適切なリフレッシュ（更新）頻度を維持する
    • 4.8 重複データに注意する
    • 4.9 非同期処理と通信を有効にする
    • 4.10 CDNとエッジキャッシングを検討する
    • 4.11 ビジネス要件を満たす必要最小限のインフラストラクチャを使用する
    • 4.12 訪問者のニーズに応じてデータを保存する
  • 5. 事業戦略、およびプロダクトマネジメント
    • 5.1 倫理的かつ持続可能性のあるプロダクト戦略を持つ
    • 5.2 持続可能性（サスティナビリティ）担当者を任命する
    • 5.3 意識向上と情報提供を行う
    • 5.4 ユーザーの選択が環境に与える影響を伝える
    • 5.5 プロダクトやサービスが環境に与える影響を見積もる
    • 5.6 明確な組織の持続可能性の目標と指標を定義する
    • 5.7 確立された第三者によるビジネス認証を利用した取り組みを検証する
    • 5.8 持続可能性オンボーディングガイドラインを導入する
    • 5.9 開示と報告の義務化をサポートする
    • 5.10 1つ以上のインパクト・ビジネス・モデルを創造する
    • 5.11 プロダクトマネジメントとメンテナンス戦略に従う
    • 5.12 継続的な改善手順を実施する
    • 5.13 将来の更新と進化を文書化する
    • 5.14 デジタル製品やサービスが必要かどうかを判断する
    • 5.15 機能単位を決定する
    • 5.16 サプライヤー行動規範を作成する
    • 5.17 経済的利益を共有する
    • 5.18 適切なステークホルダーと意思決定権を共有する
    • 5.19 JDEI（Justice（正義）、Diversity（公平）、Equity（多様性）、Inclusion（包摂性））慣行を活用する
    • 5.20 責任あるデータ実務を推進する
    • 5.21 適切なデータ管理手順を実施する
    • 5.22 責任ある新興テクノロジーの実践を促進し実施する
    • 5.23 責任ある財務方針を盛り込む
    • 5.24 組織のフィランソロピー（社会貢献活動）方針を盛り込む
    • 5.25 デジタル製品、またはサービスのケアとライフサイクルの終了に関する計画を立てる
    • 5.26 電気電子機器廃棄物（E-waste）、修理する権利（Right-To-Repair）、およびリサイクル方針を盛り込む
    • 5.27 パフォーマンスと環境予算を定義する
    • 5.28 オープンソースのツールを使用する
    • 5.29 事業継続と災害復旧計画を作成する

2.1 システミック・インパクト・マッピングを実施する

システミック（Systemic）とは？と思った方も多いかもしれませんが、システミックデザイン（Systemic design）と呼ばれる、システム思考（世界の複雑さをシステムとして全体や関係性の観点から捉える方法）とデザインを統合したアプローチと関係します。

システミックデザインの文脈においては、デザインされたプロダクトもたらす、経済的、社会的、環境的な影響をシステムとして捉え、設計プロセスに組み込んでいきます。その際に、各システムをマッピングする（相互の影響関係を明らかにする）ことで視覚化し、最も効果的な解決策を導き出すわけですが、システミック・インパクト・マッピングの実践とは、まさにこのことです。

2.7 不必要な、あるいは過剰なアセットを避ける

見た目のきれいなウェブサイトやアプリケーション自体は素晴らしいことですし、それを否定はしませんが、持続可能なデザインという考え方の上では、過剰なビジュアルでインターフェイスを乱雑にすることは避けましょう。

ウェブサイトのレンダリング量を減らす事は、温室効果ガス排出量を減らすこともつながりますよ。ということですね。

2.10 認知されたデザインパターンを使用する

オリジナリティは大切ですが、車のハンドルやアクセル、ブレーキの位置が基本的にはどのメーカー、車種でも共通しているように、ウェブサイトやウェブアプリケーションのUIにも、広く認知されたパターンというのが存在します。そこから大きく外れるレイアウトやデザインは、ユーザーの判断を鈍らせたり、ユーザー体験を低下させますので避けましょう。

2.11 操作的なパターンを避ける

ガイドラインがいう「操作的なパターン」というのは、一般的にダークパターンや欺瞞的なデザインのように、ユーザーをサイト運営者が利己的に操作することで、必ずしもユーザーの利益にならないような行動を取らせたり、逆に行動を制限しようとするような試みのことです。

弊社でもよく、短期的な自己利益だけを追い求めてユーザーの利益を最優先に考えないと、長期的な利益は望めないし、信用を失いますよという話をしていますが、まさにそういうことです。

3.4 コードにツリーシェイク（Tree shaking）を適用する

ツリーシェイク（Tree shaking）とは実行されないコードを削除することです。要するに無題なコードを排除して、ファイルサイズを最適化しましょうという話ですが、大規模なウェブサイトやウェブアプリケーションにおいては口でいうほど簡単ではなかったりします。

3.5 ソリューションへのアクセスを確保する（アクセシビリティを確保する）

そのままですが、ウェブサイトやウェブアプリケーションをアクセシブルにしましょうということです。

3.8 HTML要素を正しく使用する

HTMLのセマンティクス（意味論）は重要ですよという話です。構文的にはもちろん、意味的にも正しいHTMLを記述する必要があります。

3.22 最新の安定した言語バージョンを使用する

解決したい課題、満たしたい要件に最も適したプログラミング言語やフレームワークを選択するのはもちろんですが、それらもなるべく最新のものを使用することでセキュリティやパフォーマンスを向上させることができます。

4.5 追加環境の使用を制限する

今は使っていないテスト環境が忘れ去られたまま稼働していないかなど、無駄な環境をなくしましょうということですね。

さて、簡単にいくつかのガイドラインを挙げて説明してみましたが、中にはサスティナビリティの文脈とは関係なく、普段の品質管理の一貫で実践していたり、自社の制作ガイドラインに同じような項目が盛り込まれている場合もあるかもしれません。

今の時代、ウェブサイトやウェブアプリケーションの制作、開発現場においても、サスティナビリティの観点を抜きに仕事を進めることは困難になるでしょう。

「Web Sustainability Guidelines (WSG) 1.0」は、かなり分量のあるガイドラインですが、そういう時代に対応するためのひとつの参考資料として、興味がありましたら一度目を通してみると気付きがあるかもしれません。

なお、冒頭の繰り返しになりますが、「Web Sustainability Guidelines (WSG) 1.0」はまだ正式な標準化プロセスに進むかどうかも不明なドラフト（草案）ですので、あくまでひとつの参考情報として活用することをお勧めします。