Webサイトを構築するときにチェックをする多種多様な項目を紹介致します。
| プロジェクト計画 | |
|---|---|
| 目的共有 | プロジェクトの目的を見失うとすべての判断基準が狂うため、これを共有する。 |
| 工数設計 | 我々はビジネスとして成果と利益の両立を目指す。そのためにプロジェクトのコンディションを正しく把握する必要がある。 |
| プロジェクト進行 | どのようなプロジェクトでもアジャイルの思想にのっとり、タスクの可視化をした上で作業に取り組む。可能ならスプリント運用 |
| 必要資料の共有 | 資料が不足するとすべての判断基準が狂うため、これを常に見えるところで共有する。 |
| プロジェクトファシリテーション | |
| MTG | 進捗をお互いに報告できるようにしている。 |
| 完了の定義 | 曖昧なタスクの完了は、負債を将来にまわしているだけである。 |
| 情報共有 | プロジェクト進行にともなって増える資料は、随時まとめ、共有する必要がある。 |
| テキストコミュニケーション | コミュニケーション方法の統一は、履歴の検索性を高める。 |
| 要件定義 | |
| 開発スコープ | やること・やらないことを明確にし、無駄のないスピーディーな開発を行う。 |
| 制作要件 | 作る段階で、納品を考慮した開発を行う。 |
| 要件定義書 | クライアントへの説明が必要な場合、またはこれを元に開発を進めていくという約束事。開発要件、品質、パフォーマンスの定義などもこちら。 |
| ワイヤーフレーム | デザイン前にどのような形になるのか、どうするべきかを考える必要がある。場合によってはこれが原稿そのものになる。 |
| 動作環境 | 動作環境がわからないと使える技術もわからない。だから決める |
| 進行管理 | |
| タスク管理 | タスク管理はプロジェクトの要 |
| タスク粒度 | 大きすぎるタスクは、タスク範囲を曖昧にし、また進捗が見えづらくなる。 |
| 時間計測 | スキル面にしてもスケジュール面にしても、建てた計画と実働の差を分析することで改善につながる。 |
| バックログ | 今やることとは別にこれからやることも計画性は必要である。その上でスケジュールを建てる |
| 開発環境 | |
| 構築設計 | 設計のすり合わせは、不要な手戻りを防ぐ |
| 開発環境の整備 | 各案件によって開発環境が異なる。制作者が自由に行うのではなく、開発環境の共有を行い合意を取ること |
| 本番環境の有無 | 本番環境がどのようになるのかを必ず確認すること。 |
| サイトマップの有無 | サイトマップがあるか。ハイレベルサイトマップだけではなく、詳細が明記されているサイトマップであれば望ましい。 |
| バージョン管理 | バージョン管理が無いプロジェクトなんてありえない。 |
| コーディングルールの定義 | チーム内での共通認識、個人差を埋める |
| 質問管理・課題管理・修正管理 | プロジェクト単位で必ず問題は発生する。問題が発生した際、どのような課題があるか、質問があるかをストックしていくこと。 |
| http/https | ドメインの影響を確認 |
| 外部サービスの利用 | API、ASPなど |
| .htaccess | サーバー側で何ら化の設定をしたい場合確認 |
| JSライブラリの実装 | jQueryなどを使用する場合 |
| JSの実装 | ページ固有のJSの実装が必要な場合 |
| フレームワークの採用 | Bootstrapなどのフレームワークを使用する場合 |
| 品質管理 | |
| テスト計画 | 作るものの定義と同時にテストも計画する |
| デザイン実施前 | |
|---|---|
| 設計の確認 | 設計からデザインデータ（psd、ai、png、sketchなど）の内容を確認できる状態にできる。 |
| 実装可否の確認 | 実装をする際、不可能なことはほとんどないが要素に応じて相談が必要な箇所が存在する。 |
| 各端末の挙動について | リキッド、レスポンシブ対応など |
| デザイン・イラスト・画像・写真データの支給の有無 | 使用可能なデータの確認 |
| デザイン・イラスト・画像・写真データの著作権、肖像権の確認 | 支給されるデータの著作権、肖像権に問題がないか、または制作側に不備がないか確認 |
| デザインガイドラインの有無 | デザインガイドラインが存在するか、または作成が必要か確認 |
| モジュール・コンポーネントの有無 | 共通のパーツを用いてデザインが構成されている。 |
| 余白の指定 | 余白は機能であり、バラバラと都度設定、勝手に判断・変更しないこと |
| エラー箇所と修正方法を明示 | ユーザーがエラーを認識し、どこをどのように修正すれば良いか設計されている |
| 動画の取り扱い確認 | 動画がある場合、支給されるか、どのように取り扱うか |
| 動画のキャプション（字幕）を提供するか | 動画がある場合、音声を聞くことができなくてもコンテンツを理解できるか |
| ホバー・アニメーションの有無 | 何らかのインタラクションが存在する場合は指示をもらうこと。 |
| デザイン品質 | |
| 全体のデザイン確認 | デザインを確認し、Webでの再現性があることを前提とする |
| 全体のサイズ確認 | デザインのサイズを確認し、指定のサイズ及び統一されていることを前提とする |
| 文字サイズ | 各種文字サイズが実装可能か、改行をしても耐えられるデザインか確認。 |
| 余白 | 余白に矛盾がないか、CSSフレームワーク、グリッドシステムなどと矛盾がないか確認。 |
| カラー | 文字色、リンク色（デフォルト、ホバー、アクティブ、アウトライン）、背景色に不備がないか確認。文字色、背景色のコントラスト比に注意すること。コントラスト比を 3:1 以上にする。 |
| 情報を伝える色の使い方に注意する | 色だけで情報を伝えようとしていないか（グラフなど、色のみで差別化している、など）確認。 フォームなどのエラーなどで色のみで必須などを伝えようとしていないか。 |
| 要素の抜け漏れ | 設計から要素の抜け漏れがないか確認。制作者側で要素を勝手に削らないこと。 |
| 繰り返し処理 | 繰り返し処理をするような箇所がないか確認。繰り返した場合に表示が崩れる可能性があるかなど。リスト、サムネイル表示、文章表示がこれに該当する。 |
| クリック範囲 | デザインだけではどこがクリックできる箇所なのか、判断できない場合がある。明らかなボタンなどは良いが、画像にリンクを貼るのか、テキストはリンクなのか。リストのクリック範囲はどこなのか、など。 |
| CSS | CSSで再現が可能な角丸、ボーダー、グラデーションなどは可能な限り実装することを確認し、背景画像、アイコン、透過が必要な画像などを区別をつけておくこと。 |
| RWD | 対応しない。もしくはRWDか、リキッドかの確認し、ブレイクポイントまで確認をしておくこと。 |
| コンテンツの拡大縮小がされても問題がないか | コンテンツが拡大されると表示が崩れるなど発生しないか確認が必要。 |
| 画像の書き出し品質 | |
| RWDチェックポイント | |
| 画像比率 | 各デバイスで画像の比率があっているか。画像の出し分けをどのようにするのか確認。 |
| 背景画像の扱い | 背景画像の出し分けが必要か、ある程度画像がはみ出ても問題ないレイアウトか確認。 |
| 情報設計の矛盾 | デザインを確認し、情報設計に矛盾がないか確認。HTML＋CSSのワンソース・マルチユースで成立しない場合はソースの二重表記が許容されるか確認すること。 |
| PC、SPの要素出し分け | PCのときだけ、SPのときだけなど、各デバイス限定で表示する要素の有無を確認。場合によってはアコーディオン、ハンバーガーメニュー、カルーセルなどの切り替えが必要。 |
| レイアウトの切り替えが3パターン程度耐えられるか | PC、SPだけではなく、タブレット、または縦横比率が逆転した際など、最低でも3パターン程度の切り替えが考えられる。工数の問題で、2パターンが限界なことが多いためすり合わせが必要。 |
| 固定サイズではなく、コンテンツ量が常に変動する前提のデザインか | メニュー、リスト、テーブル、カラムなど、テキストの量や画像サイズが統一されない場合を考えられているか。 |
| 改行位置 | よくよく見るとPC、SPのデザインで改行位置が違う。ということがよくある。 |
| コンテキストの矛盾 | デバイス変更時、文章や状況に矛盾がないか確認。例で言えば文中に左側、と言いつつSP時には画像は上にあるなど。 |
| テーブルのレイアウトに無理がないか | テーブルはレイアウトの変更に弱い。SPからデザインしたほうが良い。表の情報がクライアント支給の場合は紙媒体、セルのマージがされることを前提に考えること。 |
| JSの動作確認 | PCで動作したあとにSPサイズにすると表示が崩れる、というのはよくある。逆もまた然り。 |
| HTML開発 | |
|---|---|
| 文字コード | 指定がない際はUTF-8を推奨 |
| 改行コード | CR+LFなど |
| 文字コード指定方法 | <meta charset=”UTF-8″>など |
| 拡張子 | .html / .css / .js / .jpg / .gif / .png / .svg / .pdf /など決めておく。 |
| HTMLファイル名 | サイトマップに準拠。指定がない場合はすり合わせ。 |
| HTML規格 | HTML5 |
| DOCTYPE宣言 | <!DOCTYPE HTML>など。小文字大文字も決めておく。 指定がない際は提案。 |
| ブレイクポイント | Media Queriesを使用したスクリーンサイズによるレイアウト振分け |
| 文書規格 | 半角カタカナ・全角英数字・機種依存文字は使用しない（英語サイトの場合は半角英数厳守）など |
| ページタイトル | title、h1などのルール |
| META Description | 入力するディスクリプション |
| META Keywords | 入力するキーワード |
| Viewportの指定 | Viewportをどのように指定するのか |
| アクセス解析タグ | Googleアナリティクス、Adobeアナリティクスなどの実装が必要か否か |
| ソーシャルタグ関連 | Facebook、Twitterなどのタグが必要か否か |
| ディレクトリ構成 | img、css、jsなどの格納ルール |
| 画像などの代替テキスト | imgのalt属性について |
| リンクの設定 | リンク先が分かる文言か、hrefやtargetの設定について |
| お問い合わせ（form）の使用確認 | formについて |
| フォームコントロールのラベルや説明のマークアップ | コントロールのラベルや入力方法、入力例を操作と関連付けができているか |
| 音声ブラウザ対応の有無 | voiceoverなども含む |
| バリデーションチェック | HTMLの品質担保のため、使用するバリデーションを定義しておく。 |
| CSS開発 | |
| 命名規則 | BEMなど、命名規則が決まっている。もしくは案件ごとに規定がある。 |
| CSS格納ルール | すべてのCSSファイルを一つにまとめるか、importするかを決めておく。 |
| CSSスプライトの使用可否 | 画像が多ければ多いほどリクエスト数が増えてしまう。 |
| フォントサイズの指定 | pxなのか、emなのか、%なのか、vwなのか、決めておく。 |
| フォント指定 | font-familyの指定があるか |
| Webフォントの指定 | インポートする必要のあるフォントはあるか、ある場合はどのように実装するか決まっているか。 |
| 行間の指定 | すべて統一とは限らない、状況に応じて変化できるように想定しておく。pxでの指定はフォントサイズとの兼ね合いで基本はNG。 |
| 調整用CSS | mgn_0やpdn_top_10など |
| 名前空間を利用しない | top-XXXX、header-xxxxなど、空間に依存するid、class名は使用しないこと。 |
| 繰り返し現れるブロックを囲む要素を設ける | ループ処理の際、あとひとつ、divでくくっておけば、、、という状況は多数存在する。最低限のブロック要素だけで実現できるとしても親となる要素を指定すること。親となる要素はdivを推奨。ulやdl、sectionなどはセットとなる子が必要なので非推奨。 |
| sectionにスタイルを指定しない。 | 全体のレイアウトに影響するようなスタイルをsectionに指定しない。 |
| アウトラインが無効化されていないか | フォーカスやアウトラインが認識できないようなCSSになっていないか |
| ベンダープレフィックス | 対応範囲の決定 |
| リセットCSS | 様々なリセットCSSが存在するので、決めておく |
| プリントCSS | 印刷時の対応は要件にあがらないことが多い。必ず確認しておくこと。 |
| CSSハック | 原則使用しない。旧ブラウザの対応で必要に迫られれば対応。 |
| JS開発 | |
| jQueryやライブラリについて | バージョンなど確認しておくこと。jQueryにかぎらずライブラリを使用する際は必ず確認。 |
| ライブラリ、プラグインを利用する場合の使用可否 | 世の中のコードにはライセンスが存在する |
| JSの記述位置 | head内には記述しないこと。ただし、各プラグインの仕様によっては容認する。 |
| 共通のJSファイル | 複数のページで使うことが想定されるものはcommon.jsにまとめてください。 |
| フォーカスについて | 例としてページトップへ戻るを選択した際、ファーカスの位置は適切な位置に移行しているか。ページ内のレンダリング、レイアウト変更すべてに適用すること。アコーディオンなども同様。 |
| No Script対応 | JSが読み込まれない場合の対応 |
| ウィンドウ幅切り替えによる誤動作 | ウィンドウ幅によって制御を変える際、予期せぬ挙動が発生する可能性がある。主にサイズの変更や要素の表示/非表示など。 |
| 解析タグや計測ツールの動作確認 | JSを実装した際、解析タグなどが反応しなくなってる場合もありえる |
| 制作後チェック内容 | |
|---|---|
| テキストの整合性 | 原稿と実装した内容が一致しているか。抜け漏れがないか。 |
| レイアウト・デザインの整合性 | ページによって適用するHTMLやCSSに違いがないか |
| 適用モジュールの妥当性 | リストであるべき箇所がリストになってないなど、適用するモジュールの妥当性を確認 |
| レイアウト・デザインの表示崩れの有無 | 表示崩れがないか |
| 拡大縮小による表示崩れの有無 | 拡大縮小によって表示が崩れないか。定義ができているか。 |
| ウィンドウ幅による表示崩れの有無 | 定義したサイズの中間サイズなど、崩れることも多い。 |
| ウィンドウ幅によるレスポンシブ表示切替 | メディアクエリの統一がされているか |
| 画像内テキストの妥当性と可読性 | 画像に存在するテキストとaltの設定など |
| クリック（タップ）の動作 | リンクなど、必ずチェックすること。CSS、JSの書きぶりによってはアクションしないこともままある。 |
| マウスホバーの動作 | PCなどは特にホバーやアウトラインはしっかり確認をしておくこと。 |
| ページ内リンクの動作性 | ページトップに戻る、途中の見出しに遷移するなど、しっかりと動作するか確認をすること。 |
| 拡大縮小後の動作不具合の有無 | 特にカルーセル、アコーディオン、表示非表示系の動作 |
| ウィンドウ幅変更後の動作不具合の有無 | 特にカルーセル、アコーディオン、表示非表示系の動作 |
| リンクの妥当性 | 指定したリンクが正しいか。デッドリンクが発生していないかなど。 |
| パス指定の整合性 | 相対パスか、ルートパスか、絶対パスかなど。 |
| 別ウィンドウの設定 | 外部サイトやPDFなどは別ウィンドウで表示するなど決まっている場合。 |
| ポップアップ・モーダルの動作性 | 表示されるか、した際の動作に不備がないか |
| TELリンクの有効/無効 | 未実装の場合はリンクされるので、無効にするか否かを決めておく |
| キーボードだけでも操作ができるか | マウス、タッチパネルではなくキーボードやVoiceOverでも操作できるか |
| 画像情報の妥当性（サイズ） | 変倍がかかっていないか、Retinaディスプレイなどでぼやけていないか |
| HTML文法の妥当性 | なんらかのバリデーターを利用すること |
| JS文法の妥当性 | コンソールエラーがデていないか確認 |
| ファイル配置の妥当性 | HTML、CSS、JS、画像などの格納先に誤りがないか |
| 印刷プレビュー | 印刷時に問題がないか確認 |
| ゴミファイルの有無 | thumbs.dbなど。Gitなどバージョン管理を行っている場合は余計なファイルがないか確認。 |
| 納品ファイルの確認 | 納品ファイルに不整合がないか確認すること |
お仕事・当サイトへ興味を持っていただいた方
お問い合わせを頂く際はご確認ください
「ma-san web
design」の管理者。東京都・千葉県（千葉市・四街道市・浦安市・佐倉市）・宮城県（仙台市）を中心に企業のWebデザイン／マーケティング／IT戦略のプランニングからWebサイト構築・運用をしています。
「Webアクセシビリティ」を中心に、「変わりゆくWebと共にサービス・サイトを改善していくこと」を重視します。
当サイトではお仕事のご相談からナレッジシェアを中心に活動していきます。
Webアクセシビリティの重要性について 当サイトが最も注力したい「Webアクセシビリティ」について、ぜひ多様な方々と共に学びながら充実化させ、普及活動に勤しみたいと考えています。
初めて依頼を検討している方 初めてWebサイト制作を依頼する方へ。Webサイトを作りたいと思ったときに参考にしていただけると幸いです。
Webサイトの基本 サーバーの準備からドメイン契約。Webサイトに必要なデータや情報を一通り纏めることで初めてWebサイト制作に携わる方々の学習の一助になれば幸いです。
不明な点やご相談したいことがありましたら、気軽にお問い合わせください。
お問い合わせはこちら