WEBディレクターズガイド#9「動作検証・デバッグ」
1か月ほど空いてしまいましたが、本日はこれまで設計したWEBサイトが実際に組みあがってきて、お客様にテストサイトとして報告する前の内部でのチェックについて話していきたいと思います。これまでの流れについてはバックナンバーをご覧いただければ幸いです。
バックナンバーはこちら
6月からスタートし、フェーズとしては後半くらいには差し掛かって来たのではないかと思います。シリーズとしては全15回なので長いと思いますが、お時間のある時、または気になるところだけをチョイスして…など適宜参考になればうれしいです。
さて本題です。
仕上がったWEBサイトをクライアントへ提出する前に、内部における動作検証を行います。主な検証としては、表示検証、動作検証の2つになります。具体的なテスト項目については下記に記載します。
この場合、サイトマップにデバッグの項目を追加して〇×でチェックしていくと俯瞰して見れるため便利です。
主なチェック作業としては大体以下を行います。
全部で7工程あります。
（1）ブラウザチェック
閲覧対象ブラウザにて適正に表示がされているかどうかチェックします（CSSの崩れがないか？マージンのズレがないか？など）。こちらはあらかじめ要件定義のフェーズで要件定義書として取りまとめたブラウザを対象とします。モバイル対応も当たり前なので、このチェックを行う前に場合によっては検証用の端末の手配も必要になりますね。WEBディレクターであれば当たり前の作業かと思います。
仮にレスポンシブWEBだとしてもPCのブラウザだけで作業は完結させず必ず実機で表示テストは行いましょう。
（2）リンクチェック
WEBページを操作し、リンク切れがあるかどうかチェックします。こちらは有料/無料問わず色々なリンクチェッカーが出ているので、機械的にチェックをすることもできます。が、機械だけに頼るといざと言うときの把握漏れが発生しないとも限らないので、チェック結果は確認し、自分の手でリンク切れがあることを再現しておいた方が良いと思います。
私は結構アナログでもありますので、あまりチェッカーは使わず可能な限りは自分の手でチェックをします。共通部分やテンプレート縛りで一定のルールで切れてる場合とかもあるのでこの場合、誰に修正依頼をかければよいか？がリンク切れの箇所で把握が出来るからです。
（3）CMS動作チェック
CMSの挙動をチェックします。(エラーが出ない、ページ/記事の登録が正常、など）これは使用するCMSによってもチェック推奨箇所が異なったりするので、プロジェクトで採用したCMSによりチェックする内容は変わります。
（4）校正関連
入稿原稿の内容が正しい箇所に正しく表示されているかどうかチェックします。校正ですね、WEB屋が一番おそろかにしやすくまた、チェックに手間がかかる箇所でもあります。
その昔、サイトマップと登録する記事が1段づつずれた状態で数10P入っていた時は発狂しそうになったことがありました。。。（ネタのようですが実話です。。）
印刷会社に所属していた時は、文字校正を専門にやってくれる部署がありましたので、原稿とWEBページの出力をまとめて持参し校正作業を依頼していたこともありました。この辺りも案件のスタート時にプロジェクト計画として含んでおくと良いと思います。
（5）バリデート
正しい文法で記載されているかどうかをバリデーターを使い点数化します。ここは、仮に正しく文書構造化がなされていたとしても正しい文法で記載されていないとマシンリーダブルなサイトにはならないのでチェックが必要です。例えるのであれば、日本語は話せる、だけどきちんとした文章は書けない…みたいな状態でしょうか。筆者が良く使っていたバリデータはこちらです。
Unicorn - W3C 統合検証サービス
https://validator.w3.org/unicorn/?ucn_lang=ja
HTML Lint Gateway（おすすめ）
http://www.htmllint.net/html-lint/htmllint.html
私がよく使用していたのは、Lint Gatewayでした。動作が軽くサクサク見ていきたい時にはお勧めです。最近ですとこちらでアクセシビリティチェックが出来たりしますので、ある種ここさえあれば…という風にも思えます。
（6）アクセシビリティチェック
アクセシビリティ（ JIS-X8341-3）に対応しているかどうかチェックします。これはすべてのプロジェクトで適応する工程ではなく、あくまでアクセシビリティが要件に含まれる場合になります。
グローバルサイトや多言語版サイトの場合はWCAG(現在は3.0が勧告されているはずです。）で見ていく方が良いですが、私はどちらかというとJISで設計して、JISでチェックすることが多かったです。このチェックの場合はデバッガーを使用した方が早く進みますが、デバッガーを使うにしてもベースとなるWEBアクセシビリティの知識は必要です。（チェック結果を読み取れないので）
国としてもアクセシビリティ関する取り組みには力を入れているので、総務省がリリースしているデバッガー「Mi Checker」がありますので今はそちらを使用しています。JIS-X8341-3:2016を基準に診断できます。詳しい使い方は下記のリンク先をご覧ください。
昔は富士通がリリースしていたWeb Inspectorを使用していました。（現在提供終了）
これはどんなことにでも言えますが、機械が網羅できない知識を身に付けておくことはとても大切ですね。なのでチェッカーだけに頼りすぎるのは危険です。
（7）コントラストチェック
前景と背景のコントラストが適正かどうかチェックします。こちらは(6)のアクセシビリティの中に含まれる要件ではありますが、アクセシビリティ対応でなくても色のチェックを行うことは多くありました。それもあり、本来であればアクセシビリティチェックの中に含めてもよい工程なのですが、あえて独立して書くようにしました。
WEBアクセシビリティガイドラインの項目内には「18pt以上のテキスト(見出しレベル）であれば背景と前景のカラーコントラスト比は3:1以上」「14pt以下のテキスト(本文レベル）であれば背景と前景のカラーコントラスト比は7:1以上」というルールがあります。
誰のためのWEBサイト？と捉えると、カラーコントラストくらいはチェックしておいても良いと思います。ちなみに私はカラーコントラストアナライザーを使用しています。こちらはWCAGでの適合レベルをチェックするだけでなく、チェックしている背景と前景のコントラスト比が現在いくつなのか？も分かりやすく表示してくれるため、少し古いソフトですが今も重宝しています。
最後に
今回はWEBサイトのデバッグとして抑えるべきポイントについて書かせて頂きました。会社の規模によりけりですが、大きな会社ですと、デバッグチームやQA（クォリティアセスメント）チームなどがありテストを専門でやってくれるところもあります。その場合は遠慮なく専門チームにお任せするのがベターですが、そういった場合でも段取りや采配はディレクターの仕事になります。
・どんなサイトで
・どれくらいのボリュームがあって
・どんなところを見てほしいか？
・修正がある場合のフィードバック方法は？
・いつまでに？
・何名くらいで…
などテスト工程を仕切るポイントは、抑えておいた方が良いと思います。
上記のポイントに加え、専門チームがない会社の場合は制作チームが自分たちでテストを行っていかなければなりませんが、ディレクターとしてこのデバッグ工程は程度はさておき必ず通る工程なので、知っておいて損はない項目を記載したつもりです。
次回は、いよいよ制作したWEBサイトをお客様にお披露目するテストアップについて書いていきたいと思います。私が経験したお客様とのやり取り事例なども踏まえてお送りできればと思います。
ありがとうございました！
この記事が気に入ったらサポートをしてみませんか？