この文書は、W3C 品質保証グループの作業の一環として作成されたものです。 この文書に対するフィードバックは、公開アーカイブされているメーリングリスト(public-evangelist@w3.org)へ、また個人的なフィードバックは、 Karl Dubost (karl@w3.org) にお願いします。
また、本文書の作成に関して、 レビューやコメントを頂いた方々 に感謝します。
本文書の翻訳は歓迎です。 しかし、翻訳作業を開始する前に、必ずW3Cの Copyright FAQ にある翻訳についての情報を読んで下さい。 また、本文書の既存の翻訳リスト(http://www.w3.org/QA/translations#switchにて参照可能) を確認して下さい。
あなたがマネージャであれ、Web開発者であれ、マーケティングやコミュニケー ションチームのメンバーであれ、もしくは個人のWeb管理者であれ、 いろいろなところで、Web標準の利点について読んだことがあると思います。 そしてあなたは、これらのWeb標準が、 あなたのWebサイトのコストの削減や 管理の容易さにおいて有益であると理解し、 これらの標準に切り替える - これらの標準を あなたのWebサイトに導入することに決定したかと思います。
しかし、Webサイトを標準に準拠するよう移行するにあたって、 どこから始めて、どうやって構築すればよいかについて 記載されたガイドは、残念ながら、なかなかありません。 また、大きなWebサイトであるほど、この目標は達成できないように思えるかも 知れません。 もしあなたが、Web標準とは何なのか、よく分からないのであれば、 Web標準の本当の意味 [WEB-QUALITY]、 Webサイトの品質を高めるには [REQ-WEBAGENCY]、 Webサイトをアクセシブルにすることの有益性 [WAI-PROFIT] 等の文書を読むことをお勧めします。
本文書に書かれている方法は、あらゆる規模のWebサイトに対して適用するこ とができます。個人の小さなビジネスサイトを管理している場合から、 大きな企業のWebサイトを管理している場合まで、 あらゆる規模のサイトに適用可能です。
本文書で述べる方法は、 既存のWebサイトの調査から新しいWebサイトの構築までが、 複数の独立したステップから構成されており、 各々ステップは、全て独立して実行できるようになっています。 また、各々のステップは、1つのワークフローに沿って、 別々に、繰り返し実行可能であり、 そして個人のスキルに依存しないため、 別々の人によって、いろいろなレベルで実行することが出来ます。
あなたのWebサイトの規模の大小に関わらず、あなたのWebサイトは、最初は標準 から外れていることでしょう。かなりの数のページが、あなたが設定した、 Webサイトの品質基準に、適合していないものと思われます。
コミュニケーションチーム、技術チーム、マーケティングチーム、マネジメント チームを集めて、あなたのWebサイトについて、評価したい項目のリストを作成し ましょう。この段階では、修正したい項目の優先順位を付ける必要はありません。 しかし、少なくとも、あなたのサイトにおけるHTMLとCSSの正当性、アクセシビ リティ、国際化についてチェックすることを勧めます。 これらのテクニックについては、後ほど説明します。
本文書で述べる方法は、あなたのWebサイトをW3C標準に沿って改善する 方法についてですが、あなたはこの方法を、あなたのWebサイトが準拠しなけ ればならない、他の要求事項に対して適用することもできます。 以下に、おおまかな項目のリストを示します。
あなた、もしくはあなたのチームが、あなたのWebサイトが持つ問題について理解 し、対応する技術を持っていない場合もあるかも知れません。このような場合に は、— 協力を求めましょう。 アクセシビリティや国際化の専門家を招き、あなたのチームに参加してもらいま しょう。例えば、アクセシビリティ(身体の不自由な人たちがあなたのWebサイト にアクセスしやすいかどうか)については、あなたの近くの団体、例えば盲目の 人たちの団体に協力をお願いすることができると思います。— たいていの場 合、彼らは喜んで協力してくれるでしょう。 もしあなたが、大きな組織のメンバーであったならば、あなたの会社の中に、 身体の不自由な人がいると思います。あなたの会社の人事部門に問い合わせて、 彼らにこのプロジェクトに参加してもらうように、提案してみて下さい。
テストしたい項目が決まったら、次にあなたのWebサイトが現在抱えている問題 を特定しましょう。 もっとも良い方法は、まずあなたのサイトに含まれるURIを全てリストアップす ることです。これはさほど複雑な作業ではありません。— ページリンクを 辿る単純なロボットを作成し、それによって作成されたURIリストを、テキスト ファイルに書き出す(例えば、各URIを1行に書き出す)だけで十分です。
あなたのWebサイトで使われている技術が、ロボットエンジンによってアクセ スできない場合もあるかも知れません。この場合は、それ自体が アクセスできないページの数を識別する方法となります。 基本的に、この方法は、どのページが検索エンジンによって インデックスできないかを調べる方法になります。 これはすなわち、あなたのWebサイトに入ってくるトラヒックを遮断しているこ とになります。
URIのリストを作成したら、次に あなたのテスト作業を援助するためのプログラムである Log検証ツール [LOG-VALIDATOR] を使いましょう。 Log検証ツールは、URIのリストを受け取り、 あなたがテスト開始時にロードするように選択したモジュールに沿って、 分析を行います。 (この作業はあなたの技術チームの作業になると思います。 技術チームの人たちと、あなたのサイト用の設定について検討して下さい。) Log検証ツールは、各々のURIに対して一連のテストを実施し、 その結果を返します。
この最初の分析によって、あなたのWebサイトの健康状態についての 概要を知ることができます。 これにより、必要な作業を整理して、エラーのあるペー ジを修正するための戦略を練ることができます。 もしかしたら、膨大な数のページが、あなたの設定した基準に 適合していないかも知れません。 例えば、あなたのWebサイトの全てのページが、 不適切なHTML(またはXHTML)かも知れません。 でも、心配する必要はありません。— これは、実はよい結果なのです。何故って？ それはもし、あなたのWebサイトの作成に、 特定のテンプレートエンジンまたはコンテンツ管理システムが 使用されているのであれば、この結果は、そのテンプレートに 誤りがあることを示しているからです。
この場合には、問題は簡単に解決することができます。 単に、あなたのテンプレートを修正し、再度、全てのテストを実行すれば よいのです。その結果、エラーは非常に少なくなるか、 むしろ多分、全てのエラーをなくすことができるでしょう。 もしあなたが、テンプレートエンジンの開発者でないのであれば、 その開発者、もしくはあなたのWebサイトの CMS の作成者に、適宜、問題を修正するように依頼して下さい。 また将来、あなたのWebサイトを設計しなおす場合には、 Buy standards compliant Web sites [ REQ-WEBAGENCY] 内にある勧告に、従うようにして下さい。
この最初のステップの後に、 まだあなたのWebページにエラーがあったとしても、 心配する必要はありません。 — このガイドは、それらの問題を修正するためにあるのですから。
この最初のステップによる別の効果として、 あなたのサイト内の全てのページについて、 具体的なアイデアを得ることができることが挙げられます。 例えば、もしあなたがあるページを移動したい、 またはWebサイトのあるセクションを削除したいと思ったときには、 あなたのサイトの訪問者を、新しいページに適切に導くための よりよいアイデアを思いつくことができるでしょう。 そしてその結果、外部リンク(他のサイトや検索エンジンなど)からの トラヒックを失わずに済みます。 忘れないで下さい。 優れたURIは、決して壊れないということを。
ここまでの作業で、基準に適合していないページおよび問題のあるページを 全てリストアップ出来ました。このリストが長いか短いかは問題ではありません。 リストの大小に関わらず、ここで説明する対処方法は同じです。 基本理念は単純です。: 「Fixしないように! 作業を構築し、改善しよう」
あなたのWebサイトを、一度に全て修正する必要は全くありません。 それは、以下の2つの主な理由からです:
更に、他の問題を放置して、ある特定の分野の問題のみを修正しようとしないで 下さい。例えば、あなたがあるページをHTMLに適合させ、かつアクセシブルにし たいと思ったならば — それらの作業は、同時に行ってください。 もし、これらの作業を順々に行ったならば、後で行った修正サイクルが、 以前の修正結果に対して、影響を与えてしまうかも知れません。
結論: 一度に修正しない、サイクルで修正しない、 — あなたの修正過程を改善させましょう。
この方法を成功させる鍵は、選択を現実的に行うこと、そしてその選択が 効果をもたらすことを確保することです。 Webページを改善するにあたっては、1つのページが持つ全ての問題を解決するのに、 どれくらいの時間がかかるかを定義する必要があります。 あなたのWebサイトの、一般的な問題を持つサンプルページについて、 適切な技術者とリソースを、あなたのWebサイトのワークフローに沿って、 検討してみて下さい。
いくつかのページについて、どれくらいの時間がかかるかを定義することによっ て、この修正作業全体に、どれくらいのリソースと人員を割く必要がある か、より正確に定義することができるでしょう。また、1日あたり、どれくらい のページを実際に修正することができるかを定義することができるでしょう。
修正作業は、週/月ベースではなく、1日ベースで行うことを推奨します。 その方が、作業の責任者は、この作業のためのスケジュールを、 容易に立てることができます。 また、1日ごとの方が、週ごとに比べて、より少ない時間で 修正を行うことができます。25ページを1週間のうちの1日で修正するよりも、 1日に5ページ修正する方が、負担も軽く、容易です。
これらの作業を行うチームと、定期的なミーティングを開催して下さい; 彼らの意見・議論・経験を収集して下さい。 これは、循環している問題が、CMSによるものなのか、Webページの 編集プロセスによるものなのかを、特定するのに役立つでしょう。 また同時に、修正プロセスとツールの品質を高めることが出来るでしょう。
この方法の実践による経験によって、しばらくすると、マイルストンを 設定することができるようになるでしょう。 例えば、あなたのページに入ってくるトラヒックの50%が、 あなたが適宜した基準に適合したページに到達する、 というマイルストンを設定し、この目標を達成したならば、 次は60%に上げる、という感じです。 どのようなテストや目標を設定するにしても、 合理的な、小さなものにして下さい; この方法は、継続的でありながら、かつ達成・改善可能なものだからです。
このプロジェクトを本当に成功させるためには、 この作業に関わっている人たちを、まとめる必要があります。 使用しているツールや方法をを理解することによって、 問題がどこで発生しているかを確定することができるでしょう。 — ツールの問題なのか、それともツールを使用している人の問題なのか? もしオーサリングツールが、あなたのページの問題を引き起こしているならば、 コメントを集めて、そのツールの作成者に、彼らのソフトウェアを改善して もらうように、交渉してみて下さい。 これは、大きな企業で、沢山のユーザがいる場合には、特に言えることです; これは、改善を確かなものにするための、より賢い方法です。
改善結果を公開しましょう。— 公表しなくとも、少なくとも、そのチーム内で。 これによって、進捗を示すことができ、それは、 メンバーにとって、継続する励みになるでしょう。 もし、公開するシステム自体に問題があるのであれば、 そこから改善していく必要があります。
本文書で既に引用した、 ログ検証ツール [LOG-VALIDATOR] は、あなたのサイトのどの部分に問題があるかを特定するのに、 役立つでしょう。 このツールは、デフォルトモードでは、HTMLの正当性を順に検査するように 設計されています。 その基本原理は、極めて簡単です: Webサーバのログファイルを元に、 日ごとに、最もアクセスされているページの順番を作成し、 その最初のnページ(nの値は設定可能)を W3C マークアップ検証ツール に送ります。そして、その検証結果が送られてきます。
どういう恩恵があるのでしょう? これによって、最もアクセスされているページを先に修正し、 あなたのWebサイトの品質を、 — ページの絶対数という点からではなく、 評価することができます。
ログ検証ツールは、Perlで書かれたオープンなモジュールアーキテクチャ なので、あなたの目的に添ったモジュールを開発して、追加することが出来ます。 例えば、スペルチェッカー、ページ内のロゴやフッタ情報が正しいかどうかを チェックするモジュール、または、あなたのサイト内のリンク切れを チェックするモジュールを既に持っているかも知れません。 これは、容易にインストール可能なツールであり、 CPANアーカイブに含まれています。
可能性をあげれば、きりがありませんので、現実的に、目標を設定しましょう。
ログ検証ツールに慣れたならば、 ログ検証ツールの結果を分析・使用する、別の方法もあります。 例えば、内部メーリングリストを設定して、 あなたのWebサイトの品質保証チームが、 毎朝、要注意なURIのリストを受け取ることができるようにして、 チームが、その内容を修正するか、もしその原因が他にあるのであれば、 それを報告することができるでしょう。
このステップ・バイ・ステップの方式は、 あなたのWebサイトの品質を高めるのに役立ちます。 しかし、問題が繰り返し起こるならば、 基本的な部分を見直す必要があります。
時々(例えば3ヶ月ごとに)、全ての分析を行えば、 あなたのWebサイト全体の品質が向上しているかどうかをチェックし、 あなたのテンプレートエンジンに関わる問題が何なのかを特定することが できるでしょう。これは、あなたが最初に設定した目標に沿ったものです。 もし、あなたのWebサイトの品質が向上しないならば、このプロセス自体を どこか修正する必要があります。
最終的に、あなたのチームおよびこの作業に関わった人たちに 対して、あなたの成果を示すことは、彼らにとって報酬となります。 また、少しずつ、あなたは、あなたの所属する組織にとって有益な経験を得る ことでしょう。 このレビューを指揮すると同時に、行ったことのリストを作成し、 公開して下さい。 これは、あなたのWebサイトの品質の更新記録となるでしょう。
あなたの会社内に、会社のカラーやロゴについてのポリシーを規定した スタイルガイドがある場合が多いと思います。 Webサイトのエラーが検出された際には、これらのガイドに、それを改善する 単純なテクニックについての記述を追加して下さい。
本文書で述べられている方式は、動的であり、固まった方式ではありません。 あなたのニーズに応じて、発展させる必要があります。 もし、あなたの編集プロセスが、すでに適切でない要求事項に沿っていたり、 また、新しい要求事項が追加された場合には、 あなたの編集プロセスを調整する必要があります。 そして、それはすなわち、 品質保証プロセスでもあります。
ここで述べられている、品質評価および改善方式は、お互いに独立したコンポー ネントに分けられています。したがって、あなたにとって不要なコンポーネント は取り除くことが出来ますし、また、必要に応じてコンポーネントを追加するこ とも出来ます。
あなたが問題に対処することが不可能で、その結果、 実際には、直接的な解決方法がない場合もあるかも知れません。 例えば、あなたが使用しているパブリッシングツールが、 正しいコードを出力せず、いろいろな方法を試しても、結局うまくいかない 場合もあるでしょう。 このような場合には、情報を集め、その製品を作っている会社に送ることが、 絶対に必要です。その際には、個人としてではなく、あなたの会社のサインと 共に送ってください。 あなたは、マーケットの代表であり、オーサリングツールの会社は、 あなたの意見に耳を傾けるでしょう。
あなたのサイトの品質を保守するには、 社内の優れたページの著者には報酬を与え、 また、問題を抱えている人を助ける必要があります。 あなたが選んだ方法に対して、あなたのユーザが利益を見出せない限り、 成功はありません。 これらのプロセスやツール等における、 いかなる問題をも報告してもらうように、彼らに協力を仰ぎ、励まして下さい。 これは、組織全体の改善にも結びつくのです。
この単純な方法は、長年に渡って、W3C内部において、HTML部分に対して 適用され続け、様々なWebページの正当性の保守に役立ってきました。 この方式を、あなたの会社やチーム内で使用すれば、 とても強力なものとなるでしょう。
本文書をレビューしていただいた、 Olivier Théreaux、 Stephanie Troeth、 Denis Boudreau、 および public-evangelist メーリングリストの方々 に感謝致します。
Created Date: 2003-03-28 by Karl Dubost <karl@w3.org>